미패치 TeamCity로 AWS 자격증명 유출 — JetBrains·법원 SaaS 침해가 개발자에게 남긴 것

솔직히 이런 뉴스는 이제 놀랍지도 않다. 그런데 이번 두 건은 결이 좀 다르게 다가왔다. TeamCity는 내가 직접 운영해 본 도구고, 법원 SaaS 침해는 "우리가 아무리 잘해도 벤더가 뚫리면 끝"이라는, 개발자가 제일 무력해지는 시나리오라서다. 그래서 이 글은 사건 요약보다 그래서 내 파이프라인에서 뭘 바꿔야 하나에 무게를 뒀다. 확실치 않은 세부(정확한 취약점 번호, 유출 레코드 수 등)는 보도 수준에서만 짚고, 대응은 구체적으로 간다.

표의 세부는 보도 기준 요약이다. 유출 레코드 수, 정확한 취약점 식별자 등 확정되지 않은 값은 의도적으로 넣지 않았다. 출처: The Hacker News (2026-09).

무슨 일이 있었나 — 두 사건 요약

핵심만 먼저. JetBrains 사건은 인터넷에 노출된 채 패치되지 않은 TeamCity 인스턴스가 초기 침투 지점이 됐고, 거기서 AWS 자격증명이 탈취됐다. Thomson Reuters 사건은 법원들이 쓰는 사건관리 플랫폼 C-Track이 침해돼, 미국 11개 주와 캐나다 법원의 기록에 무단 접근이 발생했다.

C-Track 쪽은 보도에서 사회보장번호(SSN)와 봉인된(비공개) 기록까지 노출됐을 가능성이 제기됐다. 다만 정확히 어떤 데이터가 얼마나 빠져나갔는지, 침해 원인이 무엇이었는지는 이 시점에 확정적으로 말하기 어렵다. 법원 기록은 이혼·양육권·형사 봉인 건처럼 극도로 민감한 정보가 섞이는 곳이라, 규모보다 데이터의 성격 자체가 무겁다.

TeamCity 쪽은 이번 사건의 구체적인 취약점 번호가 공개되지 않았다. 하지만 TeamCity는 과거에도 인증 우회로 원격 코드 실행까지 이어지는 치명적 취약점이 여러 번 나온 도구다(대표적으로 2024년의 CVE-2024-27198, CVSS 9.8 인증 우회). 패턴은 늘 같다. 관리 콘솔이 인터넷에 열려 있고, 버전이 밀려 있고, 그 안에 클라우드로 가는 열쇠가 들어 있다.

왜 CI/CD 도구가 최고의 표적인가

CI/CD 서버는 가장 강한 권한을 가진 채 가장 자주 방치되는 시스템이기 때문이다. 빌드 서버는 소스 코드 전체를 읽고, 프로덕션에 배포하고, 클라우드 계정·레지스트리·시크릿 매니저에 접근한다. 즉 여기 하나만 뚫으면 공격자는 코드, 아티팩트, 인프라를 한 번에 손에 넣는다. "빌드 도구"라는 얌전한 이름에 비해 실제 권한은 사실상 관리자다.

문제는 이런 도구가 보안 우선순위에서 늘 뒤로 밀린다는 거다. 프로덕션 웹서버는 다들 신경 써서 패치하는데, "내부용" 빌드 서버는 방화벽 뒤에 있다고 믿고 몇 달씩 버전을 안 올린다. 그런데 원격 근무·클라우드 이전 과정에서 이 "내부용"이 슬그머니 공인 IP에 물려 있는 경우가 정말 많다. 나도 예전에 팀 인수인계받고 나서, 아무도 모르게 인터넷에 열려 있던 CI 대시보드를 발견하고 식겁한 적이 있다.

공급망(supply chain) 관점에서 더 무섭다. 공격자가 CI를 장악하면 단순히 데이터를 훔치는 데 그치지 않고, 빌드 산출물에 악성 코드를 심어 당신의 고객에게까지 배포할 수 있다. SolarWinds가 그랬다. 그래서 CI/CD는 "털리면 우리만 손해"가 아니라 "털리면 우리 고객까지 감염"인 시스템이라는 전제로 다뤄야 한다.

