记一次处理Memcache反射DDoS勒索攻击及反制措施 – 作者:LittleT1ger

事件背景&分析

基本信息

碰到了一次外网机器遭遇三次Memcache反射DDOS攻击，记录一下处理、复现、反制过程。

证据分析

从阿里云下载的证据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发包实验,但实验进行的并不顺利.

最初的实验进行的很困难,全部是失败的结果.但是即使是这样,我们仍然可以得到一个结论是->使用国内外的大厂来做这个实验并不是那么容易.这也是我们为什么看到了攻击者伪造我们的IP向阿里云的mem服务器请求,但并没有返回包的原因,因为伪造的请求包并没有到对应的Mem服务器,所以看不到返回.

但是问题没有解决: 在这么严格的场景下,攻击者是如何做到的呢?

于是在类似于tg之类的市场里面做了一点调研,最终得到的信息是在类似于越南\乌克兰等一些小运营厂商里面,其实是可以找到能伪造的vps的.于是买了一个很便宜的小服务器开始测试.

while True:
send(IP(src=sip, dst=dip) / UDP(sport=1234, dport=11211) / Raw(load=getdata), count=1000000, verbose=0)

一次试验成功!

然后开始测我买的配置非常低的一台阿里云ecs，收到了云盾的报警还是挺激动的。

反制

在成功复现以后，我们已经具有了利用这批memcache服务器做反射DDOS的能力，但还是决定进行一次反制，即对这些反射服务器进行一些打击。

获取memcache服务的IP

tshark -r 1.cap -Y "memcache"  -T fields -e ip.src > output.txt

使用excel进行数据去重并得到iplist.txt

批量扫描memcache的未授权

nmap -sV -p 11211 --script=memcached-info -iL iplist.txt

其中grep到Authentication为no的即为未授权。

制定反制方案

1. 版本统计及CVE的查找

CVE-2016-8704可触发堆溢出造成远程代码执行，影响版本为<1.4.33，经过对这批机器的统计总数一百多台，该POC覆盖率满足70%。

2. 自动化批量操作memcache，写入键值对（sec,secsecsec）留言警告

3. 自动化批量操作memcache，对应key写入100000b左右的数据

4. 自动化批量操作memcache，执行flush_all命令，清理掉那些BTC勒索信息

相关POC在github均有python脚本，做一下相关改造即可。

攻击完成以后，这批机器的Memcache服务被打掉了一半，还有一半把它的缓存给flush掉，算是反击了一波，收工！

来源：freebuf.com 2021-02-24 21:51:40 by: LittleT1ger