Let's Take A "Bin" Walk Through IoT

We need to admit it ... IoT security is a disaster area. Why? Well here's just a few reasons:

• In order to get users to use it, it must be simple to setup and to reset.
• It is often copies of existing systems which are thrown together with little understanding of security.
• In order to keep costs down, it uses cheap processors, with limited capabilities and where memory is limited.
• Software developers often have no idea about how to properly implement secure code and, especially, encryption. The code is often "borrowed" from the Internet.
• Patching vulnerabilities for IoT devices is often difficult, as they often require the user to update them.

Of all the devices we've tried, there is normally a TCP or UDP port open, and there are typically simple passwords used, and where there is no lock-out for password scanning.

So let's say that everything has been locked-down, with good security. Unfortunately there's a way for an intruder to gain key information about the device, as IoT devices get their configuration from firmware, which is open to inspection by most users.

In our evaluation of devices, it was fairly easy for us to find the firmware for the device, and download it. Next we can run binwalk to extract the contents of the firmware:

root@kali:~# binwalk 51.3.0.152.bin

DECIMAL       HEX           DESCRIPTION
-------------------------------------------------------------------------------------------------------------------
36            0x24          Zip archive data, at least v1.0 to extract, name: "system/"  
101           0x65          Zip archive data, at least v1.0 to extract, name: "system/Wireless/"  
175           0xAF          Zip archive data, at least v1.0 to extract, name: "system/system/"  
247           0xF7          Zip archive data, at least v1.0 to extract, name: "system/system/drivers/"  
327           0x147         Zip archive data, at least v1.0 to extract, name: "system/system/bin/"  

After which we can examine the files in order to investigate the setup, and for default passwords:

We mount the bin file, and create a ZIP file, and basically just unzip it:

dd bs=1 skip=36  if=51.3.0.152.bin of=image.zip
unzip image.zip

One of the files contained is daemon.v5.5 which contains the main code for running the system and when we list it we get lots of binary characters but the text within the code has not been obfuscated:

root@kali:~# cat daemon.v5.5
ps > /tmp/gps.txt/tmp/gps.txtrfopen failed
encoderreboot/system/system/bin/encoder &/etc/passwdwbroot:LSiuY7pOmZG2s:0:0:Adminstrator:/:/bin/sh/etc/grouproot:x:0:adminsystem:%2x-%2x-%2x
this isn't system file

This reveals the default password, which can often be easly cracked with John The Ripper, which in this case is the hash of "123456".

Conclusion

There needs to be some standards applied to electronic equipment, and each of them must go through a full security evaluation test before they are allowed a licence to be sold in a country. Otherwise we have wi-fi dolls which can be easily compromised, or Web cameras which can be controlled remotely.

So, we have just got our enterprise systems to be security, but now the focus is on IP phones, Web camera, Air conditioning systems, and so on, as it is these devices which may offer a way for an intruder to get into a network.

Did you know that many Cisco phones have a password which is easily crackable:

 And how are we going to patch the vulnerabilities found in devices. It's a big delima for the car industry: