The insecurity of the building automation system KNX

April 29, 2016

Today I’ll write a completely different security blog post to which I normally write. This one is about KNX – I’ll guess most readers (which are largely IT people) don’t even know what it is about. Here from Wikipedia:

KNX is a standardized (EN 50090, ISO/IEC 14543), OSI-based network communications protocol for building automation. KNX is the successor to, and convergence of, three previous standards: the European Home Systems Protocol (EHS), BatiBUS, and the European Installation Bus (EIB or Instabus). The KNX standard is administered by the KNX Association.

(Source: https://laughingsquid.com/tetris-building-hack-at-mit/)

Now you’re asking why I’m writing about it and why I wrote it’s a security blog post? The KNX standard is now getting whitely deployed in Tirol in new office buildings and even is used on bigger renovations of these.  Most of these deployments are done by civil and electrical engineer, which don’t think (care?) about IT security. And as it is a network communication protocol and is often connected to the IT network of the company someone in the company should think about it.

KNX Basics

So let’s starts with the basics. The most common form of deploying that network (called KNXnet sometimes only KNX) is over a two wire bus (twisted pair, called KNXnet TP) which is routed in parallel to the 230 V electrical power supply KNXnet connects all devices and systems of the building. To make the list complete following media are possible:

• TP: twisted pair
• PL: power line (over the normal 230V lines)
• IP: Internet protocol
• RF: wireless

The network speed is 9600 bit/s and following device groups get normally connected to the network:

• Sensors (e.g. push buttons, wind-, temperature-, movement-sensors)
• Actuators (dimming units, electrical heating valves, displays)
• System devices and components (e.g. Line-Couplers, Backbone-Couplers)

Most often the system is used to automate the building (turn all lights of if no one is in the building, move the blinds up and down), but there are also implementations which are more in the direction of alarm systems.  In a security respect that means that everywhere any device, which is connected to KNX networks, is located (outside?) an attacker can get access to the network.  In any case if the system/building is larger the building manager would like to configure the system via his working PC, which leads to a connection to the IT network. This a common case so the “The KNX standard – the basics” shows following diagram:

And yes, you’re reading that correctly, the KNXnet can be tunnelled over IP and therefore over Ethernet, which leads also to following setups:

But lets keep looking at the KNXnet more directly. Setting up the KNX network is possible via 3 bus topologies:

These topologies can be mixed as needed, but no ring is not allowed. As the line and star topology are a subset of the tree topology, the tree topology is the most flexible one and used in most bigger installations. The network IDs of a given nodes is based on its location in the tree (and looks like that 1.5.1), more information can be found here. Following diagram from the “The KNX standard – the basics” shows a full network over various media. The white boxes are the networks IDs of the various devices connected.

building automation security

As we now know how the system works in basic lets take an overview look why building automation sucks at security.

• Default passwords: Yes, you’ll see building automations systems in the wild with default passwords. If set a different one it won’t comply to the password policy of the company.
• No authentication: Be it for users or devices
• No encryption
• Management system reachable from the Internet (e.g. for easier support from the vendor)
• Back door access: Some vendors deploy UMTS/LTE routers and connect via them to the system. This is often done if the system has problems in the first years of the deployment. e.g. most often seen for heading systems … a high percentage seems to have problems in the first years)
• No separation from the normal PC IT network

And these points are mainly because the building automation is not part of / controlled by the company IT department and therefore not on the radar of the IT security staff.

KNX specific problems

So now lets look at some KNX design problems. KNX providers filters on the line couplers to limit the load on the network. These provide a feature like TTL the field in the IPv4 packets do. But if you use a routing counter of 7, that goes through every filter. This allows to send packets from a subsidiary line (does not matter where you’re connected to the network) to the complete network. You just need to capture a packet (or guess one) which tells all lights to turn off (to show something harmless ;-)) and resend it at a later time with a routing counter of 7 to turn every light in the building of. Spoofing of the network id is simple, just choose one … good luck finding the place where the bad device is – it could be anywhere in (or even outside) the building and it can completely control it. Take a look at following sides from a presentations at BSidesVienna 2014 to get to know many more problems, like code injection to the ETS software and so on. So attacking the IT network over it is also possible .. maybe the ETS software runs in the same networks as you’re other servers? Its really broken from a security stand point.

Hint: KNX for hotels is also quite common and every guest room has access to the KNX network. Just saying – don’t do it 😉

Hint 2: If someone tells KNX provides security features like a password. Reply: Yes – sure …. it’s optional and its a 4 (in words “four”) byte password transmitted in clear text … really hard to sniff or guess  ;-).

KNX software

Following software can be used to play with KNXnetworks

• eibd (alternative URL) a guy from the TU Vienna.

Concussion

If you’re in an IT security roll at the IT department you most likely cannot circumvent the installation of a KNX bus, but make sure that the system does not allow any attack vector against your services and systems. Think about it like an external IT network, you need to protect your systems against it (e.g. Firewall, network separation, …) . Make the normal security checks of the devices directly connected to your network (nmap, openvas scans, check used passwords, software versions, ….)  and make sure that its clear (in writing 😉 ) who is responsible for maintaining the KNX network it’s security – its not your.

If you’re a building manager … talk and listen to the security guys from your IT department. They fight every day against attacks and know how to mitigate security problems.

No Comments yet »

RSS feed for comments on this post. TrackBack URI

Leave a comment