Hvad sikkerhedsteams kan lære af xz Utils Attack

Langfredag ​​kastede Microsoft-udvikler Andres Freund en påskebombe. Mens han fejlfindede nogle uskyldigt udseende præstationsproblemer på et Debian Linux-system, snublede han over, hvad der har været beskrevet som det "bedst udførte" forsyningskædeangreb nogensinde set.

Det vil have store konsekvenser for it-sikkerhedsteams, og hvordan de styrer open source-risici fremover.

Hvad skete der?

Angrebet var utroligt komplekst. Men det ser ud til at have været et statssponsoreret forsøg på at indsætte en bagdør i en populær open source-komponent kendt som xz Utils. Datakomprimeringsværktøjet kan findes i næsten alle Linux-systemer. Bagdøren og tilhørende sårbarhed, CVE-2024-3094, er designet til at injicere ondsindet kode i en OpenSSH-server (SSHD), der kører på et offers maskine. Der er flere detaljer link., men tl;dr er, at det ville gøre det muligt for fjernangribere i besiddelse af en specifik privat nøgle at fjernkapre en målrettet maskine.

Kort sagt, det er omtrent lige så alvorligt, som det kan blive, hvorfor CVE'en fik en CVSS-score på 10.0. Heldigvis blev angrebet opdaget, før den ondsindede xz Utils-opdatering blev slået sammen i større Linux-distributioner. På det tidspunkt kunne det have givet trusselsaktøren bag sig fjernadgang til et ukendt antal globale maskiner.

Den sofistikerede og tålmodige planlægning, der gik ind i dette angreb, peger på nationalstatens opbakning. Vi kan udlede dette fordi:

• Selve bagdøren har en kompleks udførelseskæde, der omfatter flere faser
• Bagdøren blev introduceret over flere commits
• Disse commits blev kun inkluderet i kildekode tarball-udgivelser i stedet for at blive skubbet til det offentlige git-lager – for at holde dem skjult fra granskning
• Operationen var mindst to år undervejs. Det var da den ondsindede 'udvikler' kendt som 'Jia Tan' sluttede sig til open source-projektet
• Det ser ud til, at gruppen bag Jia Tan bevidst pressede den oprindelige vedligeholder, Lasse Collin, til at bringe Tan om bord. Sandsynlige falske personligheder, herunder 'Jigar Kumar' og 'Dennis Ens', blev alle presset ved at bombardere Lasse med funktionsanmodninger og fejlklager

Open Source-sikkerhedsudfordringen

Den dårlige nyhed er, at Jia Tan er kendt for at have arbejdet på flere andre open source-projekter. Det er uklart, om ondsindet kode allerede er blevet indsat skjult i disse, og hvad virkningen kan være.

Open source er både problemet og løsningen her. Dens "mange øjne" tilgang til softwareudvikling skulle i teorien betyde, at problemer opdages i tide. Men som det ses med dette angreb, går trusselsaktører meget langt for at snige ondsindet kode uset ind i projekter.

Udfordringen for sikkerhedsteams og udviklere, der bruger open source-komponenter, er de intransitive afhængigheder, som de ofte uforvarende introducerer i kode – som fremhævet af Log4j saga. At få synlighed i en sådan risiko er afgørende, ifølge Jamie Scott, stiftende produktchef hos Endor Labs.

"Når du stoler på en Maven-pakke, er der i gennemsnit yderligere 14 afhængigheder, du implicit stoler på som et resultat," siger han til ISMS.online. "Dette tal er endnu større i visse software-økosystemer såsom npm, hvor du i gennemsnit importerer 77 andre softwarekomponenter til alle, du stoler på. Dette tillidsforhold er etableret med alle vedligeholdere af alle softwarekomponenter."

Så hvad er svaret? På et niveau skal der gøres mere af regeringer, store softwarevirksomheder, der bruger open source, og open source-samfundet selv.

"Industrien og open source-fællesskabet skal arbejde tættere sammen for at sikre det bredere økosystem for cybersikkerhedssoftware," siger Cyberhaven CSO, Chris Hodson, til ISMS.online. "Grænserne mellem kommerciel og open source-software er uigennemskuelige. Det er i alles interesse at gøre det bedre.”

