Mikä on nollapäivähaavoittuvuus?

Nollapäivähaavoittuvuus, exploit ja hyökkäys

Termejä käytetään usein toistensa synonyymeinä, mutta ne kuvaavat eri asioita:

• Nollapäivähaavoittuvuus: itse aukko, jota toimittaja ei tunne tai johon ei ole korjausta.
• Nollapäivä-exploit: koodi tai tekniikka, joka hyödyntää aukkoa.
• Nollapäivähyökkäys: exploit, jota käytetään todellisia kohteita vastaan.

Kun toimittaja julkaisee korjauksen, aukko lakkaa olemasta nollapäivähaavoittuvuus ja muuttuu tunnetuksi haavoittuvuudeksi, jota kutsutaan usein n-day-haavoittuvuudeksi. Siitä alkaa toinen kilpajuoksu: hyökkääjät tutkivat paikkauksen ja etsivät järjestelmiä, joihin sitä ei ole asennettu, joten paikkaamatta jätetty tunnettu haavoittuvuus voi aiheuttaa yhtä paljon vahinkoa kuin alkuperäinen nollapäivähaavoittuvuus.

Nollapäivähaavoittuvuudet riippuvuuksissasi

Suurin osa modernin sovelluksen koodista tulee avoimen lähdekoodin paketeista, ja suurin osa niistä on transitiivisia riippuvuuksia: muiden pakettien mukanaan tuomia eikä tiimisi valitsemia. Nollapäivähaavoittuvuus missä tahansa niistä on nollapäivähaavoittuvuus tuotteessasi.

Log4Shell (CVE-2021-44228) on tunnetuin esimerkki. Joulukuussa 2021 julkistettu haavoittuvuus antoi lokiin kirjattavaa viestiä hallitsevan hyökkääjän ajaa mielivaltaista koodia Apache Log4j 2:n kautta, ja se sai CVSS-asteikon maksimin 10.0. Useimmille tiimeille vaikein osa ei ollut korjaus vaan sitä edeltävä kysymys: missä sovelluksistamme on log4j-core, ja missä versioissa? Log4j oli yleensä riippuvuuden riippuvuus, ja monet tiimit käyttivät päiviä sen selvittämiseen.

Toimitusketjun nollapäivähaavoittuvuudet eivät aina ole bugeja. Maaliskuussa 2024 Andres Freund löysi takaoven xz:n versioista 5.6.0 ja 5.6.1 (CVE-2024-3094) huomattuaan, että SSH-kirjautumiset käyttivät liikaa prosessoriaikaa. Haitalliset pakettijulkaisut, yleinen toimitusketjuhyökkäyksen muoto, toimivat samoin: ensimmäiset saastuneen version asentavat tiimit, kuten Shai-Hulud-npm-madon uhrit, kohtaavat hyökkäyksen, josta mikään tietoturvatiedote tai skanneri ei vielä tiedä.

Miten toimia, kun nollapäivähaavoittuvuus osuu riippuvuuteen

1. Selvitä, missä se on. Listaa jokainen sovellus, konttikuva ja julkaisu, joka sisältää haavoittuvan komponentin, myös transitiivisena riippuvuutena. Tähän tarvitaan tarkka SBOM jokaisesta buildista. Lukitustiedosto (lockfile) ei näe paketinhallinnan ohi haettuja riippuvuuksia, kuten asennusskriptien lataamaa koodia tai konttikuvan käyttöjärjestelmäkerroksia.
2. Selvitä altistumisaika. Mitkä buildit toimittivat haavoittuvan version, ja mistä lähtien? Se kertoo, mitä tutkia ja mitä raportoida.
3. Rajaa se. Asenna korjaus tai kiertotie, kun sellainen on olemassa, ja estä uusia buildeja toimittamasta haavoittuvaa versiota, kun sillä on CVE. Katso CVE-haavoittuvuuksien korjaus.
4. Tarkista hyödyntäminen. Etsi merkkejä siitä, että aukkoa käytettiin sinua vastaan altistumisaikana, ja vaihda kaikki salaisuudet, joihin se olisi voinut päästä käsiksi.

Koskeeko tämä meitä? käy kaksi ensimmäistä vaihetta läpi yksityiskohtaisesti.

Voiko nollapäivähaavoittuvuudelta suojautua, kun kukaan ei tiedä siitä?

