【应急响应】“脱缰”的野马

  • A+
所属分类:安全闲碎

话说那天下着小雨,我瞅了一眼时间,哦阔快下班了。看一眼今天的事件闭环没,没有啥大问题,拔掉电源准备溜溜球。手机响了,老大来电话了。

“有空不来应急了,一片网络瘫了赶紧去看看。”“啥情况啊。”“记录转你了,进群拿包分析。”

有活干了,进群后找了同事问一下情况,有点棘手,只给了数据包排查。

PS:以下数据已经脱敏,聊天记录不会截图,只分享经验和思路,这是一次非常有意思的排查


0x10确认情况,搜集情报

看了一下聊天记录,客户的网络通过EOC设备管理终端,大概一两千台。然后在每天凌晨定时有几百台机器脱管,重启后恢复,地址不变。怀疑遭到了攻击,包体中有大量的arp包,我同事怀疑是arp欺骗攻击。

一共四个流量包,体积还不小。问了一下从哪里抓的,客户答曰:某个端口上抓的。

【应急响应】“脱缰”的野马


0x11确认到手情报

打开四个包看看什么情况,好家伙全黄,都是arp包。【应急响应】“脱缰”的野马

还夹带着一些其他包,LLDP、DHCPv4,IGMPv3,ssdp,ICMP v6

【应急响应】“脱缰”的野马

【应急响应】“脱缰”的野马

【应急响应】“脱缰”的野马


这里发现了一些很奇怪的报文,分别是dhcp和arp的。这俩的结构是有一些问题的。

【应急响应】“脱缰”的野马

【应急响应】“脱缰”的野马


0x20协议分析

这次排查还是比较困难的,因为客户只给了这点东西,而且我提出为了防止扩散危害暂时切断那片脱管主机的网络也不被允许。那接下来只能分析报文结构是否有问题了。

提取一下关键词:抓包从某一个端口,大量的arp包,异常的dhcp包,netbios协议,ssdp包中的字段。


0x21 网络拓扑分析

问客户要了一份拓扑图,拿来分析,客户给的很简单手画,为了保密我更简化了一点。【好久没画啦,见谅】

【应急响应】“脱缰”的野马

在拓扑中,可以知道,其实网络并不复杂,攻击者要不直接拿下核心交换机或者域控。又因为这张网络很庞大,主机上千台,运维不可能不写嗅探功能。

DHCP嗅探功能可以有效阻止dhcp offer报文,以达到阻止伪造DHCP服务器对终端提供虚假服务的目的。一旦开启需要手动指定信任端口。

其实,我猜客户只是想表达他们怎么管理下面的主机群。


0x22异常字段分析


1.arp报文

先来看一下正常arp报文的结构:

【应急响应】“脱缰”的野马

ARP报文的结构简单,也只有请求和回应两种包。

ARP欺骗的原理:攻击者先嗅探ARP包,然后盗取某一个主机的mac地址,将数据引流到攻击者的主机上。

【应急响应】“脱缰”的野马


再来看包中的arp报文:

主要有三个设备再发 H设备、J设备、TP设备。

【应急响应】“脱缰”的野马

出现异常的只有J设备上的ARP报文,那很简单,我们用小鲨鱼的对话过滤,过滤出所有关于J设备ARP报文。

【应急响应】“脱缰”的野马

异常就在Trailer这个字段上,因为正常的ARP报文中是用Padding字段代替的全0填充。

trailer字段用于字节超额时,承载超额字节,出现非零填充现象。

但是,在经过我长时间筛选下,都没看到有明显的攻击痕迹:都是一些无意义的字节。也不像arp欺骗攻击,以为没有任何入口被突破。

【应急响应】“脱缰”的野马

【应急响应】“脱缰”的野马

【应急响应】“脱缰”的野马


2.dhcp报文

流量包里出现问题的报文是dhcp discover报文,该报文用于请求地址,因为它不知道dhcp sever的地址所以用全0来请求。

这里提示出现一瞬间的little endian编码,这种情况就是高低电位紊乱出现的。

【应急响应】“脱缰”的野马

其实到这里,我已经和同事说,这7成是网络问题,至于是什么网络问题我一时间没办法说出来。接下来分析我不确定的3成在哪。


3.其他协议的报文

这也是后来,我打算写报告了,然后客户1点半又来了几个包,是重启恢复后短时间抓到的包。我又咕噜咕噜爬起来分析了。

来看看其他发现吧,这些发现都被客户弹回去了,确定了没事的。

在SSDP报文中,发现了似乎与外部有连接的字段:

【应急响应】“脱缰”的野马

然后又在其他报文中发现主机名和这台是域控,辣是把我吓了,域控被k掉了???

客户:那是用来抓包的机器,没事。【应急响应】“脱缰”的野马

【应急响应】“脱缰”的野马

【应急响应】“脱缰”的野马


0x30结论

这其实不是遭受网络攻击的问题,上面那是我整理了思绪写出来的,应急的时候我完全是以网安的思想去思考,其实换个网工的角度,答案就很明显了。

首先来回顾一下拓扑图:

【应急响应】“脱缰”的野马

经典的OLT架构网络,下面拖ONU设备进行管理。ONU设备是光网络单元设备,一般把装有包括光接收机、上行光发射机、多个桥接放大器网络监控的设备叫做光节点。PON使用单光纤连接到OLT,然后OLT连接到ONU。

然后再看DHCP报文,其中短暂出现了little endian编码;同时在ARP报文中,出现无意义的额外字节填充。

结论只有一个了ONU设备出了问题,光纤或者光模块出现了损伤,导致数据传输失败。在上面的分析来看,dhcp discover包是没有被回应的,arp包构造也是完整的。同时出现多次igmp加组离组的申请报文没有得到回应。得到的结论是:因为光信号传输出现问题,导致下面某一片主机脱管,并非网络攻击。


在两天后,我帮老大找材料的时候,得到了验证。有一种叫做ONU流氓猫的情况。以下是该情况的摘要:

“根据IEEE802.3协议,宽带网PON系统传输信号时,采用的是时分复用技术。在正常状态下,ONU应该按照指定的时间戳向上行方向发送数据包。但当某个ONU没有按照指定时间戳发光,而是长发光或无规则发光,就会与其他正常发光的ONU光信号产生传输冲突,  破坏了OLT设备PON口的正常接受,对OLT设备造成L2(数据链路层)  的DOS攻击行为,从而导致整个PON口下挂用户大量的掉线、断网现象。这种不按照分配的时间戳向上发送光信号的ONU被俗称为流氓ONU。”


感谢各位师傅赏脸观看,我只是随叫随到的应急响应工程师,有问题可以在下方留言讨论。


ONU流氓猫分析:

https://www.freebuf.com/articles/endpoint/277925.html?

本文始发于微信公众号(利刃信安):【应急响应】“脱缰”的野马

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: