【导读】GitLab最近又被DDoS攻击给盯上了，峰值流量超1 Tbps。此次攻击的漏洞来源于4月份已经修复的bug，但仍有30000台未安装更新的服务器遇难。

GitLab 又被分布式拒绝服务（DDoS）攻击了！

负责谷歌DDoS防御的云安全可靠性工程师Damian Menscher最近披露，有攻击者正在利用 GitLab 托管服务器上的安全漏洞来构建僵尸网络，并发起规模惊人的分布式拒绝服务攻击（DDoS）。其中一些攻击的峰值流量，甚至超过了1 Tbps 。

本次攻击利用的漏洞编号为CVE-2021-22205，GitLab曾在2021年4月修复该漏洞。

此次攻击由 William Bowling发现，并通过Bug Bount报告给GitLab，漏洞主要影响的组件是Exiftool，可以用于从上载到Web服务器的图像中删除元数据的库。

GitLab 在他们私有版本GitLab Community Edition（CE）和Enterprise Edition（EE）中使用Exiftool，也就是GitLab服务的开源和商业版本，公司可以在自己的服务器上安装，用于在安全环境中处理私有代码，而不必使用GitLab的云服务。

在通过Hackerone提交的一份报告中，Bowling说他发现了一种滥用Exiftool处理用于扫描文档的DJVU文件格式上传的方法，以获得对整个GitLab Web服务器的控制权。

据意大利安全公司HN Security称，利用这一漏洞的攻击始于今年6月，该公司上周首次报告了漏洞的使用迹象。

当时安全研究员Piergiovanni Cipolloni表示，在发现有随机命名的用户被添加到受感染的GitLab服务器后，他们随即对此展开了调查。这些用户很可能是由攻击者一手创建，旨在对受害系统实施远程控制。

尽管HN Security尚不清楚这些攻击的目的，但Google工程师Damian Menscher已于昨日表示，被黑服务器属于某个巨型僵尸网络的一部分。

该网络包含成千上万个受感染的GitLab实例，且正被用于发起大规模的DDoS攻击。遗憾的是，尽管GitLab已于2021年4月完成了修补，仍有大约30000个GitLab服务器尚未打上补丁。

这说明了什么？不要禁用安全更新！当然了，Windows更新的开启和关闭是一个玄学问题。

值得注意的是，GitLab问题核心的Exiftool漏洞（CVE-2021-22204）也可能影响部署该工具的其他类型的Web应用程序，，其他类型的Web应用程序也可能需要修补。

防止攻击的简单方法是阻止DjVu文件在服务器级别上载，如果公司不需要处理此文件类型的话。

DDoS（分布式拒绝服务）实际上是一种常见的网络攻击，亦称洪水攻击，其目的在于使目标电脑的网络或系统资源耗尽，使服务暂时中断或停止，导致其正常用户无法访问。当黑客使用网络上两个或以上被攻陷的电脑作为「僵尸」向特定的目标发动「拒绝服务」式攻击时，称为分布式拒绝服务攻击。

就是说服务器的流量都被用于服务僵尸网络了，当正常用户访问时，已经没有多余的能力来应对了，对于用户来说网站瘫痪了。

首先，DDoS攻击会拒绝访问你的网站或服务。攻击者滥用受感染或配置错误的机器（服务器，路由器甚至PC机）的网络，以向单个系统生成大量虚假流量，从而使其暂时不可用。

并且大多数托管和云提供商会向其客户收取额外的带宽或计算能力。如果启用了自动扩展，则在遭受DDoS攻击时，入口流量激增和基础架构可能会开始快速扩展，本月Internet流量和计算资源费用不断增加，导致更高的运营成本。

由于数据库和系统不堪重负，未保存的工作可能不会被存储或缓存。对于处理关键任务工作负载或运行某些数据一致性至关重要的在线事务处理应用程序的企业而言，这可能是一个至关重要的问题。

