Introduction
Now and then I tend to run some of the excellent tools from Sysinternals. Recently, I noticed something odd. It seems like Windows was searching for executables and DLLs in a Java folder. What made it even more interesting was that this folder is located within the ProgramData folder. The default NTFS ACLs allows local user to create new files within this folder. These are ingredients for local privilege escalation.
Further investigation showed that this issue was introduced around the release of Java SE 8 Update 20 for Windows. I discovered that this issue was already addressed by a recent version of Java SE. I confirmed that Java SE 8 Update 40 removes the weak NTFS ACLs from the affected folder (it may have been addressed in an earlier version). Due to this it is no longer possible for local unprivileged users to creating new files in this folder. I performed some Google searches and could not find any information about this change/fix. I guess it must have been found internally by Oracle. In this article I'll explain how this issue can be used to escalate privileges locally.
Vulnerability details - unsafe JRE installation
When installing Java SE 8 on a Windows system, the installer will create the folder %ProgramData%\Oracle\Java\javapath (if it does not exist). The javapath folder contains symlinks to the executables java.exe, javaw.exe, and javaws.exe.
Figure 1: javapath symlinks to Java executables
The NTFS permissions are inherited from the parent folder. By default any local unprivileged user is allowed to create new files within the javapath folder. It is not possible to modify the Java symlinks.
Figure 2: NTFS permissions of Users group on javapath
Creating new files in javapath is not an issue per se. In this case it can result in code being executed as a different user. This is possible because the JRE installer not only creates the javapath folder, but this folder is also added to the PATH environment variable. It is even added as the first entry of the PATH. This means that when Windows searches PATH, Windows will look in javapath first!
Figure 3: javapath added to the PATH environment variable
Running code as a different user
Abusing this issue allows us to run our own executable code with the privileges of another (system) user. Process Monitor can be used to find applications that load executable code from the affected Java folder. We can create a filter in Process Monitor to only show path operations on the javapath folder. Potential targets are shown in the Process Name column.
Figure 4: using Process Monitor to find potential targets
Using this method we can find affected applications that are started by other users and also system processes (services) that are affected by this issue. I've chosen Windows Media Player and Microsoft Distributed Transaction Coordinator Service as target applications.
When Windows Media Player is started it will look for the DLL file rapi.dll in the PATH. If such a file is present in javapath, Windows Media Player will try to load this DLL. An attacker can place a malicious DLL named rapi.dll in javapath and wait for a user to launch Windows Media Player, causing the attacker's DLL to be executed with the privileges of that user. It may even be possible to trick a user to do so by sending this user a link/file that will cause Windows Media Player to be opened.
Figure 5: malicious rapi.dll loaded in Windows Media Player opening backdoor.exe
A similar attack is possible against the Microsoft Distributed Transaction Coordinator Service. The Microsoft Distributed Transaction Coordinator Service tries to load the DLL oci.dll from the PATH. It is possible to abuse this to run arbitrary code with NETWORK SERVICE privileges, as is shown in figure 6.
Figure 6: backdoor.exe running with NETWORK SERVICE privileges