DEF CON 29 - Claire Vacherot - Sneak into buildings with KNXnetIP

00:09 - First, a little bit about myself. I started as a software developer, then moved to software security and then to embedded and industrial devices and systems security.

00:20 - Also in my job, I like penetration tests on unusual environments.

00:24 - And by unusual environments, I mean for instance, factories, transportation systems, amusement parks and so on.

00:33 - During during these assessments, we often have new environments with unknown devices and protocols, and we usually don’t know where to start.

00:41 - And this is what happened for me with building management system and KNXnet/IP.

00:48 - Just before we start, a little disclaimer. Testing industrial systems and building management systems can be dangerous.

00:56 - They control physical process. So they may have an impact on people’s safety causing accidents or disabling alerts.

01:04 - So please be careful. So during our assessments, we usually test on mock environments or at least environments we control to avoid unknown side effects.

01:18 - Now that said, let’s talk about building management systems.

01:21 - You may have already heard of them, as this is a really not the first talk about building management systems.

01:27 - But I don’t feel it’s yet the time to stop introducing them first.

01:31 - So here we go. Building Management Systems or Building Automation Systems are systems that can control every component in a facility from lighting to security systems, including HVAC, sometimes elevators and so on.

01:48 - As their name suggests, they are used to automate these components and to control them easily, and you can find them in all types of facilities like homes, factories, hospitals and so on.

02:02 - So here’s an interesting example from the movie “Hackers”, which has a BMS hacking scene.

02:09 - The main character hacks into his school BMS interface and he schedules the sprinkler system to run at a certain time, basically for revenge.

02:20 - And this is what’s happens. So I don’t know how it was back in 1995, but now apart from this weird (indistinct) interface, this is quite a workable scenario.

02:32 - We can definitely do this, provided of course that sprinkler system is linked to the building management system.

02:42 - So now, let’s take a closer look at this technically.

02:47 - In BMS, as a main part, is the field part where the actual components are.

02:54 - We often find three types of components, sensors, actuators, and controllers.

02:59 - If we take them, the example from “Hackers”, a sensor could be a fire detector.

03:04 - The actuators could be the sprinklers and so on.

03:09 - So they communicate, these devices communicate with each other using Fieldbus protocols, usually on twisted pairs or radio frequencies.

03:18 - So this part can work standalone. And in fact, before it was the only part.

03:25 - But then the field bus got connected to the IP network.

03:29 - First, because there’s that trend to connect everything, but also most probably, so that operators could reach and control them more easily.

03:37 - So basically, there are additional devices that will call IP interfaces or gateways or server or whatever.

03:46 - And these IP interfaces makes a translation between the IP world and the field world.

03:53 - So to simplify, the operator just needs to be on the same network as this IP interface, to configure and control the field parts.

04:01 - In a way, we expose components that used to be only reachable physically to anyone on the network or even the internet.

04:11 - And that’s interesting for us. And we may definitely want to take a look at it from a security point of view.

04:19 - So in industrial and building management system maiden software and protocol were created before we started talking about cybersecurity.

04:27 - Or they were created without considering that they may be exposed someday.

04:30 - And they are usually meant to last for a long time.

04:34 - So some of them do cover safety measures, which are prevention against involuntary failures, but they don’t cover security issues.

04:43 - They don’t cover provoked error. For instance, they don’t prevent from forging or replaying packets.

04:51 - And it’s also quite common to find configuration flaws on them, such as default credentials or only one user which is used to run everything on a device and its root and so on.

05:04 - So see first, a lot of things to think about when it comes to industrial systems and building management system security.

05:13 - But there’s more. Let’s take and even closer look at the interface between the LAN and the field.

05:21 - So it’s usually a device in an electric cabinet.

05:23 - So it’s means that it’s hardly reachable physically, but of course, reachable from the LAN.

05:32 - And if you just scan one of them, you may notice that several services are running.

05:37 - Like first the usual stuff for administration, most likely at least HTTP, maybe SSH or any other.

05:47 - But you may also notice another port, which is the building management system protocol service.

05:53 - What are they? As I said before, field components communicate with each other, using a field protocol.

