Hur kommer hotaktörer att attackera och använda containrar? Det här är en fråga jag ständigt tänker på. Jag har arbetat inom det här området i mer än två decennier nu, och jag känner att jag borde ha ett svar. Men det gör jag inte.
Istället har jag en massa olika idéer, som jag inte riktigt kan peka ut som korrekt. En del av denna obeslutsamhet är på grund av all tid jag ägnade åt att lära mig säkerhet i "arvet" världen. Behållare har egentligen ingen analog. Visst, virtuella maskiner (VM) blandas ofta ihop med behållare, men de kunde aldrig skalas som behållare. De används också för helt andra ändamål än containrar. Det har tagit ett tag att justera mitt tänkande och förstå var containrar faktiskt passar in i attackytan.
De offentliga exemplen på attacker mot containermiljöer är mycket begränsade. Intrången är nästan alltid relaterade till kryptominering, vilket är allvarliga attacker, men incidentsvararen i mig tycker att de är underväldigande. En annan gemensamhet är att de oftast är resultatet av en felkonfiguration, oavsett om det är i Kubernetes eller ett molnkonto. Kombinationen av motiven och taktiken har hittills inte varit särskilt inspirerande.
Gamla vägen
Sårbarheter för fjärrkörning av kod (RCE) har varit huvudproblemet inom datorsäkerhet under lång tid. Det är de fortfarande, men hur gäller detta sätt att tänka containrar? Det är lätt att direkt hoppa till RCE som det primära hotet, men det verkar inte vara rätt sätt att närma sig containrar. För det första är containrar ofta mycket kortlivade – 44 % av containrarna lever mindre än fem minuter – så en inkräktare måste vara snabb.
Detta tillvägagångssätt förutsätter också att behållaren är exponerad för Internet. Visst är vissa behållare konfigurerade på detta sätt, men de är ofta väldigt enkla och använder väl beprövade tekniker, som NGINX. Det kan finnas noll dagar för dessa applikationer, men de skulle vara extremt värdefulla och svåra att få tag på. Min erfarenhet har visat mig att många behållare används internt och inte ansluter direkt till Internet. RCE-scenariot blir mycket svårare i så fall. Jag borde nämna log4j, även om den här typen av sårbarheter har potential att utnyttjas på distans även om det sårbara systemet inte är på kanten.
Det nya sättet
Om RCE inte är det största hotet mot containrar, vad är det då? Finns containrar ens på hotaktörernas radar? Ja, containrar och deras stödjande infrastruktur är för viktiga för att ignorera. Programvara för orkestrering av containers har gjort att containeriserade arbetsbelastningar kan skalas till ofattbara siffror. Användningstrenden ökar också, så du kan vara säker på att de kommer att bli ett mål. De kan helt enkelt inte ses som servrar du kommer till genom RCE-sårbarheter.
Istället är det omvända faktiskt sant. Istället för att attackera containrar utifrån och in behöver de attackeras inifrån och ut. Detta är i huvudsak vad supply chain attacker gör. Supply chain är en extremt effektiv attackvektor mot containrar när man börjar förstå hur de är byggda. En behållare börjar med en definitionsfil, till exempel Dockerfile, som definierar allt som kommer att finnas i behållaren när den körs. Det förvandlas till en bild som en gång byggts, och den bilden är vad som kan snurras upp till en arbetsbelastning ett oräkneligt antal gånger. Om något i den definitionsfilen äventyras, är varje enskild arbetsbelastning som körs äventyrad.
Behållare är ofta, men inte alltid, specialbyggda med en applikation som gör något och avslutas. Dessa applikationer kan vara nästan vad som helst - det viktiga att förstå är hur mycket som byggs med hjälp av bibliotek, antingen sluten källkod eller öppen källkod, skrivna av andra människor. GitHub har miljontals projekt, och det är inte det enda förrådet av kod där ute. Som vi såg med SolarWinds är sluten källkod också sårbar för attacker i leveranskedjan.
En supply chain-attack är ett utmärkt sätt för hotaktörer att ta sig in i ett måls containermiljö. De kan till och med låta kundens infrastruktur skala sin attack åt dem om kompromissen går obemärkt förbi. Den här typen av scenarier spelar redan ut, som vi såg med Codecov-brott. Men det är svårt att upptäcka på grund av hur nytt allt detta är och hur vårt tänkande fortfarande är rotat i det förflutnas problem.
En väg framåt
Som med att lösa de flesta problem är synlighet vanligtvis ett bra ställe att börja. Det är svårt att fixa det man inte kan se. För att säkra dina containrar måste du ha insyn i själva containrarna, såväl som hela pipeline som bygger dem. Sårbarhetshantering är en typ av synlighet som måste integreras i byggledningen. Jag skulle också inkludera andra statiska analysverktyg, till exempel de som letar efter läckta hemligheter till det också. Eftersom hur en försörjningskedjasattack ser ut inte riktigt går att förutsäga, blir körtidsövervakning kritisk så att du vet exakt vad dina containrar gör.
