Default Credentials: The IoT Epidemic
Default credentials are the most boring vulnerability in IoT and still one of the most damaging. The Mirai botnet took over hundreds of thousands of devices with a list of about sixty default passwords. The problem is not that the passwords are weak; it is that they are shared and public. Here is how the issue plays out and how to design it away.
Why Shared Secrets Fail
A default credential ships identically on every unit and is documented in the manual an attacker can download. That makes it public. A password is only a secret if it is unique and unknown; a shared default is neither, so it provides essentially no protection across a fleet.
Finding Them in the Firmware
You often do not even need the device. The credentials are in the image:
grep -E '^[a-z]+:' squashfs-root/etc/passwd cat squashfs-root/etc/shadow
root:x:0:0:root:/root:/bin/sh admin:x:1000:1000:admin:/home/admin:/bin/sh root:$1$xS3f$9kF...:19000:0:99999:7:::
Confirming Across the Fleet
A short list of published defaults, tried against the login service, usually lands without anything that looks like a brute-force attack:
hydra -C defaults.txt ssh://192.168.1.1
[22][ssh] host: 192.168.1.1 login: admin password: admin 1 valid password found
admin/admin worked, and it works on every other unit of the same model. That is the fleet-wide blast radius in one line.
Three Default-Credential Failures
The patterns behind the headlines:
Designing the Problem Away
Generate a unique credential per device at manufacturing, force a change on first setup before the device is usable, and remove hidden support and factory accounts from production images. The goal is that there is no single secret an attacker can learn once and reuse everywhere.
Where This Fits
Checking for default and hidden credentials, in the firmware and on the live device, is a standard part of a product security assessment. That work is the kind of work we do at Berkner Tech.