코볼드 편지: HTML 이메일의 위험성

• Kobold letters는 HTML 이메일이 처음에는 무해해 보이다가 전달 후 다른 수신자에게 피싱 내용으로 바뀌게 만드는 공격 기법임
• 핵심은 이메일 클라이언트가 허용하는 CSS와, 전달 과정에서 바뀌는 DOM 위치를 이용해 특정 문구를 숨기거나 다시 표시하는 데 있음
• Thunderbird와 Outlook on the web은 DOM 구조와 CSS 재작성 방식 때문에 전달 후 숨겨진 문구가 나타날 수 있고, Gmail은 전달 시 스타일 제거로 더 단순한 형태의 노출이 가능함
• Mozilla, Microsoft, Google에는 2024년 3월 5일 문제가 보고됐으며, Microsoft는 3월 26일 즉각 조치 없이 종료했고 Google은 4월 9일 수정 작업 중임을 확인함
• 사용자는 HTML 이메일을 끄거나 제한 모드로 볼 수 있지만, <style> 차단은 기존 이메일 생태계의 많은 사용 사례를 깨뜨릴 수 있어 클라이언트 차원의 완화가 쉽지 않음

---

공격 시나리오와 핵심 아이디어

• 관리자가 전달한 이메일이 처음에는 무해한 문의 메일처럼 보이다가, 전달된 뒤 새 수신자에게는 피싱 요청으로 바뀔 수 있음
• 수신자는 발신자가 아는 사람이고, 경우에 따라 암호학적 서명까지 붙어 있으며, 전화로 전달 사실을 확인해도 속을 수 있음
• 원래 수신자인 관리자는 자신이 전달한 이메일에서 피싱 문구를 보지 못했기 때문에, 전달 사실을 확인해도 공격 여부를 알아차리기 어려움

Kobold letters의 동작 방식

• 대부분의 이메일 클라이언트는 HTML 이메일에서 CSS 스타일링을 허용함
• 이메일이 전달되면 원본 이메일의 DOM 위치가 보통 바뀌고, 공격자는 이 변화를 기준으로 CSS 선택자를 적용함
• 공격자는 문맥에 따라 나타나거나 사라지는 요소를 이메일에 넣을 수 있음
  • 평소에는 display: none;으로 숨김
  • 전달 후 DOM 구조가 바뀌면 display: block !important; 같은 규칙으로 표시함
• 이런 요소는 보통 보이지 않다가 특정 상황에서만 나타나며, 피싱 등에 악용될 수 있어 kobold letters라고 부름
• HTML 이메일을 지원하는 이메일 클라이언트와 웹메일 전반이 영향을 받을 수 있음

Thunderbird에서의 동작

• Thunderbird 관련 문제는 Mozilla에 2024년 3월 5일 보고됐고, 2024년 3월 20일 공개 예정일과 초안이 전달됨
• 가능한 완화책은 논의됐지만, 구현은 나중으로 미뤄질 예정임
• Thunderbird는 이메일을 <div class="moz-text-html" lang="x-unicode"></div>로 감싸고, 그 외에는 거의 변경하지 않음
• 이메일을 전달하면 인용된 원본 이메일이 다시 <div></div> 안에 들어가 DOM에서 한 단계 아래로 이동함
• 예시 CSS는 .kobold-letter를 기본적으로 숨기고, .moz-text-html>div>.kobold-letter 조건에서만 표시함
• 원본 이메일을 보는 사람에게는 항상 보이는 문단만 표시되지만, 전달된 이메일을 받은 사람에게는 숨겨졌던 문단이 갑자기 나타남
• 공격자는 DOM 내 상대 위치를 알고 CSS를 제어할 수 있어 이메일 일부를 숨기거나 보여 내용 전체를 바꿀 수 있음
• kobold letter를 오버레이처럼 스타일링하면 전달자가 원본 메일에 추가한 코멘트까지 대체할 수 있어 피싱 기회가 더 늘어남

Outlook on the web에서의 동작

