广告广告
  加入我的最爱 设为首页 风格修改
首页 首尾
 手机版   订阅   地图  繁体 
您是第 22222 个阅读者
 
发表文章 发表投票 回覆文章
  可列印版   加为IE收藏   收藏主题   上一主题 | 下一主题   
upside 手机 葫芦墩家族
个人头像
个人文章 个人相簿 个人日记 个人地图
特殊贡献奖 社区建设奖 优秀管理员勋章
头衔:反病毒 反诈骗 反虐犬   反病毒 反诈骗 反虐犬  
版主
分享: 转寄此文章 Facebook Plurk Twitter 复制连结到剪贴簿 转换为繁体 转换为简体 载入图片
推文 x1
[资讯教学] 关于netcut v2的二三事
关于netcut v2的二三事

转 微风
http://bbs.wefong.com/viewthread.php?tid=1713548&p...a=page%3D1#pid23035628

首先,莱因哈特必须先作两点声明,本文内容涉及ARP通讯协定运作原理,倘若您看不懂本文,请先自我充实。其次,本文内容无涉如何反制netcut,有心者请止步。谢谢!


一‧前言

本测试的目的在于观察netcut v2的运作模式,藉此了解是否在个人电脑上单靠个人防火墙,或是利用arp –s指令锁住重要的ARP table特定项目内容,即可获得免疫的效果。


二‧测试环境

攻击端:Microsoft Windows 2003 SP2主机,在个人防火墙部分,仅启动系统内建防火墙功能。

被攻击端1Microsoft Windows 2000 SP4主机,无个人防火墙保护。本机功用在于观察netcut的行为模式。

被攻击端2Microsoft Windows XP SP2工作站,个人防火墙采用COMODO Firewall Pro v3.0.14.276。本机功用在于测试个人防火墙能否阻挡netcut攻击,并作为测试netcut自我防护功能时的攻击端。

攻击软件:netcut v2.08

监听侧录软体:Sniffer Portable v4.90.104(MR4)

本测试之基本架构如下图所示,只是在单纯的区域网路上,利用一台Windows 2003主机及一台Windows XP SP2工作站充当攻击端及被攻击端,基于测试及侧录netcut封包的目的,莱因哈特在攻击端及被攻击端都安装上netcutSniffer Portable程式。



《图一》本测试之架构示意图


三‧测试重点

本测试的观察重点如下:

1.
观察netcut的网路行为模式

2.
观察COMODO对于netcut攻击的防御效果

3.
观察arp –s指令对于netcut攻击的防御效果

4. 观察netcut本身对于同类攻击的防护效果


四‧测试结果

1. 关于netcut的网路行为模式

首先说明测试的网路环境,攻击端的IP位址是192.168.1.240,被攻击端的IP位址为192.168.1.200,至于闸道器的IP位址在192.168.1.254 / 10.1.1.254(因为本身区网分成192.168.1.010.1.1.0个网段,但闸道皆设在同一台路由器上,因此会有两个闸道器位址)

攻击方法是在攻击端的netcut主画面中,先选择192.168.1.200为攻击对象,然后点选上方的切断按钮进行攻击。


《图二》在netcut主画面选择对象再点选切断按钮即可发动攻击

同时间,莱因哈特利用Sniffer Portablecapture功能在攻击端撷取所有进出封包进行分析,以下即是所探知的netcut攻击行为模式:

a. 假造一组实体位址(MAC Address / Physical Address),然后以此位址作为被攻击端(192.168.1.200)的实体位址,发送一个伪装的非典型ARP request封包给第一个闸道器(192.168.1.254)。此行为的目的在于欺骗闸道器,使闸道器误以为真,将本机ARP table上正确的对映位址换成错误的对映位址,如此当有封包要传送给被攻击端时,都会被送往错误的实体位址去,导致被攻击端不能再收到任何从闸道器送来的封包,直到切断状态解除,且ARP table上的对应资料恢复正常为止。


《图三》伪装成被攻击端(192.168.1.200)向第一个闸道器(192.168.1.254)发送的非典型ARP request封包内容,请注意被Sender’s hardware address是假造的位址

请注意,典型ARP request封包的目的应该是广播(Broadcast)位址,也就是FF:FF:FF:FF:FF:FF,并非单一主机的实体位址。下图是正常ARP request的封包截图,请自行对照与上图的封包目的位址有何不同。


《图四》这是典型ARP request封包的内容,请特别注意目的位址(Dest Address / Destination)栏显示的是广播位址,不是单一实体位址

