MOTS攻击技术分析

背景

我们经常遇到这样一个场景:在用户现场通过端口镜像方式对流量做镜像，用来分析数据包或者审计的时候，疑心较大的用户总是怀疑其数据会被篡改或客户端信任的结果并非真实服务器返回的值。我想大多数的技术兄弟可能都会和我一样回复用户:这是一台审计设备，是旁路部署，只能审计，不是串在里面的，不可能对数据进行篡改；也不可能影响客户端的最终请求响应的结果。这个理论我一直深信不疑，直到前段时间在分析DNS污染的时候才发现这句话并不完全对，难道旁路监听的设备可以用来进行攻击，并影响客户端请求最终的响应结果。的确可以！下面我们来介绍MOTS的攻击原理及常见的攻击类型。

原理

MOTS的攻击原理为：该攻击可行的前提是攻击者可以监听到通信的流量，并且利用时间差优势在正常的响应包返回之前插入精心构造的数据包，同时利用协议本身的弱点达到欺骗客户端的目的。

举个例子：

1、客户端发起一个请求，由于攻击者可以监听客户端，因此这个请求也会到达攻击者，同时服务器也会收到这个请求 2、攻击者和服务器都收到客户端的请求，于是他们都进行了应答 3、攻击者的响应报文先到达客户端，因此客户端接收攻击者的应答 4、由于时间关系，服务器的响应报文此时也送到客户端，但是客户端已经收到了响应报文，因此不处理服务器的响应报文。

这里面的关键有以下：

1、攻击者能够读取流量信息并插入伪造的报文，但是不会修改或删除通信方发送的报文。 2、当受害者发出请求时，攻击者利用时间优势让自己发送的响应先于合法的响应到达受害者 3、TCP UDP协议本身不校验消息的真实性，只接受先响应的。

常见攻击类型

3.1 基于TCP的攻击

我们学习过TCP/IP原理的兄弟们都应该了解：TCP是一种可靠的协议，其可靠性主要依赖TCP确认号。也就是说基于TCP的应用其可靠性一般严重依赖TCP做保证，以打开freebuf首页为例：

67号报文(SYN)的序列号为2859590583，148号报文(ACK+SYN)的确认号为上一个报文的seq+应用层长度+1，这里面上一个报文的序列号为2859590583，应用层长度为0，所以其确认号为2859590584。确认号是攻击基于TCP应用的关键.

3.1.1 DOS

对基于TCP的应用做DOS攻击可以在两个层面做DOS，一般情况下只需要发送单向的Reset包即可。

1、三次握手时 2、对客户端某些特定请求

Ø 对三次握手时做DOS

若客户端请求某个端口或某个特定服务时，通过MOTS做DOS攻击，攻击者只需要监听到客户端的SYN包的序列号，然后发送一个Reset+ACK包即可达到DOS的效果。其对SYN包进行DOS的例子如下所示：

当客户端收到攻击者发送Reset+ACK报文以后，客户端会主动释放连接，此后当正常的服务器的SYN+ACK报文过来以后，由于客户端已经释放了连接，因此客户端一般情况下会忽略这个SYN+ACK报文，不做任何处理。

构造这种攻击报文需要注意以下细节：

1、客户端的IP、源端口、序列号 2、服务器的IP、目标端口 3、IP和TCP校验和计算，具体计算方法大家google一下，在这里不做详细描述。在这里说一下：IP校验和仅校验IP头部；TCP校验和是必选的，其是对TCP头部和数据的校验；UDP的校验和是可选的。 4、攻击报文的源IP为服务器的IP、源端口为服务器的端口；目标IP为客户端的IP、目标端口为客户端的端口；ACK=客户端SYN请求报文序列号+1，并且计算好相应的IP和TCP的校验和，避免客户端校验时发现错误，而将该报文丢弃。

Ø 对客户端某些特定请求进行DOS

这个场景是这样的:攻击者一直监听客户端的请求，并且前期做好相应的策略，一旦客户端请求某些内容时，攻击者主动发送Reset+ack报文释放连接。这里一般情况下可以对客户端的请求进行异常释放，也可以对服务器进行释放；考虑的比较深入的话可以双向发送reset报文来双向释放。技术细节可参考上文。

3.1.2 TCP劫持

基于MOTS的劫持只要TCP的上层为明文传输就存在被攻击的可能。基于MOTS的TCP劫持一般情况下都是劫持基于TCP的上层应用，如HTTP劫持。

大家可能对HTTP劫持了解的比较多，因为大家或多或少都遇到过打开网页的时候运营商在正常页面插入广告或者尾巴的情况，这里面运营商用的比较多的技术是HTTP劫持，当然除了HTTP劫持外还有其他的技术，如DNS污染等。忽略中间的设备，HTTP劫持如下所示：

