• IoT manufacturers sell their products to vendors
  • The product itself
  • Cloud infrastructure
  • Smartphone application
• White-label vendors buy a generic product
  • Rebrand and sell products under their name

Vulnerabilities in IoT infrastructure
=
Vulnerability in all white-label products

• Same IoT cloud infrastructure used by white-label vendors
• Data and network activity is all centralised / standardised
• Privacy concerns - Who, What, Where, When, Why?
• Infrastructure outage = really really big outage..

• Reverse engineering of cloud communications protocols / API
  • e.g. MiIO protocol (link)
• Decoupling of devices from the necessity of internet / IoT cloud
  • HomeAssistant - Home Automation (link)
  • OpenHAB - Home Automation (link)
  • Valetudo - Cloud-less vacuum cleaner control interface (link)
  • DustCloud - Xiaomi Cloud Emulation (link)
  • MiCloudFaker - Xiaomi Cloud Emulation (link)
  • tuya-convert - Flash Tuya devices to custom firmware (link)

• Robotic home cleaning appliances
• Founded in July 2014, Beijing
• Partnered with Xiaomi in September 2014
  • Investments + Partnership

• September 2016 - Mi Home Robotic Vaccuum Cleaner
  • Very first product!
• ⋮ Roborock S5, E2, E3
• June 2019 - Roborock S6
• ⋮ Roborock S5 Max, S4, S6 Pure, S6 MaxV, E4, S4 Max
• January 2021 - S7

Specifications

• CPU: Allwinner R16 Quad-core ARMv7
• ACU: STM32F103VC
• RAM: 512 MB
• Flash: 4 GB eMMC
• Wireless: RTL8189ETV (802.11 b/g/n)
• Cloud: Tuya / Xiaomi
• OS: Ubuntu 14.04

Cloud Capability

IoT infrastructure vulnerability (15/09/2021)

Rationale

🔐 Security is important!

📒 Check things for yourself!

IoT ☁

The majority of hardware hacks / custom firmwares have originated from the desire to decouple hardware from cloud services

IoT | 2018 - Michael Steigerwald (VTRUST)

Talk: Smart home - Smart hack

• Products from different manufacturers used the same cloud infrastructure each with their own ‘customised’ (white-label) smartphone apps
  • Supposed ‘military-grade security’
• Used the Espressif ESP8266 chip
  • WiFi-enabled SoC with Arduino support
  • Often used by tinkerers and enthusiasts
• Anyone can become an ‘IoT company’ regardless of “having in-depth technical knowledge of IoT or IT security.”
  • 🚩🚩🚩

IoT | 2018 - Michael Steigerwald (VTRUST)

Talk: Smart home - Smart hack

“The analysis of the ‘smart’ devices using this basic platform is generally frightening […] serious […] shortcomings”

• Insecure transmission of encryption keys, serial number, etc…
• Insecure transmission of wireless credentials during pairing
• Ease of white-labelling and starting your own IoT business
  • Ease of selling malicious devices

IoT | 2018 - Michael Steigerwald (VTRUST)

Talk: Smart home - Smart hack

Automated flashing tool tuya-convert created that exploited prior vulnerabilities to flash custom decoupled firmware
(i.e. ESPhome, Tasmota, etc…)

IoT | 2018 - Michael Steigerwald (VTRUST)

Tuya’s Response

• 28th January 2019 - patch released (later subverted)
  • TLS encrypted firmware update procedure
  • Encryption of flash memory
• 3rd January 2020 - new patch released
  • unbreakable™
• 23rd April 2020 - Switched from the ESP8266 to a custom SoC
  • Tuya WB3S
• 16th June 2021 - Announced official support for HomeAssistant

IoT | 2017/2018 - Xiaomi Dafang Hacks

• Cheap WiFi camera that can be made to boot off a microSD card
• Circuit board exposed UART (baud_rate=115200) pins that allowed interaction with U-Boot bootloader
• Modification of boot environment to start /bin/sh ([link])
• Gain root shell access
• Dump firmware
• Analyse, modify and package updated firmware

Access and Control

Gaining access to a shell / stored data / things we shouldn’t.

Flash IC Dumping

• May require a proprietary flash programmer (above: US$3655)
• Budget solution for common flash types: Raspberry Pi (AU$100)
• Some flash chips (depending on form factor) may require to be desoldered
  • 🧨 Possibly a destructive process 🧨
• Open-source software: flashrom

Source: J. Jimenez - Practical Reverse Engineering

BGA shorting to gain access to FEL

• FEL mode is a “fallback” system on Allwinner SoCs
• Allows the flashing and reprogramming of the SoC
• Generally triggered by pulling FEL pin (LRADC0) LOW during boot
• FEL mode can also be entered if the bootloader fails to load 🤔

BGA shorting to gain access to FEL

• On the Allwinner R16 (BGA package) FEL pin located on ball location L14
  • Not located on package edge the chip so desoldering required

Enter FEL mode by preventing (e)MMC load?

• SoC has a solder plane height of around 0.3mm
• Too shallow for a wire, but tall enough for aluminium foil…

BGA shorting to gain access to FEL

Aluminium Foil

• Thickness: ~0.02mm (… 0.02mm « 0.3mm)
• Conductive: Yep!
• $$$

Documented: SEEMOO-MSC-0142

