기업 도메인의 DMARC 레코드 분석

DMARC 란?

SPF, DKIM 및 DMARC는 이메일 인증 프로토콜로 회사의 이메일 도메인으로 하여금 스푸핑, 피싱과 같은 사이버 범죄에 사용되지 않도록 유효성 체크를 하여 기업의 도메인을 보호하고 품질을 개선시켜줄 수 있는 방법으로, Google, Microsoft, Yahoo를 포함한 주요 이메일 제공 업체인 Paypal, Facebook, Linkedin 등 과 협력하여 악성 메일을 방지하기 위해 구현한 인증 메커니즘입니다.

dmarcanalyzer.com

정책이 구현되어 있을 경우 수신 이메일을 검사 -> 이메일 인증 통과 시 전송 -> 통과하지 못할 경우 레코드에 포함된 지침에 따라 이메일 전송(none 또는 Approve), 격리(Quarnatine), 거부(Reject)를 할 수 있습니다.

최근 DMARC가 급부상한 이유와 영향력

"이메일 도메인을 함께 사용하는 기업이 DMARC 정책을 적용하지 않을 경우 공격자는 대상 기업의 올바른 관리자로 위장하여 서비스를 이용하는 다수의 고객들에게 무차별 적으로 악성메일을 보낼 수 있는데, 악성 메일의 유형은 대부분 "계좌정보", "로그인 정보" 같은 개인을 식별할 수 있는 다양한 종류의 정보를 입력하게끔 유도합니다.

 

만약 서비스를 이용하는 사용자들 대상이 아닌 내부 기업 인력들을 대상으로 악성메일을 보내게 될 경우, 공격자는 내부 포털 사이트의 소스를 가져와 이미지 태그로 동일한 피싱 페이지로 유도하거나, 바이러스가 담긴 문서(인사평가, 급여명세서, 등)들을 전달하여 기업 PC가 감염되도록 시도할 가능성이 존재합니다."

• 기업 3곳 중 1곳이 CEO 사칭 이메일
• 전 세계 이메일의 70%가 악성 이메일
• 보안을 위한 기술은 나날이 발전하는 것에 비해 사람들의 보안 인식의 수준 미흡

dmarc.org

해외기업들의 DMARC 적용 트렌드를 보면 최근 들어 많은 관심을 가지고 있는 것을 한눈에 볼 수 있습니다.

DMARC를 적용하면 좋은 이점?

• 서비스를 이용하는 고객 대상의 피싱을 보호
• 이메일을 통해 전파되는 멀웨어 또는 랜섬웨어 차단
• 기업 내부를 대상으로 하는 스피어 피싱 예방

DMARC는 기존에 존재했던 SPF(Sender Policy Framework)와 DKIM(Domainkeys Identified Mail)의 확장 형태의 인증방법입니다. 즉 SPF와 DKIM을 통해 정상적인 메일인지 검증을 하게 되고 검증 이후의 Action을 DMARC 정책(전송, 격리, 거부)을 통해 처리를 하고 보고서를 발송하게 됩니다.

 

우선 각 기능들에 대해 간단히 알아보겠습니다.

SPF(Sender Policy Framework)

보내는 메일 서버의 IP주소가 SMTP Mail From 명령에 나타나는 도메인 소유자의 승인을 받았는지 확인한다. 즉 발송 서버를 사칭하는 메일인지, 정상적으로 인증된 서버인지를 검증하기 위해 발신자 정보와 실제 서버 정보를 비교한다.

DKIM(Domainkeys Identified Mail)

SPF와 함께 구현되어야 하는 이메일 인증 방법으로 메일의 콘텐츠가 합법적인지 확인해주는 기술로, 특정 도메인에서 보낸 이메일을 확인하는 데 사용한다. 즉 누군가의 이메일 계정에 이메일이 실제로 발송된 도메인에서 발송되었는지 여부를 확인하기 때문에 메시지의 무결성을 보장하고 발신자 사칭 여부 검토할 수 있게 된다.

DMARC(Domain-based Message Authentication, Reporting and Conformance)

DMARC는 DKIM 및 SPF에서 제공하는 보호 기능에 보고 기능을 추가하는 기술로, SPF 또는 DKIM 연관 검사를 활용하여 정책에 적합한지 구분 후 결과를 전송하고 이후에 걸러진 악성메일을 어떻게 처리할지 여부를 정하기 때문에 이메일 보안에 있어서 핵심이 된다.

