XSS for Fun and Profit

Ad-Jacking part 1


Ad-Jacking is a term I coined for this article to categorise covert Ad hacking schemes. Why Ad-Jacking, well because thats effectively what we are doing.

Understanding this paper requires us to have a little understanding around
what types of Ads make us money. So firstly let us go over the current Ad
system; the following table attempts to categorise them:

CPC cost-per-click Money per click
CPM cost-per-thousand Money per thousand impressions
CPA cost-per-action Money per action (i.e. a sale, survey etc)
Affiliates Affiliate programs Custom - can involve any of the above and more.

We really want to focus on CPC and CPM (sometimes affiliates). Why? because its guaranteed $$$ per hit, and the attacker can guarantee hits, atleast when using XSS, which part 2 of this article will discuss.

Now some of you may already know where I am going with this; for those of you who haven’t guessed, we will be discussing weaknesses in the current Ad schemes and how they can be exploited. The ideas discussed here are by know means new, but I haven’t seen any article on the Internet that really brings these weak points home.

The topics covered include but are not limited to:

  • Popups
  • Redirects
  • IFrames
  • Images
  • XSSing for Fun and Profit

popups

It makes sense that this paper should start with the most common and annoying
type of ad-jacking, popups! Why do hated webmasters do it? Now that we understand CPC and CPM the reason becomes obvious.

The proof of concept code below spawns a new window (popup) with dimensions we set. This is becoming more difficult to do as a number of web browsers support popup countermeasures, but this use to be the preferred method.

window.open('http://myadspaymentsite/url=sponsorlink&ref=12345',
'window name','attribute1,attribute2')

IFrames

An IFrame is basically a new web page that is loaded into a table in your current browser. This is really powerful for displaying content from other domains, unfortunately is can also be used nicely as an ad-jacking tool.

The following code will load up an invisible iframe to our sponsored page. The nice thing here
is that our evil attacker is now making money from your visit without the user knowing. Nice
for the user, but it completely defeats the point of having Ads.

<IFRAME NAME="iframe" SRC="http://myadspaymentsite/url=sponsorlink&ref=12345"
SCROLLING="AUTO" WIDTH="0px" HIEGHT="0px" FRAMEBORDER="0"
ALLOWTRANSPARENCY="yes">Your Browser Does not Support IFrames. Please
View the Site in a Different Browser to View this frame.
</IFRAME>

Redirects

We will cover this alot more when in part 2 of this article. With the possibilities of web 2.0 superworms there is alot of potential for badness here.

The following example simply redirects the user to an ad page upon rendering a page:

javascript:document.location = 'http://myadspaymentsite/url=sponsorlink&ref=12345';

Hidden Images

This has got to be one of the most effective methods mentioned thus far. Images allow cross-domain access, but they are also invisible in most cases by default; a web page is retrieved rather then an image, and therefore no result is ever displayed. This syntax is also dead simple:

<img src="http://myadspaymentsite/url=sponsorlink&ref=12345" alt="" />

XSS for Fun and Profit

I’ll see how this paper gets on, and decide weather to releasing part 2 of XSSing for Fun and Profit, which actually involves XSS :)

Summary

This paper looked at ways to embed malicious code into pages to trick and scam Ad applications. You can be sure Google and many others know all about these scams (atleast we hope they do) and most likely have fully-feeatured analytics to detect anomalies; however, I am curious just how effective they are at detecting this when we use the two R’s, RANDOM and REALISTIC.

It is also because of these weaknesses that CPC and CPM type Ads will be replaced in the future, Google and many others are moving more towards CPA as sales and surveys are more difficult to scam.

10 Comments so far

  1. ntp @ May 30th, 2007

    click-fraud?

  2. david.kierznowski @ May 30th, 2007

    ntp, think of it as click-fraud on steroids; the direction of this article is to demonstrate snippets of code that attackers can use with the rising of web 2.0. It is no longer about what an attacker can embed in his page, but what an attacker can embed in others web sites with web 2.0 super-worm, propogating with JSON and XSS. We can manipulate and hijack websites current Ad schemes, rewrite pages etc. Click-fraud is obsolete :)

  3. kuza55 @ May 31st, 2007

    AFAIK Google and Yahoo (and most likely others) write an iframe to the page, and the iframe contains links with nonces in them, so unless you’re talking about XSS Vulns in the ad serving domain (which is highly unlikely since both Google and Yahoo use domains separate from all their other domains for serving ads), then I’m not quite sure where this is going.

    And if you *are* talking about XSS holes in ad serving domains, well, I don’t think that you’re going to find any on an ad serving company of any size, with semi-decent web server configurations.

  4. david.kierznowski @ May 31st, 2007

    Mod’ed this comment, it was very sarcastic before :)

    Kuza55: well this is exactly the kind of thing I’m currently researching. Let me try answer your questions with a question:
    If we have XSS on the current ad serving page do we really care if they are using nonces?

    Your comment seems to be driven toward XSSing the Ad Servers.. I am referring more toward an attacker using the XSS vector to spread his/her ad network (i.e. Persistent XSS in forum, reflected XSS in search engine etc)

  5. kuza55 @ June 1st, 2007

    Ah, alright, I guess I missed your point then. I thought you were talking about smiulating user actions like ad clicks, but I see what you mean now.

    One thing which Google does is tie the Adsense code to a specific domain, so you’d have to either sign up with a different account for every site, or create an iframe to your domain, and have the ad serving code there, so that its rendered on your domain.

    But to answer your question; yes it does matter if the ad company is using nonces, because unless we know those nonces we can’t simulate user clicks, and can only either hijack clicks (by placing the iframe under the cursor), or by serving the ads and getting CPM money.

  6. david.kierznowski @ June 1st, 2007

    Kuza55:
    Adsense is not domain specific, you can have adsense running on multiple domains, see: http://adsense.blogspot.com/2005/08/from-inside-adsense-mail-bag.html

    Obviously nonces don’t help much when XSS is involved, as we can fetch the nonce from the page and then append the appropriate data. In fact, who cares, most affiliate programmes dont support this and adsense data can be replayed successfully, I have tested this. Whats more, part of ad-jacking is adding our own content including nonces (if any) into a page, effectively ad-jacking it.

  7. […] This article is part of my concept Ad-Jacking: XSSing for Fun and Profit. […]

  8. kuza55 @ June 2nd, 2007

    Whoops, my mistake, since you needed to provide a domain initially I assumed (:() that it was tied - I should really start checking all the things I say.

    But I would still be surprised if it didn’t raise a flag somewhere at Google when some code starts getting used on a new site.

  9. David @ January 17th, 2008

    Hello, guys!
    I’m very interesting about this article and especially about XSIO - Cross Site Image Overlaying
    But.. I’v tested many socials networks like myspace, digg, etc and couldn’t find such vulns
    I mean, that wnen I type in comments a code like:

    I don’t see the image in comments.
    Could some body explain^ may be this bug already fixed everywhere or what I’m making wrong?

    ———-
    Thank’s beforehand!

  10. David @ January 17th, 2008

    ups.. :) now i see that this site is support tag ()
    And in my up post i meant code like
    []

Leave a reply

Recent

Sponsored links