xz backdoor: 5 Lessen
Ingenieurswetenschappen
CVE-2024–3094 — ook bekend als xz-backdoor of xz-trojan — is de meest zorgwekkende aanval op de softwareleveringsketen tot nu toe.
Een ontwikkelaar die zich Jia Tan (Github JiaT75) noemt, gebruikte sociale-engineeringtechnieken om het open-source Tukaani-project binnen te komen en verdiende het vertrouwen van de gemeenschap in de daaropvolgende jaren.
Jia verwierf uiteindelijk de onderhoudersstatus voor het XZ-Utils project.
Uiteindelijk gebruikte Jia zijn status om slimme obfuscatie in de broncode en binaire bestanden te implementeren om een backdoor te creëren in XZ-Utils versies 5.6.0 en 5.6.1. Als het onontdekt was gebleven tot de integratie met belangrijke distributies, zouden miljoenen Debian- en Red Hat-releases getroffen kunnen zijn.
Een goed geschreven tijdlijn van gebeurtenissen is hier gepubliceerd.
xz is de meest geavanceerde aanval op de softwareleveringsketen
Software supply chain-aanvallen omvatten het opnemen van kwaadaardige code of componenten op een niveau dieper dan de applicatie zelf. Deze aanval op de “leveringsketen” van softwarebouw helpt een voordeel te verkrijgen in distributie, aangezien meer dan één downstream-project dezelfde leveringsketen kan gebruiken.
In het verleden zijn compromissen gericht op veelgebruikte applicaties (bijv. MOVEit — CVE-2023–34362), een gedeeld component (bijv. log4j) of een onderdeel van de gebouwde omgeving (bijv. SolarWinds, Codecov).
Aan de andere kant begint de xz-backdoor eerst met het compromitteren van de “onderhouder” lijst van het project. Dit is gedaan door een specifieke identiteit te creëren voor het doel — JiaT75 (geen bewijs van de bijdrages van deze gebruiker voor 2021), het verdienen van het vertrouwen van de projectmanager in de loop van de tijd en uiteindelijk het toepassen van sociale engineering om de projectmanager onder druk te zetten om die gebruiker als onderhouder te accepteren.
Eenmaal in een vertrouwde rol is het alleen maar menselijk dat codebeoordelingen een vertrouwensbias hebben en zelfs eenvoudige obfuscatie een lange weg kan gaan.
De technische kant van het openen van de backdoor is ook slim. Het omvat het gebruiken van gebroken binaire bestanden om codebeoordeling te ontwijken, het laden van die bestanden als scripts met behulp van eenvoudige maar gescheiden opdrachtvolgordes, en het splitsen van de totale backdoor-toegang over veel verschillende wijzigingen. In elk aanzienlijk, snel bewegend of slecht geïndividualiseerd project kunnen deze gemist worden tijdens codebeoordelingen door een meerderheid van teams—om nog maar te zwijgen van de situatie waarin de indiener al een 'vertrouwde' onderhouder is.
Door het bovenstaande te combineren, kunnen we ons geen andere softwareleveringsketen voorstellen met zoveel lagen van voorbereiding voordat de exploit.
Kan nu of binnenkort weer gebeuren
Veel delen van de xz-backdoor werden geïmplementeerd vanwege de vertrouwde aard van de onderhoudsmedewerker, die in de loop der jaren sociaal was geengineerd.
Met meer dan 50 miljoen actieve open-sourceprojecten blijft de kans groot dat 'vertrouwde' onderhoudsmedewerkers wachten op het juiste moment om een kwaadaardige wijziging in te voeren of het al hebben gedaan maar onopgemerkt zijn gebleven.
Dit verschilt van log4shell (CVE-2021–44228) of equivalente kwetsbaarheid, waar de ontwikkelaars zich geen specifieke exploit konden voorstellen in de eerste implementatie. Daarom kunnen onderzoekers na ontdekking nog steeds snel specifieke kwetsbaarheden onderzoeken en aan het licht brengen.
In tegenstelling tot een 'vertrouwde' onderhoudsmedewerker die een bekende exploit introduceert, zou dat opzettelijk zijn en daarom zouden ze proberen de wijzigingen zoveel mogelijk te verdoezelen. Om deze reden was de eerste reactie van Tukaani's bouwer, Lasse Collin, —
Ik zou zelfs van oudere versies van xz wantrouwig zijn, totdat het tegendeel bewezen is.
Geen van de bekende beveiligingshulpmiddelen zou xz opmerken.
Hoewel Interlynk een leverancier van beveiligingstools is, hebben we geen duidelijk bewijs gezien van waarom een specifieke tool of technologie zo'n verandering van tevoren zou opmerken.
OpenSSF suggereerde eerst dat de OpenSSF Scorecard laag zou scoren voor xz utils-projecten, wat een ware verklaring is.
Echter, specifieke controles zouden altijd worden genegeerd ten gunste van de reputatie van projecten voor ongelooflijk nuttige en betrouwbare compressiehulpmiddelen. Ik kan me niet voorstellen welke SAST/DAST-patronen problematisch zullen zijn met de aanpak, zeker niet als je bedenkt dat het betreffende script vooraf is omgezet naar een blob. Een wijziging in het runtime-gedrag kan wat ruis genereren, maar onderdeel zijn van `sshd` zal waarschijnlijk niet in elke situatie wantrouwen opwekken.
We begrijpen de behoefte van de beveiligingsleveranciergemeenschap om hun rol in dit gesprek opnieuw te bevestigen, maar we geloven dat het echte gesprek binnen open-source gemeenschappen moet plaatsvinden en door tools kan worden ondersteund indien nodig.
De kern van deze uitdaging is dat weten of iemand een Manchurian Candidate is een complex probleem is, omdat het bewijs zich in hun hoofd bevindt.
SBOM zal een backdoor niet detecteren
Interlynk beveiligt de softwareleveringsketen door de SBOM-stroom te automatiseren. In de xz-backdoor zou een SBOM helpen identificeren wanneer en wat er veranderd is door de leveringsketen, welke versie elke component heeft, en de integriteit van componenten (inclusief testgegevens).
Daarnaast creëert Interlynk een risicoscore op basis van de OpenSSF Scorecard zelf, met de leeftijd en het gebruik van het pakket, het aantal onderhouders, en enkele andere signalen. De specifieke versie zou laag begonnen zijn (5.4) en in waarde zijn gegroeid in de loop van de tijd (6.8 tegen het einde van mei).
Echter, deze informatie zou beleidsinbreuken activeren als deze is geconfigureerd rond risico, maar zal waarschijnlijk genegeerd worden door productbeveiligingsteams, gezien het verworven vertrouwen van het project.
Dus, we claimen niet dat een bestaand SBOM-programma (of een andere beveiligingstool) het integreren van xz-backdoor zou hebben opgemerkt.
Zoals gesuggereerd, is SBOM niet een zilveren kogel voor alle risico's van de softwareleveringsketen. Het speelt echter een essentiële rol in het waarborgen van de integriteit en het organiseren van post-remediatie-inspanningen.
Maar SBOM is een oplossing voor remediation
Stel je voor dat deze xz-backdoor eind juni was ontdekt in plaats van eind maart. Tegen die tijd zou het waarschijnlijk in meerdere Linux-distributies zijn binnengekomen en op miljoenen servers zijn geïnstalleerd.
Alle productbeveiligings- en DevOps-teams kennen het gevoel van wat er vervolgens komt — vragen beantwoorden zoals:
Zijn we geïnfecteerd?
Welke producten en versies zijn geïnfecteerd?
Hoe patchen we ze?
Hoe vragen we onze leveranciers of ze geïnfecteerd zijn?
Wat is met onze leveranciers?
Hoe bewijzen we aan onze compliance-teams dat dit wordt bijgehouden?
Dit is niet de eerste keer dat deze oefening plaatsvindt, en het zal niet de laatste zijn.
Echter, met SBOM had alle tracking in één interface kunnen worden gedaan.
Alle activa met SBOM zijn gekoppeld aan de specifieke versie van de software met de specifieke versie van de componenten.
Een upgradeplan zou SBOM met zich meebrengen en de componentversie tonen die naar de fixe versie gaat.
Een bijbehorende VEX zou upstream en downstream partners in staat stellen dit in realtime te communiceren.
Dit gaat niet stoppen, maar SBOM is de bouwsteen voor het coördineren van inspanningen om dit te verlichten.
Wij zijn hier om een gezonde, veilige en geweldige open-sourcegemeenschap om ons heen te ondersteunen.
Neem contact met ons op via hello@interlynk.io voor een gesprek.