Do these .env GET requests from localhost indicate an attack?

Question

I was just looking through our logs after getting some intermittent 5xx errors on a Heroku hosted site, and in there I discovered many errors that were emanating from localhost and were requests for hidden files, usually .env but also things like stuff like ".well-known/assetlinks.json" and occasionally .env in non-existant subfolders.

The requests are not frequent (15 - 30 per day), but appear to have been going on for a week. They are also being met with a "access forbidden by rule" which as far as I can tell is nginx.

The request look similar to:

2020/09/28 14:37:44 [error] 160#0: *1928 access forbidden by rule, client: 10.45.153.152, server: localhost, request: "GET /.env HTTP/1.1", host: REMOVED

I don't have any ENV files on the server, and the nginx seems to be blocking the requests, so it doesn't feel like there is any harm. Restarting all the dynos seemed to have killed the activity (based on a few hours having passed), but what worries me is that these appear to be "coming from inside the house". Is there something here that I should be concerned about? Is this a case of a bot exploiting a bug in a system that has local access?

Answer 1

Requests to /.env are, by all means, malicious.

Many apps (Laravel based for example) use .env files to keep very sensitive data like database passwords. Hackers/their automation scripts attempt to check if .env is public accessible.

If they can red .env files in the first place, this indicates an improperly configured server and a server admin who have set up the server in such a bad way, should be deemed responsible for the consequences...

The consequences are typically one thing. Hacker, once obtained .env data, has database credentials and, with little sniffing, finds the URL to PhpMyAdmin. Because typically, a "bad configuration" includes publicly accessible PhpMyAdmin.

Next thing you know, they email you that your database is gone and they have it. The only way to get it back, unless you have a backup, is paying up some cryptocurrency.

What to do

Ensure .env are not in publicly accessible directory in the first place. Even if they are, have NGINX deny access to them, e.g. deny access to all hidden files:

location ~ /\. {
    deny all;
}

Whether you have any .env files on your system or not, you can be sure the traffic associated with requesting them on the web, is malicious. To reduce any CPU load and prevent their further attempts to find website exploits, you can use the honeypot approach, e.g.:

location ~ /\.env$ {
    include includes/honeypot.conf;
}

... will trigger immediate firewall ban against an IP which tried to read .env files. This proves useful because .env exploitation can be just one out of many possible other attacks, and since the related IP is blocked, it can try no more.

Answer 2

I have a CGI script for 404s that sends a binary file Whenever I get a request for a .env. I figure a hacker will be trying to parse the .env, and I hope his parser will not like the binary file. I then black hole the IP from which the request originated.