Lessons from Pentesting Smart Buildings
We have been pentesting both digital networks and physical hardware separately for many years, but in the last 5 or so years we have been seeing more and more tech being integrated into buildings. 'Smart' technology is being introduced to make them more efficient, less polluting and more user friendly.
People can sometimes have a hard time understanding that smart buildings are not always more secure than the 'dumb' ones of yore.
I want to take you through some of the things we have discovered in our pentests of smart buildings so that you can either find them during your testing or, if you are designing a new building, learn from our findings as appropriate.
This is one of those blog posts where I really wish I could share photos of the devices I am talking about. However, for the safety and security of our clients, and the hardware manufactures, unfortunately I can't do that. I also want to save the embarrassment of some other security companies 😉
Smart Building (In)Security
When it comes to smart buildings, first you have to understand what it is you are trying to achieve. It's easy to get hyper-focused on just that aspect and forego everything else. Often, of course, this is where security gets left behind. That is unless security is the main goal, then the danger is that it is executed poorly because the focus is not on the ecosystem as a whole, but on that one particular function you are adding.
Let me give a few examples here so that we can think about this more easily.
We worked with a multi-national bank to test their new flagship smart building. Their focus was to reduce energy costs and therefore save money. The solution they were sold was to integrate smart desks. The desk communicated with the phone of the person using it via bluetooth and then pulled their information from the cloud and automagically adjusted the desk to their preferred height, standing or sitting. It worked brilliantly, and was a sight to behold if I am honest. It felt like the future!
But how did this system work? Obviously, firstly, each desk had a controller, and then every ten desks were connected back to a gateway box. This box then did the communication with the 'cloud' service to pull back the correct data.
But how did it do this? Well, taking the controller box apart we discovered that the device connected via a GPRS sim card... That's right, just straight out to the internet via a cut down cell phone.
Digging into this, we discovered that you could indeed reach the controller box from the external internet, with no firewall or anything in the way. What's more, the building had several floors and hundreds of banks of desks. In total we found roughly 300 endpoints sitting on the internet that connected straight to these desks.
Are you ready for this to get worse? Because this is where it gets much worse.
As this is a 'smart' building and the people in charge had not listened to their security teams, each bank of desks was to be monitored. This allowed them to see in real time which desks were in use. This was managed by connecting each of the control boxes to their internal network. No, it wasn't even on a separate VLAN (although we know of course that VLANs can be compromised, a separate VLAN would still have been better than what was actually set up).
I am sure that most of you reading this right now can see the problem here. For those of you that are unsure, what we have discovered here was 300 internet facing entry points directly onto the internal network of a large bank. No firewalls in place, default credentials were in use, and there was no monitoring or logging. What this means is that anyone could stumble across these endpoints online and gain access to the internal network, potentially exposing customer data and financial information. Even stealing money.
In short: a disaster waiting to happen.
It's these types of scenarios that smart building pentests can uncover. A gold mine of control systems are often bypassed where the 'smart' meets the real world.
A lot of companies spend money without investing time and effort into working out if the devices they buy are actually secure. In my entire career, I can think of only one device I have tested (so far) that had no serious issues. It was a device meant for monitoring water based products, such as grey water systems, and feeding back pressure and flows. Unfortunately, it is more common that a hardware device is built to the cheapest possible specification. Consider that when you buy a new device and plug it into your network.
For example, a device we tested recently was little more than a Raspberry Pi compute module packaged in a fancy box and sold for 10 times the price. Funnily enough, when we inspected the device the Pi module was glued in (seemingly by a child). The good news is that the manufacturer actually fixed this in the next iteration. The bad news is that the way they did so actually made the module more removable.
I have digressed here, but I hope you are starting to see that hardware devices are not given the same rigorous testing as code-based systems. Despite rigorous testing, code-based systems often have bugs. So without the testing, you can imagine the amount and type of security issues that can be found in hardware devices.
Let's take kiosk systems, those TVs that only display one function like providing a smart map. Often these are just small linux based computers connected (often zip tied) to the back of a touchscreen monitor. A quick USB insertion and a power cycle will get you pretty quick access into whatever network it is hosted on. I have done this in plain sight during assessments and not once have I been approached by staff and asked what I was doing.
Smart buildings are often rife with attack vectors that encompass the worst sides of physical and digital security. One of the biggest issues we see in our testing is that people (sometimes including security teams) are somehow blinded by the shininess of new equipment. I have compromised many client networks by leveraging the hardware devices in their smart buildings.
What does this mean for you?
If you're considering putting smart devices into your buildings (or you've already done so) hopefully this blog post has highlighted that these devices are not tested to the same standard as software. They can create a larger threat landscape that your security teams may not yet be aware of.
Consider adding smart devices to the scope of your pentests. And, if you're in the planning stage of a smart building project, you don't have to wait until the final stages to have such a test. Consultancy earlier on in a project can often be cheaper and more effective.
If you're a maker or breaker, you may be wondering how you can start looking at your own devices or how to start testing them for your clients.
First understand that all hardware - no matter what it is - is just a portal to a computer. Look at each device as an opaque magical box, it takes input and gives output.
Inspect it as if it was an alien device. How does it communicate with the outside world? How can you leverage those ingress and egress points? Once you understand what it is doing, you can even open up the device and, sure, you might break it but you might not! Watch videos on youtube on opening up devices, cheap tools can be found on amazon or e-bay. Once you are inside the device start to map out what bits do what things. After several devices you will soon see repetition and be able to rule out certain areas to avoid wasting time.
Working out how a device works is the hard part, but remember it's just a computer, maybe a tiny one but its still a computer and normal pentesting methods work on it. Maybe the device has a removable SD card or maybe its an IC you can image. Many devices function on the premise that it's a physical device and no one would ever open it! Security can be very lax because of an assumption no one will have physical access to the device itself.
People often shy away from hardware devices as it feels very hard to learn, but honestly you do not need much in the way of electrical engineering to make an impact. I would say the only real hardware you need to start is a volt meter and maybe a UART adapter. But in all likelihood it will have a standard network adapter and you can already connect to one of those! There are many tutorials online about hacking home routers as a great start for hardware hacking.
Once you have figured out all the functions of the device, how it's updated, how it's built, how it runs, what it does, how it does it - and so on - you can then start to work out how to abuse it.
Some of the things we often find include:
out-of-date software that has remote code execution vulnerabilities
default credentials in use
network ports open that shouldn't be
management interfaces that no one knows about
But remember we are not just testing the device in isolation, the device may behave very differently in situ or when configured. Make sure that you test a live version of the device, do not assume that the team installing it has done so properly, you must test all aspects and how the venn-diagram of installation crosses over into the smart building network.
The world of hardware hacking is a vast untapped universe of issues, and when combined with a standard network to make a smart building, it often brings more security issues than it solves. But, with the right planning and testing, you can eat your (smart) cake and have it, too.
If you are interested in having Cygenta test any of your smart building devices please do get in touch, we would love to work with you.