메일 서버가 셸을 불러올 때 — Zimbra ZCS 명령 주입을 방어자 눈으로 뜯어봄

이미지 출처: CISA KEV

메일 서버는 조직에서 가장 늦게 꺼지는 장비 중 하나임. 웹서버는 점검 창을 잡아 내려도, 메일은 하루만 멈춰도 전 부서가 난리가 나니 패치 순위가 계속 밀림. Zimbra Collaboration Suite가 공격자들에게 오랫동안 사랑받아 온 이유가 바로 여기 있음. CVE-2026-73570으로 등록된 이번 OS 명령 주입 결함도 같은 맥락에서 봐야 함.

핵심 요약

• Zimbra ZCS에서 사용자 입력이 운영체제 명령으로 흘러 들어가는 명령 주입 취약점이 보고됨
• 메일 서버 특성상 외부 노출이 기본값이라 인터넷에서 바로 닿는 경우가 많고, 성공 시 zimbra 계정 권한의 임의 명령 실행으로 이어짐
• 방어는 패치 적용이 1순위, 그다음이 웹 디렉터리 무결성 감시와 zimbra 계정의 비정상 자식 프로세스 탐지임

1. 왜 하필 Zimbra인가

Zimbra는 오픈소스 협업 스위트로, 메일·캘린더·주소록·문서를 한 덩어리로 제공함. 구조를 보면 앞단에 Jetty 기반 웹 계층이 있고, 뒷단에는 Postfix, OpenLDAP, MariaDB, 그리고 각종 관리 스크립트가 붙어 있음. 이 여러 컴포넌트를 이어 붙이는 접착제 역할을 셸 스크립트와 외부 바이너리 호출이 담당한다는 점이 핵심임.

웹 요청이 들어와서 첨부파일을 변환하거나, 인증서를 다루거나, 메일을 재전송하거나, 백업을 조회할 때 자바 코드가 직접 처리하지 않고 시스템 명령을 부르는 경로가 여기저기 있음. 그 경로에 사용자가 제어할 수 있는 문자열이 필터 없이 실려 들어가면 명령 주입이 됨. 이게 Zimbra에서 유사한 유형의 취약점이 주기적으로 반복되는 구조적 이유인것 같음.

2. 명령 주입이란 게 실제로 무슨 일인가

개념만 짚고 넘어감. 애플리케이션이 이런 형태의 코드를 갖고 있다고 해보면 됨.

• 프로그램이 convert [사용자가_준_파일이름] output.png 같은 문자열을 만든다
• 그 문자열을 셸에 통째로 넘겨서 실행한다
• 그런데 셸은 세미콜론, 파이프, 백틱, $( ) 같은 문자를 "여기서 명령이 끝나고 새 명령이 시작된다"는 신호로 해석한다
• 결국 파일 이름 자리에 그런 문자가 섞여 들어오면, 원래 의도한 변환 명령 뒤에 공격자의 명령이 하나 더 붙는다

딱 이게 전부임. 어렵고 화려한 기법이 아니라 "데이터로 쓸 값을 코드가 실행되는 자리에 그대로 붙였다"는 아주 오래된 실수임. 그래서 방어 원칙도 단순함. 셸을 거치지 않고 인자 배열로 프로세스를 직접 실행하거나, 값을 허용 목록으로 검증하거나, 애초에 외부 명령을 쓰지 않고 라이브러리로 처리하는 것.

공격자 입장에서 이 취약점이 매력적인 이유는 결과물이 곧바로 셸이라는 점임. SQL 인젝션은 데이터를 빼내는 데서 출발해 권한 상승 경로를 따로 찾아야 하지만, 명령 주입은 성공하는 순간 서버에서 프로세스를 돌릴 수 있음. Zimbra의 경우 웹 계층이 zimbra 서비스 계정으로 돌기 때문에, 그 계정이 접근 가능한 메일 저장소·설정 파일·LDAP 자격증명까지 사정권에 들어옴.

3. 침해가 일어나면 어떤 흔적이 남는가

이 부분이 실무에서 제일 중요함. 과거 Zimbra를 노린 캠페인들을 보면 침해 후 행동 패턴이 꽤 일관됨.

