Widgets or IFrame hacks, how would we know?

A particular aspect in IT security is injecting malware into websites. Often leading to so-called “drive by downloads“. This malware is often inserted due to a browser vulnerability which gets executed by, say, Javascript. The latter is usually “inserted” in a legitimate website using a hidden <IFRAME> tag or similar.

How can this be stopped? Modern websites include, because of widgets, several external Javascripts onto their own sites. When going to the gadget popular website engadget.com, a total of 17 hosts are contacted…

  • engadget.com
  • blogsmithmedia.com
  • o.aolcdn.com
  • platform.twitter.com
  • b.engadget.com
  • o.sa.aol.com
  • h.scorecardresearch.com
  • blogcdn.com
  • platform0.twitter.com
  • urls.api.twitter.com
  • platform.twitter.com
  • aolcdn.com
  • facebook.com
  • engadget2.disqus.com
  • static.ak.fbcdn.net
  • mediacdn.disqus.com
  • disqus.com

Wouldn’t it be easier for an attacker to -perhaps- perform DNS poisoning to take over one of these hostnames, to include javascripts in multiple websites? With the [like] buttons, [retweet] buttons and widgets, one could target many websites all at once.

Stopping this is partially performed by browsers, such as Firefox’s “this site downloads contents from xxxx.com, which contains malicious material”, but that’s only after a website is labelled as malicious. Could there be an answer where websites follow a “trusted list” (where sites register the widgets they use) type of model?

Just wondering on a thursday morning.


Posted

in

by

Tags:

Comments

2 responses to “Widgets or IFrame hacks, how would we know?”

  1. Thomas J. Raef Avatar

    DNS poisoning would be a more effective way, but definitely not easier.

    The easiest way for an attacker (hacker, cracker, whatever…) to infect a website is by looking for outdated software on a website – or more accurately on websites.

    You see, hackers rarely target a specific site, they scan the Internet looking for outdated websites. Your software (Joomla, WordPress, phpMyAdmin, osCommerce, etc…) might only be one update away from being vulnerable.

    On the attacker forums, many people post code with the following information: Google dork, example, proof-of-concept code.

    A Google dork is the search string to use to find sites vulnerable to the specific exploit at the moment. This allows many people to locate vulnerable sites and try the suggested proof-of-concept (POC) code.

    The example shows the readers how to use the POC against the websites returned by the Google dork.

    And of course the POC is the actual exploit code that allows one to infect a website.

    However, your suggestion is interesting in the fact that hackers try to use domains that look like legitimate website domains. They may use a 1 (one) in place of a “l” (letter L) or vice versa. They may register a domain that uses zeros in place of the letter “o”.

    Or, what we’ve seen most often is that the do infect a legitimate website and point other infected websites to that one. People might look at the list of websites their browser is about to go to, but if it looks legit to them, they may just let it go.

    We’ve also found that many of the browser tool bars rely on old information for blocking websites. Too often we’ve tested some of these browser security add-ons only to find them not catching the latest infected websites and still listing previously infected, but now clean, websites as being malicious.

    Registering widgets is similar to ad servers. Attackers find ways to list infectious ads on many of the most popular ad servers. So, a widget registry, would have to be scanned repeatedly to insure their list has integrity.

    Although, it is a good idea…

    Hmmm…

    Just providing food for thought – on a Thursday morning.

  2. Redha Avatar
    Redha

    good point, although indeed dns attacks could be more difficult to do. perhaps a malicious network operator/proxy admin that could “override” websites?

    thx

Leave a Reply

Your email address will not be published. Required fields are marked *