14 Replies - 957 Views - Last Post: 06 January 2020 - 02:06 AM Rate Topic: -----

#1 RobHowdle   User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 48
  • Joined: 03-December 19

Laravel Security

Posted 09 December 2019 - 02:59 AM

Hi All,

So one of the systems I've been tasked with looking after got hit about a month ago with something and the web hosting company shut it down because there were perminant server side scripts being ran. Viewed the error log to find them and removed them, gave everything a scan through and what not and it all seemed good.

Was taking a look at the folders again to look at a Password Reset problem I'm having and find the follow files and folders. Haven't looked anywhere else yet but I was quite concerned when I checked the error log with loads of weird IP's and the log constantly saying things like 'access denied'. I have a feeling whoever hit the site originally landed these files and none of them showed up when it was originally scanned, looks like password changing, data mining sort of stuff.

Any advice of making sure this stuff doesn't keep happening? This is the only time it's happened as far as I know and I didn't design the system or have any involvement in it which is rather annoying but not much I can do about that. I'll be changing all the passwords again since I changed them the first time but after finding this I'm not very trusting in my web host encase it's recorded that password change too.

any tips?

Can't seem to attach an image file due to the server returning and error during upload, weird...

Folder Path: public_html/vendor/phpunit/phpunit/src/Util/PHP
Folders: 3x_beast
home
Template
Files are:
.87.php
aa.php
AbstractPhpProcess.php
api.php
brutecp-icq-741998737.php
brutecp-icq-744324366.php
DefaultPhpProcess.php
findcp-icq-741998737.php
findwhmhas-icq-741998737.php
findwhmhas-icq-744324366.php
index.php
kill.php
king.php
makesmtp-icq-744324366.php
nhagzjery.php
papo.php
raimu.php
raimu1.php
send-icq-744324366.php

And many others in this one folder. haven't check any other folder but I'm pulling the site off the server to stop other users accessing it. Currently I plan to go through each folder and check for files like this but does anyone have any suggestions for a better way of doing it at all?

Thanks
Rob

Is This A Good Question/Topic? 0
  • +

Replies To: Laravel Security

#2 Ornstein   User is offline

  • D.I.C Head

Reputation: 32
  • View blog
  • Posts: 64
  • Joined: 13-May 15

Re: Laravel Security

Posted 09 December 2019 - 03:12 AM

