转自:http://baike.baidu.com/view/1569933.htm
目录
1类型编辑
根据消息的来源
1.协议轮内攻击:一个协议轮内消息重放
2.协议轮外攻击:一个协议不同轮次消息重放
根据消息的去向
1.偏转攻击:改变消息的去向
2.直接攻击:将消息发送给意定接收方
其中偏转攻击分
1.反射攻击:将消息返回给发送者
2.第三方攻击:将消息发给协议合法通信双方之外的任一方
2详情编辑
详情内容
重放攻击是计算机世界黑客常用的攻击方式之一,所谓重放攻击就是攻击者发送一个目的主机已接收过的包,来达到欺骗系统的目的,主要用于身份认证过程。
为了抵御重放攻击,现在的身份认证一般采用“挑战应答”(Challenge/Response)方式。
-----申请登陆----〉
〈---发送挑战值----
客户端计算相应的应答值
(可以用MD5算法计算应答值)
------发送应答值--〉
系统通过同样的算法
判断应答值是否正确
〈---通过认证(正确)--
不正确则断开连接
这里要注意的是挑战值得熵值必须大(变化量要很大,一般为随机数),若挑战值变化量不大,攻击者只需截获足够的挑战应答关系,就可以进行重放攻击了。(具体“挑战应答”方式流程可见HMAC算法应用)
典型例子
重放攻击与
cookie
我们监听http数据传输的截获的敏感数据大多数就是存放在cookie中的数据。其实在web安全中的通过其他方式(非网络监听)盗取cookie与提交cookie也是一种重放攻击。我们有时候可以轻松的复制别人的cookie直接获得相应的权限。关于cookie,我想应该用单独的一篇文章来说明,在这里就不重复了。
3防御方案编辑
时间戳
“时戳”──代表当前时刻的数
基本思想──A接收一个消息当且仅当其包含一个对A而言足够接近当前时刻的时戳
原理──重放的时戳将相对远离当前时刻
时钟要求──通信各方的计算机时钟保持同步
处理方式──设置大小适当的时间窗(间隔),越大越能包容网络传输延时,越小越能防重放攻击
适用性──用于非连接性的对话(在连接情形下双方时钟若偶然出现不同步,则正确的信息可能会被误判为重放信息而丢弃,而错误的重放信息可能会当作最新信息而接收)
序号
通信双方通过消息中的序列号来判断消息的新鲜性
要求通信双方必须事先协商一个初始序列号,并协商递增方法
提问与应答
“现时”──与当前事件有关的一次性随机数N(互不重复即可)
基本做法──期望从B获得消息的A 事先发给B一个现时N,并要求B应答的消息中包含N或f(N),f是A、B预先约定的简单函数
原理──A通过B回复的N或f(N)与自己发出是否一致来判定本次消息是不是重放的
时钟要求──无
适用性──用于连接性的对话
重放攻击是对协议的攻击中危害最大、最常见的一种攻击形式。
4会话劫持编辑
会话劫持原理
并且还可以把会话劫持攻击分为两种形式:1、被动劫持,2、主动劫持;被动劫持实际上就是在后台监视双方会话的数据流,从中获得敏感数据;而主动劫持则是将会话当中的某一台主机"踢"下线,然后由攻击者取代并接管会话。
TCP会话劫持
如果劫持一些不可靠的协议,那将轻而易举,因为它们没有提供一些认证措施;而TCP协议被誉为是可靠的
传输协议,所以要重点讨论它。
根据
TCP/IP中的规定,使用TCP协议进行通讯需要提供两段序列号,TCP协议使用这两段序列号确保连接同步以及安全通讯,系统的TCP/IP协议栈依据时间或线性的产生这些值。在通讯过程中,双方的序列号是相互依赖的,这也就是为什么称TCP协议是可靠的传输协议(具体可参见RFC 793)。如果攻击者在这个时候进行会话劫持,结果肯定是失败,因为会话双方"不认识"攻击者,攻击者不能提供合法的序列号;所以,会话劫持的关键是预测正确的序列号,攻击者可以采取
嗅探技术获得这些信息。
TCP协议的序列号
来讨论一下有关TCP协议的序列号的相关问题。在每一个
数据包中,都有两段序列号,它们分别为:
ACK:期望收到对方数据包中第一个字节的序号
假设双方需要进行一次连接:
S_SEQ:将要发送的下一个字节的序号
S_ACK:将要接收的下一个字节的序号
S_WIND:接收窗口
//以上为服务器(Server)
C_SEQ:将要发送的下一个字节的序号
C_ACK:将要接收的下一个字节的序号
C_WIND:接收窗口
//以上为客户端(Client)
它们之间必须符合下面的逻辑关系,否则该数据包会被丢弃,并且返回一个ACK包(包含期望的序列号)。
S_ACK <= S_SEQ <= S_ACK + S_WIND
如果不符合上边的逻辑关系,就会引申出一个"致命弱点"。
这个致命的弱点就是ACK风暴(Storm)。当会话双方接收到一个不期望的数据包后,就会用自己期望的序列号返回ACK包;而在另一端,这个数据包也不是所期望的,就会再次以自己期望的序列号返回ACK包……于是,就这样来回往返,形成了恶性循环,最终导致ACK风暴。比较好的解决办法是先进行ARP欺骗,使双方的数据包"正常"的发送到攻击者这里,然后设置包转发,最后就可以进行会话劫持了,而且不必担心会有ACK风暴出现。当然,并不是所有系统都会出现ACK风暴。比如Linux系统的TCP/IP协议栈就与RFC中的描述略有不同。注意,ACK风暴仅存在于注射式会话劫持。
TCP会话劫持过程
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欺骗或者其他方式),就可以成功进行会话劫持了。
HTTP会话劫持
Web应用程序是通过2种方式来判断和跟踪不同用户的:Cookie或者
Session(也叫做会话型Cookie)。其中Cookie是存储在本地计算机上的,过期时间很长,所以针对Cookie的攻击手段一般是盗取用户Cookie然后伪造Cookie冒充该用户;而Session由于其存在于
服务端,随着会话的注销而失效(很快过期),往往难于利用。所以一般来说Session认证较之Cookie认证安全。
会话型cookie也是可以通过程序获得的,换句话说我们进行TCP会话劫持的时候如果针对http会话劫持的话可以截获所有http内容包括Session信息。
http://wenku.baidu.com/link?url=6S-V65noXDJe2r-2yuUtafApJCbQCXNxWB7OPewiV08TTbVb2RS49Lafd60-EwSXH-rYnOm6I9Q1Ns4AEmubiD2gjVkfeHMpJ3ZIP-2YN4e