本站vip特权 - 全站资源免费下载

限时特惠

记一次处理Memcache反射DDoS勒索攻击及反制措施

事件背景&分析

基本信息

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

攻击次数 持续时间 与上次攻击间隔时间 攻击规模
第一次 30分钟 0 98G
第二次 30分钟 15min 82G
第三次 32分钟 2.5小时 96G

证据分析

%title插图%num

从阿里云下载的证据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复现

%title插图%num反射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的.于是买了一个很便宜的小服务器开始测试.

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

一次试验成功!

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

%title插图%num%title插图%num

反制

在成功复现以后,我们已经具有了利用这批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

%title插图%num

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

制定反制方案

%title插图%num

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脚本,做一下相关改造即可。

%title插图%num

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

网络资讯

如何把企业的云上日志采集到本地SIEM

2021-4-29 14:12:44

网络资讯

DMARC:企业邮件信息泄漏应对之道

2021-5-6 19:51:09

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索