첨부파일도 링크도 아니었다 — Zimbra 웹메일에서 '열어본 메일'이 코드를 실행시키는 원리와 차단법

이미지 출처: The Hacker News

사내 메일 관리자 입장에서 가장 등골이 서늘한 문장이 하나 있음. "사용자가 아무것도 누르지 않았는데 계정이 이상하게 움직였다." 이번 Zimbra 사안이 딱 그 유형임. 악성 첨부파일을 실행한 것도, 낚시 링크를 클릭한 것도 아니고, 그냥 받은 메일 한 통을 웹메일 화면에서 열어봤을 뿐인데 공격자가 심어둔 스크립트가 피해자의 로그인 세션 안에서 그대로 실행돼버리는 구조라 그럼.

핵심 요약

• 공격자가 특수하게 조작한 메일을 보내면, 피해자가 그 메일을 웹메일에서 열람하는 순간 스크립트가 피해자 권한으로 실행되는 저장형 XSS 계열 결함임.
• 세션 쿠키·메일 내용 탈취, 자동 전달 규칙 삽입, 대신 메일 발송 같은 세션 기반 조작이 가능해 계정 하나가 조직 전체로 번질 수 있음.
• 방어의 핵심은 벤더 패치 적용 + HTML 메일 렌더링 정책·CSP 강화 + 비정상 전달규칙·로그인 이상징후 탐지 세 갈래임.

무엇이 문제인가 — '내용'이 '코드'로 둔갑하는 지점

웹메일은 결국 브라우저 안에서 도는 웹 애플리케이션임. 받은 메일의 제목·본문·발신자 이름·심지어 캘린더 초대(ICS) 같은 부가 데이터까지 전부 화면에 그려주려면, 그 값들을 HTML로 변환해 렌더링하는 과정을 거침. 이 과정에서 '사용자가 보라고 만든 텍스트'와 '브라우저가 실행하는 코드'의 경계를 제대로 지키지 못하면 문제가 터짐.

공격자는 메일의 특정 필드에 정상 문자열처럼 보이지만 실제로는 스크립트로 해석되는 조각을 끼워넣음. 서버나 클라이언트가 이 값을 화면에 출력할 때 이스케이프(무해화) 없이 그대로 HTML에 삽입하면, 브라우저는 그걸 '그냥 글자'가 아니라 '실행할 명령'으로 받아들임. 이게 저장형 XSS(Stored Cross-Site Scripting)의 전형이고, 이번 Zimbra 건도 같은 계열로 보면 됨.

왜 세션 안에서 실행되는 게 치명적인가

여기서 중요한 건 '누구의 권한으로 도는가'임. 이 스크립트는 외부 서버가 아니라 이미 로그인해 있는 피해자의 브라우저·세션 문맥 안에서 실행됨. 그래서 피해자가 가진 권한을 그대로 물려받음. 개념 수준에서 벌어질 수 있는 일을 정리하면 대략 이럼.

• 세션 쿠키·토큰을 빼내 공격자 브라우저에서 로그인 상태를 그대로 재현(세션 탈취)
• 받은편지함 내용을 조용히 긁어 외부로 전송
• 메일 자동 전달 규칙을 몰래 추가해, 앞으로 오는 메일을 지속적으로 복사
• 피해자 이름으로 조직 내부에 다시 악성 메일을 뿌려 확산(웜 형태로 번질 수 있음)

구체적인 페이로드를 여기서 재현할 생각은 없음. 방어자에게 필요한 건 '어떤 코드를 넣느냐'가 아니라 '내용이 코드로 바뀌는 통로가 어디에 열려 있고, 그걸 어디서 끊느냐'니까.

방어자가 지금 손봐야 할 것 — 탐지와 완화

개인적으로는 아래 순서대로 점검하길 추천함. 하나만으로 끝내지 말고 겹겹이 쌓는 게 포인트임.

• 벤더 패치가 최우선. 이런 렌더링 계열 결함은 근본적으로 서버·클라이언트 코드 수정으로 막힘. Zimbra가 배포한 보안 업데이트를 확인해 지연 없이 적용하고, 업데이트가 어려운 구버전이라면 노출 자체를 줄이는 조치를 병행해야 함.
• HTML 렌더링·CSP 정책 강화. 웹메일 서버 앞단이나 애플리케이션 설정에서 콘텐츠 보안 정책(Content-Security-Policy)을 걸어 인라인 스크립트 실행을 막으면, 설령 무해화가 뚫려도 실제 실행 단계에서 한 번 더 걸러짐. 인라인 이미지·외부 리소스 로드 정책도 함께 조여두면 좋음.
• 이상 전달규칙 탐지. 계정별 자동전달·필터 규칙을 주기적으로 감사해서, 사용자가 만든 적 없는 외부 전달 규칙이 생겼는지 확인함. 공격 성공 후 지속성 확보의 단골 수법이라 여기가 조기 탐지의 금맥임.
• 세션·로그인 이상징후 모니터링. 동일 계정이 짧은 시간에 낯선 IP·지역에서 붙거나, 대량 열람·대량 발송이 튀는지 로그로 잡음. 세션 탈취가 성공하면 흔적이 여기 남음.
• 사용자 측 표면 축소. 조직 특성상 가능하다면 신뢰되지 않은 외부 메일의 HTML을 기본적으로 평문으로 보게 하거나 원격 콘텐츠 로드를 막는 정책도 공격 표면을 눈에 띄게 줄여줌.

정리하며

이번 사안이 주는 교훈은 결국 오래된 웹보안 원칙 하나로 수렴함. 어떤 값이든 화면에 그리기 전에 그것을 '데이터'로 다룰지 '코드'로 다룰지는 개발자·운영자가 명시적으로 정해야 한다는 것. 웹메일은 매일 수많은 낯선 입력이 밀려드는 창구라 이 경계가 특히 얇음. 자기 조직이 Zimbra를 쓰고 있다면 오늘 안에 패치 상태부터 확인하고, 전달규칙 감사와 CSP 점검을 하나씩 붙여보길 권함. 혹시 이미 이상 전달규칙이나 낯선 세션을 발견한 경험이 있다면 어떻게 잡았는지 댓글로 나눠주면 서로 배울 게 많을 것 같음. 같이 촘촘하게 막아보아요.