[KOR] SPF, DMARC 적용 여부 리서치

요약

이 글에서는 2021년 8월 기준 약 700개의 사기업 및 공공기관 도메인의 SPF, DKIM, DMARC 적용 여부에 대해서 알아본다. 크롤링, spoofcheck툴 수정, PoC 제작 등의 방법론에 대해 간단하게 설명한 뒤, 알아낸 결과를 정리한다. 마지막으로, 일반인의 입장에서 이메일 헤더 가 스푸핑된 이메일을 받았을 때 대처 방법에 대해 알아본다.

배경

몇 달 전 모 카페에서 피싱 이메일 관련된 글을 읽었다. 그 당시에는 또 다른 피싱 이메일이겠거니 하고 지나갔지만, 이메일 보안을 배우기 시작하며 그 글이 다시 떠올랐다. 정확하게 기억 나진 않지만 이런 내용의 글이였다.

noreplay 라는 이름으로 <유명_회사.com> 도메인에서 가입을 위한 인증 메일이 왔다. 스팸메일함에도 들어가 있지 않았다. 이미 계정이 있는데 가입 인증 이메일을 받다니 해킹시도나 피싱 이메일이 의심된다.

타겟 회사의 도메인을 그대로 썼지만, 유저 이름이noreply 가 아닌 noreplay 인 것을 보아 전형적인 SMTP 헤더 스푸핑 공격인 것 같았다.

이메일 헤더 스푸핑이야 워낙 역사가 깊고, 이에 대응할만한 SPF (Sender Policy Framework), DKIM (DomainKeys Identified Email), DMARC (Domain Message Authentication Reporting & Conformance) 또한 만들어진 뒤 많은 자료들이 나와있다 [1] [2] [3] [4]. 따라서 이 글에서는 15년 동안 다뤄진 이메일 스푸핑과 이를 막는 방법 (SPF, DKIM, DMARC) 에 대해서 자세히 설명하지 않는다.

[1] (한글) https://meetup.toast.com/posts/248
[2] https://www.praetorian.com/blog/email-security/
[3] https://protonmail.com/support/knowledge-base/anti-spoofing/
[4] https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/use-dmarc-to-validate-email?view=o365-worldwide

아주 간단하게 SPF, DKIM, DMARC 를 정리하면 다음과 같다:

SPF: 메일서버등록제: 도메인 레코드에 허락된 이메일 서버들의 정보 및 IP주소를 등록한다. 이메일 수신 서버는 해당 도메인의 DNS 정보를 찾아 이메일 서버 정보를 받아본 뒤, 자신이 현재 받은 이메일의 발신자 정보와 일치 하는지 검증한다. "우리 도메인에서 온 이메일인데 이 IP나 도메인에서 온 이메일이 아니면 스팸일 확률이 높습니다" 라고 알려주는 것과 같다.
DKIM: 도메인 키 인증 메일: SPF가 이메일 서버의 인증을 검증한다면, DKIM은 이메일 내용의 무결성을 검증한다. 도메인 DNS에 공개키 정보를 등록해놓는다. 이메일이 발송될때는 개인키로 이메일을 서명한 뒤 발송한다. 이메일 수신 서버는 이메일을 받은 뒤 도메인의 DNS에서 공개키를 받아 서명의 해시값을 확인한 뒤, 해시값이 변경되지 않았다면 이메일의 내용이 변조되지 않았다고 판단할 수 있다. "이메일 받았으면 이 공개키로 서명 해시 확인해보세요" 라고 알려주는 것과 같다.
DMARC: 도메인 기반 이메일 인증: 이메일 수신 서버가 SPF와 DKIM을 이용해 이메일이 스팸이라고 판단할 때, 해당 이메일의 처리 여부를 알려준다. 아무것도 하지않는 none, 스팸함으로 보내라고 알려주는 quarantine, 아예 이메일을 수신 거부 하라고 알려주는 reject 가 있다. "SPF, DKIM이 안맞는 수상한 이메일이 있다면 <none/quarantine/reject> 해주세요" 라고 알려주는 것과 같다.

문제 / 궁금증

내가 궁금했던 문제는 2021년 기준 우리나라 기업/단체/기관들의 SPF 와 DMARC 적용 여부 및 도메인 사용 가능 여부였다. 이와 비슷한 리서치는 항상 국내외에서 이뤄지고 있고, 논문도 여러개 있겠지만, 내가 직접 해보고 싶었다.

