스팸을 걸러내던 관문이 디렉터리 바깥까지 보여줄 때: Cisco Secure Email Gateway CVE-2026-76519, 로그에서 찾을 것과 먼저 막을 것

이미지 출처: CISA KEV

회사 메일함에 스팸이 생각보다 적게 들어오는 건 대개 메일 서버 앞에 이메일 게이트웨이가 하나 서 있기 때문임. 들어오는 메일을 전부 열어 보고, 첨부파일을 검사하고, 수상한 링크는 바꿔 쓰고, 격리함에 가둬 두기도 함. 그러다 보니 이 장비는 조직 안에서 가장 많은 외부 데이터를 가장 먼저 만지는 시스템이 되는 셈인데, 이번에 Cisco Secure Email Gateway에서 상대 경로 탐색(Relative Path Traversal) 취약점 CVE-2026-76519가 공개됐음. 지켜야 할 장비가 오히려 자기 안의 파일을 밖으로 내줄 수 있는 문제라 그냥 넘기기는 좀 찝찝했고, 그래서 방어하는 쪽에서 무엇을 먼저 보면 좋을지 정리해 봤음.

핵심 요약

• CVE-2026-76519는 Cisco Secure Email Gateway에서 경로 입력값을 제대로 정규화하지 않아 의도한 디렉터리 바깥의 파일에 접근될 수 있는 상대 경로 탐색 취약점임.
• 메일 게이트웨이는 설정 파일, 인증 정보, 격리 메일까지 쥐고 있어서 파일 하나만 새어 나가도 다음 공격의 발판이 되기 쉬움.
• Cisco 권고문 기준으로 패치 적용, 관리 인터페이스 노출 축소, 웹 로그의 경로 조작 흔적 점검을 같이 진행하는 게 현실적인 순서임.

상대 경로 탐색이 뭐길래

개념 자체는 단순함. 애플리케이션은 보통 "이 폴더 안에 있는 파일만 보여준다"는 전제로 동작하는데, 사용자가 넘긴 파일 이름이나 경로 값을 그대로 이어 붙이면 문제가 생김. 상위 디렉터리를 가리키는 표현이 섞여 들어오면 기준 폴더를 벗어나 시스템의 다른 위치를 읽거나, 경우에 따라 쓸 수도 있음.

• 원인: 입력값을 실제 경로로 바꾼 뒤(canonicalize) 허용된 기준 디렉터리 안에 있는지 확인하는 과정이 빠져 있거나 불완전함
• 변형: URL 인코딩, 이중 인코딩, 운영체제별 구분자 차이처럼 필터를 우회하려는 표현이 자주 섞여 들어옴
• 결과: 읽기만 가능해도 설정·키·로그가 새어 나가고, 쓰기까지 가능하면 설정 변조나 추가 코드 실행으로 이어질 여지가 생김

NVD 설명에 따르면 이번 건도 이런 계열에 속하는 것으로 보임. 정확히 어떤 기능과 어떤 버전대가 영향을 받는지, 인증이 필요한지는 Cisco 보안 권고문에 정리된 내용을 기준으로 보는 게 맞고, 장비마다 쓰는 기능이 달라서 자기 환경에 맞는지부터 대조해 보는 게 먼저인 것 같음.

왜 하필 메일 게이트웨이라서 더 신경 쓰이는가

일반 웹 서버였다면 "파일 몇 개 새는 것"으로 끝날 수도 있는데, 메일 게이트웨이는 사정이 좀 다름. 개인적으로 이 장비를 점검할 때 늘 긴장되는 부분이 바로 여기임.

• 설정 파일: LDAP 연동 정보, 스마트 호스트, 릴레이 정책 등 내부 메일 구조가 거의 그대로 담겨 있음
• 자격 증명: 디렉터리 서버나 외부 연동용 계정 정보가 장비 안에 저장되는 경우가 많음
• 격리 메일·로그: 차단된 피싱 메일, 첨부파일, 송수신 기록 자체가 민감 정보임
• 위치: 외부와 내부 사이 경계에 놓여 있어서 한 번 발판이 되면 내부로 들어가는 길이 짧아짐

