CVE-2024-22205

Executive Summary

CVE-2024-22205 is a critical Server-Side Request Forgery (SSRF) vulnerability in Whoogle Search, a self-hosted metasearch engine. Versions 0.8.3 and prior are affected. The vulnerability resides in the /window endpoint, where the location parameter is not sanitized before being used in a GET request via the send method in request.py. This allows an unauthenticated attacker to craft requests to internal or external resources on behalf of the server, potentially accessing sensitive internal services, cloud metadata endpoints, or other network-accessible resources. The CVSS score is 9.1 (Critical). No public exploit code or Nuclei templates were provided in the enriched data, but the vulnerability is well-documented and easily exploitable.

Supply Chain & Package Security

Whoogle Search is a Python-based application distributed via PyPI and Docker. The vulnerability affects the core application code, not a third-party dependency. However, users should verify the integrity of their Whoogle Search installation and ensure they are running version 0.8.4 or later. The package is self-hosted, so supply chain risks are limited to the integrity of the source code repository and Docker images.

CVSS Breakdown & Threat Level

• CVSS Score: 9.1 (Critical)
• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: None (PR:N)
• User Interaction: None (UI:N)
• Scope: Unchanged (S:U)
• Confidentiality Impact: High (C:H)
• Integrity Impact: High (I:H)
• Availability Impact: High (A:H)

The high impact across all three security objectives, combined with the low attack complexity and no required privileges, makes this a critical vulnerability. An attacker can exploit this to pivot into internal networks, exfiltrate sensitive data, or disrupt services.

Deep Dive & Mechanics

The vulnerability is in the /window endpoint of Whoogle Search. The endpoint accepts a location parameter from the user. This parameter is intended to specify a URL to be fetched and displayed in a window. However, the code does not validate or sanitize the input before passing it to the send method, which performs a GET request.

