libnet使用举例(5)

libnet使用举例(5)    2000-01-01     scz        技术文档             这次以ICMP重定向报文的DoS为例继续介绍libnet库编程。ICMP重定向攻击很久了， 长期不看又会对某些技术细节有所忽略，回顾一下。 -------------------------------------------------------------------------- 缺省路由向发送者报告另一条到特定主机的更短路由，就是ICMP重定向。最初，网络 路由重定向是被支持的，然而后来网络路由重定向遭到异议而废弃。除了路由器，主 机必须服从ICMP重定向。 下文引自W.Richard Stevens TCP/IP Illustrated, Volume I page 123: 一台4.x BSD主机接收到ICMP重定向报文，为了防止失常的路由、主机或者恶意的入 侵者不正确地修改系统路由表，做了如下检查： 1. 新路由必须是直达的 所谓直达，就是本机到该路由无须经过其他路由，直接利用ARP寻址，利用MAC地 址投递报文。 2. 重定向包必须来自去往目标的当前路由 比如，A欲去往Z，A和Z不在一个子网内，主机A当前选路规则下所经过的的第一个 路由是G，但G认为H比自己更优化，于是告诉A更改当前选路规则使得到Z时优先使 用H。这个重定向报文必须来自G，而不是其他主机或路由。 A目前的路由表里可能有F、G两条路由，都可以经其到达Z，但是G比F优先，那么 A目前只能接受来自G的重定向报文，来自F的重定向报文被认为无效而丢弃。后面 实验中的很多现象都与这条规则相关，必须加强理解。 3. 重定向包不能通知主机用自己做路由 虽然这是合理要求，但Pwin98允许通知主机用自己做路由，实际上就造成了DoS。 其他系统尚未测试过。 4. 被改变的路由必须是一条间接路由 所谓间接路由就是我们平时所理解的路由，那么什么是直接路由呢，利用MAC地址 进行报文投递而已，同一子网，明白了？因此若A和B在同一子网，A不可能利用 ICMP重定向使B发往子网内IP的包流向自己，但可以使B发往子网外IP的包流向自 己。 ICMP重定向提供了一种相当有效的DoS。不象ARP入口，这些特定主机路由入口永不过 期(就和你用route add命令手工增加路由一个道理，如果没有刷新出现，不存在过期 问题)。注意，攻击没有要求必须从局域网内发起，事实可以从广域网上发起。如果 子网所用DNS位于网关外，产生一个到该DNS的错误路由是很容易的，于是...... 我在Pwin98下测试过，由ICMP重定向包产生的路由都是掩码为255.255.255.255的特 定主机路由，没有办法产生诸如255.255.0.0这样掩码下的网络路由。此外，不知道 是不是系统实现有差别，反正Pwin98下，通过ICMP增加上来的特定主机路由会过期， 什么情况下过期，据观察似乎长期不使用就过期，route add增加的不会过期。通过 ICMP增加的指向自身的病态路由即使过期也会保留残像，非病态路由从路由表中彻底 消失。 许多桌面操作系统线性搜索自己的路由表，如果你利用ICMP重定向包加了太多特定主 机路由到它们的路由表中，嘿嘿。对于Unix系统，虽然搜索路由表时不是线性搜索， 但过多的特定主机路由会消耗大量的内存空间。这些都属于DoS攻击范畴。 现代操作系统或多或少提供了屏蔽ICMP重定向包的机会，具体如何实现我现在也很乱。 -------------------------------------------------------------------------- 这是我在华为的时候写的，有些东西已经不大记得，一些实验数据丢弃了，重新测试。 此次我们不考虑利用ICMP重定向进行监听，仅仅考虑DoS攻击。 伪造一个来自192.168.0.1的ICMP重定向包，从MAC层开始伪造。 1) 利用05 01重定向报文(针对特定主机)依旧可以修改2K的路由表！但是无法使2K的 特定主机路由指向自己(而Pwin98可以)，2K在这点上改进得不错。被重定向过的 特定主机路由长时间不消失，可以手工route delete掉。如果已经重定向到某个 IP，再发重定向包企图指向其他IP失败。 其实最后一条实验结果的本意可能不是你理解的那样，注意到前面我们提到过， 重定向包必须来自去往目标的当前路由，否则重定向报文会被认为非法而丢弃。 这才是真正原因。我们无法利用ICMP重定向报文产生两条特定主机路由，因为第 二次将是修改特定主机路由，而非增加特定主机路由。98下route add可以手工增 加两条特定主机路由，但实际上只有一条生效，否则选路规则相当胡乱，个人认 为这是route add命令本身实现上的缺陷。如果已经重定向到某个IP，需要重新构 造一个重定向报文使得其源IP是上次指定的路由IP，这样的报文才会生效。 2K下可以用route add增加一条路由，使之指向自身，这和重定向包不能通知主机 用自己做路由不矛盾。此时增加的路由可以被route delete删除。 2) Pwin98下，可以使特定主机路由指向自己。被重定向过的特定主机路由长时间不 消失，删除时分两种情况，如果该特定主机路由不是指向自己，可以手工 route delete掉，如果指向自己，route delete的时候会报告找不到该路由， route change时同样报告找不到该路由，netstat -nr却还能看到该路由， route -f参数不能删除该路由，注销重登录也不能删除该路由，想其他办法刷新 路由表吧，没有继续测试如何删除该病态路由。 98下可以用route add增加一条路由，使之指向自身，此路由可以被route delete 删除。但是，重定向包导致指向自身的病态路由就无法用route delete删除。98 对route命令的实现相当混乱，比如可以 route add 202.99.11.161 mask 255.255.255.255 192.168.10.3 route add 202.99.11.161 mask 255.255.255.255 192.168.10.4 route add 202.99.11.161 mask 255.255.255.255 192.168.10.5 此时用netstat -nr查看会同时看到三条特定主机路由和一条缺省路由，但 telnet 202.99.11.161 80的时候使用的仅仅是192.168.10.3，并不在失败后尝试 10.4、10.5以及缺省路由，这使得DoS攻击成立。 route change 202.99.11.161 mask 255.255.255.255 192.168.0.1 修改的是10.5对应的那条路由，telnet 202.99.11.161 80同样会失败，理由同上。 route delete 202.99.11.161后会同时删除这三条特定主机路由，此结论对ICMP 重定向导致指向自身的病态路由无效。 通过ICMP增加的非病态路由与route add增加的路由效果一致。如果先被人用ICMP 在缺省路由基础上增加过一条特定主机路由192.168.10.3，然后自己route add了 另外一条特定主机路由192.168.0.1，此时使用的还是第一条特定主机路由 192.168.10.3。再次伪造ICMP重定向包，源IP为192.168.10.3，目标IP为 192.168.10.60，可以继续"修改"后者路由表里的特定主机路由，不再是"增加"特 定主机路由。 对于前述病态路由，无法删除的情况下，依旧可以route add 202.99.11.161增加 另外一条特定主机路由，route delete可以删除后续增加的这条路由，病态路由 依旧。指向自身的病态路由增加上来，初期对IP寻径造成很坏的影响，我不确定 这个影响会持续到什么时候，何时过期等等。似乎通过手工route add一条特定主 机路由会"加快"病态路由影响的消失。该影响"彻底"消失后，route delete掉手 工增加的特定主机路由，继续使用缺省路由。但是用netstat -nr还是看到病态路 由，尽管这个时候没有影响了，faint。这种情况下，除了残像，其他都恢复到没 有残像的状态，可以伪造一个源IP为缺省路由IP的重定向包重新替192.168.10.60 增加特定主机路由。 测试中还确认，目标MAC不能是0xffffffffffff，目标IP不能是定向广播地址，源 MAC不被检查(任意)。 假如异己主机发送了一个ARP请求包或者响应包，包中源IP地址等于自己的IP地址， 那么两台之中必有一台错误配置了IP地址。Net/3侦测到这个错误并向管理员报告。 注意，只有ARP报文(无论是请求还是响应)才会更新ARP Cache，才有可能引发ARP 冲突等等，所以在伪造ICMP包时无须过多顾虑源MAC。IP报文本身永远都不会造成 事实上的ARP欺骗、冲突、刷新效果。 ARP Cache总会过期，不会因为总在使用Arp Entry而不过期。可以这样验证，在 98下pint -t，然后用NetXray设置过滤规则抓取ARP请求报文，总是在固定间隔上 看到本机发出的ARP请求报文。ICMP增加上来的路由过期时限很长，比ARP欺骗危 害大。 3) 下面是一个演示报文，伪造成从网关192.168.0.1发往192.168.10.60的ICMP重定 向报文，使得后者产生一条到202.99.11.161的特定主机路由192.168.8.90。 00 10 FF 69 FF FF 00 50 04 BF 07 34 08 00 45 00  00 3C 5B 6E 00 00 80 01 53 C5 C0 A8 00 01 C0 A8  0A 3C 05 01 AF 8A C0 A8 08 5A 45 00 63 64 65 66  00 68 FF 01 51 E1 C0 A8 0A 3C CA 63 0B A1 75 76  77 61 62 63 64 65 66 67 68 69 把上述报文存入 redir1060.txt 文件中，以 root 身份执行如下命令： ./linuxkiller -k redir1060.txt -w 5 -r 1000 测试过程中看到，如果在192.168.10.60上route delete 0.0.0.0、 route delete 202.99.11.161，则不受ICMP重定向包的影响，这个结论很正常， 前面我们提到过，重定向包必须来自去往目标的当前路由，如果根本就没有合适 的当前路由，重定向报文会被认为非法而丢弃。 4) 如果是98，可以用如下注册表设置打开路由功能，98单网卡就可以提供路由功能： REGEDIT4 [HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/VxD/MSTCP] "EnableRouting"="1" 5) 由于再三提及的原因，无法利用ICMP重定向报文凭空产生特定主机路由。同时被 更改的特定主机路由本身也会被ICMP重定向报文更改。启动98路由功能后， 192.168.8.90会向192.168.10.60发送ICMP重定向报文，修正后者直接使用 192.168.0.1。注意，掩码规则优先于特定主机路由。 必须明确理解路由优先级的概念。如果只有缺省路由，ICMP会导致增加特定主机 路由。如果已经存在特定主机路由，无论它是如何产生的，仅仅会被ICMP修改， 而不是增加。 6) 目前的测试环境使用的是交换式HUB，拓扑结构大致如下： -------------------------------------- <-- Smart Hub Or Switch | | | 192.168.10.60 192.168.8.90 ...... 192.168.0.1 (sygate) <--> Internet 255.255.0.0 255.255.0.0 255.255.0.0 下面观察这样做了之后发生什么事情。从192.168.10.60上 telnet 202.99.11.161 80，此时192.168.8.90转发了这个报文，转发过程中修改 源MAC地址成000000111111(192.168.8.90的MAC地址)，源IP保持192.168.10.60。 192.168.8.90在转发第一个发起TCP连接的SYN报文的同时会向192.168.10.60发送 ICMP重定向报文(掩码规则下192.168.0.1更优化)，使得特定主机路由成为 192.168.0.1。于是后续的192.168.10.60到202.99.11.161的报文都直接经过 192.168.0.1，但是回来的报文始终是经过192.168.8.90的。这个现象很有意思。 在192.168.8.90和192.168.10.60上抓包观察到的现象始终都是出报文直接经 192.168.0.1，入报文经192.168.8.90转发而至。袁哥和ipxodi认为是sygate本身 实现的问题，比如sygate没有使用标准ARP Cache，自己保留了MAC-IP对之类的信 息提高效率；换成正规路由器，应该不是这种现象。现在很多单位局域网的拓扑 类似，估计sygate、wingate等支持透明代理功能的软件都存在这样的问题，说不 上是漏洞还是被非法利用，总之应该意识到该问题的存在，反正以前我是没有料 到这个现象的存在。 我和ipxodi刚开始讨论这个问题的时候认为只能抓到出报文(特定主机路由)，而 入报文因为掩码规则直接投递了。没料到实际测试中，192.168.8.90本身会发送 ICMP重定向报文。可以想个办法让192.168.8.90的ICMP重定向报文不能发送出去， 比如个人防火墙、象袁哥那样修改VxD等等。 先不考虑个人防火墙的介入，在我们这种拓扑下，ICMP重定向带来的入报文经 192.168.8.90的问题很严重。想想看，192.168.10.60上很快就恢复了正常的路由 规则，ARP Cache与这个问题无关，也不表现什么异常，唯一算得上异常的是 192.168.10.60的路由表中虽然已经有缺省路由192.168.0.1，但还是出现了特定 主机路由192.168.0.1。没看过这篇文章的朋友，有几个会想到可能是出事了呢？ 由于入报文经过192.168.8.90，在这里起一个NetXray，不用写ARP欺骗程序、 "合法"利用ICMP重定向功能和98的IP路由功能，异常现象最小化等等。这里无法 抓取出报文，于是无法监听到诸如telnet口令之类服务方不回显的数据，参看后 面的讨论。上述描述适合于交换机情形，如果你对子网内每个IP用程序发送ICMP 重定向报文，并开启本机路由功能，要比ARP欺骗容易实现得多，也持久得多。考 虑DNS服务器位于子网外的拓扑，至少可以看到谁企图解析什么域名，算不算侵犯 隐私呢，sigh。强烈反对监听，可为什么总在给别人提供监听的可能，也许又是 一次矛盾选择吧。 像ARP欺骗，一是容易暴露，二是需要高频率刷新，三是一般需要编程实现。而 ICMP重定向不容易暴露(考虑sygate的"特性")，不需要高频率刷新，如果经常使 用根本就不需二次刷新，用NetXray发送一次重定向报文即可。无论如何，ICMP重 定向报文是潜在的安全隐患，现在倾向于不使用它。IDS系统应该高度敏感ICMP重 定向报文的出现，在局域网内存在支持IP转发功能主机的情况下，可能会出现非 攻击性的ICMP重定向报文，不能一味告警，需要区分。 7) 在介入个人防火墙的情况下，192.168.10.60和202.99.11.161之间就完全经过 192.168.8.90通信，无论出入报文。需要注意，98不适合做路由功能，效率很低、 负载很高，再启动一个NetXray的话更要命，尤其我这次测试时98使用的是单网卡。 上述技术仅仅限于理论研究以及纯DoS攻击，真正要做监听不实际。还有，此时 192.168.10.60上特定主机路由192.168.8.90显得很刺眼，容易暴露。 NetXray和ConSeal PC FIREWALL的启动顺序必须留心，建议如果要做协议分析， 无论如何都先启动NetXray，尤其当出现异常现象的时候关闭二者，按照建议顺序 重启动。 8) 迄今为止，都是用微软操作系统测试，并没有测试Linux/Solaris/FreeBSD，这些 系统的测试留待我写个libnet程序来完成，总是手工构造ICMP重定向报文太累了。 微软操作系统在没有个人防火墙介入的情况下如何屏蔽ICMP重定向报文，尚不清 楚，谁知道了就贴一下(注册表？)。 9) 因为前面测试是手工构造完整物理帧，所以才涉及到MAC地址，事实上ICMP重定向 报文与MAC地址无关，与源IP有关，但raw_socket上可以伪造任意源IP，至于数据 区就不在话下了。什么意思？ICMP重定向攻击可以跨路由进行，在广域网上进行。 局域网内攻击不但可以DoS还可以sniffer，广域网上就只能DoS了(想想为什么)。 还好，我这次被人抓住写的也就是DoS工具，不想那么多啦。 既然是DoS，最终目的是不让目标活得舒坦。象98，就可以设置指向自身的病态路 由，其他系统，至少可以设置一个不存在的间接路由。通过大量增加垃圾特定主 机路由消耗内存空间、延长路由搜索时间。某些实现不好的操作系统，还可能被 某些特殊重定向报文冻僵住。这些都会在我写完libnet测试程序之后验证一二。 曾经很喜欢的一句话，"死神之花已然开放"，现在淡了，喜欢"人不与天争"。 <待续>