事件背景 && 分析
基本信息
对外服务的机器遭遇到了三次Memcache反射DDOS攻击,记录一下处理、复现、反制过程。
攻击次数 | 持续时间 | 与上次攻击间隔时间 | 攻击规模 |
---|---|---|---|
第一次 | 30分钟 | 0 | 98G |
第二次 | 30分钟 | 15min | 82G |
第三次 | 32分钟 | 2.5小时 | 96G |
证据分析
从阿里云下载的证据cap进行分析可以得到四个信息:
- 本次攻击以Memcache反射流量为主,以SSDP流量为辅
- 在Memcache反弹回来的流量中夹杂着Pay 0.1 BTC to address的勒索信息
- 我们知道正常的一次Mem完成是S请求D(get key),D返回给S(value).但我们在抓到的所有看到Mem-Res的流量全部没有Mem-Req,而所有Mem-Res包,却看不到对应的Mem-Req流量.简而言之就是,有头没有尾,有尾没有头.这个结论是一个中间状态,只是一个结果.
- 进一步对IP的地址分布进行分析,所有Mem-Req包的dst全部是阿里云的地址,所有Mem-Res的src全部不是阿里云的服务器,来自越南,乌克兰等等,这个信息后面会有大用.
对基本信息分析了以后,我们进行紧急处理->复现->反制.
应急处理
阿里云云盾基础提供5G的防护,超过了就会被拉进黑洞清洗,运维工程师很快地购买了高防IP的服务,很快就被清洗并处理了.当我们解除了攻击的威胁以后,我尝试着做了一些相关研究和复现.
Memcache反射DDOS复现
反射DDOS攻击的原理非常简单,但是在国内的环境下复现起来却特别难,先简单说一下这个原理.
在一次攻击中,包含三个角色,攻击者/受害者/Memcache服务器,在这个过程中攻击者伪造受害者的IP做Mem-Req的UDP包,当Mem服务器接收到get key请求时,会给受害者服务器返回所请求的value,因此当即开始进行scapy发包实验,但实验进行的并不顺利.
实验编号 | 攻击者 | 受害者 | 反射服务器 | 实验结果 | 实验推论 |
---|---|---|---|---|---|
0 | 127.0.0.1 | 127.0.0.1 | 127.0.0.2 | Y | 脚本正常 |
1 | hostwinds-vps | hostwinds-vps | hostwinds-vps | N | 包到不了反射服务器 |
2 | hostwinds-vps | hostwinds-vps | cubecloud | N | 包到不了反射服务器 |
3 | 阿里云 | 阿里云 | cubecloud | N | 包到不了反射服务器 |
4 | cubecloud | cubecloud | cubecloud | N | 包到不了反射服务器 |
5 | 阿里云 | 阿里云 | 阿里云 | N | 包到不了反射服务器 |
6 | 阿里云 | 阿里云 | 腾讯云 | N | 包到不了反射服务器 |
最初的实验进行的很困难,全部是失败的结果.但是即使是这样,我们仍然可以得到一个结论是->使用国内外的大厂来做这个实验并不是那么容易.这也是我们为什么看到了攻击者伪造我们的IP向阿里云的mem服务器请求,但并没有返回包的原因,因为伪造的请求包并没有到对应的Mem服务器,所以看不到返回.
但是问题没有解决: 在这么严格的场景下,攻击者是如何做到的呢? 我们在类似于tg之类的市场里面做了一点调研,最终得到的信息是在类似于越南\乌克兰等一些小运营厂商里面,其实是可以找到能伪造的vps的.随买了一个很便宜的.
试验成功!
1 | while True: |
然后开始测我买的配置非常低的一台阿里云ecs,收到了云盾的报警还是挺激动的。
反制
在成功复现以后,我们已经具有了利用这批memcache服务器做反射DDOS的能力,但还是决定进行一次反制,即对这些反射服务器进行一些打击。
获取memcache服务的IP
1 | tshark -r 1.cap -Y "memcache" -T fields -e ip.src > output.txt |
使用excel进行数据去重并得到iplist.txt
批量扫描memcache的未授权
1 | nmap -sV -p 11211 --script=memcached-info -iL iplist.txt |
其中grep到Authentication为no的即为未授权。
制定反制方案
版本统计及CVE的查找
CVE-2016-8704可触发堆溢出造成远程代码执行,影响版本为<1.4.33,经过对这批机器的统计总数一百多台,该POC覆盖率满足70%。
自动化批量操作memcache,写入键值对(sec,secsecsec)留言警告
自动化批量操作memcache,对应key写入100000b左右的数据
自动化批量操作memcache,执行flush_all命令,清理掉那些BTC勒索信息
相关POC在github均有python脚本,做一下相关改造即可。
攻击完成以后,这批机器被打掉了一半,还有一半把它的缓存给flush掉,算是反击了一波,收工!