Vulnerabilities of Smart Buildings and ICS Security: Three UDP Packages to Root on EnOcean SmartServer

Depov

Moderator
Staff member
MODERATOR
ULTIMATE
SUPREME
PREMIUM
MEMBER
Joined
Feb 18, 2025
Messages
345
Reaction score
504
Deposit
0$
The business logic of attacking smart buildings: a physical impact through a digital vector
Why a BMS Controller? It's not about data theft or the encryption. Attacks on building automation systems are beaten in physics.

EnOcean SmartServer IoT is an edge controller that pulls the control logic of BMS: collects data from field sensors using the LonTalk protocol, makes decisions and distributes commands to executive devices. According to SecurityWeek, the platform stands in smart buildings, in factories and in data centers. Through one SmartServer can be controlled:
• Climate - HVAC in data centers, where the shutdown of cooling for 15-20 minutes causes cascading server equipment failure
• SKUD - electromagnetic locks, turnstiles, perimeter protection
• Power supply - monitoring and switching of loads, UPS management
• Fire safety - ventilation, smoke removal, fire valves
Compromising the controller with root privileges is not an abstraction. The attacker changes the settings, disables the equipment, presses emergency signals. There are precedents: TRITON (2017) hit anti-emergency systems petrochemical plant, Industroyer (2016, 2022) - by power grid. OT attacks with a physical impact have long been in the arsenal of APT groups.

According to Claroty, BMS controllers are usually driven by a building operation, not security units. The result - the equipment that manages physical processes falls out of vulnerability management and incident response programs. The safes just don’t know about it.
LON protocol chain: industrial safety protocols and IP-852
LonTalk Distributed Control Protocol, Echelon Corporation, 1990. Each node (controller, sensor, drive) communicates with others along the LON bus. Designed for isolated physical networks. Encryption? Authentication? No, I haven't heard.

CEA-852 - LonTalk traffic tunneling standard via IP. Classic OT-pattern: the protocol from a trusted insulated network receives IP wrap for the sake of remote management and cloud integration. CEA-852 defines the format IP-852 packets, which wrap LonTalk messages in UDP-date.

SmartServer IoT - bridge between these worlds: listening to IP-852 UDP-packages on the ports of 1628 and 1629, processes them through its LonTalk-stack stack and broadcasts commands to field devices. Both vulnerabilities are in the parser of the IP-852 packets.

IP-852 - plain UDP. No TLS, no message authentication, no packet signature. Anyone capable of sending a UDP package to port 1628 SmartServer can try the attack. The situation is one-on-one as with Modbus, where functions (FC1 - Read Coils, FC3 - Read Holding Registers, FC5 - Write Single Coil, FC6 - Write Single Register) fly without authentication. Protocols from the era of air-gapped networks did not lay malicious traffic - and now they are sticking out in IP.
CVE-2026-20761 - pre-auth RCE: command injection in EnOcean SmartServer
CVE-2026-20761 - CWE-77 (Improper Neutralization of Special Elements) used a Command) in EnOcean SmartServer IoT version 4.60.009 and earlier. According to the NVD description - remote execution of arbitrary OS commands through specially formed IP-852 messages.

CVSS: 8.1 (HIGH), CVSS vector:3.1/AV:N/AC:H/H/H/H/H/H/H/A:H/H/A:H/A:H/H:H/A:H

What is behind each component of the vector:
• AV:N - attack over the network, physical access is not needed
• AC:H - high complexity: you need to know the IP address and the port of the SmartServer configuration server
• PR:N - privileges are not needed (pre-auth)
• UI:N - User interaction is not needed
• C:H/I:H/A:H - complete compromising confidentiality, integrity and availability
By CISA SSVC (from the publication Claroty Team82), technical impact - Total. None has been activated (exloitation: none), the automation of the attack is assessed as impossible (automable: no).
Attack chain: three UDP-package up to root
According to Claroty Team82, vulnerability is in the function LtSetTimeZone Libraries libLonStack.so. The function takes a line with the name of the time zone from an incoming IP-852 packet, sculpts from it shell-command and feeds system() with root-privileges. Verification - only which the Binary set-timezone.
Full SmartServer chain of operation - three steps:

Step 1 is reconnaissance. Attacking Sends request PKTTYPE_REQDEVCONFIG (a type of package 0x63) on UDP port 1628. SmartServer responds with a package PKTTYPE_DEVCONFIG (type 0x71) with IP address and port of the configuration server. Authentication is not needed - this is the standard behavior of the IP-852 protocol. Just ask, he'll tell you.

Step 2 - Impersonality of the configuration server. Of the data obtained, the attacker forms an IP-852 packet with an extended CNIP head (extended header size = 0x03, +12 bytes). The extended title contains the fields of the Local IP, NAT IP and IP Port configuration server. SmartServer parsite CNIP title and puts the flag bFromCfgServer = True The package is considered legitimate.

Step 3 - command injection. In the timezone package field PKTTYPE_ECHCONFIG (type 0xF3, vendor 0x01) inserted a line that breaks shell quotes. With the installed flag bUseTZ SmartServer calls LtSetTimeZone, which transmits payload in system(). The team is performed with root-privileges.

