Security company Kaspersky explains how the backdoor of the compression tool 'XZ Utils' used in Linux environments is embedded



Russian security company Kaspersky posted an analysis article about a backdoor that was discovered in a library called '

XZ Utils ' on March 29, 2024 .

Kaspersky analysis of the backdoor in XZ | Securelist
https://securelist.com/xz-backdoor-story-part-1/112354/



XZ is a compression tool used in many Linux distributions, and this time the attack specifically targeted the OpenSSH server process 'sshd.' In distributions such as 'Ubuntu,' 'Debian,' and 'RedHat/Fedora,' XZ is called via ' systemd ' when sshd starts, and a backdoor that allows remote code execution is installed in sshd.

The timeline of when this backdoor was installed and discovered can be found in the following article.

Summary of the timeline leading up to the backdoor attack on XZ Utils - GIGAZINE



Since XZ is a compression tool, the XZ repository includes test files to test the compression and decompression code to make sure it works, and the attackers noticed this and added two test files that hide the code to implant a backdoor.

After that, code to extract the code from the test file was inserted into the build script. It was obfuscated to look harmless at first glance, as shown in the top line of the image below, but when rewritten to be easier to read, it reads the test file, repairs the corrupted data with the tr command , and decompresses it with 'xz -d', as shown in the bottom line.



The extracted script checks that it is running on a Linux machine and in the intended build process, as shown below, and then extracts another test file. The extracted data of this test file appears to be junk data at first glance, but it is actually 1024 bytes of junk data and 2048 bytes of malicious data, in that order. The script extracts the malicious data, deobfuscates it with the tr command, and then executes it in a shell.



The next shell script again checks the execution environment. It checks whether the necessary files and tools are available, among other things.



Then, the binary file used to execute the backdoor is extracted from the test file.



The code in the bottom line of the image above can be expanded to make it easier to read: First, XZ is used to decrypt a test file that hides a malicious binary file, then a certain number of bytes are deleted from the beginning of the data before saving it to disk as an executable file. The XZ file is also edited to replace the call to the '__get_cpuid' function with a call to the '_get_cpuid' function so that the executable can link to the library.



The infection chain throughout the build process is as follows:



XZ uses two special functions, lzma_crc32 and lzma_crc64, to calculate

the CRC of data. Both functions are stored in the glibc ELF symbol table as IFUNC (indirect function) types, allowing developers to dynamically select which function to use when the dynamic linker loads a shared library.

XZ uses IFUNC to select the optimal version of a function depending on the processor's capabilities, and calls '__get_cpuid' to check if the processor has a certain feature. The shell script rewrites this call to '__get_cpuid' with one underscore removed, and actually calls the object file with the backdoor.

Because both “lzma_crc32” and “lzma_crc64” use the same “_get_cpuid” function, the backdoor code is called twice, the second of which redirects to the backdoor entry point where the actual malicious activity begins.



The backdoor tries to hook functionality that allows it to monitor all connections to the machine while remaining as stealthy as possible. As shown in the following code, the malware will stop running if it is not running within 'sshd' and will also check all process environment variables and stop running if it finds a process that matches a string in an internal table.



This backdoor is very complex, not only in the code of the binary itself but also in the multiple layers of embedding in the XZ repository, and uses advanced methods to avoid detection. Kaspersky says that 'there is still a lot to investigate inside the backdoor,' and that this commentary is 'Part 1.'

Kaspersky Lab products detect malicious objects related to this attack as 'HEUR:Trojan.Script.XZ' and 'Trojan.Shell.XZ', while Kaspersky Endpoint Security for Linux can detect malicious code in the sshd process memory as 'MEM:Trojan.Linux.XZ'.

in Software,   Security, Posted by log1d_ts