Onlangs werd bekend door middel van een blogpost, de resultaten van testtools om kwetsbaarheden te identificeren niet-gepatcht en identificeer beveiligingsproblemen in geïsoleerde Docker-containerafbeeldingen.
Uit de test bleek dat 4 van de 6 scanners van bekende Docker-images had kritieke kwetsbaarheden waarmee de scanner zelf kon worden aangevallen en de code op het systeem kon worden uitgevoerd, in sommige gevallen (bijvoorbeeld bij gebruik van Snyk) met rootrechten.
Voor een aanval, een aanvaller hoeft alleen de verificatie van uw Dockerfile te starten o manifest.json, dat speciaal opgemaakte metadata bevat, of plaats de podfile- en gradlew-bestanden in de afbeelding.
We zijn erin geslaagd om exploit-prototypes op te zetten voor WhiteSource-, Snyk-, Fossa- en Anchore-systemen.
Pakket Claire, die oorspronkelijk is geschreven met het oog op veiligheid, toonde de beste beveiliging.
Geen problemen geïdentificeerd in het Trivy-pakket en als gevolg hiervan werd geconcludeerd dat Docker-containerscanners in sandboxen moesten worden uitgevoerd of alleen moesten worden gebruikt om uw eigen afbeeldingen te verifiëren, en ook voorzichtig moesten zijn bij het verbinden van dergelijke tools met geautomatiseerde continue integratiesystemen.
Deze scanners doen gecompliceerde en foutgevoelige dingen. Ze hebben te maken met docker, het ophalen van lagen/bestanden, interageren met pakketbeheerders of het ontleden van verschillende formaten. Het is erg moeilijk om ze te verdedigen, terwijl je probeert alle use-cases voor ontwikkelaars te accommoderen. Laten we eens kijken hoe de verschillende tools het proberen te doen:
De Responsible Disclosure-score geeft mijn persoonlijke mening weer: ik denk dat het belangrijk is dat softwareleveranciers ontvankelijk zijn voor beveiligingsproblemen die aan hen worden gemeld, eerlijk en transparant zijn over kwetsbaarheden, ervoor zorgen dat de mensen die hun producten gebruiken naar behoren worden geïnformeerd om beslissingen te nemen over de opwaardering. Dit omvat de belangrijkste informatie dat een update beveiligingsrelevante wijzigingen bevat, het openen van een CVE om het probleem te volgen en erover te communiceren, en mogelijk uw klanten op de hoogte te stellen. Ik denk dat het vooral redelijk is om dit aan te nemen als het product over CVE gaat en informatie geeft over kwetsbaarheden in de software. Ik put ook troost uit de snelle reactie, redelijke hersteltijden en open communicatie met de persoon die de aanval meldt.
In FOSSA, Snyk en WhiteSource was de kwetsbaarheid gerelateerd met bellen naar een externe pakketbeheerder om afhankelijkheden te bepalen en u in staat te stellen de uitvoering van uw code te orkestreren door aanraak- en promptopdrachten op te geven in de gradlew- en Podfile-bestanden.
En Snyk en WhiteSource vonden ook een kwetsbaarheid in verband met de commando's van het startsysteem van de organisatie die Dockerfile heeft geparseerd (in Snyk tot en met Dockefile zou je bijvoorbeeld de ls utility (/bin/ls) kunnen vervangen, veroorzaakt door de scanner en in WhiteSurce zou je de code kunnen vervangen door de argumenten in de vorm van 'echo' ; tik op /tmp/hacked_whitesource_pip;=1.0' ").
In Anchore werd de kwetsbaarheid veroorzaakt door het gebruik van het hulpprogramma skopeo werken met docker-afbeeldingen. De bewerking werd teruggebracht tot het toevoegen van parameters van de vorm '”os”: “$ (touch hacked_anchore)”' aan het manifest.json-bestand, die worden vervangen bij het aanroepen van skopeo zonder de juiste escape (alleen de tekens "; & < zijn verwijderd > ", maar de constructie "$ ( ) ").
Dezelfde auteur heeft een onderzoek uitgevoerd naar de effectiviteit van kwetsbaarheidsdetectie niet gepatcht via beveiligingsscanners van docker-containers en het niveau van valse positieven.
Daarnaast de auteur stelt dat verschillende van deze tools gebruik direct pakketbeheerders om afhankelijkheden op te lossen. Dit maakt ze bijzonder moeilijk te verdedigen. Sommige afhankelijkheidsmanagers hebben configuratiebestanden waarmee shellcode kan worden opgenomen.
Zelfs als deze gemakkelijke manieren op de een of andere manier worden afgehandeld, betekent het onvermijdelijk dat het bellen van deze pakketbeheerders geld kost. Dit maakt het op zijn zachtst gezegd niet gemakkelijk om de aanvraag te verdedigen.
De testresultaten van 73 afbeeldingen met kwetsbaarheden bekend, evenals een evaluatie van de effectiviteit om de aanwezigheid van typische toepassingen in afbeeldingen te bepalen (nginx, kater, haproxy, gunicorn, redis, ruby, node), kan worden geraadpleegd binnen de geplaatste post In de volgende link.