Mitä turvallisuustiimit voivat oppia xz Utils -hyökkäyksestä

Pitkäperjantaina Microsoftin kehittäjä Andres Freund pudotti pääsiäispommin. Kun hän suoritti vianetsintään joitakin harmitonta näköisiä suorituskykyongelmia Debian Linux -järjestelmässä, hän törmäsi siihen, mikä on ollut on kuvattu "paras toteutettu" toimitusketjuhyökkäys, joka on koskaan nähty.

Sillä on merkittäviä vaikutuksia IT-tietoturvatiimeihin ja siihen, miten he hallitsevat avoimen lähdekoodin riskejä jatkossa.

Mitä tapahtui?

Hyökkäys oli uskomattoman monimutkainen. Mutta se näyttää olleen valtion tukema yritys lisätä takaovi suosittuun avoimen lähdekoodin komponenttiin, joka tunnetaan nimellä xz Utils. Tietojen pakkausapuohjelma löytyy melkein kaikista Linux-järjestelmistä. Takaovi ja siihen liittyvä haavoittuvuus, CVE-2024-3094, on suunniteltu syöttämään haitallista koodia OpenSSH-palvelimeen (SSHD), joka toimii uhrin koneessa. Yksityiskohtia on enemmän tätä, mutta tl;dr on, että sen avulla etähyökkääjät, joilla on hallussaan tietty yksityinen avain, voivat kaapata kohteena olevan koneen etänä.

Lyhyesti sanottuna se on suunnilleen niin vakava kuin se voi olla, minkä vuoksi CVE:lle annettiin CVSS-pisteet 10.0. Onneksi hyökkäys havaittiin ennen kuin haitallinen xz Utils -päivitys yhdistettiin suuriin Linux-jakeluihin. Siinä vaiheessa se olisi voinut antaa takanaan olevalle uhkatekijälle etäyhteyden tuntemattomaan määrään maailmanlaajuisia koneita.

Tässä hyökkäyksessä käytetty hienostuneisuus ja kärsivällinen suunnittelu viittaa kansallisvaltion tukeen. Voimme päätellä tämän, koska:

• Itse takaovella on monimutkainen suoritusketju, joka koostuu useista vaiheista
• Takaovi otettiin käyttöön useiden sitoumusten aikana
• Nämä sitoumukset sisällytettiin vain lähdekoodin tarball-julkaisuihin sen sijaan, että ne siirrettiin julkiseen git-tietovarastoon – jotta ne pysyisivät piilossa valvonnalta
• Toimintaa suunniteltiin vähintään kaksi vuotta. Silloin ilkeä "kehittäjä" nimeltä "Jia Tan" liittyi avoimen lähdekoodin projektiin
• Näyttää siltä, ​​että Jia Tanin takana oleva ryhmä painosti tarkoituksella alkuperäistä ylläpitäjää, Lasse Collinia, ottamaan Tan mukaan. Todennäköiset väärennetyt persoonat, mukaan lukien "Jigar Kumar" ja "Dennis Ens", kasasivat painetta pommittamalla Lasselle ominaisuuspyyntöjä ja virhevalituksia

Open Source Security Challenge

Huono uutinen on, että Jia Tanin tiedetään työskennelleen useissa muissa avoimen lähdekoodin projekteissa. On epäselvää, onko näihin jo lisätty haitallista koodia piilossa ja mikä vaikutus sillä voi olla.

Avoin lähdekoodi on tässä sekä ongelma että ratkaisu. Sen "monen silmän" lähestymistapa ohjelmistokehitykseen tarkoittaa teoriassa sitä, että ongelmat havaitaan ajoissa. Mutta kuten tästä hyökkäyksestä nähdään, uhkatoimijat tekevät kaikkensa livahtaakseen haitallista koodia hankkeisiin.

Avoimen lähdekoodin komponentteja käyttävien tietoturvatiimien ja kehittäjien haasteena ovat intransitiiviset riippuvuudet, joita he usein tahattomasti lisäävät koodiin – kuten Log4j saaga. Endor Labsin perustavan tuotepäällikön Jamie Scottin mukaan tällaisen riskin näkyvyyden saaminen on tärkeää.

"Kun luotat yhteen Maven-pakettiin, tuloksena on 14 lisäriippuvuutta, joihin luotat implisiittisesti", hän kertoo ISMS.online-sivustolle. "Tämä luku on vielä suurempi tietyissä ohjelmistoekosysteemeissä, kuten npm, jonne tuot keskimäärin 77 muuta ohjelmistokomponenttia kaikille luotetuille. Tämä luottamussuhde on perustettu kaikkien ohjelmistokomponenttien ylläpitäjien kanssa."

Joten mikä on vastaus? Yhdellä tasolla hallitusten, suurten avointa lähdekoodia käyttävien ohjelmistoyritysten ja itse avoimen lähdekoodin yhteisön on tehtävä enemmän.

"Teollisuuden ja avoimen lähdekoodin yhteisön on tehtävä tiiviimpää yhteistyötä turvatakseen laajemman kyberturvallisuusohjelmistoekosysteemin", Cyberhavenin CSO, Chris Hodson, kertoo ISMS.online-sivustolle. ”Raja kaupallisten ja avoimen lähdekoodin ohjelmistojen välillä on läpinäkymätön. On kaikkien etujen mukaista tehdä paremmin."

Endor Labsin Scott lisää, että teollisuus voisi auttaa ottamalla käyttöön artefaktien allekirjoittamisen.

