- Регистрация
- 20.01.2011
- Сообщения
- 7,665
- Розыгрыши
- 0
- Реакции
- 135
Team82 has researched Для просмотра ссылки Войди или Зарегистрируйся and found multiple vulnerabilities in the EpicMo protocol implementation within ControlEdge Virtual UOC instances. These vulnerabilities are exploitable and can lead to unauthenticated remote code execution.
The vulnerabilities we found reside in the EpicMo protocol (TCP port 55565)—a proprietary protocol designed by Honeywell that is used to communicate between Honeywell Experion servers and controllers. This protocol contained an undocumented and dangerous function that enabled us to write files on Virtual UOC controllers without sanitation, which exposed the devices to the execution of unauthorized code. An attacker already on an OT network would use a malicious network packet to exploit this vulnerability and compromise the virtual controller. This attack could be carried out remotely in order to modify files, resulting in full control of the controller and the execution of malicious code.
Honeywell has updated Virtual UOC and users are urged to move to current versions. The Cybersecurity Infrastructure & Security Agency (CISA) has published an Для просмотра ссылки Войдиили Зарегистрируйся for Для просмотра ссылки Войди или Зарегистрируйся (CVSS v3 score: 9.1) and Для просмотра ссылки Войди или Зарегистрируйся (5.3). Honeywell has also published an Для просмотра ссылки Войди или Зарегистрируйся.
или Зарегистрируйся. The Для просмотра ссылки Войди или Зарегистрируйся includes built-in fault tolerant Ethernet, ModbusTCP, and EtherNet/IP. UOC is also offered as a virtual controller. The Virtual UOC decreases an enterprise’s hardware footprint because it does not require a physical controller. This is essentially a Linux-based virtual machine that can be installed in a virtual environment.
The VirtualUOC location on Honeywell DCS systems.
A UDP packet initiating EpicMo protocol communications.
After sending the UDP initialization message, one can start communicating over TCP. Each session starts with a TCP initialization message specifying the protocol again.
An EpicMo protocol struct, written in Python.
While researching the EpicMo protocol we discovered that the Virtual UOC implements different EpicMo function codes than the C300 controller.
EpicMo Command Handlers libepa.so
Two commands that caught our attention are LoadFileFromModule and LoadFileToModule. After researching these functions, we came to the conclusion that they enable arbitrary file-write and file-read to the virtual controller.
We discovered that this functionality allows users to supply an arbitrary path and data, and no validation or limitation exists on the given path. This means users can write files to all writeable locations on the controller, which is a security concern. By leveraging this functionality, attackers could achieve remote code execution on the controller, by writing executable files, for example.
In order to upload a file using the LoadFileToModule function code, we need to send at least three packets (start write, write data, finish write). Each packet starts with the regular EpicMo header.
LoadFileToModule start write command
The maximum length of the file data in a data command is 0x7F. If the data length is more than 0x7F it will be split into multiple packets where Upload Packet Number is updated accordingly.
LoadFileToModule final command
Final command is used to signal that the upload is finished.
When the Upload Packet Number is not 0 and the Data length is 0, it is considered as the final upload packet.
In order to send a valid LoadFileToModule start command, we need to include a checksum of the file. In order to calculate a file’s checksum, we implemented the following function that returns the correct checksum for a given file, below.
In order to demonstrate how an attacker might leverage this vulnerability to achieve remote code execution, we searched for writeable locations on the virtual controller. However, a few limitations existed:
Our code execution flow looks like this:
Finally, we were able to demonstrate a preauth RCE on a remote virtual UOC using CVE-2023-5389.
We found mechanisms with a function that enables possible remote code execution by writing files on Virtual UOC controllers without sanitization.
We found an undocumented and dangerous function that enabled us to write files on Virtual UOC controllers without sanitation. An attacker on the OT network could send malicious packets to the controller and write files without authenticating to the controller.
Team82 privately disclosed these vulnerabilities, CVE-2023-5389 and CVE-2023-5390, to Honeywell, which has addressed them in an Для просмотра ссылки Войдиили Зарегистрируйся.
Для просмотра ссылки Войдиили Зарегистрируйся
[/QUOTE]
The vulnerabilities we found reside in the EpicMo protocol (TCP port 55565)—a proprietary protocol designed by Honeywell that is used to communicate between Honeywell Experion servers and controllers. This protocol contained an undocumented and dangerous function that enabled us to write files on Virtual UOC controllers without sanitation, which exposed the devices to the execution of unauthorized code. An attacker already on an OT network would use a malicious network packet to exploit this vulnerability and compromise the virtual controller. This attack could be carried out remotely in order to modify files, resulting in full control of the controller and the execution of malicious code.
Honeywell has updated Virtual UOC and users are urged to move to current versions. The Cybersecurity Infrastructure & Security Agency (CISA) has published an Для просмотра ссылки Войди
What is Honeywell Virtual UOC?
Honeywell is a significant player in the industrial control system (ICS) market, offering an extensive array of controllers for industrial automation. One product is the Honeywell Control Edge Unit Operations Controller (UOC), a modular physical controller that extends the Для просмотра ссылки ВойдиThe VirtualUOC location on Honeywell DCS systems.
Multiple Virtual UOC Communication Protocols
Honeywell controllers use multiple protocols for communications. A service called NameServer is responsible for routing and opening communications for all protocols. In order to start communication over a specific protocol, we first need to send a UDP message to the NameServer service (over UDP port 12321) specifying which protocol that will be used.A UDP packet initiating EpicMo protocol communications.
After sending the UDP initialization message, one can start communicating over TCP. Each session starts with a TCP initialization message specifying the protocol again.
EpicMo Protocol
The EpicMo protocol (TCP port 55565) is used for debugging and diagnostics of Honeywell controllers. It includes function codes such as ReadMemory, WriteMemory, Reboot and ReadCrashBlock, which allow for error detection and debugging.Protocol Structure
| Sequence Number | Packet Length | Number of Packets Received | Number of Packets Sent | Function Code |
| 2 bytes | 2 bytes | 2 bytes | 2 bytes | 1 byte |
- Sequence number: A sequential number for the packet.
- Packet Length: Length of the packet.
- Number Packets Received: Counter for the number of packets received.
- Number Packet Sent: Counter for the number of packets sent.
- Function Code: The function code the client desires to invoke.
An EpicMo protocol struct, written in Python.
While researching the EpicMo protocol we discovered that the Virtual UOC implements different EpicMo function codes than the C300 controller.
EpicMo Command Handlers libepa.so
Two commands that caught our attention are LoadFileFromModule and LoadFileToModule. After researching these functions, we came to the conclusion that they enable arbitrary file-write and file-read to the virtual controller.
CVE-2023-5389:
From File Write to preauth RCE via LoadFileToModule
(Command 0x51)
LoadFileToModule allows users to write files to the controller. One of the parameters this function receives is a Destination_Path, which is the path the given file will be written to.We discovered that this functionality allows users to supply an arbitrary path and data, and no validation or limitation exists on the given path. This means users can write files to all writeable locations on the controller, which is a security concern. By leveraging this functionality, attackers could achieve remote code execution on the controller, by writing executable files, for example.
In order to upload a file using the LoadFileToModule function code, we need to send at least three packets (start write, write data, finish write). Each packet starts with the regular EpicMo header.
LoadFileToModule start write command
| File Type | Upload Packet Number | Unknown | File Data Checksum | File Data Length | Destination Path |
| 1 Byte | 4 Bytes | 2 Bytes | 4 Bytes | 4 Bytes | String |
- File Type: Firmware file or generic file. 0x05 is used for generic file
- Upload Packet Number: Packet number in the upload sequence. The first packet is 0.
- File Data Checksum: Checksum for the entire file data
- File Data Length: Length of the entire data
- Destination Path: The name of the file to save on the controller
The maximum length of the file data in a data command is 0x7F. If the data length is more than 0x7F it will be split into multiple packets where Upload Packet Number is updated accordingly.
| File Type | Upload Packet Number | Data Length (0x7f max) | Data |
| 1 Byte | 4 Bytes | 2 Bytes | n-Bytes |
LoadFileToModule final command
Final command is used to signal that the upload is finished.
| File Type | Upload Packet Number | Data Length: Must Be 0 |
| 1 Byte | 4 Bytes | 2 Bytes |
When the Upload Packet Number is not 0 and the Data length is 0, it is considered as the final upload packet.
In order to send a valid LoadFileToModule start command, we need to include a checksum of the file. In order to calculate a file’s checksum, we implemented the following function that returns the correct checksum for a given file, below.
In order to demonstrate how an attacker might leverage this vulnerability to achieve remote code execution, we searched for writeable locations on the virtual controller. However, a few limitations existed:
- Files uploaded using LoadFileToModule do not have the UNIX execute attribute
- All files that are mounted to /usr/honeywell are mounted as read-only and this directory is not writeable.
Our code execution flow looks like this:
- Compile libcap.so.2 with our payload set to run at startup
- Use the LoadFilefromModule to write file to /lib/libpcap.so.2 on the controller
- Call the Reboot command in order to ensure a reload of libcap.so.2
Finally, we were able to demonstrate a preauth RCE on a remote virtual UOC using CVE-2023-5389.
Conclusion
Proprietary protocols such as Honeywell’s EpicMo used for communication between Honeywell Experion servers and controllers often contain vulnerabilities that can put industrial processes at risk for manipulation or disruption.We found mechanisms with a function that enables possible remote code execution by writing files on Virtual UOC controllers without sanitization.
We found an undocumented and dangerous function that enabled us to write files on Virtual UOC controllers without sanitation. An attacker on the OT network could send malicious packets to the controller and write files without authenticating to the controller.
Team82 privately disclosed these vulnerabilities, CVE-2023-5389 and CVE-2023-5390, to Honeywell, which has addressed them in an Для просмотра ссылки Войди
Для просмотра ссылки Войди
[/QUOTE]