This isn't really about Nessus, they are just the example we will use. essentially the issue is because installers (usually inherit folder permissions from program files) and forget they offer users relocation, and those folder permissions do not follow them.
The majority of software installers I've played with inherit their folder permissions from the parent folder, and that's Program Files (x86) by default, (or maybe Program Files) to write to program files you need admin rights, so in turn if you install a folder to here it will inherit those permissions -
update Nessus and it will be fixed (published responsibly)
So what looks like an oversight or something that just hasn't been considered is that almost all software lets the user define an installation site, for example, how many people have been slapped for installing database software on C drive ? that later grinds the OS to a halt, or how many gamers put software on D because their primary drive is a smaller SSD and they manage differently, anyway there must be a reason to allow the locations but what they are missing is having those folder permissions follow the changed location, and this is ripe for privilege escalation via a few methods at it's most basic a least privileged user (member of the Users group) can write to user defined installation sites and if you wanted to be fancier you could look for NAME_ NOT_ FOUND's or more fancy patch the exe's dll's but ... no need when you can just bluntly overwrite. (at the cost of the program not running, be kind back it up) .
NT AUTHORITY\SYSTEM has been achieved from about 80% of the software I have looked at (it get's boring after a while)
Tested on many Ent-Sec Software
This is useful to those of you who perform build reviews, thick client reviews, software reviews and those who are security conscious who install software on behalf of your organisation or self?!
Reaffirming that threat modelling every step of a process, understand it's reach and responsibilities is always worth doing at least once.
Let's look at Nessus (for example).
We will install it to
C:\Tenable this is a customised configuration, selecting another installation location...
This is the default Location
Changed to This location
No new information around permissions, risks etc...
And we are installing ... golden
Bring your own context, what we do know from the installation process is that there is no warnings, and no inherited security models when you move from the default location to another such as C:\Tenable\ or D:\Tenable or wherever that choice may be.
Now Nessus is installed flat on C: (i.e. not in program files), we can see what resources it's looking for via classic binary planting (unsigned .dll's and unsigned .exe's) we do this with procmon, we are looking for resources that return results
NAME NOT FOUND and the User is
NT AUTHORITY\SYSTEM with the goal as a low privileged user to position a file Nessus is asking for, in the right place so it consumes the file and executes it on the low privileged users behalf, executing as system AKA
Procmon.exe is going banana's, Nessus is looking for stuff that aint there... goody gumdrops.
In this demo we choose a .exe over a .dll it doesn't really matter that much but we will use
java.exe because it's being requested in a folder a low privileged user can write too as can see from Accesschk.exe.
A low privilege user being
Authenticated Users to write to
C:\Tenable and some of its child folders, from procmon above we can see that there are planting opportunities in
So let's log in as a low privileged user (AKA
Authenticated Users) and let's pop
C:\Tenable\Nessus\ and see if we get that file to be consumed by Nessus and Run as
Once this is done,it's a matter of it triggering now, so over to the admin user, we will restart Nessus and see if it accepts the unsigned malicious binary from the low privileged user and Nessus will run it with
NT AUTHORITY\SYSTEM privileges on the attacker/low privileged users behalf
here is a demo of the privesc taking place
In terms of l33tness it gets a 0.5, but the facts are these:
- The application installer allows for customised location installation with no security model on the folder to complement the controls in a default install
- a least privileged user/Guest can run malicious/unsigned files via Nessus to get
NT AUTHORITY\SYSTEMvia many of the same opportunities.
It would be interesting if this is something Microsoft can do as a fix, such as if it's an installation, inherit the permission model of program files
at best, a way to get system.
at least an interesting interview question.
Post install in the default location:
I've had mixed responses from this, some companies are grateful and others it's not something they care about, again each threat model is different. consider this in yours in context of installation considerations.
If the software allows you to install to a custom location, install it to
c:\your_softwareor anywhere outside of Program Files, D:\ W:hatever\
Once installed run Procmon with the settings noted above (Process Name, PID,Path, Result, User) and note those results from the exe's you're interested in and the file names they are requesting (dll's and exe's for this post), export your config, export your results (CSV might be easier for those receiving the issue).
In a terminal navigate to the c:\ and run icacls
your_software, this will list permissions information about the
your_softwarefolder copy it, save it, close it.
Create a low priv account on the OS, all you need is a member of Users
Log in as your low privilege user navigate to the folder ( I do a quick test of dragging a folder into the directory just a visual confirmation i can write to the folder)
Recreate a file name that is being requested, so if it's urlmon.dll or xmlPewpew.exe create that file, I use Cobalt Strike, so it's super easy to ready a 'payload' what you chose is upto you msfvenom will do the trick too or empire, Windows Defender might kick up a fuss if you dont consider that into this, a dll that won't flag up can be found here, download it, rename it plant it in the folder that is asking for it, you're done... now you wait.
You can overwrite or patch existing exe's too but that will/can impact the software doing it's thing.
Log back in as your higher priv user (the one that installed it) and run the app take note if it crashes, if it doesn't, and more importantly if it executes your file if it does ... welcome to privesc club if it doesnt, you can get low level and figure out why or you can move on to the next name in the list you exported from procmon.
good you have privesc, uninstall the app, install the app to it's default location and perform
icaclson the new location of
your_softwarecompare the differences save that information too
Contact the vendor, share your findings, make the world a better place -_-.
Again worth reading if you sell software and this is a problem you have 2010 Discussion on installation permissions
What's the fix ?
I'm not 100% sure where this issue exists in terms of patient zero/culprit ... , it might be in the installer wrapper, you know the thing that builds the installation process, or it could be that people are lazy and aren't RTFM, could be both but I think this post will help people clone the permissions it would have had, if it was in program files : John Dangerbooks's blog