Missä ovat kaikki konttien rikkomukset?

Miten uhkatekijät hyökkäävät ja käyttävät kontteja? Tämä on kysymys, jota mietin jatkuvasti. Olen työskennellyt tällä alalla nyt yli kaksi vuosikymmentä, ja minusta tuntuu, että minun pitäisi saada vastaus. Mutta minä en.

Sen sijaan minulla on paljon erilaisia ​​ajatuksia, joista en todellakaan voi pitää oikeita. Osa tästä päättämättömyydestä johtuu kaikesta siitä ajasta, jonka vietin turvallisuuden oppimiseen "perintömaailmassa". Konteissa ei oikeastaan ​​ole analogia. Toki virtuaalikoneet (VM:t) sekoitetaan usein säilöihin, mutta ne eivät koskaan kyenneet skaalautumaan konttien tapaan. Niitä käytetään myös täysin eri tarkoituksiin kuin kontteja. Kesti jonkin aikaa säätää ajatteluani ja ymmärtää, mihin kontit todella sopivat hyökkäyspinnalle.

Julkisia esimerkkejä konttiympäristöjä vastaan ​​tehdyistä hyökkäyksistä on hyvin vähän. Rikkomukset liittyvät lähes aina kryptominointiin, jotka ovat vakavia hyökkäyksiä, mutta minussa tapahtuneen vastaaja pitää niitä alivoimaisina. Toinen yhteinen piirre on, että ne ovat enimmäkseen seurausta virheellisestä määrityksestä, olipa kyseessä sitten Kubernetes tai pilvitili. Motiivien ja taktiikan yhdistelmä ei ole toistaiseksi ollut kovin innostava.

Vanha tapa

Etäkoodin suorittamisen (RCE) haavoittuvuudet ovat olleet tietokoneturvallisuuden suurin huolenaihe jo pitkään. Ne ovat edelleen, mutta miten tämä ajattelutapa koskee kontteja? On helppo hypätä välittömästi RCE:hen ensisijaiseksi uhkaksi, mutta se ei näytä olevan oikea tapa lähestyä kontteja. Ensinnäkin säiliöt ovat usein hyvin lyhytikäisiä - 44 % konteista elää alle viisi minuuttia – joten tunkeilijan olisi oltava nopea.

Tämä lähestymistapa olettaa myös, että säiliö on alttiina Internetiin. Varmasti jotkut säiliöt on asetettu tällä tavalla, mutta ne ovat usein hyvin yksinkertaisia ​​ja käyttävät hyvin testattuja tekniikoita, kuten NGINX. Näillä sovelluksilla saattaa olla nollapäivää, mutta ne olisivat erittäin arvokkaita ja vaikeita saada. Kokemukseni on osoittanut, että monia säiliöitä käytetään sisäisesti, eivätkä ne muodosta yhteyttä suoraan Internetiin. RCE-skenaario muuttuu siinä tapauksessa paljon vaikeammaksi. minun pitäisi mainita log4j, vaikka tällaisia ​​haavoittuvuuksia voidaan hyödyntää etänä, vaikka haavoittuva järjestelmä ei olisikaan reunalla.

Uusi tapa

Jos RCE ei ole suurin konttien uhka, mikä sitten on? Ovatko kontit edes uhkatoimijoiden tutkassa? Kyllä, kontit ja niitä tukeva infrastruktuuri ovat liian tärkeitä sivuutettaviksi. Säilön orkestrointiohjelmisto on mahdollistanut konttityökuormien skaalauksen käsittämättömiin lukuihin. Myös käyttötrendi on kasvussa, joten voit olla varma, että ne ovat kohteena. Niitä ei vain voi ajatella palvelimina, joihin pääset RCE-haavoittuvuuksien kautta.

Sen sijaan päinvastoin on totta. Sen sijaan, että kontteja hyökättäisiin ulkopuolelta sisään, niitä on hyökättävä sisältä ulos. Tämä on pohjimmiltaan sitä, mitä toimitusketjuhyökkäykset tekevät. Toimitusketju on äärimmäisen tehokas hyökkäysvektori kontteja vastaan, kun alkaa ymmärtää niiden rakennetta. Säilö alkaa määrittelytiedostolla, kuten Dockerfile, joka määrittää kaiken, mitä säilöön tulee sen suoritettaessa. Siitä tehdään kuva, kun se on rakennettu, ja tämä kuva voidaan kääntää työmääräksi lukemattomia kertoja. Jos jokin tässä määritelmätiedostossa on vaarantunut, jokainen suoritettava työkuorma vaarantuu.

Säiliöt ovat usein, mutta eivät aina, tarkoitukseen rakennettuja sovelluksella, joka tekee jotain ja poistuu. Nämä sovellukset voivat olla melkein mitä tahansa – on tärkeää ymmärtää, kuinka paljon on rakennettu muiden ihmisten kirjoittamia kirjastoja, joko suljetun lähdekoodin tai avoimen lähdekoodin kirjastoja. GitHubilla on miljoonia projekteja, eikä se ole ainoa koodivarasto. Kuten näimme SolarWindsin kohdalla, suljettu lähdekoodi on myös alttiina toimitusketjun hyökkäyksille.

Toimitusketjuhyökkäys on loistava tapa uhkatekijöille päästä kohteen konttiympäristöön. He voivat jopa antaa asiakkaan infrastruktuurin skaalata hyökkäyksensä puolestaan, jos kompromissi jää huomaamatta. Tämäntyyppinen skenaario on jo toteutumassa, kuten näimme Codecov-rikkomus. Mutta sitä on vaikea havaita, koska tämä kaikki on uutta ja kuinka ajattelumme on edelleen juurtunut menneisyyden ongelmiin.

Way Forward

Kuten useimpien ongelmien korjaamisessa, näkyvyys on yleensä hyvä paikka aloittaa. On vaikea korjata sitä, mitä ei näe. Konttien turvaamiseksi sinulla on oltava näkyvyys itse kontteihin sekä koko niitä rakentavaan putkilinjaan. Haavoittuvuuksien hallinta on yksi näkyvyyden tyyppi, joka on integroitava rakennusprosessiin. Ottaisin mukaan myös muita staattisia analyysityökaluja, kuten sellaisia, jotka etsivät myös siihen vuotaneita salaisuuksia. Koska toimitusketjun hyökkäystä ei voi oikeastaan ​​ennustaa, ajonaikaisesta valvonnasta tulee kriittistä, jotta tiedät tarkalleen, mitä säiliösi tekevät.