12 minute read

The Windows Subsystem for Linux

The Windows Subsystem for Linux or WSL2 allows you to run full Linux distributions under Windows. We will install Kali Linux in wsl2 and have a look at some options. Kex is using TigerVNC and is a nice solution, but there is an easier and more transparent way of using X11 apps in WSL2. In the video we will just launch the xfce4 panel inside WSL2 and show it on the Windows desktop. We will use the Hyper-V console to create a virtual switch and map it to the WSL2 container using the .wslconfig file. I’ll explain the X11 integration with Wayland, Weston, WSLG, FreeRDP and MSTSC. #kalilinux #wsl2

Watch the video on YouTube

Click to view the entire transcript Welcome back to the third Kali episode. Let’s have a look at the Windows Subsystem for Linux or WSL today. There’s a bunch of videos on YouTube already showing how to get WSL and how to run Kali – or any other Linux of course – on a Windows 10 or 11 Workstation. But things have become much easier than in the early days. We’ll see this in a minute. The interesting part for the Kali Linux user however will be two things: First, a closer look at the networking and second how to integrate everything really seamlessly into the Windows desktop. Without any workarounds like kex or rdp or vnc or the like. Just like you can see it here on my screen – I have the Kali menu bar on top of my Windows desktop. But first the installation. Oh and – as I said in the last two videos – this video is not about “hacking xyz with Kali Linux” – I really think that many of these videos are click bait. People showing how to crack Wi-fi or passwords with simplified setups that have nothing to do with real-life scenarios. If you want a real introduction into ethical hacking then please check out the YoutTube channel of Offensive Security or short OffSec (they are the creators of Kali Linux). The link is up here as well – You might consider taking their courses or certifications. They do have a discord server as well. Also - check out this video by fellow Youtuber Heath Adams – the cyber mentor. It’s a 12 hours long course – but nicely sliced into chapters. Have a look – it’s really good. Back to WSL2. Installing WSL2 these days is as simple as typing this command in a command shell or Power shell: wsl –install and optionally -d and the name of the distribution that you want to run, for instance debian or ubuntu or of course kali-linux. You do not have to type any other power shell commands or the like. That’s gone. Alternatively you can install debian or kali-linux or ubuntu from the Microsoft app store. Once installed you can list them with wsl -l -v which will also show you the version of wsl. We will solely talk about version 2 in this video. What this will also do for you automatically is that it enables two Windows features, namely the Virtual Machine Platform and the Windows Subsystem for Linux. Launching a bash shell now is as simple as typing wsl or bash or ubuntu or kali-linux. That will all do the same: start WSL2 and show a terminal running the bash. From here you can now install all the software that you want – let’s do this similar to what we did in the first episode – I’ll install kali-desktop-xfce4 and this time let’s not use xrdp as a remote access protocol but rather win-kex which is in fact TigerVNC with a nice desktop integration. We’ll have a look into another very nice option for Windows 11 later in this video where we will actually run only the menu bar on the windows screen. But let’s use kex for starters. Once I type kex in the bash it will then ask me for a connection password and also launch the kex viewer where I can type that password in. Here we go. Kali running on my Windows desktop. Cool – so the first thing that I want to draw your attention to is actually the network setup. I’ve briefly touched on this in the first two episodes. If we type ip -br addr in a terminal window inside Kali then we can see this 172. something address here. And that might be quite surprising to you because usually your PC probably has a 192.168.something address right? How come? And what are the implications? The secret is lifted if you go to the network adapter properties on your Windows host. In fact you can see your Ethernet and or Wifi hardware here. Plus – you may or may not see an additional virtual network adapter called Hyper-V Virtual adapter or the like. If you can’t see that then type ipconfig /all in a separate Windows shell and it should show you that. And actually the MAC address of that adapter is identical to the MAC address inside WSL which I can show with ip link. The reason for this behavior is that WSL2 as such is running inside a virtual machine based on hyper-V and that virtual machine has that virtual network adapter attached to it. Network-wise it actually works as a NATed network behind your host’s network interface. Inside that VM the WSL distributions are running as containers. If you wanted to access the VM or an app running inside Kali from the outside world then the suggested Microsoft solution is to do a port forwarding or Port proxy like they call it. This needs to be done in Power shell. Or – hot off the press – as of June 2022 you can actually bridge your physical adapter on your host to WSL. That would then behave as if the network was physically attached directly to the container. Here’s how to do it: You define a virtual switch using either Power shell or the Hyper-V console and then you add the following into a file called .wslconfig into your C:\users\yourusername directory on the windows host. First you specify networkingMode = bridged and then you specify the virtual switch saying vmSwitch = Bridgename. At the time of making this video this is only available in the preview version but I’d assume that this will go mainstream rather sooner than later. I’ll update the description of the video or pin a comment to it. At the moment though this seems to be work in progress. On a Windows 10 I can actually see two network adapters eth0 and eth1, where eth1 is the physical adapter. I did not specify the .wslconfig file. Also there is no Hyper-V switch on an external adapter. On Windows 11, using Hyper-V console I can see the WSL switch and it does get assigned an IPv6 address, but not IPv4. I did specify bridged mode in the .wslconfig though. Guys, leave me a comment if you see similar things. If you want this to work as designed, then as of June 2022 you need the Preview version of WSL. Browse to this URL. That will open a Microsoft store instance from where you can now install the preview version. Next you need to launch the Hyper-V Manager, then click on virtual switch manager and create a new external Virtual Switch. I named mine WSL2. Guys, I am not sure if you can actually do that with the Home versions of Windows 10 or 11. I don’t have a home version to test unfortunately. Leave me a comment please. Once you have created that switch and restarted wsl by doing a wsl –shutdown and launching it again, then you should see the physical address if you type ip -br addr. Also – now you can launch the tools that need direct network access like I do here with Wireshark – seems to be working, it’s capturing packets at least. So why would you want to use a physical adapter rather than a virtual one ? After all, we can access the internet with the virtual one, can’t we ? Well yes, if you wanted to scan your website for vulnerabilities with let’s say metasploit then you can of course do that with any adapter type. But if you wanted to do stuff like I showed in this video here like analyze network flows of a different device using arp spoofing, or if you wanted to analyze packets going over a switch on a mirrored port then you really need a physical adapter. A little side note here – if you want to try out Windows 11 on unsupported hardware without TPM or secure boot or even run Windows 11 with Hyper-V in a VM running on Linux KVM/QEMU or in Proxmox, then check out this post on my blog. You can actually do that. It works. You just need Proxmox 7 with a Kernel Version 5.15 or above. Awesome. That should shed some light on the network aspects of WSL2. Now let’s have a look at how we can nicely integrate the Linux desktop into our Windows environment. Now – you might remember that I have spoken about X11, the display manager and the window manager in the first episode. As an example I launched the xeyes application over ssh and it would show up on my Linux box but not if I did the same thing in Windows 10. With Windows 11, things have changed a bit. And they have changed for the good actually. Let me show you this. Here’s what happens when I launch xeyes in a wsl bash shell on Windows 10. It tells me it has no display. Because I don’t have a Window Manager. See what happens if I do the same thing on Windows 11. Tadaah – xeyes opens in a separate window. So does Windows 11 have an integrated Window manager such as xorg or xWayland ? Surprisingly it does not. What you see here is actually an instance of mstsc.exe, the Microsoft Terminal Services client. You can see it here in the task manager. When I shutdown wsl, it disappears and it reappears when I restart it. But wait – we don’t have xrdp running as an endpoint inside WSL, do we ? No, we don’t. In order to understand this we need to have a quick look at the wslg implementation on Windows 11. That subsystem actually runs inside the WSL Virtual machine and has the following architecture which we can find on the wslg Github site. The core of this is a pimped implementation of Weston. Weston is a reference implementation of a Wayland compositor. Wayland in turn aims at being the successor to the native X11 implementation. Now I do not want to go too deep into the tech details here but there’s actually a couple of things that are important to know for us. Even though the Window manager, so Wayland and Weston, are not running on Windows but rather inside the WSL2 VM, Microsoft have actually taught weston and their Terminal Service Client a couple of new tricks. You can see this FreeRDP running inside the WSL VM. MSTSC connects to that instance from the Windows side and just displays the X11 or Wayland app in a transparent way. And it comes up automatically whenever we launch a GUI app inside WSL. That app would either connect to the X11 display on that Xwayland process here or – if it is a wayland app – connect to the wayland socket of Weston. How can we leverage that knowledge to actually integrate our KALI linux menus nicely into Windows without adding tools or overhead such as xrdp, tiger vnc, kex, x2go – you name any remote access tool ? After all, everything is there – we just need to use it. The thing is – if we would try to just launch an xfce4 session for example in this bash window by typing startxfce4 or xfce4-session then I get an error saying that it has problems accessing the wayland display. Now – if we look at the environment variables then we see this WAYLAND_DISPLAY setting here. If I wanted xfce4 to go through the X11 display then all I’d have to do is actually set this variable to an empty value. Like this. If I now launch startxfce4 again, then the session comes up. It shows the xfce4 Menu panel and they do contain all the Kali menu items. But we get a lot of error messages here. That’s mainly because a full session tries to do a lot of things, such as provide communication between the windows and processes, launch audio and so on. But honestly – I don’t really need all that. I just want that menu bar on top of my screen. So let me interrupt this with Control C. If we look at the screen layout of a typical X desktop session then usually we have the menu bar on top, we have a background on the desktop and maybe additional items such as widgets and panels etc. And in X11 terms each one of those is a separate window. That means that the top panel that contains the menu shortcuts is just a window that the Wayland / Weston / RDP combination could show on my desktop. I can actually do that by just typing xfce4-panel. And yes – we already get fewer errors but the visible result is pretty much the same. On the first launch the panel might show up on a different screen or in the middle of the screen – so what you can do is either do a right click and select preferences here or open a separate wsl shell and type xfce4-panel -p. That opens the properties window here where I can actually do stuff like unlock the panel, so that I could move it or select the display and so on. Once it has stored those parameters, it comes up OK on the next launch. Awesome. Last but not least I would want this to happen automatically if I start up wsl. So what I can do is that I just add this line to the .bashrc file in my home directory. Kind of the poor man’s service autorun really. But it does the trick. I’ll set the Wayland display to an empty value, launch xfce4-panel in the background and I just pipe error messages to nirvana so that I don’t see them. Let’s test. Wsl –shutdown, then start it again. Takes a while. Aaand – here we go. Menu bar. Beautiful. I can launch all apps, the menu is just nicely present – but otherwise I can work with my Windows like I used to do before. That’s really transparent. Perfect. Awesome! Guys – that concludes today’s episode. Please let me know if you liked it. If so, a like on YouTube is much appreciated. Please do leave me a comment on Youtube. Many thanks for watching. Stay safe, stay healthy. Bye for now.