그러니까 "경로 하나 잘못 열린 것"이 실제로는 조직 메일 인프라의 지도를 넘겨주는 일이 될 수도 있다는 거임.

먼저 할 일: 패치와 노출 범위 줄이기

1. 권고문 대조: Cisco 보안 권고문에서 영향 받는 AsyncOS 릴리스와 수정 릴리스를 확인하고, 운영 중인 장비 버전과 맞춰 봄. 클러스터 구성이면 모든 노드를 같이 봐야 함
2. 업그레이드 일정 확보: 메일 흐름이 끊기면 안 되니 이중화 장비가 있다면 한 대씩 순차 적용하는 방식이 무난했음
3. 관리 인터페이스 격리: 웹 관리 화면(HTTP/HTTPS)이 인터넷 쪽 인터페이스에 열려 있다면 바로 닫는 게 좋음. 관리망 전용 인터페이스나 허용 IP 목록으로만 접근되게 묶어 두면, 패치 전이라도 공격 표면이 크게 줄어듦
4. 불필요한 서비스 정리: 스팸 격리함 최종 사용자 접근 등 외부에 열어 둔 기능이 꼭 필요한지 다시 따져 봄

탐지: 로그에서 어떤 모양을 찾을까

공격 문자열을 그대로 외우기보다는 패턴의 특징을 잡아 두는 편이 오래 써먹기 좋았음.

• 요청 경로나 파라미터에 상위 디렉터리 이동 표현이 들어간 기록, 특히 인코딩된 형태로 반복되는 경우
• 평소에는 요청되지 않는 시스템 파일 이름, 설정 파일 확장자가 파라미터 값으로 등장하는 경우
• 짧은 시간에 같은 출발지에서 경로만 조금씩 바꿔 가며 들어오는 요청 묶음(자동화 스캐너 흔적)
• 관리 화면 접근 로그에서 처음 보는 국가·IP 대역, 업무 시간 밖의 접근
• 설정 변경 이력, 계정 추가, 새 API 키 생성처럼 사후 행위로 이어진 흔적

장비 앞단에 WAF나 리버스 프록시가 있다면 경로 정규화 후 상위 디렉터리 탐색 시도를 차단하는 룰을 걸어 두는 것도 임시 완화책으로 괜찮음. 다만 이건 어디까지나 시간 벌기용이고, 근본 해결은 결국 벤더 패치임.

이미 노출됐을지 모른다면

관리 인터페이스가 외부에 열려 있었고 위 패턴이 로그에서 보인다면, 패치만 하고 끝내기보다 한 발 더 나가는 게 맞다고 생각함.

• 장비에 저장된 LDAP·SMTP 인증 등 연동 계정 비밀번호 교체
• 관리자 계정 전체 비밀번호 재설정과 불필요 계정 삭제
• 설정 백업을 알려진 정상 시점과 비교해 변경된 정책이 있는지 확인
• 장비 로그를 SIEM으로 보내고 있었다면 과거 기간까지 거슬러 올라가 같은 패턴을 다시 검색

정리하며

보안 장비라서 안전할 거라는 생각이 사실 제일 위험한 것 같음. 메일 게이트웨이는 한 번 세팅해 두면 몇 년씩 손을 안 대는 경우가 많은데, 이번 CVE-2026-76519를 계기로 버전 확인, 관리 화면 노출 여부, 로그 수집 상태 세 가지만이라도 같이 한 번씩 훑어보아요. 각자 환경에서 패치하면서 겪은 이슈나 탐지 룰 팁이 있다면 댓글로 공유해 주세요, 같이 보면서 다듬어 보면 좋겠음.