Some of our technical security specialists attended the security conference Hack.lu on 16th- 18th October, to gain knowledge and to learn some new tricks and tools.
Geert Smelt reported about the talk 'Abusing Bash for Windows' by Antoine Cervoise on how to use bash on Windows (Cygwin, WSL) for privilege escalation and post-exploitation.
Windows Subsystem for Linux (WSL)
With the new CEO of Microsoft Satya Nadella comes a whole new direction for Windows. Nadella has expressed support for Linux and the first visible result from this is the release of the Windows Subsystem for Linux (WSL) -- commonly called Bash for Windows. It is a compatibility layer for running Linux binary executables natively on Windows 10 and Windows Server 2019 and was first released in August 2016 (1).
WSL provides a Linux-compatible kernel interface developed by Microsoft (containing no Linux kernel code), which can then run a GNU user space on top of it, such as that of Ubuntu, openSUSE, SUSE Linux Enterprise Server, Debian and Kali Linux. Such a user space might contain a Bash shell and command language, with native GNU/Linux command-line tools (sed, awk, etc.), programming language interpreters (Ruby, Python, etc.), and even graphical applications (using a X11 server at the host side). It can be considered as the Wine counterpart (2).
WSL vulnerabilities
Initially only an Ubuntu image was available, but with version 1709 of Windows 10 Fedora and SUSE have been added. Now that WSL has matured somewhat, we look at the vulnerabilities it brings to the table. Antoine Cervoise walks us through various weaknesses that have been discovered in WSL. The main difficulty with securing WSL is that it allows a user to execute both Linux and Windows commands on the same file system. This means that if a file is not readable from Linux it might still be readable from Windows and vice versa. One such an example is the /etc/shadow file on Linux, which stores all the password hashes for the users that have an account on the system. This file usually is only readable by the root user, which is the equivalent of the Administrator user on Windows. On a system that has WSL installed the file cannot be read by a non-root user, but when navigating to the shadow file in the Windows file system its contents actually can be viewed. The main weakness with this is that the hashes correspond to passwords that are valid both in the Linux file system and the Windows file system. Obviously this creates another attack vector for obtaining passwords for systems that have been compromised.
Besides reading files, Windows executables can also be called from Linux. This for example allows the user to run a command prompt processor within the Linux environment. It should also be noted that most antivirus software solutions cannot inspect WSL, opening up an attack vector for establishing persistence on an already compromised system through malware that is executed from within WSL. For such malware to be successful, it has to have a 64-bit architecture. Furthermore the task manager in Windows will show bash.exe is running, but not the actual process that runs within WSL. To prevent the process from shutting down, it can even be run within a tmux session (but not screen).
SMB authentication and fake sudo command
A different method of obtaining credentials is through the use of SMB authentication. Consider for example including a command in the Linux shell configuration that is executed each time the user enters the shell. By having the shell attempt to connect to a shared folder on the network, the SMB authentication attempt to this share can be eavesdropped upon with a tool called Responder. The hash that is then found can be cracked in order to retrieve the plaintext password, or can be replayed to authenticate to another server on the network on behalf of the victim's system.
Another interesting idea posed by Cervoise is the use of a fake sudo command. Cervoise creates a script that mimics the behavior of sudo and places that script in the user's PATH variable, before the actual sudo binary is found. This allows him to overwrite the default behavior and the user's password. Note that this attack is not limited to WSL, but can be performed on a regular Linux system as well.
Finally WSL can be used for circumventing AppLocker, the Windows element that prevents execution of any non-whitelisted executables. Cervoise does not go into much detail however.
Because WSL is relatively new we have most likely just started seeing the first vulnerabilities. Undoubtedly more vulnerabilities will be discovered and published in the nearby future as more and more developers and system administrators will start using it for their daily work.
At Secura we keep a keen eye on the news of such vulnerabilities in order to incorporate them into our tool set, to ensure you get the best service we can offer. Click here if you want to expand your knowledge on secure coding.
1. https://docs.microsoft.com/en-us/windows/wsl/faq
2. https://mikegerwitz.com/2016/04/GNU-kWindows