톰캣이 디스크에 남기는 흔적 — 암호화 없이 저장되는 데이터를 점검하는 방법

이미지 출처: CISA KEV

서버 이관 작업을 하다 보면 work 디렉터리나 세션 저장 파일을 무심코 통째로 복사하게 되는 순간이 있음. 백업 tar를 풀어놓고 grep 한 번 돌렸을 때 익숙한 사용자명이나 토큰 문자열이 눈에 들어오면 그때부터 등이 서늘해짐. Apache Tomcat에 배정된 CVE-2026-34486은 바로 그 지점, 민감한 데이터가 암호화되지 않은 채 저장·전달되는 문제(Missing Encryption of Sensitive Data)를 다루는 결함임.

핵심 요약

• Tomcat에서 민감 데이터가 암호화 없이 저장·전달될 수 있는 결함으로, 원격 익스플로잇보다 디스크·백업·로그에 남는 평문이 실질적 위험임
• 공격자 관점의 진입점은 파일 접근 권한, 백업 아카이브, 컨테이너 이미지 레이어처럼 서버 밖으로 나간 사본임
• 대응은 패치 적용과 함께 세션 지속화(PersistentManager) 설정 점검, 디렉터리 권한 재정비, 백업 암호화까지 묶어서 봐야 함

1. "암호화 누락"이 왜 조용한 취약점인가

RCE나 인증우회처럼 화려한 결함은 PoC가 돌아다니고 트위터가 시끄러워지니 대응 우선순위가 자동으로 올라감. 반면 암호화 누락은 공격 로그가 남지 않는다는 게 특징임. 누군가 평문 데이터를 읽어갔다고 해도 그건 정상적인 파일 읽기 요청이고, 웹 방화벽에도 IDS에도 걸릴 게 없음.

서블릿 컨테이너가 평문으로 남길 수 있는 것들을 떠올려 보면 목록이 생각보다 김.

• 세션 지속화(session persistence) 시 디스크에 직렬화되는 SESSIONS.ser 계열 파일 — 로그인 상태, 권한 정보, 장바구니, 때로는 토큰까지
• 클러스터 구성에서 노드 간 오가는 세션 복제 트래픽
• JSP 컴파일 결과와 임시 업로드 파일이 쌓이는 work/temp 디렉터리
• 디버그 레벨로 켜둔 로그에 흘러드는 파라미터 값

이 중 어느 하나라도 백업 대상에 포함돼 있고 그 백업이 암호화되지 않았다면, 취약점의 영향 범위는 서버 한 대가 아니라 백업이 존재하는 모든 곳으로 늘어남.

2. 개념 수준의 공격 시나리오

실행 가능한 코드는 다룰 필요가 없고, 흐름만 이해하면 충분함. 공격자는 세 갈래 중 하나를 노림.

• 로컬 계정 확보 후 파일 읽기: 별개의 결함이나 탈취된 SSH 키로 서버에 발을 들인 뒤, tomcat 프로세스가 남긴 저장 파일을 그대로 읽음. 권한 상승 없이도 세션 데이터를 가져갈 수 있으면 그것만으로 계정 탈취 재료가 됨
• 사본 경유: 운영 서버는 잘 지켜지지만 백업 스토리지, 스테이징 서버, 컨테이너 이미지 레지스트리는 통제가 느슨한 경우가 많음. 평문 데이터가 담긴 레이어 하나가 사내 레지스트리에 올라가 있으면 읽기 권한을 가진 모두가 열람자임
• 내부망 스니핑: 세션 복제나 관리 채널이 평문으로 오가면 같은 세그먼트에 붙은 장비가 조용히 수집함

공통점은 "원격에서 취약점을 때리는" 그림이 아니라는 것임. 그래서 외부 스캐너 결과만 보고 있으면 이 결함은 영원히 안 보임.

3. 지금 당장 확인할 것들

패치 적용은 당연히 첫 번째지만, 그 전후로 같이 봐야 할 항목을 순서대로 정리함.