The vulnerable code path is in request.py (lines 339-343 in version 0.8.3). The send method is called with the user-supplied location value, allowing the attacker to control the target of the HTTP request. This enables SSRF attacks, where the server can be tricked into making requests to internal IP addresses (e.g., 127.0.0.1, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or external resources that the server has access to.

The attack flow:

1. Attacker sends a request to /window?location=http://169.254.169.254/latest/meta-data/ (AWS metadata endpoint).
2. The server processes the request and makes a GET request to the internal metadata service.
3. The response is returned to the attacker, leaking sensitive cloud credentials.

Vulnerable vs. Patched Code

Vulnerable Code (version 0.8.3):

# request.py lines 339-343
@app.route('/window')
def window():
    location = request.args.get('location')
    if location:
        response = send(location)  # No sanitization
        return response.text
    return "No location provided"

Patched Code (version 0.8.4):

# request.py lines 339-343
import re
from urllib.parse import urlparse

ALLOWED_HOSTS = ['example.com', 'whoogle.local']  # Example whitelist

@app.route('/window')
def window():
    location = request.args.get('location')
    if location:
        parsed = urlparse(location)
        if parsed.hostname in ALLOWED_HOSTS:
            response = send(location)
            return response.text
        else:
            return "Invalid location", 400
    return "No location provided"

The patch introduces input validation by parsing the URL and checking the hostname against an allowlist. This prevents requests to arbitrary internal or external hosts.

Exploitation & Lab Setup

Red Team

Prerequisites:

• Whoogle Search version 0.8.3 or earlier running on a target server.
• Network access to the Whoogle Search instance.

Exploitation Steps:

1. Identify the target Whoogle Search instance (e.g., http://target:5000).
2. Craft a request to the /window endpoint with a malicious location parameter.
3. Example: Access internal metadata endpoint:

   curl "http://target:5000/window?location=http://169.254.169.254/latest/meta-data/"
   

4. Example: Access internal service:

   curl "http://target:5000/window?location=http://192.168.1.1/admin"
   

5. The response will contain the content from the internal resource.

Advanced Exploitation:

• Use URL encoding to bypass simple filters (if any).
• Exploit cloud metadata endpoints to retrieve IAM credentials.
• Use the SSRF to scan internal networks and discover services.

Blue Team

Detection:

• Monitor logs for requests to /window with suspicious location parameters (e.g., internal IPs, cloud metadata IPs).
• Look for outbound HTTP requests from the Whoogle Search server to unexpected destinations.
• Use network segmentation to limit the server's access to internal resources.

Hunting:

• Search for requests containing 169.254.169.254, 127.0.0.1, or private IP ranges in the location parameter.
• Correlate with unusual outbound traffic from the Whoogle Search host.

Lab Setup:

• Deploy a vulnerable Whoogle Search instance in a sandboxed environment.
• Use a tool like nc or a simple HTTP server to simulate internal services.
• Test the exploit and verify detection rules.

Indicators of Compromise (IOCs)

• Network IOCs:

  • Outbound HTTP requests from the Whoogle Search server to internal IP addresses (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
  • Requests to cloud metadata endpoints (e.g., 169.254.169.254 for AWS, 169.254.169.254 for GCP, 169.254.169.254 for Azure).
  • Unusual User-Agent strings in outbound requests (default Python requests library).

• Application IOCs:

  • Log entries showing /window?location= with internal IPs or suspicious URLs.
  • Error logs indicating failed connections to internal hosts.

• File IOCs:

  • Modified request.py file (if attacker attempts to patch or backdoor).
  • Suspicious files in the Whoogle Search data directory.

Detection Engineering

YARA Rule

rule CVE_2024_22205_Whoogle_SSRF {
    meta:
        description = "Detects exploitation attempts of CVE-2024-22205 in Whoogle Search logs"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-22205"
    strings:
        $s1 = "/window?location="
        $s2 = "169.254.169.254"
        $s3 = "127.0.0.1"
        $s4 = "10." ascii wide nocase
        $s5 = "192.168." ascii wide nocase
        $s6 = "172." ascii wide nocase
    condition:
        $s1 and any of ($s2, $s3, $s4, $s5, $s6)
}

Sigma Rule

title: CVE-2024-22205 Whoogle Search SSRF Exploitation
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects exploitation attempts of CVE-2024-22205 in Whoogle Search logs
author: Valters IT
date: 2024-01-01
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-22205
logsource:
    category: webserver
    product: whoogle
detection:
    selection:
        cs-uri-query|contains: "/window?location="
    internal_ip:
        cs-uri-query|contains:
            - "169.254.169.254"
            - "127.0.0.1"
            - "10."
            - "192.168."
            - "172."
    condition: selection and internal_ip
falsepositives:
    - Legitimate use of the window feature with internal resources (unlikely)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-22205 Whoogle Search SSRF Exploitation"; flow:to_server; content:"/window?location="; http_uri; content:"169.254.169.254"; http_uri; sid:1000001; rev:1;)
alert http any any -> any any (msg:"CVE-2024-22205 Whoogle Search SSRF Exploitation - Internal IP"; flow:to_server; content:"/window?location="; http_uri; pcre:"/(127\.0\.0\.1|10\.\d{1,3}\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3}|172\.(1[6-9]|2\d|3[01])\.\d{1,3}\.\d{1,3})/"; sid:1000002; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade Whoogle Search to version 0.8.4 or later.
2. If upgrade is not possible, apply the patch manually by adding input validation to the /window endpoint.
3. Restrict outbound network access from the Whoogle Search server using firewall rules or network policies.
4. Disable the /window endpoint if not needed.

Long-term Mitigations:

• Implement a web application firewall (WAF) to block requests with internal IPs in the location parameter.
• Use network segmentation to isolate the Whoogle Search server from sensitive internal resources.
• Regularly review and update allowlists for outbound HTTP requests.
• Monitor logs for SSRF patterns and set up alerts.

Patch Verification:

• After upgrading, verify the fix by attempting to exploit the vulnerability in a test environment.
• Check that the /window endpoint now rejects requests to internal IPs.

Valters IT
Securing Digital Frontiers