Hoe zullen dreigingsactoren containers aanvallen en gebruiken? Dit is een vraag waar ik voortdurend over nadenk. Ik werk nu al meer dan twintig jaar op dit gebied en ik heb het gevoel dat ik een antwoord moet hebben. Maar dat doe ik niet.
In plaats daarvan heb ik veel verschillende ideeën, waarvan ik geen enkele echt als correct kan aanwijzen. Een deel van deze besluiteloosheid is te wijten aan de hele tijd die ik heb besteed aan het leren van veiligheid in de ‘legacy’-wereld. Containers hebben niet echt een analoog. Zeker, virtuele machines (VM's) worden vaak samengevoegd met containers, maar ze zijn nooit in staat geweest om als containers te schalen. Ze worden ook voor heel andere doeleinden gebruikt dan containers. Het heeft een tijdje geduurd voordat ik mijn denkwijze had aangepast en begreep waar containers daadwerkelijk in het aanvalsoppervlak passen.
De publieke voorbeelden van aanvallen op containeromgevingen zijn zeer beperkt. De inbreuken hebben bijna altijd te maken met cryptomining, wat serieuze aanvallen zijn, maar de incidentresponder in mij vindt ze teleurstellend. Een andere overeenkomst is dat ze meestal het resultaat zijn van een verkeerde configuratie, of dat nu in Kubernetes is of in een cloudaccount. De combinatie van de motieven en de tactiek is tot nu toe niet erg inspirerend geweest.
De oude manier
Kwetsbaarheden voor het uitvoeren van externe code (RCE) zijn al lange tijd het grootste probleem in de computerbeveiliging. Dat zijn ze nog steeds, maar hoe is deze manier van denken van toepassing op containers? Het is gemakkelijk om meteen RCE als voornaamste bedreiging te beschouwen, maar het lijkt niet de juiste manier om containers te benaderen. Om te beginnen hebben containers vaak een zeer korte levensduur: 44% van de containers leeft minder dan vijf minuten – dus een indringer zou snel moeten zijn.
Bij deze benadering wordt er ook van uitgegaan dat de container is blootgesteld aan internet. Zeker, sommige containers zijn op deze manier opgezet, maar deze zijn vaak heel eenvoudig en maken gebruik van beproefde technologieën, zoals NGINX. Er zijn misschien zero-days out voor deze toepassingen, maar ze zouden uiterst waardevol en moeilijk te verkrijgen zijn. Mijn ervaring heeft mij geleerd dat veel containers intern worden gebruikt en geen directe verbinding met internet maken. Het RCE-scenario wordt dan een stuk lastiger. Ik zou moeten vermelden log4j, hoewel dit soort kwetsbaarheden het potentieel hebben om op afstand te worden uitgebuit, zelfs als het kwetsbare systeem zich niet aan de rand bevindt.
De nieuwe manier
Als RCE niet de grootste bedreiging is voor containers, wat dan wel? Staan containers zelfs op de radar van bedreigingsactoren? Ja, containers en hun ondersteunende infrastructuur zijn te belangrijk om te negeren. Met containerorkestratiesoftware kunnen gecontaineriseerde workloads worden opgeschaald naar onvoorstelbare aantallen. De gebruikstrend neemt ook toe, dus u kunt er zeker van zijn dat ze een doelwit zullen zijn. Ze kunnen gewoon niet worden gezien als servers die u bereikt via RCE-kwetsbaarheden.
In plaats daarvan is het omgekeerde feitelijk waar. In plaats van containers van buitenaf aan te vallen, moeten ze van binnenuit worden aangevallen. Dit is in essentie wat supply chain-aanvallen doen. Supply chain is een uiterst effectieve aanvalsvector tegen containers als je begint te begrijpen hoe ze zijn gebouwd. Een container begint met een definitiebestand, zoals Dockerfile, dat alles definieert wat zich in de container bevindt wanneer deze wordt uitgevoerd. Zodra het is opgebouwd, wordt het omgezet in een beeld, en dat beeld kan ontelbare keren tot een werklast worden omgezet. Als er iets in dat definitiebestand wordt aangetast, wordt elke afzonderlijke werkbelasting die wordt uitgevoerd, aangetast.
Containers zijn vaak, maar niet altijd, speciaal gebouwd met een applicatie die iets doet en weer weggaat. Deze applicaties kunnen bijna alles zijn; het belangrijkste om te begrijpen is hoeveel er is gebouwd met behulp van bibliotheken, gesloten source of open source, geschreven door andere mensen. GitHub heeft miljoenen projecten, en dat is niet de enige opslagplaats met code die er is. Zoals we bij SolarWinds hebben gezien, is closed source ook kwetsbaar voor supply chain-aanvallen.
Een supply chain-aanval is een geweldige manier voor bedreigingsactoren om de containeromgeving van een doelwit binnen te dringen. Ze kunnen de aanval zelfs door de infrastructuur van de klant laten opschalen als het compromis onopgemerkt blijft. Dit soort scenario speelt zich al af, zoals we zagen bij de Codecov-inbreuk. Maar het is moeilijk te ontdekken omdat dit allemaal nieuw is en omdat ons denken nog steeds geworteld is in de problemen uit het verleden.
A Way Forward
Zoals bij het oplossen van de meeste problemen, is zichtbaarheid meestal een goed beginpunt. Het is moeilijk om te repareren wat je niet kunt zien. Om uw containers te beveiligen, moet u inzicht hebben in de containers zelf, evenals in de hele pijplijn waaruit ze zijn opgebouwd. Kwetsbaarheidsbeheer is een vorm van zichtbaarheid die moet worden geïntegreerd in de build-pijplijn. Ik zou ook andere statische analysehulpmiddelen toevoegen, zoals instrumenten die ook op zoek gaan naar gelekte geheimen daarvoor. Omdat niet echt kan worden voorspeld hoe een supply chain-aanval eruit ziet, wordt runtime-monitoring van cruciaal belang, zodat u precies weet wat uw containers doen.