My suspicion is that the app's vendor directory is public - and I know there's a vulnerability in PHPunit which can be exploited under these circumstances. You'll probably find for example that in public_html/vendor/phpunit/phpunit/src/Util/PHP there's a file called eval-stdin.php (which can/will run PHP code submitted in a POST request). If you confirm this is the case and that this directory really can be accessed (e.g. there's no existing .htaccess to block it or whatever) then I'd recommend making it inaccessible one way or another.

As for cleaning up the injected files... do you use version control? I'd guess you're not doing commits on the production server so that would likely help you isolate the new files.

Does any of this help at all?

(It might also be worth mentioning that if the vendor directory is public, other sensitive files/directories may also be public - so that's perhaps something else to follow up on. Really only the app's "public" directory should be... public.)

This post has been edited by Ornstein: 09 December 2019 - 03:15 AM

Was This Post Helpful? 1
  • +
  • -

#3 RobHowdle   User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 48
  • Joined: 03-December 19

Re: Laravel Security

Posted 09 December 2019 - 03:19 AM

That's for the advice @Ornstein that does help. I'll run through all the permissions, I found it strange that the hosting supplier didn't know about this as the server I use at home personally will alert me if there are any "security" issues. As soon as I pulled the site onto my PC I had tons of alerts from ESET for suspicious files. I will check the notes left by the previous developer to see if he had any version control but as far as I'm aware there isn't any. Would be very handy if there was! I've deleted all the files from the server and alerted the client. Hopefully the damage isn't too bad.

Thanks again!
Rob
Was This Post Helpful? 0
  • +
  • -

#4 RobHowdle   User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 48
  • Joined: 03-December 19

Re: Laravel Security

Posted 10 December 2019 - 01:57 AM

Hi there,

Just a quick update, I believe I found the person who planted these files, a quick google of the email address left within one of the files shows this person enjoys hacking and seems to have hacked a few things. There's little bits of code here and there that has found its way into a lot of pages so I'm comparing the stuff from the server to an earlier version I found on the companies GitHub. Only thing is that was last updated about 9 months ago so HOW recent that is I don't know and theres already a couple of bits that have been updated that are not on the GitHub. Just off 40 files so far and I've just got into the vendor folder!

Thanks
Rob
Was This Post Helpful? 0
  • +
  • -

#5 RobHowdle   User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 48
  • Joined: 03-December 19

Re: Laravel Security

Posted 16 December 2019 - 02:45 AM

Hey all,

Just another update, I had a friend of mine who is more experienced in stuff like Laravel than I am, no expert but he's good. He suggested that it could be the PHPUnit that's an issue and looking into it there are a lot more dodgy files in the PHPunit folder than anywhere else, as soon as I pulled it down, my antivirus went crazy and that was the file location that it kept pointing to saying there was suspicious files within the PHPUnit folder.

I am wondering if I can just remove it? I did some research and from what I can gather it is just used for testing but I'm not 100% sure, I'm going through each folder to clean them up for now but wasn't sure if I could just remove it or not. Any advice?

Thanks
Rob
Was This Post Helpful? 0
  • +
  • -

#6 Ornstein   User is offline

  • D.I.C Head

Reputation: 32
  • View blog
  • Posts: 64
  • Joined: 13-May 15

Re: Laravel Security

Posted 16 December 2019 - 04:40 AM

You probably wouldn't be able to just delete the directory without causing problems, but there would be ways to remove it if you really wanted to. In any case, I don't think that's the right solution. Did you check whether the files are/were publicly accessible? Really that's the problem that needs to be addressed. If the vendor directory and/or other directories are public, you could have more problems further down the road.
Was This Post Helpful? 0
  • +
  • -

#7 ArtificialSoldier   User is offline

  • D.I.C Lover
  • member icon

Reputation: 2494
  • View blog
  • Posts: 7,551
  • Joined: 15-January 14

Re: Laravel Security

Posted 16 December 2019 - 08:50 AM

Also, with things like this, one or more attackers have definitely installed back doors that will let them run arbitrary code, so if you miss anything they'll probably just do it all over again. You need to find and remove everything and close the original holes, if you miss any of their backdoor scripts it's all just going to come back again. They can also edit and add code to existing legitimate files, so you need to consider that also. Checking the last modified date and time on the legitimate files there might help point to changes they've made.
Was This Post Helpful? 0
  • +
  • -

#8 RobHowdle   User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 48
  • Joined: 03-December 19

Re: Laravel Security

Posted 17 December 2019 - 04:05 AM

Hi all,

Sorry for the late reply, endedup moving offices yesterday and the IT guys were held up patching us in...

Still looking through the files as I've found plenty of dodgy looking files in most folders. I have an older version (not too old though) of this system that I'm comparing it with as well as a GitHub Repository. Only issue is there is one or two parts that the latest version has that the others don't as they weren't updated by the last developer for some reason. I'll check the permissions as soon as I stick it live again. Whilst it's offline I right clicked the Vendor folder and that DOES say it's read only but I'll double check it when I upload it :)

thanks again
Rob
Was This Post Helpful? 0
  • +
  • -

#9 Ornstein   User is offline

  • D.I.C Head

Reputation: 32
  • View blog
  • Posts: 64
  • Joined: 13-May 15

Re: Laravel Security

Posted 21 December 2019 - 02:24 PM

View PostRobHowdle, on 17 December 2019 - 04:05 AM, said:

I right clicked the Vendor folder and that DOES say it's read only


Just to be sure: There's a difference between "public" and "read only". The important part is, can anyone access those files via the web browser?
Was This Post Helpful? 0
  • +
  • -

#10 RobHowdle   User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 48
  • Joined: 03-December 19

Re: Laravel Security

Posted 23 December 2019 - 01:25 AM

Hi there,

As soon as I've finished checking the files and stick them back on the server I will double check this, I'm still finding a lot of bad files hidden in folders and subfolders and since the latest version I have backed up from a previous developer isn't actually the latest version I don't want to restore to that version and possibly loose certain things.

Thanks
Rob
Was This Post Helpful? 0
  • +
  • -

#11 RobHowdle   User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 48
  • Joined: 03-December 19

Re: Laravel Security

Posted 27 December 2019 - 02:54 AM

Hi all,

