SpamChannel: 200만 개 이상 도메인에서 스푸핑 이메일 보내고 사실상 사탄이 되기 [PDF]

 (media.defcon.org)
1P by GN⁺ | ★ favorite | 댓글 1개
  • DEFCON 31 2023 발표 SpamChannel은 Cloudflare Worker로 이메일을 보내려는 시도에서, 200만 개 이상 도메인 대상 스푸핑 문제를 다룸
  • 핵심 실험은 이메일 전송을 수작업이 아니라 프로그래밍 방식으로 처리하고, Worker 배포 흐름에 연결하는 데서 출발함
  • Cloudflare Workers는 JavaScript, TypeScript, WASM 기반 서버리스 컴퓨팅 환경으로 소개됨
  • 기본 절차는 npm create cloudflare@latest로 프로젝트를 만들고 npx wrangler deploy로 배포하는 흐름임
  • Workers에서 이메일을 보내는 실마리는 Cloudflare 블로그의 MailChannels 연동 글에서 이어짐

SpamChannel 발표의 출발점

  • SpamChannel은 DEFCON 31 2023에서 Marcello Salvati(@byt3bl33d3r)가 발표한 PDF로, 200만 개 이상 도메인에서 스푸핑 이메일을 보내는 주제를 다룸
  • 발표의 목표는 이메일 전송을 다음 조건에서 구현하는 것임
    • 이메일을 프로그래밍 방식으로 보내기
    • Cloudflare Worker를 통해 보내기
  • 법적 책임과 관련해 “범죄를 하지 말라”는 면책 고지가 포함됨

