Cybercriminals have apparently developed a new method for any malware to bypass security solutions, according to Check Point Security Research.
“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 antiviruses, 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,” say researchers Gal Elbaz and Dvir Atias. “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.
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.
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 componentsIn 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 modeA 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 LinuxAlthough 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: WineNow 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.
Beware Bashware!
