Apache Ranger UI anfällig für (Server Side Request Forgery)

The SSRF vulnerability in Apache Ranger's UI presents a significant risk. An attacker could leverage this to scan internal networks, access cloud metadata services (e.g., AWS, Azure, GCP), and potentially exfiltrate sensitive data stored within Ranger's configuration or accessed by its policies. Successful exploitation could lead to unauthorized access to internal systems and compromise the confidentiality and integrity of data managed by Ranger. The impact is amplified if Ranger is used to manage access control for other critical systems, as an attacker could potentially use this vulnerability to gain broader access.

Organizations heavily reliant on Apache Ranger for centralized security policy management and access control are particularly at risk. Environments with Ranger integrated with cloud platforms (AWS, Azure, GCP) are also vulnerable, as the SSRF vulnerability could be used to access cloud metadata and potentially compromise cloud resources. Any deployment of Apache Ranger versions 2.4.0 or earlier is considered at risk.

• java / server:

ps -ef | grep ranger

• java / server:

journalctl -u ranger-service -f | grep "Edit Service Page"

• generic web:

curl -I http://<ranger_server>/ui/edit-service -v

• generic web:

 grep -r "Edit Service Page" /var/log/apache2/access.log

1. 2025-01-22Disclosure

   disclosure

1. Reserviert2024-08-29
2. Veröffentlicht2025-01-22
3. Geändert2025-06-10
4. EPSS aktualisiert2026-04-02

The primary mitigation for CVE-2024-45479 is to upgrade Apache Ranger to version 2.5.0 or later, which contains the fix. If an immediate upgrade is not feasible, consider implementing temporary workarounds such as restricting network access to the Ranger UI to trusted sources only. Firewall rules can be configured to limit outbound connections from the Ranger UI to only necessary internal services. Regularly review Ranger's access control policies to ensure they are appropriately configured and minimize the potential impact of a successful SSRF attack. After upgrade, confirm the vulnerability is resolved by attempting to access an internal resource through the Edit Service Page and verifying that the request is denied.