Design A Microcontroller With Security In Mind

December 15, 2017 by Roger Cheng 22 Comments

There are many parts to building a secure networked device, and the entire industry is still learning how to do it right. Resources are especially constrained for low-cost microcontroller devices. Would it be easier to build more secure devices if microcontrollers had security hardware built-in? That is the investigation of Project Sopris by Microsoft Research.

The researchers customized the MediaTek MT7687, a chip roughly comparable to the hacker darling ESP32. The most significant addition was a security subsystem. It performs tasks notoriously difficult to do correctly in software, such as random number generation and security key storage. It forms the core of what they called the “hardware-based secure root of trust.”

Doing these tasks in a security-specific module solves many problems. If a key is not stored in memory, a memory dump can’t compromise what isn’t there. Performing encryption/decryption in task-specific hardware makes it more difficult to execute successful side-channel attacks against them. Keeping things small keeps the cost down and also eases verifying correctness of the code.

But the security module can also be viewed from a less-favorable perspective. Its description resembles a scaled-down version of the Trusted Platform Module. As a self-contained module running its own code, it resembles the Intel Management Engine, which is currently under close scrutiny.

Will we welcome Project Sopris as a time-saving toolkit for building secure networked devices? Or will we become suspicious of hidden vulnerabilities? The researchers could open-source their work to ease these concerns, but value of their work will ultimately depend on the fast-moving field of networked device security.

Do you know of other efforts to add hardware-assisted security to microcontrollers? Comment below or let us know via the tip line!

[via Wired]

Image of Mount Sopris, namesake of the project, by [Hogs555] (CC-BY 4.0)

Aussies Propose Crackdown On Insecure IoT Devices

October 16, 2017 by Jenny List 36 Comments

We’ve all seen the stories about IoT devices with laughably poor security. Both within our community as fresh vulnerabilities are exposed and ridiculed, and more recently in the wider world as stories of easily compromised baby monitors have surfaced in mass media outlets. It’s a problem with its roots in IoT device manufacturers treating their products as appliances rather than software, and in a drive to produce them at the lowest possible price.

The Australian government have announced that IoT security is now firmly in their sights, announcing a possible certification scheme with a logo that manufacturers would be able to use if their products meet a set of requirements. Such basic security features as changeable, non-guessable, and non-default passwords are being mentioned, though we’re guessing that would also include a requirement not to expose ports to the wider Internet. Most importantly it is said to include a requirement for software updates to fix known vulnerabilities. It is reported that they are also in talks with other countries to harmonize some of these standards internationally.

It is difficult to see how any government could enforce such a scheme by technical means such as disallowing Internet connection to non-compliant devices, and if that was what was being proposed it would certainly cause us some significant worry. Therefore it’s likely that this will be a consumer certification scheme similar to for example the safety standards for toys, administered as devices are imported and through enforcement of trading standards legislation. The tone in which it’s being sold to the public is one of “Think of the children” in terms of compromised baby monitors, but as long-time followers of Hackaday will know, that’s only a small part of the wider problem.

Thanks [Bill Smith] for the tip.

Baby monitor picture: Binatoneglobal [CC BY-SA 3.0].

Practical IoT Cryptography On The Espressif ESP8266

June 20, 2017 by Sean Boyce 44 Comments

The Espressif ESP8266 chipset makes three-dollar ‘Internet of Things’ development boards an economic reality. According to the popular automatic firmware-building site nodeMCU-builds, in the last 60 days there have been 13,341 custom firmware builds for that platform. Of those, only 19% have SSL support, and 10% include the cryptography module.

We’re often critical of the lack of security in the IoT sector, and frequently cover botnets and other attacks, but will we hold our projects to the same standards we demand? Will we stop at identifying the problem, or can we be part of the solution?

This article will focus on applying AES encryption and hash authorization functions to the MQTT protocol using the popular ESP8266 chip running NodeMCU firmware. Our purpose is not to provide a copy/paste panacea, but to go through the process step by step, identifying challenges and solutions along the way. The result is a system that’s end-to-end encrypted and authenticated, preventing eavesdropping along the way, and spoofing of valid data, without relying on SSL.

We’re aware that there are also more powerful platforms that can easily support SSL (e.g. Raspberry Pi, Orange Pi, FriendlyARM), but let’s start with the cheapest hardware most of us have lying around, and a protocol suitable for many of our projects. AES is something you could implement on an AVR if you needed to.

Continue reading “Practical IoT Cryptography On The Espressif ESP8266” →

Hack Your Own Samsung TV With The CIA’s Weeping Angel Exploit

April 26, 2017 by Jack Laidlaw 57 Comments

[Wikileaks] has just published the CIA’s engineering notes for Weeping Angel Samsung TV Exploit. This dump includes information for field agents on how to exploit the Samsung’s F-series TVs, turning them into remotely controlled spy microphones that can send audio back to their HQ.

