CVE-2021-29431

Executive Summary

CVE-2021-29431 is a Server-Side Request Forgery (SSRF) vulnerability in Sydent, the reference Matrix identity server developed by the Matrix.org project. An unauthenticated attacker can induce Sydent to issue HTTP GET requests to arbitrary internal systems due to missing parameter validation and absence of IP address blacklisting. The vulnerability enables internal network reconnaissance and port scanning but does not permit data exfiltration or request header manipulation. This issue has been addressed in upstream commits, and a firewall-based workaround was provided by the vendor.

Technical Analysis

Sydent is the reference implementation of a Matrix identity server, responsible for managing third-party identifiers (email addresses and phone numbers) linked to Matrix user accounts. As part of its normal operation, Sydent performs outbound HTTP requests to verify identity data and interact with external services.

The vulnerability class is Server-Side Request Forgery (SSRF) caused by missing hostname validation. The NVD description indicates that Sydent lacks two critical security controls:

1. Parameter validation — the server does not adequately validate user-supplied input that influences the target of outbound HTTP GET requests.
2. IP address blacklisting — Sydent does not maintain a deny-list for private, loopback, link-local, or reserved IP address ranges (e.g., 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16, ::1, fc00::/7).

Because of these shortcomings, an attacker who can reach the Sydent service (typically exposed on public infrastructure to handle identity lookups) can craft requests that cause Sydent's server-side logic to issue HTTP GET requests to attacker-specified internal hosts.

The NVD description specifies several operational constraints on the attack:

• Only HTTP GET requests can be triggered — other HTTP methods are not available to the attacker.
• No data exfiltration is possible — the attacker cannot read response bodies or otherwise retrieve data from the target internal systems.
• No request header control — the attacker cannot set custom headers on the outbound request (e.g., cannot forge Host headers or add authentication tokens).
• The primary practical impact is internal port enumeration — the attacker can determine which internal hosts are alive and which TCP ports have services listening.

The attack surface is the publicly accessible Sydent HTTP API. The NVD description does not specify the exact endpoint or parameter that is vulnerable; insufficient technical detail is available regarding the specific request parameter that controls the target URL. However, the vulnerability class is well-understood: a user-controlled URL or hostname field is passed to a server-side HTTP client without validation.

The patch commits (9e57334, 8936925, 3d531ed, 0f00412) presumably introduce hostname validation and an IP blacklist. It is worth noting that the patch confidence is rated 2/4 (CLAIMED) because a single source (the CNA) claims the fix exists, but no independent confirmation has been obtained.

Exploitation Scenarios

No public PoC or exploit code is known for this vulnerability at the time of writing. The following attack chain is inferred from the vulnerability class and the constraints described in the NVD entry.

Step 1: Reconnaissance and Target Identification

An attacker first identifies publicly accessible Sydent instances. Sydent typically listens on TCP port 8090 by default, though this is not confirmed in the NVD description. Attackers may use internet-wide scanning (e.g., Shodan, Censys) to discover Matrix identity servers. The server banner or HTTP response headers may identify the service as Sydent.

Step 2: Triggering the SSRF Flaw

The attacker crafts a request to the Sydent HTTP API, supplying a target URL or hostname that points to an internal resource. Because Sydent lacks IP address blacklisting, the attacker can specify:

• 127.0.0.1 or localhost to target services on the Sydent host itself
• RFC 1918 private addresses (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) to reach internal network services
• Link-local addresses (e.g., 169.254.0.0/16) for cloud metadata services such as AWS EC2 instance metadata (though response content cannot be read, connection timing/behavior may leak information)

Step 3: Payload/Execution Method

The attack is performed at the vulnerability-class level. The attacker submits a POST or GET request (depending on the API design) to the vulnerable endpoint, supplying a URL parameter such as target=<internal-ip>:<port>. Sydent's server-side HTTP client then issues a GET request to that address. The attacker observes the resulting behavior (response timing, error messages, difference in response codes) to infer whether the port is open or closed.

Step 4: Post-Exploitation Impact

The attacker performs internal port enumeration:

• Determines which hosts on the internal network are reachable from the Sydent server
• Discovers open TCP ports on those hosts
• Maps the internal network topology (DMZ, internal segments, database hosts, admin panels, etc.)

Because the attacker cannot read response bodies or control headers, the SSRF is limited to a network/port scanner. The information gathered can be used for subsequent targeted attacks — for example, identifying a database port (3306, 5432) or admin panel (8080, 8443) that can then be attacked through other means (if the attacker has or can gain another foothold on the network).

Impact Assessment

