Hey, everyone – have you heard? Security: it’s a thing. Of course, the internet is a thing, and, well, things are things, and the internet of things is a thing… but security on the internet of things (IoT)? Yeah, that’s still a work in progress, with dreams of becoming a full-fledged thing when it grows up.

I know, the interwebs have used untold amounts of digital ink in the service of security. Although, truth be told, most of that ink is used in pieces reminding us that security is important and that the lack thereof is a problem. There’s less in the way of actual solutions. But… all in good time, right?

A huge question that every designer of IoT things must ask is, “Is my security bulletproof?” After a good chuckle (nothing is bulletproof), you restate the question: “Where are my vulnerabilities?”

This question reflects a newer way of thinking about security, and it echoes a change in approach that happened with network security some years ago.

From Intrusion Detection to Intrusion

Ten or so years ago, in the network-processing world – where processors were (and still are) designed specifically for handling network data packets – intrusion detection was a thing. You could monitor incoming packets to figure out if something looked fishy. Detection systems might flag suspicious traffic and fire off a message to somewhere else in the system; it could then go back to monitoring.

And at some point “detection” gave way to “prevention” – instead of just alerting, a system might block certain traffic, for instance.

But here’s the thing with those approaches: you’re setting up defenses to catch attacks in progress. Let’s say there are 400 ways to attack the network; you probably know about some subset of them, and you might choose to actively defend against some subset of the ones you know about. But when a detection system gets its hackles up, of those 400 possible attacks, you’re actively dealing only with an attack that’s happening right now. Never mind the attacks you’re not even aware might be possible.

That approach has changed, and the change is claimed by a company called Rapid 7. The mind-shift was as follows: instead of looking for an attack in progress, how about we act like an attacker and try to expose every possible weakness in the system? It’s like a doing a controlled burn on the network: you’re lighting fires to figure out where the dry tinder is so that you can get rid of it before a bolt of lightning (or some other attacker) gets to it.

So you got a tool that was an automated attacker. Except that, instead of bringing down the system, it reported on what it found so you could patch the holes.

Examining Your Thing

That’s at the network level. If you’re designing IoT things, then your world is very different. Network folks can standardize and collaborate to keep networks safe, but embedded systems come in all different shapes and sizes – literally. Each has its own set of vulnerabilities. General notions of what makes things secure or not can apply across the board, but the specifics are much more individualistic.

So what if you could take the same approach to gauging how impenetrable your system is? What if there were tools that would automate attacks and give you reports on where your vulnerabilities lie?

There is (at least) one such set of tools taking this approach, provided by Tactical Network Solutions (TNS). Called Centrifuge, it places specific focus on firmware, ferreting out known weaknesses. Exactly what they look for is evolving, but they’ll freely note that they’ve started with low-hanging fruit. Why? Because there’s a lot of it out there.

And why is there a lot of it out there? Could be a lot of reasons, but, in particular, they find constant pressure to ship systems – which means cutting corners where necessary. There’s also the “other stuff on the network is not my problem” mentality.

Centrifuge performs three major analyses: library, code, and crypto. And they do this starting with as little as the extracted firmware binary. Yeah, if someone wants to give them all the source code, then the work is easier, but… in the end, they’ll get the code.

They described two engagements, both with encrypted firmware. In the first case, the manufacturer wanted their analysis, so they turned over the key to decrypt the code. In another case, they got a set-top box – and nothing else. They were able to extract the code.

So, once they have the code, they reconstruct the file system. They can then look to make sure that libraries aren’t compromised, weak coding practices aren’t used, and keys aren’t discoverable.

With respect to coding, they have an image of a report on their website, and all of the flagged calls are variants of strcpy, memcpy, sprintf, sscan, and such – likely done without bounds checking, making them vulnerable to buffer overflow attacks.

As to the crypto analysis, apparently it’s not unusual for a designer to hard code a key into the firmware. They gave one example of an automotive ECU where they pulled out the key, modified it, reloaded and re-encrypted the code – effectively taking future control of that unit. (Of course, the tool doesn’t do all that – they were able to do that with help from the tools.)

(Click to enlarge; image courtesy Tactical Network Solutions)

Other analyses planned in the next 3-6 months will include checking for hard-coded usernames and passwords– yes, apparently that happens – and for CGI files with unauthenticated web access.

One thing they pointed out is that this is not conceived as a tool for bringing legacy code up to standards. This is for new, fresh code. What they’re finding is that coders coming out of school have not been taught how to code securely.

As to what the next steps are, given a report with identified weaknesses, well, that depends. And this is where they point to their education services as a complementary offering – for improving future code as well as repairing existing code.

At present, they can handle code for x86, MIPS, and ARM processors under Linux or QNX operating systems. More RTOS coverage is planned for the future.

For designers looking to confirm that they’ve got a rock-solid system, tools like this can help. Of course, for designers not yet convinced that this stuff is important… actually, it might help also, by proving that “hidden” secrets tend not to remain hidden.

More info:

Tactical Network Solutions