우리 회사 TeamCity, 아직도 인터넷에 열려 있나요?

이미지 출처: BleepingComputer

사내 빌드 서버 주소를 외부망에서 그냥 쳐봤더니 로그인 화면이 멀쩡히 뜨는 걸 본 적이 있음. 개발팀은 "재택 근무자가 빌드 상태를 봐야 해서요"라고 했고, 보안팀은 그 화면을 그냥 지나쳤음. JetBrains가 TeamCity의 원격 코드 실행 결함을 최고 심각도로 공지할 때마다 제일 먼저 떠오르는 장면이 딱 그거임. 취약점 자체보다, 그 취약점이 닿을 수 있는 위치에 빌드 서버가 놓여 있었다는 사실이 훨씬 무거움.

핵심 요약

• TeamCity On-Premises에서 원격 코드 실행으로 이어지는 치명적 결함이 공지됨. 인증을 우회하거나 낮은 권한에서 서버 권한까지 올라가는 계열은 CI 서버 특성상 곧바로 최악의 결과로 이어짐
• 빌드 서버는 소스코드·서명키·배포 자격증명·클라우드 토큰이 한곳에 모인 자산이라, 한 대가 뚫리면 릴리스 산출물 전체를 신뢰할 수 없게 됨
• 패치 적용이 1순위, 인터넷 노출 차단이 2순위, 그리고 이미 당했다는 가정하에 계정·토큰·플러그인·빌드 스크립트를 되짚는 게 3순위임

왜 TeamCity만 유독 자주 표적이 되나

TeamCity 계열 결함이 반복적으로 크게 다뤄지는 이유는 제품이 특별히 허술해서가 아님. 공격자 입장에서 투자 대비 회수율이 압도적이기 때문임.

• 빌드 에이전트에 임의 명령을 실행시킬 수 있는 구조가 정상 기능임. 즉 관리자 권한 획득 = 원격 코드 실행이 사실상 동의어임
• 서버 안에 SSH 키, 아티팩트 저장소 자격증명, 코드 서명 인증서, 클라우드 배포 토큰이 평문에 가깝게 축적돼 있음
• 산출물이 그대로 고객·내부 사용자에게 배포되므로 공급망 공격의 출발점으로 쓰기 좋음. 2023년 CVE-2023-42793 사태에서 국가 배후 그룹들이 TeamCity를 대량으로 노렸던 이유가 정확히 이것이었음
• 사내 도구라는 이유로 패치 주기가 느리고, 다운타임 부담 때문에 업그레이드가 계속 밀림

공격 흐름 자체는 개념적으로 단순함. 인증 검사를 건너뛸 수 있는 경로로 관리자급 API에 접근 → 관리 토큰이나 계정을 생성 → 빌드 설정이나 플러그인 업로드 기능을 이용해 서버에서 코드를 실행. 상세한 요청 형태나 페이로드를 여기서 다룰 이유는 없고, 방어자가 기억할 건 "인증 우회 하나가 곧바로 서버 셸까지 이어지는 짧은 사슬"이라는 점임.

오늘 안에 끝내야 할 것

• 버전 확인부터. 관리자 화면 하단이나 /app/rest/server 응답에서 현재 버전을 확인하고, JetBrains가 공지한 수정 버전과 대조함. Cloud 사용자는 대체로 자동 반영되지만 On-Premises는 전적으로 운영자 몫임
• 패치를 미룰 수밖에 없다면 노출부터 끊음. 인터넷에서 직접 접근 가능한 TeamCity는 즉시 VPN이나 리버스 프록시 뒤로 넣고, 최소한 관리 경로와 REST API는 사내 대역·특정 IP로만 허용함
• 패치 후에도 안심 금지. 인증 우회형 결함은 패치 이전에 만들어진 토큰·계정이 그대로 살아남음. 패치는 문을 잠글 뿐, 이미 들어와 앉은 손님을 내보내진 않음

침해 흔적을 되짚는 순서

공지 시점 이전 최소 몇 주치를 대상으로 잡고 아래 순서로 봄. 개인적으로는 로그를 먼저 보는 것보다 "공격자가 남길 수밖에 없는 상태 변화"부터 훑는 쪽을 추천함. 로그는 지워질 수 있지만 만들어둔 계정은 지우기 아까워서 남겨두는 경우가 많음.

• 사용자·토큰 목록: 낯선 관리자 계정, 최근에 생성된 액세스 토큰, 갑자기 System Administrator 역할이 붙은 서비스 계정
• 플러그인 디렉터리: 설치 기록에 없는 플러그인 파일, 최근 변경된 타임스탬프. 플러그인 업로드는 정상 기능이라 알림이 잘 안 뜸
• 빌드 설정 변경 이력: 커밋과 무관하게 수정된 빌드 스텝, 새로 추가된 커맨드라인 스텝, 사라진 감사 항목
• 서버 로그: teamcity-server.log, teamcity-auth.log에서 인증 실패 없이 관리 API가 호출된 흔적, 비정상적으로 짧은 세션
• OS 레벨: TeamCity 실행 계정이 만든 예약 작업·서비스·크론, 외부로 향하는 상시 연결

이미 뚫렸다고 가정하고 움직일 때

빌드 서버 침해는 "서버 한 대 복구"로 끝나지 않음. 신뢰의 뿌리가 오염된 상황이라 정리 범위가 넓음.

• 서버에 저장돼 있던 모든 자격증명 회전: SSH 키, 레지스트리·아티팩트 저장소 비밀번호, 클라우드 액세스 키, VCS 토큰
• 코드 서명 키가 서버에 있었다면 키 폐기와 재발급까지 검토. 여기서 아까워하면 나중에 훨씬 크게 물림
• 의심 기간에 생성된 아티팩트는 재빌드 후 해시 비교. 소스와 산출물이 일치하는지 확인하는 게 유일하게 확실한 방법임
• 사고 이후 구조 개선: 빌드 에이전트와 서버 분리, 에이전트에 최소 권한 부여, 배포용 자격증명은 CI 안에 두지 말고 단기 토큰으로 발급

다음 번을 위한 준비

솔직히 말하면 TeamCity든 Jenkins든 GitLab Runner든, CI 계열 제품은 앞으로도 비슷한 결함이 계속 나올 것 같음. 기능 자체가 "원격에서 명령을 실행하는 것"이다 보니 인증 한 겹만 무너져도 결과가 똑같이 심각해지기 때문임. 그래서 개별 CVE를 쫓는 것보다 빌드 인프라를 '인터넷에 없는 자산'으로 만들어 두는 것이 훨씬 효율이 좋음. 노출된 관리 인터페이스 목록을 분기마다 한 번씩 스스로 점검하는 습관, 그거 하나로 이런 공지가 뜰 때마다 겪는 심장 떨림이 확 줄어듦.

오늘 퇴근 전에 딱 두 가지만 해보아요. 사내 TeamCity 버전 확인하기, 그리고 외부망에서 그 주소를 한 번 열어보기. 두 번째에서 로그인 화면이 보인다면 그게 지금 가장 급한 일이 맞습니다. 혹시 점검하다가 애매한 부분 생기면 댓글로 남겨주세요, 같이 정리해봐요.