<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Nginx — CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/vendors/nginx/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata — refreshed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Wed, 03 Jan 2024 12:00:00 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/vendors/nginx/feed.xml" rel="self" type="application/rss+xml"/><item><title>AzuraCast Account Takeover via X-Forwarded-Host Poisoning</title><link>https://feed.craftedsignal.io/briefs/2024-01-azuracast-account-takeover/</link><pubDate>Wed, 03 Jan 2024 12:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-azuracast-account-takeover/</guid><description>AzuraCast is vulnerable to password reset poisoning due to unconditionally trusting the X-Forwarded-Host header, allowing an attacker to inject a malicious host into the password reset URL, exfiltrate the reset token, reset the victim's password, and disable 2FA, leading to account takeover.</description><content:encoded><![CDATA[<p>AzuraCast versions 0.23.5 and earlier are vulnerable to an account takeover vulnerability stemming from the unconditional trust of the <code>X-Forwarded-Host</code> 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 <code>/forgot</code> endpoint with the <code>X-Forwarded-Host</code> 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&rsquo;s server. This allows the attacker to reset the victim&rsquo;s password and disable their two-factor authentication, gaining complete control of the account. This vulnerability exists because the <code>ApplyXForwarded</code> middleware doesn&rsquo;t validate the <code>X-Forwarded-Host</code> header against a trusted proxy allowlist and the application uses the request host for generating security-critical URLs.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>The attacker crafts a POST request to the <code>/forgot</code> endpoint with the <code>X-Forwarded-Host</code> header set to a malicious domain (e.g., <code>evil.com</code>).</li>
<li>The AzuraCast application generates a password reset email containing a poisoned URL with the attacker&rsquo;s domain.</li>
<li>The victim receives the password reset email and clicks on the malicious link, sending a GET request to the attacker&rsquo;s domain, inadvertently leaking the password reset token.</li>
<li>The attacker&rsquo;s server captures the password reset token from the URL path.</li>
<li>The attacker uses the captured token to access the password reset page on the legitimate AzuraCast instance.</li>
<li>The attacker obtains a CSRF token from the reset page.</li>
<li>The attacker crafts a POST request to the password reset endpoint on the real AzuraCast instance, including the CSRF token and a new password.</li>
<li>The victim&rsquo;s password is changed, and their 2FA is disabled, granting the attacker full account access.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>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.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Implement a trusted proxy allowlist in <code>backend/src/Middleware/ApplyXForwarded.php</code> to validate the <code>X-Forwarded-Host</code> header, as described in the provided fix, to prevent hostname injection (Fix 1).</li>
<li>Modify <code>ForgotPasswordAction.php</code> to generate the reset URL using the configured <code>base_url</code> setting rather than the request-derived URL to ensure the correct domain is used in the reset email (Fix 2).</li>
<li>Deploy the following Sigma rule to detect suspicious requests to the <code>/forgot</code> endpoint with a non-standard <code>X-Forwarded-Host</code> header to identify potential exploitation attempts.</li>
<li>Remove the line <code>$user-&gt;two_factor_secret = null;</code> from <code>LoginTokenAction.php:75</code> to prevent 2FA from being disabled during password reset, requiring a separate, explicit flow for 2FA recovery (Fix 3).</li>
</ul>
]]></content:encoded><category domain="severity">medium</category><category domain="type">advisory</category><category>account takeover</category><category>x-forwarded-host</category><category>password reset poisoning</category></item></channel></rss>