在这里说明一下HTTP劫持的相关原理和实现细节：

1、攻击者一直需要监听客户端的请求 2、当有请求相关页面时，攻击者利用时间差优势进行应答，如客户端访问www.freebuf.com时，攻击者立即进行应答，此应答报文为攻击者精心构造的报文，其效果可以用来进行推送广告，也可以进行挂马。 3、由于攻击者的应答报文比服务器的应答报文早到，因此客户端接收一攻击者的报文，丢弃了服务器的应答报文。

技术细节：

1、攻击者需要获取客户端的IP、源端口、序列号和服务器的IP、目标端口 2、攻击报文的源IP为服务器的IP、源端口为服务器的端口；目标IP为客户端的IP、目标端口为客户端的端口；ACK=客户端SYN请求报文序列号+应用层长度+1，并且计算好相应的IP和TCP的校验和，避免客户端校验时发现错误，而将该报文丢弃。 3、攻击者的报文一定要比服务器正常的响应报文早到。

针对HTTP劫持freebuf上有案例，大家自行参考，这里我就不多说了。<点击文末的阅读原文查看>

3.1.3 如何发现和解决

其实了解了MOTS的攻击原理以后，找到这种攻击还是有很多种方法的，下面我来总结一下常见的发现MOTS攻击的思路：

Ø 由于MOTS仅作监听，不会篡改正常的应答报文，其只是插入新的应答报文。因此如果客户端同一个请求，收到两个应答报文，并且非重传报文，基本上判定存在MOTS攻击。对于基于MOTS的DOS攻击和HTTP劫持可以通过这种方法分析。 Ø 通过IP的TTL和ID来判断

一般情况下，每经过一个路由设备其TTL都会减一，若为HTTP劫持，其仅对HTTP劫持，并不会对次握手做劫持，因此我们可以通过判定三次握手的TTL和HTTP会话的TTL作比较，若为同一值说明不存在HTTP劫持，若不同则说明存在HTTP劫持。另外，仅仅通过三次握手的TTL和应用的TTL做对比，分析其变化来判断TCP劫持有时候并不科学。因为很多代理设备也会更改TTL，做应用层代理的设备，有些只更改应用层的TTL，TCP 三次握手时其TTL并不更改，因此比较科学判断劫持的方法是：

1、判断三次握手的TTL和应用层的TTL， 2、多取样分析应用层服务器应答的TTL变动，如服务器应用层的应答TTL变化则基本判定存在劫持（这里面说的是基本，并不完全，这个因为不同数据包的返回路径可能不一致，因此导致TTL会变化）

附上一段使用tshark通过分析TTL的变动来检测基于HTTP劫持的方法

tshark-i eth0 -n -Y "(tcp.flags.syn==1 and tcp.flags.ack==1) or(http.response)" -T fields -e"ip.src" -e "tcp.srcport" -e "ip.dst" -e"tcp.dstport" -e "ip.ttl"

IP ID默认也是递增的，也可以根据IP ID的变化来分析是否存在劫持。不过使用IP ID这种方法在很多情况下会带来大量误判，因为很多安全设备、代理设备会改变及随机生成IP ID。

使用Tshark过滤其中一个会话，分析IPID的变化情况，相应的Tshark脚本如下：

tshark -i 2 -Y "tcp.stream == 0" -T fields -e"ip.src" -e "tcp.srcport" -e "ip.dst" -e "tcp.dstport"-e "ip.id"

解决基于TCP的MOTS劫持的方法，个人总结了一下，大概有以下几种方法：

1、会话加密，使用Https、V**等方式，由于中间的数据是进行的，因此只要相应的加密算法、证书等安全，理论上说是没有办法进行会话劫持的。 2、对TCP/IP协议进行改进，收到服务器的响应包时，默认停留一段时间，如果再收到服务器的响应，则分析这两个响应包的TTL和ID变化，通过TTL和ID的变化来判断哪个是服务器正常的响应包。不过这种方法影响用户体验，做的不好的话可能是七伤拳，杀敌一千，自损八百。相对较合理的延迟处理时间及精确的分析TTL和ID可能会有较明显的效果。 3、分片传输，中间攻击者监听到只是分片报文，为其还原真实查询报文增加难度。服务器收到后可以重组，然后得到正常的查询报文。

3.2 基于UDP的攻击

和TCP不同，UDP没有面向连接的机制，其是一种不可靠的协议，没有确认机制。也就是说只要其端口开放，有数据需要交互时直接进行数据交互，也不需要TCP的三次握手。这样的话，基于UDP的攻击比基于TCP的攻击需要分析的条件相对少了一些。

3.2.1 DOS

