Geode, Loki and the implications

The cruel details

After playing a little, I wanted to see how exactly the whole thing works. Fortunately, XPI is just a ZIP with another name, so there was not much voodoo involved in getting sources for the plug-in. However, the underlying technology is only so much of an open-source solution, since it uses a proprietary DLL / dylib file for the actual geolocation. That DLL is provided by Skyhook Wireless via their subsidiary, Loki.

Skyhook is also behind geolocation in a wide array of other products, including both iPhone and iPod Touch. Basically they have a map of coordinates for access points and GSM towers and that map is really, really huge. Coverage even here in Germany is pretty OK for a cellular network with such small cells. Remember the size of Wifi cells - we have over 400 on our city-wide university campus alone, and there is probably another 5000 in the rest of the city.

Skyhook distributes an SDK for developers, and its approach for laptops and desktop computers makes exclusive use of the wireless radio. That means: you have to have a Wi-fi adapter and it has to be activated or you’re out of luck. In addition, it seems that currently not every adapter is automatically supported - I couldn’t get the SDK examples to work on my EEE, however the Geode FF addon worked without a problem. The worrying part is: Why can a Firefox plugin access my network adapters on a level that low? If it can do that, what keeps it from sniffing packets and retransmitting them to whoever?

Location-enabled web sites and you

Anyway, the general topic is “location-enabled web sites”. What happens if you stumble upon one of these sites is basically this:

1. Webmaster of blah.com thinks it’s a great idea to know where his visitors come from. He includes either Geode or Loki JS in his page sources (two-liner, no rocket science).
   
2. Website blah.com requests your current location upon you visiting it.
   
3. If at all allowed (I will go into further options in a second), the plug-in makes a callout to the platform-specific closed-source Loki DLL.
   
4. That DLL checks if a wireless adapter is present and enabled.
   
5. If so, it (I have no friggin’ idea how) attaches to that wireless adapter (be it connected to an AP or not) and scans for available access points.
   
6. These APs are then stuffed into an associative array that contains the MAC -> signal strength tuple, like this: AA:BB:CC:DD:EE:FF -> -43 (signal strength is in dB, methinks).
   
7. That array is then stuffed into a lengthy XML request that also includes a basic authentication block (for API keys) and that request is fired off to skyhook.com.
   
8. If possible, Skyhook replies with exact coordinates. That might take a couple of iterations.
   

There’s a couple more details, like a geolocation request that contains the IP address and uses “traditional” GeoIP technology, but encapsulated in the same API, but let’s omit that stuff. GeoIP sucks balls anyway.

The plugin requires you to nod off any location requests made by web sites and thus supposedly keeps your privacy. Also, it allows you to set a preference if the site requesting is only allowed very general information (city) or a more detailed location (block or house level). This fuzzing is actually performed inside the addon by applying some geographic transformations to the precise coordinate that is returned by skyhook.

So, what happens technically? The Firefox addon more or less uses the Loki API to create a new property of the navigator object that has a small number of methods. These can then be conveniently called in normal JS code and return a set of coordinates or predefined error codes. You (the end user) can keep a list of all sites that are always allowed to obtain your location.

The Abuse Potential

So, what are the attack or the potential for abuse? I can, OTOH, see a whole bunch of them.

The marketers

First and foremost, the ones that will be delighted by this addon (or the consequential integration in mainline Firefox) will be marketers of all sorts. Finally, you can track down your web site visitors on an address level! This offers all kinds of cool (read: crooked) marketing possibilities. So I expect the banner sellers and Google to be among the first to adopt geolocation into their ad code. This could work by for example putting the ad code in an iframe (which it currently is, at least for Google Adwords IIRC) and have the location call in there. The charming idea about this is that each time a web site would contain adwords code (and that code contains a geoloc call), the geoloc call would originate from adwords.google.com. That also means that after a (presumably very short while) everyone would be immensely pissed off with constant “website adsense.google.com wants to know where you are” alerts and do what? Right. Default enable.
There we go, free ride for Google. So, now advertisers on your web site know exactly where your visitors are from and can target them even better. Next up: Site statistics.

The statistics

Same concept: Put a geoloc request in the Google Analytics code and that code in an iframe. All geoloc calls come from analytics.google.com and - shazam - web site owners know where you are. Combined with archetypical end user laziness, all web site owners that use Analytics will soon know where you are.

Spicing up web attacks with Geolocation

There’s another - although maybe a bit far-fetched - scenarios that I came up with. Given the fact that Cross-Site Scripting is everywhere, it can easily be argued that attackers possess the ability to include arbitrary JS in a large number of “trusted” sites. I think I still sit on an XSS somewhere on nytimes.com that I never got round to disclose (big corporate monster with a lot of hierarchy before you can actually talk to a web app tech person) and there’s likely others. These holes are also bound to be in sites with legitimate uses for location-based services. An oft-cited idea is for newspaper sites to have truly “local” ads and articles based on where you currently are. This is, of course, already a borderline case (think “you are not allowed to view this page since you are in an unlicensed location” as BBC does with their video streams), but my point is that in those cases, visitors have already allowed the site to access their location.
Attackers can then easily embed their own two-liner that just takes the coordinates and pushes them somewhere else.

Why is this dangerous?

If someone knows where you are, why is that dangerous anyway? You don’t have a mistress and you don’t work in a brothel or something, so why should you care? I think you should and I have a couple of examples why I think so.

Burglr 2.0 beta

Imagine this scenario. You are an avid fan of geolocation and geotagging. Your iPhone has geotagging activated for the Camera application. After buying a new TV, you snap it with your iPhone and put the image (including coordinates) onto a gallery web site of some sorts, Flickr or whatever. Then there’s this guy who uses the on-site search to search for “my new TV”. He picks up your picture and sees the coordinates. Now, he knows where that shiny 50“ plasma is. So far, so good. The attacker wants that TV. He also finds that there is an XSS flaw in the gallery site’s comment function So, he comments something like ”your TV sucks ass, mine is better" and includes the geo-location two-liner as a hidden Javascript.
You read that comment and are incensed. However, you’re at work and can’t comment like you would like to (boss is breathing down your neck). The attacker now has a set of coordinates that indicates you are 10 miles away from the TV. He concludes that your TV is currently unattended and proceeds with a real-life burglary.

Lower-profile XSS network reconnaissance

Again, take an XSS hole somewhere - maybe a extranet groupware solution or something like that. You can access that from within your company’s local network, but also when you’re abroad. Since your admins aren’t very tech savvy, there is no VPN, but there’s SSL to make eavesdropping harder. An attacker now wants some insight into your local network and proceeds to write an JS portscanner. The current approach - at least to my knowledge - includes brute forcing the IP range and just trying wildly. By checking the location, the attacker could deduce whether or not you are on the road and refine the possible approach vectors accordingly.

Wrapping up

I know that there is a ton of interesting and legitimate applications for geolocation. Hell, I use some of them myself. There’s also a ton of interesting apps for geolocation of non-portable devices. However, a little devil in the back of my head constantly screams “abuse potential!” at me. And - since some of you might think “how is this new? Loki existed for years” - the possibility of having a software like that in main line browsers adds a new dimension to the whole idea, in my opinion at least.