Common IoT Weaknesses

Mirai took down a chunk of the internet in 2016 with a list of about 60 username and password pairs. No exploit, no memory corruption, just admin and root against telnet on cameras and DVRs that all shipped the same way. That is the honest state of IoT security. The bugs are not clever. They repeat, and they repeat because the same four mistakes get made on nearly every device.

Default and hardcoded credentials

The first login you try is admin:admin, then root:root, then whatever the Mirai list holds for that vendor. Devices ship with a factory password nobody changes, and worse, many carry a hidden account you cannot change at all because it is compiled in.

When you find the same root hash in a firmware image, crack it once and it opens every unit of that model in the world. The vendor used one password for the whole production run.

No real update mechanism

Plenty of devices update over plain HTTP with no signature check. That means anyone who can intercept the download, a man in the middle on the network, can hand the device a firmware image of their choosing and the device installs it. No signing, no encryption, no rollback protection. The update channel becomes the persistence channel.

Even when an update exists, it often never runs. The device ships, sits on a shelf, and stays on a build with known bugs for its entire service life because there is no auto-update and no one logs in to flash it.

Exposed and insecure services

Embedded devices love to listen. Telnet on 23, UPnP quietly punching holes in the router, a debug service on some high port the developer forgot, an MQTT broker on 1883 with no authentication, RTSP video on 554 that streams to anyone who asks.

$nmap -sV --script mqtt-subscribe -p 1883 192.168.1.50

Each open service is a door. Half of them were meant for the factory or a developer and should never have shipped enabled.

Secrets baked into the image

The last lesson showed how to grep firmware for keys. This is why it matters. Devices carry hardcoded API keys, TLS private keys, Wi-Fi passwords, and cloud tokens right in the filesystem. A single shared private key across a product line means pulling it from one device you own lets you decrypt or impersonate traffic for all of them.

The pattern under all four is the same: the device trusts its network, trusts its cloud, and assumes nobody will ever read what is on the chip. Every one of those assumptions is wrong the moment a tester shows up.