Windows Subsystem for Linux: Addressing Security Misconceptions and Risks

One of the great features of Windows is its ability to run Linux distributions through the Windows Subsystem for Linux (WSL). However, have you ever considered what actions you can perform in this Linux environment and how they might impact the security of your main Windows system? Before using this capability, it's important to understand the types of components you’ll be working with in the subsystem and what your end goals are. Will you be handling malware samples or installing unknown packages?

Challenge: 1. By default when you are first time installing it on you machine WSL HAS FULL ACCESS TO YOUR LOGICAL DRIVE ROOT In this screenshot, you can see that the OWNER, GROUP, and OTHERS all have full access to my host's logical drive C:/. This level of access creates a security risk: if malware runs within WSL, it could potentially access and dump sensitive files from the root Windows directory. The malware could then use tools like curl and other Linux components to exfiltrate these files to a destination server controlled by threat actors. And no any EDR will not be able to catch the activity even if you have it on HOST machine .

To resolve that challenge need to umount logical drive C from terminal

umount /mnt/c(C is my OS drive)

Then change owership of mnt folder to root user

sudo chown root:root /mnt/
sudo chmod 700 /mnt/

2.In WSL (Windows Subsystem for Linux), using crontab for scheduling tasks can be problematic because it doesn’t persist across sessions. In other words, crontab jobs might not be reliable since they can disappear when you close WSL. Therefore, for regular task scheduling, it's better to use alternative methods, as relying on crontab in WSL may not be effective for daily use.

To resolve that challenge need to close access for any user instead of ROOT

sudo chmod 700 /usr/bin/crontab

3.WSL (Windows Subsystem for Linux) doesn’t have strong network restrictions or firewall settings. This means that if there’s a security threat or malicious software running inside your WSL environment, it could potentially access and explore your host network. Essentially, WSL’s lack of strict network controls might allow harmful code within WSL to interact with your host machine’s network.

To resolve the issue, you need to identify the subnet used by WSL and configure your firewall to drop all packets destined for that subnet. However, to ensure that you still have internet access, you should also allow packets destined for the 0.0.0.0/0 subnet, which covers all external addresses.

sudo iptables -A OUTPUT -d RouteIP -j DROP

sudo iptables -A OUTPUT -d 0.0.0.0/0 -j ACCEPT

4.Usual jail solutions like FireJail and SELinux do not work in WSL2. As a result, processes and other components within WSL2 are not protected by these security mechanisms. This means that in the event of a zero-day vulnerability or similar security issue, your WSL2 environment could be at risk. Consequently, the absence of these traditional security features could potentially expose your environment to greater risk.

Since there is no out-of-the-box solution, you need to combine built-in components like chroot and other components to mitigate the risk of being impacted.

Conclusion: In my opinion running unknown code on WSL is risky because it's generally better to run such code on the host system where you have robust endpoint protection layers. The chances are higher that an extended detection and response (XDR) solution running directly on the host OS will detect threats more effectively than within WSL. For information security professionals, using WSL for malware or unknown tool testing is not advisable. The best approach is to use Hyper-V, Windows Sandbox, or other virtualization tools specifically designed for these purposes, where developers have already addressed the isolation challenges between the host machine and the virtual environment.