Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

HTTP smuggling is a vulnerability that has thrived over the last few years via differences in parsers at different steps in the HTTP flow. The same bug class has been found in SMTP parsers but is less explored. The goal is to send an email to server A that is then forwarded to server B with data that shouldn't be there.

The goal was to escape the data section to execute SMTP commands from a second email. If you try to place admin@icloud.com as the FROM email, it will reject it via a proprietary check each email provider enforces. In the past, ambigious interprettations of the FROM header have led to bypasses.

In traditional SMTP smuggling, it's all about escaping the data to get into the headers via carriage returns, and line feeds. Normally, the end of data sequence is CR LF CR LF, and an end of line as CR LF. However, some implementations will still parse with only LF LF or CR CR, even though the RFC explicitly says not to to do this. By testing various combinations, they were able to get the iCloud server to see one thing but the end email sending server to see another!

The attack looks like what follows:

...
From\r: \radmin@icloud.com\r\n
From: user@icloud.com\r\n
...

The key issue in the text above is the extra carriage returns in the first FROM header. This is ignored for parsing by the iCloud servers, so it sees the second one as valid instead. Once the email is sent to the next server in the chain, it strips out the extra \r in it. So, the next part of the chain will then see admin@icloud.com instead. Pretty neat!

Most servers won't handle two inbound FROM headers. So, parser 2 can't see the original FROM header. Since the iCloud server will replace standalone \r to be \r\n instead, this can be abused. The legitimate From needs to be after two \r values. When these are later translated, they will create a new data section early! This means that the legitimate iCloud user is pushed into the data while the malicious one survives. In practice, this solves the issue of two From headers. Because DKIM is added at the second server, it works too.

Apple tried fixing this issue by making parser 1 more strict. By reading the RFC, the authors found out that they could acheive a similar smuggling effect by using a leading . on the From header. The iCloud server wouldn't see this but the downstream server would. This seems like an infinite game of wackamole at this point.

Overall, a great blog post on SMTP smuggling, and their thought process for trying different things. For their efforts, they were awarded a 15K bug bounty. Pretty awesome!