feature article
Subscribe Now

Intentional Attacks

Finding IoT Device Security Holes

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

12 thoughts on “Intentional Attacks”

  1. Pingback: GVK Bioscience
  2. Pingback: porno
  3. Pingback: www.cpns2016.com
  4. Pingback: DMPK Studies
  5. Pingback: TS Escorts
  6. Pingback: friv
  7. Pingback: see here
  8. Pingback: ADME
  9. Pingback: must watch
  10. Pingback: satta matka
  11. Pingback: Aws Alkhazraji

Leave a Reply

featured blogs
Oct 16, 2019
This year, I was excited to be one of 10 Cadence employees selected from 130 applicants to participate in the company'€™s first international volunteer service immersion program with the nonprofit... [[ Click on the title to access the full blog on the Cadence Community si...
Oct 16, 2019
The top level of product categories on Samtec.com feature our Connectors, Cables, Optics, and RF pages, which give users a jumpoff point into the four main categories of products that Samtec sells. These pages were first released in 2016 with a very simple approach, to get th...
Oct 15, 2019
As technology advances, it's becoming harder and harder to know what is real and what isn't....
Oct 15, 2019
We recently participated in a presentation discussing something that is certainly creating a significant impact these days…  Read more about a cloud-ready solution available to the semiconductor industry, and then watch the video. Over hundreds, and even thousands...
Oct 11, 2019
[From the last episode: We looked at subroutines in computer programs.] We saw a couple weeks ago that some memories are big, but slow (flash memory). Others are fast, but not so big '€“ and they'€™re power-hungry to boot (SRAM). This sets up an interesting problem. When ...