An attacker needs physical access to exploit the Smart TV, because they need to insert a USB drive and press keys on the remote to update the firmware, so this isn’t something that you’re likely to suffer personally. The exploit works by pretending to turn off the TV when the user puts the TV into standby. In reality, it’s sitting there recording all the audio it can, and then sending it back to the attacker once it comes out of “fake off mode”.

It is still unclear if this type of vulnerability could be fully patched without a product recall, although firmware version 1118+ eliminates the USB installation method.

The hack comes along with a few bugs that most people probably wouldn’t notice, but we are willing to bet that your average Hackaday reader would. For instance, a blue LED stays on during “fake off mode” and the Samsung and SmartHub logos don’t appear when you turn the TV back on. The leaked document is from 2014, though, so maybe they’ve “fixed” them by now.

Do you own a Samsung F-series TV? If you do, we wouldn’t worry too much about it unless you are tailed by spies on a regular basis. Don’t trust the TV repairman!

White-hat Botnet Infects, Then Secures IoT Devices

April 24, 2017 by Jack Laidlaw 32 Comments

[Symantec] Reports Hajime seems to be a white hat worm that spreads over telnet in order to secure IoT devices instead of actually doing anything malicious.

[Brian Benchoff] wrote a great article about the Hajime Worm just as the story broke when first discovered back in October last year. At the time, it looked like the beginnings of a malicious IoT botnet out to cause some DDoS trouble. In a crazy turn of events, it now seems that the worm is actually securing devices affected by another major IoT botnet, dubbed Mirai, which has been launching DDoS attacks. More recently a new Mirai variant has been launching application-layer attacks since it’s source code was uploaded to a GitHub account and adapted.

Hajime is a much more complex botnet than Mirai as it is controlled through peer-to-peer propagating commands through infected devices, whilst the latter uses hard-coded addresses for the command and control of the botnet. Hajime can also cloak its self better, managing to hide its self from running processes and hide its files from the device.

The author can open a shell script to any infected machine in the network at any time, and the code is modular, so new capabilities can be added on the fly. It is apparent from the code that a fair amount of development time went into designing this worm.

So where is this all going? So far this is beginning to look like a cyber battle of Good vs Evil. Or it’s a turf war between rival cyber-mafias. Only time will tell.

IoT Security Is Hard: Here’s What You Need To Know

April 21, 2017 by Jack Laidlaw 69 Comments

Security for anything you connect to the internet is important. Think of these devices as doorways. They either allow access to services or provides services for someone else. Doorways need to be secure — you wouldn’t leave your door unlocked if you lived in the bad part of a busy city, would you? Every internet connection is the bad part of a busy city. The thing is, building hardware that is connected to the internet is the new hotness these days. So let’s walk through the basics you need to know to start thinking security with your projects.

If you have ever run a server and checked your logs you have probably noticed that there is a lot of automated traffic trying to gain access to your server on a nearly constant basis. An insecure device on a network doesn’t just compromise itself, it presents a risk to all other networked devices too.

The easiest way to secure a device is to turn it off, but lets presume you want it on. There are many things you can do to protect your IoT device. It may seem daunting to begin with but as you start becoming more security conscious things begin to click together a bit like a jigsaw and it becomes a lot easier.

Continue reading “IoT Security Is Hard: Here’s What You Need To Know” →

Half Baked IoT Stove Could Be Used As A Remote Controlled Arson Device

April 20, 2017 by Jack Laidlaw 37 Comments

[Pen Test Partners] have found some really scary vulnerabilities in AGA range cookers. They are connected by SMS by which a mobile app sends an unauthenticated SMS to the AGA to give it commands for instance preheat the oven, You can also just tell your AGA to turn everything on at once.

The problem is with the web interface; it allows an attacker to check if a user’s cell phone is already registered, allowing for a slow but effective enumeration attack. Once the attacker finds a registered device, all they need to do is send an SMS, as messages are not authenticated by the cooker, neither is the SIM card set up to send the messages validated when registered.

This is quite disturbing, What if someone left a tea towel on the hob or some other flammable material before leaving for work, only to come back to a pile of ashes? This is a six-gazillion BTU stove and oven, after all. It just seems the more connected we are in this digital age the more we end up vulnerable to attacks, companies seem too busy trying to push their products out the door to do simple security checks.

Before disclosing the vulnerability, [Pen Test Partners] tried to contact AGA through Twitter and ended up being blocked. They phoned around trying to get in contact with someone who even knew what IoT or security meant. This took some time but finally they managed to get through to someone from the technical support. Hopefully AGA will roll out some updates soon. The company’s reluctance to do something about this security issue does highlight how sometimes disclosure may not be enough.

[Via Pen Test Partners]