How I was able to take over any users account with host header injection Ajay Gautam Follow Jan 23 · 4 min read

This article is about a vulnerability I was able to find in the BugCrowd private program.

At around midnight I got an alert message that said that I had been invited to pentest a new private program. Taking in regard the scope and reward range of the web application, I thought I would give it a try. However, it was midnight and I did not come across any vulnerabilities and it was quite late so I decided to go to sleep.

The next day was like every other with running important errands but I had some free time before office, so I decided to have a look and do some research about that new private program as of the night before.

Since I was already familiar with the web application working methodology, I tested for IDOR’s but I did not have much luck with it at that time. Also, if I had found any IDOR then the severity category would not have gotten any high severity vulnerability in a way because they were using MongoDB default encrypted ID which is hard to decrypt. However, I thought there might be some loopholes where they might have leaked their userId.

As I moved on, I found few stored XSS but I was very sure that I would get response of duplicate of those vulnerabilities but still, I reported these vulnerabilities and as I had thought got the response of them as duplicate.

Moving further in pentest I got a vulnerability where I was able to steal other user’s passwords reset token or email verification token via Host-Header Injection.

What is Host-Header Injection?

Host-Header Injection is a vulnerability where a remote attacker can exploit a HTTP Host header sent by sending a fake host instead of original.

According to Tenable “When creating URI for links in web applications, developers often resort to the HTTP Host header available in HTTP request sent by client-side. A remote attacker can exploit this by sending a fake header with a domain name under his control allowing him to poison web-cache or password reset emails for example.”

There appeared a form that helps in resetting passwords. The form looked like this:

When the URL is typed then it sends a password reset token to the email that has been entered.

Email Verification Token

The Email Verification Token looks like as shown.

I have made this system personalized in my own local machine for providing this article. We can have a deep look into the URL, the URL is Http://192.168.1.70/?token={token}.

So, when the HOST name is changed from the password reset, there appears a request like this.

Since we have changed the host to redacted.com from 192.168.1.70, there we might observe changes in our password reset token URL.

As stated above, the reset password URL changed and the URL looks like as shown.

redacted.com/?token={token} from 192.168.1.70/?token={token}

Here the host can be manipulated. So, if we add our own malicious host in request and send it then we can capture the password reset token. In order for this attack to be successful, the victim needs to click the password reset link sent to his/her inbox.

When the victim clicks the link then the attacker will get the password reset token of the victim’s, since the victim is clicking the malicious server link instead of the original one.

Token Leakage

As it can be seen here, the token has been leaked as soon as the victim clicks the link.

I successfully submitted this vulnerability with full proof of concept and finally this bug earned me 900$ in the Bugcrowd private program.

Editor’s Note — We are publishing write-ups related to cyber security every week. We are looking to grow our community. If you are interested in writing about cyber security, please email at blog@nassec.io or DM at twitter.com/nassecio.