With a growing number of cyber-attacks and the frequent news headlines on database breaches, spyware and ransomware, quality security products have become a commodity in every business organization. Consequently a lot of thought is being invested in devising an appropriate information security strategy to combat these breaches and providing the best solutions possible.
We have recently found a new and alarming method that allows any known malware to bypass even the most common security solutions, such as next generation anti-viruses, inspection tools, and anti-ransomware. This technique, dubbed Bashware, leverages a new Windows 10 feature called Subsystem for Linux (WSL), which recently exited Beta and is now a fully supported Windows feature.
This feature makes the popular bash terminal available for Windows OS users, and in so doing, enables users to natively run Linux operating system executables on the Windows operating system.
Existing security solutions are still not adapted to monitor processes of Linux executables running on Windows OS, a hybrid concept which allows a combination of Linux and Windows systems to run at the same time. This may open a door for cyber criminals wishing to run their malicious code undetected, and allow them to use the features provided by WSL to hide from security products that have not yet integrated the proper detection mechanisms.
Watch the Demo of the Attack: https://youtu.be/fwEQFMbHIV8
Bashware is so alarming because it shows how easy it is to take advantage of the WSL mechanism to allow any malware to bypass security products. We tested this technique on most of the leading anti-virus and security products on the market, successfully bypassing them all. This means that Bashware may potentially affect any of the 400 million computers currently running Windows 10 PC globally.
Following this discovery, we updated our SandBlast Threat Prevention solutions, to protect our customers from Bashware. We call the security industry to take immediate action and to modify their security solutions to protect against this new method.
BASHWARE
The Bashware technique leverages the underlying mechanism of the Windows Subsystem for Linux (WSL). This feature, introduced as part of Windows 10, allows native Linux ELF binaries to run on Windows. Before diving into Bashware’s internals, we will first review the inner workings of WSL.
WSL overview
The WSL feature goes far beyond having the familiar Linux “Bash” shell on Windows OS.
It contains both user mode and kernel mode components, which together create a complete compatibility layer for running an environment that looks and behaves just like Linux, without having to fire up any virtual machine.
Microsoft aimed to run the target application and OS entirely within the user-mode address space of a single process, by implementing a way to run an application in an isolated environment, with reduced overhead. In order to allow this new concept, Pico processes were introduced. Pico processes are the containers that allow running ELF binaries on the Windows OS. These new types of processes are minimal and lack the structural blocks that are commonplace in regular Windows NT processes (PEB, TEB, NTDLL, etc.).
By placing unmodified Linux binaries in Pico processes, WSL enables Linux system calls to be directed into the Windows kernel. The lxss.sys and lxcore.sys drivers translate the Linux system calls into NT APIs and emulate the Linux kernel.
The WSL concept originally started as the Astoria project and Drawbridge project, designed to run native Android applications on Windows systems. Later on, it shifted its focus and became the foundation for the service available today.
Following multiple issues found in WSL’s initial release, Microsoft decided to offer this project in beta mode, and add a support section on their GitHub page to gather live issues from the community. After fixing most of the issues raised by the community and reaching a somewhat stable version, Microsoft officially announced the release of WSL at July 28, 2017. The service will become available on the public release, starting from the Windows 10 Fall Creators Update (FCU), scheduled for October 17.
Although WSL has become a stable feature and many of its issues are now resolved, it seems the industry has still not adapted to the existence of this strange hybrid concept which allows a combination of Linux and Windows systems to run at the same time. This may open a door for cyber criminals wishing to run their malicious code undetected, and allow them to use the features provided by WSL to hide from security products that have not yet integrated the proper detection mechanisms.
Additional information regarding WSL internals can be found in “Appendix A”.
Bashware Explained
Bashware is a generic and cross platform technique that uses WSL in order to allow running both ELF an EXE malicious payloads in a stealthy manner that could bypass most current security solutions.
The key to the technique lies within the design of the Pico process structure. The Pico process has none of the common windows process characteristics, and in fact – nothing that would identify it as a regular NT process at all. Nevertheless, Pico processes have the same capabilities as normal NT process and do not pose any less threat.
Bashware loads the malicious payloads in 4 major steps:
Step 1: Loading WSL components
In order to take advantage of WSL, Bashware must first verify that the WSL feature is enabled; this is achieved by inspecting the state of the Pico drivers (checking if lxcore.sys & lxss.sys are presented in the windows drivers’ path). In cases where the feature is disabled, Bashware will load the drivers using the DISM utility. This method appears to be the simplest, and the one that does not raise any suspicion. This way, by running a single command line silently in the background, invisible to the user, Bashware loads the WSL components and is ready to move on to the next step.
Step 2: Enabling developer mode
A common assumption is that the risk of abusing WSL is minimal, since it requires developer mode to be manually set by the user. However, it’s a little known fact that all it takes to enter developer mode is setting these registry keys:
HKLM \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ AppModelUnlock \ AllowAllTrustedApps
HKLM \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ AppModelUnlock \ AllowDevelopmentWithoutDevLicense
Although these values are set by TrustedInstaller, this can be easily done by any user (or application) running with local admin privileges.
WSL feature was defined as a beta version and could only work when developer mode is enabled.
There is no native validation or any advanced security checks to verify these values or their modification. Bashware abuses these registry keys by turning them on instantly, for just long enough to allow it to perform its malicious actions. Once Bashware’s operations are complete, the keys are turned back off making this operation practically invisible.
Step 3: Installing Linux
Although Bashware has by now enabled WSL and entered developer mode, the Linux instance still doesn’t contain any file system. The next step for Bashware is to download and extract the Linux file system from Microsoft’s servers.
The user management installation is done by “Lxrun”, using the /install option. “Lxrun” command-line interface downloads and installs the file system on Windows PC. The Linux-facing file system in WSL is Ubuntu 16.04, which comes with regular support for UNIX rights. Bashware uses the Lxrun.exe utility, which downloads the Linux file system from Microsoft servers. This process seems legitimate and runs silently.
It’s interesting to note that during our research we have found that this installation process is also vulnerable to a race condition vulnerability, which will be explained in depth in the “More Security issues” section below.
Step 4: Wine
Now that Bashware has set up a fully-fledged Linux environment on the Windows system, and is able to execute anything on both environments, the question is what could it do next?
Obviously, our final goal was to show that we can run malware attacking the Windows system from the Linux instance, although malware is not designed to be cross-platform in that way. We found that Winehq project is the perfect solution for that – a free open-source compatibility layer that allows Microsoft Windows programs to run on Unix-like operating systems. Even better – for those unfamiliar with it – Wine is not an emulator, but rather it translates Windows API calls into POSIX (Portable Operating System Interface), which is perfect for our needs.
This is exactly what we needed in order to make a Windows malware run from the WSL environment, turning it invisible as well. Bashware uses the Winehq project capabilities and installs a pre-optimized wine project into the WSL Linux environment.
Next, EXE formats need to be converted by Wine, turning its NT syscalls to POSIX syscalls. Later on, the Pico provider (lxcore.sys) will convert these POSIX syscalls back to NT syscalls, turning lxcore to the actual caller of this process. This way, a file running on the Windows OS can execute any known malicious payload from the Linux OS, where it remains hidden from most security products.
Conclusions
As “Bashware” completes these 4 steps, it becomes a perfect demonstration tool for running any malware undetected, bypassing the most common security products – anti-viruses, inspection tools, debugging tools, and more.
Bashware does not leverage any logic or implementation flaws in WSL’s design. In fact, WSL seems to be well designed. What allows Bashware to operate the way it does is the lack of awareness by various security vendors, due to the fact that this technology is relatively new and expands the known borders of the Windows operating system.
However, we believe that it is both vital and urgent for security vendors to support this new technology in order to prevent threats such as the ones demonstrated by Bashware.
Microsoft has already taken steps that should assist the security vendors to deal with the new security considerations presented by WSL, including a Pico APIs that can be used by AV companies in order to monitor these types of processes.
More Security Issues – Double Privilege Elevation
During WSL’s installation process, “LxRun.exe” is responsible for downloading and extracting the Linux file system from Microsoft’s servers. Under the hood, the filesystem is saved in a hidden folder under %APPDAT% directory as a file named “lxss.tar.gz”.
After saving the filesystem archive, “LxRun.exe” then continues to extract it into the same directory. After this task is finished, the hidden folder contains a full Linux file system, later used by WSL, and more specifically by BASH.exe.
Microsoft has taken a lot of effort into protecting the Linux file system itself, such as prevention of Linux init modification, common injection techniques (such as LD.SO.PRELOAD previously discussed and disclosed by Alex Iounesco). But what about the protection mechanisms for the file system itself?
During our research we noticed that the Linux installation process is vulnerable to a simple race condition. If an attacker manages to modify the file system archive after it was downloaded but before it is extracted, there is no check to validate the authenticity of the file system. Thus, it allows the attacker to completely change the file system and load any Linux file system.
The main issue related with implementing this technique is recognizing the exact time in which the archive should be switched. Luckily for us, Microsoft calculates a SHA256 for the downloaded file system, which saves the hash value into a file right after the download process is complete and before extraction begins. For some reason, there is no other use for this value, other than signaling when to switch the file system archives.
When a user wishes to use WSL, he runs “Bash.exe”, which is executed with the user’s permission. In every WSL run, NTFS partitions are automatically mounted under /mnt in the Linux environment, granting the ability to read write and execute NTFS from within the WSL.
If a threat actor utilizes an admin token to launch Bash.exe, then Bash.exe + children will execute with full Admin token, including all privileges causing UAC bypass on the Windows side and full privilege escalation on the Linux side.
References
- Official Microsoft’s Blog and GitHub on WSL:
- Alex Ionescu’s repository on GitHub:
- https://github.com/ionescu007/lxss – Dedicated to research, code, and various studies of the Windows Subsystem for Linux used as great source of information and inspiration for this project.
- Wine project – a free open-sourcecompatibility layer that allows Microsoft Windows programs to run on Unix-like operating systems. https://www.winehq.org/
Appendix A
WSL – Windows Subsystem for Linux
Following security researches who pointed to the security bugs within it, Microsoft had opened a GitHub page for WSL, where people could report bugs. Microsoft also took several security measures, such as shipping Windows 10 with the feature off by default. This means that WSL drivers and user-mode management service components are not being loaded to the memory until the WSL feature is enabled manually (we will further explain this below). Furthermore, the feature was defined as a beta version, and could only work when developer mode was enabled.
The WSL feature goes far beyond having the familiar Linux “Bash” shell on Windows OS. It’s a complete compatibility layer for running an environment that looks and behaves just like Linux, allowing it to run any type of Linux code: Linux build system, GNU tools and anything else needed in order to build and test your application without having to fire up any virtual machines.
WSL contains both user mode and kernel mode components:
- User mode session manager service, which handles the Linux instance life cycle (LxssManager.exe).
- Pico provider drivers (lxss.sys, lxcore.sys) that emulate a Linux kernel by translating Linux system calls.
- Pico processes (“Minimal processes”) that host the unmodified Linux executable (e.g. /bin/bash).
At the heart of the WSL design is a new type of process, called Pico. Pico processes are minimal and lack the structural blocks that are common to regular Windows NT processes (PEB, TEB, NTDLL, etc.). Pico processes are the containers that allow running ELF binaries on the Windows OS.
The concept of a Pico process was first introduced in a project called Drawbridge, and was originally used to run an application in an isolated environment (a form of virtualization for application sandboxing).
One way of establishing an isolated environment is by using a virtual machine, but this approach might cause resource overhead. The Drawbridge project aimed to reduce this overhead by running the target application in a lightweight and secure container. The container has an isolated address space and is serviced by a component called “Security Monitor”.
Despite being virtually empty if examined from within the Windows OS, Pico processes have the ability to interact with a Windows NT Kernel. The interaction is achieved by the Pico provider – a special driver which is responsible for the transition from Linux ELF to a running Windows executable.
WSL uses Pico processes as containers for native Linux binaries. Pico processes are being monitored and serviced by a kernel component called ‘Pico Provider’ (implemented in lxcore.sys). The Pico Provider driver dispatches system calls and user mode exceptions made by the various Pico Processes. This processes/provider architecture provides the foundation for the Windows Subsystem for Linux. The end result of this architecture is the ability to run native unmodified Linux binaries by loading executable ELF binaries into a Pico process’ address space and executing them above Linux-compatible layer of syscalls.
(Drawbridge project) (WSL)
System Calls & Pico Providers
WSL executes unmodified Linux ELF64 binaries, by virtualizing a Linux kernel interface on top of the Windows NT kernel. One of the kernel interfaces that it exposes are system calls (syscalls), a service provided by the kernel that can be called from user mode.
The Windows Subsystem for Linux includes kernel mode drivers (lxss.sys and lxcore.sys). Pico providers are responsible for handling Linux system call requests in coordination with the Windows NT kernel. The drivers do not contain code from the Linux kernel but are instead a clean room implementation of Linux-compatible kernel interfaces.
Pico providers are essentially custom written kernel drivers which implement the necessary callbacks to respond to the list of possible events that Pico processes can trigger. When a syscall instruction is made, the NT kernel detects that the request came from a Pico process. Since the NT kernel does not know how to handle syscalls from Pico processes, it saves off the register state and forwards the request to the Pico driver (lxcore.sys). The Pico driver then determines which Linux syscall is being invoked, by inspecting the rax register and then passes the parameters using the registers defined by the Linux syscall calling convention. After the Pico driver has handled the syscall, it returns to the NT Kernel, which restores the register state, places the return value in rax, and invokes the sysret\iretq instruction to return to user mode.
User mode session manager service
While running the Bash terminal, there are numerous procedures running under the hood of Windows OS:
- exe – a Windows launcher service that communicates with the LxssManager.exe and spawns a new instance of WSL, executing the desired process.
- exe – a user-mode management service (the LxssManager.dll service living in SVCHOST.exe), which provides an external-facing COM interface, passing information to the Pico Provider through its Device Object.
- Pico Provider driver (LXSS.SYS / LXCORE.SYS) which provides the kernel-mode implementation of a Linux-compatible Kernel ABI and API, as well as a Device Object (\Device\lxss) for command & control.
The detailed procedure explained above launches the Pico process that contains the Linux environment. This Linux instance enables running ELF binaries through an interface which lxcore.sys exports. Lxcore.sys intercepts all ELF syscalls and adapts them into NT syscalls.
At the end of the day WSL is a very useful and innovative feature that provides developers with the familiar Bash shell and Linux environment in which they can run most Linux command-line tools, eliminating the need of creating a Linux virtual machine. However, there is limited security awareness with regards to the WSL design, which allowed us to take advantage of this feature and run undetected malicious code inside a Linux instance.
Appendix B
(BASH.exe – image from https://msdn.microsoft.com/en-us/commandline/wsl/faq
转载请注明：江海志の博客 » Beware of the Bashware: A New Method for Any Malware to Bypass Security Solutions