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

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::allocator > >::allocate[unsigned long, void const*] (UnknownFile:?)
    at std::allocator_traits, std::allocator > > >::allocate[std::allocator, std::allocator > >&, unsigned long] (UnknownFile:?)
    at std::_Vector_base, std::allocator >, std::allocator, std::allocator > > >::_M_allocate[unsigned long] (UnknownFile:?)
    at std::__cxx11::basic_string, std::allocator >* std::vector, std::allocator >, std::allocator, std::allocator > > >::_M_allocate_and_copy, std::allocator >*> >[unsigned long, std::move_iterator, std::allocator >*>, std::move_iterator, std::allocator >*>] (UnknownFile:?)
    at std::vector, std::allocator >, std::allocator, std::allocator > > >::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 > >] (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}}" 
# 切换到容器的网络命名空间
nsenter -n -t 
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（老母猪村服务器）提供素材.
首发于我的个人博客