嗅探，arp欺骗，会话劫持与重放攻击

Sniffer

Sniffer（嗅探器）程序是一种利用以太网的特性把网络适配卡（NIC， 一般为以太网卡）置为杂乱（promiscuous）模式状态的工具， 一旦网卡设置为这种模式， 它就能接收传输在网络上的每一个信息包。 Sniffer分为软件和硬件两种， 一般指的是软件， 但功能有限， 硬件价格比较贵。

Sniffer可以用来监听任何网络信息， 在此 我只关心http/https数据的监听。

下面我以登录126为例， 运行了在网上随便找的一个嗅探工具， 我这里为了更清楚的说明问题没有选"SSL安全登录"选项。 这里我们也该体会到的一点是防止嗅探攻击的最好方式就是加密数据。

在图片的末尾我们可以看到下面的内容：

domain=126.com&language=0&bCookie=&username=xuanhun521@126.com&user=xuanhun521&password=xuanhun&style=-1&remUser=&enter.x=%B5%C7+%C2%BC

用户名和密码都可以被嗅探到。

13.2 会话劫持

下面改编了一下网上的相关资料， 介绍一下会话劫持。

　1、会话劫持原理

我们可以把会话劫持攻击分为两种类型：1）中间人攻击(Man In The Middle， 简称MITM)， 2）注射式攻击（Injection）；并且还可以把会话劫持攻击分为两种形式：1）被动劫持， 2）主动劫持；被动劫持实际上就是在后台监视双方会话的数据流， 丛中获得敏感数据；而主动劫持则是将会话当中的某一台主机"踢"下线， 然后由攻击者取代并接管会话。

（1）中间人攻击

要想正确的实施中间人攻击， 攻击者首先需要使用ARP欺骗或DNS欺骗， 将会话双方的通讯流暗中改变， 而这种改变对于会话双方来说是完全透明的。 不管是ARP欺骗， 还是DNS欺骗， 中间人攻击都改变正常的通讯流， 它就相当于会话双方之间的一个透明代理， 可以得到一切想知道的信息， 甚至是利用一些有缺陷的加密协议来实现。

（2）注射式攻击简介

　　这种方式的会话劫持比中间人攻击实现起来简单一些， 它不会改变会话双方的通讯流， 而是在双方正常的通讯流插入恶意数据。 在注射式攻击中， 需要实现两种技术：1）IP欺骗， 2）预测TCP序列号。 如果是UDP协议， 只需伪造IP地址， 然后发送过去就可以了， 因为UDP没有所谓的TCP三次握手， 但基于UDP的应用协议有流控机制， 所以也要做一些额外的工作。

对于IP欺骗， 有两种情况需要用到：1）隐藏自己的IP地址；2）利用两台机器之间的信任关系实施入侵。 对于基于TCP协议的注射式会话劫持， 攻击者应先采用嗅探技术对目标进行监听， 然后从监听到的信息中构造出正确的序列号， 如果不这样， 你就必须先猜测目标的ISN（初始序列号）， 这样无形中对会话劫持加大了难度。

　　2、TCP会话劫持

如果劫持一些不可靠的协议， 那将轻而易举， 因为它们没有提供一些认证措施；而TCP协议被欲为是可靠的传输协议， 所以要重点讨论它。

　　根据TCP/IP中的规定， 使用TCP协议进行通讯需要提供两段序列号， TCP协议使用这两段序列号确保连接同步以及安全通讯， 系统的TCP/IP协议栈依据时间或线性的产生这些值。 在通讯过程中， 双方的序列号是相互依赖的， 这也就是为什么称TCP协议是可靠的传输协议（具体可参见RFC 793）。 如果攻击者在这个时候进行会话劫持， 结果肯定是失败， 因为会话双方"不认识"攻击者， 攻击者不能提供合法的序列号；所以， 会话劫持的关键是预测正确的序列号， 攻击者可以采取嗅探技术获得这些信息。

　　TCP协议的序列号

　　现在来讨论一下有关TCP协议的序列号的相关问题。 在每一个数据包中， 都有两段序列号， 它们分别为：

SEQ：当前数据包中的第一个字节的序号

