Hack issue. Please help.

Quote from: jonasdroste at Aug 01, 2018, 08:44 PM

It's from 16th July. Don't know what to do know... Files appear again and again. Restores don't work. Google already told me that I was hacked and lots of 404 pages appeared. What a mess!

Have you reset all FTP and control panel passwords? Is 16th July the oldest backup you have?

Here is how I managed to clean my website. Did that a couple of days ago and it works.

1. Update all packages/ plugins in ModX Manager
2. Download all website’s files to computer and duplicate / backup that folder
3. Be sure all files are completely downloaded and then delete all files from your server
4. Change FTP password of our server (important!)
5. Download latest ModX version to your computer
6. Copy all ModX files to duplicated website’s folder and replace all files/ folders that exist
7. Most important part! Delete everything in your duplicated website’s folder that could be corrupted: also look in your own folders (e.g. images folder) - when there are files or even folders that don’t belong there (e.g. index.php in images folder) or files with cryptical names like „ao49l8bg87.php“ —> delete that! Sometimes files appear that look like wordpress files but have a different spelling/ spelling mistakes. If you have not installed wordpress: delete everything that isn’t also in a freshly extracted modx installation folder. Also delete everything in assets folder or other remaining folders, except your own files (e.g. template’ sfiles). But be sure that in the remaining files there is no code that doesn’t belong there. Mostly corrupted files have cryptical code on top like: .$eroxhb[20].$eroxhb[18].$eroxhb[29].$eroxhb[18].$eroxhb[9].$eroxhb[3].$eroxhb[10] or /*36ab4*/ @include "\057is/\150tdo\143s/w\160112\064144\070_A1\126DGB\1117F6\057www\057ena\…; If you are not sure if you should keep the file: look if it’s in freshly extracted modx folder. If you cannot find the file, delete it. All plugin/ extra’s folders etc. will be recreated later automatically. Don’t be afraid to delete something. In case you need something you deleted: you have a backup!
8. Make a data base backup and save it on your computer. Then delete everything inside your online data base. (not in the backup ;-) )
9. Change data base password (important!)
10. In your original (corrupted) website’s copy, go to „/modx/core/packages/„ and copy ONLY the ZIP files (so none of the extracted folders) of your original websites folder EXCEPT core.transport.zip
11. In your duplicated website’s folder, go to „/modx/core/packages/„ (there should be only the core files) and paste copied ZIP files to this folder
12. Now you should have a completely fresh ModX Websites Setup —> upload that to your server.
13. yourwebsite.com/setup/ —> make a new installation, but DON’T delete setup folder and remember you changed your data base password
14. Now you have a fresh install but of course your contents are gone
15. Delete everything inside freshly installed database again
16. Optional: check or update DB password in cor/config/config.inc.php file
17. again: yourwebsite.com/setup —> choose „Update installation“ and checkmark „delete setup folder“ at the end
18. Login to ModX Manager and change all Passwords of all users (!important)
19. Go to ModX Manager —> Packages and reinstall all Packages. I had to delete some of them and download them again because there were some installation issues. You see that when installing the package and there is no „content/ info texts“ for this package.
20. Check if some folders or files of your original websites are still missing. If so, you have to check every single file, if it’s corrupted before copying them to your freshly installed ModX website

I wonder if your website is still clean?
My site was infected several times now, so looks like I have to clear it more thoroughly now. So I plan to use above steps.
But is is not clear how I recover the contents after we delete the data base in step 8.
Is there maybe a step missing after step 15?

This process is a lot more work than is needed.

I'm reworking a document on this but essentially to clean sites we use the PHP Malware Scanner and Ai-Bolit to scan sites to find malicious files/shells and backdoors. Once you find the naughty files, you remove them.

You can essentially remove the entire core and the Manager directories (if you don't use custom lexicon files). You must keep /core/components/ /core/packages/ and /core/config/config.inc.php. You'll also need to keep your config.core.php files. In /core/packages you can also delete the directories and leave the transport packages. Once those dirs are removed you should be able to fetch a clean install of MODX and use rsync to replace missing/altered files. You can then run setup in upgrade mode.

With regard to the DB, I've not seen any SQL injections with the recent hack. I have only seen SQL injections of users and bad plugins/snippets in the hack of sites on 2.2.15 and below.

FWIW, UpdgradeMODX will install or replace all the MODX core files for you, though it won't delete any extra files left by the hackers and it won't touch the core/components/, core/packages, or any of the config files.

Quote from: Gerben at Oct 02, 2018, 01:42 PM

I wonder if your website is still clean?
My site was infected several times now, so looks like I have to clear it more thoroughly now. So I plan to use above steps.
But is is not clear how I recover the contents after we delete the data base in step 8.
Is there maybe a step missing after step 15?

Yes, all my websites are still clean. So the effort was worth it.

I found this thread via a search for a bunch of strange hits Analytics was recording (like cleogiue, cryptologist_eranist.html, etc.). I didn't actually find any strange files, I think this was just a bot attempting to access those pages, but I decided to do a cleanse just in case. (And install LogPageNotFound so I wouldn't be guessing next time.)

