Shulou(Shulou.com)05/31 Report--

This article introduces what the Windows Java Usage Tracker local rights loophole analysis is, the content is very detailed, interested friends can refer to, hope to be helpful to you.

Preface

Recently, we discovered a design flaw in Java Usage Tracker that could cause an attacker to create arbitrary files, inject specified parameters, and escalate local privileges. Instead, the vulnerability can be used for privilege escalation, allowing an attacker to access resources in the system affected by the vulnerability, which are usually protected or limited to specific applications or users.

We fixed this vulnerability through Zero Day Initiative in cooperation with Oracle, which was fixed in the October 2018 update of Oracle. Therefore, individual users and businesses need to be urged to update their Java versions as soon as possible.

In this article, we will take an in-depth look at the cause of this vulnerability on Windows, how Java Usage Tracker works, and the conditions necessary for vulnerability exploitation.

Oracle security update bulletin: https://www.oracle.com/technetwork/security-advisory/cpuoct2018-4428296.html.

Java Usage Tracker

In Java, there is a feature called JavaUsage Tracker that tracks how Java is used in the system. Java Usage Tracker has the following features:

1. Log information about the Java virtual machine (JVM) through the startup configuration parameters.

Dump the data to a log file or redirect it to the UDP server.

3. Allow log values of custom attributes to be specified in the Usage Tracker configuration.

The configuration file name for Java Usage Tracker is usagetracker.properties. The file is located in the global default location, which varies depending on the operating system. For example, the default path for Windows is% ProgramData%\ Oracle\ Java\. The usagetracker file in the global default path tracks the usage of all started JVM on the system.

The following figure shows an example of usagetracker.properties:

In line 9 of the figure above, we can see that JavaUsage Tracker records the log information to the file global_javatracker.log. In the case of a system that installs Apache Tomcat, an Java-based open source tool, when the service is restarted, the file global_javatracker.log is created and Java usage tracking data is written to it. Each time the Tomcat service starts, new trace information is written to the log file.

The following figure is an example of trace data. Notice how two different values are separated by commas, which are defined in the properties file (delimiter configuration).

Parameters controlled by the user

In the file usagetracker.properties, there are two attributes that control the behavior of the Java Usage Tracker, namely:

Oracle.usagetracker.logToFile

Oracle.usagetracker.additionalProperties

The logTofile property allows the user to select any path in the system to save the log file. It is important to note that the log files are created by the monitored JVM. If JVM runs with elevated privileges, JVM can create the file anywhere on the system with an uncontrolled file extension (that is, you can create a log file named global_javatracker.bat).

Although the logToFile path can be set arbitrarily, the contents of the file cannot be controlled. Because JVM only writes values from existing data (which cannot be modified). However, Java Usage Tracker has a special feature to get values from custom properties. AdditionalProperties can contain any and other custom attributes to track, as shown below.

How to add custom attributes through additionalProperties:

After restarting the Tomcat service, how to track the code snippet of the data:

As shown in the figure above, a configured trace property com.anotherInterestingProperty= null with a null value is appended to the end of the line. Its value is null, indicating that the property does not exist. There are two ways to control the behavior of Java Usage Tracker: set any log path or set any custom properties. Currently, this feature does not seem to be exploitable, but if combined with other security vulnerabilities, it can be exploited by attackers.

Exploit vulnerabilities with custom attributes

Below, we will explain in detail how to exploit vulnerabilities with custom attributes. Line 9 in the previous configuration file causes Java Usage Tracker to force the creation of .bat files, and then add the custom attribute ping 172.0.1.1 >. It generates the file global_javatracker.bat, as shown in the following figure.

Custom attributes in global_javatracker.bat:

Global_javatracker.bat is being executed:

Here, you need to note the additional attribute ping 172.0.1.1 > = null. When we execute the batch file global_javatracker.bat, the error message "VM start" is not recognized. The reason for this error is that Java Usage Tracker's properties file generates only one line, and its delimiter is determined based on the com.oracle.usagetracker.separator=, in the configuration, using a comma as the delimiter.

Then, if you change the delimiter to "new line" (a new line), a completely different trace log will be generated.

JavaUsage Tracker with "new line" delimiter:

The trace log generated after using the "new line" delimiter:

The last line in the figure above contains ping 172.0.1.1 > = null. If you run global_javatracker.bat, it causes the ping172.0.1.1 > = null command to be executed. However, the command is not recognized because of the double quotation marks. However, we still have a chance to execute this command, because the double quotation marks of each attribute value can be replaced by modifying another configuration com.oracle.usagetracker.quote = ".

For example, let's create a com.oracle.usagetracker.quote configuration with empty content, as shown in the following figure.

Com.oracle.usagetracker.quote with empty content:

Use an empty configuration to configure the trace log generated from com.oracle.usagetracker.quote:

Running global_javatracker.bat will execute the command ping 172.0.1.1 > = null. As shown at the end of the command prompt in the figure above, a "null" file is created.

At this point, we can use Java Usage Tracker to do the following:

1. Create files anywhere on the file system.

2. Create a script file. Although we created a batch file in the example, it can actually be used to create other types of files.

3. Inject any command (or any other text related to the script file).

An attacker can execute or create the above anywhere on the system, or a file that can be scripted. However, if an attacker wants to successfully exploit this vulnerability to do something, he needs two more conditions:

1. Malicious files need to be created in key locations (such as automatic startup scripts).

2. You need to have access to key locations, and malicious files should be created by highly privileged processes.

In fact, both of these conditions can be achieved. For example, you can create a Java UsageTracker configuration (usagetracker.properties) for unprivileged users, and a process with higher privileges is responsible for creating malicious log files (UsageTracker logs).

Create a Java Usage Tracker log file

If you save to the global configuration path (for example,% ProgramData%\ Oracle\ Java of Windows), the Java Usage Tracker log file is read when the system starts JVM. Next, let's take the default Tomcat installation as an example. After installing Tomcat and using global usagetracker.properties, trace logs are created after Tomcat restarts (as shown in the following figure). In fact, the file is created by the Tomcat service and run by System by default.

Currently, the Tomcat service is already running by System, so it is possible to create a malicious file global_javatracker.bat anywhere. However, the profile usagetracker.properties must also be created by an unprivileged user.

The trace log created after installing Tomcat:

Log files created by Tomcat:

Local privilege escalation

The global configuration files for Java Usage Tracker are created in the default path% ProgramData%\ Oracle\ Java\. Some of the content in this path is created during the Java installation, and some is created when the Java command is executed (for example, java-c).

By default, the% ProgramData% path only allows the system's "Users" to create files. When an Oracle or Java path is established, the default permissions of the parent path are also inherited. The following is a screenshot of% ProgramData%\ Oracle\ Java\ permissions:

Let's give an example to further illustrate this loophole. A user with low privileges can create a malicious profile usagetracker.properties. Because the Tomcat service runs with "System" permissions, it can create batch files anywhere on the system. In a batch file, you can include routines such as writing scripts to the startup location.

At present, attackers can achieve privilege escalation by abusing the functions of Java Usage Tracker in a variety of ways. Our research was only tested in the Windows environment, but other operating systems may also be affected by this vulnerability.

In order to achieve privilege escalation, attackers may combine to exploit some vulnerabilities, including:

1. Creation of any file type: this vulnerability can be implemented through the oracle.usagetracker.logToFile path. For example, you can create scripts similar to batch files.

2. Parameter injection: realized through oracle.usagetracker.additionalProperties configuration.

3. Local privilege promotion: achieved through weak permissions in% ProgramData%/Oracle/Java.

On the Windows Java Usage Tracker local rights loophole analysis is shared here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.