Exploits & Vulnerabilities
Analyzing the CVE-2018-3211 Vulnerability
We found a design flaw/weakness in Java Usage Tracker that can enable hackers to create arbitrary files, inject attacker-specified parameters, and elevate local privileges.
Save to Folio
We found design flaw/weakness in Java Usage Tracker that can enable hackers to create arbitrary files, inject attacker-specified parameters, and elevate local privileges. In turn, these can be chained and used to escalate privileges in order to access resources in affected systems that are normally protected or restricted to other applications or users
We’ve worked with Oracle through our Zero Day Initiative to patch this flaw, and this has been fixed via Oracle’s October patch update. Users and businesses are accordingly urged to patch and update their version of Java. In this blog post, we will delve into how this flaw works on Windows — how Java Usage Tracker works and defining the conditions that enabled the exploit. Java Usage Tracker Java has a functionality called Java Usage Tracker that tracks how it is used in systems where it is installed. Java Usage Tracker has the following functionalities:
- Log information about the Java virtual machine (JVM) start up configuration parameters.
- Dump the data into a log file or redirect it to a UDP server.
- Allow log values for custom properties specifying them in the Usage Tracker configuration.
Java Usage Tracker uses a configuration file named usagetracker.properties. The file has a
global default location depending on the operating system (OS). For example, the default path for Windows is: %ProgramData%\Oracle\Java\. The usagetracker file in the global default path will track the usage of all JVMs initiated in the system. The following image shows an example of usagetracker.properties:
Figure 1: Snapshot showing an example of usagetracker.properties
As specified in line 9 in Figure 1, Java Usage Tracker will log information into the file global_javatracker.log. Take a system with Apache Tomcat (an open-source, Java-based tool) installed as an example. Once the service is restarted, the file global_javatracker.log is created and the Java usage track data is appended. New track information is appended to the end of the file every time the Tomcat service starts. The following image shows an example of tracked data. Note how values are separated by a comma as stated in the properties file (separator configuration).
Figure 2: Snapshot showing how track data is appended to global_javatracker.log in Tomcat
User-controlled parametersThe file usagetracker.properties has two interesting properties for controlling the behavior of the Java Usage Tracker:
- oracle.usagetracker.logToFile
- oracle.usagetracker.additionalProperties
The logTofile property allows users to select any arbitrary log file path in the system. It is important to note that the log files are created by the JVM being monitored. If the JVM is running with elevated privileges, then JVM is able to create the file in any part of the system. The file’s extension is also not controlled (i.e., it is possible to create log file named global_javatracker.bat). Even if the logToFile path can be set arbitrarily, the content of file cannot be controlled because the JVM will just write values from existing, non-controlled data. However, Java Usage Tracker has a special feature for getting values from custom properties. additionalProperties supports the inclusion of arbitrary and additional custom properties to be tracked. The following image shows an example:
Figure 3: Snapshot showing how custom properties can be added via additionalProperties
Figure 4: Code snippet showing how data is tracked after restarting the Tomcat service
As shown in Figure 4, the end of the line is appended with a configured, tracked property with null value, com.anotherInterestingProperty=null. The property value is null, which means the property doesn’t exist. There are two ways to control the behavior of Java Usage Tracker: Setting an arbitrary log path, and setting an arbitrary custom property. Such a combination seems unexploitable, but it can be exploited when used in conjunction with other security flaws or weaknesses.
Exploiting custom propertiesHere is an example showing how the custom properties can be exploited. As shown in Figure 5, the previous configuration file in line 9 will force Java Usage Tracker to create a .bat file, then add the custom property: ping 172.0.1.1 >. The corresponding generated file is global_javatracker.bat as shown in Figure 5.
Figure 5: Snapshot showing the custom properties in global_javatracker.bat
Figure 6: Screenshots showing global_javatracker.bat being executed
Note the appending property ping 172.0.1.1 >= null. If the batch file global_javatracker.bat is executed, it will display the error message “VM start” is not recognized. This error occurs because Java Usage Tracker’s property file is generating only one line, set by the configuration (comma separator) com.oracle.usagetracker.separator = ,. Changing the separator to “new line” generates a different tracking log (Figure 8).
Figure 7: Java Usage Tracker with the “new line” separator (highlighted)
Figure 8: Tracking log generated after using a new line separator
Figure 8 shows all the values in a new line, with the last line containing ping 172.0.1.1 >= null. Running global_javatracker.bat will result in the execution of ping 172.0.1.1 >= null, but because of the double quote, the command is not recognized. However, there is a chance to execute it because the double quote surrounding every property value can be controlled by another configuration, com.oracle.usagetracker.quote = ". For example, let’s create an empty com.oracle.usagetracker.quote configuration, as shown in Figure 9.
Figure 9: Snapshot showing com.oracle.usagetracker.quote with empty configuration
Figure 10: The tracking log generated from com.oracle.usagetracker.quote with empty configuration
Running global_javatracker.bat will execute the command ping 172.0.1.1 >= null. As shown in the end of the command prompt (cmd) image in Figure 10, a “null” file is created. Up until this stage, the Java Usage Tracker:
- Can be abused to create files in any arbitrary location in the file system.
- Can be abused to create text scriptable files. The example uses batch files, but it can also be used to create other file types.
- Can be abused to inject arbitrary commands (or any other text related to the scriptable file).
A combination of the above as well as a scriptable file can be carried out/created in any place in the system. However, to successfully exploit it, there are conditions:
- The malicious file should be created in a critical location (i.e., auto start scripts).
- To access a critical location, a process with high privilege should create the malicious file.
Both conditions can actually be accomplished. For example, the Java Usage Tracker’s configuration (usagetracker.properties) can be created for a non-privileged user and the malicious log file (usage tracker log) is created by a process with higher privileges.
Java Usage Tracker log file creation
When residing in the global configuration path (i.e., %ProgramData%\Oracle\Java in Windows), the Java Usage Tracker log file is read for JVM when it is started in the system. Let’s take the default Tomcat installation again as an example. Once Tomcat is installed and the global usagetracker.properties is in place, the tracker log is created after restarting Tomcat (Figure 11). As shown in Figure 12, the file is created by the Tomcat service running by default as System. Since the Tomcat service is running as System, the malicious file global_javatracker.bat can be created in any arbitrary location. However, the configuration file usagetracker.properties must be created by a non-privileged user.
Figure 11: Tracker log created after Tomcat is installed
Figure 12: Snapshot showing the log file created by Tomcat (highlighted)
Local privilege escalation
The global configuration file for Java Usage Tracker is created in the default path %ProgramData%\Oracle\Java\. This location and the initial content is created during Java’s installation, but is also created as a consequence of executing a Java command — for example, java –c. The default permission %ProgramData% allows “Users” of the system to create a file. When Oracle/Java’s path is created, the default permissions are inherited. Figure 13 shows the permissions for %ProgramData%\Oracle\Java\. This affects multiple Java versions — probably ever since Java Usage Tracker was created.
Figure 13: Screenshots showing permissions granted for %ProgramData%\Oracle\Java\
To exemplify an exploit for this: A user with low privileges can create a malicious configuration file usagetracker.properties and the Tomcat server can create the batch file in any location of the system because it is running with “System” privileges. The batch file can include routines like writing to start-up scripts’ location, etc.
Conclusions
The Java Usage Tracker functionality can be abused in multiple ways to escalate privileges. Our research was only tested in a Microsoft Windows environment, but other systems could also be vulnerable. An attack leading to privilege escalation could use a chain of weak design flaws that can be considered as different vulnerabilities:
- Arbitrary File Type Creation: This can be done through the oracle.usagetracker.logToFile path. For example, a scriptable file can be created like a batch file.
- Parameter Injection: This can be carried out through the oracle.usagetracker.additionalProperties configuration.
- Local Elevation of Privilege: This can be done through weak permissions in %ProgramData%/Oracle/Java.
Trend Micro Solutions
Trend Micro™ Endpoint Security shields endpoints from identified and unknown vulnerability exploits before patches are even deployed. Trend Micro’s endpoint solutions such as Trend Micro™ Smart Protection Suites and Worry-Free™ Business Security protect end users and businesses by detecting and blocking malicious files, all related malicious URLs, and threats that may abuse and exploit CVE-2018- 3211.