 Hi, I'm Clara Chereau and today I'm going to talk about sneaking into buildings using the building management system protocol KNX.net IP The 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 and non devices and protocols and we usually don't know where to start and This is what happened for me with building management system and KNX.net IP Just before we start a little disclaimer Testing 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 environments We control to avoid unwanted side effects 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 Schedules the sprinkler system to run at a certain time basically for revenge 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 them the example from hackers Sensor could be a fire detector the actuators Could be the spring class and and so on So they communicate these devices communicate with each other using field bus protocols usually untwisted pairs or radio frequencies so this part can work standalone and In fact before it was the only part but then the field bot got connected to the IP network First because there's 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 one So to simplify the operator just needs to be on the same network as this IP interface But to configure and control the field parts in a way re-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 the industrial and building management system made in software and protocol were created before we started talking about cyber security 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 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 SSI 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 too common of such protocol being a 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 They are a field backnet or field KNX requests 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 protocols do 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 cyber security There is no protection against replay or whatsoever 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 This it just replays the command to turn the system off every once again and that's enough And by doing this in a real environment, this could have a really bad effect But 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 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 on these 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 if for instance you can compromise An IP interface exposed on the internet 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 An alternative to this scenario could be to use the BMS for network pivoting For instance in industrial systems, IT and OT network 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 paper Also, there are already a few talks about BMS exploitation And among them, I recommend the one by Rezos Molina at Defcon 22 Which talks about abusing a KNX 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's KNX? Actually, the scenario that we just went through can be applied to any building management system protocol that has an IP layer So there's of course backnet, but there's also KNX 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 KNX So as you already know KNX 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 chargers are operated by KNX 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 KNX in 1999 Then eight years later, KNX NetIP was created and then the KNX installation became reachable from the network And then again, six years later Security came The first KNX NetIP 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 get back to it later There are a few external documentation and also a few research and work about KNX 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 it covered 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 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 a KNX IP secure and KNX dataset 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 expose and show them 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 the KNX net IP without excessive study of the KNX specifications So this is what we call security by obscurity And that's bad So KNX For my beer So now let's get started Let's start testing KNX The the standard is right about one thing The protocol is complicated We have few resources And it's hard to to start testing KNX really So at least now the specifications are free, but and you just need an account on KNX websites But You also need good nerves because the specification is 148 pdf files in 10 sections We have information spread everywhere So you just don't know where to find what you need and you can grab as many needs as 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 KNX association So we could use KNX virtual to emulate a KNX environment That will combine with ETS Which is the official engineering tool to configure KNX 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 Wireshark already has a KNX net IP 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 lights 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 run a few things in a safe environment And we can also run diagnostic on ETS And see what happens on Wireshark and and so on Just before we really start testing KNX, 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 KNX net IP request is sent to the KNX net IP interface This frame may contain only KNX net IP relevant information Or it can embed raw KNX data, which is related to the KNX layer So this KNX data are called KME for Common External Messaging Interface And there are independent KNX messages with their own formats inside the KNX net IP request So this means that they have their own headers, their own types, their own bodies, and so on So it 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 KNX 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 adds the value 1, it just starts the sprinkler 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 So there are already a few tools that we can use to do that First, there's, of course, ETS KNX 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 KNX map to scan IP interfaces on the network And you can see that we don't need to know much about KNX to use KNX map, which is cool We can see from Wireshark that a lot of things happened First, we see that we need to send a KNX request, an autonomic request with a KME And so on, but we'll get back to it later So there's KNX map, but there's also the KNX NetIP layer for Scapy, which was written by my colleague Julien Bedel It's not yet on the release, but it's at least merged to Scapy Master So you can already use it, so thanks to Julien and thanks to Scapy Maintenance for that But both Scapy and KNX map are suitable for basic interaction However, when I wanted to start using them for my own test, I encountered some limitations So first, KNX map is great if you don't know the protocol But I could not use it to craft invalid frames I could not modify KNX map code to outer 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 Scapy, 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 embed skinny 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 KNX NetIP Both is a Python-free library that we wrote to discover, interact with, and test devices They are the industrial network protocols So I first created it for KNX NetIP, but we can add other protocols For instance, we are currently adding modbed 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 and invalid frames to KNX NetIP 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 PawnCyberDefense GitHub To be honest, I wrote it for my own needs first And I use it to bring pen tests for discovery and to send comments But I also use it for vulnerability to research on protocol implementations on devices So I use both to write dump and not so dump further I can say they are 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, now 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 No 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 So 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 So 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 0 And when it's switched on it's 1 So if I write value 1 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 send 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 Kemi Here it's LDATAREC Which will be extracted and relayed to the KNX layer The server responds with a knack And also with a confirmation KNX frame To which we reply with a knack Because at least my test server is upset if I don't And yes, it's UDP So using both will 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 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 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 And this is the part I use for fuzzing Now I just show you how to start writing a further with both We won't talk about the results Because this is not another conference About how we first 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 over compile languages So it's definitely something that can happen But back to our further Here I choose to write another type of frames Because fuzzing tunneling request just writes Bad configuration to test 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 field in that frame 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 request, the rest of the code Handles the exchange with a similar process As for the tunneling 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 this 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 results we have Show 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 this we don't We could add an additional 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 is 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 when On where the crash occurs It may have different meaning If it's anywhere in the KNX NLIP 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 That a crashed occur leading to To the interface compromise But it may also be on devices themselves However it has never happened 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 So 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 system 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 other 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 enjoy the presentation Thank you for listening