记一次mcpe服务器被黑与防御

2020-03-17  本文已影响0人  lomot

0x00 起因

前几天朋友跟我说他的服务器最近老是爆炸,而且经常是一到点就集体崩溃,别的服主也有类似的情况,他给服务器套上全局代理之后服务器就不崩溃了,然而给服务器开了代理客户端也连不进来。一开始我猜测是BDS(Bedrock Dedicated Server,mcpe官方服务端)会与mojang服务器有连接,连不上就会触发某个bug导致崩溃。

让人绝望的内存占用曲线

(图片是windows服务器的内存占用,服主windows和linux都有开)

报错如下,基本上只能得知是内存分配相关的问题,从报错判断不出什么。

terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
[2020-03-15 15:09:41 INFO] Package: com.mojang.minecraft.dedicatedserver
Version: 1.14.32.1
OS: Linux
Server start: 2020-03-15 14:53:05 UTC
Dmp timestamp: 2020-03-15 15:09:41 UTC
Upload Date: 2020-03-15 15:09:41 UTC
Session ID: e24ac8b6-8e41-4d53-ba6c-949b7bbcde90
Commit hash:
Build id: development
CrashReporter Key: e29bac8d-dc1e-3938-8438-413e8e159bce

Crash
[2020-03-15 15:09:41 INFO]  at gsignal (UnknownFile:?)
    at abort (UnknownFile:?)
    at __gnu_cxx::new_allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::allocate[unsigned long, void const*] (UnknownFile:?)
    at std::allocator_traits<std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >::allocate[std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >&, unsigned long] (UnknownFile:?)
    at std::_Vector_base<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >::_M_allocate[unsigned long] (UnknownFile:?)
    at std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >* std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >::_M_allocate_and_copy<std::move_iterator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*> >[unsigned long, std::move_iterator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*>, std::move_iterator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*>] (UnknownFile:?)
    at std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >::reserve[unsigned long] (UnknownFile:?)
    at PurchaseReceiptPacket::read[ReadOnlyBinaryStream&] (UnknownFile:?)
    at Packet::readNoHeader[ReadOnlyBinaryStream&, unsigned char const&] (UnknownFile:?)
    at NetworkHandler::_sortAndPacketizeEvents[NetworkHandler::Connection&, std::chrono::time_point<std::chrono::_V2::system_clock, std::chrono::duration<long, std::ratio<1l, 1000000000l> > >] (UnknownFile:?)
    at NetworkHandler::runEvents[bool] (UnknownFile:?)
    at Minecraft::update[] (UnknownFile:?)
    at ServerInstance::_update[] (UnknownFile:?)
    at clone (UnknownFile:?)

0x01 抓包分析

为了验证这个想法,我连朋友的服务器抓了几次服务器崩溃时的包,抓包用的是tcpdump,服务器开在docker容器里面,大概方法如下:

# 获取容器PID
docker inspect --format "{{.State.Pid}}" <container id/name>
# 切换到容器的网络命名空间
nsenter -n -t <container root id>
tcpdump -i eth0 -w dump.cap

但是服务器在线人数比较多,从抓到的包里面也没分析出什么关键信息。

0x02 问题排查

服务器还在一直崩溃,不过时间段好像变化了,没那么固定了,有时候也只是卡死一段时间,服务器并没有完全崩溃,此时除了怀疑MCPE服务器可能与mojang之间有连接之外,我慢慢地开始怀疑服主的群里面是不是有内鬼,但是群里面那么多人,也不好找谁是内鬼,于是我们准备使用ip白名单的方式来排查问题,也就是把部分信任的人的ip加入防火墙白名单,如果此时还会崩溃的话,那基本就可以排除服务器是被人攻击了的猜想,开了白名单之后服务器维持了很长一段时间稳定运行,但是后来还是炸了。我当时有点像放弃了(服主跑路算了,哈哈哈哈哈)。

有内鬼终止交易

0x03 内鬼自爆

高潮来了,开了白名单的那天晚上,内鬼自爆了,这个人直接在群里面坦白说是他炸的服,并且扬言还要继续,不过当时他由于未知的原因没有黑成功,被群友的嘲讽了一晚上(具体原因可能是那天我们把服务器换到了内网,用frp内网穿透的方式开了服务器,目的是为了排除mcpe服务器的xbox验证可能导致崩溃,由于网络环境改变导致他的攻击方式失效了)。

image

不过第二天服务器还是崩了,大概就可以确认是这个人搞崩的,服主提前找出了这个人在群里面的所有小号以及他的ip,并把他踢了出去,那天开了白名单后服务器还是崩溃了的原因是服主看白名单很稳定,就放松了审核,不小心让内鬼就混了进去。在这之后服主开始了严格的ip白名单审核,服务器终于稳定了下来。

0x04 重现bug

如果这么简单结束了的话我是不会写这篇文章的,在我得到了内鬼的相关信息之后,我想知道他是怎么攻击的。于是我又翻出了那天一开始抓的包,用服主得到的ip在包里面匹配,可是并没有找到什么,应该是换了ip了,然后我从ip归属地开始查,发现了一个跟内鬼同一个归属地的ip。


image

理所当然地,我开始分析这个包的行为,发现他在服务器崩溃时刻发出了很多连接服务器的请求,每次的client GUID不一样,我猜测服务端每发现一个客户端连接时,不管它有没有连进来都会给这个客户端提前分配一段内存,一次发送很多client GUID不一样的包会让服务端误以为有很多客户端在连接,于是内存不够分配服务器就崩溃了。

hack0

为了验证这个想法,我把这段包提取出来,用tcpreplay重放,修改好网络包的mac地址,ip和端口,向一个测试服务器快速重放这些可能会导致崩服的包,然而,持续发了好几分钟,服务器纹丝不动,内存占用率是一条让人尴尬的直线。

于是我开始找别的线索,抓的包里面与服务器有连接的也就十几个ip,我挨个查了一下归属地,查完后我惊呆了,十几个ip里面有6个ip是来自阿里云的,排除其中两个是服主自己的服务器,还有4个,难道真正的攻击者是内鬼租的云服务器?我挨个看了一下那几个阿里云服务器的行为,倒也看不出什么太大猫腻,我顺手把那些包截取出来,稍作修改后开始对测试服发送,此时,测试服瞬间崩了,内存占用,报错信息和前几天的一模一样,然后我重新看了下这些包,

hack4

我猜是这样发包才能骗过服务器有很多客户端在与服务器建立连接,具体的原理已经不太重要了,毕竟这个得去研究一下BDS的协议才能知道详细信息,bug已经复现了,向mojang提交bug才是正确方式。

0x05 后续

内鬼被踢了之后服主的主页被d了。。。现在还是黑洞状态

0x06

感谢sow village(老母猪村服务器)提供素材.
首发于我的个人博客

上一篇下一篇

猜你喜欢

热点阅读