미패치 TeamCity, 어떻게 클라우드까지 번지나

경로는 대개 노출된 관리 콘솔 → 인증 우회/RCE → 저장된 클라우드 자격증명 탈취 → 클라우드 계정 이동이다. TeamCity 같은 CI에는 배포용으로 AWS 키, 레지스트리 토큰, 서명 키가 커넥션·시크릿 형태로 저장돼 있다. 서버가 뚫리면 이 값들이 통째로 노출된다. 여기에 인증 우회 취약점이 있으면 로그인조차 필요 없다.

그래서 방어의 1순위는 두 가지다. (1) 인터넷에 노출하지 말 것, (2) 즉시 패치할 것. 순서도 이게 맞다. 패치가 밀렸어도 인터넷에 안 열려 있으면 공격 표면이 확 줄고, 노출돼 있으면 패치 하루 늦는 사이에 스캐너가 먼저 찾는다. 내가 CI를 인수하면 제일 먼저 하는 게 "이거 외부에서 접근되나"를 확인하는 일이다.

# 1) 내 TeamCity가 외부에 노출됐는지부터 확인 (외부망에서 실행)
curl -sS -o /dev/null -w "%{http_code}\n" https://ci.example.com/login.html
# 200 이 뜨면 로그인 페이지가 공개돼 있다는 뜻 → 즉시 접근 제어 필요

# 2) 버전 확인 (내부에서). 밀려 있으면 최신 유지보수 릴리스로 업그레이드
curl -sS https://ci.example.com/app/rest/server \
  -H "Authorization: Bearer $TC_TOKEN" | grep -o '"version":"[^"]*"'

# 3) 급하면 우선 네트워크로 막는다 (nginx 앞단에서 사내 IP만 허용)
#   location / { allow 10.0.0.0/8; allow 192.168.0.0/16; deny all; }

운영 원칙으로는 CI 콘솔을 VPN 또는 사내망 뒤로 두고, 꼭 외부 접근이 필요하면 IdP(SSO) + 다중 인증을 앞에 세운다. 그리고 CI 노드는 인터넷으로 나가는 아웃바운드도 최소화한다 — 자격증명이 탈취돼도 공격자가 밖으로 빼내기 어렵게 만드는 두 번째 벽이다.

자격증명이 진짜 급소 — 최소 권한과 로테이션

가장 확실한 대비책은 애초에 훔칠 장기 자격증명을 CI에 두지 않는 것이다. AWS라면 정적 액세스 키(AKIA...) 대신 OIDC 기반 단기 토큰으로 역할을 그때그때 위임받게 하면, 서버가 뚫려도 훔칠 영구 키가 없다. 토큰은 몇 분~한 시간이면 만료된다. 이게 이번 같은 사고에서 피해 반경을 가장 크게 줄이는 단 하나의 변경이다.

# GitHub Actions → AWS: 장기 키 없이 OIDC로 단기 역할 위임
permissions:
  id-token: write   # OIDC 토큰 발급 권한 (이게 없으면 동작 안 함 — 자주 빠뜨림)
  contents: read
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/ci-deploy
          aws-region: ap-northeast-2
          # access-key-id / secret 를 넣지 않는다 = 저장된 장기 키가 없다

이미 장기 키가 곳곳에 박혀 있다면, 먼저 오래된 키부터 찾아내 로테이션한다. 그리고 그 역할에 붙은 권한이 정말 최소한인지 본다. 배포용 CI 역할에 AdministratorAccess가 붙어 있는 걸 나는 너무 자주 본다. 배포에 필요한 리소스만 명시적으로 허용하고, 나머지는 다 막아야 한다.

# 90일 넘은 활성 AWS 액세스 키 전수 조사 → 로테이션 후보
aws iam list-users --query 'Users[].UserName' --output text | tr '\t' '\n' | \
while read u; do
  aws iam list-access-keys --user-name "$u" \
    --query "AccessKeyMetadata[?Status=='Active'].[UserName,AccessKeyId,CreateDate]" \
    --output text
done
# 오래된 키는: 새 키 발급 → 코드/시크릿 교체 → 구 키 비활성화 → 확인 후 삭제

법원 SaaS 침해 — 남의 서버가 뚫렸을 때

