Learn more about the backdoor in upstream xz/liblzma leading to ssh server compromise

Two days ago, on March 29th, 2024, a new backdoor discovered in the xz/liblzma library has raised alarms across the tech industry, especially among those relying on Secure Shell (SSH) servers for secure communication. This backdoor poses a significant threat by potentially allowing unauthorized access to SSH servers, compromising their security and integrity. 

Since this vulnerability was introduced in an upstream repository (i.e. liblzma), this represents a perfect example of the dangers of software supply chain risk. 

Let’s dig a bit deeper. 

Understanding the Vulnerability

xz is a lossless compression program and file format which incorporates the liblzma library for compression algorithms. It is widely used in various Unix-like operating systems for file compression and decompression. The backdoor in question was ingeniously inserted in a manner that it could escape detection during routine security audits, making it a particularly stealthy threat.

The vulnerability arises when the compromised version of xz/liblzma is used to compress or decompress files. Specifically, the backdoor can be triggered, providing attackers with a way to execute arbitrary code. The OpenSSH remote logon software uses compression extensively and as such it is directly affected by this supply chain attack, which means that attackers could potentially gain unauthorized access to the server, execute commands, or even escalate their privileges to gain complete control over the system.

How can you protect yourself from this very significant new supply chain attack?

Mitigation 

To protect against this vulnerability, system administrators and security professionals should take immediate action. The following steps are recommended:

1. Identify and Update Affected Systems: Determine if your systems are using the compromised versions of xz/liblzma.
   To check if your system is affected you can run the following bash script on your system (make sure to run it as the user able to access sshd):
   
   
   #!/bin/bash
# Copyright 2024 by Andres Freund and Codenotary (for extensions)

set_colors() {
    red=$(tput setaf 1)
    green=$(tput setaf 2)
    yellow=$(tput setaf 3)
    blue=$(tput setaf 4)
    magenta=$(tput setaf 5)
    cyan=$(tput setaf 6)
    white=$(tput setaf 7)
    bold=$(tput bold)
    uline=$(tput smul)
    blink=$(tput blink)
    rev=$(tput rev)
    reset=$(tput sgr0)
}

set_colors
set -euo pipefail

# Attempt to find sshd, but don't exit immediately if not found
sshd_path=$(which sshd 2>/dev/null || true)
if [ -z "$sshd_path" ]; then
    echo "${yellow}Warning: sshd is not installed or not in the PATH. Some checks may be skipped.${reset}"
    # Depending on your needs, you could exit here or continue with alternative checks
    # exit 1
else
    echo "${green}sshd found at ${sshd_path}.${reset}"
    # Find path to liblzma used by sshd
    path=$(ldd "$sshd_path" | grep liblzma | grep -o '/[^ ]*')
    if [ -z "$path" ]; then
        echo "${green}Probably not vulnerable, but you should check for updates anyway.${reset}"
    else
        # proceed with your checks
        echo "${blue}Proceeding with checks for ${path}.${reset}"
        if hexdump -ve '1/1 "%.2x"' "$path" | grep -q f30f1efa554889f54c89ce5389fb81e7000000804883ec28488954241848894c2410
        then
            echo "${rev}${red}Probably vulnerable !!!! Pls update your system immediately!!${reset}"
        else
            echo "${green}Probably not vulnerable, but make sure to update your distribution anyway${reset}"
        fi
    fi
fi


2. Monitor for Suspicious Activity: Implement or enhance monitoring on systems to detect any unusual activity that might indicate an exploitation attempt of this vulnerability. This includes monitoring for unexpected system behavior, unauthorized access attempts, or unusual outbound network traffic.
3. Incident Response Plan: Ensure that there is a robust incident response plan in place that includes procedures for dealing with compromised servers. Contact all your software providers and ask them to send you an SBOM of their software you are running. Store the SBOM in https://SBOM.sh and analyze it there for known vulnerabilities.
4. Finally, and most importantly, start to use a software supply chain protection platform like Codentory’s Trustcenter. With Trustcenter you get immediate notification if the vulnerability is present in your organization and what steps you need to take to mitigate it. Try out Trustcenter now at https://codenotary.com/products/trustcenter/ or in the Google Cloud marketplace https://console.cloud.google.com/marketplace/product/codenotary-public/trustcenter-enterprise?hl=en

Important: At Codenotary we immediately double-checked our infrastructure setup and the application deployment and nothing is affected by the xz vulnerability.