- Hi, I'm Claire Vacherot 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 systems 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 during these assessments,
we often have new environments with unknown devices
and protocols, and we usually don't know where to start.
And this is what happened for me
with building management system and KNXnet/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 alerts.
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.
Now that said, let's talk about building management systems.
You may have already heard of them, as this is a 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's an interesting example from the movie "Hackers",
which has a BMS hacking scene.
The main character hacks into his school BMS interface
and he schedules the sprinkler system
to run at a certain time, basically for revenge.
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.
We can definitely do this, provided of course
that sprinkler system is linked
to the building management system.
So now, let's take a closer look at this technically.
In BMS, as a 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",
a 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 Fieldbus 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 bus got connected
to the IP network.
First, because there's that trend 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 these 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 parts.
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
maiden 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 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.
So see first, 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 and even closer look at the interface
between the LAN and the field.
So it's usually a device in an electric cabinet.
So it's means that it's hardly reachable physically,
but of course, reachable from the LAN.
And if you just 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 two common of such protocol
being BACnet and KNX.
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.
They are field BACnet or field KNX requests.
Today, I want to focus on thought 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 necessarily 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 of our industrial components
are protocols do not consider cyber security.
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're actually hard
and that we can reach them.
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.
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 whatsoever
and often no authentication
or at least authentication by default.
So here's a small example I did a few months ago.
This is an HVAC system in a test environment,
which can be controlled with BACnet.
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.
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.
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 overheat to death.
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.
So the other scenario is the unintended use of devices
using these protocols.
In scenario one, we run a 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 security 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's 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're 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 Jesus 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 BACnet systems and research about
attack detection and remediation on BACnet.
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.
So there's of course BACnet, 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 BACnet 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 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.
So basically, it's a merger of
three European field protocol standards
that were used since the '80s.
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.
And then again, six years later, security came.
The first KNXnet/IP security extension came out.
And finally, it's important to note that the 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're 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. (chuckles)
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 KNX IP Secure
and KNX Data Secure.
But once again, they're extensions.
They're 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 device's exposed, I'm sure that.
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 go 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 KNXnet/IP
without excessive study of the KNX specifications."
So, this is what we call security by obscurity,
and that's bad.
So KNX, hold my beer.
So now let's get started.
Let's start testing KNX.
The Standard is right about one thing.
The protocol is complicated.
We have few resources and it's hard
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,
with information spread everywhere.
So you just don't know where to find what you need
and you can grep as a need needs.
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.
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.
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 free 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 a 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 learn a lot.
And this is all virtual, so no side effects here.
Also Wireshark already has a KNXnet/IP dissector,
which is really convenient.
And also I have to say that the code for the dissector
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 downloaded it to KNX Virtual.
And we can see that if I click on buttons,
it turns on and off lights.
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.
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.
So when an operator pushes a configuration
or sends a command, a KNXnet/IP request
is sent to the KNXnet IP interface.
This frame may contain only KNXnet/IP relevant information,
or it can embed raw KNX data,
which is related to the KNX layer.
So this KNX data are called cEMI
for common External Messaging Interface.
And they are independent KNX messages
with their own format inside the KNXnet/IP requests.
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 to, with different impacts,
depending on the one we target.
And finally, a few words about the topology.
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.
The first one is individual addresses,
which are used to refer to the device.
The other one is group addresses,
which we refer more to functions.
So it's not a collection of devices,
but more collection of actions that devices can do.
For instance, we can imagine that the fire detector
and the sprinklers 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's group address answer value 1,
it's just starts to sprinkler.
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 is, of course, ETS.
KNXmap is also a great tool
if you want to discover devices and interact with them.
So let me show you quickly.
You can just KNXmap to scan IP interfaces on the network.
And you can see that we don't need to know much
about KNX to use KNXmap, 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.
Then a tunneling request with a cEMI.
And so on that, we'll get back to it later.
So there's KNXmap, but there's also
the KNXnet/IP layer for Scapy,
which was written by my colleague Julien Bedel.
It's not yet on a release, but it's at least merged
to Scapy Master, so you can already use it.
So thanks to thanks to Julien
and thanks to Scapy maintainers for that.
Both Scapy and KNXmap are suitable for basic interaction.
However, when I wanted to start using them for my own tests,
I encountered some limitations.
So, first KNXmap is great if you don't know the protocol.
But, I could not use it to craft invalid frames.
I could not modify KNXmap code to alter requests
without rewriting parts of it because they handle errors.
Which is a good practice,
but for fuzzing 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 cEMI 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 fun to write a new tool.
So now, I'm going to talk about BOF which is a tool we wrote
when I started using and testing KNXnet/IP devices.
BOF is a license free library that we wrote to discover,
interact with, and test devices,
they are the industrial network protocols.
So I originally created KNXnet/IP,
but we can add other protocols.
For instance, we are currently adding Modbus support.
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.
So if you recall the attack scenario I talked about earlier,
about sending valid and invalid frames to KNXnet/IP devices.
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.
To be honest, I wrote it for my own needs first,
and I use it doing pen tests
for discovery and to send commands.
But I also use it for vulnerability research
on protocol implementations on devices.
So I use both to write dumb and not-so-dumb fuzzer.
I can say they are smart.
And I give you an example of that soon.
And the more I go further in my research,
the more features I add in both to help my 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 BOF internals, which I think is interesting.
The first version of BOF relied on JSON5
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, and when I first presented BOF,
I was asked, why not use Scapy?
Which is actually a good question.
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.
However, we still let the user access the Scapy object
directly within BOF if she wants.
So if you want to know more about that,
we did tell how and why we did that in the documentation.
Now back to using BOF.
As I mentioned before, BOF can be used for discovery,
basic interaction and advanced testing.
So there are three ways to use BOF.
The first is the high-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 you reachable from the local network
and I'm on that local network,
so I can communicate with it choosing KNXnet/IP.
The actuator is subscribed group address 1/1/1
for the light and fan witching 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 1/1/1
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,
that's to say, change a value on devices.
This is what happens.
We send a KNXnet/IP frame to initiate
a tunneling connection to the KNX layer.
We then sent a tunneling request containing
a raw KNX frame, a cEMI.
Here it's L_data/req, which will be extracted
and relayed to the KNX layer.
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.
So using BOF, we'll just write a script
that does exactly that.
In here, the tunneling 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 the 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.
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.
(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.
See, and this is the part I use for fuzzing.
Now, I just show you how to start writing a fuzzer with BOF.
We won't talk about the results
because this is not another conference about
how we fuzz something to find buffer overflows.
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.
So it's definitely something that can happen.
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.
So that's not the best way to start I guess.
So I want to mutate a configuration requests.
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.
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.
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 handle the exchange
with a similar process as for the tunneling request
with the ACK and all.
And it will send my mutated KNXnet/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 timeout,
that's to say frames that did not get an answer.
That's, they are the most interesting ones for us.
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.
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 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 by 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 things 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.
Now that just the 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 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.
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 crash occurred leading to the interface compromise.
But it may also be on devices themself.
However, it has never happen to me so far.
So I might even be lying to you right now. (chuckles)
But investigating on this is exciting anyway.
It's time to wrap things up.
So, we have seen that there's 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 subject
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's 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 all settings and segregate your network,
or at least don't expose your devices on internet.
And for us, we have a brand new attacks surface,
so let's test it.
Maybe someone will learn something.
Just be careful when you do that,
and testing 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.