C-Track 사건의 교훈은 "데이터를 맡긴 벤더의 보안이 곧 내 보안"이라는 점이다. 우리 코드가 완벽해도, 우리가 통제할 수 없는 서드파티 SaaS가 뚫리면 우리 사용자 데이터가 새어 나간다. 법원들이 C-Track을 직접 짜지 않았듯, 대부분의 조직은 결제·CRM·분석·인증을 남의 SaaS에 맡긴다. 그 하나하나가 잠재적 침해 경로다.

개발자로서 할 수 있는 건 "믿고 맡기기"를 "검증하고 최소한으로 맡기기"로 바꾸는 거다. SaaS에 넘기는 데이터를 최소화하고(정말 SSN까지 줘야 하나?), 가능한 필드는 우리 쪽에서 암호화·토큰화해서 보내고, 벤더의 접근 로그와 데이터 처리 계약(DPA)·침해 통지 조항을 확인해 둔다. 벤더가 뚫렸을 때 몇 시간 안에 우리에게 알려주기로 돼 있는가? 대부분은 이걸 계약할 때 안 본다.

그리고 SaaS 연동에 쓰는 API 키·웹훅 시크릿·OAuth 토큰도 위의 CI 자격증명과 똑같이 다뤄야 한다. 최소 권한 스코프, 정기 로테이션, IP 허용목록, 그리고 이상 접근 알림. 벤더 침해 뉴스가 뜨면, 그 벤더에 발급해 둔 우리 토큰을 즉시 무효화·재발급하는 게 첫 대응이다.

침해가 의심될 때 — 대응 플레이북

순서가 전부다. 당황해서 서버부터 재부팅하면 증거가 날아간다. 실무에서 통하는 순서는 격리 → 자격증명 무효화 → 조사 → 복구 → 통지다. CI 침해든 SaaS 벤더 침해든 뼈대는 같다.

1. 격리 — 해당 시스템의 네트워크 접근을 끊는다. 단, 포렌식을 위해 전원을 끄기보다 네트워크만 분리하고 스냅샷·메모리 덤프를 확보한다.
2. 자격증명 전면 무효화 — 노출됐을 수 있는 모든 키·토큰·세션을 로테이션·폐기한다. CI에 저장된 클라우드 키, 서명 키, 서드파티 토큰이 1순위다.
3. 영향 조사 — CloudTrail·감사 로그로 탈취된 자격증명이 무엇을 했는지 추적한다. 새 IAM 사용자 생성, 비정상 리전에서의 API 호출, 대량 다운로드가 신호다.
4. 복구 — 깨끗한 상태에서 재구축한다. 뚫린 서버를 "청소"해서 재사용하지 말고 새로 세운다. 심어진 백도어를 놓치기 쉽다.
5. 통지 — 법적 의무(GDPR 72시간, 국내 개인정보보호법 등)와 계약상 통지 기한을 지켜 이해관계자·이용자에게 알린다.

# 탈취 자격증명이 AWS에서 뭘 했는지 CloudTrail로 역추적 (예시)
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAEXAMPLE \
  --start-time 2026-08-01T00:00:00Z \
  --query 'Events[].{time:EventTime,name:EventName,src:Username}' --output table
# 주목: CreateUser, CreateAccessKey, PutUserPolicy, 비정상 리전의 RunInstances

같은 시기 CISA KEV 추가 7건 — 지금 확인할 것

이번 advisory에서 CISA가 KEV에 추가한 7건은 실제로 악용되고 있는 취약점이다. KEV 등재의 의미는 명확하다 — 이론이 아니라 지금 공격에 쓰이고 있으니 즉시 패치하라는 뜻이다. 아래 목록에서 개발·CI·AI 인프라 도구가 절반 이상인 점을 눈여겨보라.

강조한 세 줄 — JFrog Artifactory(아티팩트 레지스트리), Kestra(워크플로 오케스트레이션), LiteLLM(LLM 게이트웨이) — 은 전형적인 개발·데이터·AI 파이프라인 구성요소다. 아티팩트 레지스트리 인증 우회는 TeamCity 사건과 정확히 같은 결의 위협이다. 레지스트리가 뚫리면 악성 패키지를 정상 배포에 끼워 넣을 수 있으니까. 이 세 개를 쓰고 있다면 이 글을 덮고 지금 버전부터 확인하는 게 맞다.