由于UDP没有三次握手，因此对基于UDP的DOS只能对其数据交互时进行DOS攻击。如果客户端在访问某项UDP服务，攻击者想达到DOS的目的，只需要伪造服务器发送一个ICMP Port unreachable即可。ICMP port unreachable的报文格式大家自行google一下，这里不做详细描述。

技术细节：

1、攻击者需要获取客户端的IP、源端口和服务器的IP、目标端口 2、攻击报文的源IP为服务器的IP、源端口为服务器的端口；目标IP为客户端的IP、目标端口为客户端的端口；ICMP port unreachable，并且计算好相应的IP校验和，UDP的校验和是可选的，因此可以关闭UDP校验。 3、攻击者的ICMP portunreachable报文一定要比服务器正常的响应报文早到。

3.2.2 DNS污染

这个在运营商和GFW层面做的比较多，有的同学可能会把DNS劫持和DNS污染混为一谈，其实DNS劫持和DNS污染是两种完全不同的概念。DNS劫持是DNS服务器的映射关系被改为错误的，如www.freebuf.com 正常映射的IP为120.55.226.207，DNS劫持就是攻击者入侵相应的DNS服务方，把DNS的映射改为如1.2.3.4这种错误的关系；DNS污染是指DNS查询www.freebuf.com时，DNS服务器返回的是正常的120.55.226.207，同时攻击者伪造DNS服务器的响应包，其DNS响应包里的IP为如1.2.3.4这种关系。客户端正常也可以接收到服务器正常的DNS响应包，但是由于攻击者伪造的DNS响应报文比正常的DNS响应报文早到，因此客户端接收了攻击者的DNS响应报文。

以攻击freebuf为例，展示DNS污染的攻击方法

1、客户端发送一个DNS查询，查询www.freebu.com对应的IP地址 2、由于攻击者对通信进行监听，其可以收到相应的DNS查询报文，同时服务器也可以收到 3、攻击者伪造服务器发送一个DNS响应报文，其对应的A记录为1.2.3.4 4、DNS服务器查询，返回的A记录为120.55.226.207 5、由于攻击者的报文比服务器的报文早到，因此客户端默认接收了攻击者伪造的报文，丢弃了正常服务器的响应报文。

技术细节：

1、前面说到UDP是一种不可靠的协议，DNS的传输层使用UDP，但是并不是说DNS不可靠，其实DNS的发明者考虑到这个问题，为了保证DNS的可靠性，设计了Transaction ID，这个ID查询的时候是随机生成的，响应报文的ID必须和查询报文的ID一致，客户端才认为这是服务器的响应，如果不一致，客户端默认丢弃这个DNS响应报文。因为进行DNS污染时一定要保证响应报文的Transaction ID和DNS查询的Transaction ID一致。

2、DNS污染报文的源IP为DNS服务器的IP、源端口为服务器的端口；目标IP为客户端的IP、目标端口为客户端的端口,并且计算好相应的IP校验和，UDP的校验和是可选的，因此可以关闭UDP校验

3.2.3 如何发现和解决

以DNS污染为例，谈谈如何发现基于UDP的MOTS攻击及相应的解决方法：

如何发现

1、伪造数据包的话肯定可以收到两个响应报文，一个为攻击者发送的，一个为服务器正常返回的。 2、分析其解析后的IP返回的内容，一般情况下进行DNS污染，攻击者可能有利益驱使，要么插曲广告，要么挂马。可以和正常页面做对比来分析是否被攻击。

如何解决

1、还是加密，针对DNS这块网上有相关的加密的DNS，DNS加密只要其加密算法安全，就可以保证DNS不会被污染。DNS加密相关链接：https://www.opendns.com/about/innovations/dnscrypt/ 2、协议该进，不是根据数据包的先后到达顺序来接受第一个响应的报文，而要进行深入分析其响应的协议参数。同一个DNS查询收到两个应答时，校验IP ID、TTL等信息。 3、DNS查询分片传输，中间攻击者监听到只是分片报文，为其还原真实查询报文增加难度。服务器收到后可以重组，然后得到正常的查询报文。

3.3 局域网如何实现

很多人认为MOTS攻击是运营商级别才可以实施的攻击。其实我们在内网也可以进行MOTS攻击，有没有办法在不对设备和链路镜像的情况下，进行MOTS攻击。一种相对较有效的思路为通过开启无线网络的监听模式来实现，然后构造相应的应答报文来实现MOTS攻击。

一点个人想法

以前在安全厂商的时候，经常遇到用户有这种需求:想要让部署的设备不影响正常的业务，最好不要串在网络中，并且可以做到有攻击时及时阻断。其实MOTS这种方式个人认为可以在WAF、防火墙等安全设备上实现，达到旁路部署，同时可以做到阻断的效果。另外：

1、本人没有相应的实现的攻击工具和代码 2、欢迎指点