05:59 - Some of them now have an IP layer, which means that you can contact interface and field devices directly using the IP version of this protocol.

06:11 - The most two common of such protocol being BACnet and KNX.

06:16 - So what happens, is that the operator will send a BACnet IP or KNXnet/IP request to the interface, which will interpret it and relay it to the field bus.

06:32 - They are field BACnet or field KNX requests.

06:39 - Today, I want to focus on thought for several reasons.

06:42 - First, because we already know the other services and you can at least expect some basic protections from the vendor, which is not necessarily true for the BMS protocol.

06:54 - And more importantly, this protocol is a direct way to talk to devices.

06:59 - It’s the best way to gather information and to run commands on the BMS.

07:04 - And finally, they have the same flaws as many of our industrial components are protocols do not consider cyber security.

07:10 - And a lot of implementation were written a long time ago and never updated since then.

07:18 - What do we have so far? So we have field devices and protocol that should not be exposed.

07:26 - And we know that they’re actually hard and that we can reach them.

07:31 - Yeah. IP interface devices. We also know that there’s this IP version of the field protocol no one has heard of before to do that.

07:41 - And finally, we know that we can talk to devices directly using that IP version of a BMS protocol through that IP gateway.

07:50 - Yeah. What can we do with that? So in the next few slides, I talk about two general attack scenarios on building management systems.

08:01 - The first one consisting in sending valid stuff on the IP interface, using the BMS protocol, and the second one consisting in sending invalid stuff, which is brilliant I know.

08:16 - So, let’s talk about the first one, which is the most obvious one.

08:20 - Here, we want to send legitimate commands to change the BMS’ behaviors.

08:24 - If we go back to the example from “Hackers”, we could for instance, enable sprinklers, which may or may not be fun depending on the situation.

08:34 - We could disable the fire detection, which is not fun at all.

08:39 - In a trickier way, we could also change thresholds.

08:43 - For instance, by setting the smoke detector thresholds higher, when an alert is triggered, it may already be too late, which is still not fun.

08:55 - Or you can just do whatever you want as long as it’s allowed by the system and this is very important.

09:02 - And why can we do that? Because as I mentioned before, these protocols do not cope with cybersecurity.

09:09 - There is no protection against replay or whatsoever and often no authentication or at least authentication by default.

09:19 - So here’s a small example I did a few months ago.

09:23 - This is an HVAC system in a test environment, which can be controlled with BACnet.

09:29 - So I have no idea what’s inside the BACnet protocol, but just by listening to the traffic and extracting the right frame, I was able to make it unavailable.

09:40 - So this is a script I used. This, it just replace the command to turn the system off every one second, and that’s enough.

09:51 - And by doing this in a real environment, this could have a really bad effect.

09:55 - For instance, in a data center without the HVAC, the servers would just overheat to death.

10:01 - Also in buildings made entirely of glass, what happens if you turn the HVAC off? Also imagine in Vegas and for the air renewing parts, if it’s turned off, all the bad things would stay in the air, which is really not suitable, especially during a pandemic.

10:26 - So the other scenario is the unintended use of devices using these protocols.

10:32 - In scenario one, we run a legitimate commands and can only perform expected operations.

10:37 - Here, we want to send malicious stuff and wait for something unexpected, most likely something you could exploit.

10:45 - And what makes it happen, is of course, the combination of security issues on these devices that we talked about previously.

10:54 - But it’s even easier knowing that a lot of BMS IP interfaces run Linux-based operating systems.

11:01 - So here’s an example of what you can do. If for instance, you can compromise an IP interface exposed on the internet.

11:13 - From the internet, you could gain a foothold in the network and possibly keep it or move somewhere else on that network, or do anything else on that network.

11:27 - An alternative to this scenario could be to use the BMS for network pivoting.

11:32 - For instance, in industrial systems, IT and OT network should be segregated.

11:37 - They’re not always segregated, but at least they should be.

11:40 - So now imagine having a BMS that’s connected to both.

11:44 - I’m not saying this is a common setting, but it can definitely happen.

11:49 - So someone who has access to the IT and wants to move to the OT would probably consider compromising devices that are connected to both.

12:01 - So this is it for the scenario. Of course I didn’t invent any of this.