• Outlook on the web 문제는 Microsoft에 2024년 3월 5일 보고됐고, 2024년 3월 20일 공개 예정일과 초안이 전달됨
• Microsoft는 2024년 3월 26일 즉각적인 조치를 하지 않기로 하고 보고를 종료 처리함
• OWA는 웹메일이라 상황이 더 복잡하며, 이메일은 <div class="rps_78fa"></div> 같은 컨테이너에 들어가지만 정확한 클래스 이름은 바뀜
• Outlook은 이메일 CSS가 웹메일 UI 스타일에 영향을 주지 않도록 id와 class 앞에 x_를 붙이고 CSS도 함께 조정함
• 예시에서 원본 이메일의 CSS는 OWA 표시 시 다음처럼 변환됨
  • .rps_78fa .x_kobold-letter {display:none}
  • .rps_78fa > div > div > .x_kobold-letter {display:block!important}
• 전달 후에는 클래스가 다시 x_x_kobold-letter처럼 바뀌고 CSS도 다시 업데이트됨
• 두 번째 규칙에서 .rps_78fa와 div 사이의 >가 사라지므로, 복잡한 선택자를 만들 때 이를 고려해야 함
• OWA의 조정은 공격 자체를 막지는 않지만, 여러 클라이언트에서 동시에 동작하는 kobold letter를 만들 때는 번거로운 제약이 됨

Gmail에서의 동작

• Gmail 문제는 Google에 2024년 3월 5일 보고됐고, 2024년 3월 20일 공개 예정일과 초안이 전달됨
• Google은 2024년 4월 9일 수정 작업 중이라고 확인함
• Gmail은 이메일을 전달할 때 모든 스타일을 제거하므로, CSS 선택자로 표시 여부를 문맥에 따라 바꾸는 좁은 정의의 kobold letters에는 기술적으로 취약하지 않음
• 하지만 더 단순한 공격은 가능함
  • 원본 이메일에서 CSS로 kobold letter를 숨김
  • 전달 시 스타일이 제거되면서 숨겨진 요소가 자동으로 표시됨
• 이 방식은 제한적이며, 원본에서는 보이고 전달 후에는 사라지는 반대 동작은 할 수 없음
• Gmail은 이메일을 보내기 전 편집기에서는 CSS를 아직 제거하지 않기 때문에, 전달자가 코멘트를 작성하는 동안에도 숨겨진 문단이 보이지 않음
• 결과 이메일에서는 스타일이 제거되어 두 번째 문단이 나타남
• Gmail이 편집기 단계에서 CSS를 제거하면 전달자가 보내기 전에 공격을 발견할 수 있어 문제가 완화될 수 있음

기존 유사 사례와 차이

• HTML 이메일에서 CSS로 회신·전달 콘텐츠가 바뀔 수 있다는 점은 새롭지 않음
• 과거에도 유사한 문제가 보고됨
  • Thunderbird - Modification of replied mail content without knowledge of replier of the mail using CSS
  • Treat OpenPGP/SMIME email messages with certain CSS elements as unsigned
  • Composition should use inline styling so that styles from quotes don’t leak into the message
• Kobold letters의 차이는 특정 공격 시나리오에 초점을 맞추고, 여러 이메일 클라이언트를 함께 살펴본다는 점임
• HTML 이메일의 위험성과 이를 완화하기 위한 트레이드오프 논의가 필요함

완화책과 한계

• 사용자는 HTML 이메일을 완전히 비활성화하거나 Thunderbird의 “plain HTML” 같은 제한 모드로 볼 수 있음
• 이메일 클라이언트가 <style> 사용을 막으면 문제를 해결할 수 있지만, 이메일 생태계의 기존 많은 사용 사례가 깨질 수 있음
• Gmail처럼 전달 시 스타일을 제거하는 구현은 스타일 있는 기업 뉴스레터를 허용하면서 HTML 이메일 위험을 제한하는 절충안이 될 수 있음
• 가까운 미래에 이메일 클라이언트가 강력한 완화책을 구현하리라고 기대하기는 현실적이지 않음
• 사용자는 HTML 이메일의 위험을 인지하고 필요한 예방 조치를 직접 취해야 함

[GN⁺]

Hacker News 의견들

