Oh no, you're thinking, yet another cookie pop-up. Well, sorry, it's the law. We measure how many people read us, and ensure you see relevant ads, by storing cookies on your device. If you're cool with that, hit “Accept all Cookies”. For more info and to customize your settings, hit “Customize Settings”.

Review and manage your consent

Here's an overview of our use of cookies, similar technologies and how to manage them. You can also change your choices at any time, by hitting the “Your Consent Options” link on the site's footer.

Manage Cookie Preferences
  • These cookies are strictly necessary so that you can navigate the site as normal and use all features. Without these cookies we cannot provide you with the service that you expect.

  • These cookies are used to make advertising messages more relevant to you. They perform functions like preventing the same ad from continuously reappearing, ensuring that ads are properly displayed for advertisers, and in some cases selecting advertisements that are based on your interests.

  • These cookies collect information in aggregate form to help us understand how our websites are being used. They allow us to count visits and traffic sources so that we can measure and improve the performance of our sites. If people say no to these cookies, we do not know how many people have visited and we cannot monitor performance.

See also our Cookie policy and Privacy policy.

This article is more than 1 year old

Mailsploit: It's 2017, and you can spoof the 'from' in email to fool filters

Message client vendors have had 25 years to get RFC 1342 right

Penetration tester Sabri Haddouche has reintroduced the world to email source spoofing, bypassing spam filters and protections like Domain-based Message Authentication, Reporting and Conformance (DMARC), thereby posing a risk to anyone running a vulnerable and unpatched mail client.

What he's found is that more than 30 mail clients including Apple Mail, Thunderbird, various Windows clients, Yahoo! Mail, ProtonMail and more bungled their implementation of an ancient RFC, letting an attacker trick the software into displaying a spoofed from field, even though what the server sees is the real sender.

That means if the server is configured to use DMARC, Sender Policy Framework(SPF) or Domain Keys Identified Mail (DKIM), it will treat a message as legit, even if it should be spam-binned.

The RFC in question is RFC 1342, “Representation of Non-ASCII Text in Internet Message Headers”, and the implementation error Haddouche found was that mail clients and Web mail interfaces don't properly sanitise a non-ASCII string after they decode it.

The embedding, Haddouche wrote, can use either =?utf-8?b?[BASE-64]?= or =?utf-8?Q?[QUOTED-PRINTABLE]?= for the embedding.

Taking Apple Mail as the example, Haddouche wrote that if it's fed the following - From: =?utf-8?b?${base64_encode('potus@whitehouse.gov')}?==?utf-8?Q?=00?==?utf-8?b?${base64_encode('(potus@whitehouse.gov)')}?=@mailsploit.com - there are two security issues, namely:

  • iOS has a null-byte injection bug, so it ignores everything after that byte and shows potus@whitehouse.gov as the sender;
  • MacOS macOS ignores the null-byte but will stop after the first valid email it sees (due to a bug in the parser).

He dubbed the bug “Mailsploit”, and provided a full list of vulnerable clients here.

As readers will see scanning the list of mail apps, Mailsploit has another nasty side: some trouble ticketing systems (Supportsystem, osTicket and Intercom) are also subject to the bug; and in many mailers, the bug can also be exploited for cross-site scripting and code injection attacks.

Most of the vendors Haddouche contacted have either patched or at least got to work on a patch, but Mozilla and Opera reckon it's a server-side issue, and Mailbird “closed the ticket without responding”. ®

 

Similar topics

Similar topics

Similar topics

TIP US OFF

Send us news


Other stories you might like