Attack Chain

1. Attacker authenticates to the Nginx-UI web interface.
2. Attacker retrieves the node_secret via a GET request to /api/settings.
3. Attacker crafts a POST request to /api/nodes to create a new cluster node.
4. The crafted node configuration includes a malicious url parameter pointing to an internal resource (e.g., http://127.0.0.1:51820 or http://169.254.169.254).
5. Attacker sends an API request (e.g., GET /api/settings) with the X-Node-ID header set to the ID of the newly created malicious node.
6. The Nginx-UI proxy middleware (internal/middleware/proxy.go) intercepts the request and forwards it to the attacker-specified internal URL.
7. The request is executed on the server-side, effectively performing an SSRF attack.
8. Attacker gains access to internal resources, cloud metadata, or triggers internal-only njs endpoints.

Impact

Successful exploitation allows an authenticated attacker to access internal services, cloud metadata endpoints, and internal-only njs endpoints. This can lead to the theft of sensitive information such as IAM credentials, port scanning of internal networks, and ultimately, remote code execution and privilege escalation if combined with other vulnerabilities. This vulnerability bypasses network segmentation and firewalls designed to restrict inbound traffic, potentially exposing critical internal resources.

Recommendation

• Deploy the Sigma rule Detect Nginx-UI SSRF via X-Node-ID Header to identify requests with the X-Node-ID header that may indicate SSRF attempts.
• Deploy the Sigma rule Detect Nginx-UI Malicious Node Creation to detect the creation of cluster nodes with suspicious URLs (e.g., internal IPs).
• Monitor network connections originating from the Nginx-UI server to internal IPs and cloud metadata endpoints using existing network monitoring tools.