The method I used is similar to what jonasdroste posted, but somewhat simpler, so I wanted to share. Another nice thing about this method is that if something goes wrong, it just takes a minute to put your site back the way it was if necessary. Also, this process seems fairly forgiving. This isn't the first time I've done this to a site, but due to the late hour, I kind of missed a couple of things. I'll note those so you can point and laugh, um, I mean, so I can describe what I did to fix the mistake. Note: This method assumes you don't have a compromised database.

So here's how I do it. Don't be put off by the length, it's really a pretty quick and easy process. (I think this took me about 10m.) I just wanted the instructions to be as clear and detailed as possible, and friendly for beginners and others who aren't comfortable wiping a live site.

1. Back up your database.
2. Change the password for the site's database user.
3. Back up your non-MODX files if necessary. I didn't need to in my case. The client doesn't have access to upload anything, so all the site files are on my computer, and in a later step, I just re-uploaded them since I know they're clean. If you don't have copies of all of your site files elsewhere and will need to use the ones on the server, AFTER you make the backup, check all of those directories and delete anything that you know isn't supposed to be there, using Google if you aren't sure. Actually, Googling everything suspicious you find is a good practice so you know better what you're dealing with. You could have multiple infections. (Don't worry, this method will still clean them, as long as they didn't get into your database.) Also take this opportunity to do some cleanup if you find things uploaded that you're no longer using, so you don't end up with outdated, potentially vulnerable code hanging around.
4. Download ./core/config/config.inc.php and rename it to something like config.inc.php_orig.
5. Prepare to do a new, clean install of MODX, the same version you currently have. (Upgrades come later.) Don't install yet, just be prepared. The next step breaks your site, so once it's time to reinstall, having this done will get you back live as quickly as possible. If you're installing via command line, make sure you have the file downloaded and a new db and user created. I went the simple route and used CPanel's Softaculous since it's pretty much a one-click install and it creates the new db and user for you. (Although it also led to my first oops. My site was on v2.7.0 and I didn't notice that it was giving me the shiny, new v2.7.1 that just came out. This led to a bit of weirdness, thankfully easy to fix. (Details below.))
   IMPORTANT: You won't actually be using the new database and its user, but make sure whatever process you use creates ones for the new install and doesn't overwrite the existing ones!
6. Go into the site's manager and uninstall (don't remove) all of your extras, then log out.
   Note: I forgot to do this so I ended up with a broken manager later on, but it was easily fixable by editing the database. (Again, details below.)
7. Rename all of the MODX directories. You can do it via (S)FTP, I did it via command line, so for anyone who wants to copy/paste using the names I used, make sure you're in your site's root directory (./public_html, for me), or the appropriate subdirectory if you don't have MODX installed in root, and:
   # mv ./assets ./assets_old
   # mv ./connectors ./connectors_old
   # mv ./core ./core_old
   # mv ./manager ./manager_old
8. In the site's root directory, back up and then delete config.core.php, ht.access, and index.php. (May be optional for you, but Softaculous complained when it found them there.)
9. Install MODX into the same location as the original install. Check the home page to make sure it brings up the default for a new install, and make sure the manager page loads. This rules out permissions errors if you run into problems later.
10. Download the new ./core/config/config.inc.php and make a backup copy (in case you need to revert and don't want to rely on your editor's undo feature). Modify the database info to match the info from the original version you downloaded earlier, then re-upload the new one. You'll be changing the variables $database_user, $database_password (don't forget to change this to the new one), $dbase, and $database_dsn. Also change $table_prefix and $database_connection_charset if your installation method set them to something else. Your shiny, clean new MODX install will now be connecting to your original site's database.
11. Upload clean copies of your site files into ./assets/, or restore them from ./assets_old if you have to, double-checking again to make sure they're clean.
    IMPORTANT: Do not restore ./assets/components/
