After my first scan for exposed .git directories, I did another scan for exposed .env files. During this scan I found more than 200 exposed .env files. Besides harmless configuration settings I found 135 database users and passwords, 48 e-mail user accounts with passwords, 11 live credentials for payment providers (like Stripe or Paypal), 98 secret tokens for different APIs and 128 app secrets (secrets to securely generate session ids, CSRF-tokens and JWT-tokens) and a few hard coded admin credentials.

TL;DR: Watch out for mistakes in the deployment process. Never expose your hidden .env file to the public.

I am SDCat a software developer with a curious mind which loves to look everywhere under the hood. After my scan for exposed .git directories I decided to go deeper into this rabbit hole. And decided I will check for exposed .env files.

In this post I describe, what a .env file is, how I scanned the domains and some stats about what was found in these files. The analysis of this data sometimes revealed many credentials for different services and accounts.

Every software requires some configuration and has various settings. In the case of user software, such as a mail client, these settings, like email address, username and password, are requested from the user the first time the software is started. For software that runs on a server and is often installed automatically, user interaction is not possible. For some software frameworks, these settings can be specified via environment variables and configured in a file with the name .env. The .env files are hidden files, so you do not see these files by default.

Example of an .env file:

ENV="PRODUCTION"
LOG_LEVEL="INFO"
SMTP_HOST="email.example.com"
SMTP_PORT= 25
SMTP_USER="[email protected]"
SMTP_PASS="SuperSecurePassword2022"
SMTP_TLS=1
SMTP_CONNECTION_TIMEOUT_SECONDS=2
DB_HOST="dbserver.example.com"
DB_DATABASE_NAME="important_database"
DB_USER="my-app-db-user"
DB_PASSWORD="2022SuperVerySecurePassword"
PAYMENT_GATEWAY="payment.example.com"
PAYMENT_SECRET= "super-secure-payment-api-secret"

Note: We recommend more secure passwords than the ones mentioned in the examples above.

Since almost every web application accesses a database or uses some APIs to communicate with, these credentials must be passed to the application. If this is done using the .env file, the credentials are in plain text in this file. When the web server is misconfigured and this .env file is delivered by the web server, anyone can query this data. To do this, one can visit just a URL with a browser, such as: https://example.com/.env.

The dangerous aspect is that the passwords and secrets are in unencrypted form in the .env file.

I chose a country which allows for DNS zone transfer to obtain all the domains of this country. It will take some time to download the complete zone file. With a simple python script, I extracted the NS records and from these records the domain names.

With another python script I read the domains and send a request to http://<domain>/.env. I also checked http://www.<domain>/.env, https://<domain>/.env and https://www.<domain>/.env.

It is important to ignore the SSL certificate check. I learned that many files were found over https but with an invalid certificate. By ignoring the invalid SSL certificates these directories can be accessed anyway.

I scanned 2.6 million domains and found:

These are the results of only the main domains. Imagine what would happen if we scan all the subdomains. I have no doubt you’d find a lot more there.

You can scan your domains and subdomains with a nuclei template or you can use a service like scan.nan.io to check your domains and subdomains automatically for exposed sensitive files.

Take away: Check your server and deployment to not expose the hidden .env file.