On August 15th, Palo Alto Network’s Unit 42 published an article describing a sophisticated large-scale attack on multiple victim organizations that leveraged exposed developer secrets in .env files.
What are .env files?
.env files are used by services at runtime to configure environment variables which are sensitive. See for example the following:
.env files usually contain very sensitive secrets such as AWS Access Keys, Database Credentials and 3rd party SaaS API Keys. Therefore, .env files are usually (but not always) prevented from reaching the Github repository. Instead they are manually configured on all endpoints on which the code is meant to run including both production servers and also on engineer endpoints to enable testing features.
Why would a .env file be exposed over the public internet?
Oftentimes, .env files are used to configure web servers which must be publicly accessible in order to serve a customer-facing web application. Unfortunately, depending on configuration, the behavior for several popular web server frameworks (including nginx, apache, node.js express) when asked to serve a local file over the public internet is to serve it as-is if the file is in the same directory as the web server.
Therefore, an attacker can visit http://your-website.com/.env and retrieve the .env file being used in production if the web server is misconfigured.
How do I know if this impacted me?
As noted by Unit 42 researchers, the attackers left a digital footprint following the initial access to victim cloud environments. In order to identify whether you were impacted, search for API calls leveraged by the attackers and search for anomalies, try to correlate with access keys that are used within .env files in your organization.
- Search in AWS CloudTrail for the GetCallerIdentity API call which was leveraged by the attackers for Discovery
- Search in AWS CloudTrail for CreateRole and AttachPolicy API calls which were leveraged by the attackers for Privilege Escalation
How to respond if I am impacted?
If you are impacted:
- Make sure to promptly rotate all sensitive keys that may have been exposed
- Make sure to discover and remove all potential backdoor identities which the attacker may have left in your environment
How can I proactively protect against these kinds of threats?
- Inventory your secrets, identify where they are located, which are at risk of leakage and who owns them
- Migrate to ephemeral credentials, for example migrate IAM Users to IAM Roles
- Rotate secrets frequently
- Enforce Least Privilege to mitigate damage post-breach
Let’s Talk
Have any comments or notes? Shoot me a message and let’s discuss. If you found this article helpful and you want to get notified on future research by Torch Security, sign up here.
