Bashware: Malware Can Abuse Windows 10's Linux Shell to Bypass Security Software

Discussion in 'other security issues & news' started by itman, Sep 12, 2017.

  1. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    https://www.bleepingcomputer.com/ne...-10s-linux-shell-to-bypass-security-software/
     
  2. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Win 10 CE Fall Update:thumbd:
    https://research.checkpoint.com/beware-bashware-new-method-malware-bypass-security-solutions/
     
    Last edited: Sep 12, 2017
  3. TairikuOkami

    TairikuOkami Registered Member

    Joined:
    Oct 10, 2005
    Posts:
    3,418
    Location:
    Slovakia
    Great, it is not even out yet and it is already exploitable.

    Thanks for the article, I have added those tweaks thus far:
    Code:
    reg delete "HKLM\Software\Microsoft\Windows\CurrentVersion\AppModelUnlock" /f
    reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\DisallowRun" /v "8" /t REG_SZ /d "bash.exe" /f
    
    Not sure, how to disallow wine64 though, since it is not exe. :doubt:
     
    Last edited: Sep 12, 2017
  4. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    I am not sure deleting this key is OK. I believe it is "toggled" on/off by Trusted Installer installation. It is set on to allow Win 10 to install the non-Win10 app and then set off once the installation completes.

    The key to monitor is this one:

    HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock\AllowDevelopmentWithoutDevLicense
    As far as monitoring bash.exe, don't believe that is necessary. Appears to be a Win 10 app that is installed when Linux subsystem is installed via Win features setting. The only way Linux can be installed is by first entering Win 10 developer settings and enabling Developer mode. This sets the above key to a value of "1".
     
    Last edited: Sep 12, 2017
  5. TairikuOkami

    TairikuOkami Registered Member

    Joined:
    Oct 10, 2005
    Posts:
    3,418
    Location:
    Slovakia
    The key is empty by default, so removing it only resets it. Setting the two values to 1 enables it. Just DISM is good enough to enable WSL.

    Code:
    dism /online /Enable-Feature /FeatureName:Microsoft-Windows-Subsystem-Linux
    dism /online /Disable-Feature /FeatureName:Microsoft-Windows-Subsystem-Linux
    In the POC video, they have enabled WSL and then dev mode. WSL works when dev mode is disabled. Disallow policy prevents it from running.
     

    Attached Files:

  6. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Missed that one. Does WSL load bash.exe into the System32 directory? From your screen shot appears so.
     
  7. TairikuOkami

    TairikuOkami Registered Member

    Joined:
    Oct 10, 2005
    Posts:
    3,418
    Location:
    Slovakia
    Yes, but restart is required, so I do not quite get that POC video, it seems to do it in one session.

    EDIT: I have found a simpler solution. Take ownership of these keys and remove it or remove all users, it will prevent DISM from enabling WSL.
    Code:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\Microsoft-Windows-Lxss-Optional-Package
     

    Attached Files:

    Last edited: Sep 13, 2017
  8. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    They're running it remotely. Example here: https://stackoverflow.com/questions/40309030/using-dism-on-a-remote-host . Downright scary.

    Which leads me to believe if bash.exe was run the same way, this might not work:
    However, if you monitor any inbound/outbound communication from dism.exe, that should do the trick. Maybe not. I believe Win 10 does same for maintenance?

    The thing about their demo is the following:

    1. They established a backdoor and connected to the remote device through it.
    2. They used Netcat for everything else through the backdoor. Ref.: https://en.wikipedia.org/wiki/Netcat

    -EDIT- Another way would be a remote PowerShell session:
    https://www.petri.com/getting-started-with-dism-powershell-cmdlets
     
    Last edited: Sep 13, 2017
  9. ronjor

    ronjor Global Moderator

    Joined:
    Jul 21, 2003
    Posts:
    163,032
    Location:
    Texas
  10. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    This is typical Microsoft dishing FUD.
    In the uTube video Checkpoint posted, that(compromised) is clearly noted as I stated previously.
     
    Last edited: Sep 13, 2017
  11. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    This one gets my vote.:thumb: Export the key and save it if you later every want to use WSL later. Then delete the key.
     
    Last edited: Sep 14, 2017
  12. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Also, I don't know if this has "dawned on" anyone yet but the same technique could be used to install any Windows feature. For example, the deprecated and dangerous PowerShell v2 and SMBv1 that you previously uninstalled in Win 10.

    Additionally, no backdoor would be need in corp. environments that have RDP and Win Remote Management enabled as a rule. Just a network hack to those connections.
     
  13. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    To give Microsoft "credit where credit is do:
    https://www.infosecurity-magazine.com/news/bashware-flaw-threatens-400m-pcs/

    A few comments on the above:

    1. Does Windows Defender use the PICO API's for monitoring? Doubtful. But I "bet my booties" that WD ATP does.
    2. Will the rest of the security vendors employ them? They first would need a HIPS or sophisticated behavior blocker to do so. Again, I wouldn't "hold my breath" on this one.

    -EDIT- Also per the below, the PICO API's have been available for some time and no one appears to be using them for bash exploit detection:
    http://thehackernews.com/2017/09/windows-10-linux-evade-malware.html
     
    Last edited: Sep 13, 2017
  14. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Also here is Microsoft's statement of events:
    However what Checkpoint did was remotely install WLS, then enable developer mode to execute the rest of the attack. Micosoft's statement implies that WLS cannot be installed without enabling developer mode which clearly is not the case.
     
  15. guest

    guest Guest

    Some interesting information about WSL / Pico Processes, etc.:
    The Linux kernel hidden inside windows 10 / Blackhat 2016 / Alex Ionescu (August 2016)
    https://github.com/ionescu007/lxss/blob/master/The%20Linux%20kernel%20hidden%20inside%20windows%2010.pdf
    Excerpts:
    Code:
    Attack Surface Analysis
    216 system calls that can now result in possible local privilege escalation (700 kb attack surface)
    * Full Network access (within firewall rules)
    * Full disk access (with token rules)
    Process / Thread Notifications & Behaviour
    * Essentially no documented way to have visibility into the creation/termination of Pico applications
     Edit: Seems to be fixed in RS2, but it is "opt-in" (see Bluehat 2016)
    Image Load Notifications & Behavior
    * Nothing is ever loaded with SEC_IMAGE inside of a Pico Process - no PE files exist so no Image Section Objects can be created
    * As such, no callbacks received if registered through PsSetLoadImageNotifyRoutine
      * Careful: many security products rely on these callbacks [...] to see the .EXE itself loading [...]
      * Everything is ELF.
        * PE Parsers will not work/break
    Bash seems to be the launcher of WSL Processes:
    Even more information about WSL:
    Gaining Visibility into Linux Binaries on Windows. Defend and Understand WSL (Bluehat 2016, Alex Ionescu, November 2016)
    https://github.com/ionescu007/lxss/blob/6a3040fadff5ce43d7bfd638a4e5d7dfe8780143/WSL-BlueHat-Final.pdf
    Excerpts:
    Code:
    Visibility Issues in Brief ...
    * No integration with Enterprise Security: Applocker and/or Code Integrity and/or Windows Defender, AMSI
      * As long as someone can talk to LxssManager, spawning init + other binaries bypasses all checks
      * Doable from PS, even in Constrained Language Mode ("not a security boundary")
    "Process Issues" 
    * Actual unprivileged user -> admin vulnerabilities not issued CVEs/bulletins (!)
    "Additional Security Issues"
    * init is a special process in Linux environment - has immediate root privileges
      * Typically protected as well [...]
    * But init is located in unprivileged, user-modifiable location on disk!
      * Launched as Medium IL to mitigate obvious issues [...]
        * Extracted from signed LxssManager binary, but can be trivially bypassed with oplocked attack
    * If user utilizes admin token to launch Bash.exe, then Bash.exe + children will execute with full Admin token, including all privileges and High IL
      * Now you have a stealthy, untouchable, user-controlled medium IL binary that has full control over Linux binaries running with high IL and a full token
      * This is true of any binary, not just init - but init has additional protections and stealth granted to it
    
     
  16. Nightwalker

    Nightwalker Registered Member

    Joined:
    Nov 7, 2008
    Posts:
    1,387
    Isn't Microsoft right?

    If the malware is already running on the system it is gameover, like almost all attacks in the past.

    If the attacker has gained administrator privileges it means that the security setup has failed and the system is already doomed.

    This scenario remember me of some old discussions here on Wilders about the meaningless of antivirus self defense (kernel mode, rootkits and the like).


    https://twitter.com/GossiTheDog/status/907521043010654208
     
    Last edited: Sep 13, 2017
  17. guest

    guest Guest

    Exact, this is more a PoC that a serious threat that will infect millions...
     
  18. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Duh ........... It always helps to thoroughly read the article to understand the attack mechanism.:rolleyes: Sorry, I am getting up there in age and as such have good and bad days.

    To begin with, this Checkpoint POC has nothing to do with using DISM to enable the WLS feature. The attack is accomplished by using DISM to load the WLS drivers; that is all that is needed. So lets review the attack again:

    Step 1.
    Note that the drivers being loaded are valid code signed Microsoft divers which will get around any Win 10 driver restrictions. Also, you really don't need to use DISM to dynamically load a kernel mode driver. An app that many use i.e. Process Explorer, does so every time it starts up.

    Step 2.
    Step 3
    For reference, what this attack does is duplicate all the processes involved when WLS is installed manually via Windows Features option:

     
    Last edited: Sep 14, 2017
  19. summerheat

    summerheat Registered Member

    Joined:
    May 16, 2015
    Posts:
    2,199
    Unless UAC - provided that it's not disabled by the user - in its standard setting is bypassed somehow.

    Anyway, this is another example why the combo LUA + SRP is the right way to go.
     
  20. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    So how do we prevent this "bashware" attack? Before I get into that, the following comment.

    Win 8 and 10 at least have a kernel driver protection mechanism. The system will only allow a kernel mode driver to load from C:\Windows\System32\Drivers directory regardless of if the driver is loaded at boot time or dynamically. Additionally, non-Win 7 upgraded versions of Win 10 1607+ require that all kernel mode drivers be signed with a special code signing certificate issued by Microsoft. In any case, this means the driver has to be stored in the above driver directory prior to being loaded.

    To prevent this "bashware" attack, use a HIPS or whatever to create a rule to prevent the creation of lxcore.sys or lxss.sys files in the C:\Windows\System32\Drivers directory. If the "bashware' cannot find these drivers, it cannot load them and the attack will fail.

    -EDIT- Additional protection can also be had by monitoring in a HIPS the below reg. key used to enable developer mode for any write activity to it:

    HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock\AllowDevelopmentWithoutDevLicense​
     
    Last edited: Sep 14, 2017
  21. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Interestingly, Ionsecu"s .pdf from which @mood extracted from at GitHub appears to be missing many of the WLS security issues posted in his original .pdf posted here: http://alex-ionescu.com/publications/BlueHat/bluehat2016.pdf . One that stands out is:
    So the statement about monitoring of Pico processes by AV vendors "rings hollow" since Microsoft designed WLS to bypass all native and available Win 10 protections.:eek:
     
    Last edited by a moderator: Sep 14, 2017
  22. guest

    guest Guest

    The next step would be to integrate it (as mentioned in the BlueHat pdf)
    Whether they will do it or not, we'll see :doubt:
     
  23. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    Have to agree, but it's still something that IT experts should be aware of. I totally forget about Pico processes, I remember reading about this years ago. I thought it would be used for sandboxing, so I wonder if it's related to AppContainer.
     
  24. TairikuOkami

    TairikuOkami Registered Member

    Joined:
    Oct 10, 2005
    Posts:
    3,418
    Location:
    Slovakia
    Theory: You will get infected by it as soon as you turn on the PC.
    Microsoft: You are perfectly safe, we took care of everything.
    Reality: Somewhere between, unfortunately. :doubt:
     
  25. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    I will summarize what I believe was performed in this bashware attack by Checkpoint:

    1. Dism was not run from command line or proxy i.e. shell or script to install the WLS feature. This would not have been "silent" and the Pico drivers would not have been installed until reboot. Reboot would have clearly indicated a Windows update was taking place.
    2. It is assumed the Pico drivers were downloaded by the bashware and contained the data, i.e .inf files, to install the drivers. Again, DISM running from command line or proxy i.e. shell or script cannot add/load a driver into an online image.
    3. This leads to the assumption that the bashware initial download was a C/C++ program that used the Dism API to add and dynamically load the Pico drivers.
    4. At this point, security solutions like Emsisoft for example that employ a behavior blocker would be monitoring the assumed non-rep status bashware for suspicious activity because of the driver activity. Again, the drivers are signed legit ones.
    5. Next comes the modification of the developer mode reg. key. Since this requires escalation of privileges, it might just be enough for behavior monitoring to now throw an alert; especially when coupled with a driver installation.
    6. Finally comes the Linux installation via remote server download. Again a lot of system updating is being done; enough to flag it by behavior analysis if not done so previously.

    Chechpoint's video shows that Cylance was being used in the demo and was totally bypassed by attack. So much for its machine learning and AI algorithms. Also and noteworthy is security solutions without active behavior monitoring would not detect anything amiss by the above activity.

    Summarizing, it appears to me based on the above that some type of initial download was done to start the above processing. So anti-exec deployment would alert upon program execution although it is doubtfull that a product like VoodooShield would show it other than an unknown process. Additionally, I would think Win 10 native SmartScreen would also flag the process as "unknown" but you never know with its detection capability.

    -EDIT- Also most noteworthy is that on Win 10 preview builds 16215+ and this falls Win 10 CE update, you will no longer be required to enter Developer mode to install Ubuntu as noted here:
    https://blogs.msdn.microsoft.com/co...ger-required-for-windows-subsystem-for-linux/

    This will make the Checkpoint bashware attack much more plausible.
     
    Last edited: Sep 17, 2017
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.