BGA shorting to gain access to FEL | Aside (2021)

On later versions (post 2020), U-Boot shell access was patched, so shell access via UART was mitigated

Pin TPA17 on the Roborock S7 circuit board was discovered to connect to ball location L14 on the SoC.

Therefore by pulling TPA17 / L14 / LRADC0 LOW (i.e connect to GND), FEL mode can be entered

Vacuums in the Cloud: Analyzing Security in a Hardened IoT Ecosystem

Presentation: USENIX WOOT 19

• Security analysis performed on a Neato BotVac Connected robot vacuum cleaner (popular in the US)
• AM335x Microprocessor (ARM Cortex-A8)
• Cold-boot attack allowed RAM to be dumped over serial
  • Cold-boot attack - restarting the system whilst keeping memory modules powered on, keeping memory (mostly) in-tact
  • USB + Serial communication allowed boot into custom image that could then dump the memory for later triage

Vacuums in the Cloud: Analyzing Security in a Hardened IoT Ecosystem

• Memory dumps contained confidential keys
  • 🙋‍♀️ Auth/Authz to the robot
  • 🙆‍♀️ Auth/Authz to the cloud infrastructure
• Logs and coredumps were encrypted… but keys hardcoded
• Secret key RNG algorithm determined to be weak
  • Small keyspace given known data = bruteforceable
• RSA key was shared with all devices 🔓
  • Identity impersonation

Also discovered buffer overflow vulnerability in an unauthenticated stage.

2014 - Firmware Analysis

Paper: A Large-Scale Analysis of the Security of Embedded Firmwares

• Broad analysis of a large number of firmware images
• Discovered 38 new vulnerabilities over 693 images
• Similarities in vulnerabilities
• Static analysis and extraction of keys, credentials, configurations and other ‘tells’

2014 - Firmware Analysis

• Source code changes largely remain the same
• But binary files change ‘arbitrarily’
• Difficult to compare binary files
• Calculate fuzzy hashes instead to compare similarity

e.g. binwalk, ssdeep, sdhash

Client-Side and Infrastructural Security

iOS application of a smart doorlock was analysed to (in)validate claims made by the device company

Findings

• Lock events and other sensitive information were being logged independent of locking functionality
• Access to lock settings were purely client-side UI checks
• Certificate pinning bypass-able

Source: Backdooring the Frontdoor

LIDAR - Acoustic Eavesdropping

LIDAR - Light Detection and Ranging

• Uses laser lights to sense distance
• Side-channel also exposes intensity (on some units)
  • Can use to detect minute vibrations induced by audio sources

LIDAR - Acoustic Eavesdropping

• Vibrations are extracted and turned back into sound waves
  • Extraction of sensitive data (i.e. credit card digits)
  • Achieved 91% classification accuracy

2015: Acoustic Eavesdropping through Wireless Vibrometry
2020: LidarPhone: acoustic eavesdropping using a lidar sensor

Xiaomi Ecosystem | 2017-2019 - Dennis Giese

Paper: SEEMOO-MSC-0142 (July 10, 2019)

• Research available: dontvacuum.me
• Performed security analysis of a range of Xiaomi products
• Found ways to root the Mi Home Robotic Vacuum Cleaner and the Roborock S6
  • UART, hardware fault injection, etc…
• Developed cloud emulation software (DustCloud)
• Research led to development of 3rd party software (i.e. Valeduto)

Xiaomi Ecosystem | 2017-2019 - Dennis Giese

“How secure is the implementation of the ecosystem of the IoT market leader Xiaomi?”

Conclusions

• ⌚ The company quickly responds to security concerns
• 🔍 Many exposed endpoints of deprecated APIs
• 🔓 Many devices do not enforce proper HTTPS checks
• 🤝 Difficult to enforce security for plugins (vendor-provided)
• ❓ CIA principles generally kept

Xiaomi Ecosystem | 2017-2019 - Dennis Giese

More to be done

• Research
• Get the Roborock S6 vacuum cleaner
• Acquisition and capture of network activity
• Find a way in (it runs Linux!)
• Image the system for offline analysis
• Reverse engineering and binary analysis of firmware and software
  • Look through binaries for security vulnerabilities and fortifications

Considerations

• I’m just a fourth year!
  • Limited skills
  • i.e. microsoldering for flash chip extraction and dumping
• Access to equipment and facilities are limited (COVID?)
• Only have one device to test on

Contingency

If we can’t get into the device?

• Option 1 - Protocol analysis (network traffic)

  • i.e. Inspect the data and its nature
    • Content, Frequency, Destination

• Option 2 - Investigate the Xiaomi Home smartphone application (used to communicate with the device)

  • i.e. Decompile the Android APK file and look for security vulnerabilities and fortifications

Future Plans

• See what the sensors see
• Circuit board decomposition
• Analyse the custom ADB binary serving the USB port

featherbear.cc/UNSW-CSE-Thesis

Summary

Network Setup

[Initial] Packet Capture

• No LAN-LAN packets???
• incomplete test - misconfigured packet capture setup

Teardown

Initial Breakdown and Pinout (where needed)

Identification of the UART pins

Serial Access

• Serial (baud=115200) gives us a shell!

Need a root password though…

U-Boot Bootloader

• Able to enter the bootloader shell if s is pressed during init

Root!