• “그래도 확신이 안 서서 관리자에게 전화해 이메일이 진짜인지 확인한다. 관리자가 맞다고 하자 돈을 송금한다”는 부분은 너무 큰 가정처럼 느껴짐
  보통 “이 이메일 보냈나요?”처럼 두루뭉술하게 묻기보다 “정말 이런 식으로 돈을 송금하라는 건가요?”라고 더 구체적으로 물을 텐데, 그러면 관리자가 당연히 당황하고 그 대화에서 공격이 막힐 가능성이 큼
  흥미로운 공격 경로이긴 하지만 실제 성공 가능성은 의문임. 글은 이 공격이 성립하려면 꽤 구체적이고 좁은 사건 흐름이 필요하다고 그리는데, 개인적으로는 납득이 잘 안 됨
  피싱이 실제로 통한다는 건 알고 있음. 다만 피싱에 걸릴 사람들은 이 정도로 정교한 공격까지 필요하지 않고, 오히려 공격자가 이렇게 구체적인 노력을 많이 들이면 성공 확률을 좁힐 수도 있음. 보통의 피싱 이메일만으로도 성공할 가능성이 큼

  • 직원 1만 명, 절반이 엔지니어인 회사에서 일했는데, 매년 몇 건씩 누군가가 “CEO”나 다른 고위 임원을 위해 회사 카드로 기프트 카드를 사는 일이 있었음
    그 임원들의 정보는 LinkedIn이나 회사 사이트에서 쉽게 찾을 수 있었고, 심지어 그 사례가 피싱 방지 교육의 정확한 예시였는데도 그랬으니 놀랄 수 있음
  • 오히려 반대에 가까움. 가장 뻔하고 우스꽝스러운 사기가 제일 잘 먹힌다는 건 잘 문서화된 사실이고, 그렇게 해야 가장 잘 속는 잠재 피해자를 걸러낼 수 있음
    https://www.microsoft.com/en-us/research/publication/why-do-...
  • 사람에 따라 다를 듯함. 어떤 관리자는 하루에도 여러 번 이런 결제를 승인해야 해서 그런 대화를 귀찮아할 수 있고, 직원들도 그런 대화를 피하고 싶어할 수 있음
    공격자는 “지금 출장 중입니다. 확실하지 않으면 제 개인 휴대전화로 전화하세요...” 같은 문구를 넣고, 그다음 가짜 음성으로 응답할 수도 있음
    표적에게 도달하는 좋은 방법은 “이중 전달”일 수 있음. 발신자가 관리자의 이메일을 행정 업무 담당자 근처의 직원에게 전달하는 직원 역할을 하고, 그 직원이 생일 축하나 병가 알림 같은 이유로 겉보기에는 무해한 메일을 다시 전달하면, 실제 표적은 이메일의 원 출처를 파악하기 어려워짐
    그 밖에도 이 “기능”을 더 창의적으로 악용할 방법은 쉽게 떠올릴 수 있음. 예를 들어 아무것도 모르는 사람이 문제 있는 내용을 전달하게 만든 뒤 협박하는 식도 가능함
  • 대기업의 매입채무 부서로 이런 메일이 보내지는 상황이라면 그리 비현실적이지 않을 수 있음
    결제 요청이 이메일로 올 때마다 담당자들이 매번 라인 매니저에게 전화하지는 않을 것이고, 특히 금액이 작고 사전 승인이 필요 없는 경우라면 더 그럼
    Google도 실제 작업이 없었는데 누군가에게 돈을 지급하는 사기에 당한 적이 있었던 것으로 기억함. 그 사례는 허위 청구서가 포함됐지만, 원리는 같음
  • 이론적으로는 송금의 수취인 변경처럼 더 정교하고 표적화된 공격을 가능하게 할 수 있음. 그런 공격은 훨씬 탐지하기 어려움

• 며칠 전 디자이너가 만든 “업데이트” 이메일 디자인을 보는데, 맨 위에 넣은 말도 안 되게 큰 그래픽 헤더 때문에 스크롤하지 않으면 이메일 제목 텍스트조차 보이지 않았음
  그러다 다른 버전을 전달해 피드백을 요청했는데, 갑자기 폰트가 좀 작아진 것처럼 보인다며 당황하더니 “아, 전달하면 모바일 버전이 아니라 데스크톱 버전으로 변환되네요!”라고 말함
  그걸 보며 믿을 수 없어서 멍하니 쳐다봤음. 이건 이메일인데 “데스크톱 버전”과 “모바일 버전”이 무슨 뜻임? 어떻게 그런 게 성립함? “변환”된다는 게 무슨 뜻임? 그냥 복사하는 거잖음. 전달했을 때 “깨진다”는 사실 자체가 이 방식이 얼마나 어리석은지 보여줌. 도대체 왜 내 이메일에 CSS가 들어가야 함?
  기울임꼴 정도를 표현하려면 Markdown 같은 훨씬 단순한 방식을 채택했어야 하는데 아직도 그러지 않은 게 말이 안 됨. 이 상황을 실제로 개선하려는 관심이 얼마나 적은지 보여줌. 전부 로고와 배너를 어디에나 넣고 싶어 하는 이상한 기업 요구를 맞추기 위한 것뿐임. HTML 이메일은 정말 터무니없음

  • 단순히 기울임꼴 등을 표현하고 싶다면 1996년에 나온 text/enriched [1]를 원하는 것 같음. 거의 모든 이메일 클라이언트가 읽기 지원을 할 가능성이 큼
    [1] https://www.rfc-editor.org/rfc/rfc1896.txt
  • MJML 같은 반응형 이메일 프레임워크는 실제로 존재함

