2

I recently had a breach on my site (laravel). I got aware of it after I tried to pull the code from github and found out that some files were modified.

The files modified were mostly storage - logs/cache and index.php had error_reporting(E_ALL) in it.

And I am not sure what happened and like to know if there's a way an attacker can access the server through the site and also what precautions I can take to mitigate these kinds of scenarios.

I researched a little bit and found out about these methods. Can anyone explain which method could possibly give access to an attacker to actually modify code files:

Cross Site Request Forgery - I dont understand much about how this works.

Cross Site Scripting - There are very less users using the site at this point and authorization & authentication is in place.

Local File Inclusion - Laravel uses namespaces and no such inclusions is made directly is it still a concern then?

Remote File Inclusion - Laravel uses namespaces and no such inclusions is made directly is it still a concern then?

Session Hijacking - PHP Sessions were not in use as it was a api based service and used jwt token

Session Identifier Acquirement - PHP Sessions were not in use as it was a api based service and used jwt token.

SQL Injection - All the db queries uses laravel eloquent so there might be no sql injection.

schroeder
  • 123,438
  • 55
  • 284
  • 319
php.prg
  • 21
  • 3
  • 2
    If a site allows uploading files and doesn't appropriately whitelist paths that can execute CGI scripts, then someone may upload a polyglot file which is seen as an image file to the filter that allows or denies uploads, but as an executable script to the server when accessed later. Is that what you're asking about? – forest Mar 07 '21 at 08:33
  • 1
    This question cannot be answered without doing an in-depth analysis of your server setup and of your code. First, such in-depth analysis is too broad and therefore off-topic. Then there are not even enough information for this, i.e. basically the only information are that you use laravel. I recommend that you get a local expert to look at your setup or maybe let others manage your system in the first place. – Steffen Ullrich Mar 07 '21 at 09:05
  • 1
    Congratulations! You have now learned the importance of application security, and it sounds like you have done it before you were out in charge of a multi-million dollar system or large amounts of user data! Do yourself a favor and learn the most important lesson: if you throw code and infrastructure up without considering basic security needs, you *will* be hacked. Time to start training yourself on application security! – Conor Mancone Mar 07 '21 at 13:12
  • @ConorMancone I am just a part of the team but i am concerned and like to know if the attacker was able to enter via the site or some other way. If they got through the site then i want to learn all the ways to fix before this happen again. I've edited the question with what i've researched so far, would you like to help. – php.prg Mar 07 '21 at 13:58
  • @forest i dont have knowledge about this, if someone is able to upload a polyglot file, How they can able to run it? – php.prg Mar 07 '21 at 14:02
  • "How did this site get hacked?" -- there is no way for us to know. "How can a site get hacked?" -- there is no way for use to answer all the possible ways on a Q&A site, – schroeder Mar 07 '21 at 14:33
  • @schroeder yes there are many ways a site could be hacked, but i was only referring to certain methods that i further edited. Don't know why you have to close the question, but anyways i do get some valuable insight from these people to go in the right direction and harden security of the site. – php.prg Mar 07 '21 at 14:54
  • 1
    @php.prg: so far you've listed several techniques which might lead to a problem and several which don't. You completely ignored though that the site could have hacked by other means apart from issues in your application, like insecure or stolen access credentials for SSH or the admin interface, bugs in the admin interface, other applications on the same server, insecure hosting ... . – Steffen Ullrich Mar 07 '21 at 17:30
  • @SteffenUllrich yes there might be other methods like you described but there are other people to handle that, i just want to get knowledge about the ways an attacker can get access to the system through the site directly. That way i can get an idea to fix those loopholes. – php.prg Mar 07 '21 at 18:57
  • 1
    @php.prg: Like I said: the question cannot be answered without in in-depth analysis of your code - which is off-topic. There can be for example logic errors which allow unauthorized access. There were also [various security issues in the laravel framework](https://snyk.io/vuln/composer:laravel%2Fframework) in the past. – Steffen Ullrich Mar 07 '21 at 20:39

2 Answers2

3

Via uploading a file and executing it. Review uploads, php enabled functions and use 'noexec' (in UNIX/Linux) mount option on filesystem. If your app must execute local binaries, create a regular job to review which binaries are available to the app. Think about using chroot or namespaces for PHP app.

Jiri B
  • 151
  • 3
1

Yes there is an option the attacker accessed the files and modified them. Check log files on the server which files were modified and how, compare them because probably he left an backdoor so he can come back later or modified some files in a way so he can do something malicious, also check for unknown files a.k.a "Shell" which attackers use to gain control over the system. You can prevent this by securing that all upload forms (if you have) do not allow .php .asp etc file extensions so none can upload an shell or something similar. If the attacker enabled the error reporting probably he was looking for more vulnerabilities in the code.

mrSotirow
  • 152
  • 1
  • 3