12:06 - And if you want to know more about BMS in general, there are already a few conferences and paper.

12:12 - Also, there are already a few talks about BMS exploitation and among them, I recommend the one by Jesus Molina at Defcon 22, which talks about abusing a KNX system in a hotel, and which is really good.

12:29 - Also, there is already some work about advanced testing on BACnet systems and research about attack detection and remediation on BACnet.

12:39 - But as you can see this is really all about BACnet, so where is KNX? Actually, the scenario that we just went through can be applied to any building management system protocol that has an IP layer.

12:52 - So there’s of course BACnet, but there’s also KNX.

12:56 - And we don’t know much about it from an offensive point of view.

13:00 - So in the context of everything that we’ve just seen, we’re going to focus on that protocol for the rest of the presentation.

13:09 - So let’s talk about KNX. So as you already know, KNX is a BMS protocol with an IP layer.

13:17 - It’s mostly used in Europe and Asia, whereas BACnet is mostly used in the US.

13:23 - And of course, like the other, you can find it in all types of homes and buildings.

13:28 - For instance, in my office, the lights and chargers are operated by KNX.

13:33 - So, I just like to say a few words about its history, because I think it’s interesting to understand some choices they made about the protocol.

13:42 - So basically, it’s a merger of three European field protocol standards that were used since the ‘80s.

13:49 - And they were merged into KNX in 1999, then eight years later, KNXnet/IP was created and then the KNX installation became reachable from the network.

14:01 - And then again, six years later, security came.

14:06 - The first KNXnet/IP security extension came out.

14:11 - And finally, it’s important to note that the Standard is only free since 2016.

14:16 - So that’s only been five years, which is not that long.

14:23 - But even with the specifications available, they’re still pretty hard to use.

14:27 - And I get back to it later. There are a few external documentation and also a few research and work about KNX security.

14:38 - But, obviously that does not mean there is nothing to say about it.

14:44 - And actually, there’s a lot to say. (chuckles) But the Standard got it covered.

14:55 - They say, “For KNX, security is a minor concern, as any breach of security requires local access to the network. ” But that does not mean there is nothing about security in KNX.

15:09 - Some vendors implement authentication, not all of them, but this is usually an option, which is usually disabled by default.

15:19 - Also there are security protection. I mentioned extensions, which are KNX IP Secure and KNX Data Secure.

15:28 - But once again, they’re extensions. They’re add-ons.

15:31 - And you usually have to pay more or to get better devices to have them.

15:36 - So yeah, security is optional. And about the device’s exposed, I’m sure that.

15:43 - I’m not saying that none of them use authentication or security extensions, but I’m just saying that most of them probably don’t.

15:55 - But then, the Standard go that covered too.

15:58 - They say, “It is quite unlikely that legitimate users of a network would have the means to intercept, decipher, and then tamper with the KNXnet/IP without excessive study of the KNX specifications. ” So, this is what we call security by obscurity, and that’s bad.

16:18 - So KNX, hold my beer. So now let’s get started.

16:28 - Let’s start testing KNX. The Standard is right about one thing.

16:33 - The protocol is complicated. We have few resources and it’s hard to start testing KNX really.

16:39 - So at least now the specifications are free, but, and you just need an account on KNX websites.

16:45 - But you also need good nerves because the specification is 148 PDF files in 10 sections, with information spread everywhere.

16:55 - So you just don’t know where to find what you need and you can grep as a need needs.

16:59 - That’s a nightmare. (chuckles) Most likely, you only need the volume three, but it’s still 35 PDF files with information spread everywhere again.

17:09 - And for instance, if you’re looking for how to build a request, that to send the value to an address, you need at least four different PDF files.

17:17 - So we don’t want to do that. And there’s a better way to get things started.

17:23 - We could set up a test environment with free tools provided by the KNX Association.

17:29 - So we could use KNX Virtual to emulate a KNX environment that will combine with ETS, which is the official engineering tool to configure a KNX environments.

17:42 - So you just set up that environment and then you just have to play with that while listening to the traffic and you learn a lot.

17:50 - And this is all virtual, so no side effects here.

17:54 - Also Wireshark already has a KNXnet/IP dissector, which is really convenient.

