Slashdot Mirror
Microsoft Claims PowerShell Now More Secure (wired.com)
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."
The parent contains no sustance, just unverified claims with no links to the alleged source. It might as well just say 'fp' but that is the quality of posts you get from users like turkeydance, creimer, drinkypoo, and MightyMartian. Please do your part to encourage better posting on Slashdot by modding the parent -1 troll.
That is easy. I would have been impressed had MS managed to make to less secure.
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.
[citation needed]
Oh its secure, probably because by the time i have the shell opened i have already chosen a different method, dogshit slow because its built on .NET crap, at least cmd opens in 1sec
And more than have the PS commands I look up don't work.
How do old vulnerabilities in a Microsoft IoT product show that their updated PowerShell lacks security? They don't. Period. You are a troll.
As usual, turkeydance is clueless. Microsoft's security camera has nothing to do with Powershell, except that Microsoft makes both of them.
That's true but Slashdot is full of people with uniformed opinions about Microsoft based upon nothing more than very outdated knowledge or group think. It was more of an issue back in the 1990s, but if Slashdot user numbers are anything to go by, most of the group thinkers weren't even around back then. Microsoft has made great improvements to security during the intervening years, if for no other reason than the relentless attacks forced them to. When the PowerShell developers say that they care about security and have focused in on it from day one I believe them. Every developer currently working at Microsoft must surely be aware of the past mistakes and reputation and wants to do their best work to make things secure. It's a point of professional pride in that way. Do they always succeed? No, but coding secure software is a hard thing to do well and I don't see the complainers doing any of the work. Meanwhile, has anyone else noticed how Apple users have become a bit less smug about security, having now been hit themselves with iOS and MacOS malware because Apple is popular these days? It sort of proves what Microsoft users had been saying all along which was that Apple was not more secure than Microsoft; it just got less attention from hackers when less than 3% of the computing population used Apple products. Well, they're not laughing anymore now that iOS malware is a thing.
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.
The world's burning. Moped Jesus spotted on I50. Details at 11.
Let's start with the operative sentence: "...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..." Really? Gee - thanks, Mister! After the damage is done - long-term, BTW -we'll have logs! Logs solve everything! Dumbass....
Per the summary, they acknowledged that they now write better logs and fixed several bugs for improved auditability. As such, it is more secure than it was before said change was made, much like a bank may be more secure with a camera even if the doors remain unlocked.
Thirty four characters live here.
Have we already forgotten about the notorious Shellshock bug that affected something like 25 years worth of releases of GNU Bash?
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
While it's no panacea, and doesn't keep attackers out...
Well I'm sold! Say no more!
Anons need not reply. Questions end with a question mark.
What class of users should be allowed access to powershell but not to all the commands ? I struggle to imagine that powershell is the domain of anyone who doesn't merit full access to the computer. OK maybe they do exist, but I can't see it being a lot of people. And besides, if the restrictions only apply to powershell people who can grasp powershell have the wherewithal to find other ways to get around them.
Nullius in verba
Get-AppxPackage -allusers | Remove-AppxPackage
Need I say more?
Outrageously verbose?
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 something like the Unix creators failed successor Plan9 where you can even pull up slashdot.org with shell scripting. But, impossible to do anything else in Unix if it is not a text file. I believe (As a non System Admin but a real one feel free to correct me) the hate on SystemD comes from the fact the log files are not text files.
For a Windows Admin binary files are good idea as a hacker can just rewrite /var/logs to cover the tracks which is an embarrasing security flaw. But if all your tools have perl -e ... awk, sed, and grep this is an unacceptable nightmare!
PowerShell uses objects for this reason so you can have encrypted binary event logs that hackers can't overwrite, but you can still view them.
http://saveie6.com/
"I am not all pro MS per say" ... Troll detected
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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
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.
The world's burning. Moped Jesus spotted on I50. Details at 11.
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.
http://saveie6.com/
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 PowerShell works.
http://saveie6.com/
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.
The world's burning. Moped Jesus spotted on I50. Details at 11.
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.
The world's burning. Moped Jesus spotted on I50. Details at 11.
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
Custom electronics and digital signage for your business: www.evcircuits.com
"all OSs have vulnerabilities"
It's funny that this concept was once summarily dismissed when ever anyone tried to use it in a discussion about MS security faults. Now that Linux and Mac platforms have been shown to be vulnerable all the rabid MS haters have suddenly had to re-evaluate their slogans.
"yeah, but look at MacOS!"
So in your mind this statement is idiotic but "yeah, but look at WinOS!" is a perfectly justified statement.
"I still find PowerShell a frankly horrible scripting language"
How would you know? What are you comparing it against? How long have you actually used it?
But I will be the calm voice of reason and publicly announce that "all Scripting engines have vulnerabilities" so back off on attacking PowerShell and go make sure all the other scripting engines have their ducks in a row and correct any problems you find.
It's less a command shell and more a .NET CLR shell. If I need to execute commands, I use a command prompt (cmd.exe). If I need
to write Windows tools with a subset of available functionality, I use PowerShell. Otherwise, I use C or C#, depending on the task. I also use JScript quite a bit. It's a fast albeit outdated ECMAScript and VM.
The war is over. The black hats won.
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.
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.
"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"
Translation: we can't even figure out how to protect Windows from security breaches.
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 text encapsulated you could still use your unix tools too. Another root user would have a different key which the filesystem would show modification by that key.
http://saveie6.com/
You don't. This is why you need to set-execution policy remote signed or allsigned off before you can do anything useful.
http://saveie6.com/
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 policy then re-enable when done, without a user having to approve/explicitly do it manually).
It's a way to vigorously say 'we were focused on security' and all the inconvenience for people to feel 'yep they thought about security' and arrive at a completely useless protection against attackers.
XML is like violence. If it doesn't solve the problem, use more.
I think you'll have to explain why that's a problem...
XML is like violence. If it doesn't solve the problem, use more.
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 also a reluctance to even risk it anywhere where ActiveX was a unique threat...
XML is like violence. If it doesn't solve the problem, use more.
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. Any file that can be written to on disk can be subverted, it doesn't matter if it is a binary file or text file.
To err is human; effective mayhem requires the root password!
Yes, but does it write BINARY logs that can't be read without invoking some arbitrary command few recall?
Powershell was already more usable, more powerful and far FAR more secure than any Linux shell, so Microsoft upping the ante here just goes to show once again how top down cathedral style development is a better way to develop software than any shitty "bazaar".
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 get more complex than they need to be.
It reminds me of the never-ending claims that "Windows <fill-in-the-version> is the most secure Windows ever".
CUR ALLOC 20195.....5804M
If you want to treat everything like a file, you can treat everything like a file. It won't be _exactly_ the same as Unix or Linux because it's not Unix or Linux, but you can use e.g. CreateFile, ReadFile, and WriteFile and their derivatives to work with most native Windows objects.