Hardware Hacking for Security Assessment

TL;DR - IoT is really bad atm, and this post shows how bad it can be. /TL;DR

Summary - to get the most out of security assessing hardware, you should ideally be proficient in numerous areas of security testing - infrastructure, web, mobile apps - as these are all presented attack surfaces on modern devices. Hardware hacking can greatly enhance the testing of these surfaces, and offers up some new attacks and a level of detail that is completely missed if the device’s debug/terminal functionality is not explored.

Motivation

A matter of longevity

The ‘half-life’ of a vulnerability - the length of time for half the users to have their service/software patched against an identified threat - is nowadays very short; minutes for a hosted web service, even hours for a maintained executables and services, to weeks with clients who have strict roll-out testing requirements. However, a vulnerability in hardware will be around for YEARS. Once a device is installed, it’s there for the long run, and if there is one guy who procured it, went on the training course, but then left under a cloud and never wrote down how to update it - you’re really stuck until you upgrade. This is the true facts of hardware based security models.

Looking past just getting a shell

There are 1001 guides online for doing ‘Hardware Hacking’ and they mostly stop at ‘…and now you’re connected’, leaving the reader to come up with the relevant attacks, tests, and experience for themselves. Few places deal with what the risks really are.

Yes, I understand (more than most) the value of having a r00t shell on a device, delivered to you through UART, but let’s be honest for a moment - this is not a viable attack vector! There is no way that you’ll actually execute access to a UART on a victim’s device without either their noticing you, or travelling around fully equipped to perform the installation and assessment of the development header.

So, given I did a post about getting UART for under a tenner (£10 for those wondering what opera has to do with this) I alluded that getting UART is just the beginning - and it is! There is much that you can do with low-level access to a device’s hardware that is hard-to-impossible without such access.

I will give details for UART in a later post, but for now, I just want to explore more on what I precisely mean, as a security person, by ‘hardware hacking’ and why it’s useful.

What hardware hacking means

First, a quick digression into what I mean by ‘hardware hacking’. This is a very broad topic - it covers circuit bending, repurposing tech, breaking DRM on games consoles, accessing debug functionality on IC’s built into product PCB’s, designing and getting an arduino/RasPi/(generic microcontroller) to achieve a certain task for a project you’re making, accessing/writing to protected ROM areas, reverse engineering IC’s that don’t have public datasheets, etc. etc. etc.

Hardware hacking is a vast topic, and I don’t want to get bogged down with definitions - they’re all valid uses of the term ‘hacking’.

Specifically, for me, the phrase hardware hacking is linked to my work as a pentester and security researcher where I would analyse IoT/hardware from the standpoint of an attacker looking to get some malicious leverage on a system - so, my point of view for ‘what to do when you have access to a debug/terminal interface with a chip?’ is to use this deep level of access to test for vulnerabilities and security flaws. This is what I’m interested in, and so I’m making this explicit from the start.

As such, here are the kinds of questions I ask of a device I come into contact with:

  • What else can you do besides (generic product description)? (you could argue this is a definition of ‘hacking’ in a generic way…)
    • are you really a microcontroller being used to flash a light?
    • Do you have a firmware-controlled radio that could be repurposed?
    • Do you have some advanced functionality that goes above and beyond what you need for the task at hand, and that I can use for other stuff?
  • Can I turn you into a malicious device for blackmail?
    • e.g. bugging, video recording, disclosing sensitive user data or Personally Identifiable Info (PII) - that kind of thing
  • Can I get data out of you that relates to your owner?
    • e.g. PII again, usernames, passwords, secret keys for 2FA, private keys for encryption, etc.
  • Can I add you to a botnet/BTC miner?
    • easy ways to monetise pwned devices - get them to mine BTC to a wallet you control, or add them to a botnet and sell DDoS services a la Mirai clone botnets
  • Can I think of any other malicious activity that would benefit me in some real way, that I can leverage to this device and others?

Some Attack Scenarios and Common Vulns

So, you’re a pentester and you’ve been given a device to hack as part of a test - what now?!? In fact, many categories of attacks relate to Hardware hacking from this security standpoint, in particular:

  • Outdated Software

There is a major supply chain issue in IoT. A recent mass hack in the UK showed that there are some serious flaws in the generic underlying software presented on the devices. But how the hell are these vulns here? Well, in part it’s a supply chain problem.

Often (incorrectly) referred to a ZyXEL, Allegrosoft manufacture software for embedded systems, including the very popular RomPager server software. It was clear that there was some issue with this software in the wake of this hack. However, according to sources, Allegro FIXED THIS VULN IN 2005, which was revealed when checkpoint disclosed the ‘misfortune cookie’ issue, which was similar in nature.

So what went wrong? Well, Allegro make money, like any other company, so they sell their software to IC manufacturers directly. In turn, these manufacturers develop a chip, and then sell/give away an SDK with the chips so that companies can quickly get products to market. As such, the problem was specifically that the manufacturer had never upgraded, so the product designers never upgraded, and these devices are in place for years and years - so a vuln from 2005 can and will be a major pain in the arse in 2017 because of this major problem in the supply chain delay-line effect.

You will find web servers you’ve never heard of (because they were discontinued in 2003, like D-Link’s Boa webserver), DNS servers older than most of your underwear, kernel versions that belong in museums, and best not to mention what versions of busybox they are running.

  • Wi-Fi woes

Many attacks have been found against commercial Wi-Fi setups. But from this to this, it’s clear that all your Wi-Fi experience as a teenager has not gone to waste.

  • Remote Command Exec (RCE)

