Op Goede Vrijdag liet Microsoft-ontwikkelaar Andres Freund een paasbom vallen. Terwijl hij een aantal onschuldig ogende prestatieproblemen op een Debian Linux-systeem oploste, stuitte hij op wat er is geweest beschreven als de “best uitgevoerde” supply chain-aanval ooit gezien.

Het zal grote gevolgen hebben voor IT-beveiligingsteams en voor de manier waarop zij in de toekomst met open source-risico's omgaan.

Wat is er gebeurd?

De aanval was ongelooflijk complex. Maar het lijkt een door de staat gesponsorde poging te zijn geweest om een ​​achterdeur in te voegen in een populaire open-sourcecomponent die bekend staat als xz Utils. Het hulpprogramma voor gegevenscompressie is te vinden in bijna alle Linux-systemen. De achterdeur en de bijbehorende kwetsbaarheid, CVE-2024-3094, zijn ontworpen om kwaadaardige code te injecteren in een OpenSSH-server (SSHD) die op de machine van een slachtoffer draait. Er zijn meer details hier, maar de tl;dr is dat het externe aanvallers die in het bezit zijn van een specifieke privésleutel in staat zou stellen om op afstand een gerichte machine te kapen.

Kortom, het is zo ernstig als het maar kan en daarom kreeg de CVE een CVSS-score van 10.0. Gelukkig werd de aanval opgemerkt voordat de kwaadaardige xz Utils-update werd samengevoegd met grote Linux-distributies. Op dat moment had het de dreigingsactor erachter op afstand toegang kunnen geven tot een onbekend aantal mondiale machines.

De verfijning en de geduldige planning die in deze aanval zijn gestoken, duiden op steun van de natiestaten. Dit kunnen we afleiden omdat:

  • De achterdeur zelf kent een complexe uitvoeringsketen die meerdere fasen omvat
  • De achterdeur werd geïntroduceerd via meerdere commits
  • Deze commits werden alleen opgenomen in de tarball-releases van de broncode en niet naar de openbare git-repository gepusht – om ze voor onderzoek verborgen te houden
  • De operatie was minstens twee jaar in de maak. Dat is het moment waarop de kwaadwillende 'ontwikkelaar' bekend als 'Jia Tan' zich bij het open-sourceproject voegde
  • Het lijkt erop dat de groep achter Jia Tan opzettelijk de oorspronkelijke beheerder, Lasse Collin, onder druk heeft gezet om Tan aan boord te halen. Waarschijnlijk neppersona's, waaronder 'Jigar Kumar' en 'Dennis Ens', voerden allemaal de druk op door Lasse te bombarderen met functieverzoeken en bugklachten

De open source-beveiligingsuitdaging

Het slechte nieuws is dat bekend is dat Jia Tan aan verschillende andere open-sourceprojecten heeft gewerkt. Het is onduidelijk of er al heimelijk kwaadaardige code in is geplaatst en wat de impact zou kunnen zijn.

Open source is hier zowel het probleem als de oplossing. De 'vele ogen'-benadering van softwareontwikkeling zou er in theorie voor moeten zorgen dat problemen op tijd worden opgemerkt. Maar zoals bij deze aanval te zien is, doen dreigingsactoren er alles aan om ongezien kwaadaardige code in projecten te sluipen.

De uitdaging voor beveiligingsteams en ontwikkelaars die open-sourcecomponenten gebruiken, zijn de intransitieve afhankelijkheden die ze vaak onbewust in code introduceren – zoals benadrukt door de Log4j-saga. Het verkrijgen van inzicht in dergelijke risico's is van cruciaal belang, aldus Jamie Scott, oprichter van productmanager bij Endor Labs.

“Als je één Maven-pakket vertrouwt, zijn er gemiddeld veertien extra afhankelijkheden die je impliciet vertrouwt”, vertelt hij aan ISMS.online. “Dit aantal is zelfs nog groter in bepaalde software-ecosystemen zoals npm, waar je gemiddeld 14 andere softwarecomponenten importeert voor iedereen die je vertrouwt. Deze vertrouwensrelatie wordt opgebouwd met alle beheerders van alle softwarecomponenten.”

Dus wat is het antwoord? Op één niveau moet er meer gedaan worden door overheden, grote softwarebedrijven die open source gebruiken, en de open source-gemeenschap zelf.

“De industrie en de open source-gemeenschap moeten nauwer samenwerken om het bredere cybersecurity-software-ecosysteem te beveiligen”, vertelt Cyberhaven CSO, Chris Hodson, aan ISMS.online. “De grenzen tussen commerciële en open source software zijn ondoorzichtig. Het is in ieders belang om het beter te doen.”

Scott van Endor Labs voegt eraan toe dat de industrie zou kunnen helpen door het ondertekenen van artefacten over te nemen.