Endor Labs' Scott tilføjer, at industrien kunne hjælpe ved at vedtage artefaktsignering.

"Artefaktsignering giver en vis modstandsdygtighed over for denne type angreb ved at sikre, at kun autoriserede pipelines kan producere gyldige, signerede artefakter," argumenterer han.

"Selvom dette ikke giver perfekt beskyttelse, øger det betydeligt omkostningerne for en modstander at få ondsindede pakker vedtaget, og hjælper også med en effektiv hændelsesrespons ved at give respondere mulighed for hurtigt og præcist at blokere brugen af ​​den ondsindede pakke, når den er identificeret."

Andre tiltrængte industriinitiativer inkluderer standardindførelse af sikkerhedsmetadata som softwarestyklister (SBOM'er) og Supply Chain Levels for Software Artifacts (SLSA), som kan hjælpe CISO'er til bedre at forstå risikoen i deres forsyningskæder. Der er også flere midler til organisationer som OpenSSF, som igen finansierer vigtige sikkerhedsinitiativer.

Næste trin for sikkerhedsteams

I sidste ende, for CISO'er og DevSecOps-hold, er nøglen at få synlighed i deres open source-kode, især intransitive afhængigheder, ifølge Hodson.

"Det er vigtigt for CISO'er at værdsætte kæden af ​​tillid og indbyrdes afhængighed af et softwarebibliotek og en eksekverbar. Xz Utils, isoleret set, føles som en softwarekomponent med ret lav risiko, men modstandere vil se efter at udnytte sådan software til at handle på deres mål,« argumenterer han. "CISO'er skal opnå en meget bedre forståelse af deres forsyningskæde – ikke kun de leverandører, de bruger til kommerciel software, men open source-komponenterne på tværs af deres applikationer og tjenester. For ikke at nævne dem fra deres tredjeparter."

SoSafe CSO, Andrew Rose, deler denne opgaveliste til styring af risiko med ISMS.online:

• Opret et bibliotek med godkendt software og aktiver for at sikre tydelige autoværn for udviklere og begrænse ikke-godkendt kode og software. Software bør være valideret og godkendt, måske fra risikovurderede leverandører
• Opret falske datasøer til testformål og implementer netværkssegmentering. Dette betyder, at alle udviklermiljøer eller steder med ukontrollerede builds ikke bør have adgang til rigtige data eller produktionssystemer og tjenester
• Brug kun godkendte, frigivne builds i produktionen, og gennemgå disse regelmæssigt for at sikre, at enhver mistænkelig aktivitet overvåges
• CISO'er bør forblive forbundet til udviklerfællesskaber for at lære om sårbarheder, bagdøre og problemer, efterhånden som de opstår
• Scan jævnligt miljøer, selv efter at CISO'er har renset huset. En "kvæg ikke kæledyr"-model bør anvendes til at administrere tjenester eller software, hvilket betyder løbende vurdering og genopbygning for at sikre, at de rigtige godkendte versioner bliver brugt

Endor Labs' Scott tilføjer følgende dybdeforsvarsråd til at reducere sandsynligheden for udnyttelse i tilfælde af, at en softwareforsyningskæde kompromitteres:

• Implementer mindste privilegier: I tilfælde af xz Utils ville en mindste privilegeret tilgang til server- og containerkonfiguration have hjulpet. Bagdørs SSH-nøgler giver dig adgang til SSH, når SSH-tjenester er tilgængelige. Undlad venligst at udsætte SSH-porte for internettet
• Opret styringspolitikker for open source-brug: Disse kan variere fra "Fastgør alle versioner af open source-software, der bruges, så du ikke altid downloader den nyeste version" til "brug ikke versioner af open source-software, der er mindre end 60 dage gamle
• Fjern ubrugt software for at reducere risikoen for forsyningskæden: Ubrugt software kan skabe unødvendigt oppustethed i din software og introducere forsyningskæderisikoen over tid. Det er kun et spørgsmål om tid, før det næste xz Utils-angreb bliver opdaget. Ved at tage flere forholdsregler nu, kan organisationer proaktivt opbygge modstandskraft og sikre, at deres vej til bedring bliver hurtigere og mindre traumatisk.