笔者对比了被植入后门的liblzma与正常liblzma反编译后的代码,亮瞎眼的地方莫过于被植入后门的liblzma使用了CPU内部指令集来进行AES计算,这个虽然CPU官方的说法是总体计算省时省电,但作为一名一直和CPU指令周期较真的人,一个时间片内,CPU执行的指令周期越多,占用资源越大,毕竟内部指令是无法被中断的,然后就因为liblzma占用了大量的CPU时间被发现了,这好像是个聪明反被聪明误的故事。
最后附上检测yara,有需要的检测可以使用
rule SSC_XZ_Backdoor_1
{
meta:
description = "SSC_Backdoor_liblzma GROUP"
author = "virk"
thread_level = 10
in_the_wild = true
strings:
$a = {F3 4D 0F BC C0 41 C1 E8 03}
$b = {F3 48 0F BC FF C1 EF 03}
$c = {66 0F 3A 44 CC 11}
$d = {66 0F 3A 44 05 ?? ?? ?? ?? 00}
$e = {0F A2 89 46 08 89 5E 10 89 4E 18 89 56 20 E9}
$f = {0F A2 41 89 02 41 89 19 5B 89 0E 41 89 10}
condition:
(uint32(0) == 0x464C457F) and ($a or $b) and ($c or $d) and ($e or $f)
}
原文始发于微信公众号(锐眼安全实验室):liblzma的供应链投毒,居然折在了CPU硬件加速上
免责声明:文章中涉及的程序(方法)可能带有攻击性,仅供安全研究与教学之用,读者将其信息做其他用途,由读者承担全部法律及连带责任,本站不承担任何法律及连带责任;如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截,联系方式见首页),望知悉。
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论