Red Hat SSO 7.6 Host Header Injection Vulnerability

Disclaimer

I reported this vulnerability to Red Hat several months ago, highlighting its potential impact. Despite the security risks, they rejected my bug report. This vulnerability created a high-risk security issue for a client, who was using this service without any documented evidence of the bug. I’ve decided to share this write-up to raise awareness and help others mitigate the potential risks

Vulnerability Summary

Red Hat SSO version 7.6 is vulnerable to a Host header injection attack. This issue occurs because the application constructs URLs based on the HTTP Host header, which can be manipulated by the request sender. As a result, an attacker could tamper with the URLs in password reset requests, redirecting users to malicious websites. By doing this, the attacker can intercept password reset tokens and potentially gain control over the victim’s account.

Attack Overview
A password reset request is performed and the Host header is modified to a Burp Collaborator address.

The email received by the user contains the modified URL.

When the user accesses the link, the reset key is logged on the attacker’s web server.

The key can be used to reset the password on the victim’s account.

Source Code Review

Since RedHat SSO is open source, we can review the code to locate the vulnerability.

When we perform the password reset request, we receive a standard response from the application. We can search for this string as a starting point to locate the relevant code.

We find references to the string in several classes, but PasswordResetTest seems like a good starting point. When reviewing the code, we notice an event called SEND_RESET_PASSWORD.

We can search the code for additional references to this event. Among the results, we find another class called ResetCredentialEmail.

Within this class, we can locate the code responsible for generating the password reset URL on line 95. By reviewing this code, we learn that the application is using UriBuilder to construct the URL, which relies on the value of context.getUriInfo() and it includes the Host header of the incoming HTTP request.

We can confirm the presence of the vulnerable code by attaching a debugger to our SSO instance and pausing the execution after the reset URL is generated. This allows us to inspect the generated URL, as shown in the screenshot, where the manipulated Burp Collaborator address is clearly visible, confirming the vulnerability.

Mitigation

While the root cause of this vulnerability lies in the application code, you can reduce the risk by applying a temporary fix through the JBoss configuration. By modifying the standalone.xml configuration file, we can add a filter to validate the Host header of incoming requests.

Open standalone.xml and locate the section containing the Undertow subsystem.Add an expression-filter to check that the Host header matches either localhost:8080 or localhost. If the Host header does not match, the server will return a 403 error.<expression-filter name="host-checker" expression="not(equals(%{i,HOST}, 'localhost:8080') or equals(%{i,HOST}, 'localhost')) -> response-code(403)"/>

3. Within the <host> element, add a reference to this filter:

<host name="default-host" alias="localhost">
<location name="/" handler="welcome-content"/>
<http-invoker security-realm="ApplicationRealm"/>
<filter-ref name="host-checker"/>
</host>

With this configuration applied, any attempt to exploit the Host header injection vulnerability will be blocked, resulting in the web server returning a 403 response.

If you have any comments, suggestions, or improvements, I would greatly appreciate your feedback. Thanks for reading!