Bevoorrechte containers

Bevoorrechte containers

Root in de container is root op de hostkernel.

Wat is Bevoorrechte containers?

Een container is standaard geen beveiligingsgrens. Een proces dat binnen één kernel als root draait, is root op de host-kernel, en de geprivilegieerde vlag plus een host-bind-mount verwijdert het weinige dat ertussen overblijft. Je voert de ontsnapping uit: lees de toegekende mogelijkhedenset, vermeld het hostbestandssysteem via de mount, steel de root-SSH-sleutel en voeg je eigen sleutel toe voor persistentie. De oplossing omvat twee bestanden. U voegt een niet-root GEBRUIKER toe aan de Dockerfile en laat vervolgens de bevoorrechte vlag en alle mogelijkheden in Compose vallen.

Wat je leert in Bevoorrechte containers

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.

Dekking van beveiligingsframeworks

CWE

  • CWE-250 Execution with Unnecessary Privileges
  • CWE-269 Improper Privilege Management

MITRE ATT&CK

  • T1611 Escape to Host

CIS Controls

  • CIS 4 Secure Configuration of Enterprise Assets and Software
  • CIS 6 Access Control Management

NIST CSF

  • PR.AT-02 Individuals in specialized roles are provided with awareness and training so that they possess the knowledge and skills to perform relevant tasks with cybersecurity risks in mind
  • PR.PS Platform Security
  • PR.AA Identity Management, Authentication, and Access Control