A SOHO Router Security Update

Commentary::Network
Audience::All
UUID: 6cb54b70-6f80-4959-bb8b-c8d20fc07e93

In April, 2014 I published Heartbleed Will Be With Us For a Long Time. One point of that post was the miserable state of SOHO router security. I referenced /dev/ttyS0 Embedded Device Hacking, pointing out that /dev/ttyS0 has been beating up on these devices for years. If you don't feel like reading my original post, the takeaway from that portion of the post is as follows.

Until proven otherwise, you should assume that the security of these devices is miserable. I have private keys for what seems to be 6565 combinations of hardware/firmware combinations in which SSL or SSH keys were extracted from the firmware. In that data, 'VPN' appears 534 times.

The database was hosted at Google Code, which Google has announced will be shutting down. I am interested in the rate at which embedded system security is becoming worse (as it demonstrably is) and meant to urge /dev/ttyS0 to migrate, if they hadn't already done so. I wanted the resource to remain available to researchers. Google Code doesn't seem to provide (at least in this case) a link to where migrated code might have gone, but searching GitHub turns up four repositories. Apparently I am not the only person interested in the preservation of this work, and the canonical /dev/ttyS0 repository is still available.

/dev/ttyS0 also has a blog. Visiting that today, I find that they have recently been beating up on Belkin and D-Link. That's a bit sad, because in simpler times, I carried products from both of these vendors in my hardware case.

There is no room for sentimentality in this business. But there is room for keeping track of trends, and gazing into an always-cloudy crystal ball, trying to extrapolate trends, and spot emerging threats. Sometimes that is ridiculously easy; I hereby predict:

a) the Internet of Things will be a source of major security/privacy breaches in 2015 [1]
b) consumers will neither know nor care, in any organized manner
c) businesses will continue to buy 'solutions' that are anything but

In short, things will continue to get worse, at an increasing rate, as they have always done.

[1] I often tell a simplistic story (to non-practioners) about how I came to be interested in security and privacy, equating the two as a simple scaling matter. Privacy is security on a small scale, and the obverse. That is not actually true; there are technical differences, down to the level of which attacks are possible, let alone which matter. But that is a whole different post.

Well, I Thought I Had a Spare Drive

But it turns out that my spares collection is FUBAR. Here's the thing. I was planning on rebuilding a lab system this weekend. I have always enjoyed messing with hardware of one sort or another, I've built many systems over the years, and I have a bit of an ingrained work flow optimized for minimal SOHO office disruption, etc. Move that pile of books out of the corner and re-shelve, fill in the space with the parts collection, etc.

The parts collection was where I ran into a bit of snag.

I get a bit uncomfortable when I am down to a single spare general-purpose SATA drive. For RAID, things are a bit more complex, as I like matching firmware versions, and I also like to keep a pristine portable drive around. What I have is a new factor, in that I can't use a basic 1 TB Caviar Black. It's been sitting for several years, still in original packing. The only thing I've ever done regarding this drive was to print the output of uuidgen(1) and purchase details, and stick it into the bag. Due to the nature of my work, I need to unambiguously track which hard drives are used by which systems. Which is a topic for another post.

Now, this drive has to be sequestered, because I seem to have built up a collection of performance notes which involved I/O to an identical drive. I may want to revisit those numbers, well after the normal life of a drive, and it is worth it, to me, to remove a variable from any comparison I might care to make. An opportunity to reduce the complexity of a future data analysis, for the cost of a consumer hard drive, is a no-brainer.

So I'm down to one consumer hard drive. If I use it, I will have no spare until a replacement arrives. That isn't something I would do, except in an emergency, which this isn't. I could just drive into town, buy one, and get on with the job. But it is probably wiser to buy three online; the odds of getting identical firmware are good, so I get more down-the-road flexibility. I could make a reasonable case for buying six, and may do that.

That's a bit of a bummer, as I did want to get that hardware upgrade done this weekend. If, for whatever reason, it can't happen next weekend, then it is no longer a casual, do it ahead of the need thing. It rises to the level of Important. Murphy is alive and well, and all it will take is a call from a client.

This sort of thing is best avoided, and that it happened in this case is my own FUBAR. I failed to allow for all the factors that might influence the effective size of the spares pool. That informal work flow bit me, and better systems administrators than I can now commence laughing. Lesson learned, and I hope that others do not make the same mistake.

Is IPv6 Coming To Your Network?

A year or so ago, I recommended a couple of things to a Network Security Guy (and a friend of mine). First off, have a look at R. I think I dealt with that one (Choosing Python over R) earlier today.  But this guy also believed that Intrusion Detection/Prevention systems are highly effective. Probably because he implemented one years ago that met the needs of the times. Evolve, plz.

I didn't then, and certainly don't now (attacks only get better), have any confidence in IDS/IPS, and also recommended that he have a look at Evader. Apparently, a year down the road, he had done neither of these things. So be it--this was just a breakfast conversation with a friend, and really none of my business.

Today, I had a conversation with another Network Security Guy (and another friend of mine) who had a serious need to vent. For reasons unknown (but it seems likely that some senior manager had read some scare-piece about IPv4 number exhaustion), a mandate had come down from on high, that IPv6 Would Be Implemented in 2014. Behind the firewall.

Heavy sigh, and all that. But what this guy, who was in more of a managerial position, was concerned about was that it was going to thrash his tentative 2014 hardware budget planning, which was already late. Well, yes. It surely will thrash his hardware budget planning; IPv6-capable network infrastructure requires more horsepower, and economies of scale are not yet present.

Here is the FUBAR bit, and I felt bad about dropping this one him, because I had worked with one of his Evil Minions on setting up some basic defenses, years back.

• Yes, your hardware will cost more 
• IDS/IPS systems will be even less effective that they were under IPv4
• Internal network scans will no longer be effective
• Pretty much nothing of your current notions of VPN security will (or should) survive

This is off the top of my head. I could get creative, and start thinking about, for example, PBX and video-conferencing systems.

IPv6 is coming, but there is already sufficient pain. It is likely that every aspect of your network security posture will have to reevaluated, via whatever risk-analysis methodology you prefer. What is certain is that a valid reason for deploying IPv6 almost perfectly does not resemble management by proclamation.

We know that waiting until the last moment will only make it worse, and that proclamations lead to FAIL. So, please, start thinking (rationally) about it now. You are far more likely to be ready when you have a real roll-out date.