Docker 빌드 이력에 남은 GitHub 토큰, 25분 만에 관리자 권한

컨테이너 하나에서 나온 관리자 권한

추론 서비스업체를 하나 정하기 전에, 그 회사가 받아들일 만한 보안 수준인지 먼저 점검해 보는 보안 스타트업이 있어요. 바로 자율 해킹 에이전트 Strix를 만드는 팀인데요. 그들은 자체 데이터와 고객 데이터, 모델, 코드를 외부 서비스에 맡기기 전에 상대편을 직접 공격해 보는 방식으로 검증하고 있어요. 기업가치가 약 130억 달러(Series F 투자 기준)로 평가된 추론 플랫폼 Baseten을 후보로 검토할 때도 예외는 아니었어요.

그들이 *.baseten.co를 겨냥해 자격 증명이나 소스 코드 없이 자율 점검을 돌렸는데, 약 25분 만에 내부 GitHub 저장소 관리자 권한을 가진 유효한 토큰을 찾아냈어요. 평범한 회사에서 벌어져도 충격적인 사건인데, 아이러니하게도 노출된 이미지는 3년 전에 만들어진 오래된 빌드였어요. 이번 사례는 "오래된 컨테이너 이미지"가 보안 점검에서 얼마나 쉽게 놓치는 영역인지 보여주는 좋은 예시가 돼요.

임의의 코드 없이 밟아간 25분

Strix는 일반적인 펜테스트가 그렇듯 리콘(정보 수집)부터 시작했어요. 호스트를 열거하고 인증서 로그를 훑으며 공격 표면을 매핑하다가 gcp-us-east4-zlw.registry.baseten.co라는 Harbor 레지스트리를 발견했어요. Harbor는 컨테이너 이미지를 프로젝트 단위로 묶어 관리하는 컨테이너 레지스트리 도구인데, 그중 한 프로젝트가 아무 인증 없이 접근 가능한 공개 상태였어요.

공개 프로젝트에서는 저장소 목록을 볼 수 있고, 익명 풀 토큰을 발급받아 이미지 매니페스트와 실제 블롭(이미지 데이터)까지 내려받을 수 있었어요. 대상은 baseten/baseten-app이라는 이미지였죠. 이쯤에서 "레지스트리가 공개돼 있다"라고만 신고하고 넘어가기 쉬운데, Strix는 오탐(false positive)을 피하려고 이미지 안에 실제 피해가 있는지부터 확인해요.

이미지를 내려받아 가장 먼저 발견한 건 AWS 키 한 쌍이었어요. 그런데 읽기 전용 sts:GetCallerIdentity 호출로 확인해 보니 InvalidClientTokenId가 돌아왔어요. 이미 죽은 키였던 거죠. 하지만 여기서 멈추지 않고 다른 단서를 계속 찾았어요.

파일보다 빌드 이력에 토큰이 남아 있었어요

Strix는 이미지 레이어를 내려받아 비밀 정보 스캐너인 TruffleHog를 돌리고, 이미지 설정(config)도 직접 검사했어요. 그런데 파일시스템 레이어가 아니라 이미지 설정에 포함된 history[].created_by 필드에서 문제를 찾았어요. 이 필드는 어느 빌드 단계가 어떻게 실행됐는지 기록하는 곳인데, 어떤 RUN 명령에 GITHUB_TOKEN의 실제 값이 그대로 박혀 있었던 거죠.

이 토큰으로 GitHub에 읽기 전용 GET /user 요청을 보내자 HTTP 200이 돌아왔고, 계정명은 basetenbot으로 확인됐어요. 흥미로운 점은 컴퓨터 이미지에는 파일시스템 레이어뿐 아니라 이미지에 대한 정보와 빌드 이력을 담은 설정 블롭도 있고, 이 설정이 이미지와 함께 내려받아진다는 사실이에요. 덕분에 자격 증명 파일을 지워도 빌드 이력에 토큰 사본이 남아 있으면 노출이 해소되지 않아요.

출처: Strix 공식 블로그

그 토큰이 열어줄 수 있었던 권한

토큰 하나가 의미를 지니려면 권한이 중요해요. GitHub가 반환한 X-OAuth-Scopes: repo와 계정이 속한 조직인 basetenlabs를 확인한 뒤, 저장소별 권한을 읽기 전용 요청으로 검증했어요.

