CVE-2024-3094: Why the xz-utils backdoor is more than a technical issue

Signage

Despite the Easter holidays, a lot of incredible work was done over the weekend by many researchers analysing the details of the xz-utils backdoor.

Some examples are:

As the situation unfolds, it is becoming clear that this was not just one of the most sophisticated technical (perhaps the most sophisticated) attempts to introduce a backdoor into open source software.

Besides the focus on the technical aspects of the attack, It’s equally important to emphasize that this attempt was an extremely well-crafted piece of social engineering.

So, let’s learn how the attackers were able to successfully take over an open-source project in order to identify what’s necessary to protect our software against such an attack in future.

The timeline is based on the great analysis in Everything I know about the XZ backdoor (boehs.org).

Disclaimer: I’m describing the steps from the attacker’s perspective for educational purposes in order to prevent such attacks to be successful in future. Using these steps to manipulate people is unethical and can lead to criminal prosecution.

  1. Find a widely used OSS package that is maintained by a single person as a hobby project but is no longer regularly updated.
  2. Setup your malicious account but be patient. Don’t misuse it right away to the full extent but start with smaller changes, also in other projects than your target project. Build up credibility for your account.
  3. Start contributing non-suspicious changes to the package you target and support the package maintainer to handle the workload.
  4. Put subtle pressure on the maintainer via the package’s mailing list, using several email accounts imitating different persons. Ask why changes are not being made more quickly, and suggest that someone else should take over maintenance of the package.
    Make sure to emphasise that you understand the maintainer’s limitations, but that it’s only for the good of the widely used package if he/she steps down.
  5. Surprise, surprise – a potential maintainer candidate with established credibility is already available and ready to increase his or her privileges by being promoted to the maintainer role of the package.
  6. After some time and over multiple commits implement the backdoor – but not directly in the code. Instead use obfuscated binary test files, which are processed in the manipulated build process.
  7. Actively inform the large Linux distributions about the new version of your library via a third-party fake-mail-address (which built up minimal credibility the days before by creating updates for other small packages as well) and again try to influence the discussion by exerting pressure by using another mail address (= imitating another person), that the update is urgently needed, and blocks others work.

Similar Posts