Hvordan vil trusselsaktører angribe og bruge containere? Det er et spørgsmål, jeg konstant tænker over. Jeg har arbejdet på dette område i mere end to årtier nu, og jeg føler, at jeg burde have et svar. Men det gør jeg ikke.
I stedet har jeg en masse forskellige ideer, som jeg ikke rigtig kan pege på som korrekte. En del af denne ubeslutsomhed er på grund af al den tid, jeg brugte på at lære sikkerhed i den "arvede" verden. Containere har ikke rigtig en analog. Sikker på, virtuelle maskiner (VM'er) er ofte blandet sammen med containere, men de var aldrig i stand til at skalere som containere. De bruges også til helt andre formål end containere. Det har taget et stykke tid at justere min tankegang og forstå, hvor containere faktisk passer ind i angrebsoverfladen.
De offentlige eksempler på angreb mod containermiljøer er meget begrænsede. Overtrædelserne er næsten altid relaterede til kryptominering, som er alvorlige angreb, men hændelsen hos mig finder dem undervældende. Et andet fællestræk er, at de for det meste er resultatet af en fejlkonfiguration, uanset om det er i Kubernetes eller en cloud-konto. Kombinationen af motiverne og taktikken har indtil videre ikke været særlig inspirerende.
Den gamle vej
Sårbarheder med fjernudførelse af kode (RCE) har været den største bekymring inden for computersikkerhed i lang tid. Det er de stadig, men hvordan gælder denne tankegang for containere? Det er nemt straks at springe til RCE som den primære trussel, men det ser ikke ud til at være den rigtige måde at nærme sig containere. For det første har containere ofte meget kort levetid – 44 % af containerne lever mindre end fem minutter – så en ubuden gæst skal være hurtig.
Denne tilgang forudsætter også, at containeren er udsat for internettet. Nogle containere er bestemt sat op på denne måde, men de er ofte meget enkle og bruger velafprøvede teknologier, som NGINX. Der kan være nul dage til disse applikationer, men de ville være ekstremt værdifulde og svære at få fat på. Min erfaring har vist mig, at mange containere bruges internt og ikke forbinder direkte til internettet. RCE-scenariet bliver meget vanskeligere i så fald. Jeg bør nævne log4j, selvom denne slags sårbarheder har potentialet til at blive udnyttet eksternt, selvom det sårbare system ikke er på kanten.
Den nye vej
Hvis RCE ikke er den største trussel mod containere, hvad er det så? Er containere overhovedet på radaren af trusselsaktører? Ja, containere og deres understøttende infrastruktur er for vigtige til at ignorere. Container orkestreringssoftware har gjort det muligt at skalere containeriserede arbejdsmængder til uanede tal. Brugstendensen er også stigende, så du kan være sikker på, at de bliver et mål. De kan bare ikke opfattes som servere, du kommer til gennem RCE-sårbarheder.
I stedet er det omvendte faktisk sandt. I stedet for at angribe containere udefra og ind, skal de angribes indefra og ud. Dette er i bund og grund, hvad forsyningskædeangreb gør. Supply chain er en ekstremt effektiv angrebsvektor mod containere, når du begynder at forstå, hvordan de er bygget. En container starter med en definitionsfil, såsom Dockerfile, som definerer alt, hvad der vil være i containeren, når den kører. Det er forvandlet til et billede, når det er bygget, og det billede er det, der kan blive spundet op til en arbejdsbyrde et utal af gange. Hvis noget i den definitionsfil er kompromitteret, så er hver eneste arbejdsbyrde, der kører, kompromitteret.
Containere er ofte, men ikke altid, specialbyggede med en applikation, der gør noget og afslutter. Disse applikationer kan være næsten alt - det vigtige at forstå er, hvor meget der er bygget ved hjælp af biblioteker, enten lukket kildekode eller åben kildekode, skrevet af andre mennesker. GitHub har millioner af projekter, og det er ikke det eneste kodelager derude. Som vi så med SolarWinds, er lukket kilde også sårbart over for forsyningskædeangreb.
Et forsyningskædeangreb er en fantastisk måde for trusselsaktører at komme ind i et måls containermiljø. De kan endda lade kundens infrastruktur skalere deres angreb for dem, hvis kompromiset går ubemærket hen. Denne type scenarie udspiller sig allerede, som vi så med Codecov brud. Men det er svært at opdage på grund af, hvor nyt alt dette er, og hvordan vores tænkning stadig er forankret i fortidens problemer.
En vej frem
Som med at løse de fleste problemer, er synlighed normalt et godt sted at starte. Det er svært at rette op på det, du ikke kan se. For at sikre dine containere skal du have synlighed ind i selve containerne, samt hele rørledningen, der bygger dem. Sårbarhedshåndtering er en type synlighed, der skal integreres i byggepipelinen. Jeg vil også inkludere andre statiske analyseværktøjer, såsom dem, der leder efter lækkede hemmeligheder til det. Da hvordan et forsyningskædeangreb ser ud, ikke rigtig kan forudsiges, bliver runtime-overvågning kritisk, så du ved præcis, hvad dine containere laver.
