荔园在线

荔园之美,在春之萌芽,在夏之绽放,在秋之收获,在冬之沉淀

[回到开始] [上一篇][下一篇]


发信人: haoa (好啊嘿), 信区: Security
标  题: IP欺骗与盗用原理
发信站: 荔园晨风BBS站 (Sun Oct 26 11:17:37 2003), 站内信件

IP欺骗的技术比较复杂,不是简单地照猫画老虎就能掌握,

但作为常规攻击手段,有必要理解其原理,至少有利于自

己的安全防范,易守难攻嘛。

  假设B上的客户运行rlogin与A上的rlogind通信:

1. B发送带有SYN标志的数据段通知A需要建立TCP连接。

并将TCP报头中的sequence number设置成自己本次连接的

初始值ISN。

2. A回传给B一个带有SYS+ACK标志的数据段,告之自己的ISN,

并确认B发送来的第一个数据段,将acknowledge number设置

成B的ISN+1。

3. B确认收到的A的数据段,将acknowledge number设置成A的ISN+1。

B ---- SYN ----> A

B <---- SYN+ACK ---- A

B ---- ACK ----> A

  TCP使用的sequence number是一个32位的计数器,

从0-4294967295。 TCP为每一个连接选择一个初始序号ISN,

为了防止因为延迟、重传等扰乱三次握手,ISN不能随便选取,

不同系统有不同算法。理解TCP如何分配ISN以及ISN随时间变

化的规律,对于成功地进行IP欺骗攻击很重要。

  基于远程过程调用RPC的命令,比如rlogin、rcp、rsh等等,

根据/etc/hosts.equiv以及$HOME/.rhosts文件进行安全校验,

其实质是仅仅根据信源IP地址进行用户身份确认,以便允许或

拒绝用户RPC。

  IP欺骗攻击的描述:

1. 假设Z企图攻击A,而A信任B,所谓信任指/etc/hosts.equiv

和$HOME/.rhosts中有相关设置。注意,如何才能知道A信任B呢?

没有什么确切的办法。我的建议就是平时注意搜集蛛丝马迹

,厚积薄发。一次成功的攻击其实主要不是因为技术上的高明,

而是因为信息搜集的广泛翔实。动用了自以为很有成就感的技术,

却不比人家酒桌上的巧妙提问,攻击只以成功为终极目标,不在乎手段。

2. 假设Z已经知道了被信任的B,应该想办法使B的网络功能暂时瘫

痪,以免对攻击造成干扰。著名的SYN flood常常是一次IP欺骗攻击

的前奏。请看一个并发服务器的框架:

int initsockid, newsockid;

if ((initsockid = socket(...)) < 0) {

error("can't create socket");

}

if (bind(initsockid, ...) < 0) {

error("bind error");

}

if (listen(initsockid, 5) < 0) {

error("listen error");

}

