One up and coming request I recently noticed in our honeypots was pretty simple:
Twilio is a popular service used to send/receive SMS messages and phone calls [1]. They offer a simple API and integration is very easy. To authenticate to the API, requests need to include an "Account SID" and "Auth Token". Like in many similar APIs, each request includes these credentials. Twilio's documentation suggests to store these credentials in environment variables and use a .env file to initialize the variables [2].
Using environment variables to store credentials is common practice and not the worst way to store this kind of data. A secure credential wallet/management system is of course preferred, but Twilio's advice makes sense in that it is language agnostic and not limited to a particular solution a developer may have selected. But the location of the .env file matters. Files like this should NEVER be placed inside the Web Root / Document Root of a website. Instead, they should be placed outside in a location not directly accessible by a browser. In addition, direct access to these files should be blocked by the webserver. The webserver will likely need read permissions to access the file, but the file should be blocked from being delivered to the user unparsed. twilio.env isn't the only .env file that attackers are looking for. The particular attacker is also looking for:
In Apache, you may use the following Files directive to block access to ".env*' files:
In the past, I sometimes blocked access to all files starting with ".", but be careful to allow access to .well-known for the Let's Encrypt ACME protocol. [1] Twilio.com --- |
Johannes 4506 Posts ISC Handler Aug 24th 2021 |
Thread locked Subscribe |
Aug 24th 2021 10 months ago |
I planned to write an internet service for a niche that I support, however I realised the need to try to combat the attack vectors used against port 80 and port 22, so I wrote a super lightweigth set of script which collect target urls and IP address, and block IP address that I catch (and now ranges).
Anyway, after 1 month, 400+ url paths and (almost) 1000 IP address are block, most of what I see in the logs no are /.env requests (230 last 30 days). Looking into 2 IP addresses captured from the the same IP range (8 hours apart) and turning up a 3rd (seemingly innocent) from 3 days before, I think I might have stumbled on a Phishing probe network. The caught IP address with "mail." domains, and an accidentally wrong IP lookup turned up another. Further checking exposes UK registered company with Dutch & Romainian IP addresses across 3 ranges, a (virtual) host with phone support "during Italian office hours", and more mail domains. Most of the domains are "questionable" at first glance, all of which are registered through 1 domain registrar, and the ones I looked up all registered out of Iceland. Checking the IP range owner reviels more domains bound to their own server, but of a "less questionable nature" (maybe), and include .co .cc .de .me .xyz .one .icu .club .ga with there most populus domain being registered in Hungaria parked by a non-functioning German registered domain parking site. More questionable mail servers are Gabon domains. If you have someone there who is interested I can provide details. |
Anonymous |
Quote |
Aug 24th 2021 10 months ago |
Sign Up for Free or Log In to start participating in the conversation!