Book review: Silence on the Wire by Michal Zalewski

Tue Apr 18 15:01:01 -0700 2006
manage

Silence on the Wire by Michal Zalewski
No Starch Press, ISBN 5-59327-046-1

Information wants to be free

The thread of thought that runs through this book is that information is like a cat. Not only does it want to be free, it will show up in the weirdest places when it escapes.

This is definitely not the everyday security book for everyday problems. You're in the target audience if you enjoy the fun of the unexpected, if you're a researcher, or if you're an intelligence professional. One chapter opens with "I've chosen to single out these two cases for the uniqueness [and] beauty", which sums up what kind of problems the book is about. This is a book for people who read about nmap's "idle scan" and want to tell all their friends about it.

Zalewski explains everyhing from the ground up and in detail. I think a non-specialist might be able to follow what Zalewski says. You'll have fun with this book. You'll also get scared and conclude that information security is impossible. One typical topic is his (apparent) favorite, recovering data streams from the blinking status LEDs on modems. Not only do you find out how you can tap a data line by using a telescope, Zalewski even includes a parts list for the necessary circuit. From there he gets more and more interesting until he's proposed a covert distributed computer running in the crevices of the Internet, never explicitly taking over any one computer but subtly leeching off thousands.

Disclosure: I got a free review copy. A different version of this review appeared on one of my blogs last year.

Covert channels, side channels, and bears, oh my!

Zalewski hits the ground running with out-of-the-box thinking about random number generators. It's normal to use keystroke timings as a source of randomness. This works well for what it does. But what if you turn the threat model on its head and ask if it's possible for an attacker to find out about keystrokes given knowledge about the random pool?

What follows is a clever example of the classic "covert channel", where two processes communicate outside the view of the OS by manipulating the supply of some shared resource like available memory. In this case a local attacker would empty the random pool (read /dev/random until it blocks) and make a note of the time whenever new randomness appears. Then the attacker has a time stamp for every keystroke.

It turns out that you can make really good guesses about what a human is typing if you know the timing between keystrokes.

Then Zalewski covers side channel attacks, for example recovering information about what key a crypto algorithm is using by measuring execution time. Power consumption is another, highly practical, example: it's a major design issue for smart cards.

Then there are unexpected interactions. There's a recurring problem with people putting "active" URLs such as delete links where the Googlebot can reach and follow them. What if someone did the same thing but maliciously? Like maybe putting exploit code for a web server vulnerability into a URL? If Googlebot has security checks for such things, do you think equal care went into the coding of spammers's email harvesters?

The chapter about reading status LEDs to deduce data is a labor of love, but falls prey to tunnel vision. Zalewski argues that the problem is ultimately insoluble. He missed the option of covering the LEDs with duct tape.

The section on network protocols is sound but has fewer surprises than the rest of the book. There's an interesting section about Ethernet frames that are padded to minimum size but none of the fascinating hidden channels Dan Kaminsky has discovered.

Of course there's a lot of material about passive fingerprinting, as you'd expect from the author of p0f.

Then Zalewski makes a switch to cover client-side security and privacy. Do you think you're protecting yourself when you turn off cookies in your browser? Martin Pool noticed that a server can send anything it wants in the Last-Modified header and you'll repeat it back exactly in If-Modified-Since, kind of like a cookie. Think you can hide your User-Agent? A server that has enough data to average out network latency can tell Opera from IE by the timing and pattern of access to elements on a page. Do you maybe think your browsing history isn't available remotely? Zalewski's research turned up work by Felten and Michael Schneider about how a web server can measure timing and find out whether you've cached a page or an image.

Did you know that port scans can betray information about the system doing the scanning? Any halfway decent scanner will step through ports at "random" instead of linearly. They tend not to use secure PRNGs though. Which means you may be able to tell from the sequence what PRNG library they're using and how long it's been since it was reseeded. And the value of the seed, which may include the system time. Then you have a time zone. Keep track of the difference between system time and real time, and you can identify repeat visits from the same attacker. All this from looking at the order of port probes [nmap defends against this sort of investigation by using a secure RNG].

The climax of the book

You can make someone else's computer do work for you legally and without hurting its security. Just send it a packet. It calculates a checksum and tells you whether the packet contents match the checksum. That's a universal logic gate. Then there's storage. Old computers used a "delay line" for storage, a gadget that didn't store data persistently but that made it reappear many CPU cycles later. You can do that today. Ping someone over a satellite link, the payload of the ping is "stored" for almost a second. Send an undeliverable SMTP message, the payload is stored for days. Put logic and storage together and in principle you have a computer, a computer built out of the cracks and corners of the Internet, one impossible to monitor, find or shut down.

More information leaks from packets

Most people read about the Time-To-Live field in a TCP header, think "OK, infinite loop prevention", and forget about it. The Zalewskis of the world notice that any given OS always sends out the same starting value of TTL and that most OS's use start values from a small set (64, 128, sometimes 255). If you get a packet with a TTL of 60 you know it came from four hops away regardless of what lies the IP address may tell you. You can use that fact to detect spoofed packets using the despoof tool Mark Loveless wrote based on an idea from Donald McLachlan. If you have two or more geographically separate systems under attack you can triangulate with the hop distances and find out where the spoofer is.

Omissions

There are several techniques with flavors that would have fit beautifully but which for some reason Zalewski didn't include.

Markus Kuhn of Cambridge came up with a way to read the contents of a display without seeing the display. For young readers, I should explain that computer displays used to be something called a "cathode ray tube" in which an electron beam lit up one pixel at a time, scanning so rapidly as to look like an image. This implies that in a room lit by a CRT the room brightness tracks the electron beam on a sub-microsecond time scale and if you sample the room brightness quickly you can reconstruct what the CRT is displaying.

Zalewski makes note of using a remote system's clock error to identify it but doesn't go into Kohno's work on using the rate of clock drift to fingerprint a remote device.

It's a little off topic from computers and networks, but the technique of "transmitter fingerprinting" is in the same spirit as Zalewski's work. Transmitter fingerprinting looks at startup changes in a radio signal to identify the particular transmitter.

Rapid changes

Zalewski presents beautiful hacks, but they are hacks, and hacks have a short shelf life. His tools for locating the source of a denial of service attack have been superseded by crooks using botnets. The crooks don't care if one of their machines gets hunted down because they can get replacements for a quarter of a cent each. His work on recovering data from status LEDs worked on slow devices like modems but seems unlikely to be effective on gigabit Ethernet cards.