By

The Blame Game

Major Malware Outbreaks Evade Anti-Virus Protection

A report released on July 14, 2009 states that “Several successive and massive malware outbreaks caused a spike in malware that was undetected by major AV engines.”

In Commtouch’s Q2 Report available here , which covers the analysis of over 2 billion emails and Internet transactions, they also claim:

  • “Business” was the website category most infected with malware
  • An average of 376,000 new zombies were activated each day with malicious intent

Amir Lev, Chief Technology Officer of Commtouch said that for the last 18 months anti-virus (AV) engines used many generic signatures, which were effective at blocking malware. However, malware writers and distributors introduced new variants which are immune to these generic signatures.

This time period coincides with the infection of 1,000s of websites with gumblar, martuz and iframe malscripts which then received Google’s moniker of “This site may harm your computer.”

The Blame Game

Answering many, many blog and forum postings from disgruntled website owners and developers who’ve been the victim of these recent gumblar, martuz and iframe infections, it’s been our experience that quite often the thought process of the victimized website owner follows this path:

  1. The website owner or webmaster receives an email from Google notifying them that their site is infectious. Google rarely (if ever) is wrong so they immediately slap all SERPs (Search Engine Result Pages) with the “This site may harm your computer” label thereby stopping all traffic dead in it’s tracks.
  2. Cautiously the site owner or webmaster will try to view the site. They don’t want to become infected from their own site, but their curiosity is overwhelming. They typically don’t see anything malicious.
  3. “How do I find and clean this?” Often these people will post questions on sites like Google’s Webmaster Forums or www.badwarebusters.org or some other favorite online watering hole.
  4. Then their focus turns to, “Who’s to Blame?”

The feeling of many site owners is one of “I’ve been violated and I need to blame someone.”

When hacking victims get to “Who’s to blame”, they quite often turn their attention to their hosting provider. Many times the blogs and forums are filled with postings where people blame even some of the largest hosting providers. Site owners want to instantly spend the time and money to move their website to a different hosting provider where they’ll once again feel safe and secure.

All because they feel it’s the hosting provider’s fault their site, or sites, were hacked.

The site owner or developer will call the hosting provider looking for assistance from their technical staff and quite frequently, they can’t find the obfuscated malscript buried deep inside some harmless HTML code either. Many times the website has been blocked by various anti-virus programs, Google’s search results and sometimes even corporate website filters for days or weeks before the issue is resolved.

Even if the site owner goes through the trouble of moving to a new hosting provider, with these recent infections, their site will just get hacked again and again.

Then who’s to blame? The new hosting provider? How many more hosting provider’s will the site owner move to until they finally find one that gives them that safe and secure feeling?

Many site owner’s want the hosting provider to take responsibility and clean their site. After all, they’re paying their $5 – $10 per month so the hosting provider should take responsibility and the spend the time to clean the infectious website, right? No matter how many times the site gets re-infected.

Don’t Shoot the Messenger

I hate to be the one to break it to you, but, hosting providers had nothing to do with websites getting hacked with the recent gumblar, martuz or iframe injections. It was anyone’s fault but theirs.

It could be the site owner’s fault, or the anti-virus company’s fault, or Microsoft’s fault, or the fault of the company that wrote the FTP software being used.

It was almost anyone’s fault – except that of the hosting provider.

Let me explain.

You see, with all the malware that went undetected by these generic signatures, thousands of PCs were compromised. According to the Commtouch report referenced above, 376,000 new zombies per day.

You could blame Microsoft, however, the Commtouch report also shows an increase in the amount of Mac malware as well. Besides, blaming Microsoft is so 2,000 late.

These recent website infections came from viruses on the PCs of people who have FTP access to websites.

OMG!

Does that mean it could be the fault of the website owners, developers and webmasters?

It might, rabbit, it might.

These recent undetectable viruses steal FTP credentials – usernames and passwords. These viruses search through the files of popular FTP software looking for the file with the stored FTP credentials. These viruses also record keystrokes so when an infected PC is used to type in the FTP credentials, they get stolen. As another point of attack the viruses also “sniff” FTP traffic. Since FTP transmits all data in plain text, it’s easy for a sniffer to see the username and password in the FTP data stream and steal it. We even did a video to show how easy it is to sniff FTP traffic. It’s so easy that some people use a sniffer on their own FTP traffic if they forgot their stored password. Here’s our video.

