▲

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

 (lutrasecurity.com)
2P by neo 8달전 | favorite | 댓글 1개

코볼드 편지

  • HTML 이메일을 기술적으로 다루어야 하는 사람들은 클라이언트들의 불일치하는 구현 때문에 직장을 그만두고 싶거나 모든 메일 클라이언트에 불을 지르고 싶은 순간에 이르렀을 것임.
  • HTML 이메일은 단순히 짜증의 원인만이 아니라 심각한 보안 위험도 될 수 있음.
  • 상사가 대량의 돈을 송금하라는 이메일을 전달했다고 상상해보면, CEO 사기에 대해 들어본 적이 있으므로 이메일이 정말 상사로부터 온 것인지 확인함.
  • 이메일이 상사로부터 온 것이 맞고, 회사에서 그렇게 한다면 암호화 서명까지 되어 있을 수 있음.
  • 그러나 여전히 확신이 서지 않아 상사에게 전화하여 이메일의 진위를 확인함.
  • 상사가 확인해주면 돈을 송금함.
  • 그러나 이것이 사기가 아니었다면 이 기사는 여기서 끝날 것임.

썬더버드

  • 이 문제는 2024년 3월 5일에 모질라에 보고되었고, 계획된 출시 날짜와 다음 섹션의 초안이 2024년 3월 20일에 모질라에 전달됨.
  • 가능한 완화 방안이 논의되었지만, 나중에야 구현될 예정임.
  • 썬더버드에서 이를 이용하는 것은 간단함. 썬더버드는 이메일을 <div class="moz-text-html" lang="x-unicode"></div>로 감싸고 그 외에는 변경하지 않음.
  • 이메일을 전달할 때, 인용된 이메일은 또 다른 <div></div>로 감싸져 DOM에서 한 단계 아래로 이동함.
  • 이를 고려하면 다음과 같은 개념 증명이 나옴:
<!DOCTYPE html>
<html>
  <head>
    <style>
      .kobold-letter {
        display: none;
      }
      .moz-text-html>div>.kobold-letter {
        display: block !important;
      }
    </style>
  </head>
  <body>
    <p>This text is always visible.</p>
    <p class="kobold-letter">This text will only appear after forwarding.</p>
  </body>
</html>
  • 이메일에는 항상 보이는 텍스트와 display: none;으로 숨겨진 텍스트가 포함되어 있음.
  • 이메일을 전달하면 숨겨진 텍스트가 갑자기 새 수신자에게만 보이게 됨.

아웃룩 웹

  • 이 문제는 2024년 3월 5일에 마이크로소프트에 보고되었고, 계획된 출시 날짜와 다음 섹션의 초안이 2024년 3월 20일에 마이크로소프트에 전달됨.
  • 마이크로소프트는 2024년 3월 26일에 즉각적인 조치를 취하지 않기로 결정하고 보고서를 마감함.
  • 아웃룩 웹(OWA)에서 상황은 조금 더 복잡함. 이메일은 <div class="rps_78fa"></div>로 감싸져 있지만, 정확한 클래스 이름은 변경될 수 있음.
  • 이메일의 CSS가 웹메일러의 스타일에 영향을 주지 않도록, 아웃룩은 이메일의 모든 id와 클래스 앞에 x_를 붙이고 CSS를 조정함.
  • 이를 고려하면 다음과 같은 개념 증명이 나옴:
<!DOCTYPE html>
<html>
  <head>
    <style>
      .kobold-letter {
        display: none;
      }
      body>div>.kobold-letter {
        display: block !important;
      }
    </style>
  </head>
  <body>
    <p>This text is always visible.</p>
    <p class="kobold-letter">This text will only appear after forwarding.</p>
  </body>
</html>
  • 이메일을 OWA에서 표시할 때 CSS는 다음과 같이 보임:
<style>
  <!--
  .rps_78fa .x_kobold-letter  {display:none}
  .rps_78fa > div > div > .x_kobold-letter  {display:block!important}
  -->
