AVideo SSRF Vulnerability via HTTP Redirect and DNS Rebinding
AVideo is vulnerable to Server-Side Request Forgery (SSRF) due to improper validation of user-supplied URLs that does not prevent HTTP redirects, and DNS rebinding due to discarded resolved IP addresses.
AVideo, version 29.0 and earlier, contains a Server-Side Request Forgery (SSRF) vulnerability due to insufficient validation of user-supplied URLs. Specifically, the isSSRFSafeURL() function, intended to prevent SSRF attacks, fails to account for HTTP redirects. This allows an attacker to bypass the intended security checks by providing a URL that initially appears safe but redirects to an internal resource, such as cloud metadata endpoints (169.254.169.254). Additionally, multiple callers of isSSRFSafeURL() discard the $resolvedIP parameter, creating a Time-of-Check Time-of-Use (TOCTOU) race condition exploitable via DNS rebinding. Attackers can manipulate DNS resolution to access internal services (127.0.0.1) that would otherwise be protected. Successful exploitation can lead to the disclosure of sensitive information, such as IAM credentials and internal service details.
Attack Chain
- Attacker crafts a malicious URL pointing to a server they control.
- The attacker’s server responds with a 302 redirect to an internal resource (e.g.,
http://169.254.169.254/latest/meta-data/). - The attacker submits the initial malicious URL to a vulnerable AVideo endpoint (e.g.,
/plugin/AI/receiveAsync.json.php). - The
isSSRFSafeURL()function validates the initial URL, which resolves to a public IP address, and incorrectly passes the check. - The
file_get_contents()function, without proper redirect restrictions, follows the 302 redirect to the internal resource. - The request is made to the internal resource, bypassing the intended SSRF protections.
- The internal resource (e.g., cloud metadata) responds with sensitive information.
- The sensitive information (e.g., IAM credentials) is stored as a video thumbnail or image within the application, accessible to the attacker.
Impact
Successful exploitation of this SSRF vulnerability allows an authenticated attacker to force the AVideo server to make HTTP requests to arbitrary internal hosts. This includes cloud metadata endpoints (e.g., 169.254.169.254), potentially leading to the exfiltration of IAM credentials and instance identity information. Attackers can also access internal services on localhost (127.0.0.1) or the private network, such as databases, admin panels, and monitoring systems. The exfiltrated data can be retrieved through the application’s public interface, increasing the severity of the impact.
Recommendation
- Apply the suggested fix by routing affected files through
url_get_contents()to safely handle redirects, as detailed in the advisory. - As an alternative to using
url_get_contents(), implement an explicit no-redirect context when callingfile_get_contents()to prevent automatic redirect following. - Update all callers of
isSSRFSafeURL()to capture the$resolvedIPparameter and pass it to a DNS-pinning-aware fetch function usingCURLOPT_RESOLVEto mitigate DNS rebinding attacks. - Monitor web server logs for requests containing internal IP addresses (169.254.169.254, 127.0.0.1) in the URL, as these may indicate SSRF attempts.
- Deploy the Sigma rules in this brief to your SIEM and tune for your environment.
Detection coverage 2
Detect AVideo SSRF Attempt via Internal IP in Request URI
highDetects potential SSRF attempts in AVideo by monitoring web server logs for requests containing internal IP addresses in the URI.
Detect AVideo SSRF Attempt via Redirect to Internal IP
highDetects potential SSRF attempts in AVideo by monitoring web server logs for 302 redirects to internal IP addresses.
Detection queries are kept inside the platform. Get full rules →
Indicators of compromise
1
domain
1
ip
| Type | Value |
|---|---|
| ip | 169.254.169.254 |
| domain | rebind.attacker.com |