新聞 | iThome ( ) • 2024-04-04 18:36

上周末,发生一起重大骇客攻击事件,差点让全球Linux都遭受供应链攻击,幸好有开发人员调查SSH登入失败及变慢500毫秒的状况,偶然发现异状,进而让后门程式码被揪出,及早揭露此项攻击活动,因此目前影响范围还算局限,只有部分Liunx版本受影响。否则,一旦该后门程式码进入稳定、主流的Linux发行版本,后果可是不堪设想。

许多资安专家纷纷指出,这起供应链攻击事件相当不单纯。

例如,攻击者是从XZ Utils资料压缩程式库植入后门,利用软体间的信任与依赖来打入Liunx环境,而该后门将可让攻击者绕过SSHD(Secure Shell Daemon)的身分认证机制。

而且,攻击者将后门植入的整个过程,如同采取间谍潜伏、爱情诈骗的社交工程手法一般,攻击者自2021年就注册GitHub帐号,之后参与开放原始码软体专案xz的维护,以逐渐获取其他开发人员的信任,直到2023、2024年才露出真面目,看似参与维护,实际行动却是想要偷偷将恶意程式码植入这个开放原始码软体。

显然,如此精心设计的攻击行动,很有可能是国家级骇客组织发起。如今,我们正持续看到有研究人员,从不同角度切入,或是分析后门程式码,希望厘清攻击全貌,以及试图找出攻击者的背景。

尽管整起事件的调查还没结束,但已有许多重要议题正被探讨,我们特别联系Linux软体开发与资安方面的专家,请他们解读目前这项资安威胁的概况,帮助大家掌握3大重要关键。

1.这次能及早发现,其实非常偶然且幸运

关于这起供应链攻击的发现,最大功臣自然是微软PostgreSQL开发人员Andres Freund。因为他在调查SSH登入变慢相关问题时,最初以为发现debian里面的套件包被入侵,但调查发现是上游的问题,XZ程式库与XZ的tarball档案被植入后门。

对于当中一些细节,我们找到Andres Freund在社群网路Mastodon平台的发文,并与身为Debian官方开发者、现于Bureau Veritas担任首席资安专家一职的林上智一同探讨,以还原发现经过。

具体而言,Andres Freund是在使用Debian开发版本sid(unstable)测试时,发现SSH登入有占用大量CPU资源的情形,进而对SSHD进行分析,发现XZ Utils资料压缩程式库的liblzma中有消耗大量CPU时间的情形  , 但是透过Linux上的效能分析工具perf检视,却找不到相对应耗费运算的函式或者相关原因。

这样的状况,使Andres Freund产生了怀疑,他回想起几周之前,在软体包更新后,曾在进行PostgreSQL自动化测试的过程中,发现了一些由Valgrind回报的记忆体异常错误结果。林上智认为,看起来是他在执行CI/CD时,发现valgrind错误。

后续,Andres Freund回报了这项问题后,才使得这起供应链攻击的面纱被揭开。

为何会去关注SSH登入时的CPU异常?我们找到Andres Freund在社群网路Mastodon平台的贴文与留言,他表示当时是在做一些微基准测试,需要让系统静止以减少噪音,所以才会发现SSHD的处理程序(processes)占用大量CPU资源。同时他也认为,自己并非资安研究人员,能发现这起攻击事件,确实需要很多巧合。

对于这次事件的偶然发现,使得XZ存在漏洞、被植入后门的问题及早浮现于台面,不只受到开发圈的关注,还有许多资安研究人员都在关注,因此我们也询问台湾资安业者奥义智慧。

奥义资安研究团队表示:「这次事件算是非常幸运。」因为有了提早的发现,所以目前只影响一小部分的Linux发行版。

因此大家都很感谢Andres Freund,能在测试时发现SSH异常状况(登入失败与登入速度变慢)后,进一步往上游追查,发现问题存在于liblzma之中,让IT界与资安界可以及早发现此漏洞与潜藏的供应链攻击。