자주 묻는 질문

TeamCity 같은 CI 서버, 어떻게 지켜야 하나요?

세 가지가 핵심입니다. 첫째, 인터넷에 노출하지 말고 VPN/사내망 뒤에 두거나 앞단에 SSO+MFA를 세웁니다. 둘째, 유지보수 릴리스를 즉시 적용해 알려진 인증 우회·RCE를 막습니다. 셋째, CI에 장기 클라우드 키를 저장하지 말고 OIDC 단기 토큰으로 전환하며, 저장된 시크릿은 최소 권한으로 두고 정기 로테이션합니다. 노출 차단이 패치보다 먼저입니다.

패치만 하면 침해는 끝난 건가요?

아닙니다. 인증 우회·RCE 계열은 패치 전에 이미 자격증명을 훔쳤거나 백도어를 심어뒀을 수 있습니다. 패치와 동시에 저장된 모든 키·토큰을 로테이션하고, 관리자 계정·최근 설정 변경·에이전트 목록을 점검하고, CloudTrail 등 로그로 탈취 자격증명의 활동을 역추적해야 합니다. 뚫린 서버는 청소보다 재구축이 안전합니다.

AWS 자격증명 유출 피해를 줄이는 가장 확실한 방법은?

장기 액세스 키 자체를 없애는 것입니다. OIDC 기반 키리스 인증으로 CI가 배포 때마다 수분짜리 단기 토큰을 발급받게 하면, 서버가 뚫려도 훔칠 영구 키가 없습니다. 여기에 역할 권한을 최소화하고(AdministratorAccess 지양), 아웃바운드 트래픽을 제한하면 탈취되더라도 피해 반경이 크게 줄어듭니다.

우리가 쓰는 SaaS 벤더가 뚫리면 개발자는 뭘 해야 하나요?

즉시 그 벤더에 발급한 API 키·웹훅 시크릿·OAuth 토큰을 무효화하고 재발급하세요. 그다음 우리가 그 벤더에 넘긴 데이터의 범위를 인벤토리로 확인해 영향받는 사용자를 산정하고, 계약상·법적 통지 의무를 이행합니다. 평소에 데이터 최소화, 필드 암호화, 접근 로그 확보, 침해 통지 조항을 갖춰 두면 이 대응이 훨씬 빨라집니다.

CISA KEV 목록은 왜 중요하고 어떻게 활용하나요?

KEV는 이론적 취약점이 아니라 실제로 악용이 확인된 취약점 목록이라, 패치 우선순위의 강력한 기준이 됩니다. 사용 중인 제품이 KEV에 오르면 CVSS 점수와 무관하게 최우선으로 처리해야 합니다. SBOM이나 자산 인벤토리와 KEV 피드를 대조해 "우리가 쓰는 것 중 지금 악용 중인 게 있나"를 자동으로 알리게 구성하는 걸 권합니다.

JFrog Artifactory, Kestra, LiteLLM을 쓰는데 지금 뭘 해야 하나요?

해당 KEV(CVE-2026-82329·49869·59822)에 대응하는 버전으로 즉시 업그레이드하고, 관리 인터페이스의 외부 노출 여부를 확인하세요. 특히 아티팩트 레지스트리 인증 우회는 악성 패키지를 정상 배포에 끼워 넣는 공급망 공격으로 이어질 수 있으니, 패치와 함께 저장 자격증명 로테이션과 최근 업로드·접근 로그 점검을 병행하는 게 안전합니다.

소규모 팀도 이걸 다 해야 하나요?

전부는 아니어도 우선순위는 분명합니다. 순서는 (1) CI·관리 콘솔 외부 노출 차단, (2) 장기 클라우드 키를 OIDC 단기 토큰으로 전환, (3) KEV 대조로 악용 중인 취약점부터 패치입니다. 이 세 가지만 해도 이번 두 사건 유형의 피해 대부분을 막거나 크게 줄일 수 있습니다. 나머지 로그·플레이북은 여력이 될 때 단계적으로 갖추면 됩니다.