18:00 - And also I have to say that the code for the dissector is way more understandable than the specifications.

18:09 - So I show you briefly how it looks like. I have a project configured in ETS, with lights and switches.

18:16 - I downloaded it to KNX Virtual. And we can see that if I click on buttons, it turns on and off lights.

18:22 - So that’s a very straight forward set up, but that’s already enough to run a few things in a safe environment, and we can also run diagnostic on ETS and see what happens on Wireshark, and so on.

18:40 - Just before we really start testing KNX, there are a few key concepts I’d like to mention because they are useful to fully understand what’s going on.

18:49 - So when an operator pushes a configuration or sends a command, a KNXnet/IP request is sent to the KNXnet IP interface.

18:59 - This frame may contain only KNXnet/IP relevant information, or it can embed raw KNX data, which is related to the KNX layer.

19:09 - So this KNX data are called cEMI for common External Messaging Interface.

19:16 - And they are independent KNX messages with their own format inside the KNXnet/IP requests.

19:23 - So this means that they have their own headers, their own types, their own bodies and so on.

19:30 - So this also means that we don’t have one protocol to test, but to, with different impacts, depending on the one we target.

19:43 - And finally, a few words about the topology.

19:45 - When you are on the IP layer, of course you use IP addresses, but when you run the KNX layer, there are two types of addresses.

19:54 - The first one is individual addresses, which are used to refer to the device.

20:00 - The other one is group addresses, which we refer more to functions.

20:04 - So it’s not a collection of devices, but more collection of actions that devices can do.

20:11 - For instance, we can imagine that the fire detector and the sprinklers subscribe to the same group address.

20:17 - And when there’s a fire, the fire detector will set the value 1 to the group address associated to it.

20:26 - And when that’s group address answer value 1, it’s just starts to sprinkler.

20:33 - I know it’s a bit hard to understand, but it comes with practice, trust me.

20:38 - And that’s all we need to know for now, and now we can really start testing.

20:44 - So there are already a few tools that we can use to do that.

20:48 - First there is, of course, ETS. KNXmap is also a great tool if you want to discover devices and interact with them.

20:58 - So let me show you quickly. You can just KNXmap to scan IP interfaces on the network.

21:03 - And you can see that we don’t need to know much about KNX to use KNXmap, which is cool.

21:10 - We can see from Wireshark, that a lot of things happened.

21:13 - First, we see that we need to send a KNX request.

21:16 - Then a tunneling request with a cEMI. And so on that, we’ll get back to it later.

21:24 - So there’s KNXmap, but there’s also the KNXnet/IP layer for Scapy, which was written by my colleague Julien Bedel.

21:35 - It’s not yet on a release, but it’s at least merged to Scapy Master, so you can already use it.

21:41 - So thanks to thanks to Julien and thanks to Scapy maintainers for that.

21:48 - Both Scapy and KNXmap are suitable for basic interaction.

21:51 - However, when I wanted to start using them for my own tests, I encountered some limitations.

21:58 - So, first KNXmap is great if you don’t know the protocol.

22:02 - But, I could not use it to craft invalid frames.

22:05 - I could not modify KNXmap code to alter requests without rewriting parts of it because they handle errors.

22:14 - Which is a good practice, but for fuzzing we don’t want that.

22:18 - For Scapy, the opposite. You can’t really use it if you don’t know the protocol in details.

22:24 - But you can definitely use it to craft invalid frames.

22:27 - However, they can become really complicated, especially when they embed cEMI frames and also IP interfaces are very strict usually, regarding the format.

22:37 - So when you fuzz, you have to fuzz specific fields, which can become really complicated and the syntax can be really tough.

22:46 - So obviously, when nothing suits my need, it’s fun to write a new tool.

22:53 - So now, I’m going to talk about BOF which is a tool we wrote when I started using and testing KNXnet/IP devices.

23:02 - BOF is a license free library that we wrote to discover, interact with, and test devices, they are the industrial network protocols.

23:09 - So I originally created KNXnet/IP, but we can add other protocols.

23:14 - For instance, we are currently adding Modbus support.

