CVE-2023-48023: Anyscale Ray SSRF Vulnerability

CVE-2023-48023 Overview

CVE-2023-48023 is a Server-Side Request Forgery (SSRF) vulnerability affecting Anyscale Ray versions 2.6.3 and 2.8.0. The vulnerability exists in the /log_proxy endpoint, which can be exploited by attackers to make the server perform unauthorized requests to internal or external resources. This SSRF vulnerability allows unauthenticated remote attackers to potentially access internal services, cloud metadata endpoints, and sensitive resources that should not be publicly accessible.

It is important to note that the vendor's position is that this vulnerability report is irrelevant because Ray, as stated in its documentation, is not intended for use outside of a strictly controlled network environment. However, organizations exposing Ray instances to untrusted networks remain at significant risk.

Critical Impact

This SSRF vulnerability allows unauthenticated attackers to access internal network resources, potentially leading to data exfiltration, credential theft from cloud metadata services, and lateral movement within the network.

Affected Products

• Anyscale Ray version 2.6.3
• Anyscale Ray version 2.8.0

Discovery Timeline

• 2023-11-28 - CVE-2023-48023 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2023-48023

Vulnerability Analysis

This vulnerability is classified as CWE-918 (Server-Side Request Forgery), a weakness that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain of the attacker's choosing. In the context of Anyscale Ray, the /log_proxy endpoint accepts user-controlled input that specifies the destination of HTTP requests, allowing attackers to abuse the server as a proxy for malicious requests.

The vulnerability requires no authentication and can be exploited remotely over the network with low attack complexity. Successful exploitation can result in significant confidentiality and integrity impacts, as attackers can potentially access internal services, retrieve sensitive configuration data, interact with cloud provider metadata endpoints (such as AWS IMDSv1), and pivot to other internal systems.

Root Cause

The root cause of this vulnerability lies in insufficient validation of user-supplied URLs in the /log_proxy endpoint. The endpoint fails to properly restrict or sanitize the destination URLs that can be requested, allowing attackers to specify arbitrary internal or external addresses. This lack of input validation enables the SSRF attack vector.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker can craft malicious HTTP requests to the /log_proxy endpoint, specifying internal resources as the target URL. The Ray server then performs the request on behalf of the attacker, potentially returning sensitive data or enabling further attacks.

The vulnerability can be exploited to:

• Access cloud instance metadata services (e.g., http://169.254.169.254/ on AWS)
• Probe and interact with internal network services
• Bypass firewall restrictions by using the Ray server as a proxy
• Potentially retrieve sensitive credentials and configuration data

For detailed technical analysis of this vulnerability, refer to the Bishop Fox Blog Post.

Detection Methods for CVE-2023-48023

Indicators of Compromise

• Unusual outbound HTTP requests from Ray server instances to internal IP ranges or cloud metadata endpoints
• HTTP requests to the /log_proxy endpoint containing suspicious URL parameters targeting internal addresses
• Unexpected access patterns to internal services from Ray server IP addresses
• Log entries showing requests to 169.254.169.254 or other metadata service endpoints

Detection Strategies

• Monitor network traffic from Ray instances for connections to internal IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and link-local addresses (169.254.0.0/16)
• Implement web application firewall (WAF) rules to detect and block SSRF patterns in requests to the /log_proxy endpoint
• Configure intrusion detection systems to alert on metadata service access attempts originating from application servers
• Review access logs for the /log_proxy endpoint and flag requests with unusual or internal URL targets

Monitoring Recommendations

• Enable comprehensive logging for all Ray Dashboard and API endpoints, particularly /log_proxy
• Implement network segmentation monitoring to detect unauthorized cross-segment traffic from Ray instances
• Deploy endpoint detection and response (EDR) solutions to monitor process behavior on Ray server hosts
• Establish baseline network behavior for Ray deployments and alert on anomalies

How to Mitigate CVE-2023-48023

Immediate Actions Required

• Ensure Ray instances are deployed only within strictly controlled network environments as per vendor documentation
• Implement network-level access controls to restrict access to Ray Dashboard and API endpoints from trusted sources only
• Block outbound access from Ray servers to cloud metadata endpoints and sensitive internal services
• Audit current Ray deployments for exposure to untrusted networks and remediate immediately

Patch Information

As of the available data, there is no specific vendor patch addressing this vulnerability. The vendor's position is that Ray is designed for deployment in controlled network environments and should not be exposed to untrusted networks. Organizations should review the Ray Documentation on Security for guidance on secure deployment practices.

Workarounds

• Deploy Ray behind a reverse proxy or API gateway that validates and restricts URL parameters to the /log_proxy endpoint
• Implement strict network segmentation to prevent Ray servers from accessing sensitive internal resources
• Configure firewall rules to block outbound connections from Ray servers to metadata services (169.254.169.254) and internal network ranges
• Use authentication mechanisms at the network level to restrict access to Ray endpoints
• Consider deploying Ray in isolated network environments with no direct access to sensitive internal systems

# Example: Block metadata service access using iptables
iptables -A OUTPUT -d 169.254.169.254 -j DROP
iptables -A OUTPUT -d 169.254.0.0/16 -j DROP

# Example: Restrict Ray Dashboard access to trusted IPs
iptables -A INPUT -p tcp --dport 8265 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 8265 -j DROP