빌드 서버가 통째로 넘어가는 경로 — TeamCity 역직렬화 결함(CVE-2026-63077) 방어 체크리스트

이미지 출처: CISA KEV

CI 서버는 조직에서 가장 권한이 센 기계 중 하나임. 소스코드 전체를 읽을 수 있고, 배포 키와 클라우드 자격증명을 들고 있으며, 빌드 결과물에 서명까지 함. 그런 서버에 신뢰할 수 없는 데이터의 역직렬화(Deserialization of Untrusted Data) 결함이 붙었다는 소식은, 단순히 "취약점 하나 더"로 넘길 만한 성질이 아님. JetBrains TeamCity에 할당된 CVE-2026-63077이 딱 그 종류임.

핵심 요약

• TeamCity에서 신뢰할 수 없는 입력이 역직렬화 경로로 흘러드는 결함(CVE-2026-63077). CI 서버 특성상 성공 시 파급이 조직 전체 공급망으로 번짐.
• 대응 1순위는 벤더가 배포한 수정 버전으로의 업그레이드. 즉시 못 하면 서버 노출면(관리 포트·인터넷 직접 공개)부터 잘라내야 함.
• 탐지는 자바 직렬화 매직바이트, 예외 스택트레이스, 빌드 에이전트의 비정상 자식 프로세스 이 세 축으로 잡는 게 현실적임.

역직렬화가 왜 그렇게 치명적인가

직렬화는 객체를 바이트 덩어리로 눌러 담는 일이고, 역직렬화는 그 덩어리를 다시 객체로 되살리는 일임. 문제는 되살리는 과정에서 객체의 생성자나 readObject 같은 훅이 자동으로 실행된다는 점임. 공격자가 그 바이트 덩어리를 마음대로 만들 수 있으면, "어떤 클래스를 어떤 순서로 되살릴지"를 공격자가 정하는 셈이 됨. 여기에 클래스패스에 이미 존재하는 라이브러리들을 사슬처럼 엮으면(이걸 가젯 체인이라 부름) 결국 임의 코드가 돌아감. 개념은 이게 전부고, 구체적인 페이로드 제작은 방어자가 알 필요가 없음.

핵심은 인증 이전이냐 이후냐임. TeamCity는 빌드 에이전트, 서비스 메시지, 플러그인, REST API 등 서버로 데이터가 들어오는 통로가 유난히 많은 제품임. 이 통로 중 하나라도 인증 없이 혹은 낮은 권한으로 역직렬화 지점에 닿을 수 있으면, 공격자는 CI 서버의 실행 권한을 그대로 가져감. 그 다음은 뻔함. 빌드 스크립트 변조, 아티팩트 서명 키 탈취, 배포 파이프라인을 통한 프로덕션 진입.

1단계 — 내 환경에 무엇이 떠 있는지 먼저 확정

• TeamCity 서버 버전과 빌드 넘버를 관리 콘솔의 서버 정보 화면에서 확인. 자체 호스팅인지 클라우드인지도 같이 기록.
• 서버가 인터넷에 직접 노출돼 있는지 확인. 사내 전용이라 믿고 있다가 리버스 프록시나 VPN 예외 규칙 때문에 열려 있는 경우가 정말 흔함.
• 빌드 에이전트가 서버에 붙는 경로(포트, 인증 방식)와, 외부 협력사·프리랜서 계정이 남아 있는지 점검.
• 설치된 서드파티 플러그인 목록 확보. 플러그인이 자체적으로 직렬화 데이터를 다루는 경우가 있어 패치 후에도 별도 확인이 필요함.

2단계 — 패치가 최우선, 그 다음이 노출면 축소

역직렬화 결함은 WAF 시그니처나 입력 필터로 완전히 막기가 어려운 부류임. 인코딩을 바꾸거나 가젯을 갈아끼우면 우회 경로가 계속 나오기 때문임. 그래서 벤더 수정본 적용이 사실상 유일한 근본 대책임. 다만 CI 서버는 "지금 당장 재시작"이 어려운 조직이 많으니, 패치 창을 잡는 동안 버틸 조치를 같이 깔아둬야 함.

