0x00 起因
前几天朋友跟我说他的服务器最近老是爆炸，而且经常是一到点就集体崩溃，别的服主也有类似的情况，他给服务器套上全局代理之后服务器就不崩溃了，然而给服务器开了代理客户端也连不进来。一开始我猜测是 BDS（Bedrock Dedicated Server，mcpe 官方服务端）会与 mojang 服务器有连接，连不上就会触发某个 bug 导致崩溃。
（图片是 windows 服务器的内存占用，服主 windows 和 linux 都有开）
报错如下，基本上只能得知是内存分配相关的问题，从报错判断不出什么。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
| 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 容器里面，大概方法如下：
1
2
3
4
5
| # 获取容器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 验证可能导致崩溃，由于网络环境改变导致他的攻击方式失效了）。
不过第二天服务器还是崩了，大概就可以确认是这个人搞崩的，服主提前找出了这个人在群里面的所有小号以及他的 ip，并把他踢了出去，那天开了白名单后服务器还是崩溃了的原因是服主看白名单很稳定，就放松了审核，不小心让内鬼就混了进去。在这之后服主开始了严格的 ip 白名单审核，服务器终于稳定了下来。
0x04 重现 bug
如果这么简单结束了的话我是不会写这篇文章的，在我得到了内鬼的相关信息之后，我想知道他是怎么攻击的。于是我又翻出了那天一开始抓的包，用服主得到的 ip 在包里面匹配，可是并没有找到什么，应该是换了 ip 了，然后我从 ip 归属地开始查，发现了一个跟内鬼同一个归属地的 ip。
理所当然地，我开始分析这个包的行为，发现他在服务器崩溃时刻发出了很多连接服务器的请求，每次的client GUID不一样，我猜测服务端每发现一个客户端连接时，不管它有没有连进来都会给这个客户端提前分配一段内存，一次发送很多client GUID不一样的包会让服务端误以为有很多客户端在连接，于是内存不够分配服务器就崩溃了。
为了验证这个想法，我把这段包提取出来，用 tcpreplay 重放，修改好网络包的 mac 地址，ip 和端口，向一个测试服务器快速重放这些可能会导致崩服的包，然而，持续发了好几分钟，服务器纹丝不动，内存占用率是一条让人尴尬的直线。
于是我开始找别的线索，抓的包里面与服务器有连接的也就十几个 ip，我挨个查了一下归属地，查完后我惊呆了，十几个 ip 里面有 6 个 ip 是来自阿里云的，排除其中两个是服主自己的服务器，还有 4 个，难道真正的攻击者是内鬼租的云服务器？我挨个看了一下那几个阿里云服务器的行为，倒也看不出什么太大猫腻，我顺手把那些包截取出来，稍作修改后开始对测试服发送，此时，测试服瞬间崩了，内存占用，报错信息和前几天的一模一样，然后我重新看了下这些包，
我猜是这样发包才能骗过服务器有很多客户端在与服务器建立连接，具体的原理已经不太重要了，毕竟这个得去研究一下 BDS 的协议才能知道详细信息，bug 已经复现了，向 mojang 提交 bug 才是正确方式。
0x05 后续
内鬼被踢了之后服主的主页被 d 了。。。现在还是黑洞状态
0x06
感谢 sow village（老母猪村服务器）提供素材.
（图片是 windows 服务器的内存占用，服主 windows 和 linux 都有开）
