Send emails on behalf of a company? Here’s how I found this vulnerability in several large companies allowing me to easily earn bounties.

Hello hunters. The goal here is to be able to send email(s) on behalf of a company — from its email address — with the ability to change/customize the content and therefore the HTML template.

The impact of this vulnerability can be significant, an attacker would take advantage of the trust users have in the platform in order to redirect them to fraudulent sites (phishing, etc.) or even push them to perform undesirable actions from their accounts. Programs generally consider the severity of this vulnerability between low and medium.

HTML injection is a vulnerability where an application accepts user input and then embeds the input into HTML. An attacker can inject HTML from user input so that their malicious code is embedded into the overall template generated by the application.

This is due to inadequate sanitization of user input. It’s very easy to fix but very often goes under the radar — this attack vector in particular — to the delight of bug hunters.

The famous golden rule for developers: Never trust user input

The first thing to do in order to identify this vulnerability is to find a feature on the application that sends emails : most applications have a “Contact us” section, or a “Help” section to send requests to the company’s teams. These features are the most basic, and the list is not exhaustive, different functionalities sending mails can be found depending on the nature of the application.

Once these functionalities have been found, they must be tested and checked for the presence of several criteria :

We will take the example of a form allowing to send a request (request for help) to the technical staff of the company

[1] When submitting the form, do I receive an email (to the email address indicated in the form or to the email address linked to the account from which the request was sent) ?

If not — make sure because this can take some time — then you don’t have to look any further. Before hoping to inject code into a template, the template in question must still exist.

[2] If I get an email when submitting the form, is it possible to specify any email address in the form/query?

To exploit the vulnerability it is necessary to be able to target other people so either the form in question allows me to specify the email of my choice, or it is necessary to be connected to submit the form and therefore the email will be automatically sent to the email address binds to the connected account :

In which case intercept the request in your preferred proxy, and check that your email address is not in the HTTP request (POST in principle), and try to change it to the email address of your choice.

[3] Are some of the information provided in the form reflected in the email received?

If this is not the case, check if some of your personal information — in the event that you are connected to your account — is reflected in the email such as username, surname or first name for example.

In this case modify the information(s) reflected and try to enter your payload there. Even if the information in question is not interpreted on the application, it may be interpreted in the email, this is called a second order injection, the injection is not directly carried out at from the user inputs of the form, but from information recorded elsewhere, on the account for example.

If not, we can’t try to inject code, or even bypass any filter.

[4] The last step is to try to inject HTML code that will be interpreted by the template in question

As mentioned earlier, this kind of vulnerability often goes under the radar, and some applications have neither front-end nor back-end side filters and a simple payload including HTML code is enough :

vul<strong>ne</strong>rable

Personally, I often perform my tests with a simple strong tag. If the word “vulnerable” reflected in the email has “ne” (part of the word between the tags) in bold then I’ve found something interesting.
I would point out though that injecting a simple strong tag will not be enough to obtain a bounty, so for the impact to be real make sure that “dangerous” tags such as <a> (link), <img> etc.. are not blocked.

Sometimes developers have focused on front-end filters, which makes it impossible to submit forms containing special characters : don’t stop there, submit the form with random values, intercept the request in your proxy and then input your payloads directly from the proxy. This will blow up all the protections of the front, which are sometimes the last bastion towards the bounty.

If protections also exist on the back side, don’t give up in the first few minutes, try to bypass the filters, the methodology here is the same as for XSS vulnerabilities.

Having trouble bypassing a filter for a particular character? Take a look at : https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md

This was my first write-up, thanks for reading. If you have any questions feel free to let me know.

My Twitter account : https://twitter.com/blank_cold