Cloudflare Workers와 이메일 전송 단서

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 발표 영상: https://www.youtube.com/watch?v=NwnT15q_PS8
    또는 여기에도 있음. 내 Firefox에서는 영상 형식이 안 됐지만 VLC로는 재생됨: https://media.defcon.org/DEF%20CON%2031/DEF%20CON%2031%20vid...

  • SPF는 이 발표에서 다룬 것보다 훨씬 더 여러 방식으로 망가져 있음. 이메일 보안 강화/도달률 지원 엔지니어로 일하는 입장에서, 조언은 늘 SPF보다 DKIM + DMARC에 집중하라는 쪽임
    레거시 이유로 SPF는 여전히 필요하지만, 도달률이나 사칭 방지에 의존하면 안 됨
    슬라이드 54는 DKIM + DMARC가 이 공격에 도움이 안 된다고 하지만 완전히 맞지는 않음
    위임한 모든 발신자에 DKIM을 설정했을 때에만 DMARC p=reject 정책을 안전하게 켤 수 있고, 그 수준에 도달하면 SPF에서 ? 중립 수정자를 써서 서드파티 발신자에 대해 SPF를 빼기 시작할 수 있음
    예를 들어 v=spf1 include:relay.mailchannels.net ~all이 v=spf1 ?include:relay.mailchannels.net ~all이 됨
    이렇게 하면 MailChannels에서 온 메일은 DMARC 가능 수신자에게 SPF가 중립으로 처리되어 DKIM을 쓰게 되고, 오래된 레거시 메일 서비스도 중립 결과는 받아들여야 함
    완벽한 해결책은 아니지만, 이메일은 어차피 100% 신뢰 가능하거나 안전해질 수 없음

    • 그렇다면 SPF의 문제가 뭔지 궁금함. TCP에서 출발지 IP 위조는 꽤 어렵기 때문에, DKIM이 SPF보다 어떤 장점이 있는지 늘 의문이었음
      나는 SPF를 $myIP만 허용하도록 설정해 왔음. 내 도메인 이름으로 스팸을 보내려면 ISP나 등록기관을 먼저 털어야 하고, 그 정도면 내 도메인의 TLS 인증서도 받을 수 있음
      여러 발신 시스템을 허용 목록에 넣어야 하는 큰 조직에서도, DKIM 레코드 위조가 불가능한 상황에서 합법적인 SPF 발신자 중 하나인 척하는 방법이 뭔지 모르겠음
      제출된 발표처럼 누구나 공개적으로 쓸 수 있는 IP 범위를 허용 목록에 넣는 경우는 그냥 어리석은 설정임
      메일 교환 전체를 위조하려면 몇 바이트짜리 이메일 하나에 테라바이트급 트래픽이 필요하고, STARTTLS가 강제되면 불가능해짐

  • 우리는 프로덕션에서 Cloudflare Workers + MailChannels를 쓰고 있음. 아찔함
    이미 CF Workers에서 실제 서버로 옮기는 작업을 하고 있었는데, 이제 MailChannels도 떠나야 할 것 같음
    보안 위험은 편의성만큼의 가치가 없음

    • 2023년 6월 이후로는 DNS에 _mailchannels 레코드를 공개하지 않으면 Workers에서 MailChannels를 통해 이메일을 보낼 수 없음
    • 분명히 하자면, 이 이슈는 MailChannels가 발신 도메인의 검증된 소유자인지 발신자를 인증하지 않는 것에 있음. CF Workers가 문제가 아님

  • “DKIM 서명이 없지만 DKIM을 구현한 도메인에서 온 모든 이메일에 배너를 표시한다”는 건, 내가 이해한 바로는 대부분 불가능함. 어떤 도메인이 DKIM을 구현했는지 확실히 알 방법이 없기 때문임
    이론상 "_domainkey.example.com"에 DNS 질의를 해서 NXDOMAIN인지 NOERROR인지 볼 수는 있음. 후자는 보통 하위 도메인이 있다는 뜻이고, 따라서 DNS에 DKIM 키가 일부 있다는 의미가 될 수 있음
    하지만 선택자 이름을 알 수 없고, 그 키가 활성 상태인지 나중에 활성화하려는 것인지도 알 수 없음
    한 도메인에 인증된 발신자가 여러 개 있고, 일부는 DKIM 서명을 쓰지만 일부는 안 쓸 수도 있음
    모든 DNS 서버가 표준을 제대로 따르지는 않아서 NXDOMAIN/NOERROR 구분도 대체로만 작동함

    • 메일 트래픽의 통계적으로 유의미한 비율을 보는 제공자라면 모든 또는 거의 모든 DKIM 선택자를 볼 수 있음
      인용한 문장은 MailChannels에서 온 메일 중 DKIM 서명이 없는 것을 거부하자는 뜻으로 보임

  • “MailChannels의 주요 고객은 자신들이 보내는 이메일의 도메인을 소유하지 않는 웹호스팅 제공자”라는 건 한동안 들은 변명 중 가장 형편없음
    웹호스팅 제공자는 보통 호스팅하는 도메인을 “소유”하지는 않지만, 어떤 도메인을 호스팅하는지는 분명히 알고 있음. 도메인을 고객 계정/디렉터리로 라우팅하는 게 웹호스팅의 핵심임
    필요한 건 cPanel 같은 통합으로 도메인 목록을 보고하고, 각 도메인을 무작위 생성 키에 묶는 정도임
    이 모든 건 최종 사용자를 귀찮게 하지 않고 자동화될 수 있고, 그래야 함

    • 메일링 리스트는 어떻게 할 건가? 메일 전달은?

  • DMARC 명세가 진화해서 검증에 SPF가 아니라 DKIM만 쓰도록 할 방법이 있으면 좋겠음. 안타깝게도 Google Calendar 초대 같은 것들은 아직도 DKIM에 실패함

    • 다음 DMARC 릴리스에는 DMARC 검증에서 SPF를 제외하는 옵션이 들어갈 가능성이 큼. Google 팀이 IETF DMARC 메일링 리스트에서 이를 밀고 있음:
      https://mailarchive.ietf.org/arch/msg/dmarc/PDktxOYkB28k6ukL...
      도메인 소유자가 DMARC를 쓰면서도 “내 도메인의 트래픽을 진짜로 인증하는 메커니즘은 DKIM만으로 해 달라”고 지정할 수 있으니 매우 좋은 아이디어라고 봄
      업계에는 SPF 해석 시점에만 알 수 있는 기준으로 인증을 동적으로 조정하는 SPF 매크로 같은, SPF와 DMARC 약점을 우회하는 방법이 많음
      하지만 어떤 우회책도 “내 도메인은 DKIM만 써 주세요”라고 말하는 것보다 낫지는 않음

  • 최근 내 도메인의 이메일 준비를 직접 겪었고, 특히 “자기 장비에서 이메일을 보내려면 비즈니스 계정이어야 한다”고 정한 ISP 때문에 미칠 듯이 답답했는데, 이런 일은 정말 화가 남
    나는 네트워크의 책임 있는 구성원이 되려고 죽어라 노력하고, 내 시스템을 제대로 맞추려고 현재 최신 수준까지 파고들며 찢어봤음
    그런데 저런 사람들이 존재할 뿐 아니라 사실상 오픈 릴레이처럼 가볍게 운영하고, 인터넷의 거의 절반이 그 대가를 지불한다니 어이가 없음

  • 요약하면, 많은 SPF 레코드에 포함된 오픈 릴레이를 발견했다는 얘기임

    • SPF 레코드로 스스로를 열어 둔 200만 도메인 중 1천 개 미만만 DKIM/DMARC 레코드를 설정했고, 심지어 DKIM을 구성하고 방치한 경우도 Gmail에서는 여전히 인증된 것으로 통과함
    • 그보다 더 나쁨. 플랫폼 자체가 도메인 소유권 검증을 시도조차 하지 않아서 누구 이름으로든 보낼 수 있었음
    • 엄밀히 말하면 오픈 릴레이는 아님. MailChannels가 스팸과 피싱을 공격적으로 제어하지 않았다면 인터넷에 존재할 수 없었을 것임
      DEFCON 발표는 거대한 구멍의 존재를 증명한 게 아니라, 인터넷 이메일 초창기부터 있었던 사실을 보여줬음
      S/MIME이나 DKIM 같은 메시지 서명을 쓰지 않으면 발신자 도메인을 충분히 인증할 수 없음
      DKIM이 있어도 DKIM 재전송 공격으로 광범위한 남용이 가능함

  • ARC 헤더가 스팸 점수에 미치는 영향이 흥미로움. 개인 메일 서버를 운영하는 입장에서, 의미 없는 ARC 헤더 세트를 내 이메일에 추가하기만 해도 도달률을 높일 수 있는 건가?

    • 그렇지 않다고 말하고 싶음. 그게 사실이라면 여러 제공자에 흩어진 내 모든 받은편지함이 스팸으로 넘쳐날 것 같기 때문임
      조직적이고 지식 있는 스패머들은 이런 류를 전부 파고들고 있을 테고, 돌파에 써먹고 있을 게 분명함
    • 이메일 업계에서 ARC를 대형 수신자의 스팸 필터를 우회하는 완전한 방법으로 보지는 않음. DEFCON 발표자는 그런 판단을 내릴 준비가 부족했음

  • 이건 2022년 5월에도 이미 확인된 것 같음: https://news.ycombinator.com/item?id=30533032

    • CEO가 이렇게 말한 듯함:
      “우리는 광범위한 스팸 및 피싱 탐지 역량을 갖추고 있고 남용을 처리할 수 있다”
      아, 그렇군 :D
답변달기