Conference PaperPDF Available


Building Automation Systems (BAS) are crucial to monitor and control buildings, ranging from small homes to critical infrastructure, such as airports or military facilities. A major problem in this context is the security of BAS communication protocols and devices. The building automation and control networking protocol (BACnet) is integrated into products by more than 800 vendors worldwide. However, BACnet devices are vulnerable to attacks. We present a novel solution for the two most important BACnet layers, i.e. those independent from the data link layer technology, namely the network and the application layer. We provide the first implementation and evaluation of traffic normalization for BAS traffic. Our proof of concept code is based on the open source Snort normalizer.
The final publication is available at
DOI: 10.1007/978-3-319-18467-8 41
Securing BACnet’s Pitfalls
Jaspreet Kaur, Jernej Tonejc, Steffen Wendzel, and Michael Meier
Fraunhofer FKIE, Bonn, Germany
{jaspreet.kaur, jernej.tonejc, steffen.wendzel,
Abstract. Building Automation Systems (BAS) are crucial for moni-
toring and controlling buildings, ranging from small homes to critical
infrastructure, such as airports or military facilities. A major concern in
this context is the security of BAS communication protocols and devices.
The building automation and control networking protocol (BACnet) is
integrated into products of more than 800 vendors worldwide. However,
BACnet devices are vulnerable to attacks. We present a novel solution
for the two most important BACnet layers, i.e. those independent of the
data link layer technology, namely the network and the application layer.
We provide the first implementation and evaluation of traffic normaliza-
tion for BAS traffic. Our proof of concept code is based on the open
source software Snort.
Keywords: BACnet, network, security, attack, intrusion detection, traf-
fic normalization, building automation, Snort
1 Introduction
BACnet (Building Automation and Control Networking Protocol) is an open data
communication protocol developed by ASHRAE (American Society of Heating,
Refrigerating and Air Conditioning Engineers), standardized by ISO 16484-5 [1]
and used for building automation systems (BAS). In general, BAS are integrated
in and capable of controlling and monitoring buildings. Moreover, BAS form
networks which can be interconnected with other buildings and the Internet (e.g.,
for remote monitoring purposes). In order to support interoperability, BACnet
can use different lower level network protocols to perform its functions [2]. In
addition to BACnet, the European Installation Bus (EIB)/Konnex (KNX), and
the Local Operating Network (LON) are the most common BAS protocols used in
practice. The main goals of BAS are to improve the energy efficiency of buildings,
to increase the comfort and safety of the people living or working in a building,
and to decrease a building’s operational costs.
Because of the immense growth of BAS, especially BACnet, the need for
secure interconnection between BAS devices is increasing. Currently, there are
neither intrusion detection nor intrusion prevention systems which are capable
of detecting or preventing various network and application layer based attacks
on BACnet devices. Although security features for BAS protocols are specified
2 Kaur et al.
in their standards and have improved over time, they are, as highlighted in dis-
cussions with our industry partners, usually neither integrated in devices nor
used in practice. Due to the Internet connectivity of BACnet systems and the
fact that BACnet devices can be found using the SHODAN search engine (cf., remote attacks on BACnet devices can also be performed.
Such attacks can, for instance, compromise smoke detectors or other critical BAS
equipment. According to [3], there were more than 100,000 Internet-connected
smart devices (including media players, smart televisions and at least one re-
frigerator) interconnected to a network of computers, which were able to send
750,000 spam emails between December 23, 2013 and January 6, 2014. In addi-
tion, the so-called smart building botnets could extend the capabilities of today’s
botnets by taking advantage of a building’s physical capabilities (sensors and
actuators) [4].
In this paper, we show how to prevent the exploitation of vulnerabilities at
the BACnet network and application layers. In particular, devices which interact
with humans have to be both secure and safe; otherwise they can threaten and
compromise human life. We improve network and application reliability and se-
curity with traffic normalizers (also known as protocol scrubbers [5] from TCP/IP
networks). In TCP/IP networks, traffic normalization is capable of preventing
various attacks on TCP/IP stack implementations [7]. So far, there is no BAS
protocol for which traffic normalization has been applied. The building automa-
tion devices usually remain in buildings for decades, possess limited processing
power and insecure firmware, and often cannot cope with malformed or malicious
packets, hence there is an increased need for such normalizers.
We analyze the BACnet network and the application layer with its poten-
tial vulnerabilities and its potential non-compliant behavior, with the goal of
ensuring that BACnet devices receive correctly formed messages. In addition,
we study the well-known attacks from TCP/IP and adapt them to the corre-
sponding BACnet network and application layer, in order to design effective
countermeasures. Based on the discovered vulnerabilities, we present the first
implementation of traffic normalization for building automation systems in the
form of a Snort [6] extension. Additionally, our normalization rules provide a
means to counter fuzzing attacks and protect BACnet devices which are are not
usually updated because patching is a challenging task for BAS. We design our
system to normalize traffic between BAS subnets (e.g., between different floors
of a building or between separate buildings). Our normalizer implementation
ensures that the transferred packets reach the receiver well-formed according to
the protocol standard, without protocol vulnerabilities. The Snort extension is
implemented in a way that gives us an opportunity to either limit or prevent the
initiated intrusions mentioned in this paper.
The rest of the paper is structured as follows. We summarize the related
work in the area of BACnet security in Sect. 2. In order to make our method
of protecting vulnerabilities in the BACnet network and application layer un-
derstandable, we provide a short overview on the relevant parts of the BACnet
protocol in Sect. 3. Section 4 lists several vulnerabilities that were found by look-
Securing BACnet’s Pitfalls 3
ing at the specifications of the standard, together with the adaptations of the
TCP/IP attacks. Our normalization rules are presented in Sect. 5. The overview
of the testing environment is presented in Sect. 6. In Sect. 7, we evaluate and
summarize our results and discuss future work.
2 Related Work
Earlier installations of BAS were designed to work as isolated standalone systems
with minimal security features. As the BAS functionality requirements increased,
interconnectivity, interoperability, and especially Internet access for BAS became
significant features. However, the interconnectivity of BAS enables remote at-
tacks. Attacks on BAS can focus on gaining physical access to a building [8] (e.g.,
by exploiting window or door actuators), on gaining access to an organizational
intranet [9], on terrorist attacks [8] (e.g., turning off fire alarms before a fire is
placed), on monitoring inhabitants [10], or on disabling a building’s function-
ality via denial-of-service (DoS) attacks [11].
Celeda et al. [12] and Szl´osarczyk
et al. [13] showed that different types of DoS attacks exist for BAS. As pointed
out by Bowers [14], BACnet devices are not robust enough to deal with abnormal
traffic, since protocol implementations are vulnerable to malformed packets and
various forms of attacks. The BACnet Attack Framework (BAF) [14] introduces
attack techniques, namely attacks on the BACnet routing, network mapping,
DoS and spoofing. The existing work provides a good estimate of the current
attack surface for BAS networks.
In terms of defense against (some of) the attacks mentioned above, the BAC-
net Firewall Router (BFR) [15] is the first approach integrating simple firewall
functionality in BACnet. BFR is an open source project that implements filters
for BACnet messages and is capable of performing NAT, software-side network
switching, and routing. However, the BFR does not possess any normalization
capabilities. In comparison to the previous work, we present the first traffic nor-
malization for BAS capable of
countering typical attacks known from TCP/IP networks,
ensuring compliance, and
increasing robustness against vulnerability tests and fuzzing attacks.
3 Structure of BACnet NPDU and APDU
BACnet’s purpose is to handle a number of application areas such as lighting,
fire alarms, and heating, ventilation, and air-conditioning (HVAC) in a cost
effective, interoperable, and reliable manner [16]. BACnet defines four layers
(physical, data link, network, and application layer), similar to the particular
functions of the OSI layers (shown in Fig. 1) and is designed to adapt to different
data link and physical layer technologies to achieve data link layer-independent
communication. BACnet network layer messages can be encapsulated in UDP
(referred to as BACnet/IP), the BACnet-specific protocol MS/TP (RS485) or
4 Kaur et al.
LonTalk ZigBee. The BACnet model differs from the OSI layer model in that the
BACnet application layer is additionally responsible for performing and handling
the message segmentation and reassembly, a feature usually accomplished by the
transport layer.
OSI Layer BACnet Stack Protocol
Application BACnet Application Layer
Network BACnet Network Layer
Data Link
BACnet/IP over
ISO 8802-2 LLC
Physical Ethernet ARCNET RS485 RS232 UDP/IP ZigBee
Fig. 1. BACnet OSI Layers, from [1].
Our work focuses on the network and application layers. Therefore, we need
to introduce the addressing scheme and the structure of the BACnet Network
Protocol Data Unit (NPDU) and the Application Protocol Data Unit (APDU).
Each BACnet device has a medium access control (MAC) address which is
combined with the BACnet (sub)net number to form the network level address.
An essential feature in BACnet is broadcasting. Due to the nature of BACnet
topology, three types of broadcasts are supported: local, global, and remote.
Octets Description
1 Version
1 NPCI Control Octet (CO)
2 Destination Network (DNET)
1 Destination Address Length (DLEN)
Variable Destination Address (DADR)
2 Source Network (SNET)
1 Source Address Length (SLEN)
Variable Source Address (SADR)
1 Hop Count
NSDU Variable
Network Layer Message or
Application Layer Protocol
Data Unit (APDU)
Bit Description
7 Indication
6 Reserved
5 Dest. Specifier
4 Reserved
3 Source Specifier
2 Expecting Reply
Fig. 2. BACnet NPDU format (left) and NPCI control octet (right). In NPCI control
octet, Bit 7 indicates whether the NSDU contains a network layer message (bit is set)
or an APDU (bit is unset). Based on [1].
Securing BACnet’s Pitfalls 5
3.1 Network Layer
Even if the BACnet network layer is embedded into various data link layer
protocols, the NPDU structure remains unchanged. We will focus on BACnet/IP,
i.e. BACnet encapsulated in UDP sent over IPv4 [1], for which we define our
normalization rules. The structure of the BACnet NPDU is shown in Fig. 2.
3.2 Application Layer
An application program which uses the BACnet protocol interacts with a BAC-
net peer device. The purpose of the interaction itself is mainly to invoke device-
specific behavior, e.g. switching on/off a lighting device or ringing an alarm bell
of an alarm device. To realize application-specific behavior, so-called objects are
specified for functional behavior and services are specified for the interaction
with the devices. The application layer then defines all required objects and
services for a device’s interaction with an application program. Notice that the
application itself is independent of the application layer and is outside the scope
of the BACnet ISO standard. In particular, the standard does not specify the
Application Programming Interface (API).
For normalization, the relevant part of the APDU is the first region, called
the Application Protocol Control Information (APCI), which is always present
and whose length varies from 2 to 6 bytes depending on the PDU type. An
example of a Confirmed Request PDU is shown in Fig. 3.
0 3 4 7
max response
seg. accepted
max APDU length
Invoke ID
Sequence Number
Proposed Window Size
Service Choice
· · ·
Fig. 3. BACnet APCI for Confirmed Request PDU (PDU Type = 0). From [1, p. 538].
4 Exploiting the BACnet Network and Application Layer
We base our normalization rules and the need for traffic normalization by looking
at the potential security deficits in BACnet. We group our attacks on BACnet/IP
into two main categories: attacks adapted from TCP/IP, and attacks specific to
6 Kaur et al.
BACnet. Each category represents the possible vulnerabilities allowing the ex-
ploitation of BACnet devices by taking advantage of primitive vulnerabilities in
the network or application layer. We give a brief overview of the general attacker
model. In this model, the attacker is outside the BACnet network with a goal
to exploit a BACnet device. He is sending packets remotely to a BACnet device
(e.g. fire alarm, HVAC or a simple door) through a BACnet Broadcast Man-
agement Device (BBMD), which forwards all the packets to the corresponding
device. This scenario can be considered as the standard approach to attack BAC-
net environments remotely as BBMDs are always present to handle broadcasts
between BACnet devices. The model is graphically depicted in Fig. 4 left.
Sensors and Actuators
BACnet over IP
Sensors and Actuators
PDU-Type: Conf.Service Req
SADR = 00:2A:15:00:3C:F3
controlling a
lighting switch
SADR = 00:2A:15:00:3C:F3
Fig. 4. General Attacker model (left) and an attack through a controlled BACnet
device (right).
4.1 Attacks adapted from TCP/IP
Covert Channels. As shown in [10], BACnet allows for creating network covert
channels, i.e. the policy-breaking communication channels capable of transferring
data in a stealthy manner which can enable hidden command and control com-
munication for botnets. Disguised as BACnet traffic, malware could use BAC-
net covert channels to hide illegitimate or confidential data within unobtrusive
Internet-based traffic.
Many hiding techniques for network covert channels are based on the idea of
embedding hidden information in the unused NPDU and APDU fields. In the
case of BACnet, all reserved bits can serve the purpose of embedding hidden
information. Moreover, the use of particular BACnet message types and timing
variations between BACnet messages can signal hidden information [10].
Abnormal behavior leading to botnets in BAS. Referring to the example
of a refrigerator sending spam mails (cf. Sect. 1), we extended our research to
Securing BACnet’s Pitfalls 7
examine the compromised BACnet devices, including BBMDs. Our concern is
to provide security measures for the BACnet protocol against the abnormal
Celeda et al. [12] introduced two examples of attacks that can serve as
a backdoor for an attacker in a BACnet network. The WriteProperty attack can
cause a BBMD or a BACnet device to switch on/off, resulting in an opportunity
for an attacker gaining access to the restricted BACnet network. In general,
the WriteProperty attack and disabling of network connection are possible by
changing values in BACnet’s object properties, respectively misusing BACnet
services, i.e. in application layer [12].
In addition, after successfully attacking a BACnet device, an attacker has an
opportunity to use the device’s communication channel within the subnet. One
of the possible examples of such a scenario is shown in Fig. 4 right. We assume
the attacker has determined the details of both BACnet devices in the subnet
with the help of probing. If he takes over the lighting device, as shown in Fig. 4
right, then he gains the ability to transfer any kind of message he wants.
For instance, he can send a packet with an APDU containing a BACnet-
Confirmed-Request to the elevator device in which the service-related data in-
dicates the elevator should stop immediately. Because the lighting device is in
the subnet, it is trusted whenever authenticity checks are performed, hence the
attacker is able to bypass this security mechanism. The elevator accepts the
request, sends a BACnet-Simple-ACK, and stops immediately.
4.2 Attacks specific to BACnet/IP
Standard Non-conformance. We start by simply listing the vulnerabilities
which are tolerated by the standard. We distinguish the following terms, related
to the packets: compliant traffic fulfill the requirements given by the standard
and non-compliant traffic contain packets that do not conform to the standard,
e.g. malformed packets. Malicious packets are defined as packets designed to
exploit a threat. Malicious packets can either be compliant or not. We present
the following two examples to illustrate:
1. Network Mapping: An attacker is able to map the network with standard-
compliant messages like Who-is requests. Additionally, he is able to send
NPDUs containing application-specific APDU messages to probe the net-
work. The messages with reachable destination addresses are always for-
warded by the BBMD to the corresponding BACnet devices [17]. If a device
understands the service-related data contained in the payload, it gives a valid
response, otherwise the device returns an error. On getting a response, the
attacker knows which kind of devices can be addressed, e.g. fire alarm, HVAC
or a door. As all BACnet devices send responses, he is additionally able to
infer where (i.e. in which subnet) a device is located since the requests and
responses contain the destination and source addresses.
2. Flooding Attack: In this case, we consider the malformed packets, i.e. each
packet must possess at least one incorrect bit, according to the standard,
either in NPDU or APDU. Since BACnet devices do not drop the packets
8 Kaur et al.
but instead try to accept and process any request, the incorrectly set bits in
NPCI and APCI pose a threat to them.
Thus, an attacker can break a device by sending a flood of identical or
different packets, making the number of packets received by the device far
higher than normal. As a consequence, this can cause a denial-of-service, or
force unintentional behavior by the device.
Vulnerable protocol design. By analyzing the protocol structure of BACnet
and behavior of devices during communication procedure of certain messages,
we categorize the following attacks.
1. Smurf Attack: In BACnet, if an attacker is able to modify the source (SADR
and SNET) at the network layer, he will be able to spoof the address of
broadcast requests and can cause a denial-of-service for selected BACnet
devices. A smurf attack on BACnet is feasible as many BACnet devices
are either old (BAS hardware is seldom altered over decades) or possess
substantially lower processing capabilities than today’s desktop computers
and smart phones.
2. Router Advertisement Flooding: A similar attack is possible if an attacker is
able to spoof a target device’s source address and source network (SADR and
SNET) to send a Who-is-Router-to-Network message (requesting a router
advertisement for a given network). The result is that the target will receive
router advertisements from all the routers in the local network. If the attacker
repeats this procedure and sends too many repeated messages, the target
is likely to receive more responses in a time window than it can normally
handle, causing a denial-of-service.
3. Traffic Redirection: An attacker can spoof I-Am-Router-to-Network [12] or
Router-Available-to-Network messages, i.e. messages indicating the avail-
ability of a router, with the goal to redirect selected traffic over itself to gain
confidential monitoring data (e.g., presence sensor data of a given room to
plan a physical break-in [18]).
4. Re-Routing DoS, Type 1 : To cause a message flood on a router R or a BBMD,
an attacker can broadcast spoofed I-Am-Router-To-Network messages to the
network using the source address of R. Therefore, all possible destination
network addresses can be used as a parameter for the router advertisement.
This attack forces R to handle all responses to the I-Am-Router-To-Network
message and, moreover, forces R to handle all remote traffic.
5. Re-Routing DoS, Type 2 : If the target device of the Type 1 attack is not a
router, an attacker can redirect all the traffic for remote networks to a de-
vice incapable of forwarding messages, thus, isolating the communication of
a subnet. The scenario is similar to the one where the victim’s address can be
spoofed in a Router-Available-to-Network message. It is important to men-
tion that broadcast floods in BACnet networks can also be caused by devices
which are not configured properly. At least three examples from practice are
known [13]: i) the wrong setup of layer two switches that can lead to loops;
Securing BACnet’s Pitfalls 9
ii) the use of multiple broadcasting BBMDs in a chain without a broadcast-
limiting router device in the chain; iii) the combination of BACnet/Ethernet
ISO 8802-3 and BACnet/IP routers within the same infrastructure config-
ured to use the same UDP port (leads to permanent broadcast exchanges
between the two layers).
5 A Snort-Based BACnet Normalizer
We implemented a Snort-based normalizer extension capable of normalizing
BACnet/IP traffic based on a configuration file. Supporting BACnet/IP allows
extending our work to non-IP-based data link-layer protocols used by BACnet.
The Snort extension includes countermeasures for each discussed attack vec-
tors. The rules serve to remove ambiguities within the traffic in order to achieve
compliant traffic.
5.1 Standard conformity
Ensuring robustness for the protocol stacks of BACnet devices is essential as
firmware is seldom updated. Therefore, malformed packets violating the rules
of the BACnet standard must be modified or discarded to achieve specificity.
We list countermeasures in the form of normalization rules for the variants of
malformed packets which succeed in compromising a BACnet device or the whole
network, as mentioned in Sect. 4. The rules are split into five categories: NPCI
field, BACnet non-security message types, BACnet security message types, APCI
field, and the handling of BACnet priority messages.
NPCI field. Being an ever present component of a BACnet NPDU, the NPCI
field including the NPCI control octet (CO) can always be normalized. Reasons
to DROP messages:
1. Protocol Version Number != 0x01
2. DNET = 0, or SNET = 0, or SNET = 0xFFFF
3. Multicasts and local broadcasts with DNET=0xFFFFFFFFFFFF using ISO 8802-
3, DNET=0x00 using ARCNET or LonTalk, DNET=0xFF using MS/TP
4. Bit 3 of CO is 1 and SLEN = 0
5. Unicast message with DNET = 0xFFFF
Reasons to MODIFY messages:
1. Set DLEN = 0 and DADR=0 if the message is a remote broadcast
2. Set bits 6 and 4 of CO to 0
BACnet Non-Security Message Types. As explained in Sect. 3, bit 7 of the
NPCI control octet indicates whether a BACnet message represents a network
layer message or an APDU. Table 1 shows the possible network layer message
types. We determined the following normalization rules for non-security network
layer message types. We DROP the message, if the message type is any of the
10 Kaur et al.
Table 1. BACnet Network Layer Message Types. Security message types are marked
Type Description Type Description
0x00 Who-Is-Router-To-Network 0x0B
0x01 I-Am-Router-To-Network 0x0C
0x02 I-Could-Be-Router-To-Network 0x0D
0x03 Reject-Message-To-Network 0x0E
0x04 Router-Busy-To-Network 0x0F
0x05 Router-Available-To-Network 0x10
0x06 Initialize-Routing-Table 0x11
0x07 Initialize-Routing-Table-Ack 0x12 What-Is-Network-Number
0x08 Establish-Connection-To-Network 0x13 Network-Number-Is
0x09 Disconnect-Connection-To-Network 0x14-0x7F Reserved for use by ASHRAE
Challenge-Request 0x80-0xFF Available for vendor proprietary messages
1. 0x02, 0x03, 0x08 or 0x13, and 4 or more bytes follow the type field
2. 0x01, 0x04 or 0x05, and an odd number of bytes follows the type field
3. 0x06 or 0x07, and more than 4× NUMBER OF PORTS +
Sum of all PORT INFO LENGTHs bytes follow the type field
4. 0x00 or 0x09, and more than 2 bytes follow after message type field
5. 0x00: Limit the number of messages to m per second
6. 0x01 and the message is not transmitted with a broadcast MAC
7. 0x12 and the message is not transmitted with a local address, or if Hop-Count > 0,
or if SADR is the same during n minutes
8. 0x13 and SNET/SADR or DNET/DADR is set or the message is sent to a local
unicast address
Parameters m and n are configurable and depend on the particular hardware
used (for example, in collaboration with industry partners we determined m =
180 as a reasonable value).
BACnet Security Message Types. We define rules for security messages as
stated in [17]. Error messages in each case should always be sent signed-trusted.
We DROP the message, if the message type is any of the following:
1. 0x0A, 0x0E, 0x0F or 0x11, and the message is broadcast
2. 0x0A and more than 9 bytes follow the type field
3. 0x0B and more payload is transferred than specified
4. 0x0C and
(a) the RESPONSE CODE (RC) is 0x06 and the length ` of
(b) RC=0x07 and ` > 2, or
(c) RC=0x0E and ` is even and the first byte is not 0x00, or
(d) RC=0x0F and ` > 2, or
(e) RC=0x15 and ` > 1, or
(f) RC=0x16 and ` > 3, or
(g) RC=0x17 and ` > 2, or
(h) RC=0x18 and ` > 1
5. 0x0D and more than 19 bytes follow the type field
6. 0x0E and more than 21 bytes + bytes of keys follow the type field
Securing BACnet’s Pitfalls 11
7. 0x0F and more than 1 byte + bytes of keys follow the type field
We MODIFY the messages as follows:
1. Set bit 2 of CO to 1 if the type is 0x0A, 0x0D, 0x0E, 0x0F or 0x11
2. Set bit 2 of CO to 0 if the type is 0x0C or 0x10
APCI field. Whenever bit 7 of the NPCI control octet is 0, the content of
the NSDU is an APDU, in which case the APCI field is present and can thus
be normalized. Therefore, we implemented additional normalization rules. We
MODIFY the messages as follows (cf. Fig. 3):
1. Set the first bit in PDU Type to 0
2. Set bits 7 and 8 of APCI to 0 if PDU Type is 0
3. Set bits 4 7 of APCI to 0 if PDU Type is 1, 2, 5 or 6
4. Set bits 6 and 7 of APCI to 0 if PDU Type is 3
5. Set bits 4 and 5 of APCI to 0 if PDU Type is 4
6. Set bits 4 6 of APCI to 0 if PDU Type is 7
Handling of BACnet Priority Messages. BACnet allows assigning each
message a priority [1, pp. 68]. The priority is indicated by bits 1 and 0 within
the NPCI control octet (11=Life Safety, 10=Critical Equip, 01=Urgent, 00=Nor-
mal). The highest possible priority of a packet is the life safety message and can
be handled in a prioritized way by the receiving devices. However, in practice
this feature is rarely used. We aim to introduce normalization for packets of all
priority levels if they are not well-formed according to the ISO standard [1]. Nev-
ertheless, we must take into account that not all malformed packets are caused
by an attacker, and that dropping a life safety message can result in significant
side-effects if the message is not delivered but contains life-essential informa-
tion. Therefore, we require that life safety messages must be modified (in order
to match compliant NPDUs according to the standard as closely as possible)
and always forwarded, and should never be dropped. We are aware of the fact
that an attacker could explicitly take advantage of such a rule. In order to miti-
gate such attacks, one could require that BACnet messages sent with life-safety
priority MUST always have a trusted level, i.e. they must be either encrypted or
physically secured according to [17], so that the receiving device is aware of the
sending device. Life safety messages not encoded this way would be dropped.
This approach, however, requires the support in the devices, which is not always
5.2 Prevention of Network Covert Channels
The covert storage channels that an attacker could embed in the reserved bits
of the BACnet NPDU and APDU are disabled, as the normalizer clears these
bits. It is important to mention that other covert channels (especially timing
channels) cannot be eliminated with this approach and that many additional
hiding techniques for network covert channels are available. To counter additional
covert channels, extensions for caching packets before forwarding them would be
required, in order to limit the capacity of covert timing channels.
12 Kaur et al.
5.3 Closing Protocol Security Flaws
Unconstrained broadcasting in BACnet networks is a problem and allows for a
wide spectrum of attacks, as outlined in Sect. 4. In order to prevent flooding and
spoofing attacks, the appropriate limits for broadcast messages per time interval
must be defined. These limits depend on the particular BACnet devices and
are thus vendor-specific. In one empirical study, performed in co-operation with
a vendor of BACnet products, we measured that most tested BACnet devices
cannot process more than 180 messages per second.
6 BACnet Testbed
Our test environment is implemented using the open source BACnet stack (avail-
able at and the virtual machines, each rep-
resenting multiple BACnet devices (see Fig. 5).
Linux VM 1
(Sender )
Fuzzer +
BACnet Stack
test traffic
Linux VM 2
(Normalizer )
test traffic
Linux VM 3
(Receiver )
Wireshark +
BACnet Stack
Fig. 5. BACnet testbed for evaluating the Snort extension [13].
We setup the testing environment using three virtual machines (VMs). VM
1 represents the attacker who sends non-compliant BACnet traffic using the
fuzzer. The messages are first examined by the normalizer (VM 2) before they
are forwarded to the virtual BACnet device (VM 3). The destination host VM
3 monitors the received packets using Wireshark.
The fuzzer is implemented using the Scapy packet manipulation tool [19]. It
sends invalid and malformed packets to our test system in order to measure the
behavior and the performance of the test system. The fuzzer follows the rules
related to the structure of the messages as described in the ISO standard. To
simulate the denial-of-service scenarios we implemented the packet sending in
C, thus achieving very high packet send rates (upwards of 800,000 packets per
The normalizer is created as an extension of the existing Snort [6] code with
our normalization rules for BACnet messages. Our extension is able to recognize
BACnet messages which are sent through UDP over IPv4. Each byte of the
NPDU and APDU can be analyzed in order to decide whether to forward, drop
or modify each packet according to a predefined rule set.
Securing BACnet’s Pitfalls 13
7 Evaluation and Future Work
The purpose of implementing the testbed is to verify the correctness and the
performance of the Snort-based normalizer by testing the prevention of attacks
(described in Sect. 4). To achieve this, we divided the BACnet/IP packets into
two sets, for each normalization rule (rules described in Sect. 5). The first set
contained non-compliant and malformed packets and the second set contained
compliant and legitimate packets. We created at least one malformed packet
for each normalization rule individually. Each set was further subdivided into
various subsets of different message types. We created different unit and generic
test cases to examine the behavior of packets from both sets.
As per the test environment setup, the messages were sent from VM 1 to
VM 3. For generic testing, we transmitted the messages using a fuzzer which
has the capability to send thousands of messages of a particular message type
at a time. This helps to evaluate the performance of the system in handling
flooding of messages. We tested scenarios with between 10,000 and 100,000 mes-
sages. By using Wireshark on the destination VM (VM 3), we observed that
the non-compliant messages were either dropped/blocked or modified correctly,
and compliant messages were transmitted to the destination without any in-
terruptions, so that all the received packets were handled as stated in Sect. 5.
We carried out this scenario (as stress-testing) to measure performance of the
destination, VM 3 the virtual machine representing the attacked BACnet
with and without a preceding normalizer. We flooded the device with a various
numbers of malformed packets. Without the normalizer, the target device was
unable to cope with the traffic. When the normalizer was enabled, none of the
malformed packets reached the device. During the test, the CPU load on the
normalizer VM (VM 2) was below 65% at all times.
For unit testing, we created 48 non-compliant test messages for different
message types. Each packet was created to test the normalization rules laid
down in Sect. 5. We also created 45 compliant test messages. These test messages
were sent individually to test the behavior of the normalizer VM 2. Our tests
showed that the normalizer was clearly able to differentiate between compliant
and non-compliant traffic and performed necessary actions whenever required
before forwarding packets to the destination VM 3.
Our future work will focus on the problem of detecting abnormal behavior
of infected or exploited BACnet devices.
Celeda et al. [12] introduced a network
flow-based detection tool and provided a theoretical comparison to determine
anomalies in BACnet control flows using their network monitor tool. The au-
thors were able to record key information in order to detect a flood. Prevention
techniques, however, were not implemented in the tool. We plan to expand our
Snort normalizer extension to include detection and prevention of abnormal
traffic. By analyzing data collected from actual BACnet networks we will de-
velop application-specific rules and create a state machine that can distinguish
abnormal states from compliant ones. Furthermore, we plan to expand the nor-
malizer to handle segmentation-based attacks by performing packet reassembly
and caching within the normalizer.
14 Kaur et al.
1. ISO 16484-5:2012 Building automation and control systems Part 5: Data com-
munication protocol.
2. Merz, H., Hansemann, T., H¨ubner, C.: Building Automation: Communication sys-
tems with EIB/KNX, LON and BACnet. Signals and Communication Technology,
Springer, 2009
3. Proofpoint Inc.: Proofpoint Uncovers Internet of Things (IoT) Cyberattack. Re-
port, January 2014.
4. Wendzel, S., Zwanger, V., Meier, M., Szl´osarczyk, S.: Envisioning Smart Building
Botnets. GI Sicherheit, LNI 228, 319–329 (2014)
5. Malan, G.R., Watson, D., Jahanian F. and Howell, P.: Transport and application
protocol scrubbing, Proc. IEEE Conf. Computer Communications (INFOCOM),
1381–1390, 2000.
6. Snort open source network intrusion prevention system and network intrusion
detection system.
7. Handley, M., Paxson, V. and Kreibich, C.: Network Intrusion Detection: Evasion,
Traffic Normalization, and End-to-End Protocol Semantics. In Proc. USENIX Se-
curity Symposium, Berkeley, 2001.
8. Holmberg, D. G.: Enemies at the gates. BACnet Today, pp. B24–B28, 2003.
9. Soucek, S. and Zucker, G.: Current developments and challenges in building au-
tomation. In: e&i (Elektrotechnik und Informationstechnik), 129(4), 278–285, 2012.
10. Wendzel, S., Kahler, B., Rist, T.: Covert Channels and their Prevention in Building
Automation Protocols A Prototype Exemplified Using BACnet. In Proc. 2nd
Workshop on Security of Systems and Software Resiliency, 731–736. IEEE, 2012.
11. Granzer, W., Kastner, W., Neugschwandtner, G. and Praus, F.: Security in net-
worked building automation systems. In Proc. 2006 IEEE International Workshop
on Factory Communication Systems, 283–292, 2006.
Celeda, P., Krejc´ı, R., Krm´ıcek, V.: Flow-Based Security Issue Detection in Build-
ing Automation and Control Networks. In Information and Communication Tech-
nologies, LNCS 7479, 64–75 (2012)
13. Szl´osarczyk, S., Wendzel, S., Kaur, J., Meier, M., Schubert, F.: Towards Suppress-
ing Attacks on and Improving Resilience of Building Automation Systems - an
Approach Exemplified Using BACnet. GI Sicherheit, LNI 228, 407–418 (2014)
14. Bowers, B.: How to Own a Building: Exploiting the Physical World with BacNET
and the BACnet Attack Framework, Shmoocon 2013.
15. Holmberg, D. G., Bender, J., and Galler, M.: Using the BACnet firewall router.
BACnet Today, pp. B10–B14, November 2006.
16. Tom, S.: BACnet for a City – Saving Energy one Small Building at a Time; BACnet
Today and the Smart Grid, pp. B4–B9, November 2012.
17. ASHRAE: Proposed Addendum ai to Standard 135-2012, BACnet – A Data Com-
munication Protocol for Building Automation and Control Networks, 2014.
18. Wendzel, S.: The Problem of Traffic Normalization in a Covert Channel’s Network
Environment Learning Phase. Sicherheit 2012, pp. 149–161, LNI 195, GI, 2012.
19. Biondi, P., the Scapy community: Scapy Documentation, Release 2.1.1, 2010.
... Their utilization via a BYOD paradigm makes them a prime objective for exfiltration attempts or steganographic attacks [9]. Similar considerations can be done for IoT nodes or building automation and control networking, which often rely upon wireless connectivity for retrofitting purposes [20]. 2. wireless technologies: the ubiquitous availability of wireless communications and the increasing softwarization of radio access networks open up to a widerange of steganographic manipulations [21]. ...
Full-text available
Wireless technologies, softwarization of hardware and the increasing diffusion of IoT nodes allow to access and control industrial settings, smart environments and a variety of remote services. This leads to a wireless connected world characterized by a mixed set of technologies handling various personal and sensi- tive data. Therefore, security and privacy are critical requirements, which should be pursued starting from the early stages of design. Unfortunately, the complex and composite nature of modern wireless deployments enables the creation of emerging and effective threats. For instance, the traffic of IoT nodes can be inspected to infer habits or to conduct reconnaissance campaigns, whereas exchanged digital artifacts could be exploited to conceal secret information or perform exfiltration of data. In this perspective, this chapter presents and outlines new threats targeting the technological ecosystems at the basis of the so-called wireless Internet. It also proposes design choices that should be considered to engineer more secure and private wireless environments.
... The BACnet protocol can use many different physical media technologies such as Ethernet, Point-To-Point over RS-232, ZigBee, ARCNET, and Lon-Talk. There are some security features defined in BACnet protocol, but the authors in [22] pointed out that a lot of actual real implementations lack these security features. -Niagara Tridium Fox is a proprietary protocol designed by Niagara to bridge between remote SCADA networks. ...
Full-text available
The Internet, and many of the related things, hence the term Internet of Things, IoT, continue to expand and take more roles in human lives. Indeed, this enables us to be connected with our devices and the environment. The Internet also enabled us to be continuously informed about the status of our cars, homes, health, family, friends, etc. However, such exposure or publicity for all those things around us risks them being accessed and used by illegitimate users or intruders. In recent years, Industrial Control Systems (ICSs) have been exposed to the public Internet after being traditionally existed in closed communication systems. As a result, there is a critical need to shed light on network security concerns for these systems' safety. Our study evaluates the different communication protocols used in these systems and assesses and analyzes their security vulnerabilities. The results showed no significant correlation between the number of open ports and total recorded vulnerabilities. Results also showed that specific ports are more vulnerable than the rest due to the nature of their services or applications.
... The QoS is affected by such an attack, which can be conducted by an attacker without any special skills. Router advertisement flooding can be used by attackers in order to exhaust the resources of a device by means of the routing maintenance protocol [153], resulting in a DoS. In BACnet, this methodology can be applied using who-is-router-to-network messages and the source addresses SADR and SNET. ...
Full-text available
During the last decade, the smart grid (SG) concept has started to become a reality, mainly thanks to the technical progress achieved in telecommunications, informatics and power electronics, among other domains, leading to an evolution of the traditional electrical grid into an intelligent one. Nowadays, the SG can be seen as a system of smart systems that include cyber and physical parts from different technologies that interact with each other. In this context, intelligent buildings (IBs) constitute a paradigm in which such smart systems are able to guarantee the comfort of residents while ensuring an appropriate tradeoff of energy production and consumption by means of an energy management system (EMS). These interconnected EMSs remain the objective of potential cyber-attacks, which is a major concern. Therefore, this paper conducts a survey, from a multidisciplinary point of view, of some of the main security and privacy issues related to IBs as part of the SG, including an overview of EMS, smart meters, and the main communication networks employed to connect IBs to the overall SG. Future research directions towards a security enhancement from both technical and human perspectives are also provided.
... In [7] and [8] the usage of BACnet Firewall Routers (BFR) is described. Another solution is discussed in [9]. It makes use of intrusion detection and applies packet normalization on BACnet messages. ...
Full-text available
Grid-interactive efficient buildings (GEBs) are not only exposed to passive threats (e.g., physical faults) but also active threats such as cyber-attacks launched on the network-based control systems. The impact of cyber-attacks on GEB operation are not yet fully understood, especially as regards the performance of grid services. To quantify the consequences of cyber-attacks on GEBs, this paper proposes a modeling and simulation framework that includes different cyber-attack models and key performance indexes to quantify the performance of GEB operation under cyber-attacks. The framework is numerically demonstrated to model and evaluate cyber-attacks such as data intrusion attacks and Denial-of-Service attacks on a typical medium-sized office building that uses the BACnet/IP protocol for communication networks. Simulation results show that, while different types of attacks could compromise the building systems to different extents, attacks via the remote control of a chiller yield the most significant consequences on a building system’s operation, including both the building service and the grid service. It is also noted that a cyber-attack impacts the building systems during the attack period as well as the post-attack period, which suggests that both periods should be considered to fully evaluate the consequences of a cyber-attack.
Full-text available
Grid-interactive efficient buildings (GEBs) have been considered as an important asset to support the power grid reliability by utilizing the demand flexibility offered by GEBs. GEBs are enabled by advances in sensors and controls, and the communication between building equipment, whole buildings, and the grid. The integration of different building technologies and network-based communication system makes GEBs vulnerable to passive threats such as equipment failure and active threats such as cyber-attacks. Modeling and simulation is an effective way to evaluate the impact of threats on the system performance. This paper proposes a generic and flexible threat injection framework for commonly-used building energy simulators such as EnergyPlus and Modelica to support threat modeling and evaluation. This framework leverages functional mock-up unit (FMU) to develop a general modeling interface for threat injection and simulation. A numerical case study using Modelica as a building energy simulator is conducted to demonstrate the capability of the framework for supporting single/multiple-order threat modeling and simulation of a GEB. Four threats and their combinations are injected on a Modelica-based threat-free building energy and control system, including operating supply fan at its full speed, remotely cycling the chiller on and off, blocking the chiller from receiving the chilled water supply temperature setpoints, and hijacking the global zone air temperature setpoint. Simulation results show that the cyber-attack that leads to short-term signal blocking has small effects on the system operation due to the ”self-healing” feature of the heating, ventilation, and air-conditioning (HVAC) interactive control system. The threat that takes control of resetting the global zone air temperature setpoints has the most adverse impact on the system energy use, peak power demand, thermal comfort and the provision of demand flexibility. The combination of four threats have aggregative effects on the system but the effects are less than the additive effects of the individual threat.
Full-text: Network information hiding is the research discipline that deals with the concealment of network transmissions or their characteristics. It serves as an umbrella for multiple research domains, namely network covert channel research, network steganography research, and traffic obfuscation research. The focus of this thesis lies primarily on network steganography and network covert channel research. This thesis was motivated by the fact that network information hiding requires a better scientific foundation. When the author started to work on this thesis, scientific re-inventions of hiding techniques were common (similar or equal techniques were published under different names by different scientific sub-communities). This is, at least partially, rooted in the non-unified terminology of the domain, and in the sheer fact that the ever-increasing number of publications in the domain is hardly knowable. Moreover, experimental results and descriptions for hiding techniques are hardly comparable as there is no unified standard for describing them. This is a contrast to other scientific domains, such as Chemistry, were (de facto) standards for experimental descriptions are common. Another problem is that experimental results are not replicated while other scientific domains have shown that replication studies are a necessity to ensure the quality of scientific results. Finally, there is an imbalance between known hiding techniques and their countermeasures: not enough countermeasures are known to combat all known hiding techniques. To address these issues, this thesis motivates and proposes methodological adjustments in network information hiding and lays the foundation for an improved fundamental terminology and taxonomy. Moreover, hiding techniques are surveyed and summarized in the form of abstract descriptions, called hiding patterns, which form an extensible taxonomy. These hiding patterns are then used as a tool to evaluate the novelty of research contributions in a scientific peer-review process. Afterwards, this thesis addresses the problem of inconsistent descriptions of hiding techniques by proposing a unified description method for the same, including hiding patterns as a core component of every description. This thesis also introduces the WoDiCoF testbed as a framework to perform replication studies. Afterwards, the concept of countermeasure variation is introduced to address the problem of not having countermeasures available for certain hiding patterns. Finally, the proposed pattern-based taxonomy is enhanced to demonstrate the extensibility of the taxonomy and to integrate payload-based hiding techniques which were not foreseen in the earlier version of the taxonomy.
Full-text available
Cybersecurity research relies on the reproducibility and deep understanding of attacks to devise appropriate solutions. Different kinds of testbeds are typically used to systematically execute attacks and evaluate defenses. Testbeds are widely used to demonstrate Building Automation and Control System (BACS) attacks and defenses, considered too risky to be executed on real infrastructures. However, those testbeds implement arbitrary configurations of building services that do not resemble real-world deployments. In this work, we present the first BACS testbed specially designed to assess the impact of cyberattacks from the victim’s perspective. It features general purpose building services such as illumination, ventilation, and temperature control, whose configuration is easily adapted to emulate the requirements of real-world locations. In this way, the context added to our testbed allows us to better understand the impact of BACS attacks through concrete and realistic scenarios. Moreover, by analyzing different configurations of the BACS (i.e., contexts), we found out that identical attacks may have dramatically different impacts. Thus, reinforcing our view on the relevance of adding context to BACS testbeds.
The Internet of Things (IoT) will connect not only computers and mobile devices, but also smart cities, buildings, and homes, as well as electrical grids, gas, and water networks, automobiles, airplanes, etc. IoT will lead to extensive interconnection between Building Automation Systems (BAS) communication protocols and the Internet. The connection to Internet and public networks increases significantly the risk of the BAS networks being attacked, since there's a significant lack of detection and defensive mechanisms for BAS networks. In this paper, we present a framework for a context-aware intrusion detection of a widely deployed Building Automation and Control network. We developed runtime models for service interactions and functionality patterns by modeling the heterogeneous information that is continuously acquired from building assets into a novel BAS context aware data structure. Our IDS performs anomaly based behavior analysis to accurately detect anomalous events triggered by cyber-attacks or any functional failure. An attack classification and severity analysis of detected attacks allow our IDS to automatically launch protective countermeasures. We evaluate our approach in the Smart Building testbed developed at the University of Arizona Center for Cloud and Autonomic Computing, by launching several cyber-attacks that exploit the generic vulnerabilities of BACnet protocol.
Conference Paper
Full-text available
The interconnection of building automation and control sys-tem networks to public networks has exposed them to a wide range of security problems. This paper provides an overview of the flow data us-ability to detect security issue in these networks. The flow-based monitor-ing inside automation and control networks is a novel approach. In this paper, we describe several use cases in which flow monitoring provides information on network activities in building automation and control sys-tems. We demonstrate a detection of Telnet brute force attacks, access control validation and targeted attacks on building automation system network.
Conference Paper
Full-text available
A building automation system (BAS) is the IT equipment within a building that monitors and controls the building (e.g., measuring temperature in a room to configure the heating level within the same room). We discuss the potential and the use of botnets in the context of BAS. Our botnet concept and scenario is novel in the sense that it takes advantage of the phyiscal capabilities of a building and as it has to adapt to a specialized environment being highly deterministic, predictable, simplistic and conservative. These properties make anomalies easy to detect. Smart building botnets allow the monitoring and remote control of (critical) building automation infrastructure in public and private facilities, such as airports or hospitals. We discuss why building automation botnets could thus enable attackers to cause various critical damage on whole regions and economies. Hiding the command and control communication is a highly beneficial step to adapt botnets to the BAS environment. We show that this is not necessarily a big hurdle and can be solved using existing covert channel techniques.
Conference Paper
Full-text available
Different concepts of IT security, like communication encryption, have already been applied to building automation systems (BAS). However, no research is available to mitigate malicious or incompliant network traffic in BAS. Both aspects are covered by traffic normalizers. We present the first work-in-progress research on traffic normalization for building automation networks exemplified using building automation control and network (BACnet) protocol.
Conference Paper
Full-text available
Enriching Building Automation Systems (BAS) with new services formerly provided by separate subsystems promises synergies, but increases demands on the BAS ar- chitecture. In particular, the integration of security sub- systems significantly tightens security requirements on the protocol of a networked control system. First, this paper gives a survey on security in BAS. Possible threats and attacks are discussed. Weaknesses in the security mecha- nisms of important open networked BAS (LonWorks, BAC- net, KNX/EIB) are summarized. Then, a security exten- sion to KNX/EIB is presented. It includes several security mechanisms that guarantee data integrity, confidentiality and freshness, as well as authentication to provide secure process data and management communication. Relevant configuration related issues such as key management and distribution are also addressed.
Full-text available
The classical systems of building automation systems (BAS) have evolved from control of heating, ventilation and air-conditioning (HVAC). The wide use of fieldbus technology and powerful embedded systems has enabled new developments. Building automation is employed to integrate user requirements, system requirements and optimizations in order to maintain user comfort—with energy efficiency being a recently added optimization goal. The classic three-layer automation model is transferred into a service-oriented architecture (SOA) of objects. At the same time, the complexity increases as new services are added. Object-oriented solutions are an approach to cope with this. The basic design of controllers has become distributed and is adopting advanced methods. The resulting, highly integrated systems require a defense-in-depth strategy to ensure security. We take a look at the building services today and in the near future, highlight the strength of integrated building automation over different domains and industries and show the upcoming challenges for building automation systems.
Conference Paper
Full-text available
Security in building automation systems (BAS) recently became a topic in the security community. BAS form a part of enterprise networks and can be utilized to gain access to a company network or to violate a security policy. Up to now, the threat of covert channels in BAS protocols was not discovered. While a first available solution can limit ``high level'' covert channels in BAS, there is no solution available to prevent covert channels on the lower level (i.e., in BAS protocols). In this paper, we present network covert storage and network covert timing channels in the network and application layer of the BACnet protocol stack to show that protocol-level covert channels in BAS are feasible. Additionally, we introduce the first means enabling a BAS to become multi-level secure on the network and application layer to prevent covert channels. We built a prototype based on the BACnet firewall router (BFR) to implement multi-level security in BACnet environments.
Conference Paper
Full-text available
Network covert channels can build cooperating environments within overlay networks. Peers in such an overlay network can initiate connections with new peers and can build up new paths within the overlay network. To communicate with new peers, it is required to determine protocols which can be used between the peers -- this process is called the Network Environment Learning Phase (NEL Phase). We show that the NEL phase itself as well as two similar approaches are affected by traffic normalization, which leads to a two-army problem. Solutions to overcome this not completely solvable problem are presented and analyzed. A proof of concept code was implemented to verify the approach.
Conference Paper
Full-text available
Abstract A fundamental,problem,for network,intrusion detection systems is the ability of a skilled attacker to evade detection by exploiting ambiguities in the traffic stream as seen by the mo,nitor. We discuss the viability of addressing this problem,by introducing a new network forwarding element called a traffi c normalizer. The normalizer sits directly in the path of traffic into a site and patches up the packet stream to eliminate potential ambiguities before the traffic is seen by the monitor, removing evasion opportunities. We examine a number of tradeoffs in designing a normalizer, emphasizing the important question of the degree to which normalizations undermine end-to-end protocol semantics. We discuss the key practical issues of “cold start” and attacks on the normalizer, and develop a methodology,for systematically examining,the ambiguities present in a protocol based on walking the protocol’ s header. We then present norm, a publicly available user-level implementation,of a normalizer that can normalize a TCP traffic stream at 100,000 pkts/sec in memory-to-memory copies, suggesting that a kernel implementation,using PC hardware could keep pace with a bidirectional 100 Mbps link with sufficient headroom,to weather a high-speed flooding attack of small packets.
While BACnet secure messages are likely several years away the time for addressing security is now. It should be noted the current security vulnerabilities and develop a security policy. Then implement that security policy using the many security products currently available. When the efforts of the NS-WG are realized with the capability in BACnet for secure messaging, future buildings will have a means to address BACnet threats and add another layer of security.
If you pay attention to the news, then you know that network security is an important issue. It seems that every day brings a new account of compromised networks and compromised personal information; new viruses, worms, trojans, phishing attacks, and the like. We hear reports on identity theft, criminal use of botnets (networks of hijacked computers), and foreign countries' concerted efforts to break into defense networks. Clearly, attackers, motives, and methods vary, but the dangers are real.