3

Just as the title says, we have a website that uses third party smtp credentials to send emails, but, we keep getting our smtp credentials hacked and used to send spams emails, which results in our smtp account suspension, we first used ses, and then figured that we need to add spf,dkim and dmarc, after we added them, we moved to sendgrid, got hacked again, teammates think it is because of weak password to access sendgrid, but i do not think so, because password test says it is strong and requires 2 thousand years to crack, we do not really know the problem, we are using laravel 7 for our website, how is the hacker able to access .env file ?

Help, please.

logax
  • 99
  • 1
  • 14
  • 2
    is the .env file and that file is part of your deployment? is it in a public folder? if not, does your application for example include another files, can it access files outside of its folder? if it is in the app environment and the app allows some cross-site scripting access it may allow either directly printing the environment in the page or include the .env file to a page and read it that way. if possible, let you try to implement some xss precautions (limit app access), let you store the password encrypted and decrypt it on the fly. make sure you have good perms everywhere. – Petr Chloupek Nov 03 '20 at 14:51
  • Hi, Thank you for commenting, how can i test and see if i can access the file from outside ? – logax Nov 03 '20 at 15:00
  • @PetrChloupek can you please show me how to test this ? i do not know alot about security. – logax Nov 03 '20 at 15:16
  • maybe, let you start with the webserver logs. it can be an url like /images/../../../../.env or also /app/controller/../../.env if you have some url rewriting or view.php?file=../../../.env, it can be more complicated. just look for some things which should not be there. remove all the lines which are regular and look at the rest. – Petr Chloupek Nov 03 '20 at 15:19
  • the .env file is not in the public folder, i read online that if it is not there then it is ok, but the problem is that the .env file has a 777 permission :O, i do not know who set this, i never set 777 to files, can that be the problem ? i tried looking into the files for a pattern that has .env, but all i find is 404 (probably me trying to test access to the .env file from the url). – logax Nov 03 '20 at 16:21
  • @PetrChloupek what do you think ? – logax Nov 04 '20 at 11:05
  • did you search for any other suspicious pattern? the thing is that nobody can tell you what flaw may your application have. Only you know what is in the code. there are countless way how to exploit an application. Correct file permissions is one way how to limit the problem, but not the only way. https://www.cloudways.com/blog/php-security/ https://www.acunetix.com/blog/web-security-zone/hardening-nginx/ https://securityboulevard.com/2020/08/linux-server-security-10-linux-hardening-security-best-practices/ also, it may be anything outside of your app. like a hacked developer'r laptop. – Petr Chloupek Nov 04 '20 at 13:04
  • Hi, I got the same issue just like you.. I already complain to sendgrid but they have no clue. I also use laravel, did you manage to resolve this issue? – Abraham Putra Prakasa Feb 24 '21 at 04:05
  • Maybe its better to put your credentials in mail.php file instead of using .env file. Your complete project must have 755 permission and only storage folder 777. – Heril Muratovic Mar 24 '21 at 16:46

2 Answers2

2

Are you using nginx? I had the same issue. Following the tip of @PetrChloupek, I analysed the access logs (/var/log/nginx/access.log) and found out that sometimes an agent could get a 200 out of "/.env". It turned out that the configuration of the nginx was so that when using just the ip (v.g. 12.244.21.21 instead of "mywebsite.com") the malicious agent hitted the /var/www/html and not the public folder, as specified in the nginx conf file, since this dealt only with the specified host (v.g."mywebsite.com").

hudata
  • 21
  • 2
  • yup, that was my problem, there is an easy command that can get your .env file quite easily, bots love it, to fix the problem, i just made a policy to refuse every demand for a file that starts with a dot. – logax Jun 03 '21 at 17:30
  • Good. Just to be precise: you have made this rule in the most general file (like at /etc/nginx/sites-available/default). Because I had the rule of refusing all demands for files that start with dot, but only applicable to one host (v.g. mywebsite.com) and not to all demands (default_server), that's why they could fetch the my .env. – hudata Jun 06 '21 at 19:12
1

There is a known issue with developers leaving APP_DEBUG = true on live systems, this means you can trigger a debug page output that contains the .env keys and values.

https://www.mailgun.com/blog/a-word-of-caution-for-laravel-developers/

An easy way to trigger the issue, if vulnerable, is make an unsupported request, e.g. a POST / PUT request to a known GET route such as the site index '/', this will in cases where DEBUG is set to true output all the envrionment variables.

Luke
  • 151
  • 6
  • 1
    Yea, i knew of this at that time, and it wasn't the issue, my issue was that there is an easy command that can get your .env file quite easily, bots love it, to fix the problem, i just made a policy to refuse every demand for a file that starts with a dot. – logax Jun 03 '21 at 17:31
  • Make sense! In this we need to hide the .env file and set it to APP_DEBUG = false Any other things needs to take care? – Shashank Shah Feb 06 '22 at 09:20