23:17 - So this is a library. So it’s most likely meant to write attack scripts, to change device’s behaviors, or to test protocol implementation on devices.

23:27 - So if you recall the attack scenario I talked about earlier, about sending valid and invalid frames to KNXnet/IP devices.

23:36 - BOF has been written to do both. No joke. (chuckles) And if you want to take a look at it, it’s available on Orange-Cyberdefense Github.

23:48 - To be honest, I wrote it for my own needs first, and I use it doing pen tests for discovery and to send commands.

23:55 - But I also use it for vulnerability research on protocol implementations on devices.

24:02 - So I use both to write dumb and not-so-dumb fuzzer.

24:07 - I can say they are smart. And I give you an example of that soon.

24:11 - And the more I go further in my research, the more features I add in both to help my testing.

24:16 - So hopefully it’s getting better and better.

24:22 - So before I show you how to use both for discovery and testing, just a quick information about BOF internals, which I think is interesting.

24:30 - The first version of BOF relied on JSON5 for protocol implementations, because it was easy to add and change things in the protocol.

24:38 - But at one point we had too many limitations.

24:42 - So, and when I first presented BOF, I was asked, why not use Scapy? Which is actually a good question.

24:50 - And I was like, “Hmm, now that you mentioned that?” So long story short, we ended up adding it to handle protocol implementations, but internally there’s a wrapper around it in BOF so that we don’t lose some of BOF capabilities that were not compatible with Scapy’s behaviors.

25:09 - However, we still let the user access the Scapy object directly within BOF if she wants.

25:14 - So if you want to know more about that, we did tell how and why we did that in the documentation.

25:20 - Now back to using BOF. As I mentioned before, BOF can be used for discovery, basic interaction and advanced testing.

25:29 - So there are three ways to use BOF. The first is the high-level one, which requires no knowledge about the protocol.

25:38 - There are just some functions in the library that can be called to perform basic operations on KNX installations.

25:46 - So for instance, this is my test setup. Here we want to turn on this light and fan, which are linked to a switching actuator.

25:55 - The actuator is linked to an IP gateway that makes you reachable from the local network and I’m on that local network, so I can communicate with it choosing KNXnet/IP.

26:07 - The actuator is subscribed group address 1/1/1 for the light and fan witching operations, both of them.

26:14 - When it’s switched off, the value is 0. And when it’s switched on, it’s 1.

26:19 - So if I write value 1 to group address 1/1/1 using the function group_write, we can see that something happens.

26:34 - Then there’s an intermediate usage, which requires some basic knowledge about the protocol.

26:40 - For instance, you could do the same thing as in the previous example, but you can use this level to have more control on the exchange and the frames you sent.

26:54 - So for instance, if you want to do the same thing, that’s to say, change a value on devices.

27:01 - This is what happens. We send a KNXnet/IP frame to initiate a tunneling connection to the KNX layer.

27:09 - We then sent a tunneling request containing a raw KNX frame, a cEMI.

27:15 - Here it’s L_data/req, which will be extracted and relayed to the KNX layer.

27:21 - The server responds with an ACK and also with a confirmation KNX frame to which we reply with an ACK because, at least my test server is upset if I don’t, and yes it’s UDP.

27:37 - So using BOF, we’ll just write a script that does exactly that.

27:41 - In here, the tunneling request is just broken down so that you can see how it looks like.

27:46 - But there’s also a direct method that can be called to initiate and send the request.

27:54 - The code actually looks like that. So, let’s try to switch everything on again.

28:05 - And success. If we use the group addresses that are attached to only one object in the KNX configuration, we can also turn on and off objects on their own.

28:21 - Oh and also something went wrong when we were setting up the demo.

28:26 - So let me introduce you what I think is the first ever KNX operated gun.

28:34 - (motor winding and pellets firing) And the final level is the one use to build the other ones, that can be used to change everything in a frame.

28:47 - See, and this is the part I use for fuzzing.

28:52 - Now, I just show you how to start writing a fuzzer with BOF.

28:56 - We won’t talk about the results because this is not another conference about how we fuzz something to find buffer overflows.

29:02 - Although, BOF can be used to do that. And KNXnet/IP interface usually have Linux-based OS with services in C or other compiler languages.

