Mail hacked | Are you keeping a database of each Install / Update with IP/ Domain?

Hi !
Last week I installed a new v5, and generated an app password for my email.

I didn’t noticed it but the very next day on my sent email folder was an email sent with the IP of my instance and my email details.

Again same thing happened few days after.
And last night I had to deal with more than 857 phishing emails sent from my email.

Fortunately I noticed it by bounced emails.

So, I now secured my install (thank you nginx for regenerating a default where the http point to my IP :face_with_symbols_over_mouth:) and generated a new app password.

After investigation, it appears that laravel have a major security flaw. But I secured it.

My Invoice Ninja v5 is not indexed by any search engine, but they hacked into the very next day after the installation.

So now, my question is very simple :

ARE YOU KEEPING ANY RECORD WITH IP / DOMAIN OF EACH INSTALL OR UPDATE ???

IF SO, DISCLOSE THAT YOUR DATABASE CAN BE READ OR HAVE BEEN HACKED ! IT IS IMPOSSIBLE FOR THEM TO KNOW I MADE AN INSTALL SO FAST !

@Charles.k

The short answer is no. We don’t store that kind of data.

The longer answer is on the internet there are bad actors swarming every IP address known with scripts looking for vulnerabilities like this where the .env has been inadvertently exposed.

This is a new IP generated for a new instance by Google cloud, so it’s not a “known IP with script”.

So, well, my best advice is to protect the .env by doing the following.

IF USING APACHE2 :
Add the following on the .access

<Files .env>
order allow,deny
Deny from all
</Files>

IF USING NGINX

Remove the file “default” with the following command

sudo rm /etc/nginx/sites-available/default

And link your conf file

sudo ln -s /etc/nginx/sites-available/your_ninja_domain.com.conf /etc/nginx/sites-enabled/your_ninja_domain.com.conf

The best method to protect the .env file is by never exposing the document root where the .env lives.
You should always use the doc root of /public

listen 80;
server_name invoiceninja.test;
root /var/www/invoiceninja/public;
index index.php index.html index.htm;
client_max_body_size 20M;

There are many reasons for this; the .env is one, but you are also exposing the vendor/ directory which is another attack vector that could be used against you.

Of course, it actually is already set like that, and I used certbot to use port 443 with ssl certs instead of port 80.

But the pesky default of NGINX point to the root instead of the public, I deleted it at first but for some unknown reasons, it got regenerated which exposed my .env

I also redirected the http to https, but because of the default file of NGINX , if they pinged my domain, then they got the IP and therfore could get the .env by simply going to

http://[my-ip-address]/.env

You can also consider Cloudflare DNS. I know with certbot, you will install a certbot cloudflare ddns extension, and edit your certbot scripts for it, but it is worth it. Cloudflare for free proxies all the 443 traffic to your server, and intercepts and blocks anyone attempting to connect to your server https with direct IP. Even running wget https://((ip address))/.env would return an SSL error.