My web app was hacked today – Bad experiences and how to prevent them?

Question

Today my web app ViralQuotes was hacked. My DB was erased, instead, there was a new table called Warning with a message 0.08 BTC to recover my DB.After 5 hours I was able to rebuild my DB, but unluckily I lost all my historical data within my 400+ users data among them.Of course, there are some lessons learned about it:Don't forget to set up regular backups. I know, I was really silly for not doing it, but I never thought that someone would hack my insignificant website. So, stop what you are doing, and go and set up some way to back up your DBs and significant files at least once a day. Some providers offer it for a few extra bucks a month. Don't be like me, maybe your product is not generating thousands of dollars and you think that no one will waste his time hacking your site, but remember that is important for you and that's is enough.After looking into how that could happen, I realized that I pushed to my server my .env file with all the database credentials in it, which Is pretty simple access to it especially if you use Laravel. I found out that is a pretty common mistake, If you google DB_USERNAME filetype:env you will find thousands of Laravel env files exposed Therefore, remember to actually set your variables from the .env file as environmental variables in your server and destroy any .env file that is around there.For sure there are more lessons to learn about this, but I realized that I Would like to hear if some of you have had bad experiences like this one, and what do you recommend to prevent them?.Cheers, Nico

michaelmcmillan · Accepted Answer

That sucks! But the real lesson should be that you do not expose your database on the internet (0.0.0.0 vs 127.0.0.1). That way it doesn&rsquo;t matter if you leak your .env via your webserver. Never expose sensitive services.

tortasaur · Answer

After reading your post, I thought "these things happen; they'll figure it out with experience."Tried going to clientsite.com/api/.env on a whim, and leapt out of bed.

ryanmccullagh · Answer

To maintain dev ops best practices such as prohibiting nginx from sending dotfiles (.env, .git, etc) takes time. It&rsquo;s understandable that you made a mistake. But how did they get access to the actual dB? Did you expose it over the public internet?

dana321 · Answer

Its a suckerpunch.. If there is a way in, they will find it. You have to vet everything.
I had a side project compromised through some supplementary php files that came with a javascript library. Luckily, i didn't have any users on it.
Keep everything up to date, including your server software, composer, javascript libraries etc.
Make sure you run a clamav on linux, it will catch any intrusion writing scammy files and rename them.
All passwords unique and made using a password generator. That way, if you are compromised it is only one password not the keys to everything.
Don't keep non-user stuff with predictable uri (like /admin/ /phpmyadmin/ etc.)
One-way backups.. Allow your backup server behind a firewall to login to your site and do hourly backups of all the data.
Disallow access to any files beginning with dot in your webserver configuration. I'm pretty sure nginx does this by default.

rutthenut · Answer

Some useful points made in other comments, tied-in to your particular problem/exploit.I would recommend you get familiar with OWASP, and especially the 'top ten' security issues that they publish. See https://owasp.org/www-project-top-ten/

priom · Answer

Sorry to hear about your situation, it really sucks. Curious, if you can shed more light on how the .env was exposed?

ngranja19 · Answer

https://twitter.com/ngranja19/status/1232852987921469441?s=1... here is the message they leave me if someone is courious.

alexpetralia · Answer

Just wanted express my condolences, that sounds like a huge pain. It at least sounds like you are using the experience profitably with some thoughtful reflection. I wish you the best in a speedy recovery!

Operyl · Answer

In addition to setting up backups, there&rsquo;s another step you should probably think about: make sure whatever credentials you are using to store those backups (if using an object storage service) are only allowed to add/append/upload and _not_ delete. I have seen attackers wiping backup locations a few times now, and it isn&rsquo;t immediately obvious to people.Sorry it happened to you, but it&rsquo;s a good lesson learned. Better luck in the future.

sergiotapia · Answer

Woah what, you're not kidding:https://www.novochem.net/.envLaravel should not even render this .env file by default, way too many results.Laravel has no github issues, so I don't know how to let the author know. https://github.com/laravel/laravel Someone ping him on twitter

mc3 · Answer

Sorry to hear that. The obvious lesson is "backup", maybe the less obvious lesson is to pay a bit more for a service that does this for you (or a cloud provider might have that included) and have peace of mind.For similar reasons I use a cloud backup for home PC files that just syncs it all up. When I was doing it manually it was a once a year affair because: too busy!

allthetime · Answer

How is your db setup? If you are running your own instance, just make a cron script that dumps the db every so often (more often if its small) and uploads it to s3 or something.You don't really need server backups/images if you document/script your server setup properly.

woranl · Answer

If the hacker gained access to your database, he/she can also create a backdoor file to gain shell access via the output sql. You might want to check for any malicious/suspicious files in your server that will take shell command as http parameters.

machinecoffee · Answer

In your haste to get everything back up and running again, don't forget to change the database credentials or you'll be back in the same boat again :)

longtermd · Answer

I would love to see a blogpost "security best practices for SPAs" (single page applications)

franzwong · Answer

Where do you host the webapp? Some cloud platforms provide security protection and you should use it.

imvetri · Answer

Sorry to hear that. As a request please remove the Google keyword suggestion in your post. More people will be aware of the technique now.

My web app was hacked today – Bad experiences and how to prevent them?

That sucks! But the real lesson should be that you do not expose your database on the internet (0.0.0.0 vs 127.0.0.1). That way it doesn’t matter if you leak your .env via your webserver. Never expose sensitive services.

After reading your post, I thought "these things happen; they'll figure it out with experience."
Tried going to clientsite.com/api/.env on a whim, and leapt out of bed.

To maintain dev ops best practices such as prohibiting nginx from sending dotfiles (.env, .git, etc) takes time. It’s understandable that you made a mistake. But how did they get access to the actual dB? Did you expose it over the public internet?

Some useful points made in other comments, tied-in to your particular problem/exploit.
I would recommend you get familiar with OWASP, and especially the 'top ten' security issues that they publish. See https://owasp.org/www-project-top-ten/