Microsoft Claims PowerShell Now More Secure (wired.com) 62
An anonymous reader quotes Wired:
Last year, well over a third of the incidents assessed by security firm Carbon Black and its partners involved some sort of PowerShell component. But as network defenders catch on to Microsoft's recent release of additional PowerShell protections, the attack sequences that exploit PowerShell are finding some long-overdue resistance... PowerShell 5.0, released last year, added a full suite of expanded logging tools... While it's no panacea, and doesn't keep attackers out, the renewed focus on logging aids flagging and detection. It's a baseline step that helps remediation and response after an attack is over, or if it persists long-term... And PowerShell's recent defense improvements go beyond logs. The framework also recently added "constrained language mode," to create even more control over what commands PowerShell users can execute... The security industry at large has also made strides to determine what baseline normal activity for PowerShell looks like, since deviations could indicate malicious behavior.
Lee Holmes, Microsoft's principal software design engineer for PowerShell, says they've been "laser-focused on security since the very first version," adding that they're now moving towards a more enlightened approach.
"You can focus harder on protecting against breaches and defense in depth, but the enlightened approach is to assume breach and build the muscle on detection and remediation -- make sure that you're really thinking about security end-to-end in a holistic manner."
Lee Holmes, Microsoft's principal software design engineer for PowerShell, says they've been "laser-focused on security since the very first version," adding that they're now moving towards a more enlightened approach.
"You can focus harder on protecting against breaches and defense in depth, but the enlightened approach is to assume breach and build the muscle on detection and remediation -- make sure that you're really thinking about security end-to-end in a holistic manner."
Re: MS's security cam (Score:1)
As usual, turkeydance is clueless. Microsoft's security camera has nothing to do with Powershell, except that Microsoft makes both of them. No links have been supplied to explain or support the post. Nothing useful to see here. Mod down and move along.
Re: MS's security cam (Score:4, Interesting)
That may be, but Windows is still a prime target, and while security features in a scripting language aren't a bad thing, at the end of the day what actually stands between a system and an attacker is the underlying OS. After all, Powrshell is hardly the only interpreter that runs on Windows.
I think Microsoft and its supporters should spend their efforts securing their own system, and stop the marketing-style "yeah, but look at MacOS!" nonsense. As to security, all OSs have vulnerabilities, so comparing who has more and the severity and so forth is just another form of pissing contest.
For myself, I still find Powershell a frankly horrible scripting language, it's only positive feature being that it's the best Windows has, and I'll its outrageously verbose syntax simply because it does do the job, no matter how awkwardly and slowly.
Re: MS's security cam (Score:2)
Outrageously verbose?
Re: (Score:2)
I prefer mnemonic commands rather than Get-* commands that can get very long. Yes, I know some of the more common commands have *nix-y shortened versions, but that's only a fairly small subset.
Re: MS's security cam (Score:2)
You can use tab completion if you don't like all that typing but Powershell is not supposed to be the same as bash. It needs to be more complex than text and file manipulation owing to the overcomplicated design of Microsoft's software.
Re: (Score:3)
That may be, but Windows is still a prime target, and while security features in a scripting language aren't a bad thing, at the end of the day what actually stands between a system and an attacker is the underlying OS. After all, Powrshell is hardly the only interpreter that runs on Windows.
I think Microsoft and its supporters should spend their efforts securing their own system, and stop the marketing-style "yeah, but look at MacOS!" nonsense. As to security, all OSs have vulnerabilities, so comparing who has more and the severity and so forth is just another form of pissing contest.
For myself, I still find Powershell a frankly horrible scripting language, it's only positive feature being that it's the best Windows has, and I'll its outrageously verbose syntax simply because it does do the job, no matter how awkwardly and slowly.
How many grandmas have Powershell turned on with execution-policy Allsigned or RemoteSigned turned on by default for hackers to target? If you are going to target you use an ad.
I am not all pro MS per say but I can do nifty things with PowerShell like this on my SSD drivers " Get-PhysicalDisk | Get-StorageReliabilityCounter | Select Wear " to find on the disk in percentages. Cool stuff as PowerShell deals with objects, while Unix scripts can only process things if they are text.
Nothing wrong with that in so
Re: (Score:3)
"I am not all pro MS per say" ... Troll detected
Re: MS's security cam (Score:4, Interesting)
Linux has moved to encrypted binary log files[1], unfortunately, a vocal minority of older system admins and developers refuse to see the necessity of this feature.
[1]https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/g1E6AxVKtyc
SystemD hate is big for a variety of reasons. But I can see System Admins concern as how can you edit and run scripts on binary files?
I like the concepts of PowerShell and piping objects even if they are less readible as even in Unix not everything is an object. If Plan9 became popular the need for an object based shell like PowerShell would not be as much of an issue but still security is a problem in a text based system.
Perhaps since so much of Linux is turning object based that a new shell or extension underneath Bash could be used to do things like view and change logs that are binary or process XML files? Maybe a signed text based redirector framework so you could run awk, sed, perl scripts on binary systemD objects.
But the old times would go ballistic and switch to FreeBSD faster than you can say SystemD lol ... turns to sighs.
Re: (Score:2)
If a hacker has write access to /var/logs, he can do a helluva lot more than just monkey with log files. At that point, he's got root access, or something nearly as nasty.
And the reason behind text files is that they are human-readable and human-editable, even if the only editor available is ed. There's a place for binary blobs, but I don't believe that place is configuration. Replicating configuration settings when you're forced to use binary files like the registry can be problematic, whereas I can rebuil
Re: (Score:2)
If a hacker has write access to /var/logs, he can do a helluva lot more than just monkey with log files. At that point, he's got root access, or something nearly as nasty.
And the reason behind text files is that they are human-readable and human-editable, even if the only editor available is ed. There's a place for binary blobs, but I don't believe that place is configuration. Replicating configuration settings when you're forced to use binary files like the registry can be problematic, whereas I can rebuild functionality on a new *nix machine by simply copying over plain text files, and I've done it on many occasions. I build custom iptables routers, and believe me, the speed at which I can get a new router up and going where I have backups to /etc is a helluva lot faster than anyone will ever get trying to shove binary blobs through Powershell pipes.
I am not disagreeing but if I r00t a server you bet the first thing I am going to do is rewrite your /var/logs when I put in my rootkit to hide evidence. That is a flaw which Solaris too now uses binary logs and switched away from init that angered many admins for this reason.
An object based or signed object with text encapsulation system inside Bash I would not be opposed too. Text files are simple and readable but can be dangerous. If objects have a format they are not black box blobs per say which is how
Re: (Score:2)
I've had registry hives get clobbered a helluva lot more frequently than I've ever had text files go down, and really, a rootkit in Windows is going to be able to access the API calls for the registry, so I fail to see how either way a sufficiently clever rootkit can't disguise itself.
A lot of your statements seem more like special pleading, and I'm not buying it. Arguing binary logs and configuration files are superior because they're harder to fake really is just an argument for security by obscurity.
Re: (Score:2)
And what, pray tell, is stopping someone from gaining root > clobbering the binary log to corrupt the last few kb of logging time to force a split of the log file ( and maybe eve turn off logging so a new log isn't written), exactly the same as hiding your tracks in a text based file?
If someone has root / full admin privs. already you are screwed. That means they have full access to logging - as well as everything else on the system - to hide tracks, it doesn't matter what type of logging is being used.
Re: MS's security cam (Score:2)
Well you could export the relevant registry keys from a working machine, copy the file over to the affected machine and then apply those settings with Powershell. A bit more complex but not the end of the world.
Re: (Score:2)
The point of using binary logs is they are signed. It is not about a horrible database system being corrupted which is what is being applied (not relevant) but rather a way of having every root or administrator having his or her own sets of keys. If a hacker uses lets say the system service to cover the tracks there would be evidence of that as a different SID (The NT version of a key sort of) or in the case of Linux just key there would be evidence.
So if you had let's say objects that are signed but had te
Re: MS's security cam (Score:2)
Re: (Score:1)
We certainly won't be forgetting the staggering cost of damage wrought by Microsoft products [wikipedia.org] anytime soon.
Now more secure? (Score:1, Troll)
Re: (Score:2)
You mean how Bash supports execution policies and does encryption by default. Oh wait ...
You're kidding me! (Score:4, Insightful)
Re: (Score:2)
Considering the piss poor nature of Windows logging, I'll take even improved logging of events.
Re: (Score:2)
We're talking about effectively a run-time compiled programming language. You have two choices: 1) You refuse to give the language power to do anything useful 2) You log what it did to detect bad actors.
The same is true of software. You either grant it the power to do useful things to the system (like copy/paste) or you run high level pattern matching (virus scan/active defense) which watches the processes for suspicious behavior. Even then, encrypting a hard drive is often both a useful and a malicious
"laser-focus" without skill is pretty worthless (Score:3)
MS has been the uncrowned queen of "just barely good enough to make money" forever and people were too stupid to recognize that and stay away. Now they can easily get away with it. Take these new promises for what they are worth: nothing at all.
Great pitch! (Score:5, Funny)
While it's no panacea, and doesn't keep attackers out...
Well I'm sold! Say no more!
Who are these people (Score:3)
Powershell is great! (Score:3)
Get-AppxPackage -allusers | Remove-AppxPackage
Need I say more?
Re: (Score:2)
If only there were some vast network of computers you could use to find out.
Re: (Score:2)
> Get-AppxPackage : Access is denied.
It's a scripting tool Microsoft, not an ActiveX re (Score:2)
If you can have a random program remotely run executables with different credentials and elevated privileges in a scripting tool, you've screwed something up.
These exploits are the equivalent of setting the setuid bit on /bin/bash
Re: (Score:2)
You don't. This is why you need to set-execution policy remote signed or allsigned off before you can do anything useful.
Re: (Score:2)
Of course a cmd/bat file can merrily do that as a prelude to an evil powershell script, so the execution policy is only annoying to legit users without being a significant problem to those that would use ps1 as an attack vector.
It would be maybe something if ps1 content could execute in some context that cmd/bat files could not (e.g. the way microsoft put activex everywhere), but they know better than to even try that. So they have something that would have mitigated problems they had with ActiveX, but als
The war is over (Score:1)
The war is over. The black hats won.
A more enlightened approach to security? (Score:2)
Translation: we can't even figure out how to protect Windows from security breaches.
Re: (Score:2)
I think you'll have to explain why that's a problem...
Security Theater (Score:2)
The powershell signing situation always baffled me.
To run a powershell script, you must sign it. Which is of course terribly inconvenient, but hey, at least it is secure.
Except you can disable the restrictions easily, so easily in fact that a would be attacker need only do one very minor thing prior to their script having to execute for all this to not matter, and that minor thing is readily accessible through a .bat or .cmd script (which I have seen professional software do even, temporarily relax the pol
Re: (Score:2)
The main security benefit of signatures is the prevention of someone changing the code. Which is a nice addition that was missing from
Re: (Score:2)
It's of limited utility so long as .vbs/.bat/.cmd still can run without such protections in the same context.
And on the 'you have to have admin rights', there is something deeply wrong with the Windows userbase. I made an app for Windows and made it available to some testers and went to see what they did. About 7 out of 10 of the test users right clicked to 'run as administrator' without even *trying* to run it normally. Even after telling them as the developer of the application that it does not need ad
Re: (Score:2)
It's of limited utility so long as .vbs/.bat/.cmd still can run without such protections in the same context.
And on the 'you have to have admin rights', there is something deeply wrong with the Windows userbase. I made an app for Windows and made it available to some testers and went to see what they did. About 7 out of 10 of the test users right clicked to 'run as administrator' without even *trying* to run it normally. Even after telling them as the developer of the application that it does not need admin rights, 2 of them refused to run it normally, because they didn't believe that it could work without it.
That's why we (or at least I) deny users administrative rights. Expect your users to be useless in regard to security, and harden your systems accordingly.
learn from history or repeat it (Score:2)
The problem with PowerShell is in its basic design. Merging an embeddable scripting language and a shell is just a lousy idea. How do we know that? Because people in the UNIX world have tried it for decades and it failed every single time. It failed because, among many other problems, securing such a thing is really hard, as Microsoft is discovering. It also failed because creating such a Swiss army knife of a tool means that each individual function just isn't very well supported, and that simple things ge
This sounds familiar... (Score:2)
It reminds me of the never-ending claims that "Windows <fill-in-the-version> is the most secure Windows ever".