Sunday, July 1, 2012

PowerShell Web Access: What could possibly go wrong?

I recently started playing with PowerShell Web Access. It is a nice feature of PowerShell 3.0 and could be really useful in enterprise environments. This post is result of my experiments with this feature from a Penetration Tester's point of view (may be as a backdoor). So let's get started.

For setting up of PowerShell Web Access, I used a virtual machine (a Windows Server 8 (2012?) Developer Preview) running on virtualbox. This Technet document explains it all. So AFAIU from the technet document, following cmdlets could be used to setup PSWA up and running.

  1. Install-WindowsFeature –Name WindowsPowerShellWebAccess
  2. Install-PswaWebApplication -UseTestCertificate
  3. Add-PswaAuthorizationRule UserName -ComputerName -ConfigurationName
PSWA also requires PS remoting to be enabled. "Enable-PSRemoting -force" could be used to enable that.


So let us consider a post exploitation scenario where we can run commands on a Windows Server 8 (2012?). Following commands could be used to setup PWSA assuming that it is not already installed.



Above command will install a PWSA web app with name "pentest" which will use a self signed certificate. Obviously, you would like to change the name during a Pen Test.


Above command adds an Authorization rule which governs the access control for PWSA.
The cmdlet takes three arguments:
  1. Username is username of the user which would be used for authenticating.
  2. Computername is name of the computer to which the user would have access.
  3. ConfigurationName is name of the session configuration.

During a Pen Test you may like access to all of the computers accessible to a user. There is a nice "tip" (with warning) in the technet document which says that you can use wildcards for all the options in Add-PswaAuthorizationRule cmdlet. That is what we have used in above example.

A * in all of the three fields indicate, "allow all authorized network users access to all computers on the network to which they typically have access, with access to all session configurations to which they typically have access."

What does this mean? This means that if you are able to have access to credentials of a user which is present on large number of machines in a network, you can use PWSA as a secure, encrypted and native method of accessing the systems (with its own set of restrictions). Of course, there are other ways too of accessing systems if you have credentials of such a user.

Be mindful while using wildcard on a client's machine as this will open up the network for everyone. A better option could be


Enable PSRemoting


So now we have a PowerShell web session open in front of us.



Now what? Let us try to do some nasty things with it. I am using credentials of an Administrative user.

Elevate to meterpreter
Well not "elevate" exactly :P. Many pentesters can't go without having a meterpreter on target. Using a simple PowerShell script we can download and execute a meterpreter binary.


And the result is


Have a look at my previous blog post for doing this more effectively and stealthily.

Persistent Jobs
In the above example, if you do not use any persistance available with meterpreter, your meterpreter session will close as soon as you logout of web session. To keep it running, you can schedule it as job. Remember, you can schedule only a PowerShell script as job. A quick dirty trick could be



This can be used for many post exploitation tasks which require scripts to be running on target machine.

Elevation to SYSTEM
Now, let us try for SYSTEM level access to the machine. Why? For fun and password hashes :)

Let us use the technique implemented in Kautilya. We will schedule a batch file as a task which will run with SYSTEM privilege. The batch file will call the powerdump script (available in msf) and the hashes will be dumped. Sounds easy? Yes it is.

We will download the powerdump script and batch file using script used in the above example. The batch file should look like this.


Now let's scehdule it as a task which will run as SYSTEM

I am using harcoded paths as the batch will be running with SYSTEM priv and its TEMP directory is different (C:\Windows\Temp).

Let us run the task


Now if we check the contents of "C:\Users\<currentuser>\AppData\Local\Temp\dump.txt" we will find hashes :D


If you already have access to password of an Administrative user, why would you need to dump hashes? To gain access to more systems or similar stuff.

Many more things could be done using PSWA specially post exploitation activities. Look at it as one of the best web shell ever !!

Lastly, I have not seen any enterpise deployment of PSWA (as the OS itself is in review phase) so few things in this post could be wrong or based out of pure assumption. I hope the administrators will take care while deploying and users will be more careful while using this.

I will keep working on this and will write more posts about anything interesting. Also, if PSWA is ported to a Desktop OS ever, an implementation of this in Kautilya will be definitely done with a blog post detailing that.

Hope this would be useful and fun. Please leave comments and feedback.



4 comments:

  1. Howdy Nikhil!

    I love the scrutiny and have a couple questions. What I read from this is:
    1) If you allow someone to log into your system, they can do bad things and if you let them log in with Admin privs, they can do more bad things.
    2) PowerShell is powerful and makes hard things easy.

    Is that the conclusion or is there something specific about the way you let people log in (PowerShell Web Access) that is more risky or opens up new attack vectors?

    Also - are there things you think we could/should do to either
    1) make this mechanism more secure/safe?
    2) make this mechanism more useful/fun?

    Thanks for the post Nikhil! I hope you keep pushing/publishing. We are super open to hearing where we can make things better.

    Jeffrey Snover[MSFT]
    Distinguished Engineer and Lead Architect for Windows Server

    ReplyDelete
    Replies
    1. Thanks a lot Jeffrey!!

      The conclusion you got is right for the post but alongwith some other points. PSWA could be a little bit secure in some aspects IMHO. Two things which came to my mind while playing with PSWA are:

      1. There seems to be no mechanism (at least no easy mechanism) to know which user(s) is/are logged in using PSWA. This makes PSWA stealthier for an attacker.

      2. Wildcard (*) support by Add-PswaAuthorizationRule. This could be a serious issue in case of a misconfiguration or two. I expect to see * most of the times at least for runspace/configuration.

      I have just started playing with PSWA and I may be completely wrong about the above two things. I will keep posting for sure as more interesting things come up. Glad to see you are so open for improvements.

      Delete
  2. Thanks Nikhil!

    I appreciate the feedback and we'll put those on the list of things to consider going forward.

    Cheers!
    Jeffrey Snover[MSFT]
    Distinguished Engineer and Lead Architect for Windows Server

    ReplyDelete
  3. This comment has been removed by the author.

    ReplyDelete