Challenges of Securing a Custom Embedded System

After many years of “hobbying” in the security field, I learned that people tend to ignore the possibilities a potential adversary may have. I have had much fun but never wrote about it. And that is a shame. Some of my stories are almost ten years old, and I will certainly come back to them, but now I need to self-reference myself for my bachelor thesis on more relevant issues, so let’s start with that!

New girl in town

I have a little psychological disorder: A strong urge to examine every area I live in for some time. All the corners, all the possible ways to penetrate the building, all the cameras, motion sensors, cabling, power sources, valves, etc. And I have lived in one particular dormitory for quite a few years now. So you can imagine how well do I know the building. More about that may come in my next posts. Anyway, it has been pretty quiet place lately. And I was getting bored, too.

Until suddenly the provider of our dorm’s reservation system was installing a new “electronic coin box” for the washing machine to replace the old, apparently “non-electronic” one. And I just somehow knew that it was going to be fun. As a local network administrator, it is my duty to make sure that our little network is safe. A duty I immediately started fulfilling. Well, OK, that particular subnet was out of my competence, but let that just sink in for now.

The electronics of old, apparently non-electronic coin box for actual physical coins ?

Physical security rules them all!

Opening the device was too easy. No lock, no alarm, no seal. Only two clips were holding it in place. Something like this is a clear invitation for me. I took some photos quickly and ran away to analyze them.

Open, take photos, close and RUN! You can do the analysis later and in comfort

So we have got a Raspberry Pi 3 Model B with two modules attached to it: Directly on the GPIO – the one with the RJ-11 port for extending the 1WIRE communication to the washing machine and connected to the solder points a 125kHz module, apparently for the EM MARIN chips my University is using for identification. I know… that itself is very sad. And I will come back to that. But moving on…

Encryption is too hard…

Well, here I was, ready to do some advanced analysis. I removed the TF card, made an image and pushed it back. And I got surprised again: no encryption. Well, that is understandable, because home folder encryption is not compatible with autologin and unattended boot of encrypted volume is pretty hard. Sadly, the device was already completely compromised at this point. All you have to do is write some nasty stuff, flash the card, reboot and you have a proxy with full internet access for doing other nasty stuff without being suspectable, log the cards or even worse – you can wash your clothes for free. But bear with me, we are only at the beginning.

So let’s look at the files: Logs exposed the IP address, which was behind the firewall of some sort (thank god) and the code for student identification and activating the washing machine was very lovely, unobfuscated and easily readable Python 3. Not sure if that is something you want after it has been deployed, but well, I guess the intellectual property is not a concern. I have to acknowledge the fact that the code was written as a pure dumb client and everything was controlled from the server. This way the communication with the washing machine stays hidden… Until you read the API… Or change the python code to monitor and log the communication , of course.

That was great fun, but then I noticed the startup script. Guess what. It did contain the s-word. And that blew my mind because it became clear that the developers didn’t know what platform they were dealing with, which they humbly acknowledged later during our mutual effort to resolve the issues. To use sudo on a fully deployed embedded system only to access some device is kind of nuts. You see, the problem is: how can you use “sudo” command with a deployed embedded system? To make it not ask for the password.

RPi, passwordless sudo & autologin

This is the very first time I plugged in my keyboard, switched to tty1 and wrote something…

Yes. They did. Really. So just by connecting a keyboard and switching to any tty, you have full root access. Sadly, after investigation of RPi forums, this seems to me like a common practice. That already is pretty hardcore so… can we get any more fun? Sure! Creating my own sudo user and opening an SSH tunnel so I can play is a matter of course.

RPi & software updates

We all know that guy who hates Windows Update, and his ultimate solution is to disable it. I hope that you, dear reader, are not one of them. But it can be worse – I once met a person who did not upgrade a single package on his Linux installation for more than two years. He is a developer. Scary, isn’t it? Well, guess how old kernel version is on our little happy coin box. Not half a year. Not a year. Not 24 months… OVER 2 YEARS! There are dozens of critical and exploitable bugs found in Linux kernel every year and 4.1.19, being released in March 2016 is exploitable even with easy-to-use Dirty Cow! So there would be no problem hijacking the device anyway, considering that autologin is a must here. The devs apparently did not have any idea about the risk and because Linux distributions do not include kernels as part of automatic (unattended) updates, you have to do it manually. So again, ignoring these updates looks like a common practice in this community.

Lateral movement

Let them have a break for a moment and look one level higher – at the horrifying consequences of what we just learned. So where are we right now regarding the network? The device has its own public IP address. But at the same time, it is routed in a strange way so that it is hidden behind a firewall in an artificial subnetwork. And with it… other very attractive devices. By the way, all of them have their own public IPv4, which is common at my university. We have enough of them anyway so f*** it. The firewall is an apparent effort to protect the devices somehow. Well, that effort is worthless now. I am already inside. And simple ARP spoofing, an easy to defend against attack, seems to work well here.

Access control system? Yes please!