"Artefaktien allekirjoittaminen tarjoaa jonkin verran joustavuutta tämäntyyppisille hyökkäyksille varmistamalla, että vain valtuutetut putkistot voivat tuottaa kelvollisia, allekirjoitettuja esineitä", hän väittää.

"Vaikka tämä ei tarjoa täydellistä suojaa, se nostaa huomattavasti kustannuksia, joita vastustaja saa käyttöönsä haitalliset paketit, ja auttaa myös tehokkaasti reagoimaan tapauksiin antamalla vastaajille mahdollisuuden estää haitallisen paketin käytön nopeasti ja tarkasti, kun se on tunnistettu."

Muita kipeästi kaivattuja alan aloitteita ovat tietoturvametatietojen, kuten ohjelmistojen materiaalilaskujen (SBOM) ja ohjelmistoartifactien toimitusketjutasojen (SLSA) käyttöönotto oletuksena, mikä voi auttaa CISO:ita ymmärtämään paremmin toimitusketjunsa riskejä. Myös OpenSSF:n kaltaisille organisaatioille on lisätty rahoitusta, joka puolestaan ​​rahoittaa tärkeitä tietoturva-aloitteita.

Turvatiimien seuraavat vaiheet

Hodsonin mukaan CISO- ja DevSecOps-tiimeille avain on saada näkyvyyttä avoimeen lähdekoodiin, erityisesti intransitiivisiin riippuvuuksiin.

”CISO:n on tärkeää arvostaa ohjelmistokirjaston ja suoritettavan tiedoston luottamusketjua ja keskinäisiä riippuvuuksia. Xz Utils yksinään tuntuu melko vähäriskiseltä ohjelmistokomponentilta, mutta vastustajat pyrkivät hyödyntämään tällaisia ​​ohjelmistoja tavoitteissaan”, hän väittää. "CISO:n on saatava paljon parempi käsitys toimitusketjustaan ​​– ei vain kaupallisiin ohjelmistoihin käyttämiensä toimittajien, vaan myös sovellusten ja palveluiden avoimen lähdekoodin komponenteista. Puhumattakaan heidän kolmansista osapuolistaan."

SoSafe CSO, Andrew Rose, jakaa tämän tehtävälistan riskien hallintaa varten ISMS.onlinen kanssa:

• Luo kirjasto hyväksytyistä ohjelmistoista ja resursseista varmistaaksesi selkeät suojakaiteet kehittäjille ja rajoittaaksesi ei-hyväksyttyä koodia ja ohjelmistoja. Ohjelmistot pitäisi validoida ja hyväksyä, ehkä riskiarvioitujen toimittajien toimittajilta
• Luo väärennettyjä datajärviä testitarkoituksiin ja toteuta verkon segmentointi. Tämä tarkoittaa, että kaikilla kehittäjäympäristöillä tai paikoilla, joissa on hallitsemattomia koontiversioita, ei pitäisi olla pääsyä todellisiin tietoihin tai tuotantojärjestelmiin ja palveluihin.
• Käytä vain hyväksyttyjä, julkaistuja koontiversioita tuotannossa ja tarkista ne säännöllisesti varmistaaksesi, että epäilyttävää toimintaa valvotaan
• CISO:n tulisi pysyä yhteydessä kehittäjäyhteisöihin saadakseen tietoa haavoittuvuuksista, takaovista ja ongelmista niiden ilmaantuessa
• Tarkista ympäristöt säännöllisesti, jopa sen jälkeen, kun CISO:t ovat puhdistaneet talon. Palvelujen tai ohjelmistojen hallintaan tulisi soveltaa "karja ei lemmikkieläimiä" -mallia, mikä tarkoittaa jatkuvaa arviointia ja uudelleenrakentamista sen varmistamiseksi, että oikeita hyväksyttyjä versioita käytetään.

Endor Labsin Scott lisää seuraavat perusteelliset puolustusvinkit, joilla vähennetään hyväksikäytön todennäköisyyttä, jos ohjelmistojen toimitusketju vaarantuu:

• Toteuta vähiten etuoikeus: xz Utils -sovelluksen tapauksessa vähiten etuoikeuksien lähestymistapa palvelimen ja säilön määritykseen olisi auttanut. Takaoven SSH-avainten avulla voit käyttää SSH:ta, kun SSH-palvelut ovat käytettävissä. Älä altista SSH-portteja Internetiin
• Luo hallintokäytännöt avoimen lähdekoodin käyttöä varten: Ne voivat vaihdella "Kiinnitä kaikki käytetyt avoimen lähdekoodin ohjelmistojen versiot, jotta et lataa aina uusinta versiota" ja "älä käytä avoimen lähdekoodin ohjelmistojen versioita, jotka ovat alle 60 päivää vanhoja".
• Poista käyttämättömät ohjelmistot toimitusketjun riskin vähentämiseksi: Käyttämättömät ohjelmistot voivat aiheuttaa tarpeetonta turvotusta ohjelmistoosi ja aiheuttaa toimitusketjun riskiä ajan myötä. On vain ajan kysymys, ennen kuin seuraava xz Utils -tyyppinen hyökkäys havaitaan. Ryhtymällä nyt enemmän varotoimiin organisaatiot voivat aktiivisesti rakentaa joustavuutta ja varmistaa, että heidän toipumispolunsa on nopeampi ja vähemmän traumaattinen.