Email SPFoofing: modern email security features and how to break them

Video: https://www.youtube.com/watch?v=eyuOD6FZO-4

Emails are still the most widespread way to get information about subscriptions and important public services, it is then critical for both users and providers to have a secure way to distinguish between genuine and malicious messages.

To do so, two main standards are currently adopted: SPF and DMARC. This talk shows how they can be circumvented and describes a case study that allowed to elude them in all office 365 email domains.

The session details how to detect attack windows for such bypasses and how to protect against the aggression vectors described.

Transcript

1. Email SPFoofing Modern email security features and how to break them Roberto Clapis (@empijei)
2. whoami • Security Engineer @ Secure Network • Programmer • Geek
3. Email The one thing we all hate but no one can get rid of
4. Email is just text Delivered-To: empijei@gmail.com Return-Path: <michael@scrt.ch> ← Envelope From: Michael Zanetta <michael@scrt.ch> ← Body Hello, [...]
6. Phishing
7. SPF Sender Server Receiver Server Email from server IP DNS TXT & SPF Record Sender Receiver
8. SPF (more details) • When an email is received, the Return-Path header(also called Envelope-From) is read for the domain after the @ sign. • DNS is then queried for SPF and TXT records, some recursive steps may happen (up to 10) • If the IP of the originating server is included in one of the specified lists, the mail is OK
9. SPF record example "v=spf1 a ip4:1.2.3.4/16 include:foo.com -all" a: the server resolved by DNS A record can send emails ip4:1.2.3.4/16: this subnet can send mail include:foo.com: recursively resolve SPF record for foo.com -all: assume the rest is a scam
10. Effects Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) [...] Received-SPF: pass (google.com: domain of michael@scrt.ch designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41;
11. Manual validation dig TXT scrt.ch dig TXT _spf.google.com dig TXT _netblocks.google.com IPExpander 209.85.128.0/17 | grep 209.85.220.41
13. First problem: prevents spam, not phishing The Return-Path header is not shown anywhere. Only From header is
14. The attack Delivered-To: target@gmail.com Return-Path: <attacker@securenetwork.it> ← Envelope crafted by attacker (pass SPF) From: Victim <victim@victimdomain.com> ← Body (what the client shows, not checked by SPF) Hello, [...]
15. Second problem: what if it fails? SPF record does not tell the server what to do if the check does not pass.
16. DMARC DMARC Just relies on SPF and DKIM (DKIM gives a lot of false negatives, it is very impractical and poorly documented/implemented anyways*) * http://noxxi.de/research/breaking-dkim-on-purpose-and-by-chance.htmlz
17. DMARC DMARC • checks the FROM address using SPF mechanisms • tells the server what to do in case something is wrong
18. DMARC Example "v=DMARC1; p=reject; rua=mailto:postmaster+dmarc@yourdomain.com" v: version p: what to do if fails (reject) rua: send aggregated reports to (postmaster+dmarc@yourdomain.com) ↑ This gives visibility on potential attacks
19. Effects ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@scrt-ch.20150623.gappssmtp.com header.s=20150623 header.b=IUMqcEnT; spf=pass (google.com: domain of michael@scrt.ch designates 209.85.220.41 as permitted sender) smtp.mailfrom=michael@scrt.ch; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=scrt.ch
20. What could possibly go wrong Basically SPF and DMARC rely on IPs being used only once and not shared across different domains. (Let's remember SPF was finally proposed for an RFC in 2014, but started development in 2003)
22. Woe 1: Cloud hosting Most modern servers share the same external IP addresses or addresses range, making it impossible to properly use SPF. Anyone sharing the same external IP can spoof emails
23. Woe 2: Clutter / IPv4 reuse Most SPF records are huge due to replication, see office 365 record: 330688 valid IPs, hard to keep track of everything. IPv4 needs to be reused, we run out of them
24. Case study for both problems: Azure and o365 Of 330688 valid IPs, 30 of them were obtainable by buying an Azure cluster in the EU West zone until late october. (Microsoft fixed the issue when reported) An attacker could deploy a mail server on Azure and send emails impersonating any o365 domains.
25. The attack Server with external IP designated as trusted sender by the victim service Attacker-Owned subscription Victim Service subscription The internet Victim Client
26. The attack Server with external IP designated as trusted sender by the victim service Attacker-Owned subscription on Azure Office 365 The internet Victim Client
27. Don't use the cloud? But I don't use the cloud!!!!!!!
28. You like email campaigns, don't ya?
29. The attack Server with external IP designated as trusted sender by the email campaign service Attacker-Owned subscription Email Campaign subscription The internet Victim Client Server with external IP designated as trusted sender by the victim service
30. Woe 3: Mail campaign Most mail campaign services: • use AWS, GCP or Azure, and include all the possible external IPs they can be assigned by those services • They accidentally include anyone in their NAT or in their region
31. So... what can I do to set it up? • Make sure you are assigned a non-shared IP by your cloud provider, or move the mail server somewhere you can do so • Use a different domain for mail campaigns and only include the loose SPF record in that domain: use @ads.mydomain.com instead of @mydomain.com for campaigns
32. What if I want to know if an email is authentic? after 40 years of email, here are some surprises
34. 1) READ THE SOURCES! Look for the source IP, see in which subrecord and in which recursive call was matched. Getting a non-campaign email from an IP address that was only included in the external campaign SPF record is at least suspicious.
35. 2) USE BING! To detect if a domain is sharing the same external IP with other ones like in most modern cloud services... you might use BING ( ip:<the ip you got the mail from> ) if a service shares its IP, it's usually with several others.
36. Thank you Roberto Clapis @empijei