0

My website built upon Laravel is currently under attack.

Only the index.php file was changed, and by that I mean that every line of code is inserted above the original Laravel code. So this code executes before the legitimate Laravel code.

It is harming my SEO.

  • What is causing this massive exploitation?
  • How do you protect yourself against it?
Sir Muffington
  • 1,447
  • 2
  • 9
  • 22
Hassan Nasir
  • 1
  • Someone else asked almost exactly this question less than an hour ago, so it sounds like there's widespread exploitation of some Laravel bug happening right now. https://security.stackexchange.com/questions/256054/my-website-hacked-needs-possible-reasons-and-solutions – Polynomial Oct 13 '21 at 14:01
  • How can I prevent from it. @Polynomial – Hassan Nasir Oct 13 '21 at 14:06
  • 1
    All you've told us is "my site got breached", so it's impossible to know what the cause is. Maybe you left some of the config files exposed like the other person? Try following the advice in the accepted answer to this question: https://security.stackexchange.com/questions/39231/how-do-i-deal-with-a-compromised-server – Polynomial Oct 13 '21 at 14:09
  • Check for the existence of the file `/vendor/voku/portable-ascii/src/voku/helper/data/functions.php`. It looks like the attacker is creating that file, and it's probably where their malicious code is. Just removing it won't stop you from being exploited again, though, through whatever method they used before. – Polynomial Oct 13 '21 at 14:25
  • 2
    Does this answer your question? [How do I deal with a compromised server?](https://security.stackexchange.com/questions/39231/how-do-i-deal-with-a-compromised-server) – kelalaka Oct 13 '21 at 17:18
  • It might be CVE-2021-3129 and you fix it by disabling debug mode on your app. – Sir Muffington Oct 15 '21 at 15:42
  • As suggested above, there may be a widespread attack going on. Since you mentioned that the index.php file on your site was modified, then it would make sense to post the contents of that file along with your question. Then we could probably better understand the nature of the attack and provide guidance. – Kate Oct 15 '21 at 19:14

1 Answers1

1

For Context: This answer was written before any more infos on the incident were available. At the time, it was uncertain whether this was a common configuration issue, a vulnerability in Laravel itself or a commonly used module.

As it is impossible for us to tell what could be the cause for this exploitation. There are several possibilities, such as a zero-day exploit in Laravel itself or a related module, or a widespread configuration issue.

Here are some steps you can take:

1. Take your App Offline. NOW!

Your application is compromised and so an attacker can do as they wish on your server. That includes stealing all your data, compromising all your user data and generally endangering your users.

Take the application offline. NOW!

2. Inform your Users

Inform your users that a security incident occurred and that it is possible, likely even, that user data was stolen. If some of your users are affected by GDPR, you may need to file a Notification of a personal data breach to the supervisory authority.

3. Contact a Professional Forensics Specialist

I know that this step will sting financially, but depending on your setup, contacting a forensics specialist may be a way to find out how they gained entry, what they did and the full extent of the damage.

At any rate, you need to find the source of the breach before you put the application back online. It's as if a fuse burned out - just replacing it won't fix the underlying problem. If you just replaced the fuse and turned on the power again, the next fuse will burn out again immediately.

4. Fix the Vulnerability

Depending on the nature of the vulnerability, this could be done through an update, through a configuration change or any number of ways. The important part is that just removing the web shell won't fix the issue!. That web shell got there for a reason, so before that reason is addressed, don't put the server back online.

5. Wipe your Server Clean

That means full reinstall from a known-good backup, then applying all the necessary fixed before re-deploying your application.

Yes, it sucks, but it's the only way to be sure. Attempting to "doctor around" will likely result in an attacker having continued access to your server. Remember: They tricked you once - there is no reason to assume they can't trick you again.

  • It would be nice if you added the guideline to disable debug mode in case of CVE-2021-3129 – Sir Muffington Oct 15 '21 at 15:43
  • Debug mode only applies to a single vulnerability on a defined Laravel version. MeckMK1 answer applies to any scenario of a hacked web application in any language. – ThoriumBR Oct 15 '21 at 16:38