In April 2021 we reported seven vulnerabilities in Broadcom Automic Automation (UC4) 12.3.5+hf.3. No CVE IDs were assigned to the issues yet.
The vulnerabilities have been found in the course of a research project, in which we analyzed the security of multiple Endpoint Management solutions. Similar vulnerabilities have been found in other solutions as we pointed out in previous posts about the Ivanti DSM Suite, Nagios XI, and Solarwinds N-Central. The outcome of the research project will be published as a whitepaper and a conference talk at Troopers 2022.
In this blog post we will provide a short description of the vulnerabilities outlining the impact. More technical details will be published in the whitepaper and conference talk. All vulnerabilities were found in Broadcom Automic Automation (UC4) version 12.3.5+hf.3.
Memory Leak
The UC4 agent discloses uninitialized memory from the stack when specific messages are received. The agent sends a response with a 4 KB buffer as the payload. The buffer is located on the agents stack memory and is not initialized prior to sending the response (similar to Heartbleed CVE-2014-0160). Therefore, large chunks of uninitialized stack memory are disclosed to a potential attacker on the network. The leaked data contains memory addresses which can be exploited to break Address Space Layout Randomization (ASLR). It may also be possible that sensitive data such as keys or passwords are disclosed.
The vulnerability can be exploited without authentication. The attacker only needs
access to the network port of the UC4 agent (default: TCP/2300)
System User Enumeration
The UC4 agent allows for operating system user enumeration via a custom UC4 protocol message. For a specific function in the handler module the existence of a given username is checked. If the user does not exist, the listener responds with the given username and the message “No such file or directory”. If the given user is an actual OS user in the target system, the listener process crashes and does not respond. The listener process is restarted immediately by the main agent process.
The parsing is performed in the ucxjlx6-listener process which runs with low privileges (user ‘nobody’). To exploit the vulnerability, an attacker does not have to be authenticated to the agent. The attacker only needs to be able to communicate with the listener port (default TCP port 2300) of the UC4 Agent.
RCE via Buffer Overflow
The UC4 agent contains a buffer overflow vulnerability in the function which parses a custom UC4 protocol messages. The function copies data from a received message into a buffer on the stack. However, the destination buffer on the stack is not big enough to fit the largest possible data field of the message.
If an attacker sends a message that is larger than the buffer size, the function overwrites data which is located after the buffer on the stack (e.g., the return address of the function). This can be exploited to gain control of the program flow of the agent.
The parsing is performed in the ucxjlx6-listener process which runs with low privileges (user ‘nobody’). To exploit the vulnerability, an attacker does not have to be authenticated to the agent. The attacker only needs to be able to communicate with the listener port (default TCP port 2300) of the UC4 Agent.
RCE via Custom Protocol Message
The protocol handler of a custom UC4 protocol message (TIMER_FIRE) takes an 8-byte value from the payload and uses it as a function pointer without further validation. This can be exploited by an attacker to gain arbitrary remote code execution in the agent process.
The parsing is performed in the ucxjlx6-listener process which runs with low privileges (user ‘nobody’). To exploit the vulnerability, an attacker does not have to be authenticated to the agent. The attacker only needs to be able to communicate with the listener port (default TCP port 2300) of the UC4 Agent.
RCE via Broken Authentication
The UC4 Agent allows the execution of system commands and jobs. If the Agent is configured with ‘LOGIN_CHECK=yes’, every command must provide a set of credentials for a local user account on the agent system.
It is possible to provide a username that exists on the target system but has no password set in the corresponding ‘/etc/shadow’ file. There are usually many users on a standard Unix system which fit this criteria (e.g., ‘bin’ or ‘nobody’). If such a user together with an empty password string is provided, the agent accepts the credentials as valid and executes the command.
For some commands it is necessary that the selected user has a valid login shell configured in ‘/etc/passwd’, otherwise the command is not executed correctly. Other commands do not have this restriction because it is possible to overwrite the user’s standard shell with a value provided in the payload.
This vulnerability can be combined with the privilege escalation that is described next.
Privilege Escalation
During the execution of jobs and potentially other tasks, the UC4 agent creates local files with root privileges and subsequently changes their owner to the respective user that is used to execute the actual job. The path and name of the created files is often directly controlled by a potential attacker who is therefore able to create files in arbitrary locations on the filesystem.
This primitive of creating files in arbitrary locations can be exploited to elevate privileges on the agent system. One possible example is to create a file in the ‘/etc/cron.hourly/’ directory which will be executed with root privileges every hour.
Low-entropy Encryption Keys
The AES encryption keys which are generated by the Automic AutomationEngine (UC4 backend) in default configuration have very low entropy due to a bug. These so-called transfer keys are distributed to the agents and are used for the encryption of traffic between agents and the backend.
The analysis of the generated transfer keys (stored encrypted on each agent system in the ucxjlx6.kstr file) has shown predictable patterns. The observed actual entropy of the generated keys was less than 24 bit. If an attacker has access to encrypted network traffic of a UC4 server it is possible to obtain the correct key by checking all possible key combinations (brute-force attack). Since OS credentials and other highly sensitive data is exchanged via the UC4 infrastructure, this poses a substantial threat.
Additionally, the UC4 server and agents use AES in ECB mode which is not recommended according to security best practices.
Summary
We highly recommend updating to the newest version. All of the above mentioned vulnerabilities have been fixed according to Broadcom.
—————————————————————————
This work has been conducted on behalf of the ERNW Research GmbH.
Disclosure Timeline
- 21.04.2021: Initial communication with vendor and start of 90 day disclosure period.
- 21.04.2021: Vendor acknowledges the receipt of the advisories.
- 13.05.2021: Vendor asks for a meeting to clarify on technical questions.
- 25.05.2021: Meeting with the UC4 developer team to clarify technical questions.
- 02.06.2021: ERNW provides detailed PoC scripts to reproduce the issues.
- 29.06.2021: Meeting with the Vendor to discuss CVE publishing process.
- 13.07.2021: Broadcom informs us that they are working on the fixes.
- 25.10.2021: ERNW inquires if all issues have been fixed and if CVEs have been assigned.
- 28.10.2021: Broadcom states they will assign CVE identifiers.
- 03.11.2021: ERNW inquires for the status again.
- 05.11.2021: Broadcom states they will select a disclosure date ASAP.
- 24.02.2021: ERNW inquires about the status on the CVEs and disclosure timeline.
- 21.03.2021: ERNW inquires about the status, stating that the findings will be presented on an upcoming conference.
- 23.03.2022: Broadcom states they believe all fixes are completed and that a security notice will be scheduled ASAP.
- 19.04.2022: ERNW inquires about the status of the disclosure sharing the date of the conference the issues will be disclosed on.