Attack Chain

1. An attacker identifies a network-accessible OpenCost instance running a vulnerable version. This could be through a public ingress, NodePort exposure, or internal network access.
2. The attacker crafts an HTTP POST request targeting the /serviceKey endpoint of the OpenCost service (e.g., http://opencost.opencost.svc.cluster.local:9003/serviceKey or http://localhost:9003/serviceKey).
3. The request includes a key parameter within the request body, containing malicious data such as malformed JSON, an empty string, or attacker-controlled valid GCP service account credentials.
4. The vulnerable AddServiceKey function in OpenCost's pkg/costmodel/router.go receives the unauthenticated request.
5. Lacking any authentication or input validation, OpenCost extracts the value from the key parameter.
6. The extracted content is directly written to the key.json file located in the CONFIG_PATH directory (which defaults to /var/configs).
7. The existing key.json file is overwritten with the attacker-supplied malicious content, compromising the integrity or confidentiality of the GCP service account key.
8. Subsequent attempts by OpenCost to interact with GCP APIs will either fail due to invalid credentials, causing service disruption, or connect to an attacker-controlled GCP project, enabling data exfiltration or unauthorized actions.

Impact

The unauthorized file write vulnerability in OpenCost can lead to severe consequences across multiple dimensions. If an attacker injects invalid JSON or malformed credentials into key.json, OpenCost's ability to communicate with the GCP Billing API will cease, resulting in a disruption of cost monitoring and FinOps processes. This directly impacts an organization's ability to track and manage cloud expenditures. More critically, an attacker can inject their own GCP service account credentials, leading to sensitive data leakage. This includes the organization's cloud resource usage patterns, detailed cost breakdowns per namespace, and overall business intelligence regarding infrastructure scale and technology adoption. Such information could be highly valuable to competitors or for reconnaissance in future attacks. While the attacker cannot control the file path or name, the ability to fully control the key.json content without authentication poses a significant risk. For improperly exposed instances, the permissive CORS configuration enables cross-origin attacks, allowing malicious websites to initiate attacks from a victim's browser without their awareness.

Recommendation

• Deploy the Sigma rule Detect OpenCost ServiceKey Unauthorized File Write Attempt to your SIEM to alert on suspicious unauthenticated POST requests to the /serviceKey endpoint.
• Monitor webserver logs for HTTP POST requests directed at the /serviceKey endpoint, especially those originating from unexpected IP addresses or lacking proper authentication headers.
• Restrict network access to the OpenCost service endpoint /serviceKey through firewall rules, network policies, or API gateways to prevent unauthenticated external access.
• If possible, implement an authentication layer (e.g., API key, OAuth, OIDC) for the /serviceKey endpoint, as recommended by the OpenCost maintainers' remediation guidance.
• Ensure strong input validation is applied to the key parameter to verify the integrity and format of any submitted GCP service account keys.
• Review and restrict the Access-Control-Allow-Origin header in your web server or ingress configuration for OpenCost to only trusted domains, preventing cross-origin attacks.