해결

문제 해결을 위해 다음과 같은 방법론을 사용했다. 논문이나 프로페셔널한 리서치가 아니라 주말에 몇 시간 짬 내 간단한 사이드 프로젝트를 진행하는 것이니 단순한 방법론을 이용했다.

우리나라의 사기업 및 공기업 리스트를 특정 사이트 크롤링을 통해 확보한다.
BishopFox 사의 spoofcheck 프로그램을 살짝 수정해 #1 번 리스트의 SPF 와 DMARC 적용 상태를 확인해본다.
#2번의 도메인들이 실제로 피싱이 가능한지 이메일을 보내는 PoC를 제작한다. 그 뒤 본인의 이메일 서버와 본인의 공격자 아이디, 그리고 본인의 피해자 아이디를 만들어 피싱 이메일 시나리오를 실행한다. ‌‌‌‌
실제로 피싱 이메일이 보내지는지, 피해자 아이디에서 받아지는지 확인해 PoC를 검증한다.

1단계 - 크롤링

깃헙이나 gist 등을 통해 크롤링 코드를 공개할까 생각했지만 악용될 여지가 있어 일단은 비공개 처리한다.

크롤링을 한 뒤 도메인만 따로 뽑아내 총 사기업 319개, 공공기관 362개를 추려냈다.

2단계 - Spoofcheck

spoofcheck 툴을 이용해 SPF, DKIM, DMARC 적용 여부를 살펴봤다. BishopFox 사의 spoofcheck는 DNS 쿼리를 통해 해당 도메인에 SPF 와 DMARC 레코드가 있는지 살펴본 뒤, 간단한 논리를 통해 이메일 스푸핑이 가능한 도메인인지 알려주는 툴이다. 원래 툴이 1개의 도메인 밖에 입력값으로 받지 않기 때문에 코드를 조금 수정했다. 수정한 포크 버전의 spoofcheck 는 깃헙에 올려놓았다.

깃헙 링크

3단계 - PoC || GTFO

1단계와 2단계를 통해 SPF, DKIM, DMARC 적용 여부에 대해 알아봤지만 실제로 해당 도메인들을 이용해 피싱 공격이 가능한지 아닌지에 대해서는 확실하게 알 수 없다. 따라서 PoC제작을 위해 다음과 같은 설정으로 PoC를 진행했다. 이메일을 보내는 PoC 또한 악용될 여지가 있어 공개하지 않는다.

공격자 아이디 - 본인의 구글 아이디
피해자 아이디 - 본인의 구글 아이디
공격자 이메일 서버 - 본인의 이메일 서버
공격자 도메인 - 본인의 도메인
이메일 클라이언트 - 본인이 제작한 스크립트

남에게 피해를 주지 않으며 도덕적인 보안 리서치 (Ethical Security Research) 를 위해 모든 환경은 모두 내가 소유한 유저 아이디, 환경, 서버, 어플리케이션, 스크립트를 통해 이뤄졌다.

테스트 계정 testoblogemailcheck@gmail.com 으로 메일 전송

2단계에서 나온 도메인들 중 약 50개를 무작위로 뽑아 랜덤한 시간을 정해두고 천천히 메일을 전송했다. 그 이상 했다간 구글의 이메일 서버 이용약관에 위반될 수 있으니 진행하지 않았다.

결과

결과의 Weak SPF는 SPF 룰이 없거나, ~all 혹은 -all 이 설정되어 있지 않은 경우에 약한 룰이라고 판단한다. Weak DMARC는 DMARC 룰이 없거나, none으로 설정되어 있는 경우 약한 룰이라고 판단한다. 자동으로 도메인이 피싱에 사용되는 것을 막으려면 SPF 경우 할 수 있는 일이 없고, DMARC가 quarnatine 내지는 reject 로 설정이 되어야한다. 따라서 스푸핑이 가능한 도메인은 온전히 DMARC 에 따라서 결정된다.

최종 결과를 살펴보면 사기업은 20%가 약한 SPF룰을 가졌고, 98% 가 약한 DMARC 룰을 가지고 있다. 공공기관은 13.5%가 약한 SPF 룰을, 약 95.5%가 약한 DMARC 룰을 가지고 있다. 최종적으로 모든 도메인 중 96.7% 가 피싱이 가능한 상태다.

