Blog: Internet Of Things
This week’s IoT security news
Here’s a round-up of noteworthy IoT security stuff I’ve come across in the last 5-6 days.
TP-Link serves outdated or no firmware at all on 30% of its European websites
Firmware updates are an important part of any IoT or embedded system. Often this needs a manual firmware update – but how easy is it to find the download, and is it up-to-date? This blog looked at nine TP-Link products to see how consistent and recent firmware downloads are. As you’ve probably guessed, the results aren’t great. We’ve seen the same across many other products we have tested.
https://www.ctrl.blog/entry/tplink-firmware-outdated-downloads
Busybox autocompletion vulnerability
Busybox is the multipurpose binary used on many embedded system, providing commands like grep, find, telnet etc. It can also act as a shell. A vulnerability has found in the sanitisation of escape sequences whilst performing tab autocompletion. You think you are tab completing DirectoryToDelete, but the shell will process any escape sequences – including backspace, commands to dump the terminal to file. It can lead to RCE.
I could see the vulnerabiluty being hard to exploit on IoT – most are single user systems with only rare interactive use. But little did I realise, it seems that busybox is starting to be used in containers due to it’s low size.
https://www.twistlock.com/2017/11/20/cve-2017-16544-busybox-autocompletion-vulnerability/
Intel ME has many vulns
The Intel Managment Engine is a subsystem that is probably running on all of our machines, a tiny separate processor and OS that has very high-level privileges, including potentially access to all memory and network traffic. And it contains a number of buffer overflows. No exploits out there in the wild, but this is a key example of why we need to have full security audits of all code running on our machins.
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00086&languageid=en-fr
Logitech “bricking” a product
Logitech are withdrawing support for a product and it is being termed “bricking”. I suspect the device just relies on the cloud service -and taking that away stops it working. Raises interesting questions around automated updates and cloud based services – do you truly own these devices?
We have seen similar before, when Google bought Revolv:
https://www.theguardian.com/technology/2016/apr/05/revolv-devices-bricked-google-nest-smart-home
And when the owner of an Internet-connected garage door opener got the hump with a customer:
Inside a low-budget GSM bug
A GSM bug hidden in a USB cable. I have one, it’s really not very good. Audio is very poor, reception is marginal even in strong signal areas. But the insides of it are interesting. A good teardown and examination of how this one works.
https://ha.cking.ch/s8_data_line_locator/
Reverse engineering another BLE device
Another interesting post on reverse engineering another BLE device. If you work in IoT security, take a look at some BLE equipment – it’s becoming more and more popular. Yet security seems to have stagnated somewhat.
http://jacksonbaker.net/reverse-engineering-the-misfit-bolt-btle-protocol/
Vulnerabilities in implantable cardiac defibrillators
I wouldn’t want one of these in me. This paper reverse engineers the protocol and finds weaknesses.
https://www.esat.kuleuven.be/cosic/publications/article-2678.pdf
Crypto issues in the encryption used to secure intellectual property in chips
IEEE standard P1735 concerns the encryption of intellectual property passed between entities when designing chips. As we have seen many times before, it uses sound primitives such as AES, but the implementation leaves many holes. Firstly, a padding oracle is found, allow the plaintext to be obtained. An even more advanced attack is developed using a syntax oracle – instead of just finding out the padding is wrong, you find out if there is an error anywhere in the file. Finally, the use of hardcoded IV means an attacker can modify the first block of plaintext and insert a hardware trojan.
