Container security; anders dan traditionele security denkwijze
Infrastructure as Code is een ontwikkeling waar we als security, risk of audit professional steeds vaker mee te maken krijgen. Net als in (web)applicatie code kunnen er door fouten van engineers kwetsbaarheden ontstaan in infrastructuur die makkelijk voorkomen, gedetecteerd en gemitigeerd konden worden.
Dit betekent natuurlijk niet dat je als information security, risk of audit professional handmatig elk stukje Infrastructure as Code, zoals een Dockerfile, moet gaan reviewen. Wel is het als professional noodzakelijk om de risico’s te kunnen benoemen en om te weten in welke levensfase (van bijvoorbeeld een container) je welke maatregelen kunt nemen.
Zo kan er in de ontwikkelfase van de container, software worden gebruikt/aangeboden die kwetsbaarheden en risico’s detecteert en rapporteert, en boven bepaalde drempelwaardes een uitrol stopt. Maar als we het shift security left principe volgen, dan kunnen heldere principes of eisen al een hoop kwetsbaarheden voorkomen.
Hieronder laten we een afbeelding van een Dockerfile zien. In deze Dockerfile zitten kwetsbaarheden. In deze blog gaan we verder in op een aantal van deze kwetsbaarheden.
Tijdens onze OSCS-training zullen we onder andere op dit onderwerp nog dieper op de materie in gaan.
Gebruik version pinning
Version pinning is een principe waarbij engineers specificeren welke versie van een image ze willen gebruiken in plaats van :latest of :3 te gebruiken. Dit laatste kan leiden tot de volgende risico’s:
Risico 1: Verstoring van applicaties
Het eerst wat ons opvalt is dat deze Dockerfile gebaseerd is op de httpd:latest image. Iets wat vele security, risk en audit professionals zullen aanraden gezien de ‘latest’ versie ook de laatste security updates bevat.
Door het gebruik van de laatste versie, zal vandaag (27-10-2023) versie httpd:2.4.58 geïnstalleerd worden. Maar morgen kan dit versie httpd:2.5 zijn, waardoor applicaties niet meer kunnen werken en in productie verstoord kunnen raken met alle gevolgen en impact van dien.
Risico 2: Ongeautoriseerde toegang door een supply chain aanval
Doordat in de voorbeeld Dockerfile “httpd:latest” wordt gebruikt, is het mogelijk voor een aanvaller om in een publiek register een malafide versie van httpd te uploaden, die bijvoorbeeld een backdoor of cryptominer bevat die automatisch gebruikt wordt bij een volgende build van de container. Dit overkwam Microsoft en Apple in Februari 2021 met npm packages.
Dit brengt ons dan ook gelijk bij de volgende principes.
- Gebruik een privé-register voor al je images, dependencies en libraries.
- Dance like nobody is watching, encrypt like everyone is
We hoeven encryptie van data in transit aan information security, risk en audit professionals niet uit te leggen… Toch?
Risico 3: Ongeautoriseerde toegang door niet versleuteld netwerkverkeer
Misschien wel het meest opvallende risico in ons Dockerfile voorbeeld. Containers hebben standaard geen connectiviteit, tenzij er gespecificeerd wordt welke netwerkpoorten er open gezet moeten worden. Hier kiest onze engineer voor poort 80. Als information, risk of audit professional zien we hier natuurlijk liever poort 443 (https).
Risico 4: Data lek door gebrek aan least privilege
Standaard draaien containers onder de gebruiker ‘root’: de gebruiker met de hoogste rechten op het besturingssysteem van de container. Hierdoor ontstaat het risico dat een aanvaller, bij ongeautoriseerde toegang tot een container, alles kan doen wat hij/zij maar wil. Denk aan het loglevel naar debug verhogen van de httpd server, om zo in de httpd logs niet versleutelde gebruikersnamen en wachtwoorden te zien. Daarnaast zal de aanvaller, wanneer er een mogelijkheid is om uit de container te breken, ook root-rechten hebben op de onderliggende infrastructuur, met alle gevolgen van dien. Dit brengt ons bij de laatste principe van ons blog.
Specificeer onder welke gebruiker de container moet draaien.
RUN useradd --create-home httpduser
WORKDIR /usr/local/apache2
USER httpduser
Containersecurity gaat verder dan traditionele security denken
Deze blog laat al zien dat er alleen in een simpele Dockerfile voldoende risico’s kunnen ontstaan door niet op de hoogte te zijn van de laatste best practices, en dat klassieke security-denkwijze niet altijd voldoet op het gebied van containers. Wil je nu zelf ook je kennis op gebied van containersecurity up to date maken, kijk dan eens naar onze containersecuritytraining (OSCS) en schrijf je in. Of als je vragen hebt, neem dan even contact met ons op!