Ei paikkaamalla eikä skannereilla, koska molemmat edellyttävät, että aukko tunnetaan. Ennen julkistamista toimii se, että rajoitetaan, mitä hyökkääjä voi löytämällään aukolla tehdä:

• Vähimmät oikeudet. Anna jokaiselle järjestelmälle ja CI-jobille vain sen tarvitsemat käyttöoikeudet ja salaisuudet.
• Lähtevän liikenteen hallinta. Estä lähtevät yhteydet palvelimiin, joita järjestelmä ei tarvitse, jotta ajossa oleva exploit ei voi lähettää dataa hyökkääjälle. CI-buildissa tämä on yksi harvoista kontrolleista, jotka toimivat, vaikka olisit uuden haitallisen paketin ensimmäinen uhri. Katso lähtevän liikenteen käytännöt GitHub Actionsille.
• Syvyyssuojaus. Kerrosta kontrollit niin, ettei yksi aukko avaa kaikkea.
• Tallenteet, joista voi hakea myöhemmin. Kun nollapäivähaavoittuvuus julkistetaan, reagointisi nopeus riippuu siitä, tiedätkö, mitä olet rakentanut ja toimittanut.

Miten CRACI auttaa

CRACI ajaa GitHub Actions -jobisi omilla runnereillaan ja tallentaa jokaisen buildin sen aikana:

• Buildin aikana tallennetut SBOM:t listaavat paketit, jotka kukin jobi todella haki, myös piilossa olevat riippuvuudet, jotka lukitustiedostoon perustuvilta työkaluilta jäävät huomaamatta, joten voit vastata kysymykseen "missä se on?" sen perusteella, mitä todella rakennettiin. Katso buildin aikana tallennetut SBOM:t.
• Buildihistoria näyttää jokaisen aiemman buildin ja sen SBOM:n sekä sen, mitkä buildit sisälsivät haavoittuvan riippuvuuden, suoran tai transitiivisen, joten tiedät ajanjakson, jona olit altistunut.
• Käytäntöportit voivat estää buildin, joka sisältää tietyn CVE:n, jotta uusi buildi ei toimita haavoittuvaa versiota uudelleen.
• Oletuksena estäväksi asetettu lähtevän liikenteen käytäntö estää yhteydet palvelimiin, joita buildi ei tarvitse, myös hyökkäyksessä, jota kukaan ei ole ennen nähnyt.

Nollapäivähaavoittuvuudet: usein kysytyt kysymykset

Mikä on nollapäivähaavoittuvuus?

Tietoturva-aukko, josta hyökkääjät tietävät tai jota ne jo hyödyntävät ennen kuin toimittaja tai ylläpitäjä on julkaissut korjauksen. Nimi laskee päivät, jotka puolustajilla on ollut aikaa paikata se: nolla.

Mitä eroa on nollapäivähaavoittuvuudella, exploitilla ja hyökkäyksellä?

Haavoittuvuus on aukko. Exploit on koodi tai tekniikka, joka hyödyntää sitä. Hyökkäys on exploit, jota käytetään todellisia kohteita vastaan.

Milloin nollapäivähaavoittuvuus lakkaa olemasta nollapäivähaavoittuvuus?

Kun korjaus on saatavilla. Siitä eteenpäin se on tunnettu haavoittuvuus, jota kutsutaan joskus n-day-haavoittuvuudeksi, ja riski siirtyy järjestelmiin, joihin korjausta ei ole vielä asennettu.

Voiko skanneri havaita nollapäivähaavoittuvuuden?

Ei hakemalla sitä. Haavoittuvuusskannerit vertaavat komponentteja julkaistuihin tietoturvatiedotteisiin, eikä nollapäivähaavoittuvuudesta ole vielä yhtään. Skanneri tai SBOM antaa sinulle inventaarion, josta voit hakea heti, kun tiedote ilmestyy.

Miten selvitän, koskeeko nollapäivähaavoittuvuus ohjelmistoani?

Hae haavoittuvaa komponenttia ja sen versioita tarkasta inventaariosta siitä, mitä kukin buildi ja julkaisu sisältää, transitiiviset riippuvuudet mukaan lukien. Selvitä sitten, mitkä julkaisut toimittivat sen ja mistä lähtien, niin tiedät altistumisajan.