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

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?

Sunnisunnite

I think Information Security or Webmasters would be better places to ask this. – Tigon

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.

Touchwood

My bigger concern was the localhost aspect, that it appeared that the bot was running locally, implying a vulnerability on the server. Restarting the dynos seems to killed that, so if access was granted, it wasn't disk access. Not great, but not worst case. The honeypot approach you indicated is new to me, and looks like something that could be really useful, so thanks for pointing me in that direction. – Sunnisunnite

From your log entry, 10.45.153.152 appears to be an intranet (LAN area) IP address, and the server: localhost does not guarantee that the client is on the same machine. You might have a server with server_name localhost, but is accessible from the outside because it is either a default server (so anyone hitting server IP, end up "requesting" that server block) or remote client sends Host: localhost while talking to your server IP. – Touchwood

@DanilaVershinin I really like your proactive honey spot solution; do you recommend a similar solution for Apache at AWS? – Nirvana

@Nirvana you probably can setup fastcgi script for automatic ban in a similar fashion, but with Apache – Touchwood

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.

Ruthi

Welcome to Stack Overflow. Please take the tour. This is a question and answer site, not a discussion forum. This section is only for answers. Once you have earned 50 reputation points by asking and answering you will be able to comment on other users' questions and answers. – Sty

This does not provide an answer to the question. Once you have sufficient reputation you will be able to comment on any post; instead, provide answers that don't require clarification from the asker. - From Review – Stewardess

lol that sounds awesome. im going to do that but either send a jpg or fake honeypot credentials – Kiel

Buddy. You are a hero. Will you share that binary file?😂 – Hyperparathyroidism

One of my SaaS app's backend was attacked multiple times. The request was to GET /.env I am returning a dummy .env file. That hacker thinks its a legit .env and tries them. I feel so happy. Thanks for the idea. – Hyperparathyroidism