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.

Roberto (Rob) Clapis

March 22, 2018
Tweet

More Decks by Roberto (Rob) Clapis

Other Decks in Technology

Transcript

  1. 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
  2. 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
  3. 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
  4. The attack Delivered-To: [email protected] Return-Path: <[email protected]> ← Envelope crafted by

    attacker (pass SPF) From: Victim <[email protected]> ← Body (what the client shows, not checked by SPF) Hello, [...]
  5. Second problem: what if it fails? SPF record does not

    tell the server what to do if the check does not pass.
  6. 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
  7. DMARC DMARC • checks the FROM address using SPF mechanisms

    • tells the server what to do in case something is wrong
  8. DMARC Example "v=DMARC1; p=reject; rua=mailto:[email protected]" v: version p: what to

    do if fails (reject) rua: send aggregated reports to ([email protected]) ↑ This gives visibility on potential attacks
  9. 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)
  10. 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
  11. 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
  12. 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.
  13. The attack Server with external IP designated as trusted sender

    by the victim service Attacker-Owned subscription Victim Service subscription The internet Victim Client
  14. 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
  15. 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
  16. 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
  17. 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
  18. What if I want to know if an email is

    authentic? after 40 years of email, here are some surprises
  19. 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.
  20. 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.