Kwetsbare Base Images

Wat is Kwetsbare Base Images?

De dependencies van een applicatie worden gecontroleerd. Het onderliggende besturingssysteem vaak niet. Een zwevende base image-tag betekent dat de laag onder je code verandert zonder dat iemand daartoe besluit, en een verouderde tag betekent dat bekende kwetsbaarheden bij elke deploy naar productie gaan. Deze oefening behandelt een uitbuitbare fout in de OS-laag: bekijk hoe een aanvaller die gebruikt, pin daarna het base image op digest, stap over naar een slank base image en laat de pipeline afhangen van een scan.

Wat je leert in Kwetsbare Base Images

• De laag onder je applicatie verandert zonder dat iemand daartoe besluit, waardoor je niet kunt zeggen welke OS-pakketten in productie draaien of wanneer ze voor het laatst zijn gewijzigd.
• Dat elke build precies dezelfde bytes binnenhaalt, zodat een wijziging aan de base een bewuste, toetsbare commit is in plaats van een stille gebeurtenis.
• Een bewuste rebuild-cadans, want een gepinde base ontvangt geen patches meer totdat iemand de pin verplaatst.
• De fout zit in de OS-laag onder de applicatie, dus geen enkel dependencybestand vermeldt hem, en de oplossing is een wijziging van het base image in plaats van een pakketupdate.

Kwetsbare Base Images — Trainingsstappen

1. De scheduler-image in de registry

   Bob heeft leestoegang tot de container registry van Bremhollow via een gelekt robot-token. Hij kijkt niet naar code — hij kijkt naar hoe vers de images zijn, want een service die al een tijd niet opnieuw is gebouwd, is een service waarvan de base image stilletjes is verouderd. De scheduler verwerkt geüploade afbeeldingen, wat maakt waarop deze is gebouwd erg interessant voor hem. Open de pagina ervan en bekijk wat de registry zegt.

2. Een image die stilstond

   De registry hoeft niet fout te zijn om Bob te helpen. Eén regel vertelt hem dat de gedeployde image oud is en gebouwd op een floating base.

3. Scan de base op een ingang

   Bob pullt de image en draait er een vulnerability scanner overheen, hetzelfde gereedschap dat een verdediger zou gebruiken. Hij is niet geïnteresseerd in de applicatiecode. Hij wil een bekende, gepubliceerde kwetsbaarheid in de besturingssysteempakketten die de base image heeft meegesleept, want die komen met werkende exploits.

4. Maak van de CVE een shell

   Een scannerbevinding is geen exploit totdat iemand hem uitvoert. CVE-2023-4863 heeft een publieke proof-of-concept: een geprepareerde WebP die libwebp laat overlopen op het moment dat deze wordt gedecodeerd. De scheduler decodeert elke geüploade afbeelding, dus Bob mount het PoC-bestand in een wegwerprun van de kwetsbare image en decodeert het — waarmee hij bewijst dat de bevinding een werkend remote-code-executionpad is voordat hij ooit productie aanraakt.

5. Waar de kwetsbaarheid zich bevindt

   Eén moment stilstaan bij het mechanisme voordat de respons begint.

6. De scanner markeert de vloot

   Bremhollow heeft image scanning toegevoegd aan zijn pipeline, en de eerste volledige doorlichting van wat al in productie draait, kwam terug met iets dat niet kan wachten.

7. Zie het zelf

   Voordat ze iets wijzigt, draait Alice dezelfde scan op de gedeployde image. Ze wil de bevinding zien, waar deze zich bevindt, en wat de base eigenlijk is.

8. Open het Dockerfile

   De base image wordt gekozen in één regel van het Dockerfile. Alles wat de scanner vond, kwam mee via die regel.

9. Vind de floating base

   Er staat hier niets verkeerd gespeld of misvormd. Het probleem is één regel die minder zegt dan hij zou moeten.

10. Pin de base op digest

    Een tag is een label dat iemand kan verplaatsen; een digest is de content-fingerprint van de image en kan nooit naar iets anders wijzen. Alice pint de base op een exacte, actuele, slanke node:18 aan de hand van zijn digest, zodat elke build vanaf nu dezelfde geauditeerde bytes pullt, en het verplaatsen van die pin een bewuste, controleerbare wijziging wordt.