Sunday, February 23, 2014

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.

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.

Monday, February 10, 2014

Thanks to Matt, PowerSploit has had a function to resolve hostnames to IP addresses for a while. The Invoke-ReverseDnsLookup utility is useful in mapping a domain from inside or out. Often, organizations use overly-descriptive names which can help an attacker narrow down their targets during initial recon and again once they have a foothold on the inside of a network. If you haven't used it, you should check it out.

Recently, we added support for two things to the function which I found helpful on a recent engagement. Both are simple enhancements that come with the PowerShell language that you may want to implement in your tools.

The first is the use of the Write-Verbose cmdlet which is a Common Parameter. That means it comes free when you declare your parameters with "[CmdletBinding()]" and then can be called by adding the "-verbose" switch when the function is called. Optionally, it can be enabled by changing $VerbosePreference, but by default it doesn't show anything. In the case of Invoke-ReverseDnsLookup, I added it to the function to be able to see what IP address it was currently trying to resolve. Since verbose statements are written to the console and not the output pipeline, you can use any of the "out-*" without it being cluttered with messages.

The next feature of PowerShell that we added is support for input from the pipeline. Pipeline input allows functions to be chained together and allows developers to focus on doing one thing. Where input is coming from and how the output is parsed or stored should be handled by the user. For example, I had a text file of several different network ranges and IP addresses that I wanted to be able to pass to Invoke-ReverseDnsLookup, but it didn't support it. Fortunately, it is simple to add support to your tools. The first thing you need to do is decide what logic (if any) only needs to happen once at the beginning or at the end of the script. In our case, Matt wrote a function to break out and validate CIDR ranges into individual addresses. We don't need to declare that function for every IP address, so we will create a BEGIN script block:

The only required script block is PROCESS. That is the part that will do the work on each object coming down the pipeline. You can see the PROCESS block above and how the current IP address in the pipeline is reference with the pipeline variable ($_). Once the PROCESS block is done, the optional END block does any post-processing for the function.

Certainly nothing ground-breaking here, but I thought I would share some neat features of PowerShell and how they can be applied to your tools. It may give you some insight into the "why" behind some of the functions in PowerSploit. Thank you for reading.