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
Sep 30, 2022
When I wrote my book 'Bebop to the Boolean Boogie,' it was certainly not my intention to lead 6-year-old boys astray....
Sep 30, 2022
Wow, September has flown by. It's already the last Friday of the month, the last day of the month in fact, and so time for a monthly update. Kaufman Award The 2022 Kaufman Award honors Giovanni (Nanni) De Micheli of École Polytechnique Fédérale de Lausanne...
Sep 29, 2022
We explain how silicon photonics uses CMOS manufacturing to create photonic integrated circuits (PICs), solid state LiDAR sensors, integrated lasers, and more. The post What You Need to Know About Silicon Photonics appeared first on From Silicon To Software....

featured video

PCIe Gen5 x16 Running on the Achronix VectorPath Accelerator Card

Sponsored by Achronix

In this demo, Achronix engineers show the VectorPath Accelerator Card successfully linking up to a PCIe Gen5 x16 host and write data to and read data from GDDR6 memory. The VectorPath accelerator card featuring the Speedster7t FPGA is one of the first FPGAs that can natively support this interface within its PCIe subsystem. Speedster7t FPGAs offer a revolutionary new architecture that Achronix developed to address the highest performance data acceleration challenges.

Click here for more information about the VectorPath Accelerator Card

featured chalk talk

Clamping Down on Failure: Protecting 24 V Digital Outputs

Sponsored by Mouser Electronics and Skyworks

If you're designing IEC61131 compliant digital outputs for these PLCs or industrial controllers, you need to have a plan to protect these outputs from a variety of unknowns. In this episode of Chalk Talk, Amelia Dalton chats with Asa Kirby from Skyworks about an innovative new isolated smart switch device from Skyworks that gives you an unprecedented level of channel flexibility and protection, letting you offer customers a truly “set it and forget it” solution when it comes to your next PLC design.

Click here for more information about Skyworks Solutions Inc. Si834x Isolated Smart Switches