admin/common/login.php hacked

Hello, On Oct. 20 someone managed to hack our OpenCart install. Here is what the server techs had to say.
We scanned the domain logs relative to when the files that were injected got changed, and here's what we've got: web.php was POSTed against when /home/........./public_html/enroll/admin/controller/common/login.php was submitted.

Another message from our server techs had this information.
Firstly an strace of the process generated by the script /home/.../public_html/enroll/admin/index.php was performed. It was found that the following system call was being made which was taking a large amount of time to complete. It appears to be sending outbound traffic to the IP address "198.46.205.125".
22:52:10.583479 connect(8, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("198.46.205.125")}, 16) = -1 EINPROGRESS (Operation now in progress)

Next it was found that in the script /home/......./public_html/enroll/admin/controller/common/login.php the following malicious code had been injected.

It looks like this could have been used to siphon passwords and send them to a remote address.


I don't know how they managed to put the web.php page on our server. Any ideas?

We have run several scans to make sure there is no ore more malware, we have checked our databases and can't find anything that has been corrupted.
As soon as we found the problem (a couple days ago) we put the site in Maintenance mode and deleted the malicious code. We have also completely replaced the entire public_html with a copy from before the breach. We changed our usernames and passwords. At this point I have also changed the name of the admin folder and put it behind a .htaccess/.htpassword. Before this happened we already had ssh and sftp etc locked to specific IP addresses. The contact form and the returns forms already had captcha. I thought we were fairly secure, but now I am worried about other potential sources of security breaches. Is there anything else I should do to secure this OpenCart from hackers?

Sandra King

Well, this Page Code has not much do with OpenCart, it's more a Mix of some Journal
Theme and something else, and to use some 'regular' user accessable Pages in an Admin
Section is also far away from the OC way of doing things:
https://floridarealestateschool.com/enr ... in/web.php
So, you probably need a Professional, since no-one else would be able, to be of help,
and if a commercial Software, like a Journal Theme, is part of, it's also not something,
to be handled in this 'free' OpenSource specific Forum either, according to the rules.
Sorry for the bad News
Ernie

There is another post with a similar hack as they seem to use the same email address. The technique used in should not be possible on version 3, but it may give you other ideas of things to check. Such as additional payment options.
viewtopic.php?t=147282

As to ways that they could of uploaded web.php. There are a few I can think of.

Uploaded via FTP using a week or stolen password. Probably the most common. There is malware out they that steals passwords for popular FTP apps. Check your FTP logs for any unusual activity. Your host should be able to provide you with these if you can not access them in your hosting control panel. If you've restricted by IP it's probably unlikely, but check the logs and remember to change FTP passwords for all accounts, including your main hosting control panel login.

Via vulnerabilities other web applications on your hosting. Are you running anything else on the server? Is everything up to date?

Via vulnerabilities in your theme or other third party extensions. Sadly the quality of some extensions and themes is quite poor (although it's usually XSS or SQL injection). Are yours update? You could ask the authors if they have patched anything since you purchased.

Another option would be a problem with your host. If it's shared hosting, maybe another account has been compromised allowing them access to all accounts on that server.

Finally it could be a problem with OpenCart itself. Things to look for are extra admin accounts you didn't create, your password changing when you didn't change it, etc. Being sent links to your own stores admin.

If you want to try and track the root problem. Going through your web access logs at around the time before you noticed the hack, is one way. Look for any of the IP address used to access the hacked and uploaded files. Also look out for any access to your admin (or other web apps) from IP addresses that aren't yours. And just anything suspicious.

I dealt with this same hack yesterday. In my thread, I explain how I fixed it (but was unable to figure out how it happened in the first place).

viewtopic.php?f=202&t=207977

JEfromCanada wrote: ↑

Fri Nov 02, 2018 4:49 pm

(but was unable to figure out how it happened in the first place)

Assuming you've changed your passwords and you haven't used them anywhere else, perhaps you could share them so we can see if they were secure?

We're finding that brute force attacks are getting more sophisticated and passwords that used to be considered safe, are not any more:
https://www.antropy.co.uk/blog/are-pass ... rs-secure/

paulfeakins wrote: ↑

Fri Nov 02, 2018 6:31 pm

JEfromCanada wrote: ↑

Fri Nov 02, 2018 4:49 pm

(but was unable to figure out how it happened in the first place)

Assuming you've changed your passwords and you haven't used them anywhere else, perhaps you could share them so we can see if they were secure?

We're finding that brute force attacks are getting more sophisticated and passwords that used to be considered safe, are not any more:
https://www.antropy.co.uk/blog/are-pass ... rs-secure/

Thanks for sharing

Some time ago Journal theme was silently patched because of a security issue.
Update your theme or move to anther one.

@agatha65

I'm using the latest release of Journal2's 2.x series. It was downloaded in August 2018.

If you have any information about which file(s) were patched, I could check the source to see if I have the latest version. All of the recent updates to Journal 2 theme only reference updates to 3.x components. Are you saying there's an update in the 2.x portion of the recently updated files that was not properly referenced in the change log?

** EDIT **
I have just done a byte-by-byte comparison of the OpenCart 3.x folder of Journal 2 version 2.16.8 from the initially released file of June 2018, against the same folder bundled in the most recently released 3.0.12 release, and those folders are IDENTICAL. So, any silent update to the Journal 2 theme would have occurred before version 2.16.8.

@khnaz35,

The employee passwords used on this site won't win any entropy awards, as they are relatively short (though obscure). A brute force attack, if not rate limited, would be able to break them in a relatively short time. The superuser password (mine) is significantly longer and would therefore be quite a bit less likely to be hacked. The hosting account itself has a very long random series of characters and would be much more difficult to breach.

Having said that, I have taken the "discontinued" passwords and run them through Troy Hunt's compromised password database, and none of them show as having been compromised.

Hi guys, thanks for all the feedback.
I have spent the last few minutes testing my old (no longer used) passwords and emails on the mentioned list. None of the passwords are on it, but several of my older email addresses are. Luckily I have already changed the passwords associated with those email addresses and the sites that were compromised.

We are using Journal on that site, but I don't see how that affects the admin login which is in the default theme. I will definitely be patching his Journal theme, and I have removed all the unused payment types just for safety. At this point the site owner seems satisfied that he is secure again, but has asked me to let him know if any recommendations that come up in the forum.

@sandraolt,

Does this mean the site had been totally cleaned and verified working? Did you find any records in the "orders" table that were identified as using the authorizenet payment method? If so, those customer's card numbers are now compromised. Same goes for pp_pro (thankfully, we used pp_standard, which was not compromised).