Overview

In an effort to safeguard our customers, we perform proactive vulnerability research with the goal of identifying zero-day vulnerabilities that are likely to impact the security of leading organizations. Recently, we decided to take a look at Ant Media Server with the goal of identifying any vulnerabilities within the application. We performed testing against AntMedia Server by leveraging the official Ant Media Server images made available through the AWS marketplace targeting version 2.8.2 of the application.

During our analysis we identified a local privilege escalation vulnerability arising from the application exposing an unauthenticated Java Management Extensions (JMX) remote management interface on localhost that was accessible by unprivileged local operating system users. An attacker could then leverage access to the JMX remote management listener to execute code within the context of the “antmedia” service account and then leverage the account’s sudo privileges to elevate access to root on the system. Praetorian responsibly disclosed this vulnerability and it was assigned CVE-2024-32656.

Identifying the JMX Service Listening on Localhost

After configuring a local copy of Ant Media Server we then began performing enumeration of the installed programs, running processes, and listening network ports. We observed that the antmedia service was configured to start with JMX remoting enabled and authentication disabled (see Figure 1). However, the service was only configured to listen for connections on localhost meaning that the service would never be accessible remotely (see Figure 2).

Figure 1: We observed that the Ant Media Server application was configured to launch with Java Management Extensions (JMX) for Remote Management configured with authentication disabled listening on localhost.

Figure 2: We observed that the JMX remote management service was configured to listen on localhost on port 5599/TCP.

We performed fingerprinting and enumeration of the service running on port 5599/TCP using the rmi-dumpregistry script from Nmap. The JMX remote management service leverages the Java remote method invocation protocol as a transport for remote procedure calls (see Figure 3).

Figure 3: We observed that the JMX remote management service leveraged the Java Remote Method Invocation (RMI) protocol as a transport layer for making remote procedure calls to the JMX service.

After confirming the existence of the JMX remote management service running on port 5599/TCP we then need to confirm that authentication is not required to access the service. To confirm our hypothesis we leveraged the beanshooter utility to enumerate the installed MBeans within the JMX server. We observed that it was possible to authenticate to the JMX server without authentication (see Figure 4).

Figure 4: We then leveraged the beanshooter utility to enumerate installed MBeans.

Escalating Privileges to Root using JMX

We then leveraged the MLet MBean available through the JMX service to load a remote attacker-controlled MBean named TonkaBean from an attacker-controlled server running on localhost on port 1337/TCP (see Figure 5). This allowed us to execute arbitrary code within the context of the victim Java process running as the “antmedia” user account. Hans-Martin Muench outlines why it is possible for an attacker to load an MBean from a remote server into th JMX process when JMX is configured without authentication in his article Attacking RMI Based JMX Services.

Figure 5: We leveraged the MLet Mean interface to load a remote attacker-controlled MBean object called “TonkaBean” which allowed for execution of arbitrary shell commands within the victim Java process.  

After loading the malicious MBean we then performed enumeration of the JMX service again to confirm that our malicious TonkaBean MBean was loaded successfully (see Figure 6).

Figure 6: We verify that we successfully leveraged the MLet MBean to load our malicious TinkaBean MBean into the victim Java process. 

Next, we connected to the TonkaBean MBean now loaded within the JMX process and leveraged it to run arbitrary commands as the “antmedia” user account. We determined that the “antmedia” user was allowed to run any script named enable_ssl.sh as root and we leveraged this capability to run the “id -a” command to achieve root access on the system (see Figure 7).

Figure 7: We then leveraged the malicious TonkaBean MBean to execute arbitrary commands within the context of the “antmedia” service account user.

Conclusion

In this article, we discussed a local privilege escalation vulnerability we identified in Ant Media Server due to a JMX server deployed by the application without any prior required authentication. It’s definitely worth paying attention to JMX and RMI whenever you observe them being used within an application or network environment during a security test as these services are quite dangerous.