For nylig blev kendt gennem et blogindlæg, resultaterne af testværktøjer til at identificere sårbarheder unpatched og identificere sikkerhedsproblemer i isolerede Docker-containerbilleder.
Testen viste, at 4 af de 6 scannere af kendte Docker-billeder havde kritiske sårbarheder der gjorde det muligt at angribe selve scanneren og udføre dens kode på systemet, i nogle tilfælde (for eksempel ved brug af Snyk) med root-rettigheder.
For et angreb, en angriber behøver kun at starte verifikation af din Dockerfile o manifest.json, som inkluderer specielt formaterede metadata, eller placer podfilen og gradlew-filerne inde i billedet.
Det lykkedes os at opsætte udnyttelsesprototyper til WhiteSource, Snyk, Fossa og Anchore-systemer.
El paquete Claire, som oprindeligt blev skrevet med sikkerhed i tankerne, viste den bedste sikkerhed.
Ingen problemer identificeret i Trivy-pakken og som et resultat blev det konkluderet, at Docker containerscannere skulle køres i sandkasser eller kun bruges til at verificere dine egne billeder, og også være forsigtig, når du forbinder sådanne værktøjer til automatiserede kontinuerlige integrationssystemer.
Disse scannere gør komplicerede og fejltilbøjelige ting. De beskæftiger sig med docker, trækker lag/filer, grænseflader med pakkeadministratorer eller analyserer forskellige formater. At forsvare dem, mens man forsøger at imødekomme alle use cases for udviklere, er meget vanskeligt. Lad os se, hvordan de forskellige værktøjer forsøger at gøre det:
Den ansvarlige afsløringsscore afspejler min personlige mening: Jeg tror, det er vigtigt for softwareleverandører at være modtagelige over for sikkerhedsproblemer, der rapporteres til dem, at være ærlige og gennemsigtige om sårbarheder, for at sikre, at de mennesker, der bruger deres produkter, er behørigt informeret til at træffe beslutninger om opgraderingen. Dette inkluderer de vigtigste oplysninger om, at en opdatering har sikkerhedsrelevante ændringer, åbning af en CVE for at spore og kommunikere om problemet og potentielt underrette dine kunder. Jeg synes, det er særligt rimeligt at antage dette, hvis produktet handler om CVE, der giver information om sårbarheder i softwaren. Jeg trøster mig også med den hurtige reaktion, rimelige afhjælpningstider og den åbne kommunikation med den person, der rapporterer angrebet.
I FOSSA, Snyk og WhiteSource var sårbarheden relateret med at ringe til en ekstern pakkemanager for at bestemme afhængigheder og give dig mulighed for at orkestrere udførelsen af din kode ved at angive berørings- og promptkommandoer i gradlew- og Podfile-filerne.
En Snyk og WhiteSource fandt også en sårbarhed forbundet med startsystemets kommandoer fra organisationen, der parsede Dockerfile (for eksempel i Snyk til Dockefile kunne du erstatte ls-værktøjet (/bin/ls), forårsaget af scanneren, og i WhiteSurce kunne du erstatte koden gennem argumenterne i form af 'echo' ; tryk på /tmp/hacked_whitesource_pip;=1.0' ").
I Anchore var sårbarheden forårsaget af brugen af skopeo-værktøjet at arbejde med docker-billeder. Operationen blev reduceret til at tilføje parametre i formen '"os": "$ (touch hacked_anchore)"' til manifest.json-filen, som erstattes, når man kalder skopeo uden korrekt escape (kun tegnene "; & < blev fjernet > ", men konstruktionen "$ ( ) ").
Samme forfatter udførte en undersøgelse om effektiviteten af sårbarhedsdetektion ikke lappet gennem sikkerhedsscannere af havnemandscontainere og niveauet af falske positiver.
Desuden forfatteren hævder, at flere af disse værktøjer bruge pakkeadministratorer direkte til at løse afhængigheder. Det gør dem særligt svære at forsvare. Nogle afhængighedsadministratorer har konfigurationsfiler, der tillader inkludering af shellcode.
Selvom disse nemme måder håndteres på en eller anden måde, vil det uundgåeligt betyde, at man skal bruge penge på at ringe til disse pakkeadministratorer. Dette gør det mildt sagt ikke let at forsvare ansøgningen.
Testresultaterne af 73 billeder, der indeholder sårbarheder kendt, samt en evaluering af effektiviteten til at bestemme tilstedeværelsen af typiske applikationer i billeder (nginx, tomcat, haproxy, gunicorn, redis, rubin, node), kan konsulteres inden for den post, der er lavet I det følgende link.