综观上述说法,我们可以发现,除了有开发人员产生警觉并愿意去追查,从另一面向来看,也是因为该恶意活动可能有Bug,导致出现占用大量CPU资源的情形,才让开发人员有发现的机会。甚至,国际间有资安人员臆测这是否并非个案,其他只是还没发现。

之所以会进一步调查SSH登入异常,我们找到Andres Freund的说法,他在社群平台X上的一篇回应中指出,他是在尝试使用随机帐密组合的自动化尝试下,发现SSH登入失败、占用大量CPU资源的情形下,开始进一步调查,并也发现登入速度变慢500毫秒的情况。

2.若是后门进入所有Liunx发行版本,后果不堪设想

这起事件之所以受到极大重视,是因为如果没有及早发现,后果相当严重。幸好发现当下只有一些版本受到影响,尚未进入稳定、主流的Linux发行版本。

究竟影响范围与具体影响有哪些?毕竟这次事件是锁定软体程式库的供应链攻击,而非直接对OpenSSH伺服器本身进行攻击,手法相当复杂。

奥义资安研究团队表示,如果一直都没有发现的话,将是几乎所有的Linux发行版都会受到影响。

而且,从这次后门的具体功能来看,主要是透过systemd干扰SSH(Secure Shell)的sshd常驻程式,最终使网路犯罪分子可以绕过SSHD身份验证,并获得未经授权的远端存取系统。

林上智也指出,后果会是在进行OpenSSH身分验证前,攻击者可以执行特定封包,进而挟持OpenSSH伺服器,因为OpenSSH使用已遭污染的liblzma程式库。

整体而言,骇客攻击的目标是,将恶意程式码注入在受害者机器上运行的OpenSSH 伺服器(SSHD),并允许特定的远端攻击者(拥有特定私钥)通过SSH发送任意酬载(Payload),这些酬载将在身份验证步骤之前执行,从而有效地劫持整个受害者机器。因此,若是后门真的进入主流的Linux发行版本,届时骇客可能发动相当大规模的劫持行动,进而造成前所未有的重大资安事件。

3.攻击者竟长期潜伏以取得信任,引入后门的手法也非常隐密

这起事件的另一瞩目焦点,是入侵过程相当复杂且难以察觉。

在事件揭露后,已有许多研究人员正追查其入侵手法,以及本次事件提交(Commit)的GitHub帐号。

例如,从涉及此事件提交的GitHub帐号来看,攻击者似乎是在2021年就注册一个GitHub帐号用户,其代号为Jia Tan(JiaT75),该帐号先是在2022年2月6日,首度提交内容至XZ程式库,后续竟然悄悄将恶意程式码埋常其中,例如,其中bad-3-corrupt_lzma2.xz与good-large_compressed.lzma这两个看起来无害的测试用binary,会在特定条件下解析出恶意程式。

因此,在这次供应链攻击中,我们整理出目前最值得注意的3个重点:

(一)骇客铺陈这起供应链攻击行动,看起来已潜伏长达3年之久

关于攻击者的入侵过程,宛如间谍行动的社交工程手法一般,从3年前就开始准备,之后积极参与xz项目的维护,逐渐获取原始项目开发人员的信任,直到近期才开始将软体加料,而且其手法相当难以察觉。

这也显现攻击者有著超乎寻常的耐心,经历这样长时间的渗透,花了两年多时间取得信任,让自己可以成为合法的维护者。这也让外界纷纷推测,如此精心设计的攻击行动,非常有可能是由国家级骇客组织发起。

因此,目前许多研究人员正在追查相关线索,而且攻击者似乎也在使用的代号上做出混淆,取了一个很像中文拼音的代号,但有研究人员从时区角度切入去追查,猜测攻击者可能是位于东欧。不过这些都还在调查中,还有像是关于后门程式的逆向分析等,也有待后续有研究人员一一揭露。

(二)加入后门的手法相当隐密,提交的测试资料在特定条件下才会解析出恶意程式

关于攻击者的入侵过程与方式,奥义智慧资安研究团队说明了他们的观察。