그리고 이는 PoC 스크립트를 실행함으로서 확인할 수 있었다. 약한 SPF와 DMARC를 가진 도메인들 중 무작위로 뽑은 50개가 모두 스푸핑 된 채 메일 수신함에 도착했다.

DMARC 적용의 어려움

모의침투테스터로서 일을 하면서도, 혹은 버그바운티를 진행하면서도 이와 관련된 제보를 하면 돌아오는 대답은 항상 비슷하다.

SPF, DKIM, DMARC를 적용할 경우 일반적인 이메일 발신/수신이 실패할 위험이 있고, 서비스 다운 타임이 생길 수 있기 때문에 검토 해보겠지만 빠른 시일 내에 적용하지 않을 것이다

그리고 이는 100% 이해 가능한 부분이다. 이메일 서버를 운영하는 것도 복잡한데, 이메일 보안을 완벽하게 적용하는 것은 정말 어려울 것이다. 실무에서 일하면서 느끼는 건 개발자, 시스템 관리자, 전산실쪽에서 일하시는 분들은 항상 고생하신다는 것이다.

그래도 씁쓸한 것은 피싱 이메일을 효과적으로 도메인 차원에서 막을 방법이 있는데도 책임을 이용자/피해자에게 넘기는데 있다. 이를 두고 컨퍼런스에서 만났던 한 사람은 마치 "옛날 HTTPS 적용 안하던 웹사이트들이 이용자들에게 보안 책임을 떠넘기던 것과도 비슷하다" 라고 했다. 아래와 비슷한 답변들도 심심치 않게 볼 수 있다:

"이메일 수신 서버에서 필터링 해 스팸함에 넣으면 그만이다"
"이용자들이 피싱 이메일에 더 관심을 기울이면 된다"
"우리 도메인측이 아닌 이메일 릴레이 서버나 보안 솔루션들이 해결해야할 문제다"

이런저런 씁쓸함이 있지만, 전세계적으로 DMARC를 적용하는 도메인들은 빠르게 늘고 있다. 우리나라도 비슷한 트렌드이길 바랄뿐이다.

이미지 출처: https://dmarc.org/2021/02/dmarc-policies-increase-43-over-2020/

대응 방법

이메일 헤더 스푸핑의 경우 워낙 오래된 공격이다 보니 일반적인 이용자들이 사용하는 서비스의 경우 알아서 스팸함으로 보낸다. 왠만한 회사의 경우도 이메일 보안 솔루션이나 이메일 게이트웨이에서 알아서 필터링을 해주기 때문에 큰 걱정 할 필요 없다. (물론 이를 우회할 방법도 있지만, 그건 모의침투테스트 할때나 필요한 것이다)

스푸핑 된 from 헤더와 실제 공격자의 호스트이름/도메인을 보여주는 X-AntiAbuse

그럼에도 불구하고 불안하거나, 혹은 필터링을 거쳐 들어온 이메일이 있을 수 있다. 이 경우 "원본 보기" 혹은 "원문 보기" 등을 이용해 X-Source-Sender, X-AntiAbuse, X-Source-Auth, X-Sender, Return-Path 등의 이메일 헤더와 From 헤더를 비교해보면 어떤 서버에서 스푸핑 했는지 알 수 있다.

위 스크린샷의 경우에도 From 헤더는 스푸핑됐지만, X-AntiAbuse 과 X-Source-Sender 등의 이메일 헤더는 공격자의 아이피주소, 실제 이메일 주소, 호스트 이름 등을 보여주고 있다.실제 공격자라면 이 주소들 또한 장악한 이메일 서버를 쓰거나 오픈 릴레이 이메일 서버를 사용한다. 하지만 어쨌든 이런 헤더들을 확인해 헤더 스푸핑이 됐는지 안됐는지 확인하는 것이 중요하다.

확인 됐거나 누가봐도 수상한 피싱 이메일이라면 회사 내 보안팀, 혹은 자신이 이용하는 서비스의 "피싱 이메일 신고" 등의 기능을 찾아 신고하는 것 또한 좋은 습관이다.

Happy hacking!