GHSA-8MC6-XJPR-H98X: Server-Side Request Forgery (SSRF) in Ech0 fetchPeerConnectInfo

The vulnerability exists in the peer connection management logic of the Go-based Ech0 application. The specific vulnerable component resides in the fetchPeerConnectInfo function, which handles outbound requests to configured peer nodes. The application utilizes this function to synchronize status and metadata from external peer connections.

The application accepts a user-provided URL during the connection registration process. When processing the registered peers, the server initiates an HTTP GET request to the specified destination. The implementation relies on a generic HTTP client wrapper that performs no network boundary validation or hostname sanitization.

This behavior introduces a Server-Side Request Forgery (CWE-918) vulnerability. The application fails to validate the destination URL or the resolved IP address before establishing the connection. Consequently, the server blindly follows requests to protected network segments.

Attackers leverage this design flaw to pivot attacks through the Ech0 application server. The application executes these requests using its own network context and privileges, granting the attacker indirect access to internal resources that are otherwise isolated from external networks.

The fundamental root cause is the usage of an unconstrained HTTP client combined with unvalidated user input. The fetchPeerConnectInfo function in internal/service/connect/connect.go retrieves the peerConnectURL parameter and passes it directly into httpUtil.SendRequest. The function appends /api/connect to the base URL but applies no restrictions on the domain or IP address specified in the base URL itself.

The Go standard library http.Client automatically resolves hostnames and connects to the resulting IP addresses. Without a custom DialContext implementation to enforce network constraints, the client permits connections to any address accessible from the host OS. This includes loopback addresses (127.0.0.1, ::1), RFC 1918 private network spaces, and cloud provider metadata services (169.254.169.254).

The implementation evaluates the target solely based on the input string. It ignores the underlying network characteristics of the destination. If an attacker supplies a hostname that resolves to an internal IP address, the generic HTTP client performs the DNS resolution and initiates the TCP handshake with the internal host.

Furthermore, the application lacks defense against Time-of-Check to Time-of-Use (TOCTOU) DNS rebinding attacks. Even if the application attempted basic string matching against the URL, an attacker could supply a domain name under their control that initially resolves to a safe IP address but subsequently resolves to a protected internal IP address when the HTTP client establishes the connection.

A review of the vulnerable implementation reveals a direct pipeline from user input to the HTTP request execution. The fetchPeerConnectInfo function utilized httpUtil.SendRequest, which acted as a direct wrapper around standard Go HTTP execution.

// Vulnerable Implementation
func fetchPeerConnectInfo(peerConnectURL string, requestTimeout time.Duration) (model.Connect, error) {
    url := httpUtil.TrimURL(peerConnectURL) + "/api/connect"
    // The SendRequest function performs no validation on the destination URL
    resp, err := httpUtil.SendRequest(url, "GET", ...) 
    // ... processes response ...
}

The maintainers addressed this vulnerability in commit 091d26d2d942df6df9f520328d2f9cf2592bbefc by implementing a defense-in-depth strategy. They replaced the insecure HTTP wrapper with httpUtil.SendSafeRequest and introduced validation during the initial connection registration phase.

// Patched Implementation
func fetchPeerConnectInfo(peerConnectURL string, requestTimeout time.Duration) (model.Connect, error) {
    url := httpUtil.TrimURL(peerConnectURL) + "/api/connect"
    // SendSafeRequest implements IP validation at the dialer level
    resp, err := httpUtil.SendSafeRequest(url, "GET", ...) 
    // ... processes response ...
}

The core of the mitigation lies within the SendSafeRequest implementation. This updated wrapper utilizes a SecureDialContext which hooks directly into the Go net.Dialer. It resolves the target hostname and explicitly rejects private IP ranges and loopback interfaces immediately before the TCP handshake occurs.

By enforcing validation at the dialer level, the patch effectively prevents DNS rebinding attacks. The IP address validated by the security policy is the exact IP address used for the TCP connection, eliminating the TOCTOU race condition present in application-layer URL parsing.

Exploitation requires the attacker to possess sufficient privileges to add or modify a peer connection within the Ech0 application. This typically requires administrative credentials or an authorized user account with connection management permissions.

The attacker initiates the exploit chain by registering a new peer connection. They supply a target internal URL, such as http://169.254.169.254/latest/meta-data/ for AWS environments or http://127.0.0.1:8080 for locally bound administrative services, as the peerConnectURL parameter.

The trigger occurs when the application processes the list of configured connections. The attacker forces this process by issuing an HTTP request to the /api/connects/info endpoint. This action commands the application to iterate over the registered peer connections and execute the fetchPeerConnectInfo function for each entry.

The Ech0 server performs the outbound HTTP request to the specified internal resource. The target service processes the request and returns the response to the Ech0 server. The server then includes the contents of this response in the connection metadata returned to the attacker, completing the data exfiltration.

The successful exploitation of this vulnerability yields a high severity impact on confidentiality. The Ech0 server acts as an open proxy, enabling the attacker to interact with internal services that are intentionally shielded by firewalls or network boundaries.

In cloud-hosted deployments (AWS, GCP, Azure), the primary risk is the exposure of the Instance Metadata Service (IMDS). Attackers query the IMDS endpoint at 169.254.169.254 to extract temporary IAM credentials, instance configuration data, and user-data scripts. These credentials often permit lateral movement into the broader cloud control plane.

In containerized or Kubernetes environments, attackers leverage the SSRF to query internal orchestration services. They can issue requests to kubernetes.default.svc to retrieve cluster status, or query the local kubelet endpoints to extract pod metadata and configuration secrets.

The CVSS score is evaluated at 8.0 (High), reflecting the requirement for initial privileges but acknowledging the significant downstream impact. The vulnerability provides a direct pathway to pivot from application-level access to deep infrastructure-level access.

Organizations running the Ech0 application must apply the software update containing commit 091d26d2d942df6df9f520328d2f9cf2592bbefc. This update enforces strict validation of outbound connections and neutralizes the SSRF vector at the application level.

Administrators who cannot immediately patch the application should implement network-level controls. Configuring strict egress filtering on the application host or container neutralizes the impact of the SSRF. Blocking all outbound HTTP traffic to the 169.254.169.254 subnet prevents the extraction of cloud metadata.

Cloud infrastructure administrators must transition to AWS IMDSv2. IMDSv2 requires an initial PUT request with specific HTTP headers to generate a session token. The vulnerable httpUtil.SendRequest implementation only performs generic HTTP GET requests and cannot construct the specific payloads required by IMDSv2.

Security teams should monitor application logs for requests to /api/connects/info that are closely preceded by modifications to the peer connection configuration. Outbound connection logs from the Ech0 host targeting internal RFC 1918 subnets serve as a strong indicator of compromise.