How To Pull Location Data From Encrypted Google Maps Sessions

Trailrunner7 writes "In the last couple of years, Google and some other Web giants have moved to make many of their services accessible over SSL, and in many cases, made HTTPS connections the default. That's designed to make eavesdropping on those connections more difficult, but as researchers have shown, it certainly doesn't make traffic analysis of those connections impossible. Vincent Berg of IOActive has written a tool that can monitor SSL connections and make some highly educated guesses about the contents of the requests going to Google Maps, specifically looking at what size the PNG files returned by Google Maps are. The tool then attempts to group those images in a specific location, based on the grid and tile system that Google uses to construct its maps."

Comments

I think...

[Lally Singh]

This is a known-cyphertext attack using the tile filesizes as identifiers. Build a database of map tiles' sizes and coordinates (x,y,z) from gmaps, then compare against the SSL response stream.

It doesn't say if it's only effective for satellite view.

Re:I think...

[ShavedOrangutan]

Satellite and Terrain tiles seem to follow similar patterns in file sizes. The 'normal' view is vast amounts of nothing. What you see in the browser is an overlay of the terrain/sat/normal PNG images plus the actual map view GIF. So you have two sets of data to analyze.

It's a lot of data. I once cached (ripped off) enough map tiles to build a mobile GPS enabled application for a small geographic area and the number of tiles is absolutely huge when you consider all the zoom levels. Triple the number of you want all three view types. If this works at all, you're looking at some serious hardware to pull it off. There's a reason Google builds data centers over hydroelectric dams.

Not to mention getting the data in the first place. Google makes it difficult to get at the raw map tiles.

Re:I think...

[unrtst]

The article says he tested with just 3 cities. As you noted, it's a lot of data. It's a hell of a lot more data if you consider the whole world. I'm VERY curious if this would work at all if your local cache of tiles had all of them?

I suspect that the number of potential matches would increase significantly if the test were repeated with the whole db... so you have to have a starting point for this to work (maybe geoip and assume they're looking locally), and at that point, what's it really worth?

Don't get me wrong... it's still a great example and could still be used to get a lot more information than one may like/imagine, but I think the demo is flawed in a way that favors it working a lot better than it would really work.

It'd also be easy to thwart by making each scale-size image the same file size (pick max file size for a tile at scale X; null pad out all other images to match that size; don't do additional inline compression on the image requests). You'd then be able to tell what zoom level one is at, but that's all (AFAICT from the article - sorry, I read it)

lucrative, how?

[eyenot]

Could anybody brainstorm as to how this could be made lucrative? I don't imagine it, somehow.

1. You're on a public wifi, unsecured, and I'm sniffing your packets, and uh oh, I'm getting information about where you are located. Wait... you're right over there. I can see you. Okay, I'm smart.

2. Okay, you're far away, and somehow I hacked your network connection, and all I see is you're using Google. Or maybe I hacked you over unsecure wifi from the public bench over here. Anyways, I can see what location you're looking *at*. So... I come up to you, and I say, "Karl... Karl, are you looking at Mogadishu, Karl? You know... we, uh, we're not allowed to look at Mogadishu, Karl. It's against whatevers. So... you're FIRED, Karl. Clean out your locker, Karl!"

Is this all plausible? What is this useful for, anyway?

"I caught you looking at the world's largest beaver dam in northern Canada. I'm going to tell the boss I caught you looking at beaver on your lunch break. Guess what? He's going to totally misunderstand. He's going to fire you. I'm going to get the partnership. I might be a douche, but, you're saaaaaaaaaaaaaaack---tuh."

Or how about this:

"Hrmmmm my opponent seems to be spending a great deal of time looking at the Himalayas. Hrrmmmmm yesssss I think I have something to use against him there. Hrmmmmm the public sentiment could be turned again.... no.... well the.... his wife would not appreesh... uh.... well.... the U.S. government has a strict policy regarding.... no.... well wtf. There's something wrong with this fuck for staring at Katchenjunga all god damn day long."

Re:Very cool!

[chrylis]

SSL is a protocol for agreeing on a set of encryption parameters to use (which cipher, what keys, and so on) rather than a cipher itself. The two most common ciphers, (3)DES and AES (as well as all the other block ciphers I know of) produce a ciphertext that's the same size as the plaintext (plus padding if necessary to fill out the block size). An SSL connection, however, frequently gzips the content before running it through the cipher, so the size of the ciphertext depends on the compressibility of the plaintext.

This is essentially what's happening here; PNG is a bitmap form, but it is supports a couple of different types of compression, so tiles of the same pixel dimensions compress to different file sizes, which can be distinguished even without knowing the contents.

Re:Not a failing in SSL

[tibit]

Well, it has to do with the underlying technology: SSL, as it's normally applied, provides you with an unencrypted side channel that leaks information that you'd like kept private. To counter it would require sending a more-or-less fixed bandwidth SSL stream, padded with pseudorandom noise. That is a fundamental deficiency of SSL and many other cryptosystems that apply to interactive uses over the web: to keep everything private, it needs a fixed (and wasteful) bandwidth allocation.

Re:Not a failing in SSL

[gnasher719]

It doesn't even have to be fixed size; if these maps were let's say between 1000 and 10,000 bytes, then round up to a multiple of 500 bytes, and only twenty different sizes get transmitted - very little information left.

Re:Not a failing in SSL

[bennomatic]

Even with only 20 different sizes, if there is enough variation between neighboring tiles, the groupings could still provide enough information to narrow things down significantly.

Re:Not a failing in SSL

[Hatta]

Why is it possible to determine the sizes of the images over HTTPS? Are they seriously opening a new connection for each and every image on the satellite map? What's wrong with opening one tunnel and shoveling everything through there?