• p=none(모니터 정책): 모든 수신 메일을 통과하도록 허용
• p=quarnatine(검역 정책): 스팸 폴더로 이메일을 보냅니다.(스팸 폴더에는 내용이 유지되고 있기 때문에 완벽하게 안전하진 않음)
• p=reject(거부 정책): DMARC 정책을 적용하는 이유이며, 해당 정책을 통해 승인되지 않을 경우 메일이 전달되지 않음

DMARC 적용 여부 확인

DMARC의 정책이 올바르게 구성되어 있는지 확인하기 위해 대표적으로 2가지 방법을 사용하여 확인해볼 수 있습니다. 우선 온라인 사이트를 통해 확인하는 방법입니다.

https://mxtoolbox.com

MX Lookup Tool - Check your DNS MX Records online - MxToolbox

Search 옵션에 mxtool로 두고 도메인 주소를 검색해보면 여러 정책 정보들이 나타납니다. 도메인 레코드 테스트를 위해 "yahoo.com" 도메인을 입력 후 하단에 나열된 DMARC 관련 정보들을 분석해보면

• Yahoo.com은 "Yahoo Biz" 이름을 가진 이메일 제공 업체를 사용 중
• Response에 DMARC 레코드가 발견됨
• DMARC 레코드 값에는 Quarantine(검역) / Reject(거부) 정책이 활성화되어 있음

이제 취약한 DMARC 레코드 정책을 가진 도메인 정보를 보도록 하겠습니다.

• xxx.com은 "Google Apps" 이름을 가진 이메일 제공 업체를 사용 중
• Response에 DMARC 레코드가 발견되지 않음
• DMARC 레코드 값에는 Quarantine(검역) / Reject(거부) 정책이 발견되지 않음

특정 기업에 해당 문제를 제기하고자 할 경우 아래의 포인트 정도는 체크 후 알려주시는 것이 좋습니다.

• DMARC Policy Not Available / DMARC Policy Not Enabled 일 경우 p=none 의미이므로 취약함
• Your email service provider "" 문구가 없을 경우 이메일 도메인을 쓰지 않는 곳이기 때문에 취약점 제보는 불가능함

---

이제 오픈소스 도구를 통해서도 확인해 보겠습니다. 깃허브 링크는 아래를 참고해주시면 됩니다.
Opensource: https://github.com/BishopFox/spoofcheck => 단일 도메인 테스트
Custom: https://github.com/ChoiSG/spoofcheck => 다중 도메인 테스트

 

기존 spoofcheck는 단일 도메인 테스팅 기반으로 되어있으며, 별도의 옵션 없이 도메인 주소 입력해주시면 정보가 나타납니다.

Yahoo.com의 정보중 v=DMARC1 정책을 보면 p=reject 이 설정되어 있으므로 악성메일로 의심되는 메일들은 자동으로 전달되지 않도록 거부하고 있습니다. 이밖에도 사용된 정책들은 다음과 같습니다.

• pct: 인증되지 않은 메일 중 DMARC 정책을 적용할 비율 지정(Default: 100%)
• rua: SPF, DKIM 및 DMARC에 대한 인정 상태 정보를 집계(날짜, 통과 여부, 발신자 IP 포함)
• ruf: 포렌식에 사용될 보고서로 rua보다 많은 데이터를 집계(이메일의 제목, 헤더, 첨부파일, 링크 URL 등)

반대로 취약한 도메인은 "No DMARC record found" 메시지를 출력함으로 써 Email Domain Spoofing이 가능하다고 나옵니다.

• ~all: 실패지만 수신될 것을 원하며 수신 서버에서 의심스러운 메일로 처리될 수 있음(- 는 수신 메일 서버에서 Drop)

Yahoo의 경우 굉장히 안전한 수준의 이메일 보안을 유지하고 있는 점을 확인할 수 있습니다.

대부분의 기업들은 DMARC의 quarnatine(격리) 수준 정도로만 구성되어 있어도 높은 보안 수준을 기대할 수 있습니다.