服务器日志将与数千个攻击日志混在一起，因此将很难进行过滤和检查一切是否正常。另外，你可能设置了if-then规则，并使系统自反应。在这种情况下，混杂的日志可能会对系统造成实际损害，从而给你造成很大的影响。

DDoS还可以用作服务错乱这种攻击技术。当管理人员忙于过滤流量时，可能会同时执行小的破坏性攻击。这种相似的攻击方式曾经对号称世界上最安全的比特币钱包Electrum进行过。

当时来自超过15万个受感染主机的巨大DDoS攻击被发往Electrum网络，中断了所有用户的交易。同时，网络钓鱼攻击迫使恶意消息弹出给客户端，要求他们更新软件。然后，人们错误地安装了恶意软件，该恶意软件立即将所有的账户余额都转向了攻击者的钱包。

2017年时，GitLab就发生过不小心删除了数据库导致网站下线的事故。

Gitlab遭受了恶意邮件发送者的DDoS攻击，导致数据库写入锁定，网站出现不稳定和宕机，在阻止了恶意邮件发送者之后，运维人员开始修复数据库不同步的问题，在修复过程中，错误的在生产环境上执行了数据库目录删除命令，导致300GB数据被删除，Gitlab被迫下线。

在试图进行数据恢复时，发现只有 db1.staging的数据库可以用于恢复，其它五种备份机制均无效。db1.staging是6小时前的数据，而且传输速率有限，导致恢复进程缓慢。

Gitlab第一时间在Twitter上对事件的处置状态进行实时更新，后来索性在 Youtube上开了频道直播恢复进程，网站恢复了正常后，gitlab还是丢掉了差不多6个小时的数据。

2018年时，GitHub也曾遭受过DDoS攻击，峰值流量甚至达到了1.3 Tbps，在当时堪称史上最严重的DDoS攻击。GitHub受到攻击后，服务器断断续续，无法访问。攻击发生10分钟后，GitHub向CDN服务商Akamai请求协助，访问GitHub的流量由后者接管。

Akamai用多种方式防御这次攻击。除了通用DDoS防御基础架构之外，该公司最近还针对源自memcached服务器的DDoS攻击实施了特定的缓解措施。

网络监测和舆情分析公司ThousandEyes表示「这次防御做的很出色，一切都在15-20分钟内完成。如果看一下统计数据，就会发现，单独的DDoS攻击检测通常都要一个小时，而这次20分钟内搞定」。

Akamai怀疑攻击者仅仅是因为GitHub很高端，知名度很高，所以锁定了GitHub作为目标。而防御措施太快，持续时间相当短，可能还没来的及要赎金，一切就结束了。

目前防御手段的发展也很快，在2020年时，AWS报告说2月检测到2.3Tb的DDos攻击，持续了三天，意图瘫痪AWS，但没有成功。

规模来看虽然达到了2018年GitHub的两倍，但防御起来显然比之前更轻松。

但IBM就相对比较惨了，2020年6月11日，IBM声明称，云业务宕机事件是由第三方网络提供商非预期地调整IBM对外网络路由，导致其全球流量一度严重受阻。声明中还提到，整个事件持续时间是从北京时间6月10日早上5:55到早上9:30。两个小时后该公司再次发推表示，所有的IBM云服务已重启。

IBM宣布了这次事故归咎于「外部网络提供商用错误的路由瘫痪了IBM云网络」。然而，Techzim从一个技术来源处收到了一份信息，该技术来源自始至终都在监视停机情况，并显示了IBM云网络本身发生的问题。

所以说，如果一家云公司一年没有几次大事故，那它就不能称之为云巨头。

参考资料：

https://therecord.media/gitlab-servers-are-being-exploited-in-ddos-attacks-in-excess-of-1-tbps/

本文来自微信公众号“新智元”（ID:AI_era），编辑：LRS，36氪经授权发布。