• 웹셸 투입: /opt/zimbra/jetty/webapps/zimbra/ 하위나 공개 리소스 경로에 JSP 파일이 새로 생김. 정상 배포 시점과 파일 생성 시각이 어긋나는 게 첫 단서임
• 비정상 자식 프로세스: 자바 프로세스가 갑자기 sh, curl, wget, python을 자식으로 띄움. 평상시 프로세스 트리를 알고 있으면 즉시 눈에 띔
• 지속성 확보: zimbra 계정의 crontab 추가, SSH authorized_keys에 공개키 삽입, 시작 스크립트 수정
• 메일함 대량 접근: 특정 계정이 짧은 시간에 다수 메일박스를 조회하거나, 관리자 API로 위임 로그인을 반복하는 흔적
• 외부로 나가는 연결: 메일 서버가 25/465/587이 아닌 엉뚱한 포트로 아웃바운드를 시도하는 것 자체가 이상 신호임

4. 지금 당장 할 수 있는 점검

패치가 최우선이라는 말은 굳이 반복할 필요가 없을 텐데, 문제는 패치 창이 잡히기까지의 공백임. 그 사이에 해볼 수 있는 것들을 정리해 봄.

• 웹 디렉터리 무결성 스냅샷: 지금 시점의 웹 배포 경로 파일 목록과 해시를 떠 두고, 하루 단위로 비교함. 새로 생긴 .jsp는 무조건 확인 대상
• 프로세스 계보 로깅: auditd나 EDR로 zimbra 계정에서 발생하는 execve를 수집함. 자바에서 셸이 파생되는 패턴을 알림으로 걸어 두면 탐지 지점이 하나 생김
• 노출면 축소: 관리 콘솔(7071 등 관리용 포트)을 인터넷에 열어 둘 이유는 거의 없음. VPN이나 사내망 뒤로 넣고, 앞단 프록시에서 관리 경로 자체를 차단
• 웹 로그 역추적: 침해가 의심되면 접근 로그에서 비정상적으로 긴 파라미터, 인코딩이 중첩된 요청, 평소 쓰지 않는 엔드포인트 호출을 시간순으로 훑음. 공격 성공 요청 직후에 새 파일 접근 로그가 따라붙는 패턴이 자주 보임
• 자격증명 초기화 계획: 침해가 확인되면 패치만으로 끝나지 않음. LDAP 관리자 비밀번호, 서비스 계정 키, 발급된 인증 토큰을 갈아엎어야 함. 공격자가 이미 들고 나간 자격증명은 패치와 무관하게 계속 유효하기 때문

5. 개발자 관점에서 남는 교훈

제품을 만드는 쪽이라면 체크 포인트는 세 가지로 압축됨.

• 외부 명령을 부를 때 셸 해석을 거치는 API를 쓰지 않기. 문자열 한 덩어리가 아니라 실행 파일과 인자를 분리한 배열로 넘기면 셸 메타문자가 그냥 평범한 글자가 됨
• 파일명·경로·식별자처럼 시스템 명령에 실릴 값은 차단 목록이 아니라 허용 목록으로 검증하기. 위험 문자를 하나씩 막는 방식은 인코딩 우회에 계속 뚫림
• 서비스 계정 권한을 최소화하기. 명령이 실행되더라도 그 계정이 할 수 있는 게 적으면 피해 범위가 확 줄어듦

마무리

Zimbra 취약점이 나올 때마다 느끼는 건, 기술적 난이도보다 운영의 공백이 더 큰 문제라는 점임. 취약점 공개부터 실제 스캐닝 시작까지 걸리는 시간은 요즘 며칠이 아니라 몇 시간 단위로 줄었는데, 조직의 패치 결재 라인은 여전히 주 단위로 돌아감. 그 간극을 메우는 게 결국 탐지 체계인것 같다는 생각을 하다 보니, 요즘은 패치 속도를 올리는 것보다 "뚫렸을 때 몇 시간 안에 알아채는가"를 더 자주 들여다보게 됨.

혹시 Zimbra를 운영 중이시라면, 오늘 웹 디렉터리 파일 목록 스냅샷 한 번 떠 두시길 개인적으로 추천함. 나중에 비교할 기준선이 있는 것과 없는 것은 대응 속도에서 하늘과 땅 차이임. 다들 무사히 넘어가시길 바라고, 각자 환경에서 유용했던 탐지 룰이 있으면 댓글로 공유해 주시면 같이 배워 보아요!