DMARC 정책으로 악성메일을 100% 완벽하게 보호할 수 없다고 판단되어 사후 대응이 유리한 "ruf" 레코드를 적용하여 침해사고 분석을 빠르게 대처할 수도 있겠지만, 몇몇 해외기업들은 규정 및 개인 정보 보호의 문제로 인해 ruf는 제외하는 방향으로 적용하고 있다는 점을 참고해주시면 되겠습니다.(Google ruf 사용 X)

 

Send Anonymous Email

https://emkei.cz/

Emkei's Anonymous Mailer

DMARC 적용 유무를 확인했으니 익명 메일 서비스를 이용해서 전송해볼 수 있습니다. 대표적으로 테스트하기 편한 온라인 사이트는 "emkei.cz"로 정하겠습니다.

 

• From Name: 보낸 사람 주소의 앞에 부여되는 이름으로 일반적으로 admin, customer, noreplay 같은 이름을 많이 씀
• From E-mail: Spoofing 할 이메일 도메인(ex: admin@example.com)
• Subject: 메일의 제목

이메일 도메인의 DMARC 정책이 미흡할 경우 위처럼 정상적인 관리자로 위장하여 메일을 수신할 가능성이 있습니다.

 

과연 올바른 주소에서 메일이 전달되었는지 확인해볼까요? 모든 메일에는 "원문보기" 기능이 존재합니다. 메일의 원문과 보낸 메일 헤더를 비교 분석해보면 보낸 사람은 noreplay@xxx.com으로 되어 있지만 실제 보낸 주소는 101.99.94.116 즉 emkei.cz 가 됩니다.

 

주관적 견해

DMARC를 적용함으로써 스팸 및 사회 공학적 공격에 대해 사전에 예방할 수 있는 방법이 있다는 것을 알게 되었다.

최근 민간 기업, 공공기관 등을 대상으로 사이버 공격이 증가하고 있어 정부기관에서는 DMARC를 의무 적용하는 방안으로 추진하고 있다는 내용을 보았다. 국내에도 점차 관심을 가지고 있다는 부분에 있어서는 좋은 점수를 주고 싶다.

모의 해커들 관점에서 DMARC 이메일 보안 프로토콜을 적용하지 않았다는 이유만으로는 취약점 제보로 검증받기는 힘든 부분이 있다.(3,4년 전까지만 해도 소정의 포상금 사례는 존재했음) 이유는 서비스의 안정성 여부를 확보해야 되는 문제가 있기 때문에 과거에도 이를 적용하는 기업이 많지 않았다. 또한 몇몇 기업은 무분별하게 메일을 열람하는 사용자들의 책임으로 넘기는 경우도 존재한다. 마치 Open Redirect을 활용한 Typosquatting 공격처럼 말이다.

물론 어느 정도 이해는 된다. 왜냐하면 기업의 서비스를 우회하거나 직접적으로 기밀성, 무결성, 가용성 측면을 무너트리는 것이 아닌 정상적으로 이용하게 만든 기능을 나쁘게 악용하는 것이니 악용하는 사람 자체의 잘못이다. 하지만 이러한 관점으로 리스크를 관리한다는 것은 공격자들에게 있어서 내부/외부 사용자들을 공격하기 위한 다양한 접근 가능성을 열어주게 되는 격이다.

소속이 있거나 없는 모의 해커의 관점에서 자신이 앞세운 취약점의 위험성을 검증하기 위해 시나리오를 구성하는 경우 DMARC 정책이 미흡한 부분을 Server Security Misconfiguration"으로 추가하여 보고서의 디테일을 추가해줘도 좋을 것 같다는 생각이 든다.

Bugcrowd Rating

 

다크 웹에서 떠도는 해외/국내의 개인정보들은 과연 크리티컬 한 취약점들로 인해서만 유출된 것일까?? 고객들의 개인정보를 소중히 여기고 보안에 대한 서비스 질을 높이고 싶다면 DMARC, Open redirect, SSL/TLS  같은 문제들에 관심을 가질 필요가 있다. 우리가 모르는 사이에 고객 또는 내부정보가 언제 어디서 유출될지 아무도 알 수 없기 때문이다.

 

references

https://blog.sunggwanchoi.com/spfdmarckorea/

https://securelist.com/email-spoofing-types/102703/
https://meetup.toast.com/posts/248
http://www.crypto-it.net/eng/attacks/homograph-attack.html
https://ryanking13.github.io/2018/12/03/idn-homograph-attack.html