b. 利用该假造位址作为第一个闸道器(192.168.1.254)的实体位址,同样发送一个伪装的非典型ARP request封包给被攻击端(192.168.1.200)。此行为的目的在于欺骗被攻击端,使被攻击端信以为真,将本机ARP table上正确的对映位址换成错误的对映位址,如此当有封包要传送给闸道器时,都会被送往错误的实体位址去,导致闸道器不能再收到任何从被攻击端送来的封包,直到切断状态解除,且ARP table上的对应资料恢复正常为止。


《图五》伪装成第一个闸道器(192.168.1.254)向被攻击端(192.168.1.200)发送的非典型ARP request封包内容,请注意Sender’s hardware address是假造的位址

由于在本测试环境中有两个网段,netcut会依样画葫芦用相同的假位址为被攻击端(192.168.1.200)的实体位址,发送一个伪装的非典型ARP request封包欺骗第二个闸道器(10.1.1.254),使被攻击端不能再收到从第二个闸道器传来的封包,直到切断状态解除,且ARP table上的对应资料恢复正常为止。注意,若是仅有单一网段,则不会出现第三及第四个伪造的ARP request封包。


《图六》伪装成被攻击端(192.168.1.200)向第二个闸道器(10.1.1.254)发送的非典型ARP request封包内容,请注意Sender’s hardware address是假造的位址

再一次利用相同手法,伪装成第二个闸道器(10.1.1.254),发送一个非典型ARP request封包给被攻击端(192.168.1.200),使第二个闸道器不能再收到从被攻击端传来的封包,直到切断状态解除,且ARP table上的对应资料恢复正常为止。


《图七》伪装成第二个闸道器(10.1.1.254)向被攻击端(192.168.1.200)发送的非典型ARP request封包内容,请注意Sender’s hardware address是假造的位址

当被欺骗端收到传来的ARP request封包后,会按照ARP通讯协定的运作原理,将自身的实体位址填入封包,并回传给发送ARP request封包的主机,这种封包称为ARP reply。由于上述的ARP request并非由表头记载的发送端所发送,而且发送端实体位址也是假造的,因此这些ARP reply封包并不会真的传送到另一方手里,而是回到netcut攻击主机手上。以下四个封包都是被欺骗端回传的ARP reply封包,请恕莱因哈特不再赘言。

这是被攻击端(192.168.1.200)回传给第一个闸道器(192.168.1.254)ARP reply封包。


《图八》被攻击端(192.168.1.200)回传给第一个闸道器(192.168.1.254)ARP reply封包,请注意Target hardware address是假造的位址,代表被攻击端的ARP table内容已经被篡改

接着是第一个闸道器(192.168.1.254)回传给被攻击端(192.168.1.200)ARP reply封包。


《图九》第一个闸道器(192.168.1.254)回传给被攻击端(192.168.1.200)ARP reply封包,请注意Target hardware address是假造的位址,代表第一个闸道器的ARP table内容已经被篡改

再来是被攻击端(192.168.1.200)回传给第二个闸道器(10.1.1.254)ARP reply封包。注意,若是仅有单一网段,则不会出现第三及第四个ARP reply封包。


《图十》被攻击端(192.168.1.200)回传给第二个闸道器(10.1.1.254)ARP reply封包,请注意Target hardware address是假造的位址,代表被攻击端的ARP table内容已经被篡改

最后是第二个闸道器(10.1.1.254)回传给被攻击端(192.168.1.200)ARP reply封包。


《图十一》第二个闸道器(10.1.1.254)回传给被攻击端(192.168.1.200)ARP reply封包,请注意Target hardware address是假造的位址,代表被攻击端的ARP table内容已经被篡改

因此,netcut的攻击手法就是交互发送伪造的非典型ARP request封包到被攻击端与闸道器,使两者的ARP table记录下错误位址而达成截断两者间封包传送的目的,而且莱因哈特发现,netcut会持续变造实体位址,并且不断发送伪造的ARP request封包,直到netcut使用者下达恢复连线的指令为止。根据相关封包的Relative Time显示,其变造实体位址并发送伪造ARP request封包的频率接近每秒一次。


《图十二》netcut所发送的伪造ARP request封包一览,请特别注意Source Address所显示的位址有何规律性

netcut频繁更换实体位址的原因何在?个人猜测可能是为了避免网管人员凭藉少数封包就追查到这些假造实体位址的伪造封包来源,并且加以封锁。不过,经过反覆监听后发现,其实netcut假造实体位址的法则并非无迹可寻,例如在第一个攻击封包里,假造的实体位址是以62开头,后续的假造位址也将是以62开头,接着改用636465等等,以此类推,因此只要分析相当数量的攻击封包,就不难发现它的规律性,此时再利用分段隔离的原则进行监听过滤,还是可以追查出这些伪造封包的来源。


