brandtkeller
commented
6 months ago Thanks for creating the issue @naveensrinivasan.
This will help track conversations as we look to perform more exploratory efforts for API functionality that lead to Lula being Generally Available.
For posterity - Lula is currently being designed in an effort to meet assessment requirements towards accredited/authorized systems. Part of that requirement is continual authenticated scanning - which Lula could augment.
This coupled with the design element of where security and trust should be established leads a large surface for conversation that the team is approaching. For context: Lula is driven contextually to enable proofs (data collection + policy) to be stored in OSCAL for transient-data / GRC purposes. Meaning that there needs to be a greater discussion for the signing and verification of OSCAL artifacts prior to Lula executing against a live-environment.
All of this to say - definitely agree on the potential vulnerability involved here. Some of which may be accepted for intended use and others for which Lula can establish guard rails to protect against malicious intent. More to explore as API functionality is not currently a focus for the team as of yet.
Inquiry:
Is there a possibility that the application's feature, which fetches data from URLs specified by users, could be exploited to access cloud provider metadata services? This concern arises from the observation that the application does not enforce strict validation on the URLs it requests, potentially opening up avenues for Server-Side Request Forgery (SSRF) attacks.
Context:
Our application includes functionality where it makes HTTP GET requests to URLs provided by users. The relevant code snippet is as follows: https://github.com/defenseunicorns/lula/blob/e6c2c2fa8d4d8cc5c8c0a24c074d92b9a4de1f3a/src/pkg/providers/opa/opa.go#L57-L94 Given this setup, I am concerned about the potential for SSRF attacks, mainly targeting cloud provider metadata services, which could lead to unauthorized access to sensitive information.
Scenario: Accessing Internal Cloud Metadata Services
Many cloud providers offer a metadata service to virtual machines (VMs) running in the cloud. This service provides data about the VM, such as its role, identity credentials, and other sensitive information, accessible at a specific URL.
Suppose an application allows users to specify a URL from which it fetches data. An attacker discovers this functionality and inputs the URL of the cloud metadata service. The server, running in the cloud and accessing the metadata service, requests the specified URL.
Attacker specifies: http://169.254.169.254/latest/meta-data/iam/security-credentials/The application, not properly validating or restricting the URLs it can request, fetches the data from the cloud metadata service. The attacker can then access this sensitive information, which might include:
With these credentials, the attacker could potentially:
Real-World Impact
This scenario is not just theoretical. There have been instances where SSRF vulnerabilities were exploited to access cloud metadata services, leading to data breaches and unauthorized access to cloud resources. For example, the Capital One data breach in 2019 involved an SSRF vulnerability that allowed an attacker to query the metadata service for credentials, ultimately leading to data exfiltration from cloud storage.