for (;{

newsockid = accept(initsockid, ...); /* 阻塞 */

if (newsockid < 0) {

error("accept error");

}

if (fork() == 0) { /* 子进程 */

close(initsockid);

do(newsockid); /* 处理客户方请求 */

exit(0);

}

close(newsockid);

}

listen函数中第二个参数是5,意思是在initsockid上允许的最大连

接请求数目。如果某个时刻initsockid上的连接请求数目已经达到5,

后续到达initsockid的连接请求将被TCP丢弃。注意一旦连接通过三

次握手建立完成,accept调用已经处理这个连接,则TCP连接请求队列空出

一个位置。所以这个5不是指initsockid上只能接受5个连接请求。

SYN flood正是一种 Denial of Service,导致B的网络功能暂时中断

Z向B发送多个带有SYN标志的数据段请求连接,注意将信源IP 地址换

成一个不存在的主机X;B向子虚乌有的X发送SYN+ACK数据段,但没有

任何来自X的ACK出现。B的IP层会报告B的TCP层,X不可达,但B的TCP

层对此不予理睬,认为只是暂时的。于是B在这个initsockid上再也不能接

收正常的连接请求。

Z(X) ---- SYN ----> B

Z(X) ---- SYN ----> B

Z(X) ---- SYN ----> B

Z(X) ---- SYN ----> B

Z(X) ---- SYN ----> B

......

X <---- SYN+ACK ---- B

X <---- SYN+ACK ---- B

X <---- SYN+ACK ---- B

X <---- SYN+ACK ---- B

X <---- SYN+ACK ---- B

......

我认为这样就使得B网络功能暂时瘫痪,可我总觉得好象不对头。

  因为B虽然在initsockid上无法接收TCP连接请求,但可以在another

initsockid上接收,这种SYN flood应该只对特定的服务(端口),不应该

影响到全局。当然如果不断地发送连接请求,就和用ping发洪水包一

个道理,使得B的TCP/IP忙于处理负载增大。至于SYN flood,回头有机

会我单独灌一瓢有关DoS的。如何使B的网络功能暂 碧被居 很多办法,

根据具体情况而定,不再赘述。

3. Z必须确定A当前的ISN。首先连向25端口(SMTP是没有安全校验机制的),

与1中类似,不过这次需要记录A的ISN,以及Z到A的大致的RTT(round trip

time)。这个步骤要重复多次以便求出RTT的平均值。现在Z知道了A的ISN基

值和增加规律(比如每秒增 加128000,每次连接增加64000),也知道了从Z到

A需要RTT/2 的时间。必须立即进入攻击,否则在这之间有其他主机与

A连接, ISN将比预料的多出64000。

4. Z向A发送带有SYN标志的数据段请求连接,只是信源IP改成了B,注意

是针对TCP513端口(rlogin)。A向B回送SYN+ACK数据段,B已经无法响应,

B的TCP层只是简单地丢弃A的回送数据段。

5. Z暂停一小会儿,让A有足够时间发送SYN+ACK,因为Z看不到这个包。

然后Z再次伪装成B向A发送ACK,此时发送的数据段带有Z预测的A的ISN+1。

如果预测准确,连接建立,数据传送开始。问题在于即使连接建立,A仍然会

向B发送数据,而不是Z,Z 仍然无法看到A发往B的数据段,Z必须蒙着头

按照rlogin协议标准假冒B向A发送类似 "cat + + >> ~/.rhosts" 这样的命令

,于是攻击完成。如果预测不准确,A将发送一个带有RST标志的数据段异常

终止连接,Z只有从头再来。

Z(B) ---- SYN ----> A

B <---- SYN+ACK ---- A

Z(B) ---- ACK ----> A

Z(B) ---- PSH ----> A

......

6. IP欺骗攻击利用了RPC服务器仅仅依赖于信源IP地址进行安全校验的特性,

建议阅读rlogind的源代码。攻击最困难的地方在于预测A的ISN。我认为攻击

难度虽然大,但成功的可能性也很大,不是很理解,似乎有点矛盾。考虑这种情况



入侵者控制了一台由A到B之间的路由器,假设Z就是这台路由器,那么A回送

到B的数据段,现在Z是可以看到的,显然攻击难度骤然下降了许多。否则Z必须

精确地预见可能从A发往B的信息,以及A期待来自B的什么应答信息,这要求攻

击者对协议本身相当熟悉。同时需要明白,这种攻击根本不可能在交互状态下完成



,必须写程序完成。当然在准备阶段可以用netxray之类的工具进行协议分析。

7. 如果Z不是路由器,能否考虑组合使用ICMP重定向以及ARP欺骗等技术?没有

仔细分析过,只是随便猜测而已。并且与A、B、Z之间具体的网络拓扑有密切关系



在某些情况下显然大幅度降低了攻击难度。注意IP欺骗攻击理论上是从广域网

上发起的,不局限于局域网,这也正是这种攻击的魅力所在。利用IP欺骗攻击得


到一个A上的shell,对于许多高级入侵者,得到目标主机的shell,离root权限

就不远了,最容易想到的当然是接下来进行buffer overflow攻击。

8. 也许有人要问,为什么Z不能直接把自己的IP设置成B的?这个问

题很不好回答,要具体分析网络拓扑,当然也存在ARP冲突、出不了网关等问题。



那么在IP欺骗攻击过程中是否存在ARP冲突问题。回想我前面贴过的ARP欺骗攻击


,如果B的ARP Cache没有受到影响,就不会出现ARP冲突。如果Z向A发送数据段时



企图解析A的MAC地址或者路由器的MAC地址,必然会发送ARP请求包,但这个ARP请



求包中源IP以及源MAC都是Z的,自然不会引起ARP冲突。而ARP Cache只会被ARP

包改变,不受IP包的影响,所以可以肯定地说,IP欺骗攻击过程中不存在ARP冲突



相反,如果Z修改了自己的IP,这种ARP冲突就有可能出现,示具体情况而言。攻击



中连带B一起攻击了,其目的无非是防止B干扰了攻击过程, 如果B本身已经down掉



那是再好不过。

9. fakeip曾经沸沸扬扬了一下,我对之进行端口扫描,发现其tcp端口113是接收



连接的。和IP欺骗等没有直接联系,和安全校验是有关系的。当然,这个东西并不



如其名所暗示,对IP层没有任何动作。

10. 关于预测ISN,我想到另一个问题。就是如何以第三方身份切断 A与B之间的


TCP连接,实际上也是预测sequence number的问题。尝试过,也很困难。如果Z是



A与B之间的路由器,就不用说了; 或者Z动用了别的技术可以监听到A与B之间

的通信,也容易些; 否则预测太难。作者在3中提到连接A的25端口,可我想

不明白的 是513端口的ISN和25端口有什么关系?看来需要看看TCP/IP内部实现的

源代码



未雨绸缪

虽然IP欺骗攻击有着相当难度,但我们应该清醒地意识到,这种攻击非常广泛,入



往往由这里开始。预防这种攻击还是比较容易的, 比如删除所有的/etc/hosts.
equiv、



$HOME/.rhosts文件,修改/etc/ inetd.conf文件,使得RPC机制无法运做,还可以



掉portmapper等等。设置路由器,过滤来自外部而信源地址却是内部IP的报文。


cisio公司的产品就有这种功能。不过路由器只防得了外部入侵,内部入侵呢?

TCP的ISN选择不是随机的,增加也不是随机的,这使攻击者有规可循,可以

修改与ISN相关的代码,选择好的算法,使得攻击者难以找到规律。估

计Linux下容易做到,那solaris、irix、hp-unix还有aix呢?sigh

虽然写的不怎么,但总算让大家了解了一下IP欺骗攻击,我实验过预

测sequence number,不是ISN,企图切断一个TCP连接,感觉难度很大。

作者建议要找到规律,不要盲目预测,这需要时间和耐心。现在越发明

白什么是那种锲而不舍永远追求的精神,我们所向往的传奇故事背后

测sequence number,不是ISN,企图切断一个TCP连接,感觉难度很大。

作者建议要找到规律,不要盲目预测,这需要时间和耐心。现在越发明

白什么是那种锲而不舍永远追求的精神,我们所向往的传奇故事背后

有着如此沉默的艰辛和毅力,但愿我们学会的是这个,而不是浮华与喧嚣。

一个现成的bug足以让你取得root权限,可你在做什么,你是否明白?我们太

肤浅了......

--
※ 来源:·荔园晨风BBS站 bbs.szu.edu.cn·[FROM: 192.168.44.227]


[回到开始] [上一篇][下一篇]

荔园在线首页 友情链接:深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店