Wat sekuriteitspanne kan leer uit die xz Utils-aanval

Op Goeie Vrydag het Microsoft-ontwikkelaar Andres Freund 'n Paasfees-bom laat val. Terwyl hy 'n paar onskadelike prestasieprobleme op 'n Debian Linux-stelsel opgespoor het, het hy gestruikel oor wat was beskryf as die "beste uitgevoer" voorsieningskettingaanval wat nog ooit gesien is.

Dit sal groot implikasies hê vir IT-sekuriteitspanne, en hoe hulle oopbronrisiko vorentoe bestuur.

Wat het gebeur?

Die aanval was ongelooflik kompleks. Maar dit blyk 'n staatsgeborgde poging te wees om 'n agterdeur in 'n gewilde oopbron-komponent bekend as xz Utils in te voeg. Die datakompressiehulpmiddel kan in byna alle Linux-stelsels gevind word. Die agterdeur en gepaardgaande kwesbaarheid, CVE-2024-3094, is ontwerp om kwaadwillige kode in 'n OpenSSH-bediener (SSHD) in te spuit wat op 'n slagoffer se masjien loop. Daar is meer besonderhede na hierdie skakel, maar die tl;dr is dat dit afstandaanvallers in besit van 'n spesifieke private sleutel in staat sal stel om 'n geteikende masjien op 'n afstand te kaap.

Kortom, dit is omtrent so ernstig as wat dit raak, en daarom het die CVE 'n CVSS-telling van 10.0 gekry. Gelukkig is die aanval opgemerk voordat die kwaadwillige xz Utils-opdatering in groot Linux-verspreidings saamgevoeg is. Op daardie stadium kon dit die bedreigingsakteur daaragter afgeleë toegang tot 'n onbekende aantal wêreldwye masjiene gegee het.

Die gesofistikeerdheid en geduldige beplanning wat in hierdie aanval ingegaan het, dui op nasie-staatsteun. Ons kan dit aflei omdat:

• Die agterdeur self het 'n komplekse uitvoeringsketting wat uit verskeie stadiums bestaan
• Die agterdeur is ingestel oor verskeie commits
• Hierdie commits is slegs by bronkode tarball-vrystellings ingesluit eerder as om na die publieke git-bewaarplek gedruk te word - om dit weggesteek te hou van ondersoek
• Die operasie was ten minste twee jaar in wording. Dit is toe dat die kwaadwillige 'ontwikkelaar' bekend as 'Jia Tan' by die oopbronprojek aangesluit het
• Dit blyk dat die groep agter Jia Tan doelbewus druk op die oorspronklike onderhouder, Lasse Collin, uitgeoefen het om Tan aan boord te bring. Waarskynlike vals personas, insluitend 'Jigar Kumar' en 'Dennis Ens' het almal druk opgehoop deur Lasse te bombardeer met kenmerkversoeke en foutklagtes

Die Open Source Security Challenge

Die slegte nuus is dat dit bekend is dat Jia Tan aan verskeie ander oopbronprojekte gewerk het. Dit is onduidelik of kwaadwillige kode reeds heimlik hierby ingevoeg is en wat die impak kan wees.

Oopbron is beide die probleem en die oplossing hier. Sy “baie oë”-benadering tot sagteware-ontwikkeling behoort in teorie te beteken dat probleme betyds raakgesien word. Maar soos gesien met hierdie aanval, doen bedreigingsakteurs baie moeite om kwaadwillige kode ongesiens in projekte in te sluip.

Die uitdaging vir sekuriteitspanne en ontwikkelaars wat oopbronkomponente gebruik, is die onoorganklike afhanklikhede wat hulle dikwels onbewustelik in kode inbring – soos uitgelig deur die Log4j-sage. Volgens Jamie Scott, stigtersprodukbestuurder by Endor Labs, is dit van kritieke belang om sigbaarheid in sulke risiko's te kry.

"Wanneer jy een Maven-pakket vertrou, is daar gemiddeld 'n bykomende 14 afhanklikhede wat jy implisiet vertrou," sê hy aan ISMS.online. “Hierdie getal is selfs groter in sekere sagteware-ekosisteme soos npm, waar jy gemiddeld 77 ander sagtewarekomponente invoer vir almal wat jy vertrou. Hierdie vertrouensverhouding word met alle instandhouers van alle sagtewarekomponente gevestig.”

So wat is die antwoord? Op een vlak moet daar meer gedoen word deur regerings, groot sagtewaremaatskappye wat oopbron gebruik, en die oopbrongemeenskap self.

"Nywerheid en die oopbrongemeenskap moet nouer saamwerk om die breër kuberveiligheidsagteware-ekosisteem te beveilig," sê Cyberhaven CSO, Chris Hodson, aan ISMS.online. “Die lyne tussen kommersiële en oopbronsagteware is ondeursigtig. Dit is in almal se beste belang om beter te doen.”