• 이메일의 서식 있는 텍스트에는 HTML 대신 Markdown에서 인라인 HTML을 뺀 형태나 비슷한 단순 텍스트 마크업을 써야 한다고 오래 주장해 왔음
  그러면 이메일 클라이언트가 서식 있는 텍스트로 보여줄지, 그냥 일반 텍스트로 보여줄지 쉽게 결정할 수 있고, 일반 사용자가 필요로 하는 대부분의 서식도 지원할 수 있음: 굵게, 기울임, 인용, 인라인 이미지, 코드 블록, 제목 등
  아주 고급 HTML을 쓰는 마케팅 이메일에는 좋지 않겠지만, 그런 용례를 신경 써야 한다고 보지는 않음

  • 비슷한 것으로 RFC 1896에 정의된 text/enriched가 있음. Apple Mail 등도 지원함
    https://en.wikipedia.org/wiki/Enriched_text
    https://www.rfc-editor.org/rfc/rfc1896.html
  • 많은 Markdown 파서가 인라인 HTML을 허용함. 어떤 언어에서는 대부분이 그렇고, 끌 수 있게 해주는 파서는 일부뿐임. 정말 어리석음
  • Lynx 브라우저처럼 텍스트 터미널에서 HTML을 보여주는 방식도 꽤 잘 동작하는데, 굳이 다른 마크업 언어가 왜 필요한지 모르겠음
  • 충분한 도입을 얻기 어려움. 이메일 표준은 바꾸기 힘들기 때문임
    아직 이메일에서 하이퍼링크를 거는 지원조차 없고, 최근에 그걸 고쳐보려 했음
    https://pastebin.com/kHQs50xm
  • 색상과 크기는 글쓰기의 기본적이고 유용한 요소임

• 조직의 진짜 위험은 HTML 이메일을 생성하라고 배정한 개발자가 미쳐서 서버실에 틀어박힌 뒤 “왜 Outlook 렌더링이 다르게 나와”라고 소리치며 모든 하드웨어를 부수는 것임
  물론 진지하게 말하면, 이건 매우 흥미로운 취약점임

  • 그래서 몇 년 전부터 이메일 관련 작업은 그냥 HTML 이메일 코딩 서비스에 돈을 내기로 했음. Litmus 테스트를 통과하는 HTML 템플릿을 코딩하려면 특수 지식이 많이 필요하고, 다시는 거기에 들어가고 싶지 않음

• 스타일시트는 허용하지 않고 태그의 인라인 style 속성만 허용하면 고칠 수 있지 않을까?
  사용성을 위해 이메일 클라이언트가 모든 스타일시트를 인라인 스타일로 “컴파일”하는 자동 단계를 넣을 수도 있음
  이렇게 하면 고급 CSS 선택자, 예를 들어 hover 같은 것만 깨질 텐데, 그런 게 꼭 필요한지는 잘 모르겠음

  • 동의함. 메일을 보여주기 전에 모든 클래스를 인라인 스타일로 구워 넣으면 해결될 듯함. 어차피 그렇게 하는 편이 말이 됨
    의사 클래스와 미디어 쿼리는 동작하지 않겠지만, 그것들은 보안 위험이 될 수 있고 주요 메일 클라이언트에서도 지원되지 않음: https://www.caniemail.com/features/css-at-media/
  • HTML 이메일은 Outlook과 Gmail이 수십 년 된 렌더링 엔진을 쓰기 때문에 이미 CSS를 인라인화해야 함. Outlook은 말 그대로 2006년 무렵의 MS Word HTML 엔진을 씀
    게다가 모든 style 속성을 죽이면 모바일 최적화와 다크 모드도 같이 죽음. 미디어 쿼리는 인라인화할 수 없기 때문임
  • 그러면 현재의 반응형 이메일 접근도 깨짐
    보통 기본/데스크톱 스타일은 이미 컴파일되어 인라인화되고, 모바일 기기에서 읽기 쉽게 하려고 head 안의 style 태그에 미디어 쿼리 선택자를 둠