12. COPY all of the zip files in ./core_old/packages/ except core.transport.zip to ./core/packages/. Just the zip files, ignore the rest.
13. Log into your site's manager. You may get a blank page. Don't panic! Here's how to troubleshoot:
    
    • If you forgot to uninstall your extras like I did (sigh), it could just be an issue with the manager home page. Try going directly to the package manager page:
      http://www.yoursite.com/manager/?a=workspaces
    • If you can't access that either, you'll need to disable them in the database. I use phpMyAdmin. (NOTE: See my question below, these instructions worked for me, but may not be entirely correct.) Go to the modx_transport_packages table, and update the records, setting disabled to 1. You can do them all at once, or one at a time if you think you know what's causing the problem. If you have UpgradeMODX installed, start with that one, that fixed it for me.
      QUESTION: Is that actually the best method? I know deleting the records entirely would work, but removing them from the package manager list will make reinstalling them a lot more of a pain. Also, after reinstalling my extras, I see that some still have disabled set to 1. But all of them are working. What exactly did changing this field do besides make UpgradeMODX stop crashing my manager?
    • If disabling all of your extras doesn't work, double-check ./core/config/config.inc.php and make sure you correctly updated all of the db values I listed, and, assuming you changed it, that you're using the new password for the db user, not the original.
    In my experience so far, the above should fix any blank manager problems caused by this process. (If anyone finds any others, let me know and I'll update.) Otherwise, there are other things that can cause a blank manager page even on a completely new install. Search the forums for tips, or just wipe the new directories and database and try again, double-checking to make sure you're installing the same version you already have installed. Or if you'd rather try a different method, delete the new directories, undo step 7, re-upload the files you deleted in step 8, update the password in this version of ./core/config/config.inc.php, and you'll have your original site back in less than a minute.
14. So, once in the manager, go to the package manager. It'll show your extras as being installed, even though they aren't. You can try just reinstalling them, but I went ahead and uninstalled them first. Note: I got errors when reinstalling UpgradeMODX, I assume because I was using the v2.7.0 database with v2.7.1. But thankfully it did install and work properly. If you don't already have UpgradeMODX, install it.
15. Using UpgradeMODX, reinstall the MODX version it tells you that you have installed. (After doing this, I again uninstalled and reinstalled UpgradeMODX, this time, with no errors.) You probably only need to do this if you do what I did and install the wrong version of MODX, but it can't hurt.
16. Check your site, it should now be working just like before, minus any malicious intruders. Now upgrade to the most recent MODX version if you're not caught up. (If you're multiple versions behind, follow the instructions and don't upgrade directly to the latest. Do it in stages.)
17. Almost there. Go to the Error Log (Manage->Reports->Error Log) and clear it. Open the manager in a new tab/window, click around for a bit, and refresh to see if you get any errors. Troubleshoot if necessary. Then clear again, click around the front-end of your site, refresh, troubleshoot if necessary. (Unfortunately I can't give any real advice here except to remind you that Google is your friend. Errors/warnings at this point are probably specific to your site. For example, I was getting one because some code in one of my snippets has been deprecated. I'm also getting one related to modMenu, but I need to research that, I don't think that's my fault.)
18. Finally, once you're sure everything is working, back up all the *_old directories and delete them, and delete the dummy db and user created with the fresh install. If you installed via Softaculous, update the installation info with the correct db name and user. Also, I like to delete everything in ./core/cache/ once all the fixing and upgrading is done to make sure nothing weird is left over.

Congrats, you should now have a pest-free site.

Disclaimer: I'm writing this after getting pretty much no sleep last night, so everyone please let me know if anything sounds confusing or I left anything out or if any of my advice is just plain bad. Also, the whole point of me cleaning a site this way is to make it as easy and idiot-proof as possible. (Says the idiot who forgot to uninstall the extras and failed to notice a new version number...) So if you see anything that can be simplified, let me know. On the flip side, I've only done this on fairly simple sites. If there are other problems that could come up on more complex sites, again, let me know and I'll update the instructions.

Dealing with a hacked site, or even a potentially-hacked site, can be a nightmare. This may not be the best method for everyone, but so far I've found it to be a quick and easy method for me, hopefully some of you out there will find it useful. And again, sorry for the length, like I said, I just wanted to be as clear and detailed as possible, with generous amounts of hand-holding, given that I'm talking about how to completely wipe a live website, something that still makes me nervous and I've been dealing with stuff like this for years.

Thanks for posting that. I think it will help a lot of people.

I would only add that you should then rename your manager, connectors, and assets folders, and move the core directory above the web root as described here.

Do you mind if I make this into a blog post (with credit to you), to make it easier to find?

Quote from: BobRay at Feb 19, 2019, 08:59 PM

Thanks for posting that. I think it will help a lot of people.

I would only add that you should then rename your manager, connectors, and assets folders, and move the core directory above the web root as described here.

No problem! I've gotten so much help from the community over the years, I've felt bad that I haven't had time in a long while to hang out on the forums and try to give back like I used to.

About the renaming and other hardening methods, I've used them quite often and definitely support helping people with implementing them. They certainly work. I've made a few ARG sites that players were actively trying to hack in any way possible (it's kind of expected in some cases) and MODX has always held up perfectly! But I was writing this more for less experienced people who may not be comfortable even working directly with site files, and who are just wanting to quickly get a compromised site fixed as quickly and simply as possible, without having to redo the database or mess with anything else any more than they absolutely have to. (Although looking at it now, I probably should have stayed away from command line instructions and put a bit more detail about changing db values given that goal. I was a tech writer/editor in a past life, I'll blame sleep deprivation for my fuzzy audience targeting...)

That aside, I felt like my word count on that was already far past reasonable, adding in more complicated things would end up being, well, more appropriate for a blog post...


Quote from: BobRay at Feb 19, 2019, 08:59 PM

Do you mind if I make this into a blog post (with credit to you), to make it easier to find?

I don't mind at all! I'm actually quite honored you'd ask. Feel free to add/edit/delete as much as you feel necessary. And by "feel free" I mean please do whatever you want/need to make my sleep-deprived ramblings more coherent, correct, and complete.

And maybe you can clarify what the disabled field in the modx_transport_packages is supposed to do? I guess at the very least you can clarify why it fixes the issue with UpgradeMODX. Either that, or I've given you a bug/feature to track down. ;-)

Speaking of blog posts, I've been meaning to contact you to request you put some type of "tip jar" on your site, like a PayPal link... like the one I just now found there, never mind. I usually end up on your site via direct searches. I have clicked around quite a bit, but never noticed the side link until now. (And actually misinterpreted it when I did as being three separate links...) My point was going to be that I end up on your site SO often when I'm searching for MODX help that I've started wanting to leave you tips when your posts help me out. My point now will instead be to advise you to decrease that line-height and add a graphic or something to make it stand out more. Although much more than that, put the link on your blog! I occasionally land on your MODX pages from searches, but I always read your blog posts and at least a couple times sat down and scrolled through start to finish. So many times I wished for a tip jar that was there all along... So yeah, make that more prominent so people like me know how to easily give you money!

BTW, you mentioned credit, and since I'm now poking more parts of your site, I just wanted to casually mention that I develop almost exclusively in MODX (unless practically forced at gunpoint) and have since way back before Revo was a thing, and have a dedicated server for hosting my clients. I think I could be considered a "MODX-Friendly Host." ;-) Although no pressure, I see how short that list is. Interesting thing, Glowhost is the company that maintains my server, good choice! (And god, don't get me started on EIG, they ruined my absolute favorite alternate hosting company. They were up there with Glowhost as far as reliability. I once worked with a consulting firm on a few sweepstakes for companies like Luzianne and Hostess that were hosted with them and they were getting multiple entries a SECOND, millions in total, lightning fast, no problems at all. I tried them once after EIG got them and they couldn't even keep a low-traffic, single-page site from going down multiple times a day, every single day from the very first day until I cancelled. When I first heard about EIG and learned about what they were doing, even before my own experience, I opened a support ticket with Glowhost specifically just to beg them not to sell out to them. Thankfully, they VERY firmly assured me I had nothing to worry about. I don't know what I'd do if they took Glowhost away, I've been with them well over a decade now and EIG has managed to snatch up and ruin every other host I've ever tried except Godaddy. (Suddenly thinking I should add "not owned by EIG" to my list of hosting benefits...))

Sorry. Massive sidetrack. Long days + little sleep = Coder rambling far, far off-topic.

Quote from: BobRay at Feb 19, 2019, 08:59 PM

I would only add that you should then rename your manager, connectors, and assets folders, and move the core directory above the web root as described here.

Reading over this thread again, I realized I also didn't cover important steps that should be done before starting the new install, like checking who has (S)FTP access to the site, making sure there are no extra mysterious users, making sure everyone has good passwords and changing them after an incident, etc.

Our server has FTP disabled completely and only allows SFTP/SSH access via key authentication, so adding instructions for that didn't even occur to me since it's not an issue for us. But for anyone outside our obsessively locked-down little speck of the internet, checking and tightening (and monitoring, if possible) access to the site itself should definitely be the first step. Doesn't matter how well you clean your site if someone can just log back in and upload the malicious content again.

Same with MODX users who have access to the files via the manager interface. We use really strong admin passwords, and use media sources to limit filesystem access for the clients who need it, but limited access is still access and a malicious file is just as malicious in ./assets/images/ as it is anywhere else. (And limiting allowed file types only helps until someone finds some new way to exploit one of those types.)

Has anyone made a plugin yet that sets requirements for user passwords beyond min length? (For the manager interface, I do seem to remember Login provides that feature.) When I create accounts for clients, I create them with strong passwords, and while I don't want to take away their ability to change their passwords if they want, it pains me to think of how often my long strings of letters, numbers, and special characters probably end up turning into something much closer to password1. In those cases, you can't really expect much more from higher min length requirements than password11111111.

Related, I've not yet moved to trying this method:
https://xkcd.com/936/
but I still run into enough sites that take issue with one character I like to use in passwords that I know from the resulting errors that spaces are still very often not allowed. (What really horrifies me are sites that still only allow letters and numbers - like MY BANK.)