Virus writers are incredibly smart and this round of malware proves it.

Once the virus has the FTP credentials it sends them to the server of a cybercriminal. This server is configured to login to the website as a valid user, inject it’s infectious code and move on to the next site.

Who’s to Blame?

How many websites did you visit that displayed some type of ad? Did you know that many ad networks have served up infectious ads – unknowingly of course, but nonetheless, the ads could have infected many visitors.

How many websites did you visit that displayed Flash intro’s or allowed you to view an Adobe Acrobat file (pdf)? Adobe had a few vulnerabilities in their software, that were exploited during and prior to this time period. Combine a vulnerability in files so widely used with the ineffective generic anti-virus signatures, and there’s another source to blame. Maybe two new sources – the AV companies and Adobe.

Did you update your Adobe products as soon as the update was available?

If not, then there’s another person to blame – you.

Could the companies that wrote the FTP software used, maybe have encrypted the stored usernames and passwords so that it wasn’t quite so easy to find and steal the FTP credentials? There’s anothe source to blame.

Maybe if so many people didn’t use their PCs with full administrator rights, there wouldn’t be such a virus outbreak in the first place. Maybe these PC owners are to blame.

Whoever you decide to blame, don’t incur the costs involved with moving to a new hosting provider before you find out what your site was infected with and how those infections occurred. You might be barking up the wrong tree.

I’ll tell you, the cybercriminals are to blame.

They’re the people who write and distribute viruses, malware and malscripts.

Cybercriminals (some call them hackers) want to control as many computers as they possibly can. They don’t care if it’s a computer for a university or if it’s the computer of a new Internet start-up company. One compromised computer looks just the same as another.

Compromised computers make up their inventory.

You know what a hacker calls an uninfected computer – opportunity!

Their digital assets are the computers they control. Often times some of their inventory of infected computers gets rented out to other cybercriminals. This provides them with a source of income.

If you really need to blame someone, blame the hackers, or the international cyber laws, or the world economy. Just don’t blame the hosting providers.

Hosting providers provide a very valuable service. Their margins are squeezed tighter and tighter as it seems everybody thinks it’s a great idea to enter the hosting industry. The good hosting providers work hard for their customers. They depend on customer retention and acquisition – just like every other business. They do the best they can with what they have.

The only thing a hosting provider could do to prevent these gumblar, martuz and iframe infections is to block all FTP traffic. Then you would have a very good reason to blame them for something, but you still wouldn’t be able to justify blaming them for the rash of website infections.

It simply isn’t their fault.

Let me know your thoughts on this. Who would you blame if your site got hacked? Who did you blame if your site was already hacked?

By

The Errors of Error Pages

Over the past few months, the number of sites infected with malscripts has increased dramatically. Many of these injection infections are difficult to track. Unbeknownst to many site operators, “error pages” can actually complicate the detection process. This blog posting discusses what we call “The Errors of Error Pages”.

Frequently, if you mistype a word in a URL, the “Page Not Found” error page is displayed. The very plain, non-descriptive message is not terribly user friendly in that it gives minimal information. The error code produced by a “Page Not Found” is a 404.

If you request a non-existent page on a Microsoft IIS webserver you might see something like this:

 404-iis1

Much has been written about preventing the typical “Page Not Found” error page from scaring away potential buyers. However, most of these marketing articles omit the critical discussion of how cybercriminals use these error pages to distribute their malware. This posting focuses on that topic.

The General Problem

When a site discloses Google’s moniker, “This site may harm your computer”, the user’s or host’s first response is to scan their website with anti-virus programs – rarely will this find the malscripts. Since Google prohibits the site from appearing as a normal search result while generating this message, the user aims to quickly find the injection infection. Once discovered, the site then seeks Google’s permission to reappear. We’ve handled many cases where everyone from the hosting provider, to friends, to the web developer, has checked “every file” and found nothing malicious on the site in question. Often, the error page is the source of the problem. However, they routinely fail to investigate the error pages – and cybercriminals know this.

Relevant Codes

To understand the criminal mind, one must first understand the various response codes generated by different requests. For example, when one uses their browser to request http://www.wewatchyourwebsite.com, the page actually exists. Therefore, the response code the browser receives is a 200. These codes don’t appear on the screen, but the browser sees them.

