Skip to content
Sedat Özdemir
Writing

firmware

The Dumb Security of Smart Homes: Why Are We Still Living in the 1990s in the IoT World?

Is Shodan really everything? In this piece, we dive into why the IoT ecosystem feels like the Wild West, exploring MQTT vulnerabilities and the 'geeky' reality of firmware analysis from a Red Teamer's perspective.

Sedat Özdemir
· 4 dk read

There's this Shodan fetish in the industry, have you noticed? Everyone is constantly tweeting stuff like 'Look, I found an open camera on Shodan' or 'Check out how many IPs are exposed.' Let's be real: spending all night on Shodan and claiming you're 'doing IoT security' is just window shopping. Relying on Shodan in a real production environment or during an actual operation is literal madness. Shodan only shows you the welcome mat at the front door; it doesn't show you the 20-year-old vulnerabilities, the horribly written firmware, or the unencrypted protocols hidden behind that door. Our job isn't the storefront; it's the heart of the device.

The IoT world is currently like the 'Wild West' of cybersecurity. We're talking about an ecosystem where developers say, 'Just get it working, we'll deal with security later,' and hardware engineers think, 'Let's cut costs, we don't really need TLS.' When we put these devices on the table at Payten, what we usually see are 1990s-era security standards. Let’s dig through these dusty shelves a bit.

MQTT: A Backdoor Left Wide Open

MQTT is the favorite protocol for IoT devices to talk to each other. It’s lightweight, fast, and a total 'set-and-forget' friend. But guess what? In default installations, authentication is usually left as 'optional.' During Red Team operations, this is one of the first places we look after breaching a network.

Just imagine: all the sensor data of a factory or the smart lock systems of an office are flying around unencrypted. If an attacker is on the local network (or if some 'genius' exposed the MQTT port to the world via 1883), eavesdropping on all traffic is child's play.

For example, let's look at how you can see all messages on the network with a simple mosquitto_sub command (Please only try this in your own test environment):

# Defanged MQTT subscription command
# Listen to all topics (#) on a broker running on 127.0.0.1
mosquitto_sub -h 127.0.0.1 -t "#" -v

If the output looks like this, that 'smart' building isn't so smart anymore:

devices/office/lock/status unlocked
devices/office/temp/sensor 24.5
devices/admin/credentials {"user": "admin", "pass": "123456"}

The real disaster here isn't just the existence of a topic like devices/admin/credentials, it’s the fact that this data is being 'broadcast' without any encryption or authorization. What should we do on the defensive side? Using MQTTS (MQTT over TLS) is not a luxury; it’s a necessity. Furthermore, it is essential to define ACLs (Access Control Lists) so that each device can only access the specific 'topic' it needs.

Firmware Analysis: Searching for a Needle in a Haystack

The external face of a device (web interface, ports) might look solid. But what about the 'brain' inside that device? Firmware analysis is the most enjoyable and 'geeky' part of Red Team operations. When you take a .bin file and extract the file system, it’s very likely you’ll find 'forgotten' debug scripts or 'temporary' backdoors left behind by the developer.

Usually, binwalk is considered the holy grail of this work. But binwalk is just a tool; the real work starts after extracting the files...

Related posts