Although new messaging apps like WhatsApp, Telegram, and Messenger have taken a large chunk of our day to day communications, email remains one of the most popular ways we communicate. In this post we’ll talk about the post exploitation of a vulnerability we recently disclosed to one of the most popular email providers in Israel.
Like Facebook, Google, and other reputable companies, the email provider operates a bug bounty program where they encourage security researchers to find and report vulnerabilities in their services.
With that said, the company requested to remain anonymous at this time, for the purpose of this post we will refer to it as Y.
The Vulnerability
Email clients use a subset of HTML to provide formatting capabilities that are not available with plain text, things like images, links, colors, etc. This places email providers in a dangerous spot. On the one hand they must filter out dangerous HTML, and on the other hand they want your email to be rendered correctly.
Taking this into account, we started digging into the Y’s HTML filter.
We sent emails with various payloads to our Y mail account. For example, when sending the following HTML as the email body:
<div>
<div>hello<script src=“//example.com”></script>world</div>
</div>
We received the email with the following HTML:
<div>
<div>helloworld</div>
</div>
As you can see, the Y filter deleted the script tag.
However, when sending the following:
<div>
<div>hello<scrXipt src=“//example.com”></scrXipt>world</div>
</div>
No changes were made to the email body, which made us believe Y uses a deny list.
In other words, the Y’s HTML filter is probably looking for specific keywords to remove like <script>, onerror, onload, and more. At this point, we tried to imagine how such a deny list filter might be implemented – after a few minutes we came up with the following pseudo code:
function removeDangerousKeywords(body) {
keywords = [/on[a-z]+/i, /<script/i, /* … */];
for (keyword of keywords) {
body = body.replaceAll(keyword, “”);
}
return body;
}
Other than the obvious issue with a deny list (what if you forgot to block something? 🙈 )
We noticed that the order in which we remove the dangerous keywords can be used to bypass the filter, even if we have a perfect list that contains all the dangerous keywords.
We realized that the email body changes as the filter goes down the list of keywords.
This means that we can engineer a payload that the filter will transform into a dangerous one as it removes keywords in order.
After a few tries we came up with the following payload that worked.
<img src=v on<script>error=alert(location.origin) />
As you can see, the payloads use the <script> tag to hide the “onerror” attribute. Since the rule responsible for removing such attributes runs before the rule that removes script tags, our payload will not be detected.
We could now execute arbitrary JavaScript in the account of any user who opened our email. This could allow us to perform any action as the user, anything from reading all the user emails to sending new ones.
Post Exploitation
While stored Cross-Site Scripting (XSS) in the email body is a big issue, it’s important to remember that once the user reloads the page the attacker will no longer have access to its account. The attacker would have to keep sending his target new emails and hope they will be opened in order to continuously collect information.
We wanted to take a deeper look at this scenario, and see what could be done from the attacker standpoint with this kind of temporary access.
We first examined the Y mail cookies, as they could potentially allow for account takeover. We found they could not be exploited since Y uses the HTTP only flag for its sensitive cookies.
Next we looked at the account settings, we tried to embed our payload in the user signature. That way when a new email would be sent, our script would run again, giving us continuous access. This turned out to be another dead end, our method for bypassing the Y’.s HTML filter did not fool the email signature endpoint.
While testing the endpoint responsible for saving the email signature we noticed an interesting field called “api” which contained the URL for the API used by the Y email client. We tried to modify it, and to our surprise it worked. We did it by sending the following request:
The account “api” property now pointed to a domain under our control. However, it wasn’t obvious for what it was used, as requests from the web email client were still sent to the original Y API.
It was only when we opened the Y mobile app when we discovered all requests from our account were hitting our domain. We quickly set up a proxy between our server and the original Y API, we restarted the app, and as expected we were able to intercept all communication between the app and the Y API.
Impact of Stored XSS vulnerability
The attacker could use the Stored XSS vulnerability to gain continuous access to the account by modifying the account “api” property. Once the api was updated, the Y mobile app would send all requests through the attacker’s servers giving him full control over the account.
We classified this issue as a Mass Assignment Vulnerability since this property should have not been configurable by the user. Finally, we coded an exploit utilizing the two vulnerabilities that would work in the following way:
- We send an email with our XSS payload to our target
- The target opens the email
- Our injected script sends all the user emails to our server
- Our injected script overwrites the user API endpoint
- The next time our target uses the Y mobile app, all it’s traffic would flow through our server, giving us full control over the account
We shared our findings with the Y security team who promptly fixed all the vulnerabilities in a few hours. Y has also confirmed that there was no evidence for abuse of this vulnerability as all accounts were pointing to the Y API domain.
Closing Thoughts
As researchers, it was a privilege to contribute to protecting the privacy of the Y mail user community, as we continuously do for our own Imperva customers.
Try Imperva for Free
Protect your business for 30 days on Imperva.