On the other hand, if one types in http://www.wewatchyourwebsite.com/fredflintstone.php, the browser would generate a 404 (Page Not Found) response code because there is no page with that name on the site.

To avoid a user receiving a 404 response, and the resulting “ugly” Page Not Found page, a website can be configured to generate a different response for those requests which would typically result in a 404 response code. Instead of a 404 response, you would see a page that’s been created to replace the “Page Not Found” response, or some substitue page that informs the visitor that the page they’ve requested has either moved or does not exist.

Use of Security Tools

In our work, we’ve tested various tools, vulnerability scanners, exploit engines, etc. seeking a vulnerable script file or software exploit, and found that if the tool sends a request to a website that generates a response of any kind, often times the tool considers the exploit successful. However, if the website being tested is setup to return a custom error page rather than the basic “Page Not Found” page, the security tool will record that attempted exploit as successful, thus, rendering a false positive.

For example, a security tool may be used to check for a vulnerable version of some shopping cart software. If the website being checked is set up to return a customized 404 error page, the security tool will see that it generated a webpage response to it’s request for the vulnerable shopping cart URL. If the tool detects a webpage in response to it’s check, the tool will assume that the site must have the vulnerable version of the shopping cart software – a potentially false positive.

Since hackers know that false positives arise under these circumstances, when they infect a website, they inject their infectious code into the default error pages. As cybercriminals also know, frequently, these pages are neglected by those working to detect infections on websites.

Clues to Find and Methods for Searching

Knowing all of this, during a search for infections, we always check for fredflintstone.php. (When we start seeing websites with a webpage with this name, we might switch to betty.php, wilma.html, barney.cfm or dino.asp.) Nevertheless, by checking for pages that we know don’t exist, we are confident that we have scanned for this obvious point of infection, and thereby detected possible cybercriminal activity.

Further, many shared hosting services use a folder off of the root folder named something like “error_docs”. Often, the hosting provider will fill that folder with basic webpages that a site uses as responses when visitors request webpages they aren’t allowed to see or simply don’t exist. Sometimes these files will be named with the response code, e.g. for a “Page Not Found” error the resulting webpage might be called 404.html. Other times, the webpage will be called by the error name it’s produced by – like “page_not_found.html” for a 404 response code.

Every host or site owner should determine how their site handles these different responses and check those files for any malscripts. At the end of this article, we suggest a valuable tool to conduct such checks.

More Examples

In the course of our work, we recently discovered a rather ingenious way of delivering malscripts through the use of 404 error pages. Apache Web server software can be configued differently to a request for a webpage that doesn’t exist.

One basic response is in the configuraton file: httpd.conf, and it would look like this:

  • ErrorDocument   404   /404.html

If you’re on a shared hosting plan (you’ll know if you’re not), you probably (hopefully) don’t have access to this file. But you will have access to .htaccess (yes there is a period in front of that file name). This file might also have the same entry for ErrorDocument listed in there.

How do hackers use this to infect visitors to one of their distributional assets?

One of two ways.

First, they can see what file is used for the 404 (or other such response codes) and inject their malscript into that page. This can be found during a scan of the files residing on the webserver.

Or, they can instead insert their own malicious URL replacing the /404.html in the line ErrorDocument…

Instead of this: ErrorDocument    404    /404.html

They would put: ErrorDocument    404   http://hackerswebsiteinsertedhere

That way when someone scans all the files with a search tool, it won’t find the malscript because the malscript isn’t in any of the files located on that server. It’s located on a server miles away.

This is why it’s always important to know how a site is handling 404’s and other errors. The specific method used by the hosting provider must be checked. Any suspicious looking should be checked and verified.

As hackers become more sophisticated, website owners and developers must as well. Therefore, while the hackers increase their attempts to infect websites, so too, must we all increase our efforts to detect and to block them.

How can you check your site?

I recommend a tool I learned about from Kaleh (a moderator on www.badwarebusters.org and a frequent contributor on Google’s Webmaster forum). The tool is a website: http://web-sniffer.net. Simply, enter a URL in the box at the top, add “/fredflintstone.php” (no quotes) to the end of it, and hit “Submit”.

Scroll down to the bottom of the screen to see what HTML/code the site sends to a visitor’s browser when they request a page that doesn’t exist (404 error).

