IoT Weapons

How bad can it get?

Who are we

A team of expert penetration testers and IoT reverse engineers

In fun time, carry out extensive IoT security research

Samsung smart fridge

Mitsubishi Outlander

Smart TVs

Ransomware for IoT thermostats

Ken Munro@thekenmunroshow

IoT blog: www.pentestpartners.com

Same old new stuff

Brand new vulnerability!

When the kettle is reset to factory defaults the users PSK is not wiped

Which means that if we buy second hand kettles, we get the users Wi-Fi key

Compromise the owner

Now we have the owners Wi-Fi key, we can Man in the Middle EVERYTHING

Introduce fake SSL certificates, sidestep encryption, steal data

We can spoof DNS too

Fortunately, this is a local attack, one kettle at a time

Another new kettle vulnerability

iKettle 2.0 death

Send it a raw 0x0C

It dies – appears to be a firmware update loop

Kettle death – here’s one!

Don’t like tea? How about coffee?

Jura E8 smart coffee machineBluetooth is a secure protocol, IF you implement it correctly

Far too many IoT devices use Bluetooth with NO pairing security

Take over your coffee machine, stop it working, waste your beans

Also stores your email password!

Nespresso ProdigioBut it can get more interesting

This machine integrates Bluetooth remote control PLUS ecommerce functionality

Interesting value add for manufacturer

The mobile app has permissions to make calls silently without user interaction!

We can take control of it, but more concerning is potential to tamper with payment processes

Pairing challenges

Advice

Radio communications to IoT devices (Wi-Fi, Bluetooth, Zigbee, Z-Wave etc) all need to be secure

Just buying a 3rd party module doesn’t make it secure

Most devices we see can be made secure, but no one has bothered to implement the security features, or has implemented them wrongly

Provisioning devices is a real challenge:

New things with BB-8

Consider an IoT device in default config

How do you secure the commsto push keys to it? Six zeros?

SSL? Limited entropy sources

Proximity? RF easy to amplify

Provisioning Advice

BLE antenna gives potential to amplify pairing signal

Possible takeover from a distance, as BB-8 itself has no UI to initiate pairing from?

Also, JTAG

handily marked

up!

Anki Cozmo, very much work in progress

However, static WPA PSK stored client side

Is this truly random, generated at factory?

Or is it created on the toy, without sufficient entropy to be random?

Provisioning Advice

Can you find a source of entropy locally? Running an algorithm locally does not offer randomness: open to reverse engineering

On-chip sources can include time since boot, environmental factors such as temperature and RF noise

Possible to provision unique keys per device at factory, but at a cost!

Proximity offers potential; reduce RF signal strength to assure mobile is near to device. High gain antenna attack possible too.

Swearing kids toys

My Friend CaylaBEUC and US consumers protection bodies filed a formal complaint against Vivid Toys

This morning!

Listening stupidity

Echo! Amazon Dot 2nd gen launches TODAY

Amazing voice recognition and sensitivity, will respond to any voice without training

Alexa voice/IoT integration is pretty secure

What do you control with it? The amazing August smart door lock?

Are you having a laugh?

Stand outside window, ‘unlock BMW’

Car on drive unlocks, code key, drive off?

Hack the hardware instead

Hardware hacking

The second game changer in IoT security

You are putting your firmware and software in the hands of the hacker

If they can extract and/or modify the firmware, your security could easily be bypassed

Firmware security is essential:

SIGN your code, validate it at boot

Ensure signing cannot be bypassed or rolled back

Never put sensitive data in code

Multimeter

Logic probe in UART port

Logic analyzer

Beer Coffee

UART

SPI

Fitbit Aria smart scales

UART, SPI, JTAG etc should NEVER be live on production IoT devicesDevice cheaper to replace than to send an engineer, so why expose them?

Taking control of your home:

IoT Ransomware

Ransomware

Could we take control of a smart thermostat?

Could we lock the user out and hold their heating/cooling to ransom?

A likely candidate found on Amazon

Quick check of FCC search suggested ARM/Linux

Detailed breakdown - hardware

Highly functional – we’re looking for JTAG, SPI and UART interfaces to pull data/firmware from

We found:

An SD Card slot – used for updating firmware and transferring data

6-pin header has serial out

No obvious exposed JTAG

The way in

Awkward for user to create complex schedules from the on-board user interface

