
Det hele startet da Andres Freund, en hovedprogramvareingeniør fra Microsoft, ble nysgjerrig på hvorfor SSH ekstern sikkerhetskode i Debian Linux beta kjørte sakte. Freund gravde litt og oppdaget problemet: En sjefsprogrammerer og vedlikeholder av xz-datakomprimeringsbiblioteket, Jia Tan, hadde satt en bakdør i koden. Dens mening? For å gjøre det mulig for angripere å ta over Linux-systemer.
Også: Linux kan være det beste alternativet for å øke sikkerheten for din stasjonære datamaskin
Nylig har det blitt alt for vanlig for ondsinnede hackere å sette inn dårlig kode i programvare. Noen åpen kildekodelagre, som den populære JavaScript-pakkebehandleren, Node Package Manager (npm) og det like populære Python-programvarelageret Python Package Index (PyPI), har blitt beryktet for å være vert for kryptomining og hacking av skadelig programvare.
Det finnes også åpen kildekode-programvare, slik som SapphireStealer, som prøver å stjele bruker-IDer, passord og andre hemmeligheter. Selv om det absolutt har vært mye dårlig kode skrevet i Linux og dets nært beslektede verktøy, har ingen noen gang gjemt skadevare i den – før nå.
Før du blir for spent, legg merke til dette: Den korrupte xz-koden dukket ikke opp i noen produksjons-Linux-distroer. Hvis du jobbet med Fedora, Debian, openSUSE, Ubuntu eller andre beta-distribusjoner med blødende kant, hadde du noe å bekymre deg for. Ellers bør du være tydelig.
Men, gjør ingen feil: Linux unngikk en kule. Hadde dette nådd Linux-systemene vi alle bruker hver dag – uansett om du noen gang er klar over det eller ikke – ville vi vært i en verden full av vondt.
Ironisk nok, mens folk bruker xz-rotet som en unnskyldning for å piske åpen kildekode, er sannheten at angrepet mislyktes på grunn av åpen kildekode. Som Mark Atwood, Amazons hovedingeniør for programkontoret for åpen kildekode, bemerket: “Angrepet mislyktes fordi det var åpen kildekode. Måten dette angrepet fungerer for ikke-åpen kildekode er at angriperen bruker to år på å få en agent ansatt av en kontraktsleverandør av programvareutvikling, de sniker det inn, [og] ingen finner ut av det."
Også: Vurderer du å bytte til Linux? 10 ting du trenger å vite
Hvordan kan han si det? Fordi det er sannheten. For eksempel vet vi fortsatt ikke nøyaktig hvordan Microsoft tillot en kinesisk hackergruppe å bryte seg inn i Microsoft Online Exchange i fjor. Takket være Freund vet vi mye om hvordan xz-hacket ble oppnådd. Som Dimitri Stiliadis, Endor Labs CTO og medgründer, påpekte: “Vi var heldige at angrepet skjedde mot åpen kildekode-programvare som alle kan se på og forstå. Hvis det samme angrepet var mot en lukket kildekomponent, hvordan skulle vi i det hele tatt vite det?"
Amen.
Det vi ennå ikke vet er hvem som sto bak angrepet – eller hvorfor. Det er mange spekulasjoner om at det var en annen kinesisk hackergruppe; men på slutten av dagen sitter vi igjen med utdannede gjetninger.
For eksempel, i stedet for internasjonal politikk som står bak skadevare, kunne det ha vært et spesielt forseggjort forsøk på å plante kryptogruvearbeidere inn i høydrevne Linux-systemer. Med nåværende Bitcoin-verdier som svever rundt $65 000 per mynt, er grådighet et plausibelt motiv.
Vi vet at den som sto bak navnet Jia Tan tok mye tid og problemer med å plante skadevare. Tan begynte sitt mørke arbeid i 2021. Han eller hun, ved hjelp av noen sokkedukker, tok gradvis kontroll over xz-prosjektet. Tan og kollegene hans begynte deretter å presse på for at det nye bakdørsinfiserte programmet raskt skulle spores inn i Linux-distros.
Det er på dette punktet at Freunds graving i koden avdekket handlingen. I dag har Lasse Collin, den opprinnelige XZ-vedlikeholderen, tatt tilbake kontrollen over prosjektet og renser koden.
Også: De beste Linux-distroene for nybegynnere: Eksperttestet
Det har også vært spekulasjoner om at Tan og selskapet allerede hadde plassert skadelig programvare i tidligere xz-versjoner. Det ser ikke ut til å være noe med dette.
Andre er bekymret for at xz bare var toppen av isfjellet, og at det er mange andre open source-malware-programmer som skjuler seg i Linux. Men, som Eric S. Raymond, medgründer av åpen kildekode, observerte: “Det høres klokt og forsiktig ut å anta at for enhver oppdaget utnyttelse må det være et stort antall uoppdagede. Men vi vet faktisk ikke det, og selv om det var sant, ville det ikke føre til konkrete råd."
Så, hva kan vi gjøre med det? Mange!
Før denne felledør-utstyrte skadevare ble oppdaget, hadde Open Source Security Foundation (OpenSSF) foreslått at vi vedtar retningslinjer for sikker og ansvarlig bruk av åpen kildekode.
I kjølvannet, Dan Lorenc, medgründer og administrerende direktør for leverandørkjedeselskapet Chainguard for åpen kildekode, foreslo at vi skulle reflektere over hullene dette angrepet har dukket opp og bygge opp et mer dyptgående forsvar over hele forsyningskjeden med åpen kildekode: “Vedvarende trusler forsvinner ikke, og vi kan ikke på magisk vis stoppe dem, men vi kan fortsette å heve listen og gjøre dem hardere.”
Også: 5 tips for å sikre SSH på din Linux-server eller skrivebord
Lorenc har rett. Som han også sa, “Vi var utrolig heldige.”
Åpen kildekode, i sin natur, er potensielt sikrere enn proprietære metoder. Men det er bare sikrere hvis vi tar en lang, grundig titt på koden vi bruker og sørger for at den virkelig er trygg. Ideen om at koden er trygg bare fordi den er åpen, er magisk tenkning på sitt verste. Å ønske vil ikke gjøre åpen kildekode eller Linux sikkert; bare hardt arbeid vil gjøre det.