Hvordan vil trusselaktører angripe og bruke containere? Dette er et spørsmål jeg hele tiden tenker på. Jeg har jobbet i dette området i mer enn to tiår nå, og jeg føler at jeg burde ha et svar. Men det gjør jeg ikke.
I stedet har jeg mange forskjellige ideer, som jeg ikke kan peke på som riktige. En del av denne ubesluttsomheten er på grunn av all tiden jeg brukte på å lære sikkerhet i "arven"-verdenen. Beholdere har egentlig ikke en analog. Visst, virtuelle maskiner (VM-er) blir ofte blandet sammen med containere, men de var aldri i stand til å skalere som containere. De brukes også til helt andre formål enn containere. Det har tatt en stund å justere tankegangen min og forstå hvor containere faktisk passer inn i angrepsoverflaten.
De offentlige eksemplene på angrep mot containeriserte miljøer er svært begrenset. Bruddene er nesten alltid relatert til kryptominering, som er alvorlige angrep, men hendelsesreaksjonen i meg finner dem underveldende. En annen fellestrekk er at de stort sett er et resultat av en feilkonfigurasjon, enten det er i Kubernetes eller en skykonto. Kombinasjonen av motivene og taktikken har ikke vært særlig inspirerende så langt.
Den gamle veien
Svakheter med ekstern kjøring av kode (RCE) har vært hovedproblemet innen datasikkerhet i lang tid. Det er de fortsatt, men hvordan gjelder denne tankegangen for containere? Det er lett å umiddelbart hoppe til RCE som den primære trusselen, men det ser ikke ut til å være den rette måten å nærme seg containere. For det første har containere ofte svært kort levetid – 44 % av containerne lever mindre enn fem minutter – så en inntrenger må være rask.
Denne tilnærmingen forutsetter også at beholderen er eksponert for Internett. Visst noen containere er satt opp på denne måten, men de er ofte veldig enkle og bruker veltestede teknologier, som NGINX. Det kan være null dager for disse applikasjonene, men de vil være ekstremt verdifulle og vanskelige å få tak i. Min erfaring har vist meg at mange containere brukes internt og ikke kobles direkte til Internett. RCE-scenarioet blir mye vanskeligere i så fall. Jeg bør nevne log4j, selv om denne typen sårbarheter har potensial til å bli utnyttet eksternt selv om det sårbare systemet ikke er på kanten.
Den nye veien
Hvis RCE ikke er den største trusselen mot containere, hva er det da? Er containere til og med på radaren til trusselaktører? Ja, containere og deres støttende infrastruktur er for viktig til å ignorere. Container orkestrering programvare har gjort det mulig for containeriserte arbeidsmengder å skaleres til ufattelige tall. Brukstrenden øker også, så du kan være sikker på at de vil være et mål. De kan bare ikke ses på som servere du kommer til gjennom RCE-sårbarheter.
I stedet er det motsatte faktisk sant. I stedet for å angripe containere fra utsiden og inn, må de angripes fra innsiden og ut. Dette er i hovedsak hva forsyningskjedeangrep gjør. Forsyningskjeden er en ekstremt effektiv angrepsvektor mot containere når du begynner å forstå hvordan de er bygget. En container starter med en definisjonsfil, for eksempel Dockerfile, som definerer alt som vil være i containeren når den kjører. Det er gjort om til et bilde når det er bygget, og det bildet er det som kan spinnes opp til en arbeidsmengde utallige ganger. Hvis noe i den definisjonsfilen er kompromittert, blir hver eneste arbeidsbelastning som kjøres kompromittert.
Containere er ofte, men ikke alltid, spesialbygde med en applikasjon som gjør noe og avslutter. Disse applikasjonene kan være nesten hva som helst - det viktige å forstå er hvor mye som bygges ved hjelp av biblioteker, enten lukket kildekode eller åpen kildekode, skrevet av andre mennesker. GitHub har millioner av prosjekter, og det er ikke det eneste kodelageret der ute. Som vi så med SolarWinds, er lukket kilde også sårbart for forsyningskjedeangrep.
Et forsyningskjedeangrep er en fin måte for trusselaktører å komme inn i et måls containermiljø. De kan til og med la kundens infrastruktur skalere angrepet for dem hvis kompromisset går ubemerket hen. Denne typen scenarier er allerede i gang, som vi så med Codecov-brudd. Men det er vanskelig å oppdage på grunn av hvor nytt alt dette er og hvordan vår tenkning fortsatt er forankret i fortidens problemer.
En vei fremover
Som med å fikse de fleste problemer, er synlighet vanligvis et flott sted å starte. Det er vanskelig å fikse det du ikke kan se. For å sikre containerne dine må du ha innsyn i selve containerne, samt hele rørledningen som bygger dem. Sårbarhetshåndtering er en type synlighet som må integreres i byggerørledningen. Jeg vil også inkludere andre statiske analyseverktøy, for eksempel de som ser etter lekke hemmeligheter til det også. Siden hvordan et forsyningskjedeangrep ser ut ikke virkelig kan forutsies, blir kjøretidsovervåking kritisk slik at du vet nøyaktig hva containerne dine gjør.
