Forge Public folder hacked

https://www.freecodecamp.org/news/protect-your-laravel-app-against-the-owasp-top-10-security-risks/

Level 73

Yes
Yes
Maybe

I think these might be worth checking out

https://www.esparkinfo.com/laravel-security-practices.html

1 like

Level 3

@Tray2

Thank you! I will certainly have a good read of those.

I'd love to know how a script can write to the public folder by using the debug information...

Level 102

@stuartcusack Debug mode is just one attack vector. Check you .env for any value that could give access to the site itself.. But the hack could just as well come from a bad file uploader, or an insecure password (if ftp is enabled).

It is a bit like saying "How did thiefs get into my house by going though my mailbox and letters.. I know I forgot to lock it".. When in fact they both went though you letters, but got in through your bathroom window.

1 like

Level 3

@Sinnbeck I get you. The thing is that application is quite simple with a minimal amount of endpoints. Almost every route is behind authentication. No FTP either. Only SFTP.

The debug mode being turned on is the only weakness I can see. I just wonder how they manage to exploit that. I thought the public folder was impossible to write to unless you have SSH access.

Level 102

@stuartcusack Personally I dont see any way of getting stuff into the public folder by using .env/debug info. But then again I dont know what you have in there :) Mostly it would give access to stuff like the database.. There isnt any page where you can upload anything (even admin)?

Level 3

@Sinnbeck Yes me neither. It's a standard env file with database credentials, smtp credentials and Amazon S3 credentials. All the default ENV variables that ship with a new installation of Laravel, I haven't added anything special.

In the private sections of the application a user can upload files to Amazon S3 but nothing more.

Level 102

@stuartcusack Then I cant say. Best bet would be to have a security researcher look over the source and if they have any idea.

martinbean

Level 80

@stuartcusack If you’ve been compromised then yes, rotate every API key and secret. Consider them exploited. Also turn off debug mode if you haven’t already. It goes without saying that this should not be enabled in a production or public-facing environment.

Unfortunately, there are myriad of ways someone can gain access to a server. Someone’s obviously found an exploit with yours. It may not be specifically debug mode itself being enabled, but it gave the attacker enough detail to be able to successfully compromise your application and server.

So, you now need to find out how they did. Check your server logs for suspicious requests. A lot of them will be URLs but with suspect-looking query strings added. The attack vector could be anything. The most common are a susceptible package, or susceptible code you’ve written yourself such as an endpoint that takes user input and it is not sanitised fully before being processed by your application, allowing attackers to craft URLs that have unintended side effects.

If the issue isn’t with debug mode but actually somewhere else, then disabling it isn’t going to stop further attacks. It’s a bit like saying you’ve locked your door if you’ve left the window open and it was the window the burglar was using. You need to pinpoint the method. You need to identity the problem before you can solve it, otherwise you’re just playing whack-a-mole and hoping for the best.

4 likes

https://github.com/fabpot/local-php-security-checker

Level 102

You can also try running this against your packages

1 like

Level 3

@Sinnbeck Nice piece of software. It flagged a few suspect packages and I have updated them.

No hacks over the weekend. Fingers crossed....