Software containers in het algemeen en in de cloud in het bijzonder zijn een redelijk nieuwe technologie. Ze maken inmiddels wel deel uit van de mainstream. Veel IT’ers zijn fan van containers omdat zij een aantal voordelen bieden. Containers kunnen complexiteit reduceren en continuïteit waarborgen. En zelfs beveiligingslagen toevoegen aan een infrastructuur. Het zou echter een wonder heten als deze technologie niet ook doelwit was van cyberboeven. Het moment dat een technologie in de mainstream belandt is meestal ook het moment dat zij met gerichte cyberaanvallen te maken krijgt.
Veiligheid en de container
Laten wij eerst eens kijken wat containers op zich veilig maakt. Met een container kun je een enkele applicatie ‘verpakken’ en in gebruik nemen. Het kan je een verscheidenheid aan operationele en veiligheidsvoordelen opleveren als je applicaties of diensten van verschillende delen van een doelomgeving kan loskoppelen. Containers kunnen de complexiteit van meerdere gelijktijdige services op één systeem verminderen, vooral als er overlappende of tegenstrijdige afhankelijkheden tussen de applicaties bestaan. Door dit loskoppelen, deze abstractie, kunnen containers ook helpen om de effecten van infrastructuurstoringen te beperken. Hierdoor kun je de uptime waarborgen en voorkomen dat applicaties of cruciale diensten gecompromitteerd worden.
Gelaagd verdedigingsmodel
Containers draaien op een geabstraheerde laag boven op het host-besturingssysteem. Deze abstractie biedt de mogelijkheid om een gelaagd verdedigingsmodel toe te passen. Naast het feit dat zij per definitie geabstraheerd zijn en dus niet meteen vatbaar voor infectie door het host-besturingssysteem kun je containers bovendien zo configureren dat zij alleen in vertrouwde en geïsoleerde omgevingen draaien. Deze configuratie biedt een extra barrière, waardoor de beveiliging verder wordt verbeterd.
Containers zijn echter niet ondoordringbaar en zijn gevoelig voor verschillende kwetsbaarheden en mechanismen. Kubernetes bijvoorbeeld is een open-source beheersysteem om containers automatisch in te zetten en te monitoren. In de eerste week van december 2018 bracht Kubernetes niet minder dan drie updates uit (v1.10.11, v1.11.5 en v1.12.3) om CVE-2018-1002105 te adresseren, een kwetsbaarheid die toegang op cluster-admin-niveau mogelijk maakt voor iemand die niet over speciale privileges beschikt. Dit maakt het voor kwaadwillenden mogelijk om willekeurige services te creëren. Cybercriminelen kunnen gevoelige gegevens stelen, kwaadaardige code installeren of applicaties en diensten uitschakelen. Bovendien zullen deze acties niet als ongeautoriseerde manipulaties in audit- of serverlogs opduiken.
Tesla
In een ander voorbeeld werden de Kubernetes-consoles van autofabrikant Tesla geïnfiltreerdomdat ze niet met een wachtwoord waren beveiligd. Binnen één Kubernetes-podwerden de toegangsgegevens van het systeem blootgesteld aan Tesla’s Amazon Web Services (AWS)-omgeving. Deze bevatte een Amazon S3 (Amazon Simple Storage Service) bucket met gevoelige gegevens over bijvoorbeeld autotelemetrie. Onderzoekers kwamen er ook achter dat cybercriminelen één van Tesla’s Kubernetes pods voor cryptomining misbruikten.
Het is helaas te verwachten dat er nog meer en andersoortige aanvallen komen die zich specifiek op container-technologie richten.
Container-kwetsbaarheden
Zoals met alle software moeten de kwetsbaarheden in containers zorgvuldig worden beheerd. Zo heeft IBM in juli 2018 twee kwetsbaarheden (CVE-2018-11756 en CVE-2018-11757) aangepakt in de Apache OpenWhisk-applicatie, een component die IBM gebruikt om container-gebaseerde diensten te leveren. Door deze kwetsbaarheden kon een aanvaller back-end functies in het platform met willekeurige code overschrijven. De risico’s van dit type kwetsbaarheid variëren van eenvoudige denial of service (DoS) tot wijzigen, verwijderen en extraheren van gegevens.
Het patchen van containers en specifieke applicatiebibliotheken in containers kan soms problematisch zijn vanwege het aantal actieve containers. Het gebruik van containers kan namelijk tot grote diversiteit in een omgeving leiden. Microsoft Azure, Amazon Web Services en het Google Cloud Platform bieden de mogelijkheid containers in de cloud tijdens de nacht automatisch van beveiligingspatches te voorzien. Beheerders moeten echter nog steeds nodes herstarten en downtime voor patches inplannen.
Gecompromiteerde container images
Bij het downloaden en gebruiken van container images van derden is het helemaal opletten geblazen. Deze dien je te scannen op kwetsbaarheden, vooral als je van plan bent om gevoelige toepassingen in de container te draaien. Je moet er standaardprocedures op na houden voor het ‘verharden’ van externe containers en ook van het host-besturingssysteem voor deze containers. Het kan je hierbij helpen images digitaal te ondertekenen om te detecteren of de inhoud van een image is gewijzigd. Met name het ondertekenen van images met privé-sleutels ( “private keys”) biedt cryptografische zekerheid.
Kwaadwillenden kunnen juist de kracht van container-beheerplatforms gebruiken om containers uitgebreider en sneller te infiltreren. Zo vondenonderzoekers kant en klare Kubernetes-implementaties die draaien op honeypot-servers die ‘vergiftigd’ waren met kwaadaardige Docker-containers en geconfigureerd om Monero-cryptocurrency te minen.
Slecht configuratiebeheer
Containers kunnen worden blootgesteld door eenvoudige configuratiefouten. Als een gecompromitteerde container bijvoorbeeld per abuis geconfigureerd is als geprivilegieerd op een host-besturingssysteem, kan deze container zijn privileges overdragen aan de host of aan andere containers. Om dit te voorkomen kun je de toegang tot de host of andere containers beperken. Hiervoor moet je elke container de minst mogelijke privileges geven. Eén methode is dat je voor elke container een specifiek gebruikersaccount aanmaakt en de container als deze specifieke gebruiker laat draaien.
Bovendien moet je voorzichtig zijn als je host volumes toewijst aan containers. Als je dit niet zorgvuldig doet kan deze toewijzing (“mapping”) een andere methode bieden voor directe toegang tot de host vanuit een gecompromitteerde container. Als je bijvoorbeeld de “/dev”-map verkeert toewijst kan dit toegang vanuit de container tot alle apparaten op de host bieden.
Gebruik van geheimen
‘Geheimen’ zijn data-blokjes met gevoelige informatie die mogelijk tussen de host en een container moeten worden uitgewisseld. Veelvoorkomende voorbeelden van geheimen zijn wachtwoorden, SSH-sleutels, SSL/TLS-certificaten, verbindingsstrings en andere gegevens. Deze mogen niet via platte tekst worden verzonden of onversleuteld worden opgeslagen.
Cloud-bedrijven bieden hiervoor verschillende oplossingen. Met Microsoft Windows Server 2016, inclusief het Docker-containerplatform op de Microsoft Azure cloud, kun je geheimen in de runtime aan containers leveren. Amazon Web Services biedt een Parameter Store-functie voor het beheer van geheimen binnen toepassingen die in containers op Amazon ECS (Elastic Container Service) draaien. De Parameter Store zorgt voor de rotatie en herroeping van geheimen en ondersteunt encryptie om gevoelige gegevens verder te beschermen. Ook het Google Cloud Platform ondersteunt via het Cloud Kubernetes management systeem geheimen.
Ongeacht de dienst die je gebruikt, moet je geheimen goed beveiligen en centraal beheren. Geheimen mogen alleen worden doorgegeven aan containers die ze specifiek nodig hebben, versleuteld zowel in transit als in rust, alleen toegankelijk voor containerdiensten en -toepassingen die expliciet toegang hebben gekregen, en idealiter alleen tijdens het uitvoeren van deze specifieke diensten.
Conclusies
In het licht van het steeds toenemende gebruik van containers, zowel op locatie als in de cloud, ontwikkelen container- en cloud-leveranciers voortdurend robuustere containerbeveiligingsoplossingen om de configuratie en automatisering beter te beheren. Zo richt IBM zich op de ontwikkeling van zijn Nabla-containers. Google op de verbetering van zijn gVisor-product, Microsoft op Azure Kubernetes en Windows Server 2019 en Amazon op zijn Elastic Container Service (Amazon ECS). De OpenStack Foundation is bezig met haar open-source Kata Containers project. VMWare plant beveiligingsverbeteringen aan zijn NSX-netwerkvirtualisatie-software door deze te combineren met het aanbod van de Pivotal container service.
Ondanks verbeteringen door leveranciers kan het bij gebruik van containers in het eigen datacenter, in de cloud of hybride omgevingen noodzakelijk zijn voor een organisatie om programma’s voor security monitoring en dreigingsdetectie aan te passen. Sommigen moeten misschien zelfs een heel nieuw programma opzetten. De bestaande systemen bieden misschien niet voldoende toezicht op de veiligheid van containers. Dit is vooral het geval als beveiligingscontroles zich richten op het dataverkeer tussen eindpunten en niet op het inspecteren van applicaties en diensten die in containers draaien.
Als containers automatisch worden ingezet kunnen kwetsbaarheden en aanvalsmogelijkheden snel veranderen. Hierdoor worden zorgvuldige segmentatie en instrumentatie nodig om de veiligheid van containers continu in de gaten te kunnen houden. En hen naar behoren te kunnen beschermen. Zoals elke technologie, ook al is deze op zichzelf als veilig te beschouwen, vragen containers dus om specifieke security-aanpak. En om de nodige expertise. Houd er in elk geval rekening mee, anders kan de overstap naar containers een hoop ellende veroorzaken.
Radboud Beumer, Regional Director Continental Europe, Secureworks