CVSS Score: 7.7 (High). The vector indicates: Network attack vector (AV:N), Low attack complexity (AC:L), No privileges required (PR:N), No user interaction required (UI:N), Unchanged scope (S:U), High confidentiality impact (C:H), No integrity impact (I:N), No availability impact (A:N).

The high confidentiality score reflects the information disclosure potential — internal network reconnaissance reveals sensitive topological information. However, the actual data leak is limited because response bodies are not retrievable.

Business Impact:

• Internal Network Mapping: An attacker gains visibility into internal network segments, host existence, and open services — information that is normally not accessible from the outside.
• Precursor to Further Attacks: The port enumeration data can be used to target specific internal services in follow-up attacks.
• Compliance Risks: SSRF vulnerabilities that expose internal infrastructure may violate compliance frameworks (PCI-DSS, SOC2, etc.) that require strict network segmentation and access controls.

Affected Systems:

• All deployments of Sydent prior to the patched commits are potentially vulnerable.
• The Matrix Foundation's own Sydent instances were likely affected, as were any third-party Matrix identity servers run by enterprises or community members.
• Self-hosted Matrix deployments that use Sydent for identity verification are at risk.

Blast Radius:

The blast radius is limited to internal infrastructure reachable from the Sydent host. In a well-segmented network, the impact is confined to the server's local network segment. In a flat network, the attacker can probe the entire corporate internal range.

Detection Guidance

The following detection rules focus on identifying anomalous outbound HTTP requests from Sydent servers to internal IP addresses, which would indicate SSRF exploitation. These rules should be adapted to your environment's logging capabilities.

Sigma Rule

title: Sydent SSRF - Outbound HTTP Request to Internal IP
id: 5f3a2b8c-9d4e-4f7a-8b2c-1a2b3c4d5e6f
status: experimental
description: Detects Sydent sending HTTP requests to internal IP addresses, indicating potential SSRF exploitation (CVE-2021-29431)
author: Valtersit Security Team
date: 2024/01/15
tags:
    - attack.t1190
    - attack.lateral-movement
logsource:
    category: webserver
    product: sydent
detection:
    selection:
        cs-method: GET
        c-uri|contains:
            - 'http://'
            - 'https://'
    filter_internal_legit:
        c-uri|contains:
            - 'matrix.org'
            - 'vector.im'
            - 'example.com'
    filter_private_ip:
        c-uri|contains:
            - '127.0.0.1'
            - '10.'
            - '192.168.'
            - '172.16.'
            - '172.17.'
            - '172.18.'
            - '172.19.'
            - '172.2'
            - '169.254.'
    condition: selection and not filter_internal_legit and filter_private_ip
level: high
falsepositives:
    - Legitimate monitoring of internal health check endpoints
    - Misconfigured Sydent instances pointing to internal services

YARA Rule

rule Sydent_SSRF_CVE_2021_29431
{
    meta:
        author = "Valtersit Security Team"
        description = "Detects known SSRF exploitation patterns against Sydent (CVE-2021-29431)"
        date = "2024-01-15"
        reference = "CVE-2021-29431"
        score = 70
    strings:
        $s1 = "sydent" ascii nocase
        $s2 = "http://" ascii
        $s3 = "https://" ascii
        $ip_loopback = "127.0.0.1" ascii
        $ip_local1 = "10." ascii
        $ip_local2 = "192.168." ascii
        $ip_local3 = "172.16." ascii
        $ip_local4 = "172.17." ascii
        $ip_local5 = "172.18." ascii
        $ip_local6 = "172.19." ascii
        $ip_local7 = "169.254." ascii
    condition:
        uint16(0) == 0x5A4D and  // MZ header (PE file)
        $s1 and $s2 and
        (
            $ip_loopback or $ip_local1 or $ip_local2 or
            $ip_local3 or $ip_local4 or $ip_local5 or
            $ip_local6 or $ip_local7
        )
}

Suricata IDS Rule

alert http any any -> any any (msg:"Sydent SSRF Attempt - Outbound HTTP to Private IP (CVE-2021-29431)"; flow:to_server,established; http.method; content:"GET"; http.uri; content:"http://"; http.uri; pcre:"/(?:127\.0\.0\.1|10\.\d{1,3}\.\d{1,3}\.\d{1,3}|172\.(?:1[6-9]|2[0-9]|3[01])\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3}|169\.254\.\d{1,3}\.\d{1,3})/i"; sid:2021004; rev:1; metadata:created_at 2024_01_15, updated_at 2024_01_15, cve 2021_29431;)

Elastic Detection

sequence by host.name, process.name with maxspan=30s
  [network where process.name == "sydent" and network.direction == "egress" and
   source.ip == "10.0.0.0/8" or source.ip == "172.16.0.0/12" or source.ip == "192.168.0.0/16" or source.ip == "127.0.0.1"]

