AzuraCast Account Takeover via X-Forwarded-Host Poisoning

AzuraCast versions 0.23.5 and earlier are vulnerable to an account takeover vulnerability stemming from the unconditional trust of the X-Forwarded-Host HTTP header. An unauthenticated attacker can exploit this by injecting a malicious hostname into the password reset URL sent to a user. This is achieved by sending a crafted request to the /forgot endpoint with the X-Forwarded-Host header set to a domain controlled by the attacker. The victim, upon clicking the poisoned link in the reset email, inadvertently sends their password reset token to the attacker’s server. This allows the attacker to reset the victim’s password and disable their two-factor authentication, gaining complete control of the account. This vulnerability exists because the ApplyXForwarded middleware doesn’t validate the X-Forwarded-Host header against a trusted proxy allowlist and the application uses the request host for generating security-critical URLs.

Attack Chain

1. The attacker crafts a POST request to the /forgot endpoint with the X-Forwarded-Host header set to a malicious domain (e.g., evil.com).
2. The AzuraCast application generates a password reset email containing a poisoned URL with the attacker’s domain.
3. The victim receives the password reset email and clicks on the malicious link, sending a GET request to the attacker’s domain, inadvertently leaking the password reset token.
4. The attacker’s server captures the password reset token from the URL path.
5. The attacker uses the captured token to access the password reset page on the legitimate AzuraCast instance.
6. The attacker obtains a CSRF token from the reset page.
7. The attacker crafts a POST request to the password reset endpoint on the real AzuraCast instance, including the CSRF token and a new password.
8. The victim’s password is changed, and their 2FA is disabled, granting the attacker full account access.

Impact

Successful exploitation of this vulnerability allows for full account takeover of any user, including administrators, without prior authentication. The attack also bypasses 2FA, negating its security benefits. If an administrator account is compromised, the attacker gains full control of the AzuraCast instance, including all stations, media, and system settings. The attack requires the victim to click a link in a legitimate-looking password reset email, increasing the likelihood of success. This can lead to unauthorized access to sensitive data, disruption of service, and reputational damage.

Recommendation

• Implement a trusted proxy allowlist in backend/src/Middleware/ApplyXForwarded.php to validate the X-Forwarded-Host header, as described in the provided fix, to prevent hostname injection (Fix 1).
• Modify ForgotPasswordAction.php to generate the reset URL using the configured base_url setting rather than the request-derived URL to ensure the correct domain is used in the reset email (Fix 2).
• Deploy the following Sigma rule to detect suspicious requests to the /forgot endpoint with a non-standard X-Forwarded-Host header to identify potential exploitation attempts.
• Remove the line $user->two_factor_secret = null; from LoginTokenAction.php:75 to prevent 2FA from being disabled during password reset, requiring a separate, explicit flow for 2FA recovery (Fix 3).