Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Windows Microsoft Security Linux

'Bashware' Attacks Exploit Windows 10's Subsystem for Linux (betanews.com) 80

Mark Wilson quote BetaNews: While many people welcomed the arrival of Windows Subsystem for Linux (WSL) in Windows 10, it has been found to be a potential security issue. A new technique known as a Bashware has been discovered by security researchers that makes it possible for malware to use the Linux shell to bypass security software.

While administrator access is needed to execute a Bashware attack, this is fairly easily obtained, and the technique can be used to disguise malicious operations from antivirus software and other security tools. Researchers from Check Point Research point out that the danger stems from the fact that "existing security solutions are still not adapted to monitor processes of Linux executables running on Windows."

This discussion has been archived. No new comments can be posted.

'Bashware' Attacks Exploit Windows 10's Subsystem for Linux

Comments Filter:
  • by natex84 ( 706770 ) on Sunday September 17, 2017 @11:39AM (#55214331)

    While administrator access is needed to execute a Bashware attack, this is fairly easily obtained

    Really? that sounds like more of a problem than some particular tool....

    • by The MAZZTer ( 911996 ) <megazzt.gmail@com> on Sunday September 17, 2017 @11:48AM (#55214355) Homepage
      Yeah, like I said on the last website that posted this story, this is a non-issue. If the attacker has local admin access, they've already pwned the system, it's game over. What they do after that point is trivial and not interesting.
    • by johnnys ( 592333 ) on Sunday September 17, 2017 @11:49AM (#55214359)

      Yes. If you have Administrator access, you own the system. So what they are really saying is "Hey, if you already own the Windows system then you can do bad things with the Windows system!"

      So it's a meaningless and irrelevant story.

      • Not entirely meaningless.

        Can drive-by-downloads install the WSL, and then install something to apt-get WINE, or complile WINE on the WSL, resulting in a virus running undetected by the Windows antivirus?

        The issue here is that once it happens, there will be no way to catch it down the road. Once an id10t user gets infected, nothing will detect the infection. Only knowledgeable techs who know to remove the WSL to remove the virus.

        Can an antivirus or anti-malware system detect malware installed into the
      • by DrYak ( 748999 ) on Sunday September 17, 2017 @12:56PM (#55214607) Homepage

        The thing is, on the platform usually targetted by malware written in Bash script - like GNU/Linux systems - "Administrative access" isn't something trivial.
        It's rare that regular users run everyday tasks as "root".

        You needed Microsoft to bring the GNU userspace and "linux ABI" to their NT kernel for suddenly things to run sour.

        ----

        And joke aside about NT user running as "administrators" 24/24 hours and 7/7 days, this was bound to happen :
        In order to not have ridiculous performance (as opposed to solution like Cygwin which is a user-land translation layer that must leverage whatever meagre functions the Win32 API offers to provide its POSIX compatibility) "WSL" takes a lot of shortcuts when providing "linux API" ("picothreads" was a widely advertised capability introduced inside the NT kernel and leveraged by WSL so it could provide posix-threads to linux ELFs that doesn't suck as much at multi-threading/multi-processing as the rest of Windows).
        Some of these "not that much secure" performance shortcuts was bound to blow back on WSL users' face.

        Again, remember : WSL is only exclusively to be used in testing/development environment (so that devs can directly test linux binary ELFs without needing, e.g., a full blown Ubuntu VirtaulBOX VM image).
        WSL is currently NOT to be used in production (keep it away from production servers - obviously those will be running some GNU/Linux flavor), otherwise such blow-in-your-face accident could happen on critical machines with critical data.

        • Re: (Score:2, Insightful)

          So really, the better solution is to actually run Linux on VMWare, VirtualBox, Hyper-V, and so on.

          Got it, avoid another MS integration clusterfuck.

          • by KiloByte ( 825081 ) on Sunday September 17, 2017 @02:24PM (#55215077)

            So really, the better solution is to actually run Linux on VMWare, VirtualBox, Hyper-V, and so on.

            And why would I do that instead of running Windows in qemu-kvm, VirtualBox or even VMWare? You want the more secure system as the host rather than the other way around.

            • I think they meant for development. The only benefit to WSL over a full Linux in a vm is that it's closely coupled to Windows. But that's a drawback more than it is a benefit. It's not like it's arduous to get your data in and out of the vm.

        • Again, remember : WSL is only exclusively to be used in testing/development environment (so that devs can directly test linux binary ELFs without needing, e.g., a full blown Ubuntu VirtaulBOX VM image). WSL is currently NOT to be used in production (keep it away from production servers - obviously those will be running some GNU/Linux flavor), otherwise such blow-in-your-face accident could happen on critical machines with critical data.

          But some stupid shop is going to underbid you writing a thin layer on top of some free opensource code, and install/enable WSL behind the back. PHBs, dimwitted people masquerading as chief of cyber security, all the layers of CXOs, all bent "upon making the numbers" for the coming quarter to get an additional million dollar stock options all will claim that is the fair price for that module that faces the world from the landing page of corporate web site.

          You lose immediately

          They lose after some time

          We

          • Yes. The upcoming release of Windows Server 2016 will come with containers for Redhat support using docker. Redhat and Microsoft have a partnership

        • Incorrect. Windows has a VMS security system with tokens since NT evolved from VMS. Unlike Unix a user is not really admin under Windows but rather requests a token to perform and admin task from ACL access control lists

          WSL doesn't do shortcuts. The NT kernel was designed by David Cutler to be as portable as possible and uses a HAL hardware access layer. 32 bit tasks run on a wow layer win64 on Win32 to the kernel below. WSL is another layer on the kernel just like native .exes.

          • Incorrect. Windows has a VMS security system with tokens since NT evolved from VMS. Unlike Unix a user is not really admin under Windows but rather requests a token to perform and admin task from ACL access control lists

            These are implementation details.
            My main point is that most of the time, Windows users are used to run as adminsitrator.
            It doesn't matter if that is done by "holding admin level VMS tokens" or "being Unix UID=0, GID=0" is an implementation.

            In practice :
            - Windows user has account flagged as "admin"
            - Windows user does something and UAC shows up asking authorisation for admin action
            - Windows user clicks yes by habbit, because that's an entirely normal flow of actions.
            My point : Windows users are completely use

      • by Cognitive Dissident ( 206740 ) on Sunday September 17, 2017 @01:07PM (#55214657)

        No, it's not a non-issue, but it's a different kind of issue than most people realize. Remember the Alexis de Tocqueville Institution [sourcewatch.org] and the propaganda they pumped out last decade about how Linux and Open Source in general was a parasite on the tech industry, was enabling all sorts of illegal activities (such as terrorism - of course!), and attempted to publish a book claiming Linus Torvald's didn't really invent the Linux kernel? Microsoft was (and still is!) a major funder of this propaganda mill.

        Think about the possible implications of a story like this: Could it generate calls to change the way the Linux kernel and programs that run under it are written? And now MS have their hooks sunk deeply into the kernel dev team. The SCO gambit (also funded by MS) failed, spectacularly. And the Astroturf de Tocqueville [scienceblogs.com] gambit failed, though not quite as spectacularly. And now we have MS "cooperating" in the development of Linux. And up pops a story that may justify an overhaul of Linux to make it controllable by MS Windows. Well, surprise, surprise! This "change of attitude" by MS is looking more and more like a subtler strategy to seize control of Linux rather than outright destroy it.

    • While administrator access is needed to execute a Bashware attack, this is fairly easily obtained

      Really? that sounds like more of a problem than some particular tool....

      It's a classic example of a Raymond Chen airtight hatchway [microsoft.com] attack. In order to carry out an attack with admin privs, you first need to be admin. And then a sign lights up in black on a black background telling you you've done it.

    • by Anonymous Coward

      "I'm gonna tell you how to make a MILLION dollars tax free. First, get a million dollars."

      "I'm gonna tell you how to get root access on a Linux machine. First, get admin access."

      Eh, needs work before it's ready for Steve if he ever does a Linux show.

    • by mysidia ( 191772 )

      I believe the concern is the Subsystem for Linux can work something like some cornfields or an underground labyrinth inside the castle walls, where an invading army or a few soldiers that successfully scaled the walls and gained Administrator can secretly retreat soldiers to, and hide out in, and the normal security protocols will never be able to root out all the enemies hiding in the underground maze that has secret passages going out to the treasury and all the critical areas of the kingdom.

      IOW, the S

    • It's pretty easy to get administrator access in Windows, yes. Many environments require normal domain users to be 'local administrators' of their machine to perform seemingly normal, day to day tasks.

    • by Greyfox ( 87712 )
      I'm pretty sure if you popped up a dialog that said something to the effect of "Can we have administrator access so we can install a botnet on your computer and steal your identity?" a surprising number of people would reflexively click OK. That'd be an interesting study to do, come to think of it.
  • So Windows has a Linux subsystem.

    Does that mean all copies of the Windows 10 operating system are vulnerable? Meaning grandma or bubba and their propensity to give everything and its kid brother root access?

    Or are we just talking about systems being administered by Linux admins, where root access by an untrusted application carries this risk implicitly.
    • It's an optional component like IIS.
    • by Tablizer ( 95088 )

      Now we get all the holes of Windows AND Linux in one OS. Jeenius!

    • The WSL must be installed. It does not exist in a default install. For 32 bit systems it isn't available at all. In the end though this is not a vulnerability any more than most of the "vulnerabilities" you see these "researchers" finding on Linux systems. It is the classic "OMFG if you have admin / root / ring0 privs then you can do things!" Chicken Little cry.
      • The issue isn't in the install vector (typical user clicking "yes" to every UAC prompt). It is that no existing anti-malware utilities will automatically catch and remove the malware. This is a serious risk.
        • It is that no existing anti-malware utilities will automatically catch and remove the malware. This is a serious risk.

          Well to be more precise :

          - currently the WSL subsystem that provides "linux ABI" to original linux ELFs
          - and the Win32 system usually offered to normal windows userland
          are too different environment which are kept (on purpose) isolated from each other.

          (Just think about it: even if theoretically NTFS can store case-sensitive filenames, absolutely no Win32 userland does handle it.
          That's just one of the several reasons why both environment should touch eachother's stuff.
          Another reason is that for performance re

          • Nothing prevents it, except for two things.

            1. The user doesn't know the Linux subsystem is installed.
            2. The user doesn't know anything about Linux, and expects their Windows anti-virus to protect them.
            • The user doesn't know the Linux subsystem is installed.

              WSL isn't installed by default on Windows 10.
              It's an optional component that you need to explicitly select in the corresponding control-pannel-thingy.
              (like IIS).

              If the user is clueless, chances are high that they don't have WSL installed.

              The user doesn't know anything about Linux, and expects their Windows anti-virus to protect them.

              (well, if they are running McAffee, they are toasted anyway :-P )

              More seriously, it's the "security suite"'s developpers' job to develop a solution.
              Again there is no technical reason preventing it (even if the current suite happens not to be able to see what happens on the

              • Just because the standard method of installing an optional service is through a control panel, doesn't mean that is the only way.

                .NET 2, & 3 are optional on Windows 10. They are typically installed via control panel. The last time I installed a legacy application, the .NET frameworks were downloaded and installed automatically.

                So we are back to Antivirus vendors providing ELFs, and providing a means of automatically installing and registering them, after installation. A means of automatically detect
                • Just because the standard method of installing an optional service is through a control panel, doesn't mean that is the only way. .NET 2, & 3 are optional on Windows 10.

                  The difference is that .NET is a platform that is extensively used by Windows software.
                  It was designed with this purpose by Microsoft and is distributed widely.
                  It's completely expected that a lot of users will install it, because there are tons of legit use cases for that.

                  By the time a use clicks on a virus running on .NET, it is pretty expected that .NET will be installed.

                  WSL is a platform developed by Microsoft that currently only targets developers (so they can test linux code without a VM).
                  There might b

                  • My point is that the bashware is a Trojan Horse which installs the WSL, as you described. The average Joe ain't gonna know they don't need WSL, they have to trust the program they are installing, the Trojan Horse.

                    "if WSL happens to be deployed on that machine, they need to start the ELFs." Still confused on this terminology. If the WSL happens to be deployed after the antivirus was installed, will the ELFs be available to the WSL so they can be started? The Lxss folder is not safely writeable by Windows n
                    • My point is that the bashware is a Trojan Horse which installs the WSL, as you described. The average Joe ain't gonna know they don't need WSL, they have to trust the program they are installing, the Trojan Horse.

                      Which sound a little bit stretching the average Joe's trust, just to click on some attachement.
                      (But on the other hand if the torjan begin its life as a "bloatware" that is co-installed with a big software suite, that sounds more realistic :
                      the joe wants to install a copy of Adobe premiere that he managed to download for free from some website. he IS going to expect a tons of aditionnal platform and libraries to get installed with it. An installation of WSL to get an invisible zombie node of a botnet can ver

        • Why wouldn't they be able to catch it? Surely you don't think they work by waiting until the virus runs and has already done its damage?
          • I'm going off the OP, which references it being disquised from anti-malware applications.

            "that makes it possible for malware to use the Linux shell to bypass security software."

            So, neither definitions, nor AI, nor heuristics would detect something not running natively on the OS. May as well be running in a virtual machine.
            • OK. Reality check time. First, the following: "It is said that the attack vector could place all 400 million computers running Windows 10 at risk." So we immediately know that these people are disingenuous at best, since no 32 bit system can even run WSL, most 64 bit systems won't have it, and detecting attempts to install it outside the normal manual channel is trivial.

              Next, the exploit example requires you to install WINE, (which they misspell as Wine), so suddenly they sound quite foolish indeed don'
              • Point about definitions updates preventing the malware from infecting hosts after the definitions have been created and pushed out to clients. Which just means the spread will be limited, and old variants will not be a threat.

                I won't concede that it is much ado about nothing.
                • I'm OK with you thinking it is a major issue. Everybody has the right to be wrong :-)
                  • This is an exploit waiting to be used. I could see botnets taking advantage of this exploit for quite some time. Windows 10 is already slow anyway,... And this is on a Surface Pro 4.
                    • Windows has always been one big exploit waiting to be used. Ones that require admin access are NOT the low hanging fruit.
                    • Ones that require admin access have been offset by an antivirus.

                      From a Google, it does appear that the Lxss/WSL file system can be scanned by a Windows antivirus scanner for signatures of known viruses.
                      %localappdata%\Lxss\rootfs
                      There appears to be risk when removing or quarantining files located within the WSL. So an antivirus may be able to detect, but not remove known virus signatures. Not sure that qualifies as remaining undetected as the OP suggests.
                    • An antivirus to detect infections is key to keeping infected machines under control

                      Malware which can evade detection is a serious threat.

                      Most infections of this sort boil down to a user clicking "Yes" on every UAC prompt they get. The antivirus compensates for this weakness in security, but only if it can detect an infection. Though I now believe that these infections can be detected by a Windows based antivirus solution.
        • I can't see how this can be a serious risk, the people installing WSL to start with are a fraction of a fraction of the user base. Most people installing it aren't going to be your average users that install and accept any prompt. So realistically the install base is going to be so tiny and most of that base knows what they are doing so it won't be worth trying to even target
          • Those running WSL would not not likely be vulnerable to such an exploit. They wouldn't need WINE, nor whatever a Trojan Horse would be disquised as.

            The ones who would be vulnerable are the ones who have no idea what WSL is. The ones who would click "Yes" to a UAC prompt on a Trojan Horse, and then install a botnet which couldn't be detected by an antivirus.

            Though, from what I've just read today, signatures and definitions should be able to run against "%localappdata%\lxss\", and detect it that way. A W
  • Too late (Score:3, Funny)

    by jabberw0k ( 62554 ) on Sunday September 17, 2017 @12:17PM (#55214469) Homepage Journal
    Windows 10 itself is malware, isn't it?
  • Why is bashware not a problem on a Linux system ? After all: if all that Windows Subsystem for Linux does is to provide Linux functionality then you would expect the same malware to also have been a problem on native Linux systems.

    • Linux users are expected to be more knowledgeable. You grant root access to malware or a rootkit, and its your problem. Microsoft Windows is marketed towards masses of naive idiots. They have no clue, and unleash botnets on the rest of the world. So if we can't protect them from themselves, we have a problem. If an antivirus can't remove an infection, nor even detect it, we have a problem.
      • The masses are not enabling Windows Subsystems for Linux either. If someone is, they are supposed to know what they are doing.

        • The malware they installed to get emoticons installed WSL. So their Avast or AVG or Kasperky isn't picking up the WSL botnet infection running on Wine.
    • by PPH ( 736903 )

      Completely different security philosophies. Windows depends too much on 'trusted' executables to prevent bad things. And they attach Admin rights to a subset of normal users. So if a user with admin privileges happens to run an evil command accidentally, too bad. *NIX controls access to privileged functions in the OS. And treats root (admin) as a separate user. Even if you write an 'evil' executable, a normal user can only do limited damage (usually to their own files) when running it. And you just don't go

  • by Ecuador ( 740021 ) on Sunday September 17, 2017 @12:22PM (#55214485) Homepage

    Holy crap! If someone gets administrator access on my system, they can do bad things? With the SUBSYSTEM FOR LINUX, SPECIFICALLY???
    Seriously, /., what is this shit?

  • Under Windows 10 install Linux, load Linux and install Wine = Exploit. Video is now private, I can see why.

  • by mhkohne ( 3854 ) on Sunday September 17, 2017 @01:20PM (#55214739) Homepage

    AKA: Code execution results in code execution.
    Raymond has a whole series of these things:
    https://blogs.msdn.microsoft.com/oldnewthing/20070807-00/?p=25683

    Once you're able to run arbitrary programs as admin on a Windows box, the box is lost. Which particular set of arbitrary weirdness you choose to do to crash, compromise, or exfiltrate the data is pretty much irrelevant.

  • Well, I installed it on my 1703 build and there I was at the prompt:
    Username? Mac
    Password? This_day_we_are_gathered_together
    Repeat Password: This_day_we_are_gathered_together
    (rumble-rumble-rumble)
    Login: q!z (or something) - [I'd typed Mac]

    Evidently at login time bash decided that I was from Outer Mongolia or somewhere and gave me the appropriate keyboard. with totally strange key-mappings.

    Needless to say I couldn't log in at all, either as Administrator or Mac . . .

    Now that's what I call security!

    Hats off t

  • >> While many people welcomed the arrival of Windows Subsystem for Linux (WSL)

    Really? No one I know cares or takes it seriously. Hardcore windows users won't go near it because like evyerhting Microsoft does, its a crap implementation and is buggy as fuck, and hardcore Linux users (like me) don't want windows anywhere near anything we do, especially not the parent layer.

  • I see that Microsoft is quickly incorporating it's patented security model into Linux!

Practical people would be more practical if they would take a little more time for dreaming. -- J. P. McEvoy

Working...