Slashdot Mirror

← Back to Stories (view on slashdot.org)

How To Pull Location Data From Encrypted Google Maps Sessions

Posted by Soulskill on from the step-one-create-1:1-model-of-the-earth dept.

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."

28 comments

  1. Not a failing in SSL by Anonymous Coward · · Score: 1

    This is an example of an algorithm to guess based on image sizes based on knowledge of the system that Google uses to send map information, there is nothing wrong with the underlying technology. Google could easily stymie this if they wanted to. Moderately interesting, but not really news-worthy.

    1. Re:Not a failing in SSL by tibit · · Score: 4, Informative

      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.

      --
      A successful API design takes a mixture of software design and pedagogy.
    2. Re:Not a failing in SSL by gnasher719 · · Score: 3, Insightful

      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.

    3. Re:Not a failing in SSL by bennomatic · · Score: 3, Insightful

      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.

      --
      The CB App. What's your 20?
    4. Re:Not a failing in SSL by Hatta · · Score: 2, Insightful

      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?

      --
      Give me Classic Slashdot or give me death!
    5. Re:Not a failing in SSL by DarkOx · · Score: 1

      I don't know that it needs to be fixed bandwidth. For things like speech were rates of pauses can yield information absolutely. I would expect most attacks like this one could be thwarted with noop commands padded with random number of enough random bytes to put them within a few standard deviation of the applications typical transaction size, sent at a random internal again within what would be an expected rate of human interactions for the protocol.

      That still will result in the transmission of lots of junk but probably not nearly as much as a fixed stream, for apps like Google maps and online banking and should provide as much protection.

      --
      Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
    6. Re:Not a failing in SSL by Anonymous Coward · · Score: 0

      That's actually a lot of information, over the course of a session -- it does introduce some ambiguity, but each image still matches one exact size, so you can correlate a burst of images with matching regions (from panning, it'll generally be a horizontal or vertical strip, or an L-shaped region if panning diagonally; from zooming, it'll be a rectangular region), make some assumptions (e.g. only look for matches in the local region, or if you catch the start of a session, assume the first few steps are zooming down from Google Maps' default whole-US view), keep track of multiple possibilities and rule them out when a subsequent burst doesn't match any reasonably likely panning or zooming motion.

      It's not easy, and would work best post-processing an entire session, rather than real-time, but it would still be possible. Adding some random size (rather than rounding up to an exact size) would probably be a better solution; your way breaks the (nearly) one-to-one mapping of tile to size, but random padding destroys it entirely.

    7. Re:Not a failing in SSL by Anonymous Coward · · Score: 0

      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?

      Because "everything" is the entire planet. Ever wonder how you can scroll over such a large area so rapidly? The map consists of a set of tiles.and as you move in any given direction, new tiles are fetched. The exploit consists of attempting to guess which tiles were fetched.

    8. Re:Not a failing in SSL by maxwell+demon · · Score: 1

      Well, it could randomly pad to larger sizes. That's still less bandwidth than using the maximal size consistently, but you can't tell if a large size is a large tile, or a small tile randomly padded. Especially you'll not get a deterministic pattern; the same view may have dramatically different sizes.

      --
      The Tao of math: The numbers you can count are not the real numbers.
    9. Re:Not a failing in SSL by Anonymous Coward · · Score: 1

      You can guess by the size of the ip packets. As they are not fixed. The meta data for the tcp packets is basically 'in the clear' (size destination etc). Given that meta data you can 'infer' that it is a small subset. Then give other similar sized packets you can narrow it down to exactly what they are looking at. This does require you however to have a LARGE subset of the data already mapped out.

      Didnt read the article. But that is my guess of how they did it.

    10. Re:Not a failing in SSL by Rei · · Score: 1

      The US learned a frustrating lesson about this in the 1980s when they discovered that this was precisely how the Soviets were listening into our communications in our war games exercises.

      Of course, we had a number of fun ways to listen in on them that they either didn't know about or kept forgetting about. Like how, for example, the radio signals on early mobile phones didn't just propagate laterally (which they were very careful about), but also up. And can be heard from really far up, if you have a good enough ear in orbit ;)

      It was always fun, chatting with an old friend who served in military intelligence during the Cold War.

      --
      Windmills do not work that way!
    11. Re:Not a failing in SSL by Lennie · · Score: 1

      SPDY to the rescue ! :-)

      --
      New things are always on the horizon
  2. I think... by Lally+Singh · · Score: 2

    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.

    --
    Care about electronic freedom? Consider donating to the EFF!
    1. Re:I think... by ShavedOrangutan · · Score: 2

      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.

      --
      Godaddy is a scam and a ripoff.
    2. Re:I think... by unrtst · · Score: 2

      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)

    3. Re:I think... by Anonymous Coward · · Score: 0

      I made overlay tiles for 6 zoom levels over just a 4 square mile area, and it's 50MB. The further in you go, the bigger the data get.

  3. Very cool! by SultanCemil · · Score: 1

    So perhaps I'm new to this game - but this is a pretty cool hack. Using the sizes of PNG files over an encrypted channel to locate someone is pretty nifty.

    For those who know more: is SSL encryption predictable (size-wise)? If I have the same size payload, will it always generate the same size encrypted result?

    --
    Cemil.
    1. Re:Very cool! by chrylis · · Score: 2

      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.

    2. Re:Very cool! by Robert+Zenz · · Score: 1

      First, it's not a hack. Second, you can only *guess* at what region the client is looking, not where the client is.

  4. lucrative, how? by eyenot · · Score: 5, Funny

    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."

    --
    "Stratigraphically the origin of agriculture and thermonuclear destruction will appear essentially simultaneous" -- Lee
    1. Re:lucrative, how? by vidnet · · Score: 1

      Your boss could keep track of where you plan to go if you use the office network, and he can keep track of where you are if you have VPN enabled on your phone or tablet and use Google navigation software.

      "You're not looking up addresses of our competitors, are you Karl? You know, we don't tolerate disloyalty here at the company. And did you visit a.. gentleman's club after hours yesterday? We're a family company, Karl. We need all employees to represent our family values at all times, also outside work."

    2. Re:lucrative, how? by Anonymous Coward · · Score: 0

      Must...not...check...location...of...secret bunker. Must...resist...temptation.

  5. Always cool...but useful? by gimmebeer · · Score: 1

    An interesting take on attacking an SSL stream, but like said above how useful is this really? As the first reply said, it does sounds like a known-plaintext attack in that you know to look for a certain number of bits, and when taken together with other certain numbers of bits you can deduce the area of the world being viewed. Seems mostly academic, unless you're law enforcement or some other such entity who is recording traffic from a known bad guy and trying to determine his next target... (which then again is sorta what counter-terror units do these days)

    1. Re:Always cool...but useful? by Anonymous Coward · · Score: 0

      Its also potentially useful for counter-terrorism in the reverse manner. If you have know which maps are for high value targets, you might track who's accessing those maps and investigate. A lot of false positives that way.

      Perhaps something on the real estate front, tracking how often land of interest is being checked out by others via Google Maps.

    2. Re:Always cool...but useful? by Mithent · · Score: 1

      True. There are some fringe uses, but mostly you're just going to be intercepting someone planning how to get to their meeting tomorrow, or looking for the nearest Starbucks. You'd have to have a target in mind before it would be worthwhile spending the computational resources.

  6. Knapsack problem by drolli · · Score: 1

    by bundling tiles randomly google could make this approach much harder - if they accept that sometimes its a little slower.

  7. Solution? by Anonymous Coward · · Score: 0

    Or they could switch to using SPDY as they have on other services. There would be only 1 TCP stream, so no logical boundaries outside the SSL wall.