Are Social Bookmarking Buttons Hijacking AdSense Publisher IDs?


Something has been hijacking the Adsense Publisher ID on some of my pageloads, inserting someone else’s ID in the Google ads instead of mine. I’ve been investigating this with some members of the Google Help forums and an HTTP debugger.

It seemed to me as if a popular plugin for social bookmarking buttons was hijacking the Adsense IDs. However, the jury is still out on who or what the cause is, because since publishing my original post, I have been in contact with AddToAny, who told me this:

I can say with absolute certainty that AddToAny doesn’t run 3rd party
ads at all (never has), and I think it’s unlikely that someone would
try to hijack vicariously through our widget in particular.
Technically, it wouldn’t work unless you’re using forked AddToAny
code, but your requests seem to be from our CDN.

In which case, sorry AddToAny.

So the investigation is continuing: something is hijacking publisher IDs and stealing Adsense.

I installed the AddToAny social bookmarking plugin on a different website about a month ago. I would really like this not to be the culprit, because is it so useful. Here’s what happened:

A few weeks after installing it, I noticed something odd in Statcounter: under the ‘Exit Link Activity’ option, Adsense exit links were showing up with someone else’s Adsense Publisher ID. The rogue Adsense ID I found was this one: ca-pub-7957824725474864

I checked in Adsense, and obviously the clicks from my site with the other publisher id had not been recorded there.

Here is a screenshot from Statcounter (sitename removed), showing the beginning of the exit link with someone else’s publisher ID:

Statcounter exit links showing the rogue Adsense Publisher ID

Statcounter exit links showing the rogue Adsense Publisher ID

The visitor had come in from a normal Google search to a landing page on my website, and appeared to have left from a page on my website, as opposed to a page that was saved to someone’s desktop.

I went to the page itself and reloaded it a few times to check the Adsense, but everything looked normal, both on the page and in the HTML source code.

Next I checked the Adsense code that was set up on my website, but again, everything was as normal.

So I did a search to see if anyone else had experienced this, and found this thread on Google Help forums. Not only was someone else experiencing the same thing, but with the same other person’s Adsense publisher ID.

Like the original poster, I reported this to Google AdSense. They replied that any extra ads on my site were placed without their knowledge, I should take security precautions (which I have) and that they would investigate this, but wouldn’t be able to tell me any of the results they found.