Endor Labs se Scott voeg by dat die industrie kan help deur artefakondertekening aan te neem.

"Artefakondertekening bied 'n mate van veerkragtigheid aan hierdie tipe aanval deur te verseker dat slegs gemagtigde pyplyne geldige, getekende artefakte kan produseer," voer hy aan.

"Alhoewel dit nie perfekte beskerming sal bied nie, verhoog dit die koste vir 'n teenstander aansienlik om kwaadwillige pakkette aangeneem te kry, en help ook met effektiewe voorvalreaksie deur reageerders toe te laat om die gebruik van die kwaadwillige pakket vinnig en akkuraat te blokkeer sodra dit geïdentifiseer is."

Ander broodnodige industrie-inisiatiewe sluit in die aanneming by verstek van sekuriteitsmetadata soos sagteware stukke materiaal (SBOM's) en Supply Chain Levels for Software Artifacts (SLSA), wat CISO's kan help om risiko's in hul voorsieningskettings beter te verstaan. Daar is ook meer befondsing vir organisasies soos die OpenSSF, wat op sy beurt belangrike sekuriteitsinisiatiewe finansier.

Volgende stappe vir sekuriteitspanne

Uiteindelik, vir CISO's en DevSecOps-spanne, is die sleutel om sigbaarheid te kry in hul oopbronkode, veral onoorganklike afhanklikhede, volgens Hodson.

“Dit is belangrik vir CISO's om die ketting van vertroue en interafhanklikhede van 'n sagtewarebiblioteek en 'n uitvoerbare program te waardeer. Xz Utils, in isolasie, voel soos 'n redelik lae-risiko sagteware komponent, maar teëstanders sal probeer om sulke sagteware te ontgin om op te tree op hul doel,” voer hy aan. “CISO's moet 'n baie beter begrip van hul voorsieningsketting kry – nie net die verskaffers wat hulle vir kommersiële sagteware gebruik nie, maar die oopbronkomponente oor hul toepassings en dienste. Om nie eers te praat van dié van hul derde partye nie.”

SoSafe CSO, Andrew Rose, deel hierdie doenlys vir die bestuur van risiko, met ISMS.online:

• Skep 'n biblioteek van goedgekeurde sagteware en bates om duidelike veiligheidsrelings vir ontwikkelaars te verseker, en beperk nie-goedgekeurde kode en sagteware. Sagteware moet bekragtig en goedgekeur word, miskien van risiko-geasseerde verskaffers
• Skep vals data-mere vir toetsdoeleindes en implementeer netwerksegmentering. Dit beteken dat alle ontwikkelaaromgewings, of plekke met onbeheerde bouwerk, geen toegang tot regte data, of produksiestelsels en dienste moet hê nie
• Gebruik slegs goedgekeurde, vrygestelde weergawes in produksie en hersien dit gereeld om te verseker dat enige verdagte aktiwiteit gemonitor word
• CISO's moet verbind bly met ontwikkelaargemeenskappe om te leer van kwesbaarhede, agterdeure en kwessies soos dit opduik
• Skandeer gereeld omgewings, selfs nadat CISO's die huis skoongemaak het. 'n 'Beeste nie troeteldiere'-model moet toegepas word om dienste of sagteware te bestuur, wat beteken voortdurende assessering en herbou om seker te maak dat die regte goedgekeurde weergawes gebruik word

Endor Labs se Scott voeg die volgende verdediging-in-diepte wenke by om die waarskynlikheid van uitbuiting te verminder indien 'n sagteware-voorsieningsketting in die gedrang kom:

• Implementeer minste voorreg: In die geval van xz Utils, sou 'n minste voorreg-benadering tot bediener- en houerkonfigurasie gehelp het. Backdoor SSH-sleutels laat jou toe om toegang tot SSH te kry wanneer SSH-dienste toeganklik is. Moet asseblief nie SSH-poorte aan die internet blootstel nie
• Skep bestuursbeleide vir oopbrongebruik: Dit kan wissel van “Speld alle weergawes van oopbronsagteware wat gebruik word vas sodat jy nie altyd die nuutste weergawe aflaai nie” tot “moenie weergawes van oopbronsagteware gebruik wat minder as 60 dae oud is nie
• Verwyder ongebruikte sagteware om voorsieningskettingrisiko te verminder: Ongebruikte sagteware kan onnodige opblaas in jou sagteware skep en voorsieningskettingrisiko mettertyd inbring. Dit is net 'n kwessie van tyd voor die volgende xz Utils-tipe aanval ontdek word. Deur nou meer voorsorgmaatreëls te tref, kan organisasies proaktief veerkragtigheid bou en verseker dat hul pad na herstel vinniger en minder traumaties sal wees.