ACK：期望收到对方数据包中第一个字节的序号

　　假设双方现在需要进行一次连接：

S_SEQ：将要发送的下一个字节的序号

S_ACK：将要接收的下一个字节的序号

S_WIND：接收窗口

//以上为服务器（Server）

C_SEQ：将要发送的下一个字节的序号

C_ACK：将要接收的下一个字节的序号

C_WIND：接收窗口

//以上为客户端（Client）

它们之间必须符合下面的逻辑关系， 否则该数据包会被丢弃， 并且返回一个ACK包（包含期望的序列号）。

C_ACK <= C_SEQ <= C_ACK + C_WIND

S_ACK <= S_SEQ <= S_ACK + S_WIND

　　如果不符合上边的逻辑关系， 就会引申出一个"致命弱点"。

　　这个致命的弱点就是ACK风暴(Storm)。 当会话双方接收到一个不期望的数据包后， 就会用自己期望的序列号返回ACK包；而在另一端， 这个数据包也不是所期望的， 就会再次以自己期望的序列号返回ACK包……于是， 就这样来回往返， 形成了恶性循环， 最终导致ACK风暴。 比较好的解决办法是先进行ARP欺骗， 使双方的数据包"正常"的发送到攻击者这里， 然后设置包转发， 最后就可以进行会话劫持了， 而且不必担心会有ACK风暴出现。 当然， 并不是所有系统都会出现ACK风暴。 比如Linux系统的TCP/IP协议栈就与RFC中的描述略有不同。 注意， ACK风暴仅存在于注射式会话劫持。

　　TCP会话劫持过程

　　假设现在主机A和主机B进行一次TCP会话， C为攻击者， 劫持过程如下：

A向B发送一个数据包

SEQ (hex): X ACK (hex): Y

FLAGS: -AP--- Window: ZZZZ， 包大小为:60

B回应A一个数据包

SEQ (hex): Y ACK (hex): X+60

FLAGS: -AP--- Window: ZZZZ， 包大小为:50

A向B回应一个数据包

SEQ (hex): X+60 ACK (hex): Y+50

FLAGS: -AP--- Window: ZZZZ， 包大小为:40

B向A回应一个数据包

SEQ (hex): Y+50 ACK (hex): X+100

FLAGS: -AP--- Window: ZZZZ， 包大小为:30

攻击者C冒充主机A给主机B发送一个数据包

SEQ (hex): X+100 ACK (hex): Y+80

FLAGS: -AP--- Window: ZZZZ， 包大小为:20

B向A回应一个数据包

SEQ (hex): Y+80 ACK (hex): X+120

FLAGS: -AP--- Window: ZZZZ， 包大小为:10

　　现在， 主机B执行了攻击者C冒充主机A发送过来的命令， 并且返回给主机A一个数据包；但是， 主机A并不能识别主机B发送过来的数据包， 所以主机A会以期望的序列号返回给主机B一个数据包， 随即形成ACK风暴。 如果成功的解决了ACK风暴（例如前边提到的ARP欺骗或者其他方式）， 就可以成功进行会话劫持了。

3.http会话劫持

Web应用程序是通过2种方式来判断和跟踪不同用户的：Cookie或者Session（也叫做会话型Cookie）。 其中Cookie是存储在本地计算机上的， 过期时间很长， 所以针对Cookie的攻击手段一般是盗取用户Cookie然后伪造Cookie冒充该用户；而Session由于其存在于服务端， 随着会话的注销而失效（很快过期）， 往往难于利用。 所以一般来说Session认证较之Cookie认证安全。

会话型cookie也是可以通过程序获得的， 换句话说我们进行TCP会话劫持的时候如果针对http会话劫持的话可以截获所有http内容包括Session信息。

下面我们一个具体的例子。 这个例子中我使用的是一个非ARP欺骗方式的工具SSClone。 本机ip是192.168.1.107， 我在ip地址为192.168.1.105的机器上打开126邮箱。

之后在ip是192.168.1.107的计算机上我们截获了这个会话， 而且可以直接进入邮箱， 不用登录。

哎呀， 好累， 还剩点内容， 留到明天吧， 欢迎各位读者踊跃批评。