Meanwhile, on the Google forums, people were very helpful. Various causes were suggested for the rogue ID, including:

  • stealware in browser toolbars and third party applications on the visitors’ PCs (see this post about stealware in peer to peer file sharing programs,
  • pages loading in iframes,
  • adsense and banner advertising manager programs,
  • and third party javascript scripts.

Apparently it is well known for ‘stealware’ programs to hijack ids for affiliate marketing, although I could not find a reference to them hijacking Adsense.

There was a link to the Jensense Adsense blog, describing a Tell a Friend script that was inserting Adsense ads at the bottom of web pages: http://www.jensense.com/archives/2005/07/using_a_third_p.html

The original poster and I established that our websites were running on different software (one WordPress, one Joomla), with different advertising programs (Advertising Manager and Banners Manager). The original poster had uninstalled Advertising Manager a month ago and had not seen the rogue ID since then, but I was not using Advertising Manager. However, one thing we did have in common (apart from Statcounter and Adsense) was the AddToAny social bookmarking code. The original poster had the AddToAny WordPress plugin, and I had the version for other websites.

Although it is very popular, this plugin had also been criticised in the WordPress forums for nondisclosure of privacy issues: http://wordpress.org/support/topic/364390?replies=17, and in Futtta’s technology blog post ‘AddtoAny Removed from here‘.

So because of the timing, with it being the most recent thing I had installed, the privacy concerns and because it was one of only three scripts our sites had in common (Adsense, AddToAny and Statcounter), we were starting to wonder about it. But I was still not convinced it was a script on the page, because I hadn’t seen it in action, apart from exit clicks reported after the fact in Statcounter.

One of the helpful people who answered on the thread suggested reloading the page 5 or 10 times and checking the source code, as many third party scripts are up to similar tricks. So I tried, and found nothing, then tried again while running the Fiddler HTTP debugging tool, and I found something very very sneaky.

On the fifth pageload, the HTTP requests appeared the same at first. I could see the adsense loading with my own publisher ID. I could see the AddToAny button code loading, then Google Analytics, which I don’t use on that website, and then something from media6degrees.com, the website discussed in the WordPress privacy thread. All of these sources were the same each time the page loaded, but on the fifth pageload, after the last line of that code there was a new line, inserting Google Adsense code with the rogue publisher ID. Here is the section with the AddToAny HTTP requests:

The HTTP request URLs:

HTTP Debugging: URLs requested

HTTP Debugging: URLs requested

The bottom line shows Adsense being reloaded with someone else’s publisher ID instead of mine.

The body size, caching and content types:

Next I wanted to compare the caching and content types for the rogue adsense with my genuine adsense, to see if there were any more clues there.

(The first line on the white background below is from my genuine adsense, to show how the rogue version (the last line in blue) is comparable in size and content):

HTTP Debugging: Content types and caching

HTTP Debugging: Content types and caching

Both have a same day expiry date, type of ‘text/html’ and size of around 4300.
From the similarities between the two requests, it looks as if Adsense is being completely reloaded, with the other publisher ID.

The URLs (my site and directory names changed):

Here are the full URLs requested in that section, (names changed again):

http://static.addtoany.com/buttons/share_save_171_16.png
http://static.addtoany.com/menu/transparent.gif
http://static.addtoany.com/menu/sm1.html
http://static.addtoany.com/menu/icons_19.png
http://www.google-analytics.com/__utm.gif?&utmwv=4.6.5&a2a&utmn=4149404286&utmhn=www.mysite.co.uk&utmt=event&utme=5(Share%20menu*TestHit1)&utmcs=iso-8859-1&utmsr=1280x1024&utmsc=32-bit&utmul=en-us&utmdt=Weddings%20-%20Special%20Events%20-%20My%20Directory&utmhid=4149404286&utmr=-&utmp=/mysitedirectory/special-events/weddings/&utmac=UA-1244922-3&utmcc=__utma%3D3411996521.1303784683.1272227757.1272228778.1272229292.5%3B%2B__utmz%3D3411996521.1272229292.5.1.utmcsr%3D(direct)
%7Cutmccn%3D(direct)%7Cutmcmd%3D(none)%3B

http://map.media6degrees.com/orbserv/hbpix?pixId=2869&curl=http%3A%2F%2Fwww.mysite.co.uk%2Fmysitedirectory%2Fspecial-events%2Fweddings%2F

The inserted adsense:
http://googleads.g.doubleclick.net/pagead/ads?client=ca-pub-7957824725474864&format=468x60_as&output=html&h=60&w=468&lmt=1272229292&channel=2542620937&ad_type=text_image&color_bg=FFFFFF&color_border=FFFFFF&color_link=191970&color_text=000000&color_url=006644&flash=10.0.32.18&url=http%3A%2F%2Fwww.mysite.co.uk%2Fmysitedirectory%2Fspecial-events%2Fweddings%2F&ui=undefined&dt=1272229292156&shv=r20100414&correlator=1272229287250&frm=0&ga_vid=1774231493.1272229290&ga_sid=1272229290&ga_hid=582968367&ga_fc=0&u_tz=-420&u_his=0&u_java=1&u_h=1024&u_w=1280&u_ah=994&u_aw=1280&u_cd=32&u_nplug=0&u_nmime=0&biw=1259&bih=800&fu=0&ifi=1&dtd=109&xpc=ZtxUdmoqKN&p=http%3A//www.mysite.co.uk

It looked suspicious to me, seeing the Adsense being reloaded like that right after the AddToAny code, as if either AddToAny was doing it, or something was hijacking AddToAny for this purpose, or something else was hiding itself by appearing immediately afterwards to look like part of the AddToAny code.

The sneakiest thing was that when I looked in my HTML source file, everything still looked normal: the rogue ID was not there. So many people who had concerns about missing Adsense clicks or strange exit links would check the HTML view of their page and not see anything.

But I have no doubt that if I clicked on that ad, the rogue ID would appear in the exit link in Statcounter and nothing would show up in my adsense account.

I spent some time trying to get it to show up again so that I could test that out (after all it wouldn’t technically be an invalid click would it!). When I was testing the rogue ads didn’t appear again, but then looking back through the Fiddler logs I saw that sometimes they appeared later, after a second call to Google Analytics (which I don’t use on that site), so there may be an occasional time delayed attack as well.

I also checked my server access logs for the visit when the rogue link was clicked, but nothing unusual showed up, presumably because it was all requested from other websites. In any case, I did not see anything else unusual going on.

Next I wondered if this was something I had missed that was authorised somewhere in the AddToAny terms, although I know I checked them at the time. Google forum member Steven G had seen such provisions for hijacking publisher IDs left out of the agreements by third party scripts, but listed in FAQs, or even the manual (as he put it, a great place to hide it!). Steven G discusses this more in his pay per click blog.

Checking the AddToAny terms, there is nothing mentioned about Adsense, or revenue sharing. I couldn’t find the manual, but in their FAQ it specifically states:

Does this service cost anything?
AddToAny is free, and always will be.

AddToAny also confirmed to me that they do not run third party advertising, and they did not believe that their plugin could have been hijacked in this way.

Well it’s true that it’s free, as are all the scripts on that website, but if any free script is the culprit, it is certainly costing me something, along with many of its other users.

As Steven G put it,

As long as people monetize their sites and have no choice but to trust the scripts they install to do certain things, there will be programmers to offer their scripts that hijack a portion of your earnings.

– and also hackers taking advantage of another doorway into your system: cross site scripting only works if there is a way in.

In the case of some scripts, the user base is enormous, eg here are the download statistics for AddToAny’s WordPress plugin:

AddToAny WordPress Plugin Download Statistics

AddToAny WordPress Plugin has been downloaded 880,378 times in the last 2 years

The annoying thing is that if I knew one of the scripts was going to do this (and only this), as long as it was ok with the Google Adsense terms, it would have been ok with me. They could have been upfront about some kind of Adsense revenue sharing arrangement, and I would probably have agreed to it, for a useful plugin. But as it is, I don’t know what else it might come up with, because whatever is happening here is dishonest.

However, having been in contact with AddToAny, I don’t believe they are the ones who are being dishonest, in spite of the coincidences implicating their button code, or other services it uses.

But there are still other possibilities.

Firstly, the two remaining scripts should be considered, ie Google Adsense and Statcounter.

Statcounter

It’s obvious that Statcounter itself is not doing this: for one thing, if they were, they would be able to hide it from the website statistics!

It does not seem very likely to me that Statcounter is involved via hijacking either, firstly because their code loaded after the rogue Adsense, and secondly because the reloaded Adsense always appeared after a call to Google Analytics. Why would something that hijacked Statcounter make itself more noticeable by calling Google Analytics, which would probably not be installed if Statcounter was there.

Also, the other site owner had posted in Statcounter forums, including the rogue Adsense ID.

Google Adsense

The final script that my site had in common with the other site that found the rogue Adsense Publisher ID was Google Adsense itself, and as a third party script that loads code from another website into the page, it also has to be considered.

Obviously there’s no way Google itself is doing this. It just wouldn’t make sense for Google to be jeopardising the service it provides to its Adwords customers by fraudulently loading Adsense units twice on one pageload.

Would it make sense for an Adsense ad to include a script that inserted a different publisher ID? Well it wouldn’t make sense to do it with their own ads, since they’d be paying more for the user to click it than they’d get for having it fraudulently clicked.

But would they make a profit if their ad caused Adsense to reload with a different ad including a publisher ID that they would profit from? They would have a lot of impressions, with no clicks on their own ads, and profit from clicks on other ads that should have been earned by the website owner. I just can’t see them getting away with that from Google.

Ads Serving Malware

There have been security bulletins for a long time warning of malware being hidden in Flash adverts and other hotlinked graphics files, exploiting unpatched vulnerabilities in certain software and browser plugins.

Over the last few weeks, there have also been discussions online about malware being served through third party ad networks provided through Adsense.

Here’s a post from six weeks ago about malware being served by ad networks, including ad networks including Google Adsense, Adultadwords, and Adbrite. There’s also a Google Help forum thread from today about websites and visitors being attacked by malware served by advertisers in third party networks supplied by Adsense. http://www.google.com/support/forum/p/AdSense/thread?tid=420c791905c1c74d&hl=en

The Anti-Malvertising website (http://www.anti-malvertising.com/) is a useful resource for those dealing with malware and malvertising.

Browser Vulnerabilities

Another possibility to consider is unpatched vulnerabilities in Internet Explorer 8, since all the rogue exit links were clicked by visitors with Internet Explorer 8. However, many visitors do use Internet Explorer 8, and the number of rogue exit links we have visitor data for is too small to generalise from. I’ve also only been able to use the HTTP debugger with IE 8. So it’s a possibility to consider, but not at all conclusive (as it seems to be with all the options so far).

In the meantime, I have uninstalled the AddToAny code and disabled third party ad serving networks through Adsense (this is done by disabling image ads via your Adsense ‘My Account’ page). I am continuing to monitor my pageloads, so if I see the rogue ID without these being installed I will post it here immediately.

If anyone has found similar exit link activity, found this publisher ID elsewhere, or has more suggestions about this, please do post a comment below.

(Click for comments)

10 Responses to “Are Social Bookmarking Buttons Hijacking AdSense Publisher IDs?”

  1. Are Social Bookmarking Buttons Hijacking AdSense Publisher IDs?…

    Something has been hijacking the Adsense Publisher ID on some of my pageloads, inserting someone else’s ID in the Google ads instead of mine and steal……

  2. gary says:

    As I’ve already stated on the WordPress.org forums, what bothers me most is the lack up front of transparency here and the opt-out method.

    Many thank annabelt for an incredibly detailed article, which I now link to instead of Pat’s plugin page.

    Needless to say I’ve deleted his plugin, and it would seem a great many others are to follow.
    .-= gary´s last blog ..What happened to Bita Ghaedi? =-.

    • annabelt says:

      Thanks, but I never found the code that was causing this problem. I haven’t seen it happen again since though, and I’ve been checking my exit links carefully since then.

  3. Ronny says:

    It is just plain obvious that it is Google Adsense hijacking your pub id. Why is this so? Well, for one thing, this post has been featured in Adsense Forum and yet no Google Employee in Adsense Forum or yourself has asked the plain obvious question which only Google have the answer and that is this…who owns ca-pub-7957824725474864?

    Whoever owns this pub-ID must be making money from Adsense from hijacking other websites’ Adsense Ads and if Google is been defrauded, it would not go after the innocent publisher but rather ca-pub-7957824725474864, which is the guilty one. Many a times, Google bans the innocent party, even when evidence shows that it’s script is vulnerable to attacks unless in an unsual twist, Google is the one defrauding its innocent publishers yet making money from the advertisers. This is not too far-fetched a proposition, unless Google comes forward to defend itself, but it does not care because no one can catch it red-handed.

    • annabelt says:

      I’m sure Google could have found out who that was in 5 minutes! And perhaps they did, but I can’t see them telling anyone else because of privacy rules.

  4. Pakiisp says:

    can anyone tell me please how do i hide my PUBlisher ID bcoz lot of pepolz stolen others Ads n put them on thier sites.

  5. Playlist says:

    I think its not as the publisher id ca be protected with in adsense.

  6. Gloopy says:

    great article, i have uninstalled ad to any as a precaution. Who do these people think they are hiding stuff in the code

  7. Rate md says:

    If these works i think people can lose there publisher account and a lot of revenue.

Leave a Reply

CommentLuv badge

*
To prove you're a person (not a spam script), type the security word shown in the picture. Click on the picture to hear an audio file of the word.
Click to hear an audio file of the anti-spam word