Security Blog

The latest news and insights from Google on security and safety on the Internet

All Your iFrame Are Point to Us

11 February 2008
Share on Twitter Share on Facebook
Google

23 comments :

Unknown said...

It was just a matter of time before malware distributors started exploiting hosts. For the last several years Open Directory volunteer editors have noticed hosts they were exploited by programs that put hidden porn and drug links and text on the sites on that host.

There are also some parking hosts that are either adding the malware themselves or are being exploited.

Blogs may be next, if they are not a target already. We saw an explosion of "hijacked" blogs about 3-4 years ago. I assume the blog owner's password was hacked. Off-topic links and copied text was substituted for the original content. For a search engine there is little context to know what the original content was. It is quite evident to from the original title and description that the site is hacked/hijacked. Of course, once a search engine is instructed what to look for, it is effective in searching for similar sites. One example:
--hamster-dwarf.blogspot.com-- The site was originally listed in Open Directory as " Hamster Hang Out - A general guide on the care of Campbell's Russian Dwarf hamsters. Includes information on care, diet and health." I think the content has changed :)

Even earlier than exploiting blogs, hackers/hijackers were changing content of free-hosted sites. I imagine it is fertile ground for malware producers. One example:
-jwscattergood.mysite.wanadoo-members.co.uk- That particular free host is not worse than others, most were exploited.

11 February 2008 at 20:04
Tim said...

Yes it's become very bad. I really appreciate the Google Safe Browsing API being available. While I haven't gotten to use it yet, it's another tool that can be used to prevent spreading of malware.

As for causes, I'd say most of the causes are on the web application area. There are tons of new exploits and vulnerabilities found daily and all it takes is a handful of people to forget to upgrade and there is another handful of websites with more malware.

12 February 2008 at 13:32
djpaisley said...

Most of the Malware hosting runs along the same lines as spam... older domain URL's that have been purchased as place holders to serve up some kind of PPC ads.. normally about 6 mos. to a year after the first purchase a second purchase may occur when then has a refresh tag to and inside URL that has a +26 character pagename (26+.html, etc.) which has a large image of somekind at the top and drive by malware at the bottom.. by the time the image loads... it's too late..

i think better policing of DEAD URLs will go along way to fixing this problem.

thanks for the heads up.. good article :)

12 February 2008 at 16:30
cseifert said...

Lots of information. Thanks guys!

On the analysis of the network connections: Did you investigate also new listening ports? I am wondering whether compromised hosts are abused as phishing sites (which might be promoted by some spam-malware that is pushed on the client machine)

On the anti-virus scan: Would be great if you could include some stats on the classification of the malware. In our work, we mostly saw fraudulent applications (approx 37%), spyware/adware (approx 6%), and bots/ rootkits/ spam apps (< 5%). While our data set only analyzed about 200 malicious URLs, it would be interesting to see results on the gigantic data set Google has available.

Christian

15 February 2008 at 17:27
Unknown said...

Its interesting that while Google has spent so much time researching drive-by downloads, they dont know how to test a product's protection against them. They still continue to use AV scanners to test drive-by downloads. That approach is just plain wrong.. because when you do that, you are testing only one aspect of the product - the av engine.

I have been looking at a specific feature in NIS/NAV2008 called Browser Defender that according to Symantec was specifically designed to detect and block drive-by downloads even if they are obfuscated.

I have to say, it works incredibly well even if you modifying the JScript to tweak the shell-code or the JScript. Google's tests did not take this into account, so the results that they have in their paper that the best protection they found was 70% is very misleading.

Google you need to fix your test methodology. What you should do is install the entire security product under test and then launch the browser with the offending URL and see if it detects it. Oh.. one important point. If have to have the ActiveX being exploited actually installed on the machine.

18 February 2008 at 20:56
Zestful said...

Google report was interesting reading, and it was satisfying to notice that it repeated some of the findings of the recent WOT study of dangerous websites: http://www.mywot.com/en/press/february

In this study we found out that the 3 categories of websites causing most damage to users are adult content (28% of the dangerous sites analyzed), software (27%), and entertainment (16%).

The study is based on analysis of 17 million websites rated by the WOT user community: www.mywot.com

21 February 2008 at 09:36
BillyWarhol said...
This comment has been removed by a blog administrator.
4 March 2008 at 22:34
Anonymous said...
This comment has been removed by a blog administrator.
17 March 2008 at 13:23
Ron said...
This comment has been removed by a blog administrator.
23 March 2008 at 10:24
MCKE said...
This comment has been removed by a blog administrator.
26 March 2008 at 21:10
Aristedes DuVal said...
This comment has been removed by a blog administrator.
14 April 2008 at 14:32
Ignacio said...

Question: when will you solve the problem with iclk script that's being used as a redirector for spam, phishing and malware?

4 May 2008 at 20:37
Unknown said...

The "malvertisement" problem has sadly been around for almost two years now (at least as far as i know) and it's worrysome that it's getting worse. One of the problems is indeed the increasing # of ad-networks and hence the longer redirect stream.

If anyone is interesting I've written extensively about the advertising problem: http://www.mikeonads.com/what-is-errorsafe-and-how-do-we-stop-it/