</style>
  • 이메일을 전달한 후, 코볼드 편지는 또 다른 <div>로 감싸지고 CSS가 다시 업데이트됨.

지메일

  • 이 문제는 2024년 3월 5일에 구글에 보고되었고, 계획된 출시 날짜와 다음 섹션의 초안이 2024년 3월 20일에 구글에 전달됨.
  • 지메일은 기술적으로 코볼드 편지에 취약하지 않음. 왜냐하면 이메일을 전달할 때 모든 스타일을 제거하기 때문임.
  • 이메일을 전달할 때 CSS가 제거되기 전까지는 CSS로 숨겨진 코볼드 편지가 자동으로 나타나게 됨.

이전 연구

  • 이러한 가능성이 있는 것은 놀랍거나 새로운 것이 아님.
  • 비슷한 문제들이 과거에 보고된 적이 있음.

전망

  • 사용자는 HTML 이메일을 완전히 비활성화하거나 제한된 모드에서 보는 것으로 코볼드 편지를 완화할 수 있음.
  • 이메일 클라이언트에 대해서는 완화를 구현하기 어려움. <style>의 사용을 방지하는 것은 문제를 해결할 수 있지만, 이메일 생태계에서 이미 존재하는 많은 솔루션을 깨뜨릴 수 있음.
  • 안타깝게도 가까운 미래에 이메일 클라이언트들이 견고한 완화책을 구현할 것으로 기대하기는 비현실적임.

GN⁺의 의견

  • 이 기사는 HTML 이메일의 취약성을 보여주며, 특히 이메일이 전달될 때 내용이 변할 수 있는 '코볼드 편지' 공격에 대해 설명함. 이는 이메일 사용자들에게 보안에 대한 경각심을 불러일으키는 중요한 정보임.
  • 이메일 클라이언트들이 CSS를 다루는 방식에 따라 보안 취약점이 발생할 수 있음을 보여주며, 사용자와 개발자 모두에게 보안에 대한 주의를 촉구함.
  • 이러한 공격은 사용자가 신뢰하는 소스로부터 온 것처럼 보이기 때문에 특히 위험함. 이는 이메일을 통한 소통에 있어서 항상 경계해야 할 필요성을 강조함.
  • 기술적인 관점에서, 이메일 클라이언트 개발자들은 이러한 공격을 방지하기 위해 CSS 처리 방식을 개선해야 할 필요가 있음. 그러나 이는 기존의 이메일 디자인과 호환성 문제를 야기할 수 있어, 적절한 균형을 찾는 것이 중요함.
  • 이 기사는 새로운 기술이나 오픈소스에 관한 것은 아니지만, 이메일 보안과 관련된 기술을 도입할 때 고려해야 할 사항들을 제시함. 이메일 클라이언트 개발자들은 사용자의 보안을 강화하면서도 사용성을 유지할 수 있는 방법을 모색해야 함.
