Sneak into buildings with KNXnet/IP
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Vacherot, Claire
Building Management Systems control a myriad of devices such as lighting, shutters and HVAC. KNX (and by extension KNXnet/IP) is a common protocol used to interact with these BMS. However, the public's understanding and awareness is lacking, and effective tooling is scarce all while the BMS device market keeps on growing. The ability to craft arbitrary KNXnet/IP frames to interact with these often-insecure BMS provides an excellent opportunity in uncovering vulnerabilities in both the implementation of KNX as well as the protocol itself. From unpacking KNX at a lower level, to using a Python-based protocol crafting framework we developed to interact with KNXnet/IP implementations, in this talk we’ll go on a journey of discovering how BMS that implement KNXnet/IP work as well as how to interact with and fuzz them. After this talk you could also claim that “the pool on the roof has a leak”!
 Hi, I'm Clave Acheaut and today I'm going to talk about sneaking into buildings using the Building Management System protocol KNXNET IP. 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 system security. Also in my job I like penetration tests on unusual environments and by unusual environments I mean for instance factories, transportation systems, amusement parks and so on. During these assessments we often have new environments with non-devices and protocols and we usually don't know where to start. This is what happened for me with Building Management System and KNXNET IP. Just before we start, a little disclaimer. Building industrial systems and Building Management Systems can be dangerous. They control physical process so they may have an impact on people's safety, causing accidents or disabling outlets. So please be careful. So during our assessments we usually test on mock environments or at least environment we control to avoid a non-deficient effect. Now that said, let's talk about Building Management Systems. You may have already heard of them as this is really not the first talk about Building Management Systems but I don't feel it's yet the time to stop introducing them first 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. 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. So here is an interesting example from the movie Hackers which has a BMS hacking scene. The main character hacks into a school BMS interface and he schedules a sprinkler system to run at a certain time basically for revenge. And this is what happens. So I don't know how it was back in 1995 but now apart from this weird 3D interface this is quite a workable scenario. We can definitely do this provided of course that the sprinkler system is linked to the Building Management System. So now let's take a closer look at this technically. In BMS the main part is the field part where the actual components are. We often find three types of components sensors, actuators and controllers. If we take the example from Hackers sensor could be a fire detector, the actuators could be the sprinklers and so on. So they communicate, these devices communicate with each other using field bus protocols usually on twisted pairs or radio frequencies. So this part can work standalone and in fact before it was the only part. But then the field part got connected to the IP network first because there was that train to connect everything but also most probably so that operators could reach and control them more easily. So basically there are additional devices that will call IP interfaces or gateways or server or whatever and this IP interfaces makes a translation between the IP world and the field world. So to simplify the operator just needs to be on the same network as this IP interface to configure and control the field part. In a way we expose components that used to be only reachable physically to anyone on the network or even the internet. And that's interesting for us and we may definitely want to take a look at it from a security point of view. So in industrial and building management system many software and protocol were created before we started talking about cybersecurity or they were created without considering that they may be exposed someday and they are usually meant to last for a long time. So some of them do cover safety measures which are prevention against involuntary failures but they don't cover security issues. They don't cover provoked error for instance they don't prevent from forging or replaying packets. And it's also quite common to find configuration flows on them such as default credentials or only one user which is used to run everything on a device and its route and so on. So see there's a lot of things to think about when it comes to industrial systems and building management system security. But there's more. Let's take an even closer look at the interface between the LAN and the field. So it's usually a device in an electric cabinet so it means that it's hardly reachable to physically but of course reachable from the LAN. And if you scan one of them you may notice that several services are running like first the usual stuff for administration most likely at least HTTP maybe SSH or any other. But you may also notice another port which is the building management system protocol service. What are they? As I said before field components communicate with each other using a field protocol. 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. The most common of such protocol being backnet and KNX. So what happens is that the operator will send a backnet IP or KNX.NET IP request to the interface which will interpret it and relay it to the field bus via a field backnet or field KANYs request. And today I want to focus on that part for several reasons. First because we already know the other services and you can at least expect some basic protections from the vendor which is not necessary true for the BMS protocol. And more importantly this protocol is a direct way to talk to devices. It's the best way to gather information and to run commands on the BMS. And finally they have the same flaws as many other industrial components. To not consider cybersecurity and a lot of implementation were written a long time ago and never updated since then. What do we have so far? So we have field devices and protocol that should not be exposed and we know that they are actually are and that we can reach them. Yeah, IP interface devices. We also know that there's this IP version of a field protocol no one has heard of before to do that. And finally we know that we can talk to devices directly using that IP version of a BMS protocol through that IP gateway. Yeah. What can we do with that? So in the next few slides I talk about two general attack scenarios on building management systems. 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. So let's talk about the first one which is the most obvious one. Here we want to send legitimate commands to change the BMS behaviors. 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. We could disable the fire detection which is not fun at all. In a trickier way we could also change thresholds. 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. Or you can just do whatever you want as long as it's allowed by the system and this is very important. And why can we do that? Because as I mentioned before these protocols do not cope with cybersecurity. There is no protection against replay or whatever and often no authentication or at least no authentication by default. So here is a small example. I did a few months ago. This is an HVAC system in a test environment which can be controlled with backnet. So I have no idea what's inside the backnet protocol but just by listening to the traffic and extracting the right frame I was able to make it unavailable. So this is a script I used. It just replays the command to turn the system off every one second and that's enough. And by doing this in a real environment this could have a really bad effect. For instance in a data center without the HVAC the servers would just cover it to death. Also in buildings made entirely of glass what happens if you turn the HVAC off. Also imagine in Vegas. And for the renewing part if it's turned off all the bad things would stay in the air which is really not suitable especially during a pandemic. So the other scenario is the unintended use of devices using these protocols. In scenario one we run legitimate commands and can only perform expected operations. Here we want to send malicious stuff and wait for something unexpected, most likely something you could exploit. And what makes it happen is of course the combination of securities issues and devices that we talked about previously. But it's even easier knowing that a lot of BMS IP interfaces run Linux-based operating systems. So here is an example of what you can do. For instance you can compromise an IP interface exposed on the internet. On 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. An alternative to this scenario could be to use the BMS for network pivoting. For instance in industrial systems IT and OT networks should be segregated. They are not always segregated but at least they should be. So now imagine having a BMS that's connected to both. I'm not saying this is a common setting but it can definitely happen. 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. So this is it for the scenario. Of course I didn't invent any of this. And if you want to know more about BMS in general there are already a few conferences and papers. Also there are already a few talks about BMS exploitation and among them I recommend the one by Jesus Molina at DEF CON22 which talks about abusing a KANIC system in a hotel and which is really good. Also there is already some work about advanced testing on backnet systems and research about attack detection and remediation on backnet. But as you can see this is really all about backnet so where is KANICS? Actually the scenario that we just went through can be applied to any building management system protocol that has an IP layer. So there is of course backnet but there is also KANICS and we don't know much about it from an offensive point of view. 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. So let's talk about KANICS. So as you already know KANICS is a BMS protocol with an IP layer. It's mostly used in Europe and Asia whereas backnet is mostly used in the US. And of course like the other you can find it in all types of homes and buildings. For instance in my office the lights and shutters are operated by KANICS. So I'd just like to say a few words about its history because I think it's interesting to understand some choices they made about protocol. So basically it's a merge of free European field protocol standards that were used since the 80s and they were merged into KANICS in 1999. Then eight years later KANICS net IP was created and then the KANICS installation became reachable from the network. And then again six years later security came. The first KANICS net IP security extension came out. And finally it's important to note that this standard is only free since 2016 so that's only been five years which is not that long. But even with the specifications available they are still pretty hard to use and I'll get back to it later. There are a few external documentation and also a few research and work about KANICS security. But obviously that does not mean there is nothing to say about it. And actually there's a lot to say. But the standard got a bit covered. They say for KANICS 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 KANICS. Some vendors implement authentication not all of them but this is usually an option which is usually disabled by default. Also there are security protection. I mentioned extensions which are KANICS IP secure and KANICS data secure. But once again there are extensions, there are add-ons and you usually have to pay more or to get better devices to have them. So yeah security is optional. And about the devices exposed on showdown. 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. But then the standard got that covered too. They say it is quite unlikely that legitimate users of a network would have the means to intercept, decipher and then tamper with a KANICS net IP without excessive study of the KANICS specifications. So this is what we call security by obscurity. And that's bad. So KANICS for my beer. So now let's get started. Let's start testing KANICS. The standard is right about one thing. The protocol is complicated. We have few resources and it's hard to start testing KANICS really. So at least now the specifications are free. And you just need an account on KANICS websites. But you also need good nerves because the specification is 148 PDF files in 10 sections with information spread everywhere. So you just don't know where to find what you need and you can grab as you need that's a nightmare. And most likely you only need the volume free. But it's still 33 PDF files with information spread everywhere again. And for instance if you're looking for how to build a request to send a value to an address you need at least four different PDF files. So we don't want to do that. And there's a better way to get things started. We could set up a test environment with three tools provided by the KANICS association. We could use KANICS virtual to emulate a KANICS environment that will combine with ETS which is the official engineering tool to configure KANICS environments. So you just set up that environment and then you just have to play with that while listening to the traffic and you'll learn a lot. And this is all virtual so no side effects here. And also Weirshark already has again a NetIP data sector which is really convenient. And also I have to say that the code for the data sector is way more understandable than the specifications. So I show you briefly how it looks like. I have a project configured in ETS with light and switches. I don't know that it took any virtual and we can see that if I click on buttons it turns on and off lights. So that's a very straightforward setup but that's already enough to learn a few things in a safe environment. And we can also run diagnostic on ETS and see what happens on Weirshark and so on. So just before we really start testing KANICS there are a few key concepts I like to mention because they are useful to fully understand what's going on. So when an operator pushes a configuration or sends a command a KANICS NetIP request is sent to the KANICS NetIP interface. This frame may contain only KANICS NetIP relevant information or it can embed raw KANICS data which is related to the KANICS layer. So this KANICS data are called KEMI for Common External Messaging Interface and there are independent KANICS messages with their own formats inside the KANICS NetIP request. So this means that they have their own headers, their own types, their own bodies and so on. So this also means that we don't have one protocol to test but two with different impacts depending on the one we target. Finally a few words about the topology. When you run the IP layer of course you use IP addresses but when you run the KANICS layer there are two types of addresses. The first one is individual addresses which are used to refer to the device and the other one is group addresses which refer more to functions. So it's not a collection of devices but more a collection of actions that devices can do. For instance we can imagine that the fire detector and the sprinkler subscribe to the same group address. And when there's a fire, the fire detector will set the value 1 to the group address associated to it and when that group address has the value 1 it just starts to sprinkle. So I know it's a bit hard to understand but it comes with practice trust me. And that's all we need to know for now and now we can really start testing. There are already a few tools that we can use to do that. First of course ETS. KANICS map is also a great tool if you want to discover devices and interact with them. So let me show you quickly. You can just use KANICS map to scan IP interfaces on the network. And you can see that we don't need to know much about KANICS to use KANICS map which is cool. We can see from where a lot of things happened. First we see that we need to send a KANICS request, an autonomic request with a KME and so on but we'll get back to it later. So we're at KANICS map but there's also the KANICS net IP layer for Skappi which was written by my colleague Julien Bedel. It's not yet on the release but it's at least merged to Skappi master so you can already use it. So thanks to Julien and thanks to Skappi maintenance for that. Both Skappi and KANICS map are suitable for basic interaction. However, when I wanted to start using them for my own tests I encountered some limitations. So first KANICS map is great if you don't know the protocol but I could not use it to craft invalid frames. I could not modify KANICS map code to autonomic requests without rewriting parts of it because they handle errors which is a good practice but for first thing we don't want that. For Skappi the opposite. You can't really use it if you don't know the protocol in details but you can definitely use it to craft invalid frames. However, they can become really complicated especially when they embeds KME frames and also IP interfaces are very strict usually regarding the format so when you fuzz you have to fuzz specific fields which can become really complicated and the syntax can be really tough. So obviously when nothing suits my need it's time to write a new tool. Now I'm going to talk about both which is a tool we wrote when I started using and testing KANICS net IP devices. Both is a Python 3 library that we wrote to discover, interact with and test devices that are the industrial network protocols. So I first created it for KANICS net IP but we can add other protocols. For instance we are currently adding mod-push support. So this is a library so it's most likely meant to write attack scripts to change devices behaviors or to test protocol implementation on devices. So if you recall the attack scenario I talked about earlier about sending valid frames to KANICS net IP devices, both has been written to do both. No joke. And if you want to take a look at it, it's available on the Born-Chibert-Defense GitHub. To be honest I wrote it for my own needs first and I use it to bring pen tests for a discovery and to send comments. But I also use it for vulnerability research on protocol implementations on devices. So I use both to write dump and not so dump further. I can save it as smart. And I'll give you an example of that soon. And the more I go further in my research, the more features I add in both to admit testing. So hopefully it's getting better and better. So before I show you how to use both for discovery and testing, just a quick information about both internals which I think is interesting. The first version of both relied on JSON files for protocol implementations because it was easy to add and change things in the protocol. But at one point we had too many limitations. So when I first presented both I was asked why not use CAPI? Which is actually a good question. And I was like, hmm, not that you mentioned that. So long story short, we ended up adding it to end of protocol implementations but internally there's a wrapper around it in both so that we don't lose some of both capabilities that were not compatible with CAPI's behaviors. However, we still let the user access the CAPI object directly within both if she wants. So if you want to know more about that, we detailed how and why we did that in the documentation. Now back to using both. As I mentioned before, both can be used for discovery, basic interaction and advanced testing. So there are three ways to use both. The first is the higher level one which requires no knowledge about the protocol. There are just some functions in the library that can be called to perform basic operations on KNX installations. 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. The actuator is linked to an IP gateway that makes it reachable from the local network and I'm on that local network. So I can communicate with it using KNX and IP. The actuator is subscribed to Group Address 111 for the light and fan switching operations, both of them. When it's switched off, the value is zero and when it's switched on, it's one. So if I write value one to Group Address 111 using the function group write, we can see that something happens. Then there's an intermediate usage which requires some basic knowledge about the protocol. 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. So for instance, if you want to do the same thing, as to say change a value on devices, this is what happens. We send a KNX net IP frame to initiate a tuneling connection to the KNX layer. We then send a tuneling request containing a raw KNX frame, a KAMI. Here it's L data rack, which will be extracted and relayed to the KNX layer. The server responds with an act and also with a confirmation KNX frame to which we reply with an act because at least my test server is upset if I don't. And yes, it's UDP. So using both, we'll just write a script that does exactly that. Here the tuneling request is just broken down so that you can see how it looks like, but there's also a direct method that can be called to initiate and send a request. The code actually looks like that. So let's try to switch everything on again. 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. Oh, and also something went wrong when we were setting up the demo. So let me introduce you what I think is the first ever KNX Operated Gun. And the final level is the one used to build the other ones that can be used to change everything in a frame. See, and this is the part I use for fuzzing. Now I just show you how to start writing a fuzzer with both. We won't talk about the results because this is not another conference about how we fuzz something to find buffer overflows, although both can be used to do that. And KNX IP interface usually have Linux-based OS with services in C or overcompiled languages, so it's definitely something that can happen. But back to our fuzzer, here I choose to write another type of frames because fuzzing tuneling request just writes bad configuration to 10 devices, so that's not the best way to start, I guess. So I want to mutate a configuration request. This means that I am my base frame and I wrote a generator function that will set a random value to random fill in the same. I can just fuzz the whole frame because if the frame is not valid, it will be rejected by the IP interface before it's even processed. And here we don't want that because we are trying to cause errors while processing our frames. 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. The rest of the code handles the exchange with a similar process as for the tuneling request with the hack and all. And it will send my mutated KNX IP frames. Some of them may trigger some unexpected behaviors which we would want to test more afterwards to investigate. So here we want to first know which field triggered a handled error to exclude them later from the final results. And we also want to know which fields triggered timeouts. That's to say frames that did not get an answer. That's the most interesting one for us. So let's run it on a test device. You can see on Wireshark that a lot of packets are being sent and received. At some point we already have some results. 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. So the result we have shows that frames with some values in some fields did not get a response from the test device. So here we have six results. So this means that we have six potentially problematic fields that we will want to investigate. But at that point there's one question. How do we know if the device rejected the frame or crashed while processing it? And the answer is using all of these we don't. We could send an additional frame to check if the device just stopped responding. But even when the device keeps on responding that does not mean there was no crash. So the next thing to do is to add a debugger on the device and keep testing. But what do we expect to find then? So first of all we expect to have crashes. That's to say situations where what we sent is not handled correctly and that we can investigate to eventually exploit them. But depending on where the crash occurs it may have different meaning. If it's anywhere in the KNX-NetIP frame we can suspect that the service or any other software interpreting the frame crashed and that we can use it to possibly compromise the IP interface itself. But if there's an error in the KNX frame it can also be that it can also be on the KNX layer on the IP interface KNX layer but a crashed occur leading to the interface compromise. But it may also be on devices themselves. However it does never happen to me so far so I might even be lying to you right now. But investigating on this is exciting anyway. So it's time to wrap things up. We have seen that there's a lot of things to do on BMS and KNX security. What we have so far is environments that control important stuff but where security is a minor concern. 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. But even when there is can we consider that building management systems that use KNX are secure? So apart from just abusing such systems we can go further and there are a lot of research subjects left to work on here. For instance to find out what's really inside widely used implementations and what we can do with them 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. So first a quick message to vendors and users. Stop assuming it's the others problem. You both have your part to do in it. So vendors please at least make sure that secure settings are default settings and users check both settings and segregate your network or at least don't expose your devices on internet. And for us we have a brand new attack surface so let's test it. Maybe someone will learn something. Just be careful when you do that and test in controlled environments. As for defenders lucky you you get a brand new defense surface. So that's all for me. I hope you enjoyed the presentation. Thank you for listening.
 Hi, I'm Clave Acheaut and today I'm going to talk about sneaking into buildings using  the Building Management System protocol KNXNET IP.  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 system security.  Also in my job I like penetration tests on unusual environments and by unusual environments  I mean for instance factories, transportation systems, amusement parks and so on.  During these assessments we often have new environments with non-devices and protocols  and we usually don't know where to start.  This is what happened for me with Building Management System and KNXNET IP.  Just before we start, a little disclaimer.  Building industrial systems and Building Management Systems can be dangerous.  They control physical process so they may have an impact on people's safety, causing  accidents or disabling outlets.  So please be careful.  So during our assessments we usually test on mock environments or at least environment  we control to avoid a non-deficient effect.  Now that said, let's talk about Building Management Systems.  You may have already heard of them as this is really not the first talk about Building  Management Systems but I don't feel it's yet the time to stop introducing them first  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.  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.  So here is an interesting example from the movie Hackers which has a BMS hacking scene.  The main character hacks into a school BMS interface and he schedules a sprinkler system  to run at a certain time basically for revenge.  And this is what happens.  So I don't know how it was back in 1995 but now apart from this weird 3D interface this  is quite a workable scenario.  We can definitely do this provided of course that the sprinkler system is linked to the  Building Management System.  So now let's take a closer look at this technically.  In BMS the main part is the field part where the actual components are.  We often find three types of components sensors, actuators and controllers.  If we take the example from Hackers sensor could be a fire detector, the actuators could  be the sprinklers and so on.  So they communicate, these devices communicate with each other using field bus protocols  usually on twisted pairs or radio frequencies.  So this part can work standalone and in fact before it was the only part.  But then the field part got connected to the IP network first because there was that train  to connect everything but also most probably so that operators could reach and control  them more easily.  So basically there are additional devices that will call IP interfaces or gateways  or server or whatever and this IP interfaces makes a translation between the IP world and  the field world.  So to simplify the operator just needs to be on the same network as this IP interface  to configure and control the field part.  In a way we expose components that used to be only reachable physically to anyone on the  network or even the internet.  And that's interesting for us and we may definitely want to take a look at it from a security  point of view.  So in industrial and building management system many software and protocol were created before  we started talking about cybersecurity or they were created without considering that  they may be exposed someday and they are usually meant to last for a long time.  So some of them do cover safety measures which are prevention against involuntary failures  but they don't cover security issues.  They don't cover provoked error for instance they don't prevent from forging or replaying  packets.  And it's also quite common to find configuration flows on them such as default credentials  or only one user which is used to run everything on a device and its route and so on.  So see there's a lot of things to think about when it comes to industrial systems and building  management system security.  But there's more.  Let's take an even closer look at the interface between the LAN and the field.  So it's usually a device in an electric cabinet so it means that it's hardly reachable to  physically but of course reachable from the LAN.  And if you scan one of them you may notice that several services are running like first  the usual stuff for administration most likely at least HTTP maybe SSH or any other.  But you may also notice another port which is the building management system protocol  service.  What are they?  As I said before field components communicate with each other using a field protocol.  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.  The most common of such protocol being backnet and KNX.  So what happens is that the operator will send a backnet IP or KNX.NET IP request to  the interface which will interpret it and relay it to the field bus via a field backnet  or field KANYs request.  And today I want to focus on that part for several reasons.  First because we already know the other services and you can at least expect some basic protections  from the vendor which is not necessary true for the BMS protocol.  And more importantly this protocol is a direct way to talk to devices.  It's the best way to gather information and to run commands on the BMS.  And finally they have the same flaws as many other industrial components.  To not consider cybersecurity and a lot of implementation were written a long time ago  and never updated since then.  What do we have so far?  So we have field devices and protocol that should not be exposed and we know that they  are actually are and that we can reach them.  Yeah, IP interface devices.  We also know that there's this IP version of a field protocol no one has heard of before  to do that.  And finally we know that we can talk to devices directly using that IP version of a BMS protocol  through that IP gateway.  Yeah.  What can we do with that?  So in the next few slides I talk about two general attack scenarios on building management  systems.  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.  So let's talk about the first one which is the most obvious one.  Here we want to send legitimate commands to change the BMS behaviors.  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.  We could disable the fire detection which is not fun at all.  In a trickier way we could also change thresholds.  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.  Or you can just do whatever you want as long as it's allowed by the system and this is  very important.  And why can we do that?  Because as I mentioned before these protocols do not cope with cybersecurity.  There is no protection against replay or whatever and often no authentication or at least no  authentication by default.  So here is a small example.  I did a few months ago.  This is an HVAC system in a test environment which can be controlled with backnet.  So I have no idea what's inside the backnet protocol but just by listening to the traffic  and extracting the right frame I was able to make it unavailable.  So this is a script I used.  It just replays the command to turn the system off every one second and that's enough.  And by doing this in a real environment this could have a really bad effect.  For instance in a data center without the HVAC the servers would just cover it to death.  Also in buildings made entirely of glass what happens if you turn the HVAC off.  Also imagine in Vegas.  And for the renewing part if it's turned off all the bad things would stay in the air  which is really not suitable especially during a pandemic.  So the other scenario is the unintended use of devices using these protocols.  In scenario one we run legitimate commands and can only perform expected operations.  Here we want to send malicious stuff and wait for something unexpected, most likely something  you could exploit.  And what makes it happen is of course the combination of securities issues and devices  that we talked about previously.  But it's even easier knowing that a lot of BMS IP interfaces run Linux-based operating  systems.  So here is an example of what you can do.  For instance you can compromise an IP interface exposed on the internet.  On 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.  An alternative to this scenario could be to use the BMS for network pivoting.  For instance in industrial systems IT and OT networks should be segregated.  They are not always segregated but at least they should be.  So now imagine having a BMS that's connected to both.  I'm not saying this is a common setting but it can definitely happen.  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.  So this is it for the scenario.  Of course I didn't invent any of this.  And if you want to know more about BMS in general there are already a few conferences  and papers.  Also there are already a few talks about BMS exploitation and among them I recommend  the one by Jesus Molina at DEF CON22 which talks about abusing a KANIC system in a hotel  and which is really good.  Also there is already some work about advanced testing on backnet systems and research about  attack detection and remediation on backnet.  But as you can see this is really all about backnet so where is KANICS?  Actually the scenario that we just went through can be applied to any building management  system protocol that has an IP layer.  So there is of course backnet but there is also KANICS and we don't know much about  it from an offensive point of view.  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.  So let's talk about KANICS.  So as you already know KANICS is a BMS protocol with an IP layer.  It's mostly used in Europe and Asia whereas backnet is mostly used in the US.  And of course like the other you can find it in all types of homes and buildings.  For instance in my office the lights and shutters are operated by KANICS.  So I'd just like to say a few words about its history because I think it's interesting  to understand some choices they made about protocol.  So basically it's a merge of free European field protocol standards that were used since  the 80s and they were merged into KANICS in 1999.  Then eight years later KANICS net IP was created and then the KANICS installation became reachable  from the network.  And then again six years later security came.  The first KANICS net IP security extension came out.  And finally it's important to note that this standard is only free since 2016 so that's  only been five years which is not that long.  But even with the specifications available they are still pretty hard to use and I'll  get back to it later.  There are a few external documentation and also a few research and work about KANICS  security.  But obviously that does not mean there is nothing to say about it.  And actually there's a lot to say.  But the standard got a bit covered.  They say for KANICS 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 KANICS.  Some vendors implement authentication not all of them but this is usually an option  which is usually disabled by default.  Also there are security protection.  I mentioned extensions which are KANICS IP secure and KANICS data secure.  But once again there are extensions, there are add-ons and you usually have to pay more  or to get better devices to have them.  So yeah security is optional.  And about the devices exposed on showdown.  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.  But then the standard got that covered too.  They say it is quite unlikely that legitimate users of a network would have the means to  intercept, decipher and then tamper with a KANICS net IP without excessive study of  the KANICS specifications.  So this is what we call security by obscurity.  And that's bad.  So KANICS for my beer.  So now let's get started.  Let's start testing KANICS.  The standard is right about one thing.  The protocol is complicated.  We have few resources and it's hard to start testing KANICS really.  So at least now the specifications are free.  And you just need an account on KANICS websites.  But you also need good nerves because the specification is 148 PDF files in 10 sections  with information spread everywhere.  So you just don't know where to find what you need and you can grab as you need that's  a nightmare.  And most likely you only need the volume free.  But it's still 33 PDF files with information spread everywhere again.  And for instance if you're looking for how to build a request to send a value to an address  you need at least four different PDF files.  So we don't want to do that.  And there's a better way to get things started.  We could set up a test environment with three tools provided by the KANICS association.  We could use KANICS virtual to emulate a KANICS environment that will combine with ETS which  is the official engineering tool to configure KANICS environments.  So you just set up that environment and then you just have to play with that while listening  to the traffic and you'll learn a lot.  And this is all virtual so no side effects here.  And also Weirshark already has again a NetIP data sector which is really convenient.  And also I have to say that the code for the data sector is way more understandable than  the specifications.  So I show you briefly how it looks like.  I have a project configured in ETS with light and switches.  I don't know that it took any virtual and we can see that if I click on buttons it turns  on and off lights.  So that's a very straightforward setup but that's already enough to learn a few things  in a safe environment.  And we can also run diagnostic on ETS and see what happens on Weirshark and so on.  So just before we really start testing KANICS there are a few key concepts I like to mention  because they are useful to fully understand what's going on.  So when an operator pushes a configuration or sends a command a KANICS NetIP request is  sent to the KANICS NetIP interface.  This frame may contain only KANICS NetIP relevant information or it can embed raw KANICS data  which is related to the KANICS layer.  So this KANICS data are called KEMI for Common External Messaging Interface and there are  independent KANICS messages with their own formats inside the KANICS NetIP request.  So this means that they have their own headers, their own types, their own bodies and so on.  So this also means that we don't have one protocol to test but two with different impacts  depending on the one we target.  Finally a few words about the topology.  When you run the IP layer of course you use IP addresses but when you run the KANICS layer  there are two types of addresses.  The first one is individual addresses which are used to refer to the device and the other  one is group addresses which refer more to functions.  So it's not a collection of devices but more a collection of actions that devices can do.  For instance we can imagine that the fire detector and the sprinkler subscribe to the  same group address.  And when there's a fire, the fire detector will set the value 1 to the group address  associated to it and when that group address has the value 1 it just starts to sprinkle.  So I know it's a bit hard to understand but it comes with practice trust me.  And that's all we need to know for now and now we can really start testing.  There are already a few tools that we can use to do that.  First of course ETS.  KANICS map is also a great tool if you want to discover devices and interact with them.  So let me show you quickly.  You can just use KANICS map to scan IP interfaces on the network.  And you can see that we don't need to know much about KANICS to use KANICS map which  is cool.  We can see from where a lot of things happened.  First we see that we need to send a KANICS request, an autonomic request with a KME and  so on but we'll get back to it later.  So we're at KANICS map but there's also the KANICS net IP layer for Skappi which was  written by my colleague Julien Bedel.  It's not yet on the release but it's at least merged to Skappi master so you can already  use it.  So thanks to Julien and thanks to Skappi maintenance for that.  Both Skappi and KANICS map are suitable for basic interaction.  However, when I wanted to start using them for my own tests I encountered some limitations.  So first KANICS map is great if you don't know the protocol but I could not use it to  craft invalid frames.  I could not modify KANICS map code to autonomic requests without rewriting parts of it because  they handle errors which is a good practice but for first thing we don't want that.  For Skappi the opposite.  You can't really use it if you don't know the protocol in details but you can definitely  use it to craft invalid frames.  However, they can become really complicated especially when they embeds KME frames and  also IP interfaces are very strict usually regarding the format so when you fuzz you  have to fuzz specific fields which can become really complicated and the syntax can be really  tough.  So obviously when nothing suits my need it's time to write a new tool.  Now I'm going to talk about both which is a tool we wrote when I started using and testing  KANICS net IP devices.  Both is a Python 3 library that we wrote to discover, interact with and test devices that  are the industrial network protocols.  So I first created it for KANICS net IP but we can add other protocols.  For instance we are currently adding mod-push support.  So this is a library so it's most likely meant to write attack scripts to change devices  behaviors or to test protocol implementation on devices.  So if you recall the attack scenario I talked about earlier about sending valid frames to  KANICS net IP devices, both has been written to do both.  No joke.  And if you want to take a look at it, it's available on the Born-Chibert-Defense GitHub.  To be honest I wrote it for my own needs first and I use it to bring pen tests for a discovery  and to send comments.  But I also use it for vulnerability research on protocol implementations on devices.  So I use both to write dump and not so dump further.  I can save it as smart.  And I'll give you an example of that soon.  And the more I go further in my research, the more features I add in both to admit testing.  So hopefully it's getting better and better.  So before I show you how to use both for discovery and testing, just a quick information about  both internals which I think is interesting.  The first version of both relied on JSON files for protocol implementations because it was  easy to add and change things in the protocol.  But at one point we had too many limitations.  So when I first presented both I was asked why not use CAPI?  Which is actually a good question.  And I was like, hmm, not that you mentioned that.  So long story short, we ended up adding it to end of protocol implementations but internally  there's a wrapper around it in both so that we don't lose some of both capabilities that  were not compatible with CAPI's behaviors.  However, we still let the user access the CAPI object directly within both if she wants.  So if you want to know more about that, we detailed how and why we did that in the documentation.  Now back to using both.  As I mentioned before, both can be used for discovery, basic interaction and advanced  testing.  So there are three ways to use both.  The first is the higher level one which requires no knowledge about the protocol.  There are just some functions in the library that can be called to perform basic operations  on KNX installations.  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.  The actuator is linked to an IP gateway that makes it reachable from the local network  and I'm on that local network.  So I can communicate with it using KNX and IP.  The actuator is subscribed to Group Address 111 for the light and fan switching operations,  both of them.  When it's switched off, the value is zero and when it's switched on, it's one.  So if I write value one to Group Address 111 using the function group write, we can see  that something happens.  Then there's an intermediate usage which requires some basic knowledge about the protocol.  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.  So for instance, if you want to do the same thing, as to say change a value on devices,  this is what happens.  We send a KNX net IP frame to initiate a tuneling connection to the KNX layer.  We then send a tuneling request containing a raw KNX frame, a KAMI.  Here it's L data rack, which will be extracted and relayed to the KNX layer.  The server responds with an act and also with a confirmation KNX frame to which we reply  with an act because at least my test server is upset if I don't.  And yes, it's UDP.  So using both, we'll just write a script that does exactly that.  Here the tuneling request is just broken down so that you can see how it looks like, but  there's also a direct method that can be called to initiate and send a request.  The code actually looks like that.  So let's try to switch everything on again.  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.  Oh, and also something went wrong when we were setting up the demo.  So let me introduce you what I think is the first ever KNX Operated Gun.  And the final level is the one used to build the other ones that can be used to change everything  in a frame.  See, and this is the part I use for fuzzing.  Now I just show you how to start writing a fuzzer with both.  We won't talk about the results because this is not another conference about how we fuzz  something to find buffer overflows, although both can be used to do that.  And KNX IP interface usually have Linux-based OS with services in C or overcompiled languages,  so it's definitely something that can happen.  But back to our fuzzer, here I choose to write another type of frames because fuzzing tuneling  request just writes bad configuration to 10 devices, so that's not the best way to start,  I guess.  So I want to mutate a configuration request.  This means that I am my base frame and I wrote a generator function that will set a random  value to random fill in the same.  I can just fuzz the whole frame because if the frame is not valid, it will be rejected  by the IP interface before it's even processed.  And here we don't want that because we are trying to cause errors while processing our  frames.  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.  The rest of the code handles the exchange with a similar process as for the tuneling  request with the hack and all.  And it will send my mutated KNX IP frames.  Some of them may trigger some unexpected behaviors which we would want to test more afterwards  to investigate.  So here we want to first know which field triggered a handled error to exclude them  later from the final results.  And we also want to know which fields triggered timeouts.  That's to say frames that did not get an answer.  That's the most interesting one for us.  So let's run it on a test device.  You can see on Wireshark that a lot of packets are being sent and received.  At some point we already have some results.  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.  So the result we have shows that frames with some values in some fields did not get a response  from the test device.  So here we have six results.  So this means that we have six potentially problematic fields that we will want to investigate.  But at that point there's one question.  How do we know if the device rejected the frame or crashed while processing it?  And the answer is using all of these we don't.  We could send an additional frame to check if the device just stopped responding.  But even when the device keeps on responding that does not mean there was no crash.  So the next thing to do is to add a debugger on the device and keep testing.  But what do we expect to find then?  So first of all we expect to have crashes.  That's to say situations where what we sent is not handled correctly and that we can  investigate to eventually exploit them.  But depending on where the crash occurs it may have different meaning.  If it's anywhere in the KNX-NetIP frame we can suspect that the service or any other  software interpreting the frame crashed and that we can use it to possibly compromise  the IP interface itself.  But if there's an error in the KNX frame it can also be that it can also be on the  KNX layer on the IP interface KNX layer but a crashed occur leading to the interface  compromise.  But it may also be on devices themselves.  However it does never happen to me so far so I might even be lying to you right now.  But investigating on this is exciting anyway.  So it's time to wrap things up.  We have seen that there's a lot of things to do on BMS and KNX security.  What we have so far is environments that control important stuff but where security  is a minor concern.  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.  But even when there is can we consider that building management systems that use KNX are  secure?  So apart from just abusing such systems we can go further and there are a lot of research  subjects left to work on here.  For instance to find out what's really inside widely used implementations and what we can  do with them 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.  So first a quick message to vendors and users.  Stop assuming it's the others problem.  You both have your part to do in it.  So vendors please at least make sure that secure settings are default settings and users  check both settings and segregate your network or at least don't expose your devices on  internet.  And for us we have a brand new attack surface so let's test it.  Maybe someone will learn something.  Just be careful when you do that and test in controlled environments.  As for defenders lucky you you get a brand new defense surface.  So that's all for me.  I hope you enjoyed the presentation.  Thank you for listening.
DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_0_215.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_216_1187.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_1188_1931.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_1932_2315.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_2316_3023.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_3024_3503.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_3504_4031.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_4032_6263.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_6264_7883.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_7884_8291.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_8292_9935.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_9936_10931.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_10932_11807.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_11808_12371.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_12372_15611.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_15612_16595.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_16596_19703.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_19704_19787.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_19788_21539.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_21540_22271.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_22272_24599.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_24600_27203.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_27204_27443.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_27444_27695.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_27696_27815.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_27816_27959.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_27960_31091.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_31092_31451.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_31452_31727.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_31728_32087.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_32088_32663.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_32664_34295.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_34296_34523.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_34524_36503.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_36504_38651.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_38652_38903.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_38904_39479.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_39480_39815.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_39816_40343.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_40344_41831.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_41832_42527.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_42528_42791.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_42792_43019.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_43020_43307.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_43308_43379.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_43380_45971.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_45972_46139.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_46140_46271.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_46272_46739.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_46740_47999.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_48000_49631.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_49632_49715.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_49716_52235.png DEF_CON_29_-_Claire_Vacherot_-_Sneak_into_building_QofeTV39kQE_52236_52383.png