If you see something that looks out of place, you should suspect that code, research it and possibly remove it. If you ever have any doubts, please contact me and I’ll review it for you. We have deobfuscation tools available and can usually determine what a piece of obfuscated script is really doing.

Should you have any questions or wish to continue this discussion, please post your comments below or contact directly at traef@wewatchyourwebsite.com

Thank you.

By

Paul McCartney's Web Site Hacked – "Back in the USSR"

Yes it’s true. The rock n roll icon Paul McCartney had his website hacked. (This attack isn’t necessarily originating in Russia, but I couldn’t refuse the obvious opportunity.)

It’s amazing how certain hackings follow the news. It was just a couple days ago when I was watching the news on TV (yes that old, outdated media) and learned that Paul McCartney and Ringo Starr were going to get back together for a “reunion” tour.

The website hacking could have been purely coincidental, as the toolkit planted on his website – Luckysploit, has been used in many, many recent website malware distributions. It could be that the cybercriminals behind this exploit  just happened to find this site vulnerable to their recent attack. I believe it’s irrelevant how or why, their timing was impeccable.

This is another example of social engineering used successfully to infect more computers.

Think of the millions of Beatle’s fans (my father-in-law is one of them – a fan not a virus victim) hearing about this reunion and flocking to Mr. McCartney’s website to find out where their concerts will be performed only to find out at the next anti-virus scan that they’ve been compromised by a bank login and password stealing virus.

The nerve of these hackers. Using something so “in the news” to lure millions of people to  infectious websites that have been planted with malicious code, appearing to be legitimate websites, for the sole purpose of delivering a virus that is currently evading detection by many anti-virus programs.

Is there no shame?

This attack is being carried out by the Zeus botnet. Yes while everyone was watching out for Conficker, many forgot about the other botnets out there.

It’s easy to spot the infectious malware code in the “source” of the web page. All you have to do is look for something that’s impossible to read because it is encrypted and obfuscated to avoid easy detection. Luckily for us, we don’t look for specific infections while scanning websites. Our systems are based on any changes to a website. We pay close attention to changes that include specific keywords, but our alert system is based on any changes made to a website.

Once again the cybercriminals use a popular event to spread their malware. This particular infection will steal banking credentials which are then sold on the open black market. This is one of the cybercriminals profit centers. They have many.

Be careful when using the Internet, you never know if you’re getting more than you bargained for.

Other Beatle’s songs that come to mind with my sub-titles:

“Do You Want to Know a Secret” (about my malware)

“Don’t Ever Change” (my website)

“Don’t Let Me Down” (please click on this infectious link)

“Eight Days a Week” (and I’ll infect you every one of them)

“Everybody’s Got Something to Hide Except Me and My Monkey” (okay maybe my monkey has some malware to hide too)

“Fixing a Hole” (in your website)

“Free as a Bird” (free as in free malware)

“From Me to You” (more malware from me to you)

“Get Back” (to where you can get infected)

“Got To Get You Into My Life” (so I can hack you some more)

“Help!” (I need the services of WeWatchYourWebsite)

“I Am the Walrus” (I live Belarus) (okay you find something that goes with Walrus)

I could go on, but the Beatles wrote a lot of songs and I need to save server space.

Let’s be careful out there…

By

www.tiscali.co.uk was hacked

According to information freely available, the website www.tiscali.co.uk has been hacked.

Primary Method: SQL Injection

Hazard to Humanity: Low

Date: March 15, 2009

Although hundreds of thousands of people login to this website, unless they’re using the same username and password for this site that they do for all their online activity; banking, bill paying, ebay, etc., then the actual risk is low. We gave this one a Low rating because it isn’t a site with financial information, but it is a very popular website.

Remediation and Preventative Measures: Properly sanitizing all data prior to inserting into database

By

www.telegraph.co.uk hacked

According to reports, the website for The Telegraph was hacked.

Primary Method: SQL Injection

Hazard to Humanity: Very Low

Date: March 6, 2009

Actually the site was: search.property.telegraph.co.uk and only the usernames and passwords of people who login to the site were exposed. As always, often times people use the same username and password for a variety of logins so an incident like this could grow bigger than just having someone post comments using a “hacked” username and password.

Remediation and Preventative Measures: Same as for all SQLi attacks – properly sanitizing all data submitted to a SQL database.