IoT hacked? As a cyber security company, we regularly create internal contests for the fun and education purposes. The latest one was focusing on the hacking of an IoT application. This article – redacted by one of our cyber security consultants – may be of interest to you especially if you are curious about cyber security or in the process of developing a secure application.
Introduction
Here in Approach; we are lucky to have skilled people that enjoy sharing their knowledge, notably during what we call our « Knowledge Lunch ». The topics could vary from cyber security, secure coding as well as Web penetration testing.
Latest subject was presented by our Senior Cyber Security Consultant, David Bloom. David presented us some web hacking techniques that are easy to perform, yet has devastating impact as an end result.
The purpose of this session was to demonstrate how easy it is to compromise a server or infect a client browser if the web application does not apply proper input validation or if the webserver is not properly hardened.
The challenge: “Hack a cheap, old, brand-less music streaming box” – context and rules
After the informative presentation, David had another gift for us: a challenge. David brought a cheap, old, brand-less music streaming box which he has borrowed from his brother to present a mission for us: get administrator access and find the flag he planted on it somewhere hidden within the files of the streaming box.
There were only 2 rules for the challenge:
RULE 1 – No defacing/destruction/alteration that could prevent others from participating (and possibly make his brother angry).
RULE 2 – No connection of the box on our own network or on the Internet to avoid inserting a vulnerable object in our office environment.
The box is fairly basic in functionality. It creates a Wi-Fi network on which you may connect to stream the music and share files. It presents a limited web portal with the following functionalities:
– A file manager to manage files present on a USB stick or a USB hard drive.
-Setup of the Wi-Fi hotspot.
-A way to connect to the Internet and your network through another Wi-Fi antenna.
-Setup the audio service.
-Setup of a Shared folder.
– Upgrade the firmware.
The penetration test
As a cyber security consultant, I was curious to see how secure the application was, and see if there was any challenge to black-box testing it. At first glance, the security was not this product’s main focus. Unencrypted services (HTTP, telnet…), very permissive cookies and more importantly, weak field validation were the easily noticeable weaknesses. Furthermore, some fields were removing angle brackets « <> » only client-side through JavaScript (weak protection which can be circumvented with a simple proxy), some fields did not validate anything, some did only character encoding.
This amount of potentially exploitable vulnerabilities on such a small application made it difficult for me to guess which one would be the best one to exploit. I quickly grew tired of trying each field and URL parameter. More importantly, I wanted to find the flag first.
Key for hacking
Yet, the key for hacking this device was in the extension of the pages: shtml. SHTML is a special extension that let the web server execute, if it allows so, Server Side Includes (SSI) instructions if they are presented in a static page. SSI is a simple interpreted language that allows to execute some commands on server-side.
So clearly, SSI was the exploit language to look for. But, how to inject it to the box?
I could have tried SSI injection, or create a shtml file on the server through command injection, or even code injection. But this could take long to find out how to exploit the pieces of code that would allow injection, so I took a shortcut instead.
I created my own shtml page containing some very simple SSI code: 
I copied the file on an USB stick, discreetly reached the box to insert it in the USB port of the box, then came back to my desk, pretending I went for a coffee.
Then I went to the File Management page and opened the shtml document from there:
To no-one’s surprise, the shtml page was executed server-side. The reason is simple: to be able to display the content of the USB key, the device was mounted in the working directory of the web application.
Result
The resulting page gave:
The first part of the challenge was won. I became root! Remote File Inclusion by simply plugging in an USB key. Nice!
So now basically I could do anything I want on the box. All I had to do is create other files to browse and open the flag file.
After reporting my findings, I was informed that it was only one of the vulnerabilities, and that there were others, involving command/code/file injection indeed.
In conclusion, how secure was it?
This box was a great example of insecure system, as it illustrated different types of flaws:
– Software flaw: field(s) that allowed injection.
– Configuration flaw: the webserver running as root.
– Physical protection flaw: the box was accessible physically.
– Design flaw: it will execute any file from a USB removable media, while it should only allow known files.
This box is an extreme case of IoT device that was not designed with security in mind. But what could have they done to secure the application?
Some advices for similar IoT application developers
Other than the physical security of the device which just made thing easier for me and vendors have no influence on, this box developers could have:
– Not run the webserver as root.
– Limit the working directory of the webserver.
– Limit the execution of shtml files to a single known directory through the configuration of the webserver or .htaccess files.
– Not give writing permission in the working directory and subdirectories (to avoid the generation of new shtml pages by an attacker).
– Configure the webserver not to allow the « exec » SSI command. For example, on Apache, the IncludesNOEXEC option.
– Better field validation.
Do you want to perform penetration test for your IoT applications? Have a look at our pentest page
Do you want to develop securing applications? Have a look at our secure development page
Advice for the end-buyers of IoT devices
If you plan to buy a new device that could be plugged on your network and/or on the Internet, you will need to consider that it is less powerful and smart than a computer, and therefore more vulnerable. When it comes for your security and your privacy, you will need to consider the risk of having such device just a hop away from your computer and/or your smartphone,
To limit the risks, you should aim for renown brands with a good reputation for security and avoid brand less or unknown brands. These last ones having no reputation to lose may be tempted to cut corners in order to lower development costs.
Once bought, the first thing you should do with a new IoT is: replace the default administrator password by a strong one!
Also:
– Ensure it is not accessible by an attacker physically. For example, do not leave it unattended in your apartment building corridor.
– Switch it off when you are not using it.
– Use a password for the Wi-Fi if it acts as a router.
– Keep the device up to date.
Want to stay up to date with the latest threats? Subscribe to our SOC newsletter.