Many instances where you can send a command over the internet and run commands on the local device as r00t. This is quite obviously bad - and there are many sources for ‘what to do’ if you find this kind of vulnerabilty. Many devices also run everything (even web pages) through BASH scripts because then they don’t have the overhead of including a (probably as vulnerable) PHP service. As such, injecting RCE strings all over is likely to find something, somewhere, on the web-app used to manage the devices.

  • Remote Code Exec

Likewise, connecting to some exposed service on the external device presentation and send crafted payloads to exploit BOF, format string vulns, etc. These service, if vulnerable, can easily be found using shodan and the like.

  • Cross Site Reqeust Forgery (CSRF)

Using CSRF to fire in a user’s browser, connect to the ubiquitous web based apps/API’s used to manage the devices, and either get RCE or directly manipulate settings is a common vulnerability I have found on firmware-based devices. The required CSRF-Token checks needed to mitigate this can produce lines and lines of code, which is a hefty price to pay on storage-light firmware chips (remember - the max for most firmware chips is 16Mb). This vuln is going to be a common theme.

  • Cross Site Scripting (XSS)

XSS is always bad, and if there is a way to compromise the device with, say, a stored or reflected XSS, the user’s browser as well as the device can be compromised. I’m not going to write here on the evils of XSS as many others have done this before me! But your honed bug-bounty/web-CTF skillz are not lost here!

  • File Upload vulns

Linking into my nightmare CSRF scenarios, file parsing is almost always comically bad on devices, and I will put money on that if there’s a file upload on a new-to-market device, it’ll have some vulnerability related to either Local File Inclusion, Directory Traversal, or straight up pwning (as seen with a device that just unzipped a file as root into /, including the malicious /bin/evil-ELF I included).

  • XML/SOAP based attacks

More and more devices are using mobile based android/iOS apps to manage these devices. As cool as this sounds, these devices open up a SOAP/XML/JSON based API to talk to the app (rarely implementing any authentication), and UPnP attacks, enumeration, TR069 attacks and enumeration (and others) fall into this category, too - but see ‘cloud’ for more.

  • Authentication / Session management issues

Default credentials are everywhere - literally! admin:admin or similar used to be a joke in the office, until it was everywhere on every device you could talk to that used some embedded platform. It is also a myth that most users even can change their passwords to these devices (many don’t support this anymore - see ‘cloud’) so this is also worth reporting. Authentication information enumeration (usernames/emails) is also rampant, as well as authentication bypass - I remember doing a test on one device where just having a valid cookie (which you could guess or bruteforce to get) was enough to bypass username/password requirements.

  • Information disclosure - READ

If the device passes through much of the user’s data (as in CPE’s) then this data is at risk if the device is - and so these devices can act as a source for further malicious activity (dumping CC data, seeing if someone is in the house for IPCams, etc.). Don’t forget, setting malicious DNS servers is very, very easy on CPE’s once you’ve compromised one, and most users (even tech savvy IT people) won’t notice, not ever.

Additionally, if a devices offers up access to other services that they then manage (SIP/VOIP, FemtoCell or IPTV access) then disclosure of the internal mechanisms on these devices can reveal private keys for encryption, common shared secrets or credentials (often unencrypted/unhashed), certificates for authentication and encrypted access, DRM information and access methods, etc.

  • the ‘Cloud’

…is just someone else’s computer. But aside from all these issues (which are dealt with much better elsewhere) there is another concern. Amid this melange of written-at-4am-with-no-sleep and updated-when-West-Virgina-last-voted-Democrat software (see, US-relevant jokes… how international of me), introducing new and modern services is as bad an idea as you might thing.

All I can say is that there is little reason for a user to be able to change their firewall settings on their router from the other side of the planet (read; over the internet) but that hasn’t stopped manufacturers’ efforts to ‘solve problems people didn’t know they had’, thereby creating more problems that nobody whatsoever needs.

Hardware Specific stuff

There are also some specific issues relating to hardware devices themselves:

  • More Supply chain woes

Example: U-Boot doesn’t support secure booting. At all. Secure boot mode has been in ARM processors from 2005/6 time, but the most common bootloader in existence doesn’t support it. This means that your bootloader probably doesn’t support checking if the firmware is malicious. Again, tie this into a CSRF vuln (see above) and you can upload a malicious firmware file (I’ll probably do a blog on how to make these).

But how is this a supply chain issue? Well, ARM is sold under license, and as such, many of the cheapest chips use licenses of older chip designs. So we see the precise same issue as above - Jazelle mode is an old ARM exec mode that supports native Java bytecode execution (YES YOU READ THAT RIGHT). It was ‘replaced’ by a new mode in ARMv7 called ‘ThumbEE’, but you’ll still see Jazelle in millions of chips in the wild worldwide.

  • Development Headers

Kinda obvious from the outset, but the reason these are left on the boards is that the cost of tooling a ‘consumer safe’ board is very high. Prototyping can take weeks, and when you double that time to create a ‘secure’ version of a PCB layout, most project managers would shelve such an idea on the grounds of cost alone.

Also, ‘omitting’ a connecting resistor when going from dev board to production board isn’t fooling anybody…

  • Bootlog Oracles

Bootlogs are great. They’re on the list a little down from post-it notes and using your MAC address as the default Wi-Fi password. The tell you processor versions, chip ID’s (they are often covered up with heat-sinks you need light munitions to get off), kernel versions, precise software versions, and tell you all the modes that things are running in/at/on. I may do some detailed commentaries on some bootlogs to show how this works.

So… now what?

So from my point of view, that is the why for doing hardware hacking. Next up will be an in-depth look on the how - starting with UART.

Stay tuned.