By now, Mailsploit has ruffled the feathers of most in the email security community, and may have even made its way to the ears of many IT admins. While the vulnerability mainly affects email clients, these exploits can effectively bypass DMARC, serving as a thumb-in-the-eye for most email security leaders who have been working for the last few years on improving and deploying these enhanced authentication methods.
Essentially, this set of exploits relies on using encoded text that is decoded by most email clients and webmail apps. When encoded text is sent within a sender “from” field in an email, it can pass DMARC and other authentication measures at the gateway level, and then be decoded at the client level to appear as practically any email address that the sender chooses.
This enables perfect spoofing because the emails can pass the most advanced authentication standards while also appearing to users as indistinguishable from legitimate emails, even when watching for the most advanced commonly used spoofing tactics.
Null characters can also be used to fool some email clients, as most clients interpret null characters as the end of a display string, making any characters appended to a sender address invisible to users, creating even more spoofing opportunities.
[cta id=’18654′]
While rules can be established to block or quarantine this sort of sender address, most MTAs don’t prevent this, and few MTAs can address this vulnerability because it mostly occurs at the client level. Regardless, the bug has been reported to and ultimately triaged by most developer organizations for months, including Apple, Microsoft, Opera and AOL Mail.
Ultimately, email client developers haven’t completely abided by the defined standards for writing email, and these shortcuts have created vulnerabilities that malicious attackers can exploit. This isn’t entirely their fault, however, as these standards aren’t clearly established to be compulsory, and the root of the exploit – RFC-1342 – was developed in 1992(!). This entry-level vulnerability also allows other vulnerabilities to be exploited, like the execution of malicious scripts in webmail apps and more, where code can be injected after delivery and wreak havoc on a target user’s device.
Is mailsploit a “mailgeddon”? A freakout moment? Likely not. However, it bears greater cause for concern – if a major vulnerability like this is reported to and unaddressed by major email client organizations for months, what other vulnerabilities aren’t being addressed, and what other unreported issues linger out there to drive even more significant exploits and social engineering attacks, such as Business Email Compromise?
Leave a Comment