XZ Utils Made Me Paranoid

🌈 Abstract

The article discusses the author's experience and approach to developing a scanner tool to identify potential backdoors in software packages, specifically in response to the XZ Utils backdoor discovered in 2024. The author shares their thought process, the technical details of the scanner, and the challenges encountered during its development.

🙋 Q&A

[01] The Groundwork

1. What were the initial goals of the author's project?

• The main goals were to:
  • Identify what libraries were needed for a specific binary
  • Relate the libraries to each other and compare what was in memory to what was on disk

2. Why did the author choose to start with a basic function hook?

• The author had a simple "accept" backdoor proof of concept that used hooking, which allowed them to test the scanner without running an actual backdoor on their system.

3. What were the key steps involved in parsing the ELF file?

• Parse the ELF file to identify all the offsets for the sections, parse the relocations/offsets, get the remote process's memory, and compare the sections.
• The author decided to redo the relocations for the binary for every section they wanted to compare and null those sections before comparison.

4. How did the author handle the comparison of the sections?

• The author used "ptrace" to attach to the remote process and pull all the sections for every directly imported library in use.
• The author patched out the relocations in the range and compared the modified sections.
• The author encountered an issue with the Global Offset Table (GOT) not showing as different, which led to a different approach for a second scanner.

5. What were the noted problems with the initial approach?

• The author didn't consider "dlopen"/"dlsym" calls, which can load additional libraries that are not required by the process.
• Resolving symbols to the exact address used by the remote process was challenging, especially with newer systems using snap packages and containers.

[02] GOT Hooks

1. What was the author's approach for the GOT hooks scanner?

• The author decided to limit the scanner to a specific PID, read and parse the base executable, resolve all the symbols it imports, apply all relocations to it, and compare just the GOT.

2. What were the limitations of this approach?

• If a process uses a library that then calls a hooked function, it would be missed.
• To address this, the author would need to recursively load and compare the GOTs of every library loaded in the remote process, which would drastically increase runtime.

3. How did the author validate the effectiveness of the scanners?

• The author set up a Debian testing system and tried to backdoor it with a generic GOT hook, which the scanner was able to identify.
• The author also ran the "validate all sections" scanner on processes in memory and encountered some potential false positives related to "wtext" sections and multiple versions of libraries.

4. How can the results of the scanners be interpreted?

• The author provides examples of how to interpret the scanner output, including looking up function names in the libc.so.6 file and identifying potential false positives based on the "FileOffset" value and the presence of "wtext" sections.

[03] Future Work

1. What are the potential future applications of this type of scanner?

• The author suggests using this type of validation proactively on "critical" services and for identifying indicators of compromise (IOCs) in incidents like the "ArcaneDoor" campaign.
• The author also mentions the potential to expand the scanner to identify libraries that use "RWX"/"R-X" memory and sections inside processes with those permissions that aren't known to have them.