• 서버 웹 인터페이스와 에이전트 통신 포트를 인터넷에서 분리. 최소한 소스 IP 화이트리스트나 VPN 뒤로 이동.
• 관리자 권한 계정 전수 점검. 쓰지 않는 계정, 퇴사자 계정, 공용 계정 정리하고 관리자에게는 2단계 인증 강제.
• 게스트 로그인, 익명 열람 설정이 켜져 있으면 끔. 프로젝트 단위로 열려 있는 경우도 확인.
• CI 서버가 들고 있는 자격증명(클라우드 키, 레지스트리 토큰, 서명 키)의 유효기간을 짧게 줄이고, 가능하면 단기 토큰으로 전환.
• 빌드 에이전트를 서버와 같은 호스트에서 돌리고 있다면 분리. 에이전트는 언제든 침해될 수 있는 실행 환경으로 취급해야 함.

3단계 — 탐지: 어디를 봐야 걸리나

역직렬화 공격은 네트워크에서든 로그에서든 나름의 흔적을 남김. 완벽하진 않지만 세 축으로 나눠 보면 실전에서 쓸 만함.

• 페이로드 형태: 자바 직렬화 스트림은 0xAC 0xED 0x00 0x05로 시작함. Base64로 감싸면 rO0AB로 시작하는 문자열이 됨. HTTP 요청 본문, 쿠키, 헤더, 파라미터에서 이 패턴이 CI 서버로 향하는지 프록시·IDS에서 룰을 걸어둘 것. 정상 트래픽에서도 나올 수 있으니 차단보다 알림 먼저.
• 예외 로그: 실패한 역직렬화 시도는 대개 ClassNotFoundException, InvalidClassException, StreamCorruptedException 같은 예외를 남김. TeamCity 로그 디렉터리의 서버 로그에서 이런 예외가 짧은 시간에 반복되면 탐색 시도로 보고 원본 요청을 추적할 것. 공격자는 보통 한 번에 성공하지 않고 여러 가젯을 시험함.
• 프로세스 계보: 가장 확실한 신호임. TeamCity 서버 JVM 프로세스가 셸이나 스크립트 해석기를 자식으로 띄우는 순간은 정상 운영 중엔 드묾. EDR에서 서버 프로세스의 자식으로 cmd.exe, powershell.exe, /bin/sh, curl, wget이 생성되는 이벤트를 우선순위 높은 탐지로 올려둘 것. 빌드 에이전트 쪽은 원래 그런 프로세스가 많으니 서버와 에이전트의 기준선을 반드시 분리해서 잡아야 함.

여기에 하나 더 붙이자면 아웃바운드임. CI 서버가 평소 통신하지 않던 외부 IP로 나가는 커넥션, 특히 정체불명의 호스트로 향하는 HTTP 요청이나 낯선 포트의 연결은 그 자체로 조사 대상임. 서버가 나가는 목적지를 허용 목록으로 관리하는 조직이라면 이 단계에서 대부분 걸림.

4단계 — 이미 당했다고 가정하고 확인할 것들

패치는 미래를 막는 조치일 뿐, 이미 들어온 흔적을 지워주진 않음. 노출 기간이 길었다면 사후 점검을 같이 돌려야 함.

• 빌드 설정과 빌드 스텝의 변경 이력 확인. TeamCity는 설정 변경을 감사 로그로 남기니, 아무도 손대지 않았어야 할 시점의 수정 기록을 찾아볼 것.
• 새로 생성된 관리자 계정, 새로 발급된 액세스 토큰, 신규 등록된 빌드 에이전트.
• 플러그인 디렉터리와 서버 데이터 디렉터리에 낯선 파일이 추가됐는지 타임스탬프 기준으로 정렬해서 확인.
• 최근 산출물의 해시가 소스 기준으로 재빌드했을 때와 일치하는지 대조. 공급망 침해는 여기서 갈림.
• CI 서버가 쥐고 있던 모든 비밀값은 침해된 것으로 간주하고 회전. 이건 확신이 없을 때 특히 필요한 조치임.

마무리하며

개인적으로는 CI 서버를 "내부 시스템"이 아니라 프로덕션 자산으로 분류하는 것부터 시작하길 추천함. 인터넷 노출 여부를 분기마다 확인하고, 패치 알림을 제품별로 구독해두고, 빌드 서버 프로세스의 자식 프로세스 탐지 룰을 미리 깔아두면 이런 CVE가 나올 때마다 허둥대지 않게 됨. 역직렬화 결함은 앞으로도 계속 나올 것이고, 매번 새로 준비하는 것보다 한 번 만들어둔 대응 틀을 재활용하는 쪽이 훨씬 덜 지치는 방법인것 같음.

혹시 TeamCity를 운영 중이라면 오늘 서버 정보 화면 한 번 열어보고, 결과가 어땠는지 댓글로 나눠주면 좋겠음. 같이 점검해보아요!