2200+ Potentially Exposed to High Severity Vulnerability
Building Automation and Control network (BACnet) is one of the most popular SCADA protocols that building automation and control systems use to operate. Censys searches for five of the most popular SCADA protocol (including Modbus, S7, BACnet, DNP3, Tridium Fox) and a quick search shows that there are 16,899 BACnet servers accessible across the Internet.
Security practitioners have long known that these building control systems are particularly risky from a security perspective. Much like other IoT devices, many of these servers are not built securely and are often misconfigured during setup.
Remember, too, that this 16.9K number is only including those building control systems running on BACnet protocol, which is one of the most common for these systems, but it hardly represents a comprehensive view of building control systems overall.
What is BACnet anyway?
BACnet was developed in 1995 by the American Society of Heating, Refrigerating and Air-Conditioning Engineers to control building systems — think HVAC systems, lighting controls, fire detection devices, etc. The protocol was created to allow all those devices to work in sync and be controlled in one “language,” regardless of vendor, for data-sharing. Vendors, however, can specify proprietary objects, which allows the protocol to scale but also prevents cross-manufacturer from playing well together.
Researcher Jaspreet Kaur has done some really solid work in the area of BACnet security and she asserts that manufacturers do not implement these in practice. More robust history on BACnet is available in Steven T. Bushby’s paper that delves into the history of the protocol. Censys founders also wrote a research paper on industrial control service (ICS) devices that’s worth exploring.
Security implementation owned by…building contractors?
SCADA devices are often set up by building contractors, typically a different group than IT groups that understand security and all the risks that come with misconfigurations during setup. As such, these devices are often incorrectly installed and become a fairly easy target for attackers. Potentially adding to security woes is the way that the industry handles firmware updates in general, often requiring a manual process and a big, complicated lift from the IT and security teams.
In the case of BACnet and other building control systems, the onus typically lies with building contractors to maintain these systems and ensure security updates are installed in a timely manner. You can imagine, then, how often known vulnerabilities can exist, unpatched, on these devices, leaving them wide open to exploitation.
Real world impact of BACnet attacks
One of the reasons that BACnet exposure is so worrisome is that these devices operate critical systems like fire detection systems, lighting and HVAC controls within commercial buildings, which means that an attack against them could cause some serious physical damage, in addition to using these devices to launch attacks against other conventional IT systems. There are some pretty scary stories out there about how building control systems could be breached, but rather than fostering those fears, we want to focus on the real impact from attacks that have happened in the wild so we can learn how to prevent future ones.
Target becomes a really easy target (woof, sorry) for any and all building control systems compromise stories. In their case, attackers got in through the HVAC company, but it’s not a far reach to suggest that attackers could have also gained access through vulnerable BACnet (other similar SCADA) systems. We’ll use them as an example because, frankly, there are a lot of stories about potential dangers here, but not a lot of publicly-known breaches caused directly by insecure BACnet.
What happened in Target’s case is that the HVAC company was connected enough that it provided attackers with access to the company’s financial information and customer data. So, while a breach of the system would have been damaging to the brand, the media interest and focus was primarily due to the potential consumer financial and privacy concerns that resulted from the breach.
Let’s go through how to find theses BACnet systems on the Internet and then filter down to your particular organization so that you can isolate anything you find there and then use additional security tools to mitigate the risk they present to you or your business.
Exposed, vulnerable BACnet systems online today
The most common BACnet-based products in our scans are the Niagara AX and Niagara 4 systems. We looked at the most recent CVE-2017-16744 h associated with those products and found that more than 2000 of these systems would be affected by that vulnerability, which allows for remote code execution and is rated 7.4 (out of 10) on the severity scale.
It’s important to note that our data doesn’t determine whether these systems are patched. Because patching takes time and can sometimes be disruptive to other systems within an organization’s network, we know that many systems either never get patched and updated appropriately or, if they do, it often takes a while for these patches to be installed. With that in mind, it’s likely that many of these devices have not been to remediate this CVE.
Finding all BACnet systems in Censys
Here’s a quick search within Censys to locate those 17K systems running BACnet protocol, filtered by product name. Note, you’ll notice that the report drops in number, which is due to some 2000 BACnet products out there that are not named with manufacturer and product, for unknown reasons. At any rate, it’s a useful report as we explore the most popular BACnet products and assess their security state:
https://censys.io/ipv4?q=protocols%3A+%2247808%2Fbacnet%22
In the drop down next to “Build Report,” you can select how you want the data displayed (by location, for instance — more than 10K are in the US). Filtering is where the fun is (what do you mean we’re nerds?!), so we strongly encourage you to play around with our report builder function while exploring BACnet protocol usage.
For businesses trying to locate unknown (or monitor known) BACnet systems, you’d want to add “AND autonomous_system.asn:[YOUR AS NUMBER]” to the search text. For example, to find all BACNet devices exposed on University networks (don’t worry, we alerted REN-ISAC about these):
https://censys.io/ipv4?q=tags%3A+%22bacnet%22+AND+autonomous_system.name%3A+%22university+of%22
Mitigating risk of BACnet devices
In a rare, positive story in our industry, Penn State went on record about how they deal with BACnet systems in their organization. Recognizing that these services were a necessity (if a thorny one) for their university, they knew that just removing them wasn’t going to scale. So, their solution was to focus on microsegmentation instead of virtual local area networks (VLANs), firewalls, or access control lists (ACLs).
With sprawling and complex university networks, this option worked for Penn State and it’s definitely an option for businesses who are reliant on BACnet system but also want to ensure those servers don’t become doorways into the organization for malicious actors.
Nail down the basics:
- Ensure BACnet systems communicate on a network isolated from your other systems. There’s no reason at all to allow your building control systems to be connected to your customer database or financial systems. All this does is open the door to massive data loss risks.
- Reduce the number of administrators that have full admin rights these devices. If possible, revert control of your BACnet devices to your internal corporate security team, rather than the building contractors you work with. Enforce strong authentication, TLS or VPN connections, and ensure access provisioning to these is managed as you would any other mission critical IT system.
- Determine which systems are talking to each other via the BACnet protocol and make sure that those systems are secured with updated patches, configurations, and the like.