Sandi has a more up to date list of "bad ads" on her blog here: http://msmvps.com/blogs/spywaresucks/Default.aspx

-mike

15 May 2008 at 12:08
Unknown said...

It is tough to blame the ad-networks for this problem simply because there are more of them. That is like blaming car dealers for an increase in carjackings.

Do you (Google) contact the owner of the potentially affected host and let them know your findings? It may be helpful to give them your data so they can take measures to deal with the malware.

And Mcafee SiteAdvisor (www.siteadvisor.com) is a tool for web-users looking to verify if sites have been infected. This along with google's own system seem to do a decent job keeping people from accessing infected sites.

www.mbridge.com

5 June 2008 at 12:41
wow gold said...
This comment has been removed by a blog administrator.
9 June 2008 at 04:03
Jane B said...

Nice work done!!! But can we have any permanent solution to avoid this malware from internet? Can Google remove such sites from search results that will stop visitors to visit such sites?

9 June 2008 at 05:02
Unknown said...

Given the impossibility of policing the internet we believe a client side browser security solution is needed. ZoneAlarm ForceField virtualizes the browser so that any malware received in a drive by download is trapped in the virtual session. More information is available at www.zonealarm.com.
Laura Yecies
General Manager, Check Point ZoneAlarm Consumer Division

10 June 2008 at 19:37
Anonymous said...
This comment has been removed by a blog administrator.
17 July 2008 at 01:15
Anonymous said...
This comment has been removed by a blog administrator.
19 August 2008 at 02:05
Anonymous said...
This comment has been removed by a blog administrator.
4 September 2008 at 13:11
Psidekick said...

The trouble with this is that it becomes more of a shock if a Google result turns out to be malware! :)
I had a malware search result today. The URL was http://www.gbminis.lhosting.info/burris-b2a/international-sim-card-uk.html
It would be nice if there was a way of reporting a search result as potentially harmful..
Regards
Rick

10 September 2008 at 17:54
Jerry W. said...

The simple fact is that a browser, connected to the largest network in modern history, should not have the privilege to create and execute files, unattended, all over the OS system. If browser developers are unwilling to adopt a 'sandbox' security model we will continue to be vulnerable to internet-based attacks. Whether a site is trusted or not, it should not have any ability to permanently modify the browser or OS. Our security, software, and identities are continually compromised because the 'good guys' have the same interest as the 'bad guys'-- accessing detailed system/user information and exploiting it. Therefore, I assert that we will remain exposed to internet based 'attacks' because it is in the interest of browser makers to server up the greatest access to OS/User to advertisers and site traffic tools.

10 June 2010 at 13:36
Unknown said...

Questo blog è davvero utile e pieno di ottime informazioni. Grazie mille

Redatto da http://www.cataniaroma.com

2 December 2013 at 14:43

Post a Comment

  

Labels


  • #sharethemicincyber
  • #supplychain #security #opensource
  • android
  • android security
  • android tr
  • app security
  • big data
  • biometrics
  • blackhat
  • C++
  • chrome
  • chrome enterprise
  • chrome security
  • connected devices
  • CTF
  • diversity
  • encryption
  • federated learning
  • fuzzing
  • Gboard
  • google play
  • google play protect
  • hacking
  • interoperability
  • iot security
  • kubernetes
  • linux kernel
  • memory safety
  • Open Source
  • pha family highlights
  • pixel
  • privacy
  • private compute core
  • Rowhammer
  • rust
  • Security
  • security rewards program
  • sigstore
  • spyware
  • supply chain
  • targeted spyware
  • tensor
  • Titan M2
  • VDP
  • vulnerabilities
  • workshop


Archive


  •     2025
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2024
    • Dec
    • Nov
    • Oct
    • Sept
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2023
    • Dec
    • Nov
    • Oct
    • Sept
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2022
    • Dec
    • Nov
    • Oct
    • Sept
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2021
    • Dec
    • Nov
    • Oct
    • Sept
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2020
    • Dec
    • Nov
    • Oct
    • Sept
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2019
    • Dec
    • Nov
    • Oct
    • Sept
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2018
    • Dec
    • Nov
    • Oct
    • Sept
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2017
    • Dec
    • Nov
    • Oct
    • Sept
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2016
    • Dec
    • Nov
    • Oct
    • Sept
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2015
    • Dec
    • Nov
    • Oct
    • Sept
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2014
    • Dec
    • Nov
    • Oct
    • Sept
    • Aug
    • Jul
    • Jun
    • Apr
    • Mar
    • Feb
    • Jan
  •     2013
    • Dec
    • Nov
    • Oct
    • Aug
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2012
    • Dec
    • Sept
    • Aug
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2011
    • Dec
    • Nov
    • Oct
    • Sept
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
  •     2010
    • Nov
    • Oct
    • Sept
    • Aug
    • Jul
    • May
    • Apr
    • Mar
  •     2009
    • Nov
    • Oct
    • Aug
    • Jul
    • Jun
    • Mar
  •     2008
    • Dec
    • Nov
    • Oct
    • Aug
    • Jul
    • May
    • Feb
  •     2007
    • Nov
    • Oct
    • Sept
    • Jul
    • Jun
    • May

Feed

Follow
Give us feedback in our Product Forums.
  • Google
  • Privacy
  • Terms