▲
neo 8달전  [-]
Hacker News 의견

  • “However, you are still not convinced, so you call your manager to ensure that the email is legit. He confirms, so you transfer the money.”

    • 이 댓글은 이메일을 통한 금전 이체 요청에 대한 의심이 제기될 때, 단순히 "이 이메일을 보냈느냐"고 묻는 것이 아니라, "정말로 이렇게 돈을 이체하길 원하는가"와 같이 구체적으로 물어봐야 한다는 점을 강조함. 이러한 대화를 통해 공격이 실패할 가능성이 높아질 것이라는 의견을 제시함. 또한, 기사에서 설명하는 공격 시나리오가 성공하기 위해선 매우 특정하고 좁은 상황이 필요하다고 지적하며, 이러한 복잡한 공격이 실제로 성공할 가능성에 의문을 표함.

  • The other day I was discussing the design for an "update" email that our designer was putting together...

    • 이 댓글은 이메일 디자인에 대한 경험담을 공유함. 디자이너가 만든 이메일의 그래픽 헤더 때문에 제목을 보려면 스크롤을 내려야 하는 문제를 지적하고, 이메일이 포워딩될 때 모바일 버전에서 데스크톱 버전으로 변환되는 것에 대해 놀라움을 표현함. 이메일에 CSS가 사용되는 것 자체가 불필요하다고 비판하며, 마크다운과 같은 간단한 텍스트 마크업이 도입되지 않은 현 상황에 대해 불만을 표함.

  • I long argued that we should use markdown (without the inline HTML) or a similar simple text markup...

    • 이 댓글은 이메일에서 HTML 대신 마크다운이나 비슷한 간단한 텍스트 마크업을 사용해야 한다고 주장함. 이렇게 하면 이메일 클라이언트가 리치 텍스트로 표시할지 일반 텍스트로 표시할지 결정하기 쉬워지며, 사용자가 필요로 하는 대부분의 포맷팅을 지원할 수 있다고 설명함. 마케팅 이메일에 사용되는 고급 HTML은 중요하지 않다는 의견을 제시함.

  • The real risk to your organisation is that the developer you assign to generate HTML emails will go mad...

    • 이 댓글은 HTML 이메일을 생성하는 개발자가 아웃룩의 다른 렌더링 때문에 미쳐버릴 수 있다는 농담을 하며, 이메일을 통한 공격이 흥미롭다고 언급함.

  • Wouldn’t this be fixable by not allowing Stylesheets but only inline style attributes on the tags?

    • 이 댓글은 이메일에서 스타일시트를 허용하지 않고 태그에 인라인 스타일 속성만 사용하는 것으로 문제를 해결할 수 있을지 제안함. 이메일 클라이언트가 스타일시트를 인라인 스타일로 자동 변환하는 단계를 포함시키면 사용성이 향상될 수 있다고 주장함.

  • HTML in email shouldn't be as big of a nightmare as it is.

    • 이 댓글은 이메일에서 HTML이 큰 악몽이 되어서는 안 된다고 언급함. 모든 이메일 클라이언트가 텍스트 대 HTML을 확인하고 HTML일 경우 렌더링 엔진을 웹킷으로 전환하면 문제가 쉽게 해결될 수 있다고 주장함. 이에 대한 표준이 제안되었는지 궁금해함.

  • Some possible mitigations from the top of my head (maybe ineffective):

    • 이 댓글은 이메일을 통한 공격을 완화할 수 있는 몇 가지 방법을 제시함. 숨겨진 요소에 대한 경고, 포워딩 시 메시지의 모습을 계산하여 크게 달라질 경우 확인을 요청하는 것 등이 그 예임.

  • When efail came out, I wrote a blogpost about the security risks of HTML mail.

    • 이 댓글은 HTML 이메일의 보안 위험에 대해 블로그 포스트를 작성했다고 언급함. HTML 이메일 사양이 오래되었고 보안 고려 사항이 거의 없으며, 안전한 HTML 이메일은 HTML의 부분집합이어야 하지만 그 부분집합이 무엇인지 아무도 정의하지 않아 보안 결함이 끊임없이 발생한다고 지적함.

  • This is really clever!

    • 이 댓글은 HTML 이메일에서 CSS를 사용하여 메시지가 포워딩된 후에만 특정 텍스트가 보이게 하는 것이 매우 영리하다고 칭찬함. 이로 인해 검증된 이메일의 신뢰성에 큰 위협이 될 수 있다고 언급함. 또한, 이메일 클라이언트가 이메일의 내용을 추가 HTML 태그로 감싸고 CSS 및 클래스 이름을 수정하는 것에 대해 궁금증을 표현함. 이메일 클라이언트가 HTML 이메일을 렌더링하기 위해 샌드박스된 iframe을 사용하지 않는 이유에 대해 의문을 제기함.
답변달기