Brian M. Waters’ Unencrypted

On Learning how to “Hack”

So I just returned from DEF CON 23, which, if you’re not already aware, is basically a days-long drunken hacker party disguised as a conference. I ended up spending a lot of time at the “Internet of Things” or “IoT” village, where attendees try their hand at compromising crappy Best Buy-grade consumer electronics like SOHO (that’s small office/home office) routers, storage devices, baby monitors, and other mostly useless crap like “smart fridges” and Internet-connected doorknobs (seriously - what!?!?!). Needless to say, the security situation for most of this stuff is not good. The slogan for the area was “SOHOpelessly broken,” and the organizers were encouraging random people to try and find 0-days in various products they had brought along. I managed to find one in a very small surveillance camera advertised as “Simple. Smart. Secure.” (Good one.)

The flaw was a shockingly obvious authentication bypass via cross-site request forgery; one so ridiculous that several friends later suggested it had to be some sort of intentional back door. (I think it has more to do with a market segment that prioritizes price and time-to-market above all else, but that’s another story.) I managed to recruit a few other helpful folks, and we set forth trying to escalate a simple authentication bypass to a root shell. We ended up with full, remotely exploitable, firmware flashing pwnage. (I’ll post the details here after we notify the vendor.)

During this session, a guy came over who seemed to think I was some kind of 1337 w!z0rd h4xn0r (I’m not), asking how I learned to “hack” and how the exploit worked. He proceeded to whip out a pen and paper and take notes, as if the details of an obscure vulnerability in a cheap home camera were something worth committing to memory.

I think by “hack” he meant “gain unintended access,” and for some reason he made me think about technical education and how I got here to begin with. There are a lot of books out there with black covers and titles like “[insert system here] Hacking Secrets” and “The [insert system here] Hacker’s Field Manual” that claim to teach these kinds of skills. I have a number of these on my shelf, and I haven’t read any of them. They are mostly tutorials on specific (albeit useful) tools, or documentation on well-known bugs that are probably mostly patched by now. A few explain generally-useful techniques like ARP cache poisoning, and none contain any information that could be used outside the scope of “hacking” or defending.

The problem with this approach is that, in focusing on specific techniques, these books simultaneously avoid explaining the total context of whatever system they’re about, and deprive the reader of any chance at creativity by giving away all the answers on how to “hack in.” Rather than reading a book on “hacking networks,” for example, consider reading a book on networks. You will probably re-invent a few well-known techniques yourself (and feel good about yourself for doing so); moreover, you’ll have a much deeper and more generally useful understanding when you’re done. Reading a tutorial on using yersinia to become the spanning tree root bridge might earn you some serious pwnage, but it doesn’t teach you anything about running an STP network or why STP is important.

More importantly, the ground-up approach teaches research skills and critical thinking, and can give learners the confidence they need to find new flaws that aren’t in any of those books yet.

So, future 1337 h4xn0r man I met at DEF CON, if you’re out there and reading this, head to your local university library, grab a crusty old book on network protocols or UNIX programming (or a shiny new one on web development), and get to work. You might even enjoy yourself.