Honeywell – a well-established company with a pretty wide range of products including autopilots and thermostats and with a development center here in Brno. Their portfolio also includes something called NetAXS – an NBÚ-certified (National Security Authority of Czech Republic) access system. And there is one in the subnetwork our little coinbox has just opened to me. And it is no good. Simple raw tcpdump revealed that the EM MARIN card numbers are being sent to the server unencrypted. Also, “access granted” is represented by empty TCP ACK packet from the server, while “not granted” is represented by ACK with some (at this point entirely irrelevant) data. And that means gaining access anytime I want just by spoofing an empty ACK instead of non-empty ACK.

But that is not so interesting, because in combination with a forgotten interface in University’s information system revealing the identity of a person based on ISIC number, or EM chip number that means easy tracking of anyone living here. And having access anywhere they do. And eating in canteens at their expenses and basically doing anything they can do. And they even don’t have to use the coin-box! How cool is that? A specimen of lateral movement.  So big check here. Moving on!

Security cameras

There are three IP cams at my dorm. All of them appeared in the subnetwork. And here is my first applause for anyone who dealt with them. Passwords are not the default ones, and video transmission is an RTP. I have been too lazy to wait for authentication, and the stream is probably encrypted because I have not been able to replay the videos successfully. Maybe that is just lack of knowledge. The only interesting thing is that one of the cameras has an undocumented telnet service running which smells like these well-known proprietary techniques to reset the password. But I was not able to reverse-engineer the process from the provided firmware. Anyway, one kind of attack – caging the cameras so they could not send any data – is pretty much possible here. So, that’s another check.

Nice proxy

All of the above has more-less only local impact. Considering the nature of data an attacker could get access to, it could be easily played down as “not a big deal.” And I am not even mentioning the pre-GDPR world. But this particular device has unlimited network access. And what could be the better prize for an attacker than getting a new proxy for his activities! This is what I call a “Hello World!” And this is why every network administrator should always keep an eye on the devices his network is serving. You never know when you’ll be suspected for something horrible.

But how to fix it?

Because I didn’t want this to be only about me grumbling on other’s work, I tried to be constructive so I cautiously contacted the company behind the device. They immediately started internal talks about how to resolve the issues and even asked me about my ideas, which for me was really surprising. Now let’s learn something new!

Getting physical

You don’t want accessing your hardware physically to be easy. Period! While it can’t be impossible, an attacker could have a tough time by just finding a better lock in place. Remember, an intelligent attacker capable of exploiting physical access would not want to be intrusive so destroying the lock or the container is not an option here. The problem is, “better lock” (which means pick-resistant) would cost too much.

The idea from our guys was to use a magnetic sensor – simple reed switch which would trigger small alarm and notice the personnel on opening the case. Great idea! Combine it with tamper-evident stamp and you have a cost-effective way of deterring and detecting the adversary. An alternative could be using IR proximity sensor the same way.

Learning Linux

Linux is NOT easy. There is a plenty of stuff to master until you can use it meaningfully and securely. In this case, we encountered two problems:

  1. Using sudo is the easiest way to access a device. But when you deploy the product, this magical word should not be present anywhere! For accessing the devices Linux offers groups – to allow an user the access, just add him to the corresponding group: tty for serial consoles, i2c for I²C or I²C to 1WIRE converter and so on… Also, if you really need to call sudo for some system calls, using a SUID bit on your executable is still a better idea. However, in this case it is completely your responsibility to make the executable as secure as possible. In our case, however, you can not do it the correct way, because you can always run a python script with -i, which basically makes you a root in this case.
  2. Software updates – while apt in Debian-based distributions updates the standard packages automatically, Linux Kernel needs to be upgraded manually. In case of RPi, the easiest way is to trigger the rpi-update tool. This is very important, because from time to time a new critical bug appears. And some bad adversary may appear as well.


Now the level of security is at least satisfactory for our usage. But in different setting and with different services, let’s say something that a life of some people depends on, you should consider brutal redundancy to your security. For example let’s say I would be able to open the case without triggering the alarm. There are still ways to capture the device. One of them might (as already mentioned) be tampering with the TF card – inserting load and restarting. So what could you do next?

  1. SD Card removing detection
  2. Cutting down power from USB (or disabling them whatsoever – if you do not need USB peripherals on board such as networking) and disabling UART – debugging would be really hard for you, but no one will play with your console. There may always be some 0-day bug which can be exploited for the privilege escalation.
  3. Multiple ways of tampering detection – combining magnetic sensor with proximity, maybe even mechanical button… It may be always possible to contain all of them during a professional attack.
  4. Hide it! As mentioned, there is one great way how to avoid any executables being physically present – PXE boot (Boot via LAN). This is still a hard one for raspberry, but it certainly is possible.
  5. Encrypt it! You can’t just use simple home encryption, because it is absolutely irrelevant with autologin. Also, encrypting whole volume needs some user input at the beginning. But, there is always a way – this one is kind of magic, but it works:  Hacking initrd to act as ssh server where you can input the key. You’re welcome 🙂
  6. Do NOT use Raspberry and similar? These boards are actually meant for education and not for production. There are better and more expensive boards such as DragonBoard, which does even have the TPM so you can use it with BitLocker and Windows without such magic.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.