2. 关于COMODO对于netcut攻击的防御效果

首先来看看COMODO Firewall Pro对于ARP Spoofing攻击有什么设定选项。在COMODO FirewallPro>Firewall>Advanced>Attack Detection Settings功能设定画面中,发现有Protect the ARP cacheBlock Gratuitous ARP frames等两个关于ARP防护的设定项目,由于要测试COMODO Firewall Pro对于ARP Spoofing攻击的防御能力,因此莱因哈特把这两个防御功能全都启动。


《图十三》COMODO Firewall Pro具有Anti-Spoofing的功能选项

接着直接来测试netcut攻击能否突破COMODO Firewall Pro的防护吧!只要执行命令提示字元(也就是所谓的DOS视窗),在发动攻击前先执行arp –a指令列出正确的ART table内容,待发动攻击后再执行同样指令,两相对照就能看出COMODO Firewall Pro的防护效果如何。在正常状况下,闸道器的对映位址应该是永恒不变的,可是我们从下图可以发现,前后两次所列出的闸道器位址192.168.1.25410.1.1.254,它所对映的实体位址已经被置换,而此时原先持续在PING Yahoo首页的DOS视窗也变成满满的Request timed out讯息,这就证明了COMODO Firewall Pro对于netcut攻击根本束手无策。


《图十四》从攻击前后的ARP table可以看出,COMODO Firewall Pro根本无阻档netcut篡改对映资料的攻击手法

其实,打从得知netcut的行为模式开始,莱因哈特就警觉到个人防火墙对于netcut攻击可能无力抵挡,因为即使个人防火墙可以锁住本机ARP table的内容不被置换,也无法阻止netcut篡改闸道器上ARP table内容的恶质行为,只要闸道器上的对映位址不正确,造成被攻击端完全无法再从闸道器收到任何封包,同样会让被攻击端电脑无法正常连网。

很庆幸自己不是用COMODO Firewall Pro吗?先别高兴得太早,因为根据上述原因,不管你用的哪一套个人防火墙,都注定无法在netcut的攻击下存活,除非你能把闸道器的ARP table内容锁死不让修改。


3.
观察arp –s指令对于netcut攻击的防御效果

既然COMODO Firewall Pro无法锁死ARP record,那么自行下达arp –s指令锁住又如何呢?

莱因哈特在本机开启一个DOS视窗,下了两行指令锁住闸道器的对映资料:

arp –s 192.168.1.254 00-09-0f-0a-cd-88

以及

arp –s 10.1.1.254 00-09-0f-0a-cd-88

接着跑一次arp –a指令,确定已经成功加入两笔型态是staticARP recordARP table中,然后再开一个DOS视窗持续PING Hinet首页,最后在攻击端执行netcut对本机发动攻击。

很显然,arp –s指令可以成功抵挡住netcut欺骗本机意图修改ARP table的行为,因为闸道器的记录始终闻风不动,不过这时已经PING不通Hinet首页,证明只要闸道器上的ARP table没有被妥善保护,就依然会发生封包传输错误的问题而导致连线中断。


《图十五》下达arp –s指令后,无论netcut如何攻击,10.1.1.254192.168.1.254这两笔闸道器的ARP record丝毫不受影响


《图十六》没有保护好闸道器上的ARP table,依然会发生连线中断的现象


4. 关于netcut本身对于同类攻击的防护效果

眼尖的使用者可能会发现,在netcut主画面的左上方有一个保护我的电脑的功能选项,而且预设就是启动状态,那么是不是只要启动这项功能就可以保护自身不被同类攻击造成断线呢?在回答这个问题以前,我们先来分析一下它究竟在做什么事情。

在侧录分析这些攻击封包的时候,莱因哈特发现它同时也会持续发送包含正确实体位址的非典型ARP request封包给闸道器192.168.1.25410.1.1.254,而且发送频率为固定每秒一次。这种设计的用意,应该是想利用定时为闸道器ARP table更新正确资料的方式,去确保闸道器的封包能够正确传送到攻击端,不过,这只是单一方向的防护措施,是否意味它也会保护本机的ARP table内容不被置换呢?且来测试看看吧!


《图十七》netcut的自我防护功能,采用的依然是发送非典型ARP request封包给闸道器的方法,只是这回封包里的位址是正确无误的