Splunk SPL Query

index=proxy OR index=webserver OR index=network
| search process_name="sydent" OR src="*" method="GET"
| rex field=uri "http://(?<target_host>[^/:]+)"
| eval is_private=case(
    match(target_host, "^(127\.|10\.|192\.168\.)"), 1,
    match(target_host, "^172\.(1[6-9]|2[0-9]|3[01])\."), 1,
    match(target_host, "^169\.254\."), 1,
    match(target_host, "^::1$"), 1,
    match(target_host, "^fc"), 1,
    1=1, 0)
| where is_private=1
| stats count min(_time) max(_time) by src_ip, dest_ip, target_host, uri
| rename src_ip as "Sydent Server IP", target_host as "Internal Target", uri as "Full URL"
| sort - count

Wazuh OSSEC Rule

<group name="sydent,ssrf,">
  <rule id="100301" level="12">
    <decoded_as>json</decoded_as>
    <field name="process">sydent</field>
    <regex>(127\.0\.0\.1|10\.\d{1,3}\.\d{1,3}\.\d{1,3}|172\.(1[6-9]|2[0-9]|3[01])\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3}|169\.254\.\d{1,3}\.\d{1,3})</regex>
    <description>Sydent Sending HTTP Requests to Internal IP - Possible SSRF (CVE-2021-29431)</description>
    <group>ssrf,sydent,attack.t1190,</group>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 2/4 — CLAIMED (single source — CNA — claims patch exists in upstream commits; not independently confirmed)

1. Immediate Mitigations (before patching):

• Firewall egress filtering: As recommended by the vendor, deploy a firewall rule that prevents the Sydent host from reaching internal HTTP resources (private IP ranges, loopback addresses, link-local addresses). Block all outbound connections from the Sydent process to RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), loopback (127.0.0.0/8), link-local (169.254.0.0/16), and IPv6 equivalents.
• Restrict network access to Sydent: If possible, place Sydent behind a reverse proxy or ingress controller and restrict which network segments can reach the Sydent HTTP API.
• Monitor outbound traffic: Enable logging of all outbound HTTP requests from the Sydent host and review for anomalies (requests to internal addresses).

2. Patch/Upgrade Steps:

• Upgrade to the latest version of Sydent that includes fix commits 9e57334, 8936925, 3d531ed, or 0f00412.
• If using a packaged distribution (Docker, Debian package), check for an updated release that incorporates these commits.
• Verify the patch is applied correctly by testing that requests to private IP addresses are rejected and that IP blacklist entries are active.
• Note the patch confidence is moderate (2/4) — independently verify the fix works in your deployment by attempting to trigger the SSRF against a patched instance.

3. Long-Term Hardening:

• Network segmentation: Ensure Sydent runs in a DMZ with strict egress controls, isolated from core production networks.
• Defense in depth: Apply the principle of least privilege — the Sydent process should only be able to access the specific external services it needs (Matrix identity lookups, email/SMS verification providers).
• Input validation: Enforce strict allow-listing of domains/IPs the Sydent can contact, if the application supports a configured allow-list after patching.
• Regular vulnerability scanning: Include Sydent in your vulnerability management program — track updates from the Matrix.org security advisories.
• Monitor vendor advisories: Subscribe to the Matrix security mailing list for notifications about further vulnerabilities in Sydent or related components.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2021-29431 — Official NIST vulnerability database entry.
2. GitHub Advisory: https://github.com/matrix-org/sydent/security/advisories — Matrix.org security advisories for Sydent (likely contains the security advisory for this CVE).
3. Patch Commits: Referenced in NVD description — commits 9e57334, 8936925, 3d531ed, 0f00412 in the matrix-org/sydent repository on GitHub.
4. CWE-918 — Server-Side Request Forgery (SSRF): https://cwe.mitre.org/data/definitions/918.html — MITRE weakness description for the vulnerability class.
5. Matrix.org Security Disclosure Policy: https://matrix.org/security-disclosure-policy/ — Vendor's security response process.

Threat Actor Campaigns / Exploit-in-the-Wild Evidence:

No active exploitation in the wild has been reported for CVE-2021-29431 as of the writing of this report. The CVE is not listed on the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score of 0.01194 (65.1st percentile) suggests a moderate-to-low likelihood of exploitation in the near term, but the vulnerability remains a viable target for attackers probing exposed Matrix infrastructure. Monitoring for suspicious outbound traffic from Sydent instances is still recommended given the active attacker interest in SSRF vulnerabilities in identity and authentication systems.