首先,攻击者的确是从2021年就注册了GitHub帐号,并多次提交测试相关的程式码,因此逐渐取得XZ Utils主要专案开发者的信任。

但值得注意的是,Jia Tan在每个送出的提交(commit)中,都带有片段的后门程式,但是,只有特别在XZ要进行打包编译release出去时,才会加进编译的过程中。

为什么会有这样的情形?使得攻击资料可以成功伪装成测试资料,并且直接编译原始码时还不会加入编译的过程。

奥义智慧资安研究团队解释,这里有一个特殊的关键:攻击者在一个很隐密的地方,加上了一个看似不小心多打出的句点「.」。但是,就是因为一个普通的句点,造成了解析上的差异。

基本上,例如在使用CMake进行编译时,为了确认某个编译器是否可以使用,通常会尝试编译一小段程式码,而攻击者特意写出一段有错误的程式码,这就是开头那个小句点需要出现的原因,编译器会因为编译出错,误认为此沙盒(Lanlock)的测试是不存在的,所以就会停用。

这个可以跳过沙盒的CMake并推上正式版本,后续即可推后面程式上去,并可以跳过检查,攻击者就可以在下一版往(Lanlock)的部分加入任何程式码,而不会受到检查。且攻击者也会挑选快要release的时间提交(commit)他的程式码上去,尽量减少被人发现的机会。

(三)提交时间点巧妙,避过原始维护者的审查

对于攻击者事件,凯特纳科技创办人兼CEO曾信田(Newbug)也提供一些重要观察,他表示,这事件的影响范围在debian/ubuntu/fedora/opensuse testing 版的x86-64 sshd,攻击时间锁定在原始XZ维护者Lasse Collin(Larhzu)处于休息离线(internet breaks)的时间发动攻击。

他特别指出,这个问题是审查commit时的疏忽,算是一种信任感攻击,由于原始维护者在这段休息期间无法审查(review)程式码,而导致恶意程式码被整合于其中。

因此他认为,在程式码commit时,或许可以导入AI进行程式码审查(code review),避免因为人员的疏忽,或是程式码审查上的疲累,而导致恶意程式码被接受。他也庆幸,还好恶意酬载(payload)有CPU资源占用飙升的Bug,而被及早发现,才没污染到稳定版。

Debian社群有实名制等衍生性讨论

在上述3大焦点之外,对于Debian官方开发者社群而言,林上智表示,在这次事件后,也引发了一些衍生性的讨论。

例如,最主要的焦点是,由于Debian开发者需使用unstable进行套件打包上传至unstable archive,因此,Debian开发者所使用的开发机器需要尽速更新。

还有一些衍生的安全议题,像是开源贡献者的实名制问题探讨。

事实上,由于开源贡献者来自世界各地,很难去辨别其背后身分,因此过去Debian开发者需要需要层层审核跟检验,累积贡献后才能进行申请。

例如,在成为Debian官方开发者之前,需要申请成为Debian维护者,而申请的第一步就是要做到身分识别(Identification),这方面的要求是需要面对面的情形,至少跟一位Debian官方开发者交换PGP key(keysigning),并在交换key时需核对对方的官方证件,通常是会核对护照,以确保该人员的身分。现在则是则对实名制有更进一步的讨论。

林上智解释,这方面的相关讨论还在进行中,因为有的Debian开发者认为,如果是国家级的攻击,那该国家也可以帮忙制作假ID或者假的身分证明,所以实名制对抵挡国家级的攻击较没有意义;不过也有的人认为,攻击者不太喜欢曝光于外界,或被看到真面目,如果要面对面交换key,这多少可以吓阻有心人士。

至于从其他开源生态的动向来看,已经有些专案这么做,例如:GCC专案要求贡献者一律实名制,以及Linux kernel禁止匿名贡献的情形。林上智也以自身经验为例,过去他在送kernel patch时,曾有一度被kernel maintainer退件,后来才知是因为名字有中文,但对方的机器不支援中文编码,因此显示不出来,导致对方以为他是匿名贡献者。