A lovely Adobe Air app is available to allow customization on a PC, then load to thermostat from SD card

Includes the entire firmware, should an upgrade be required!!

Unpacking firmware

BINGO! We have the filesystem

Examining firmware

Remember SQL injection for web applications?

We can carry out similar attacks against filesystems using command injection

User input is not validated in some cases

The upload function for the screen background image is not checked

The developer gave no thought to attackers getting hold of the firmware

More developer issuesThis dev really didn’t think their code would ever be seen!

Taking control

Now we can upload a shell and gain full control of the thermostat, it even survives a reboot – APT?

Create an IRC channel so we can control the stat remotelyChange the screen lock PIN to lock the user outChange the screen background to some ransomwareSend on/off messages to boiler 3 times per second until it fails

All because a filename was implicitly trusted by device

Weaponising IoT

MVPower DVR

Web enabled DVR to record CCTV

Security can’t get any worse

Easy to find on Shodan44,000 as of yesterday

MVPower DVR – Very bad...

Easy to bypass web authentication by changing cookie values

dvr_usr = <anyusername>

dvr_password = <anypassword>

Remember these are ON THE INTERNET!

MVPower DVR – It gets worse....

Remote root shell availablehttp://<hostname/IP>/shell?<command>

Available whenever the webserver is runningWeb server needed to use the device

Can’t get much worse.....can it?

MVPower DVR – the most read blog post on our web site

Dahua IP CCTV cameras with telnet open to the public internet - UPnP

Several sets of default creds, one of which we identified through reverse engineering

Mirai bot-net takes advantage of this

Attackers created a 1Tbps DDoS

Mirai has since moved on to port 22 (SSH) and other devices

1Tbps is nothing compared with potential

Make sure you can soak it!

Attribution of Mirai – it’s all DVRs

QVIS DVR

Yale DVR

Mezory DVR

DreamboxDVR/PVR

Realtek DVR

TR-064 worm

TR-069 is a well known protocol for remote admin of customer routers. Pretty secure, so long as HTTP is specified, unlike TalkTalk Huawei

TR-064 is for LAN management, not WAN management, hence should not be available from internet

No authentication required, which leads to some scary issues

TR-064 worm

Exact cause for outage last week not known yet, though probably a result of using TR-064 to change ISP ACS

Two interesting requests using the protocol: GetSecurityKeys retrieves WPA PSK

Impossible for ISP to push a firmware upgrade to a compromised router using TR-069

TR-064 worm User has to trigger reset manually

Router will then look for new firmware

This fixes the TR-064 issue

Resetting WPA PSK to default – fail!

Except users rarely change PSK from default, so the ‘fix’ doesn’t fix the PSK theft issue: 57,000 keys exposed

TR-064 worm – where next?

Seeing evidence of ACS takeover attacks

Can also change DNS. Remote code execution may be possible – potential to use TR-064 to open SSH externally, pwd is Wi-Fi PSK!

Affects >50 different routers running same Zyxel rompager. Digging through supply chain, may point to Ralink / Econet / Mediatek

Numerous ISPs involved globally

TalkTalk have blocked TCP 7547 – as of 8am yesterday

Extensive reports of bricked routers. Replacement may be required

The ultimate IoT weapon?

IoT weaponsAround 1M IoT thermostats already installed in UK

Several times that in USA

Forget ransomware – the consumer would never know if the stat had been compromised

Use port 80 and RCE, hard for ISP to detect/block

Switch on electrical heating and a/c on every stat concurrently, when grid load is highest

Advice

The attack surface for IoT is huge!

Mobile app

API

Web app

Wi-Fi, Bluetooth etc

Firmware

I/O ports

…and more

The opportunity for great customer interaction and revenue growth is also huge

Insecure IoT devices have the potential to damage your brand

…and potentially result in PII and card data breaches

Final thoughts

OWASP guidance is excellent, as is IoT Security Foundation

Make sure your outsourced development and manufacturing contracts specify security

Test it, examine firmware, be sure

A few questions to ask:

“Do you pin the SSL certificates in the mobile app?”

“What PII does the app & device store?”

“Do you sign (and validate) the firmware?”

“If I stole the users IoT device, what data could I steal from it?”

@thekenmunroshow

@pentestpartners

Blog:www.pentestpartners.com

Create security@ mail address for researchers