• 정말 영리함
  전제는 HTML 이메일의 CSS 때문에 어떤 텍스트가 메시지를 전달한 뒤에만 보일 수 있다는 것임. 이는 검증된 이메일의 신뢰성에 큰 위협임
  Thunderbird, Outlook, Gmail 예시가 제시되어 있고 훌륭한 작업임
  나는 모든 메일을 mutt에서 읽으므로 공식적으로는 “남의 문제”임
  그래서 다른 데에 불평하자면, Mozilla에 보고한 날짜가 05.03.2024로 되어 있음. 리틀 엔디언 날짜가 미국식 미들 엔디언 날짜보다 더 말이 된다는 데는 동의함
  하지만 기술자라면 ISO 8601 날짜 형식인 2024-03-05, 하이픈 유무와 관계없이, 을 쓰지 않는 건 잘못이라고 봄 :)

  • 그뿐 아니라 미들 엔디언 날짜 형식을 쓰는 사람은 누구든 잘못하고 있음. 무언가를 쓰는 방식 중 가장 비합리적임
    리틀 엔디언은 적어도 다른 모든 숫자를 쓰는 방식과 반대라는 장점이라도 있지만, 미들 엔디언은 그냥 정신 나간 방식임. 물론 그래서 미국인들이 쓰는 방식이기도 함

• 언급된 일부 이메일 클라이언트가 메일 내용을 추가 HTML 태그로 감싸고 CSS와 클래스 이름을 바꾸는 것이 보임
  왜 이메일 클라이언트는 HTML 이메일을 렌더링할 때 샌드박스 iframe을 쓰지 않는지 궁금함. 여전히 보안 위험이 있나?

  • 추가 HTML은 전달된 이메일을 읽는 클라이언트에서 생기는 게 아니라, 전달할 때 생김
    전달하는 사람이 이메일에 더 많은 텍스트를 추가하고 싶을 수 있으니 예상 가능한 동작임
  • 예전에 iframe을 쓰다가 문제가 있었음. 렌더링이나 보안 문제는 아니었고, 기억상 그쪽은 잘 동작했음
    다만 이메일에 웹사이트 링크가 있고, 샌드박스 iframe이 JavaScript를 허용하지 않으면, 그 보안 컨텍스트가 iframe 안의 링크를 클릭해 열린 페이지까지 이어져 웹사이트가 JS를 쓸 수 없었음
    해결책은 allow-popups-to-escape-sandbox였으므로, 지금은 동작하지 않을 이유가 없어 보임

• 상처를 고치겠다고 팔다리를 잘라내는 전형적인 해결책임. 문제는 이런 해킹이 지배하도록 허용한 이메일 표준화 부실임
  HTML 전반이 이런 우려에 취약하긴 함. 그래도 문제없이 HTML을 쓰는 이메일은 많음. 이 글은 야생에서 마주친 무언가에 대한 개인적 좌절을 보안 문제처럼 포장한 것으로 읽힘

• 머릿속에 떠오르는 가능한 완화책은 이렇지만 효과가 없을 수도 있음: 숨겨진 요소에 눈에 띄게 경고하기, 수신·발신 양쪽에서 감싸는 div 개수를 무작위화하기, 전달 시 실제로 어떻게 보일지 계산해 크게 다르면 확인을 요구하기
  또는 반대로 처리하는 편이 더 효과적일 수도 있음. 다른 클라이언트의 도움을 요구하지 않기 때문임

• “왜 이메일이 조직에 위험한가”로 고치면 됨

  • 그쯤 되면 그냥 “왜 외부와의 커뮤니케이션이 조직에 위험한가”가 됨
    이 글은 HTML 이메일에 고유한 공격 경로를 제시하지만, 이메일을 통한 대부분의 공격은 WhatsApp, Slack, Jira, Zoom 또는 사람들이 외부와 소통하는 어떤 도구로도 쉽게 옮겨갈 수 있음