Why Does Google Consider Some Images Malicious?

">    18 Nov 11   Filed in Tips and Tricks

The other day I received an email from a webmaster whose site was blacklisted by Google. In Webmaster Tools, he found the following example of a malicious code detected on his site (domain changed):

So why did Google think this image tag was malicious? Can images be malicious? After all they are not scripts, iframes or embedded executable objects that that hackers use to attack web surfers.

It turns out, images can really make Google blacklist your site. In that particular case, the image was from a third party site and it was (as its name suggests) just an RSS icon. A normal legitimate file. The only problem was the third party site got hacked and attackers modified its .htaccess file to redirect search traffic to malicious sites (like here). Subsequently, that “example. net” got flagged by Google.

Cross-site warnings

Sometimes it’s enough for your site just to load something from a blacklisted site to get a warning. For example, Google Chrome has so called “cross-site warnings“. When you open a website that is not currently blacklisted, Chrome can detect (in real time) that a page loads something (usually scripts or iframes) from a known blacklisted site. In this case you will see the infamous red malware warning. The only difference from a normal warning will be the words that “website at contains elements from the site , which appears to host malware…“.

These cross-site warning only (reliably) work in Google Chrome. And since websites that contain elements from malicious site are not blacklisted at the moment, there will be no malware warnings in Webmaster Tools (until Google discovers malware on your site). So the webmaster couldn’t find that code in Webmaster Tools if that was just a cross-site warning.

Broken links can be dangerous too

Let’s get back to that hacked site. It’s .htaccess file also contained rules to redirect all erroneous requests (e.g. requests with error codes 404 Not Found, 400 Bad Request, 401 Unauthorized, 403 Forbidden and 500 Internal Server Error ) to malicious sites. In our case, that rssicon.png file was missing for some reason, thus requests to this file returned the 404 error code and got redirected to a bad site.

So every time when someone loads a page with that img tag, behind the scenes, one browser request goes to a malicious site. This is probably what Google malware scanners detected and this was the reason for flagging that website with the rssicon.png img tag.

Images in third party widgets

Another real world example is the current problem with Blogger blogs that use some fishy “page views counter widget” from bloggerwidgets .cz .cc. Google says, this site has infected 169 blogs.

All infected site has the following “counter widget” code

As you can see, this code loads an image from demo .bloggerwidgets .cz .cc. I guess it is supposed to display views count. However, the “bloggerwidgets .cz .cc” domain seems to be discontinued and now redirects all requests to a scam site.

Are those images malicious?

Can those images from hacked/redirecting sites be really dangerous for visitors to a site that embeds the images via an tag? Well, I think such tags are “mostly harmless” ;) Modern browsers seem to correctly handle such redirections and simply don’t process server responses in unsupported formats (the malicious redirect returns some HTML code where an image is expected). But who knows, maybe some older browsers under certain conditions may misinterpret the scope of the redirection and navigate a browser to a bad site (after all this is what browser exploits are all about — they allow to do undocumented stuff).

To webmasters

Anyway, whats’ more important for webmasters is that image tags can really be the source of malware warnings.

So here are some basic tips on how to deal with such situations:

1. Where possible, don’t use images and other resources (e.g. scripts, objects, etc) from third-party sites. You might want to copy the files to your own server (if their license permits this).

2. If you have to embed resources from third party sites (counters, widgets, ads), check how trustworthy and reputable they are (e.g. compare Facebook widget and the “bloggerwidgets .cz .cc” widget).

3. If Google blacklists your site and mentions some tag as the source of the problem, you should remove that tag (or replace the image with some placeholder with similar dimensions to preserve page formatting) from all pages and then request a malware review via Google Webmaster Tools.

4. In case you don’t see any samples of malicious code in Webmaster Tools (for example, if you haven’t registered your site with Webmaster Tools yet) you might want to check Google’s Safe Browsing diagnostic page for your site:

http://www.google.com/safebrowsing/diagnostic?site=example.com

Just replace “example.com” with your site domain.

On the diagnostic page, check domains mentioned in the “What happened when Google visited this site?” section. If your site links to some images on those domains you need to remove them before requesting a malware review.

5. If you really want to use those images on your site, you should contact the owners of the sites they reside on and ask to clean them up and have Google unblock them. Once those third party websites are clean you can link to their images again.

Note, the above instructions only apply to situations when Google blacklists your site because of the tags that you added to your site yourself. If you find some image tags or other HTML code that don’t belong to your site and you never added them yourself, this will be a whole different story that requires different remediation steps (for example, the most important step will be to figure out how that alien code was injected into your web pages.)

Related posts:

Practical Guide to Dealing With Google’s Malware WarningsHtaccess Redirect to Example.ru/dir/index.phpReadable SafeBrowsing Add-on for Firefox 4+Introduction to Website Parasites If you need my help to resolve your site security issues, you can request it here.
Tags: cross-site warning Google Chrome htaccess img redirects safe browsing Webmaster Tools « /tmp/wp_inc or Not Your Typical WordPress Attack Selected Tweets (Oct-Nov 2011) » Reader's Comments (2) loupiote | 18 Nov 2011 11:01 pm

hi denis,
actually, malicious images loaded with the tag can be harmful. there has been several instances of security bugs in the processing of compressed images (e.g. jpeg) that were causing buffer overflow, thus allowing the mere display of a malicious image to cause some arbitrary code to be run on the client. the exact same type of bugs have also been exploited with music (i.e. playing an audio file would execute malicious code).

Reply to this comment Denis | 18 Nov 2011 11:21 pm

Good point!

While browsers can discard redirects of images to HTML pages (as in examples I wrote about in the post), there may be specifically crafted image files that exploit bug in browser software that renders images – one more reason to always update your browser.

Reply to this comment Leave a CommentClick here to cancel reply.

Name (required)

Mail (will not be published) (required)

Website

XHTML: You can use these tags:

About this blog

Occasional posts from the developer of
Unmask Parasites about things that hackers already know and site owners should know (if they don't want to be victims).

Exploit reviews, security tips, and all that jazz.

This blog in the news

Get free updates:  RSS   Email   Twitter   G+
Recent PostsThe Crocodile Hunter Meets Badware in the Wild Malicious Apache Module Injects Iframes RFI: Server-wide iframe injections RunForestRun Now Encrypts Legitimate JS Files What’s in your wp-head? Millions of Website Passwords Stored in Plain Text in Plesk Panel Runforestrun and Pseudo Random Domains CategoriesGeneral (19)Hosting+Security (5)Short Attack Reviews (13)Tips and Tricks (14)Tweet Week (83)Unmask Parasites (12)Website exploits (78)Recent CommentsDIY malicious domain name registering service spotted in the wild « Webroot Threat Blog – Internet Security Threat Updates from Around the World on Lorem Ipsum and Twitter Trends in MalwareHans Bonini on Runforestrun and Pseudo Random DomainsAgain with the “Wordpress Isn’t Secure” Meme | All Things Cahill on Careless Webmasters as WordPress Hosting Providers for SpammersDealing with WordPress Malware | Sucuri Blog on Malicious Apache Module Injects IframesCode obfuscation « ..::Mendel's Weblog::.. on Runforestrun and Pseudo Random DomainsadvertisementHas your website been hacked?We're here to help you get back up and running with minimal downtime!

Call us now at 1-800-639-6442

www.HackRepair.com © Unmask Parasites. Blog. / Design: Smashing Wordpress Themes

View the Original article