CVE-2024-22203: Whoogle Search SSRF Vulnerability

CVE-2024-22203 Overview

CVE-2024-22203 is a Server-Side Request Forgery (SSRF) vulnerability in Whoogle Search, a self-hosted metasearch engine. In versions prior to 0.8.4, the element method in app/routes.py fails to validate user-controlled src_type and element_url variables before passing them to the send method in request.py. This allows attackers to craft arbitrary GET requests to both internal and external resources on behalf of the server.

Critical Impact

This SSRF vulnerability enables attackers to access internal network resources that the server can reach, potentially exposing sensitive internal services, cloud metadata endpoints, and other protected resources that are not directly accessible from the internet.

Affected Products

• Benbusby Whoogle Search versions prior to 0.8.4
• Self-hosted Whoogle Search instances running vulnerable versions
• Docker deployments of Whoogle Search using pre-0.8.4 images

Discovery Timeline

• 2024-01-23 - CVE-2024-22203 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2024-22203

Vulnerability Analysis

This Server-Side Request Forgery vulnerability exists because the application accepts user-supplied input for URL parameters without proper validation or sanitization. The element method in the routing module directly processes the src_type and element_url parameters from incoming requests. These values are then used to construct and execute HTTP GET requests through the send method in the request handling module.

The vulnerability is classified under CWE-918 (Server-Side Request Forgery). The attack can be executed remotely over the network without requiring any authentication or user interaction. Successful exploitation could lead to complete compromise of confidentiality, integrity, and availability of internal resources accessible by the Whoogle server.

Root Cause

The root cause of this vulnerability is insufficient input validation in the element method within app/routes.py. The application fails to implement proper URL validation, allowlisting, or blocklisting mechanisms to restrict the destinations of outgoing requests. When user-controlled data is passed directly to the send method on lines 339-343 in request.py, the server blindly executes requests to arbitrary URLs specified by the attacker.

Attack Vector

An attacker can exploit this vulnerability by sending crafted HTTP requests to a vulnerable Whoogle Search instance with malicious src_type and element_url parameter values. The attack vector operates as follows:

1. The attacker identifies a vulnerable Whoogle Search instance accessible over the network
2. The attacker crafts a request containing a malicious URL pointing to an internal resource (e.g., cloud metadata endpoints like http://169.254.169.254/, internal admin panels, or other protected services)
3. The Whoogle server processes the request and makes an outbound HTTP GET request to the attacker-specified URL
4. The response from the internal resource is potentially returned to the attacker, disclosing sensitive information

The vulnerability allows attackers to scan internal networks, access cloud provider metadata services, interact with internal APIs, and potentially pivot to other attacks against the internal infrastructure. For detailed technical information, see the GitHub Security Advisory for the complete analysis.

Detection Methods for CVE-2024-22203

Indicators of Compromise

• Unusual outbound HTTP requests from the Whoogle server to internal IP ranges (10.x.x.x, 172.16.x.x, 192.168.x.x)
• Requests to cloud metadata endpoints such as 169.254.169.254 originating from the application
• Anomalous access patterns to the /element endpoint with suspicious URL parameters
• Server logs showing requests to internal services or localhost addresses

Detection Strategies

• Implement network monitoring to detect outbound connections from the Whoogle server to internal network ranges or cloud metadata IPs
• Deploy web application firewall (WAF) rules to identify and block requests containing internal IP addresses or localhost references in URL parameters
• Monitor application logs for the element endpoint with unusual element_url parameter values
• Use SentinelOne Singularity to detect abnormal network behavior patterns indicative of SSRF exploitation

Monitoring Recommendations

• Enable verbose logging for all HTTP requests handled by the Whoogle application
• Configure alerts for outbound connections to RFC 1918 private address ranges from the application server
• Implement egress filtering and monitor for policy violations from the Whoogle server
• Regularly audit network traffic patterns from self-hosted applications to detect potential SSRF activity

How to Mitigate CVE-2024-22203

Immediate Actions Required

• Upgrade Whoogle Search to version 0.8.4 or later immediately
• If immediate upgrade is not possible, restrict network access to the vulnerable instance
• Implement network segmentation to limit the server's access to internal resources
• Review logs for any signs of prior exploitation attempts

Patch Information

The vulnerability has been fixed in Whoogle Search version 0.8.4. The patch introduces proper input validation for the src_type and element_url parameters to prevent arbitrary URL requests. The fix is available in commit 3a2e0b262e4a076a20416b45e6b6f23fd265aeda. Organizations should update their Whoogle Search installations by pulling the latest version from the official repository or updating their Docker images to use the patched release.

Workarounds

• Implement network-level controls to block outbound requests from the Whoogle server to internal IP ranges and cloud metadata endpoints
• Deploy a reverse proxy with URL filtering capabilities to inspect and block malicious requests before they reach the application
• Restrict the Whoogle server's network access using firewall rules to only allow necessary external communications
• Consider running Whoogle in an isolated network segment with no access to sensitive internal resources

# Example iptables rules to block SSRF to internal networks
iptables -A OUTPUT -m owner --uid-owner whoogle -d 10.0.0.0/8 -j DROP
iptables -A OUTPUT -m owner --uid-owner whoogle -d 172.16.0.0/12 -j DROP
iptables -A OUTPUT -m owner --uid-owner whoogle -d 192.168.0.0/16 -j DROP
iptables -A OUTPUT -m owner --uid-owner whoogle -d 169.254.169.254 -j DROP