1
Wedee
Site Hacked... Plan of attack to get running again.
  • 2009/4/22 16:23

  • Wedee

  • Just popping in

  • Posts: 4

  • Since: 2009/4/22


OK, so I was informed by my host that they have shut down my site because they noticed my site was compromised and was now phishing. In talking to their tech guy we located the main offending file. I went thru and deleted all the offending files, and am now sitting with the task of reinstalling and updating to get it back. As well need to make sure I figure out what I need to do differently to secure the site better. I was running protector on a 2.3.2b site, and have now done a ton of reading and wanted to list off the things that I intend (Based upon posts on Xoops.org) to do to secure the site, and see what else anyone may have to add.

I have moved my original (Hacked) site to a different location, and installed a index.html file with general text “We will be back shortly” so once my Host turns the site back on that is what will load.

So here is what I intend to do…

1. Create a brand new database with new name, user, PW
2. Download, unzip and upload a fresh copy of 2.3.2b
3. Run the Checksum PHP routine to verify it was uploaded correctly
4. Delete the checksum PHP and MD5 files.
5. Rename xoops_lib and xoops_data and move them out of the XOOPS folder (I cant move it completely below my htdocs as I do not have access to that portion.
6. Replace the mainfile.dist.php with the protector version located in the XOOPS distribution extras folder
7. Set the various xoops_data folders as listed to 755
8. Add a index.html to all directories missing it containing…. <script>history.go(-1);</script>
9. Run the installer and set up Xoops
10. Verify all folder permissions are set to 755, except cache/, templates_c/, uploads/ are 777
11. Verify that the files are set to 644, except mainfile.php should be 444
12. Verify the site is turned off
13. Install the modules I had installed previously – Same versions for now
14. Copy over my theme and supporting files
15. Copy over any images that were uploaded
16. I am going to use a backup of my database from 3 days prior to the attack, even after searching for any unknown “javascript” entries I would rather lose 4 days of posts then be wrong. To import the backup I am assuming I go to the phpMyAdmin control panel and say import, selecting the backup file I want to use.
a. The questions I have here are;
i. If the name of the new data base is different will it cause any issues?
ii. There are entries in my backup DB for modules I previously installed and then removed (and do not intend on running again), if I don’t install these modules now and then import my backup into my new database will the import crap out because the entries the backup is referring to do not exist in the new blank database?
17. Immediately log into the site and change all “admin” account passwords.
18. Verify all functionality
19. Upgrade XOOPS and any installed modules to the latest versions
20. Verify functionality
21. Open site

There are a few other items I have read that help make the site secure, but as each thread about them had contradicting information and I am interested in seeing if I should do these as well.

The first was in reference to pulling the DB information out of mainfile.php and replacing them with variable, then create a sep file that populates the variables. The argument here was that the only way mainfile.php would give up the password is if a catastrophic error halted the php execution, and that it was not worth the bother to do this as there are still ways to gain the information.

The second was the use of .htacces files in various folders. Can anyone tell me what files / folders I should look at protecting with the .htacces files?

2
ghia
Re: Site Hacked... Plan of attack to get running again.
  • 2009/4/24 7:01

  • ghia

  • Community Support Member

  • Posts: 4953

  • Since: 2008/7/3 1


Last XOOPS version is 2.3.3, you should use this one.
Best is to postpone step 5 until the installation is complete and verified to work (move the two directories and adapt mainfile.php).
i) This is no problem, just adapt mainfile.php
ii) Check the module table and note the id's of the modules in use and the ones to remove. In other tables (eg comments) the records with these unused module id's have to be removed. They should be checked to have only id's of modules in use.

3
Wedee
Re: Site Hacked... Plan of attack to get running again.
  • 2009/4/24 12:29

  • Wedee

  • Just popping in

  • Posts: 4

  • Since: 2009/4/22


Thanks for the reply...

Yes, I intend to upgrade to 2.3.3 before I go live again, but as I was 2.3.2B before the attack I need to install that to restore my DB, and get it running first. (I started to flush out the hacker added / modified files, and determined that based upon the post Here that I couldn't trust I did remove the offending code.)

Thanks for the tip on moving xoops_lib and xoops_data after the install. Could you expand on why you believe it is best to wait till after the install to rename and move them?

I downloaded a sql database editor and it does a much nicer job of formatting the data then notepad. I have a database backup (backup.sql) of the db before the attack, and that is what I would like to restore. If i was to import the backup, does it add or overwite the current data in the database, in other words, can I delete items from the backup before I import? (I really just want to add my user accounts and forum posts back in)

4
ghia
Re: Site Hacked... Plan of attack to get running again.
  • 2009/4/24 14:09

  • ghia

  • Community Support Member

  • Posts: 4953

  • Since: 2008/7/3 1


The XOOPS file check utility can verify that all XOOPS files are correct. It can not detect if excess files (not in use by XOOPS) exists.

Moving xoops_lib and xoops_data is not possible on all server configurations. If that is the case, your installed XOOPS will not run. And if there is a second problem, then it is impossible to start fault determination.

For the SQL, I think it is better to clear the tables and rely only on the data from the backup. Mixing of the new and old data is not a good idea, because module id numbers may vary and they are woven through other tables.


Login

Who's Online

163 user(s) are online (62 user(s) are browsing Support Forums)


Members: 0


Guests: 163


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: May 31
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits