| Everyday we read about some newfangled internet connected device being released. Things we use everyday are being made "smart" with some rushed-to-production software embedded in a cheap micro-controller. Fitness trackers, smoke alarms, televisions, cars, wall-outlets, even water-bottles. Internet connected-water bottles? What a time to be alive! Some think this "Internet of Things" (IOT) and embedded system explosion is driven by gadget hungry consumers. Perhaps it is, but most of this absurdity is side-effect of us technologically transitioning from a world built around ASICs to a world powered by cheap general purpose SOCs (with FPGAs and CPLDs filling in the gaps). | We'll be releasing our findings in about ten internet connected devices..." |
The old ASIC world required electrical engineers to team up with software engineers to make anything of significance. Back then, everything was bespoke: from the hardware up through stack to the "business logic" software that was embedded. These days, this is less common because of the proliferation of multi-purpose SoCs and cheap solid-state storage powerful enough to run full operating systems. These days, your average C programmer can make hardware do useful things using generic multipurpose micro-controllers.
And as we all know this means new places for security problems.
And as we all know this means new places for security problems.
hack all the things?
Some of the vulnerabilities we will be releasing are 'remotely accessible'...some even allow an attacker to access the manufacturer's backend and spread to ALL devices from there... | So to further celebrate this brave new world of newly connected devices we at Xipiter will (over the next few weeks) be releasing our findings in about ten connected devices that many people (according to Amazon) have in their homes. Some of these vulnerabilities are remote, meaning they can allow a remote attacker access to the hardware. In some cases these vulnerabilities are serious enough that anyone can buy the hardware and not only remotely attack other devices but also attack the manufacturer's backend infrastructure and spread from there. |
We aren't much for the "CVEs-as-resume-material" or the "CVEs-as-company-marketing" mentality that plagues our industry. We also don't want to do a "Yet Another 'Thing' Hacking" talk about this stuff. (We prefer to be head down, make hardware and software and find cool bugs.) So, we are going to simply release our findings here and walk you through how we found them with LOTS of photos and screenshots along the way. We'll share some PoC code and maybe even share some IDB files, firmware images, and other stuff.
If after all this if you want to learn more or get hands on, there are a few seats left for our public course in November in the D.C. Area. In this class we will do all of the above and talk in greater detail about these techniques.
The interns did it...
So in short, here is what we did at Xipiter:
When the interns got stuck with lab hardware or lab tools, we'd help them. When they got as far as they could go with that stuff (which was generally pretty far), we showed them (deeper stuff) like how to extract and reverse engineer binaries and firmware, write simple exploits for binaries on the targets (although many of these targets sadly didn't require too much fun binary exploitation). They got to learn a lot. | |
 Ben and Mohini debug compiler errors for the firmware of their ARM microcontroller. | They approached their targets from the outside (sniffing traffic, accessing network services, intercepting firmware updates), then if required, they went deeper (opening the hardware, findings interface points, using diagnostic hardware) and finally accessed and interfaced with the devices at a hardware level with the intent to discover some remotely exploitable vulnerability. From web directory traversal down to MIPS/ARM disassembly with tools like IDA and Capstone Engine. They got to do it all. |
It is also worth noting that the interns spent no time researching "prior art" vulnerabilities on each target (although they stumbled upon some). Based on what was found, Xipiter has not yet reported any of the vulnerabilities . (At Xipiter we generally strictly adhere to our "Responsible Disclosure" policy, but we are deviating from that for this kind of hardware work by releasing everything here for academic research purposes only.)
The targets
The interns basically combed Amazon for the more popular "smart" or "IOT" (Internet of Things) devices and purchased those. They also looked around on Craigslist and found some stuff that they thought would be neat to investigate. So here is what they purchased:
|  Ben builds a router out of his Raspberry Pi to do SSL MITM of one of the devices... |
We'll start dumping next week with some pretty devastating vulnerabilities in:
- A "Smart Home" Hub
- A home Access Point
- A home NAS
Some more thoughtful words ...
At Xipiter, we do all the standard "boutique information security firm" stuff. We do source code audits, reverse engineering of mobile and desktop software but we also do quite a bit of embedded systems security work.
For some strange reason, however within the information security world there is a severe lack of knowledge in this realm. This ultimately stems from the "hardware/software divide": Hardware guys dont understand software and software guys (even the "low level" ones) don't really understand hardware.
But in this uncanny valley there be gold.
Attackers these days need to spend spend months/years of man hours finding and weaponizing exploits and building post-exploitation toolkits for operating systems cluttered by Anti-Virus, software updates, Intrusion Detection, Endpoint Detection, etc. Why do all this when he could just find some 90's-style bugs and hang out on your router, access point, NAS, mobile phone, "smart home" appliance, set-top box, or television? There is no protection on these things there like there is on the endpoint. These devices often have infrequent updates or updates that are trivially disabled. Even if an attacker were detected, very few of the "industry leaders" in forensics and incident response actively address non-PC hardware.
Most of the research on "embedded device" security is boring and irrelevant which leads fed-up security folks like Dave Aitel to scoff at it. And rightfully so. Most of the people publishing the embedded security research "miss the point": How threatening is an "attack" that requires you to physically go to the location of your target to do something? If you're the one deploying the attack it increases your costs and risk.
But again, it is all about scope: A vulnerability found with a Facedancer in the USB stack of a "Smart Thermostat" is not as valuable a "button pressing" vulnerability found in the firmware of a Casino machine or Video Poker. But both of them are found with similar techniques. So it is the techniques that are worth mentioning.
Most "embedded device" security talks either "miss the point" and talk about irrelevant bugs or
(on the other end of the spectrum) are innovative "Hardware Security" talks that are so heavily steeped in hardware that the software guys seem overlook their importance.
This is unfortunate because as software security people we somehow miss the significance of things like: the existence of "CPU cheat codes" that effectively give software in userland access to all of system memory. Or overlook the significance of "memory mapped IO" that gives software direct access to peripherals that can be used for rootkit persistence. As software security people we somehow miss that there are "shadow registers" or "magic values" that can unlock other functionality in the CPU or leak back values of privileged memory. We miss great work by folks like Felix Domke showing us that random peripherals (with software vulns) often have hidden functionality that have DMA to privileged memory regions. Why should we spend our time weaponizing vulns and building toolchains when we can just execute a few magic instructions (or get a magic value into the right register at the right time) to unlock "debug" functionality left in by the CPU manufacturer? Why should we waste time on the endpoint that can be spent finding "operationally" valuable things on devices NEAR the endpoint or that route internet traffic for the endpoint?
This is real stuff.
Not fantasy.
We'll show you.
We'll start dumping next week...
For some strange reason, however within the information security world there is a severe lack of knowledge in this realm. This ultimately stems from the "hardware/software divide": Hardware guys dont understand software and software guys (even the "low level" ones) don't really understand hardware.
But in this uncanny valley there be gold.
Attackers these days need to spend spend months/years of man hours finding and weaponizing exploits and building post-exploitation toolkits for operating systems cluttered by Anti-Virus, software updates, Intrusion Detection, Endpoint Detection, etc. Why do all this when he could just find some 90's-style bugs and hang out on your router, access point, NAS, mobile phone, "smart home" appliance, set-top box, or television? There is no protection on these things there like there is on the endpoint. These devices often have infrequent updates or updates that are trivially disabled. Even if an attacker were detected, very few of the "industry leaders" in forensics and incident response actively address non-PC hardware.
Most of the research on "embedded device" security is boring and irrelevant which leads fed-up security folks like Dave Aitel to scoff at it. And rightfully so. Most of the people publishing the embedded security research "miss the point": How threatening is an "attack" that requires you to physically go to the location of your target to do something? If you're the one deploying the attack it increases your costs and risk.
But again, it is all about scope: A vulnerability found with a Facedancer in the USB stack of a "Smart Thermostat" is not as valuable a "button pressing" vulnerability found in the firmware of a Casino machine or Video Poker. But both of them are found with similar techniques. So it is the techniques that are worth mentioning.
Most "embedded device" security talks either "miss the point" and talk about irrelevant bugs or
(on the other end of the spectrum) are innovative "Hardware Security" talks that are so heavily steeped in hardware that the software guys seem overlook their importance.
This is unfortunate because as software security people we somehow miss the significance of things like: the existence of "CPU cheat codes" that effectively give software in userland access to all of system memory. Or overlook the significance of "memory mapped IO" that gives software direct access to peripherals that can be used for rootkit persistence. As software security people we somehow miss that there are "shadow registers" or "magic values" that can unlock other functionality in the CPU or leak back values of privileged memory. We miss great work by folks like Felix Domke showing us that random peripherals (with software vulns) often have hidden functionality that have DMA to privileged memory regions. Why should we spend our time weaponizing vulns and building toolchains when we can just execute a few magic instructions (or get a magic value into the right register at the right time) to unlock "debug" functionality left in by the CPU manufacturer? Why should we waste time on the endpoint that can be spent finding "operationally" valuable things on devices NEAR the endpoint or that route internet traffic for the endpoint?
This is real stuff.
Not fantasy.
We'll show you.
We'll start dumping next week...
RSS Feed
