The Mailsploit flaw

Developer and security researcher Sabri Haddouche recently discovered a vulnerability in e-mail visualization, the purpose of which is to spoof the sender’s e-mail address or execute malicious code. He warned the major email client publishers, the first to be affected, and after three months, finally published it, naming it Mailsploit.

For historical reasons, message headers can only contain ASCII characters. However, ASCII does not include any characters for languages other than English (accents, cedillas or Asian characters, for example). To overcome this limitation, a technical encoding solution has been found, documented in RFC1342. It is mainly used to encode the subject of emails.

It consists of a syntax that specifies :
– Character set or charset (e.g. utf-8),
– Encoding method (e.g. base-64),
– The encoded character string.

Here’s an example:

The characters “=?” and “?=” indicate the beginning and end of the string. Authorized character sets are those specified in RFC1341 – 7.1. Encoding can be of 2 types: “b” for Base-64, and “q” for Quoted-printable. Finally, the encoded string is, in our example, “éric et françois”, which we generated using the ‘base64’ utility under GNU/linux :

echo "éric et françois" |base64 -> w6lyaWMgZXQgZnJhbsOnb2lzCg==

To generate a quoted-printable string under GNU/Linux, you can use the little script created by Jeff Jarmoc :

qp "éric et françois" -> =C3=A9ric et fran=C3=A7ois

This global encoding method is taken into account by e-mail clients. They know how to interpret and decode these strings, and integrate them into the headers of incoming messages.

The Mailsploit flaw consists in exploiting this encoding to pass special characters that modify the way the field indicating the sender (“From”) will be perceived by the e-mail client, such as the “null” character (“=00” in quoted-printable) or line feed (“=0A” in quoted-printable).

Some e-mail clients (which Sabri Haddouche, with the help of the community, has listed here) don’t handle these characters correctly and therefore behave in unexpected ways. Most of the time, the flaw is used to hide the real sender and display another. In the worst-case scenario (indicated in the “XSS/Code injection” column in the above table), it is possible for the client to execute code included in the chain.

Here is an example of “From” modified to use the flaw:

=?utf-8?b?cHJlc2lkZW50QGVudHJlcHJpc2UuY29tCg==?==?utf-8?Q?=00=0A?= <demo@mailsploit.com>

which we can decode as :

president@entreprise.comn <demo@mailsploit.com>

Affected email clients will stop displaying the sender address at “” (null character) or “n” (line feed), thus hiding the real sender “demo@mailsploit.com”. The recipient will therefore only see “president@entreprise.com” as the sender and is likely to treat the message with less caution than with an unknown sender.

On the Altospam side, we can’t block the principle of header encoding, which is regularly used in legitimate messages and is part of the RFC. We do, however, carry out a number of checks, including the “From” check, to check for malicious code. We took advantage of this alert to further improve our controls. However, this flaw is and remains a problem with the e-mail client, which is supposed to check the correct formatting of incoming message headers.

Most of the information in this article is taken from www.mailsploit.com, which presents and explains the flaw.