Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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.

51a79d752c98d83196a9bdb4db9b1c01?s=128

Roberto (Rob) Clapis

March 22, 2018
Tweet

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, [...]
  5. None
  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
  12. None
  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)
  21. None
  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
  33. None
  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