hope you all had a good christmas, would it be against the rules if I posted a list of the "bad" files and where they were located? I wrote them down purely so encase this happened again I had a bit of a cheatsheet to know where to look first. Figured it might be handy if anyone else had a similar issue or the same issue by the same person. Clocked a lot of bad files in various folders a thought it could be handy if there was a list for anyone facing a similar problem :)

If it goes against any rules that's fine :)

Thanks
Rob
Was This Post Helpful? 0
  • +
  • -

#12 CTphpnwb   User is offline

  • D.I.C Lover
  • member icon

Reputation: 3826
  • View blog
  • Posts: 13,946
  • Joined: 08-August 08

Re: Laravel Security

Posted 27 December 2019 - 02:31 PM

You'd probably get further by creating a separate install of the version of Laravel that you're using and compare against that. It might be a good idea to add to that version the known legitimate files from your current code, and get that working.
Was This Post Helpful? 0
  • +
  • -

#13 ArtificialSoldier   User is offline

  • D.I.C Lover
  • member icon

Reputation: 2494
  • View blog
  • Posts: 7,551
  • Joined: 15-January 14

Re: Laravel Security

Posted 30 December 2019 - 11:07 AM

Yeah, at this point the most efficient thing to do might be to get your clean repository, even if it's an older version, download the entire current site, and do a diff on the two of them to find the differences. Copy any legitimate changes to the clean repo, throw out the rest, commit the repo, and use that version.
Was This Post Helpful? 0
  • +
  • -

#14 RobHowdle   User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 48
  • Joined: 03-December 19

Re: Laravel Security

Posted 31 December 2019 - 01:20 AM

So another update, I've cleaned all the files. Originally I was under the impression that the stuff on our companies GitHub wasn't the latest version as I was told the last dev had "made small tweaks" and not got round to reuploading them to the GitHub Repository. Because of this I spent a month ish cleaning the files and folders one by one, 27,755 files by the way :) Nice fact to know haha spent all day yesterday trying to get the issue with the Password Reset not working and got that irritated I ended up copying the last version from the GitHub. Realising what I'd done, I quickly stuck it on my local server to check it to find that (as far as I can tell) the versions are actually identical. There is nothing missing or any errors so far!

It's good in a way but very annoying because I could have just saved myself a month of work haha and that ladies and gents is why handovers between developers and documentation on projects is key! I'm at a point now where I can stick the system back on the actual web servers however just to be sure I'm waiting until the client comes back from the Christmas/ New Years holidays so they can change the password for the server and their user passwords as I'm not sure if/ how much information these infected files may have taken but I do know that a couple of password resets were done with the infected files in place so just to be on the safe side, I don't want to be doing this again!

Thanks for all the help everyone!

Rob
Was This Post Helpful? 0
  • +
  • -

#15 RobHowdle   User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 48
  • Joined: 03-December 19

Re: Laravel Security

Posted 06 January 2020 - 02:06 AM

Hi all,

Just an update, I believe the issues are now fixed with regards to the security issue, just to sum up, I found some very old wordpress files that were on the server for some reason so I can only assume at some point a wordpress site was here and looking at the last modified date of the files, it makes it highly possible they are very out of date and therefore would have made it easy picking for a good hacker. Also the file permissions for some of the folders seemed to have been set really strangely and this could have been another reason somebody gained access.

On another note the issue I was facing of being unable to reset the users password has now been resolved, I was clicking the reset password and it was registering in the database but not sending the email on the live version but for some reason on the version I run on my local sever for testing it all worked perfectly fine. Again whilst I'm not 100% sure what the reason was for not being able to get it to register the reset request, I replaced that part of the code with again an identical copy from a Git repo and it worked but then I was faced with it not actually sending an email. Spoke to the web hosting company and double checked the mail server settings and they were all correct.

Turns out the problem the whole time of not sending an email but registering in the database was down to the Mail Encryption setting in my .env file. Originally it was set to TLS but on the local server it's set to SSL. Now I did some research because I wasn't 100% sure and to my surprise a few people have actually reported a similar thing that the TLS mail encryption causes problems sometimes. I'm not sure as to why but for I did quite a bit of testing on this and every time the Mail Encryption is set to TLS the password reset emails don't send at all but they register in the database. Changing to SSL fixed it straight away! How strange! Just need to get the client to sort out an SSL certificate now as that wont help things haha.


Thanks for all your help folks!
Rob
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1