《图十八》请注意上图出现两笔192.168.1.254的资料,上方实体位址为1E:69:34:45:23:54者为假资料,下方实体位址为00:09:0F:0A:CD:88者为真资料,显然netcut会将正确的闸道器位址储存起来,因此尽管其他应用程式被欺骗,netcut却能将自我保护的ARP request封包传送到正确的位址去

为了证明它是否具备前述的防护功能,我们改从被攻击端执行netcut对攻击端发动切断攻击,同时利用arp –a指令观察攻击前后的ARP table内容是否会被篡改。很不幸的,netcut根本无法阻挡本机的ARP table内容被置换,因此,即使它依然能够持续发送包含正确位址的ARP request到闸道器,使闸道器的ARP table内容得以纠正,却也因为本身的ARP table被篡改,造成netcut以外的应用程式封包都被传送到错误位址去,在这种情况下,原先的攻击端就变得无法正常连线了。


《图十九》请注意攻击前后10.1.1.254192.168.1.254个位址的Physical Address变化,就算已经启动自我保护,netcut依然挡不住本机的ARP table被篡改而沦陷

既然netcut主机被别人发动同类攻击,导致netcut以外的应用程式封包,再也无法将封包传送到正确的闸道位址,那么这时netcut主机还能切断别人的连线吗?答案是肯定的,因为在预设状态下,他人的同类攻击只是截断netcut主机与闸道器间的封包传输,并未切断netcut主机与同网段其他电脑间的通路,因此,netcut主机的攻击封包还是可以送达其他电脑,造成这些被攻击电脑的ARP table对映位址不正确而断线。


五‧结论

经过前面的一连串测试,我们可以得到以下结论:

1. netcut
的攻击手法就是交互发送伪造的非典型ARP request封包到被攻击端与闸道器,使两者的ARP table记录下错误位址而达成截断两者间封包传送的目的

2. netcut
在发动切断攻击时,约莫每秒钟就会变更一次实体位址并发送欺骗封包进行持久攻击,直到接获恢复指令为止。

3.
由于netcut会分别攻击闸道器及被攻击端,因此在单一主机上安装个人防火墙,或在单一主机上利用arp –s指令锁住ARP table内容,同样无法阻止连线中断的情形发生。

4.
即使启动netcut的自我保护功能,攻击端电脑一旦遭受同类攻击,同样无法抵挡,显然这是程式作者始料未及的事情。

5.
要追踪netcut攻击封包的来源虽非易事,不过也并非天方夜谭,只要分析出实体位址的造假规则,然后利用分段隔离的方法进行追踪即可;若是使用具备网管功能的高阶交换器,管理者甚至能够利用实体位址的造假规则,直接在交换器上查出攻击封包的来源并且加以封锁。

最后,请不要忘记netcut不单可以用来截断被攻击端与闸道器间的连线,也可以截断被攻击端与DHCP主机、AD主机,甚至与网路上任何一台主机的连线,因此攻击手法并非只有一种,可别以为只要顾好本机与闸道器就可以高枕无忧。假如你在自动分派IP位址的网路,发生跟DHCP伺服器失连的情形,照样会让你气得七窍生烟的。



爸爸 你一路好走
献花 x0 回到顶端 [楼 主] From:台湾 | Posted:2007-12-28 17:13 |
wenyilin
个人文章 个人相簿 个人日记 个人地图
初露锋芒
级别: 初露锋芒 该用户目前不上站
推文 x0 鲜花 x11
分享: 转寄此文章 Facebook Plurk Twitter 复制连结到剪贴簿 转换为繁体 转换为简体 载入图片

感谢大大详细的解说 表情 表情


望心无我欲沉醉
情由天涯笑苍穹
潮浪不识刀中趣
卧看浊世现云踪
献花 x0 回到顶端 [1 楼] From:未知地址 | Posted:2008-10-17 08:46 |
nicetalk
个人文章 个人相簿 个人日记 个人地图
小人物
级别: 小人物 该用户目前不上站
推文 x0 鲜花 x4
分享: 转寄此文章 Facebook Plurk Twitter 复制连结到剪贴簿 转换为繁体 转换为简体 载入图片

值得收藏~
感谢分享!


献花 x0 回到顶端 [2 楼] From:欧洲 | Posted:2009-02-08 18:44 |

首页  发表文章 发表投票 回覆文章
Powered by PHPWind v1.3.6
Copyright © 2003-04 PHPWind
Processed in 0.076732 second(s),query:16 Gzip disabled
本站由 瀛睿律师事务所 担任常年法律顾问 | 免责声明 | 本网站已依台湾网站内容分级规定处理 | 连络我们 | 访客留言