주력 제품 저장소의 관리자·푸시 권한은 다른 기업들의 모델 실행에 쓰이는 추론 플랫폼 코드 자체를 바꿀 수 있는 수준이었어요. GitOps 저장소는 클러스터의 목표 상태를 담아 인프라에 적용하는 곳이라 프로덕션 인프라 변경으로 이어질 수 있는 경로가 있었죠. Homebrew tap은 실제 개발자 기기에 CLI를 배포하는 경로라서, 변조되면 공급망 공격으로 확대될 위험도 있었고요.

검증팀은 오탐이 아니라고 판단되는 시점에 더 이상 진행하지 않고 즉시 신고로 넘어갔어요.

왜 오래된 이미지가 이렇게 되기 쉬운가

문제의 빌드는 비공개 GitHub 의존성을 가져오려고 토큰을 빌드 인자로 넘겼어요. 코드 형태로 보면 대략 이렇게 생겼어요.

ARG GITHUB_TOKEN
RUN GITHUB_TOKEN=${GITHUB_TOKEN} bash -c '\
  if [[ "${GITHUB_TOKEN}" != "" ]]; then \
    git config --global --add url."https://${GITHUB_TOKEN}@github.com/".insteadOf "git@github.com:"; \
  fi'

비공개 의존성이 필요해서 토큰을 넘기고 Git이 인증하는 방식이라 겉보기엔 잘 돌아가요. 그런데 Docker는 빌드 인자를 이미지 메타데이터와 이력에 기록할 수 있고, 이번에는 실제 토큰 값까지 남았어요. 게다가 git config --global이 인증 정보가 포함된 URL을 Git 설정 파일에 기록하면서 두 번째 노출 경로가 생겼죠.

문제가 된 빌드 단계는 2023년 3월 3일에 실행됐는데, 2026년 7월 검증 시점까지 3년 넘게 토큰이 유효했어요.

우리 컨테이너에서 확인해 볼 것

이번 사례에서 얻을 실용적인 점검 항목을 정리하면 아래와 같아요.

1. 익명 풀 범위를 확인해요. 로그인 없이 받을 수 있는 이미지를 오래된 태그와 오래 방치한 프로젝트까지 포함해 점검해요.
2. 빌드 이력을 봐요. docker history --no-trunc나 설정 블롭의 history[].created_by를 검사하고, 이미지 레이어도 함께 확인해요.
3. 빌드 인자에서 비밀을 제거해요. BuildKit의 비밀 마운트를 쓰고, 그 비밀을 소비하는 명령이 이미지에 다시 기록하지 않는지도 확인해요.
4. 빌드 토큰의 권한과 만료를 확인해요. 의존성 다운로드에는 해당 의존성의 읽기 권한만 필요해요. 관리자 권한을 주고 만료일 없이 쓰면 유출 피해가 커져요.

신속했던 Baseten의 대응

이번 사건이 특별했던 건 피해 기업의 대응이 빨랐다는 점이에요. 7월 13일 오후 11시 10분에 유효한 토큰과 공개 Harbor 프로젝트, 저장소 권한이 신고됐는데, 다음 날 오전에 Harbor 프로젝트가 비공개로 전환됐어요. 토큰이 여전히 작동한다는 사실을 알리자 오후 4시 34분에 보안팀 안톤(Anton)이 심각도를 Critical로 확인하고 토큰 교체까지 마쳤어요. 내려받은 이미지의 안전한 삭제를 요청받았고요.

같은 점검에서 찾은 건이 낮은 두 취약점도 추가로 전달됐어요. 7월 17일에 나머지 조치가 완료됐고, 9월에 공개 계획과 초안이 공유됐으며 팀은 감사 선물로 티셔츠와 맨투맨을 받았다고 해요.

Baseten은 이미 AI 보안 도구를 쓰고 있었는데도 이 오래된 이미지의 토큰이 관리자 권한을 유지하고 있었어요. 이 점이 이번 사건의 핵심 교훈이에요. 애플리케이션과 소스 저장소만 열심히 점검한다고 해서 오래된 컨테이너 이미지를 지나치지 않는 건 아니거든요.

AI가 공격자와 같은 경로를 따라갈 수 있다는 점을 감안하면, 운영하는 쪽이 먼저 이런 빌드 이력을 뒤져 유효한 관리자 토큰을 찾아내는 편이 현실적인 대응이라고 볼 수 있어요.

참고 링크

• Strix 공식 블로그 — Baseten case study
• Strix 오픈소스 저장소 (GitHub)
• Docker의 빌드 변수 보안 경고
• Docker BuildKit 시크릿 마운트
• GeekNews 원문 토픽