A detail that makes you think: a function LtSetTimeZone not available in open-source code LonTalk stack on GitHub EnOcean. She lives only in a compiled library libLonStack.so on the device. The source code review is useless here - you need a binary analysis of the firmware through Ghidra or IDA Pro. Team82 found her that.
Preconditions and Restrictions of Operation
Works if:
• SmartServer IoT version 4.60.009 or earlier
• UDP port 1628 or 1629 is available to the attacker
• IP-852 protocol is active (default - included)
Does not work if:
• Firmware updated until v4.60.023 or higher
• UDP ports 1628/1629 are closed by firewall on the perimeter or boundary of the BMS segment
• SmartServer in an isolated VLAN without routing to attack
Context of application: the attack is carried out both from the external network (if the ports are entangled or SmartServer sticks to the Internet), and with an internal pentest of the OT segment - from a compromised engineering station or through an insider with network access to BMS subnet. High complexity (AC:H) is due to the need to obtain the address of the configuration server, but this step is automated by one UDP-query PKTTYPE_REQDEVCONFIG. In fact, AC:H is a formality here.
Kill chain and mapping MITRE ATT&CK for ICS
CVE-2026-22885 - memory leak and bypass of ASLR in EnOcean SmartServer
CVE-2026-22885 - CWE-125 (Out-of-Buss Read) in the same versions of the SmartServer IoT. According to NVD - memory leakage from the address space of the process through specially generated IP-852 messages.

CVSS: 3.7 (LOW), CVSS vector:3.1/AV:N/AV/AC/C:N/I:N/I:N/I:N/A:N/A:N

3.7 - at first glance nonsense. But CISA SSVC puts a technical impact partial (exploitation: none, automatable: no). EPSS - 0.0037 (percentage 28.77%).

Mechanism: According to Team82, the bug sits in the IP-852 headline parser. The attacking sends time synchronization package with a swunch overward field extended header size. The non-standard value causes the controller to read data outside the selected buffer on the stack and send them back in the response package. Classic OOB read.
Two CVE Bundle: RCE Strengthening through Expression
Dishesive data may contain pointers to runtime libraries. Knowing the address of at least one function, the attacker calculates the basic address of the library and bypasses ASLR - randomization of the address space.

Separately, each CVE is a limited risk. In a bunch, it's another matter.

In the OT, it is more dangerous than in IT: BMS controllers work for years without rebooting. If the SmartServer process has not been restarted (update, crash, watchdog), the memory layout is stable - the leaked addresses remain relevant for months.
How BAS protection is different from IT: OT safety of industrial systems
Building automation systems are sitting in a blind zone. They are OT by all indications (manage physical processes, affect the safety of people, work on legacy protocols), but fall out of both IT-security parameters and classic OT programs.
Corporate EDR - CrowdStrike Falcon, SentinelOne, Kaspersky EDR Expert - is not put on the GNU/Linux-based controller SmartServer. SIEM does not parse IP-852 packets. To monitor BMS traffic, you need OT platforms (Claroty, Nozomi Networks, Dragos), which are able to disassemble LonTalk, BACnet and related industrial protocols.

In practice, it's still getting worse. According to Claroty, most organizations do not have a complete inventory of BMS devices. The controller, delivered during the construction of the building 10-15 years ago, can sit in the corporate network without segmentation, without monitoring, with default on the web interface. The compromise scenario through a compromised engineering station or a laptop of an operationler turns the “internal” attack into a trivial task: three UDP packets from the corporate network to port 1628.
Thrown devices and the surface of the attack
According to Claroty Team82, vulnerabilities affect:
• EnOcean SmartServer IoT - versions 4.60.009 and before
• Potentially legacy controllers Echelon i.LON 100/600 - total LonTalk-stok, requires confirmation from the vendor
• Devices that implement CEA-852 with proprietary Echelon packet types
To assess the external exposure:
Bash:
nmap -sU -sV --version-intensity 9 -p 1628,1629 <target_range>
Any device that responds to UDP queries on ports 1628/1629 is potentially vulnerable to the version of the firmware of 4.60.009 and earlier (on the NVD).
BAS Vulnerabilities Techniquer: From Immediate Actions to Strategy
EnOcean has released SmartServer 4.6 Update 2 (v4.60.023)closing both vulnerabilities. Claroty has published technical details. Below is a checklist suitable for transfer to operation or inclusion in the audit report.
Immediate action (24-48 hours)
1. Update SmartServer IoT to v4.60.023 or higher. Pre-auth RCE with published technical details of operation - delay is not an option here
2. Conduct an inventory of BMS controllers. Interview the operation service: IT department often does not know that SmartServer and i.LON are generally in the infrastructure
3. Lock UDP 1628/1629 on the perimeter firewall and on the border of the BMS segment
4. Check out the external exposure - scan your IP bands via Shodan/Censys on IP-852/LonTalk services
 
Top Bottom