Local privilege escalation in Tenable Nessus Agent 6.10.3 (CVE-2017-7199)
During a pentest of a Win10 laptop environment, I struggled finding a privilege escalation avenue. Latest patches installed (no Tater/Potato here), GPO stored passwords, just signed SMB, hardened UNC paths, smartcard signon only, Bitlocker with secure boot and PINs, they've even removed the keyboard and the powerbutton! True story. Anyhow, I struggled.
Finding the bug
I had access to a backup local admin account that I could use for installing software, debugging and fix anything I might break when testing with the low-privileged account.After trying everything and failing any privilege escalation using the low-privileged account, I decided to use the admin account and Procmon myself to victory, hoping I would find a service that could load some DLL's in a lowpriv user-writeable directory. No avail. As a last resort, I enabled the bootlogging in procmon and rebooted, hoping there could be some vulnerable initialization-code performed by the services when they were started. And there it was. Sort of:
The nessusd.exe process, belonging to the Tenable Nessus Agent software, running as SYSTEM is trying to access java.exe in the plugins directory!!
Read more about the Nessus Agent software here: https://www.tenable.com/products/nessus/nessus-agents
Programdata ACL
Now, you might ask, can we write to the plugins directory? Yes we can!
The folder c:\programdata by default has the following ACL, thank you very much Microsoft!
C:\ProgramData NT AUTHORITY\SYSTEM:(OI)(CI)F BUILTIN\Administrators:(OI)(CI)FCREATOR OWNER:(OI)(CI)(IO)FBUILTIN\Users:(OI)(CI)RBUILTIN\Users:(CI)(special access:)FILE_WRITE_DATAFILE_APPEND_DATAFILE_WRITE_EAFILE_WRITE_ATTRIBUTES
This implies that unless the software creating a dir here changes the ACL, regular low privileged users can append files and directories in the subdirectories under c:\programdata. Sweet.
Creating c:\programdata\tenable\nessus agent\plugins\java.exe
C:\programdata\tenable had default inheritage, so this means we can write java.exe here. Lets try that! I wrote a simple add local user C# snip:using System;
class MainApp{
public static void Main() {
System.Diagnostics.Process.Start("cmd.exe","/C net users egiladmin SupahS3cr3t! /add");
System.Diagnostics.Process.Start("cmd.exe","/C net localgroup administrators egiladmin /add");
}
}
Thanks http://formatmysourcecode.blogspot.no/
I compiled using the builtin .NET compiler CSC.exe (again, thank you Microsoft) to java.exe in the plugins directory, and restarted the nessus agent service..
Yay.. it deleted the file. Now, this is where I would normally give up. But, I wasn't in my normal mood that day. So I didn't give up. First I tried setting a DENY ACE on the file, which the SYSTEM process gave f***all about - it deleted it nevertheless. I then proceeded to do something I seldom do anymore. Debugging.
After wasting some hours of my life in the debugger that I could have spent working out, contributing to the society or played guitar instead, I stumbled onto something. But before I continue, allow me to show you some debug pics I took after finding the unlink code. I post them because all pro vuln walkthroughs have pictures of assembly code. So here it is:
BTW - the debugger used is x64dbg (http://x64dbg.com/). I've used IDA with Windbg and also Olly before, but this blew my mind away. Clean, fast (search through memory was extremly quick compared to IDA/Windbg) and very intuitive to use.
As can be seen from the pics, the unlink function calls DeleteFileA, which MSDN implicitly says that isn't for removing directories (the RemoveDirectory function should be used for that), I thought. What if java.exe was a directory?
Java.exe as a directory
When java.exe is a directory, the following stuff happens:
Notice the last line? Java -version.exe ? That's a file just waiting to exist. Doing the CSC.exe routine again and restarting the service.... Ah. There's nothin' like the hot winds of privesc blowin' in your face.
I of course had the privilege of restarting the service at will, so to exploit this as a low-privileged user, you would have to trigger a restart of the service somehow. If the user has reboot privilege, a boot is all that's needed.
Further work
So why java -version.exe, and not java.exe -version? That's a nice cross-platform feature gone wrong - I suspect. I never wasted more hours in the debugger, but ate the cake instead. |
| Nothing tastes as sweet as zerodaycake. The other cake is for another vuln coming up soon |
What have I learned? Enable procmon bootlogging. There is interesting stuff happening at service startup!
Communication with Tenable
Tenable was exceptionally professional about this, and confirmed the vuln the same day I reported it. No bounty though, just fame and glory.
