 Welcome everybody, thanks for being here. I'd like to start by saying that this is my first time at DEF CON, so I'm really happy to be here and really happy to be able to talk to you. I know that the title is a little bit generic, using the IoT in smart buildings, but that's intentional, that's because I want to take you through a journey of the research that we did in smart buildings that is culminating in, let's say, consumer grade IoT devices in smart buildings, but it started with industrial protocols with BACnet and all of that, and I'll take you through all of that, by showing you some of the attacks that we developed, and that's the main focus of the talk today. But first, a little bit about me. So I have a bachelor's and a master's in PhD in computer science, so I have an academic background, I have more than five years now in security doing some pen testing and mostly academic research also. Right now I'm a senior researcher at Forescout, and I do vulnerability research for OT and IoT environments and vices, and I also work with network monitoring and intrusion detection for OT and IoT. This presentation, of course, is not just my work, it's the result of more or less a couple of years of research with many collaborators at Forescout and also at the University of Eindhoven where I used to work before, so just bear in mind that this is not something that only I did. So a little bit of motivation, why are we talking about IoT in smart buildings and IoT in general? So what are the risks from IoT devices, right? So the number of devices in organizations is rapidly increasing and I think everybody is aware about that. IoT has already grown a lot in the past decades and is expected to reach, the numbers vary there, but people say between 20, 30, up to 50 billion connected devices in the next few years. Those devices are mostly unmanaged. They come from different vendors. It's not just the usual IT world anymore where we had Windows and Linux and maybe MacOS. So we have non-standard operating systems. We have a diversity of protocols. Many of them are insecure. There are infamous cases of insecure protocols in building automation. Some of these devices may dynamically connect to other devices. It could be inside or outside of the organization's network. And there's also another statistic there that by 2020, next year, more than 25% of identified attacks and enterprises will involve the IoT. This is a projection, but it's something that could happen. And there was this report released by Microsoft just last week about nation state attackers using IoT devices to infiltrate in corporations. They're using printers and voiceover IP phones and stuff like that and IP cameras, mostly. But let's talk then about smart buildings. So smart buildings is one of the places where the IoT is rapidly proliferating. So in the smart building, we have several functions. We have lifts. We have surveillance systems. We have fire alarm systems. We have lighting systems, HVAC, thermal stats, fans. We have data centers that have to be cooled. We have surveillance rooms to control the surveillance systems. And all of these are connected to a network and connected to building controllers. And why would anybody attack smart buildings? Well, first of all, smart buildings are not just shopping malls or residential buildings or something like that. They could be very critical buildings like airports, data centers, hospitals, public spaces, even factories. We're talking about, we're in the ICS village, right? So the factories that host the ICS devices can also be critical buildings that are smart buildings. These building automation systems and smart building networks are many times legacy systems. So some of those systems are decades old. There's many times no encryption or authentication. It's the same story as in ICS. But what's happening nowadays is that connectivity is increasing, right? So there's an increasing attack surface. There are default protocols and open ports, default passwords, weak passwords used in these devices. And all of that creates a perfect storm, let's say, for attackers. So OT, IT, and IoT are all converging in smart buildings. So if you look at a typical smart building network, you have a management layer where you have workstations, you have IoT platforms, and you have building management workstations that are connected and used to manage all of the field devices and the controller devices and all of that. And then you have separate subsystems, right? You have, for instance, video surveillance with IP cameras and NVRs and displays. And then you have the access control systems with badge readers and door locks and physical access control controllers. You have the HVAC system. You have the smart lighting system. And then you also have, in this whole scenario, the consumer grade IoT entry. So you have IoT gateways. You have things like smart plugs, smart TVs, wearables. In hospitals, you have medical devices, which many times are in the same networks as the building automation devices. You have other kinds of sensors and actuators and smart everything, basically. And although, we will see that later on, but although ideally, these networks would not be just flat networks and things should be isolated and all of that, in many cases, in practice, what we do see is just a flat network where everything is able to communicate to everything else, which is an ideal scenario for an attack. So what is the focus of our research? So we wanted to study vulnerabilities and attacks in smart buildings. And there are many attacks, attack vectors in smart buildings. And we were looking first at building automation systems of the legacy, protocols and devices, and then later on, the consumer grade IoT stuff. And then some of the attacks and areas that we imagined and some of the things that we implemented are, for instance, in HVAC, changing the temperature set points to, I think there was a presentation before talking about backnet and from the McAfee guys about backnet and how you can change temperature set points and HVAC devices so that basically data centers are taken offline or in hospitals, biological or medical material can suffer severe consequences. So you also have in the access control systems, you can add or delete authorized users. In the surveillance system, you can, for instance, delete or replay footage so that physical intrusions can happen. For the smart lighting systems, you can switch lights on or off or continuously on and off and basically make them unusable. And for other IoT systems, you can do things like denial of service. You can use them for information gathering, for pivoting in the network and all of that. So on the left-hand side there, what you can see is the lab that we built for this research. And you can see that there is a mix of legacy built-in automation stuff, so workstations and industrial-grade built-in automation controllers using protocols like backnet and Modbus and KNX and Longtalk and others. And you also have IP cameras and Philips Hue and Wi-Fi access points and stuff that are more consumer-grade IoT. So now I'll go through a list of attack scenarios and stuff that we implemented so that we can show some of these scenarios in practice, what are their effects and how to achieve those things. So we started as almost everybody who starts looking at smart buildings by looking at the backnet protocol, because it's really one of the major protocols used for interoperability in these systems. And it's one of the most used protocols in building automation. Nowadays it's infamous, because it's a clear-text protocol, there's mostly no authentication. Because of that, there are all the security threats, right? Or you can use it for reconnaissance. You can spoof devices. You can temper with variables, for instance, temperature set points or inputs and outputs and all that. You can do denial of service easily in many of these devices. So if you look at the right-hand side there, it's one of the parts of the lab that I showed before. And the little dollhouse is simulating a smart building where on the upper floor you have a motion sensor in the light, and on the lower floor you have a thermostat and a fan. And on the right-hand side you can see a lot of devices there. There's a network switch, and there's an HMI that's used to program the backnet devices. And there's another touchscreen device, which is actually a Raspberry Pi, simulating an attacker. And then on top you can see some backnet controllers. So the idea is that the usual functioning there is, yeah, you have a temperature set point, and then if the temperature ever goes above the set point, the fan starts working. And then if it lowers down, the fan stops working. And when there's presence detected in the house, the light goes off. But you can easily DOS the backnet router, which is the blue device in the middle there on the top. And the effect that you have when you run a simple DOS, so you're basically just flooding the device with many packets. And you can see that the packet's being sent there by the attacker. And you will see that basically the router will stop working, and then the error LED will go on. And yeah, that means that the device is not active anymore, and then it should be controlling the light. But it doesn't, right? So the light doesn't work anymore. So in this case it's controlling the lights, but it could be controlling HVAC or any other of the subsystems that I mentioned before. So OK, we can do that with using the backnet protocol and with building automation devices. But then we wanted to look at another attack scenario, which is basically, OK, if we have many vulnerable devices, can we create a chain on attack path, for instance, where a remote attacker could reach the devices that are actually controlling, for instance, the access control function in this case? So another thing we did is, in that lab, we did some vulnerability research. We disclosed some CVs. We found around, from not mistaken, eight CVs. And most of them were actually related to the web applications running in these devices. So I think almost all of them had cross-site scripting, and some of them had command injections. This is very common in this kind of environment. And we also found a buffer overflow that allowed for remote code execution. So we basically changed an attack where the steps are those on the bottom there. So first, we gained access remotely using an IP camera. Then we performed some lateral movement to the management workstation. Then from there, we moved to the access control PLC using the buffer overflow. We execute our payload over there. And then the idea is to persist also in that. And that was achieved basically by exploiting mostly the access control PLC, which has a web application and a specific building automation framework, Java framework running on that, and runs on top of the QNX operating system. So once we have that buffer overflow, we can basically leave off the land there on the device and use some of the devices on functions to upload our malware and persist. And then implement our final attack, which is to open or close doors depending on what we want to achieve. So for instance, here you can allow and authorize people to access sensitive locations, imagine that in a hospital or in an airport or something like that. Or you could also not allow somebody to access a specific location. So for instance, you combine both attacks, and you have an HVAC not working in the data center, and then you lock the door, and then nobody can go in and fix the issue. So then we actually looked at how many of those devices can be found online. And this is data from last year. So this we did last year. And we saw around 23,000 devices of the ones, the same models that we were looking at in our research. And we saw that around 40% of those, almost 40% of those, were vulnerable to the remote code execution, the buffer overflow and the remote code execution that we found. So that means that there are more than 9,000 devices available on the internet that's from Shodan that could be completely owned from the outside. So then we saw, OK, so we have problems with the protocols. We have problems with the devices in the building automation side, right, in the older stuff, let's say. And we have a lot of those available online. But what we have, what we really can easily find online are IoT devices and consumer-grade IoT devices and smart cameras, for instance, and such kind of devices. So we wanted to look at these IoT devices and what are the impacts that they have on smart buildings. So in this attack that I described now, we use the IP camera, for instance, as an entry point. But what else could we do with the IP camera, right? Or with the lighting system and all the other systems that I described. So the next three scenarios are about the IoT smart buildings. So our goal was to investigate the IoT protocols and devices used in the smart building. So some of the examples of the protocols and devices that I'll be talking about in the next scenarios are RTP and RTSP for video surveillance, the Philips Hill Smart Light for the lighting system, and MQTT for the IoT system. And we divided our findings there in three categories. So things that we found on the field. So basically by talking to customers and partners and by looking at the networks of these customers. Things that we found on the web, mostly on Shodan, and things that we found on our lab. So the setup of the lab is this is just a simplified version of the same figure that we had in the beginning. So we have the video surveillance system, the IoT system, and the smart lighting system. So let's talk about the findings on the field. So when we look at smart building networks with consumer grade IoT devices, how are these networks configured in practice? So first thing we realize is that many times these internal networks are not well segmented. So you do have one switch that has IP cameras and IT devices and an OT and building automation and everything talking to each other, not well segmented at all. So you have unwanted communication links between all these categories, right, IT, OT, IoT caused by misconfigurations. There are many unwanted services and insecure protocols enabled. So it's easy to find Telnet, FTP, UPNP. And many times the facility managers or the people who are managing those networks are not even aware that those things are activated because they come activated by default. The insecure protocols come activated by default and that's it. There are many times weak passwords to access devices. There are devices with no vulnerabilities. And there's a lot of use of unencrypted traffic. So I already mentioned RTP and RTSP for the video streams, and I'll talk about this in details. And you also have, for instance, HTTP and MQTT in clear text for IoT devices. So then what do we find on the web? So we were talking about the unencrypted protocols, right? So if we look at devices with clear text or TSP on the web, we find more than 4.5 million devices. And those are mostly IP cameras, but there are also other devices that use this kind of protocol. If we look specifically for the Philips Hue, for instance, for the smart lighting system, we found almost 10,000 devices online. And if you look at clear text MQTT, which is used for general IoT, you have more than 75,000 devices. And these data are from this year, actually, just from last month, because this is one of the latest things that we had been looking at. So let's go in details in these three next-to-text scenarios, right? So just in general, what are the findings of the labs? So again, this is the lab that we had before. Now we have an internal attacker. And what we want to achieve there is, for the video surveillance, we want to do a footage replace or a Hollywood style, highest movie kind of scenario where we are showing one thing to the security operator. But actually, the camera is streaming something else. So you can steal something from the bank. And in the smart lighting system, you can just basically cause a denial of service to make the lights go out or go on or on and off continuously. You can also use, in the case of the Philips Hue, something that's interesting, you can just reconfigure the platform to use that as a pivot point inside of the network. And in the case of MQTT and IoT devices, you can use that for, for instance, information gathering and denial of service. And these are the attacks that we implemented. So for the attack scenario number three for the video surveillance system, again, this is just a simplified version of the other picture. You have the IP cameras that are using RTP and RTSP to communicate with the network video recorder. And the network video recorder is connected to the network switch, and then you have a storage server and then local monitoring to look at the video being streamed. So what's the problem with RTSP and RTP? So they are streaming protocols. One is usually over TCP. The other one over UDP. One is to send the data. The other is to control the session, basically. RTSP is very similar to HTTP. And it's used to control the stream. And it's basically mandatory to establish a session before you start streaming via RTP. And RTP is designed for a real-time transfer of usually audio and video data. It's unidirectional from a server, which is the camera to a client, which is a network video recorder. And there are secure versions. And you can use the GLS, for instance. But this is rarely used in practice. So what is the anatomy of an attack here? Because you're using these unencrypted protocols and you are, in turn, in the network, you can just establish a man in the middle. If you drop the traffic and record the video footage, it's unencrypted. It's a clear text. You can replace a heartbeat RTSP command. Usually it's a get-per-end command with a tear down. So you stop the connection between the camera and the NVR. And then you just basically tell the camera to stream some URLs, and then you start streaming your pre-recorded footage to the NVR. So we do replay a pre-captured stream to the NVR. So in practice, this is how it looks like. So you have the surveillance footage. And this is what the camera is normally streaming. And then in the attacker machine, you run attrcap to do a man in the middle. So you select the hosts. And then we have another script, which is actually recording the footage and replaying the pre-recorded footage when the session is stopped. Yeah, and now basically the session with the camera has stopped. And then now we are replaying something that was captured before. And then on the bigger screen, you can see what is actually going on. And on the smaller screen, you can see what the security operator or the surveillance guard would be looking at. So this is another attack scenario, attacking the Phillips Hue. And the Phillips Hue is interesting because it's a very common IoT device, which until last year didn't support HTTPS at all. It was only supporting HTTP. And a lot of people knew about that. And it was very easy to attack a Phillips Hue. And then they issued a former update last year. But basically, what is used to validate your communication with the Hue is an authorization token. And that can be just sniffed also from the network because it's in clear text. And then an attacker can just control the camera. So you just send a put request there for the state of the camera so you can do on or off. I just saw that I have like three minutes left, so I'll run through the slides. So you can just switch the lights on or off. And then as a result, you can have something like this. So it's basically that the light is completely unusable. So the last attack scenario that you have is MQTT, which is a published subscribe protocol used for IoT devices where you have a broker that coordinates the communication between a set of publishers and subscribers. And that's used to exchange sensory information, telemetry information, and also to issue commands to some devices. And again, it's usually used in clear text. So you can just passively sniff the traffic. Or you can subscribe to some topics. And you can use that for information gathering to understand the devices that are in the network. You can subscribe to wildcard topics. So you can see basically every topic that a broker is handling. It's very easy to do denial of service also, because you have quality of service that can be increased. So you amplify the attack with the responses that are required. And you can use very heavy payload. So it's a very common protocol in IoT. But again, if used insecurely, it's very easy to attack it. So in mind, with all these scenarios of attacks, let's very quickly talk about defending the IoT. So the things that we should do so that those attacks are mitigated or cannot happen. So the first thing is that we need network visibility. So you need to know what devices are on the network so that you can know if they're vulnerable or not or what kinds of protocols they are talking, what devices are communicating to what other devices, and so on, which allows you to do proper asset management, so proper configuration and patching of the devices. Network segmentation is extremely important, so you can isolate problems and reduce the attack surface. Sometimes there are devices that are difficult to patch, so at least they should be segmented. And as a last point, network monitoring and intrusion detection, you should basically know what's going on at the network in real time and be able to spot anomalies and attacks happening. So more details about these attacks and about the defenses and all of that are in four papers that we have over there. The top two papers are actually academic publications, and they deal mostly with the backnet stuff. And they deal mostly actually with the defensive side, so how to do intrusion detection for backnet. But we also describe the attacks. And the two white papers on the bottom are commercial white papers. So they describe most of these attacks and areas that I showed here, and also a little bit about defense. So what are the key takeaways from this talk? Abusing the IoT in smart buildings, it's easy, it's cheap, can have severe consequences, right? Like we've seen with HVAC, with Access Control, where you can let the attacker basically do physical intrusions. And defending the IoT in smart buildings, it's doable, and it starts with understanding what's in the network and monitor, right? And as a last takeaway, I just want to say that the building automation technologies is old, but we are moving to more connected smart cities and connected everything, so we should always keep in mind that more connection means an increase that our surface and the consequences of these attacks also. So sorry if I went over time. Thanks.