Jake Williams works for Rendition Infosec and is a former NSA TAO operartor that’s brining us some knowledge on Windows privilege escalation tricks today. This is a sequel to last year’s Linux Privilege Escalation Tricks talk that Jake gave last year at WWHF. No zero days, just tried and true methods for privilege escalation.
Quick Rant
Hacker culture is not infosec culture and the difference isn’t between white hat and black hat. Infosec has a job to do (securing stuff) and sometimes it’s okay to just push the magic button and hope everything works. We got hacker culture by actually understanding how things work at a very low level (the rules) and then systematically breaking the rules. The “hacker culture” is dying because too many people today just want to push the magic button… Let’s reverse this course.
Agenda
We’ll be going over general misconfigurations, specific misconfigurations related to %PATH% hijacks, services, installation flags, unattended.xml, sysprep, upgrades (system permissions are everything!), and uninstalled software that really isn’t uninstalled.
Why Focus on Misconfigurations
Misconfigurations are endemic and harder to detect with unauthenticated vulnerability assessments. As such, most of this talk will focus on misconfigurations commonly found in enterprise environments. While unpatched binary vulns and 0 days are fun, too many pen testers today rely on them for 100% of privilege escalation. There are FAR more misconfigurations than vulns and vulns will be detected and patched by Nessus, Nexpose, etc. However, misconfigurations are typically missed by scanners.
Misconfigurations FTW
Many of the misconfigurations we discuss are actually recommended by training that system admins take. Remember that here, we’re in the security echo chamber. While security is all about Confidentiality, Integrity, and Availability, most infosec professionals have a confidentiality fetish and most system admins have only one–availability. Configurations that help availability are the ONE thing that matters most to IT personnel. Add these other things discussed during this contalk to the job responsbilities.
NTFS Filesystem Permissions to Look For
NTFS offers more than just Read, Write, and Full Control. A number of “special permissions” are generally of more concern than general permissions. Create files / write data and create folders / append data are two special permissions to analyze in particular. These permissions are only revealed from the main interface with a general “special permissions button”. We can use icacls to enumerate this.
- Delete: does removing a config fule default to generic configs?
- Write Data/Add File: add a DLL that is sideloaded into an applicaiton with elevated privileges
- Write Attributes: set file attributes to hidden or system, potentially hiding them from view by most users
- Append Data: Allows the user to add data to end of a file, but not overwrite any existing data.
- Change Permissions: this is pretty much full control.
A good way to find these vulnerabilites involves just downloading commerical packages, installing them, and then analyzing the permissions of the directories created by the installation package and MSI Build install scripts.
#do we see WD (write data) and AD (append data) with the BUILTIN\Users group?
icacls C:\CustomApp\
#show all hidden and system files
dir /a
Registry Permissions
Registry keys have permissions, but the values do not. While we find poor directory permissions regularly, finding registry keys writeable by the Authenticated Users group is more unusual. However, if a registry key or value that controls the execution of a privileged process has write permissions, we can run our code with elevated permissions. Don’t forget to check plugins, you may be able to add a DLL! For a proxy DLL, export every function originally performed.
Registry Permissions 2
The subinacl tool can be used to get permissions on registry keys, which is not normal behavior.
#part of the Windows resource kit
subinacl /keyreg HKEY_LOCAL_MACHINE\software\microsoft
# every permission has a bit mask, so powershell "helps" by converting a bitstream into a number
Get-Acl HKLM:\software | format-list
%PATH% Hijacks
If any portion of the SYSTEM %PATH% variable is writeable by Authetnicated Users, it is almost certain that privilege escalation opportunities exist. A horrifying number of programs call other applications without specifying a full path. Some system admins don’t leave system32 as the first directory in %PATH%, but it almost always should be. The netsh command is one of the most common commands ran by the Windows operating system. A 0 day was found due to a program running netsh and had the program directory prepended to the %PATH% variable (the program directory is checked for system binaries before system32). If a non-standard directory is found in the %PATH%, check permissions to see if the Users group has write permissions. The directories in %PATH% are analyzed in order.
#this command returns the %PATH% variable with a custom directory at the front
reg query "HKLM_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment"
#check the permissions and note that write access is present (W,D)
icacls c:\mydir
Abusing Services
Attackers may try a number of ways to abuse services, such as service executable replacement, DLL added to service a executable directory, changing a service config file, and two others Service config file $TWO MORE
Executable Replacement
Attackers query service configuraitons and discover the service executable in the ImagePath value. If the attacker has write permissions to the service executable, they can overwrite it. One of the biggest challanges is that executables are locked “open exclusive” by Windows while running. Any service set to autostart will be running and can’t be replaced… Windows doesn’t page file executables, so it can’t be deleted while the service that’s using the executable is running–even with WRITE permissions. Can we crash the service, starve the resources, or social engineering the helpdesk to stop the service.
DLL Added to Service Directory
If the service executable is in a directory where the user has write permissions, they may add a DLL that is loaded into the service process. Unless the attacker takes pains to build a proxy DLL, the service will crash, so this is best used to add an account, change a configuration, etc. This has the distinct advaantage of not requiring the service to be stopped before implementing.
#is monitoring of full command line auditing turned on
#enumerate pathnames with wmic and investigate with icacls
wmic service get pathname | findstr /i f-response
icacls "c:\program files\f-response"
Modify Service Config
IF the service uses a config file and the attacker has write access to the file,they can add or modify entries that may result in code execution. This obviously requires a very specific service to be successful. Of all the service privlege escalation scenarions………
Modify Service Registry Value
The ImagePath registry value for the service controls the executable that is launched. In some rare cases, service registry keys may be created that allow the currently logged in user write access to values. By replacing the ImpagePath value, the attacker’s executable will be executed with elevated permissions the next time the service is restarted. The Service Control Manager reads them once at boot and not on changes.
Abusing Unquoted Service Path
Windows does not handle spaces in executable names and paths gracefully at all. Windows treats each space in an unquoted file name as the possible beginning of command line arguments.
#cycle through all the iterations of the file paths to see if one has write permissions that an EXE can be dropped to
wmic service get name,displayname,pathname,startmode | findstr /i /v Windwos | findstr /c:""" /v
Find a 0 day by putting putty.exe as program.exe, and put it in
InstallAlwaysElevated
The InstallAlwaysElevated registry key allows software packages to be installed using with system privileges. HKLM is for managed applications (e.g. those deployed via GPO) while HKCU applies for everything else. If these are configured, msfvenom can be used to build an MSI package which will elevate permissions.
$reg_keys
HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Installer
HKEY_LOCAL_MACHINE\""
Unattended Setup/Upgrades
Unattend.xml files are used to answer questions asked during the Windows installation, of which one of thse is the login password for the local administrator account. If an unattend.xml file is found and is readable, it is trivial to recover the admin password and elevate. Password is either plaintext or base64 encoded. Upgraded versions of Windows will move the originally Windows directory to Windows.old, which many contain sensitive files, including registry hives. Although the default filesystem permissions SHOULD prevent access to the files, we’ve observed these directories set to world readable and inherited within the sub directories.
?Uninstalled Software
Many software packages use COM objects, these COM objects are controlled by registry settings, specifically InProcServer32 values. In some cases, stale COM entries are left behind in the registry (even though the files on disk are gone). When this occurs we can trick the syst em into executing code in a privleged context if we have appropariate, filesystem permissions. The original work on this is from Jimmy Bayne @ bohops abusing-com-registry-strcutue post. Jimmy notes that this is usually best used as a stealthy persistence technique due to standard directory permissions. As we’ve already discussed, directory permissionsmay not be configured in the standard manner for any number of reasons.
Where to go from Here?
We reguarlyl use ProcMon from sysinternals in our evaluation of third party software. Often unquoted paths (or absnce of a full path) combined with weak filesystem permissions, allows for the exploitation of custom/third-party applications that run in a privleged context.
Conclusion
Windows privilege escalation is often easier than it should be. If you don’t hunt down the privelege escalation opporiutnites on your machine, attackers will. If you are an attacker, good news – most system admins still suck at this…