Introduction
Silverstripe is a popular open-source CMS for creating and maintaining websites. During a client engagement, Jason Xie identified a Host header injection vulnerability leading to account takeover. The issue was reported to Silverstripe and was marked as web server a configuration issue. The vulnerability was identified during subsequent client engagements, so Will Frame decided to further investigate this issue, the mitigating factors, and how many servers on the internet were misconfigured.
The Vulnerability
In common Silverstripe configurations, user-supplied Host headers are used to construct URLs throughout the application. For example, the Host header may be used to generate links or buttons on a webpage.
One critical instance of this behaviour occurs in the password reset functionality. In November 2021, Jason Xie observed that when a user requested a password reset, the application used the value of the Host header to generate the reset link. An attacker could exploit this by crafting a password reset request for a victim, modifying the Host header to point to a server they control. If the victim clicks the link sent in the email, the password reset token is sent to the attacker’s server. This allows the attacker to capture the token, reset the victim’s password, and compromise their account. Recently, in October 2024, Will Frame observed that the impact was amplified if the victim used Microsoft email services. Microsoft SafeLinks, a feature that scans email URLs for malicious content, automatically visits links to verify their safety. When a password reset email containing the crafted link is received, if enabled, Microsoft SafeLinks follows the link to evaluate it. This triggers an automated request to the attacker’s server, which includes the full password reset link including the password reset token in the Referrer header. This behaviour inadvertently assists the attacker by leaking the password reset token without requiring any action from the victim.
The full attack path can be summarised in the following diagram:
It should be noted that to carry out this attack, a valid email address for the target Silverstripe account must be known. Time-based enumeration could assist in the discovery of accounts.
In some cases, an X-Forwarded-For header with the user-controlled domain was required.
Further Investigation
Will Frame further investigated the impact by checking Silverstripe sites identified on the web to see whether requests to the front page with arbitrary Host headers were rejected, and whether the “Lost Password” page was accessible without authentication. Of 2,511 sites checked, 1,305 accepted arbitrary Host headers and had the lost password page accessible without authentication, meaning the majority of the Silverstripe sites were vulnerable. Of these 1,305 vulnerable sites, 207 used Microsoft as their email hosting provider, which means that the password reset token could be retrieved without any user interaction (because SafeLinks auto-checks it). It should be noted that certain MX records, which are not directly linked to Outlook, appeared to route emails through Microsoft Outlook, where they are subsequently processed by SafeLinks. These sites are not included in the numbers above.
How To Fix It
Silverstripe recommends adding to the list of allowed hosts in the .env file, to ensure arbitrary Host headers cannot be used with the Silverstripe instance. More detail can be found here.
Additionally, MFA should be implemented for all administrator accounts, along with proper rate-limiting to prevent the brute-forcing of a one-time passcode or enumerating a user account through time-based enumeration.
Vulnerability Disclosure Timeline
- 21/10/2021 Issue first reported to Silverstripe
- 22/10/2021 Further code analysis reported to Silverstripe
- 26/10/2021 CVE-2021-43031 created
- 18/11/2021 SilverStripe final decision: “We’ve decided that we’ll treat this as a security enhancement in the open instead of as a regular security issue. This is because it relies on a server to not be following standard security practices for it to be exploitable”
- 01/10/2024 Zero-click SafeLinks issue identified
- 14/11/2024 Further research began after identifying the issue in multiple client engagements
- 16/11/2024 2,511 sites checked with 1,305 accepting arbitrary Host headers, further research continued
- 03/12/2024 Reported to CERT/NCSC, including a list of vulnerable New Zealand sites
- 21/01/2025 Advisory released with approval from CERT