Bevoorrechte containers

Wat is Bevoorrechte containers?

Een container is standaard geen beveiligingsgrens. Een proces dat als root in een container draait, is root op de kernel van de host, en een bevoorrechte container met een host-mount kan overal op de machine schrijven waarop hij draait. Deze oefening behandelt een container-escape: bekijk hoe een aanvaller code-executie binnen een container omzet in controle over de host, en werk daarna aan de echte oplossing met een non-root gebruiker, ingetrokken capabilities en een alleen-lezen root-bestandssysteem.

Wat je leert in Bevoorrechte containers

• Containerisolatie is een set kernel-functies, geen grens. Root in de container is root op de kernel van de host, dus elk gat in die isolatie is direct te misbruiken.
• Feitelijk alle capabilities en toegang tot host-devices, waardoor het grootste deel verdwijnt van wat de container van de host scheidt.
• Draai als non-root-gebruiker, laat capabilities vallen, en stop met het meegeven van --privileged en de host mount.
• Een aanvaller die code execution bereikt, kan geen tools of persistentie in de container schrijven, waardoor de foothold veel moeilijker uit te bouwen is.

Bevoorrechte containers — Trainingsstappen

1. Een shell in de container

   Bob heeft het gemunt op Vosswark, een logistiek platform waarvan de media-service uploads van klanten schaalt en transcodeert. Een ongepatchte image-library in die service gaf hem remote code execution, en hij heeft nu een shell die daarin draait. Hoe hij binnenkwam is niet het interessante deel. Wat de container hem daarna laat doen, wel.

2. Wie ben ik, en wat kan ik doen

   Twee vragen bepalen of dit steunpunt een doodlopend spoor is of een deur: als welke gebruiker het proces draait, en wat de kernel die gebruiker toestaat te doen. Eén bestand beantwoordt ze allebei.

3. Wat bevoorrecht zijn daadwerkelijk opleverde

   Bevoorrecht betekent dat de gebruikelijke beperkingen niet worden toegepast. Bob controleert het meest waardevolle gevolg daarvan: of er iets van de host rechtstreeks aan de container is gegeven.

4. De sleutel van de host stelen

   De container was een middel, geen doel. Wat Bob wil, staat op de machine eronder, in de ene map die van één gecompromitteerde host een steunpunt over de hele vloot maakt.

5. Wat de escape mogelijk maakte

   Even stilstaan bij het mechanisme voordat de schade wordt opgeteld.

6. Een weg terug achterlaten

   De sleutel lezen is diefstal. Naar de host schrijven is persistentie. Omdat de mount niet alleen-lezen is, kan Bob zijn eigen publieke sleutel toevoegen aan de authorized_keys van de host, en vanaf dat moment heeft hij de gestolen sleutel helemaal niet meer nodig. Het toevoegen print niets, precies zoals in een echte shell. Die stilte is precies het punt: niets hieraan ziet eruit als een aanval.

7. Tel wat één container kon bereiken

   Bob heeft nu de eigen sleutel van de host in handen en heeft er zijn eigen sleutel naast geplant. De media-worker was een service met lage waarde die uploads van klanten afhandelde. Zoals geconfigureerd was het ook een route naar elke machine die die sleutel vertrouwt, en een deur die Bob naar believen weer kan openen.

8. De host meldt een bestandsleesactie

   Vosswark draait file integrity monitoring op zijn hosts. Het maakt niet uit welke container iets deed; het meldt dat het eigen sleutelmateriaal van de host is gelezen.

9. Bekijk hoe hij werd gestart

   Het Dockerfile beschrijft wat er in een image zit. Het zegt niets over de flags waarmee een container werd gestart, en die flags zijn waar dit incident zich afspeelt. Alleen de host kan die vraag beantwoorden.

10. Open het Dockerfile

    Er zijn twee helften om te repareren en ze staan in verschillende bestanden. De image bepaalt als wie het proces draait; de deployment bepaalt wat dat proces mag aanraken. Begin met de image.