29:11 - So it’s definitely something that can happen.

29:14 - But back to our fuzzer. Here I choose to write another type of frames because fuzzing tunneling requests just writes bad configuration to test devices.

29:24 - So that’s not the best way to start I guess.

29:28 - So I want to mutate a configuration requests.

29:31 - This means that I have my base frame and I wrote a generator function that will set a random value to random field in that frame.

29:40 - Again, just fuzz the whole frame because if the a frame is not valid, it will be rejected by the IP interface before it’s even processed.

29:48 - And here we don’t want that because we are trying to cause errors while processing our frames.

29:55 - So I have to first mutate specific fields, not all of them because some of them must remain valid for the request to be accepted.

30:06 - The request, the rest of the code handle the exchange with a similar process as for the tunneling request with the ACK and all.

30:14 - And it will send my mutated KNXnet/IP frames.

30:18 - Some of them may trigger some unexpected behaviors, which we would want to test more afterwards to investigate.

30:26 - So here we want to first know which field triggered a handled error to exclude them later from the final results.

30:35 - And we also want to know which fields triggered timeout, that’s to say frames that did not get an answer.

30:41 - That’s, they are the most interesting ones for us.

30:45 - So let’s run it on a test device. And you can see on Wireshark, that’s a lot of packets are being sent and received.

30:53 - At some point, we already have some results.

30:55 - All of them are timeouts. And for each one of them, I have the name of the field and the value that were mutated, as well as a view of the complete frame.

31:09 - So the result we have show that frames with some values in some fields did not get a response from the test device.

31:17 - So here we have six results. So this means that we have six potentially problematic fields that we will want to investigate.

31:27 - But at that point, there’s one question. How do we know if the device rejected the frame or crashed by processing it? And the answer is, using all of this we don’t.

31:37 - We could add an additional… We could send an additional frame to check if the device just stopped responding.

31:47 - But even when the device keeps on responding, that does not mean there was no crash.

31:52 - So the next things to do is to add a debugger on the device and keep testing.

32:00 - But what do we expect to find then? So, first of all, we expect to have crashes.

32:05 - Now that just the situations where, what we sent is not handled correctly and that we can investigate to eventually exploit them.

32:13 - But depending on when, on where the crash occurs, it may have different meaning.

32:19 - If it’s anywhere in the KNXnet/IP frame, we can suspect that’s a service or any other software interpreting the frame crashed and that we can use it to possibly compromise the IP interface itself.

32:33 - But, if there’s an error in the KNX frame, it can also be that…

32:41 - It can also be on the KNX layer, on the IP interface KNX layer, that a crash occurred leading to the interface compromise.

32:52 - But it may also be on devices themself. However, it has never happen to me so far.

32:58 - So I might even be lying to you right now. (chuckles) But investigating on this is exciting anyway.

33:06 - It’s time to wrap things up. So, we have seen that there’s lot of things to do on BMS and KNX security.

33:15 - What we have so far is environments that control important stuff, but where security is a minor concern.

33:21 - So for now we don’t need to go really deep into hacking techniques, as there is no protection to bypass or a few of them.

33:29 - But even when there is, can we consider that building management system that use KNX are secure? So apart from just abusing such systems, we can go further and there are a lot of research subject left to work on here.

33:46 - For instance, to find out what’s really inside widely-used implementations and what we can do with them.

33:52 - Or what’s inside KNX security extensions? Or even how to secure BMS efficiently and how to make sure they are actually secure? Until then, there are a few things that we can already do to make things better.

34:08 - So first, a quick message to vendors and users.

34:11 - Stop assuming it’s the other’s problem. You both have your part to do in it.

34:17 - So vendors, please at least make sure that secure settings are default settings.

34:21 - And, users check all settings and segregate your network, or at least don’t expose your devices on internet.

34:32 - And for us, we have a brand new attacks surface, so let’s test it.

34:37 - Maybe someone will learn something. Just be careful when you do that, and testing controlled environments.

34:44 - As for Defenders, lucky you, you get a brand new defense surface.

34:49 - So that’s all for me. I hope you enjoy the presentation.

34:52 - Thank you for listening. .