“Het ondertekenen van artefacten biedt enige veerkracht tegen dit soort aanvallen door ervoor te zorgen dat alleen geautoriseerde pijpleidingen geldige, ondertekende artefacten kunnen produceren”, betoogt hij.

“Hoewel dit geen perfecte bescherming biedt, verhoogt het de kosten voor een tegenstander om kwaadaardige pakketten geadopteerd te krijgen aanzienlijk, en helpt het ook bij een effectieve respons op incidenten doordat hulpverleners het gebruik van het kwaadaardige pakket snel en nauwkeurig kunnen blokkeren zodra het is geïdentificeerd.”

Andere broodnodige initiatieven in de sector zijn onder meer de standaard adoptie van beveiligingsmetagegevens zoals software stuklijsten (SBOM's) en Supply Chain Levels for Software Artefacts (SLSA), die CISO's kunnen helpen de risico's in hun toeleveringsketens beter te begrijpen. Er is ook meer financiering voor organisaties als de OpenSSF, die op hun beurt belangrijke beveiligingsinitiatieven financiert.

Volgende stappen voor beveiligingsteams

Uiteindelijk is de sleutel voor CISO's en DevSecOps-teams het verkrijgen van inzicht in hun open source-code, met name intransitieve afhankelijkheden, aldus Hodson.

“Het is belangrijk voor CISO's om de keten van vertrouwen en onderlinge afhankelijkheden van een softwarebibliotheek en een uitvoerbaar bestand te waarderen. Xz Utils voelt op zichzelf aan als een softwarecomponent met een vrij laag risico, maar tegenstanders zullen proberen dergelijke software te exploiteren om hun doel te bereiken”, betoogt hij. “CISO's moeten een veel beter inzicht krijgen in hun toeleveringsketen – niet alleen de leveranciers die ze gebruiken voor commerciële software, maar ook de open source-componenten van hun applicaties en diensten. Om nog maar te zwijgen van die van hun derde partijen.”

SoSafe CSO, Andrew Rose, deelt deze takenlijst voor het beheren van risico's met ISMS.online:

  • Creëer een bibliotheek met goedgekeurde software en middelen om duidelijke vangrails voor ontwikkelaars te garanderen en niet-goedgekeurde code en software te beperken. Software moet worden gevalideerd en goedgekeurd, misschien van leveranciers die op risico zijn beoordeeld
  • Creëer nep-datameren voor testdoeleinden en implementeer netwerksegmentatie. Dit betekent dat alle ontwikkelaarsomgevingen, of plaatsen met ongecontroleerde builds, geen toegang mogen hebben tot echte gegevens, of productiesystemen en diensten
  • Gebruik alleen goedgekeurde, vrijgegeven builds in productie en controleer deze regelmatig om er zeker van te zijn dat verdachte activiteiten worden gecontroleerd
  • CISO's moeten verbonden blijven met ontwikkelaarsgemeenschappen om op de hoogte te blijven van kwetsbaarheden, achterdeurtjes en problemen zodra deze zich voordoen
  • Scan omgevingen regelmatig, zelfs nadat CISO's het huis hebben opgeruimd. Er moet een 'vee geen huisdier'-model worden toegepast om services of software te beheren, wat betekent dat er voortdurend moet worden beoordeeld en opnieuw moet worden opgebouwd om er zeker van te zijn dat de juiste goedgekeurde versies worden gebruikt

 

Scott van Endor Labs voegt de volgende diepgaande tips toe om de kans op uitbuiting te verkleinen in het geval dat een softwaretoeleveringsketen in gevaar komt:

  • Implementeer minimale privileges: In het geval van xz Utils zou een benadering met minimale privileges van de server- en containerconfiguratie geholpen hebben. Backdoor SSH-sleutels geven u toegang tot SSH wanneer SSH-services toegankelijk zijn. Stel SSH-poorten niet bloot aan internet
  • Creëer governancebeleid voor open source-gebruik: deze kunnen variëren van “Alle versies van open source-software vastzetten, zodat u niet altijd de nieuwste versie downloadt” tot “geen versies van open source-software gebruiken die minder dan 60 dagen oud zijn
  • Verwijder ongebruikte software om het risico van de toeleveringsketen te verminderen: Ongebruikte software kan onnodige opgeblazenheid in uw software veroorzaken en in de loop van de tijd een risico voor de toeleveringsketen introduceren. Het is slechts een kwestie van tijd voordat de volgende aanval van het xz Utils-type wordt ontdekt. Door nu meer voorzorgsmaatregelen te nemen, kunnen organisaties proactief veerkracht opbouwen en ervoor zorgen dat hun pad naar herstel sneller en minder traumatisch zal zijn.