Host Header Poisoning in IBM Websphere

CVE-2017–1398

John M
2 min readMar 1, 2019

During my first couple of months as a Pentester, I was tasked with a simple web application assessment of a Websphere Commerce site.

One of the things I try to do on every assessment is run through a basic web app checklist to ensure that I’ve followed each bit of my methodology, one such test is to look at issues related to the host header which resulted in finding CVE-2017–1398.

This effectively allowed a malicious actor to rewrite the host header that was then pulled into HTML and other areas. Whilst my client wasn’t vulnerable to password reset email poisoning (as they didn’t include a reset link in their email, a whole different issue), I have theorised that this was possible using this CVE and found the below real world WebSphere Commerce site that demonstrates it.

NOTE: This CVE has been resolved across most instances, and the below was the only public website I could find prepared to give me permission to test the theory. They use custom URL structures so I’ve had to redact more than I would like to maintain their privacy. Also due to the use of custom URL structures it’s not clear if custom coding has effected the outcome of my test. If you find a real world example using the default IBM URL structures please drop me a message on twitter.

Proof of Concept

The attack is fairly simple, find a customers email address (and any other information needed to generate a password reset request), then when creating a password reset request, capture it using Burp Suite and rewrite the host header to a domain your control.

An example request, the highlighted host header has been swapped out for attackerswebsite.com
The redacted password reset email, important to note that email templates change according to the brand and may even obscure the domain behind a link

End Result

The end result is that an attacker would be able to use this vulnerability to trick users into passing their password reset tokens to a malicious website under the attackers control.

Timeline

  • March 2017: Issue discovered and reported to IBM
  • July 2017: IBM validate issue and release a fix
  • February 2019: This blog post detailing vulnerability published

--

--