When we say “hack” here we most often mean either modifying something to do something different or building something out of parts. But as we build more Internet-connected things, it is worthwhile to think about the other kind of hack where people gain unauthorized access to a system. For example, you wouldn’t think a remote control would be a big deal for hackers. But the Logitech Harmony Hub connects to the Internet and runs Linux. What’s more is it can control smart devices like door locks and thermostats, so hacking it could cause problems. FireEye’s Mandian Red Team set out to hack the Harmony and found it had a lot of huge security problems.
The remote didn’t check Logitech’s SSL certificate for validity. It didn’t have a secure update process. There were developer tools (an SSH server) left inactive in the production firmware and — surprisingly — the root password was blank! The team shared their findings with Logitech before publishing the report and the latest patch from the company fixes these problems. But it is instructive to think about how your Raspberry Pi project would fare under the same scrutiny.
In fact, that’s the most interesting part of the story is the blow-by-blow description of the attack. We won’t spoil the details, but the approach was to feed the device a fake update package that turned on a dormant ssh server. Although they started by trying to solder wires to a serial port, that wasn’t productive and the final attack didn’t require any of that.
We’ve looked at some ways to harden Linux systems like the Raspberry Pi before, but honestly, it is an ongoing battle. We’ve seen plenty of devices with cybersecurity holes in them — some not found by good guy hackers first.
Frustrated by the glut of unsecured IoT devices? So are Microsoft. And they’re using custom Linux and hardware to do something about it.
Microsoft have announced a new ecosystem for secure IoT devices called “Azure Sphere.” This system is threefold: Hardware, Software, and Cloud. The hardware component is a Microsoft-certified microcontroller which contains Microsoft Pluton, a hardware security subsystem. The first Microsoft-certified Azure Sphere chip will be the MediaTek MT3620, launching this year. The software layer is a custom Linux-based Operating System (OS) that is more capable than the average Real-Time OS (RTOS) common to low-powered IoT devices. Yes, that’s right. Microsoft is shipping a product with Linux built-in by default (as opposed to Windows Subsystem for Linux). Finally, the cloud layer is billed as a “turnkey” solution, which makes cloud-based functions such as updating, failure reporting, and authentication simpler.
Continue reading “Microsoft Secures IoT from the Microcontroller Up”
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!
Image of Mount Sopris, namesake of the project, by [Hogs555] (CC-BY 4.0)
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].
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”
[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!
[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.