上週末，发生一起重大骇客攻击事件，差点让全球Linux都遭受供应链攻击，幸好有开发人员调查SSH登入失败及变慢500毫秒的状况，偶然发现异状，进而让后门程式码被揪出，及早揭露此项攻击活动，因此目前影响範围还算侷限，只有部分Liunx版本受影响。否则，一旦该后门程式码进入稳定、主流的Linux发行版本，后果可是不堪设想。
许多资安专家纷纷指出，这起供应链攻击事件相当不单纯。
例如，攻击者是从XZ Utils资料压缩程式库植入后门，利用软体间的信任与依赖来打入Liunx环境，而该后门将可让攻击者绕过SSHD（Secure Shell Daemon）的身分认证机制。
而且，攻击者将后门植入的整个过程，如同採取间谍潜伏、爱情诈骗的社交工程手法一般，攻击者自2021年就注册GitHub帐号，之后参与开放原始码软体专案xz的维护，以逐渐获取其他开发人员的信任，直到2023、2024年才露出真面目，看似参与维护，实际行动却是想要偷偷将恶意程式码植入这个开放原始码软体。
显然，如此精心设计的攻击行动，很有可能是国家级骇客组织发起。如今，我们正持续看到有研究人员，从不同角度切入，或是分析后门程式码，希望釐清攻击全貌，以及试图找出攻击者的背景。
儘管整起事件的调查还没结束，但已有许多重要议题正被探讨，我们特别联繫Linux软体开发与资安方面的专家，请他们解读目前这项资安威胁的概况，帮助大家掌握3大重要关键。
１.这次能及早发现，其实非常偶然且幸运
关于这起供应链攻击的发现，最大功臣自然是微软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毫秒的情况。
２.若是后门进入所有Liunx发行版本，后果不堪设想
这起事件之所以受到极大重视，是因为如果没有及早发现，后果相当严重。幸好发现当下只有一些版本受到影响，尚未进入稳定、主流的Linux发行版本。
究竟影响範围与具体影响有哪些？毕竟这次事件是锁定软体程式库的供应链攻击，而非直接对OpenSSH伺服器本身进行攻击，手法相当複杂。
奥义资安研究团队表示，如果一直都没有发现的话，将是几乎所有的Linux发行版都会受到影响。
而且，从这次后门的具体功能来看，主要是透过systemd干扰SSH（Secure Shell）的sshd常驻程式，最终使网路犯罪分子可以绕过SSHD身份验证，并获得未经授权的远端存取系统。
林上智也指出，后果会是在进行OpenSSH身分验证前，攻击者可以执行特定封包，进而挟持OpenSSH伺服器，因为OpenSSH使用已遭汙染的liblzma程式库。
整体而言，骇客攻击的目标是，将恶意程式码注入在受害者机器上运行的OpenSSH 伺服器（SSHD），并允许特定的远端攻击者（拥有特定私钥）通过SSH发送任意酬载（Payload），这些酬载将在身份验证步骤之前执行，从而有效地劫持整个受害者机器。因此，若是后门真的进入主流的Linux发行版本，届时骇客可能发动相当大规模的劫持行动，进而造成前所未有的重大资安事件。
３.攻击者竟长期潜伏以取得信任，引入后门的手法也非常隐密
这起事件的另一瞩目焦点，是入侵过程相当複杂且难以察觉。
在事件揭露后，已有许多研究人员正追查其入侵手法，以及本次事件提交（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出去时，才会加进编译的过程中。
为什么会有这样的情形？为什么攻击资料可以成功伪装成测试资料，并且不受到像是Lanlock等process access control防御机制作业系统的防御机制的检查，并且直接编译原始码时还不会加入编译的过程。
奥义智慧资安研究团队解释，这里有一个特殊的关键：攻击者在一个很隐密的地方，加上了一个看似不小心多打出的句点「.」。但是，就是因为一个普通的句点，造成了解析上的差异。
基本上，例如在使用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退件，后来才知是因为名字有中文，但对方的机器不支援中文编码，因此显示不出来，导致对方以为他是匿名贡献者。