• 세션 지속화 설정 확인 — context.xml에서 PersistentManager와 FileStore/JDBCStore가 켜져 있는지 봄. 재시작 시 세션 유지가 꼭 필요한 서비스가 아니라면 끄는 것만으로 노출면이 사라짐
• 저장 경로 실물 점검 — CATALINA_BASE 하위 work, temp, 그리고 FileStore의 directory 속성이 가리키는 경로를 직접 열어 봄. .ser 파일이 있다면 소유자와 퍼미션이 tomcat 계정 전용인지 확인
• 백업 정책 — 위 경로가 백업 대상에 들어가 있는지, 백업 자체가 암호화되는지. 들어가 있는데 암호화가 없다면 제외 대상으로 빼거나 백업 암호화를 켜는 쪽이 빠름
• 클러스터 통신 — 세션 복제를 쓴다면 채널에 암호화 인터셉터가 걸려 있는지, 아니면 최소한 별도 관리망으로 분리돼 있는지 확인
• 로그 레벨 — 운영 환경에 DEBUG가 남아 있는 경우가 의외로 많음. 로그에 세션 속성이나 파라미터가 통째로 찍히고 있지 않은지 샘플링해서 봄

4. 탐지 관점: 무엇을 알림으로 만들 것인가

이런 유형은 "공격 시그니처"가 없으므로 접근 자체를 이벤트로 만드는 방향으로 접근해야 함.

• 리눅스라면 auditd로 세션 저장 디렉터리에 대한 읽기(open/openat) 감사 규칙을 걸어두고, tomcat 프로세스 외의 UID가 접근하면 알림. 정상 상황에서는 거의 울리지 않으므로 오탐 부담이 적음
• EDR이 있다면 해당 경로를 중요 파일 경로로 등록하고, 압축·복사·외부 전송 행위와 연계된 룰을 만듦
• 백업 서버에서 아카이브를 뜬 뒤 무작위로 하나 골라 문자열 검사를 돌려보는 정기 점검도 효과가 좋음. 세션 ID 형식이나 사내 계정 접두어를 패턴으로 잡아 두면 됨
• 애플리케이션 단에서는 세션에 무엇을 담고 있는지 자체를 감사 대상으로 삼아야 함. 세션 속성에 비밀번호·API 키·주민번호류가 들어가 있으면 컨테이너를 아무리 고쳐도 근본 해결이 안 됨

5. 근본 대책은 결국 "담지 않기"

개인적으로는 이런 취약점을 만날 때마다 설정보다 설계를 먼저 보는 것을 추천함. 컨테이너가 데이터를 어떻게 저장하느냐는 우리가 통제하기 어렵지만, 세션에 무엇을 담느냐는 전적으로 개발팀의 선택임.

• 세션에는 식별자만 두고 실제 민감 정보는 서버 측 저장소에서 매번 조회하는 구조로 바꾸기
• 토큰은 세션 객체가 아니라 짧은 만료 시간을 가진 별도 저장소에 두기
• 불가피하게 담아야 한다면 애플리케이션 레벨에서 암호화한 뒤 담기 — 컨테이너가 직렬화하는 시점에는 이미 암호문이 되도록

이렇게 해두면 다음에 비슷한 CVE가 또 나와도 "우리는 세션에 담은 게 없어서 영향 없음"이라고 30분 안에 답할 수 있음. 그게 진짜 대응 역량인 것 같음.

마무리

암호화 누락 계열 결함은 티가 안 나서 밀리기 쉽지만, 사고가 터졌을 때 피해 산정이 가장 어려운 유형이기도 함. 언제부터 노출됐는지, 누가 읽어갔는지 증명할 방법이 마땅치 않기 때문임. 오늘 저녁에 서버 하나만 잡고 work 디렉터리를 열어보는 것부터 시작해 보아요. 생각보다 많은 게 남아 있어서 놀랄지도 모릅니다.

여러분 환경에서는 세션 지속화를 켜두고 계신가요? 어떤 이유로 켜두셨는지, 대신 어떤 보완책을 쓰고 계신지 댓글로 공유해 주시면 저도 배우겠습니다. 같이 안전하게 굴려보아요!