Transmissions
by Dragorn
Lean back and remember the 1980s (if you can), or complain about old people always talking about "the good old days" if you can't (and while you're at it, get off my damn lawn with your rap music and your skateboards). Imagine... a cheesy flashback ripple effect... Think back... Back to the days of big hair, ripped jeans, GI Joe being just a cartoon, synthesizers, and shared media networks.
Shared media networks - the predecessors of modern switched networks - were a hacker's playground. Instead of virtual circuits between the systems communicating, every system on the network got the packets from every other system. Anything anyone else on your segment did was visible, and anything you did could affect all other users on the network.
Too bad the good (which is to say, bad old days are long gone, right? We'll never see their like again. Everything now is switched, protected, encrypted. I'll just take my laptop and go sulk at the coffee shop and leech a little free Wi-Fi. Free, unencrypted Wi-Fi. Where all the users are on the same channel. Sharing the same network. On a shared physical medium. That's right, Wi-Fi is a time machine to the 1980s. All the old tricks work, we just need to tweak them around a bit.
Most likely the best trick that most of us have forgotten all about is TCP session hijacking. TCP is only "secure" (that is, secure from being spoofed from random attackers) in so much as it uses a random sequence number. The sequence number is used to ensure that all packets are delivered, that the packets are delivered in order, and that the packets came from a host which knows the proper sequence. Without this sequence number, packets which claim to be part of a connection are discarded. On a shared network like open Wi-Fi, this number is by no means random or unknown.
Performing a TCP hijack is the same as it's ever been: Capture packets, extract the sequence number, and reply quicker than the foreign system. Every TCP connection goes through a handshake stage where the client and server exchange sequence numbers and establish the connection, and packets sent from then on advance the sequence number by the number of bytes sent.
Sessions can be hijacked at the beginning of the connection by spoofing the remote system during the handshake process, but they can also be hijacked in the middle of a stream by beating the next legitimate packet. A local attacker is closer, and therefore able to respond more quickly than a remote host which can be thousands of miles and many routers away, each hop taking more time to navigate. Exploiting this allows matching things like HTTP requests and replacing them. In fact, exactly this attack was shown about five years ago at DEFCON in Airpwn by Toast... and then promptly forgotten as anything other than a method to make people look at Goatse.
The obvious risk from this (and one many attendees of DEFCON learned to their dismay) is replacement of any web content with any other arbitrary content. Unfortunately, this is by no means limited to simply pranking. When a TCP session is spoofed, it is indistinguishable from traffic coming from the legitimate host. Arguably, timing might reveal that the packets are coming from a closer source than a physically distant remote host, but for all practical purposes a client application will have no chance of detecting a spoof attack. The HTTP security model is generally based around the idea that only JavaScript code which is part of a page, or which is included by a page, is allowed to alter the page. Cookies are based on domain controls so that only websites which appear to be the proper domain can access them. Browsers such as Chrome segregate individual pages into separate instances to prevent cross-contamination.
All of these protections are eliminated when surfing an unencrypted website on an open network. Most modern Ajax-ified "Web Two Point Whatever" pages include helper JavaScript (and often, dozens of helper JavaScript) files when they load. Any one of those JavaScript helper files has privileges to control the content of the website. By delaying the TCP session hijack until the handshake is completed and the user has requested a file, it becomes easy to target specific files (for example, a tracking/statistics file from a popular company which rhymes with "moogle").
So, someone has fed you a poisoned JavaScript file. What can happen to you? Just about anything. Having your browser fed a selection of the latest exploits is one obvious result, but once inside the DOM it becomes trivial to rewrite the content of pages on the fly, opening a variety of possibilities.
For example, replacing every HTTPS link with the unencrypted HTTP equivalent:
Once inside the Document Object Model (DOM), redirecting forms, poisoning links, extracting cookies, and loading additional attacks becomes a trivial, but major, risk.
The chances of picking up something unpleasant from public networks is compounded when you consider the risks of the browser cache. Files loaded in the background are just as cacheable as normal web pages. Think about that one again, slowly. JavaScript helper files, which we just saw being altered for fun and profit, can be set to cache. Once cached, a hostile file will remain until the browser cache is cleared, the cache expires, or the page using it changes to include another file.
Detailed by Robert Hansen at www.sectheory.com/rfc1918-security-issues.htm, controlling the cache of a page on an insecure network can lead to control of secure content later.
The cache is controlled by the HTTP headers. The HTTP headers are, of course, returned as part of the TCP stream. When the TCP stream can no longer be trusted, no content can be considered safe. Even websites which normally are not considered trusted, because they don't require a login, or aren't something you care about (if, for some inexplicable reason, you don't mind someone having one of your logins somewhere), may now lurk, waiting for an opportunity later.
Once in your cache, a hostile file can call home each time it's loaded. This might be when you're at home, or at the office. The spiked file may do nothing for a month, acting completely normally, until a new browser vulnerability allows a takeover of the whole system. Even without exploiting the browser, purely browser-level issues such as wrapping all future browsing in an <iframe> can still compromise sessions.
These risks are inherent in any open network, and avoiding them is very difficult.
The only way to avoid bringing home something unexpected from the coffee shop Wi-Fi is pretty much the same as the precautions you should be taking already, with one notable addition: Use a VPN or SSH tunnel for all traffic. The addition? Use it for all traffic.
Even "low-trust" web pages remaining in your cache indefinitely until the next browser 0-day hits and they include a new attack via a cached callback. Simply clearing the cache or setting the browser to not cache may prevent retaining poisoned content, but that won't prevent local attacks from working in the first place.