I’d wrote about this in on my old site, I didn’t do a great job of migrating, but this is a useful tip for IT/Infosec concerned about application security in their infrastructure (not to be confused with ‘appsec’ web apps/API’s I mean installing programs internally, on Windows, and it’s also useful if you’re on the offensive side and you aint got much to work with.
The Skinny
When a program is installed and that program requires admin rights it tends to traditionally be installed in Program Files, or Program Files x86 and when the program is finalising it’s installation it applies access controls via inheritance from those traditional locations, basically it’s inheriting ACL’s that allow only admin and elevated accounts can write and delete in these places, all can read and copy but no write, no delete.
The problem is, this inheritance is issued from a relative address (parent) not an absolute C:\Program Files\, what that means is the installer assumes the folder above the program is Program Files, or Program Files x86 etc … but doesn’t factor in during the installation process it affords the person installing the opportunity to change the installation site, let’s say for example you had storage concerns on C:\ so you decided to stick it in D:\ the permissions will be completely useless opening up attack surface to overwrite, patch or position binaries within those folders for other bugs developers haven’t cleaned up or defended against.
Remediation:
The best I have means that the alternative install location has to be NTFS formatted filesystem, (I think)
Get-Acl -Path C:\Program Files\ | Set-Acl -Path D:\NewLocation
Why am I writing about this ?
It’s yielded me over $7k in bug bounties for those programs that truly care about their software (lots don’t)
