Meet the new guy on the block: BASHware and its use in the WSL
This post is also available in: Spanish
Meet the new guy: BASHware and its use in the WSL
In this blog we published last year, an interesting insight of the penguin’s OS in the field of proprietary software, specifically in Microsoft® Windows®. Redmond’s company had just finished its beta phase of “Windows Subsystem for Linux”® (WSL), and we asked ourselves: “Is there security in that environment? ”.
Our rhetorical question was answered at the Rootedcon 2018 Computer Security Congress, held in the city of Madrid in March where the Checkpoint team made a presentation on the subject.
Approach of the theoretical framework
Every time a work tool is added to any software, there will always be incidences -or “bugs“- that can even be analyzed to see if they can have sneaky intentions. Originally, Microsoft® clearly explained the limitations of the WSL: it was not for production (databases, web servers) nor did it support graphic programs. In short, it was just, as we say, an “amusement park” for programmers (both hackers and crackers). In the case of us hackers, this feature saves us a lot of time, since the scripts that we have written for GNU/Linux can be executed in that private environment, but always modifying the environment variables (in any case the work of adaptation is minimal, the unit “C:\” is mounted as “/mnt/C/user”.
In order to enable the “Windows Subsystem for Linux” – which, has nothing to do with the Linux kernel, since GNU utilities really run on the Windows® kernel – you need administrator rights and you need to restart the computer. Although this fact is comforting we must take into account the following: every day Windows 10® occupies every new computer, because it comes with that operating system preinstalled. Who guarantees us that it is disabled, by default? The latter approach is derived from point 15 of the GNU General Public License: “The entire risk of both the quality and performance of the program is at your own expense,” i.e. the final responsibility for our systems always rests on our shoulders.
We must clarify that The people from Microsoft have pronounced on the matter and have refuted that this is a vulnerability of Windows® and that they will not dedicate more time to the matter (nowadays, there are no news about it), but here at Pandora FMS it is our duty to analyze as many scenarios as possible and to provide the tools; Monitoring also includes future events. We’ll write from the point of view of how it might affect our systems.
Monitoring with Pandora FMS
Another very remote possibility, more direct because it is aimed at specific local or virtual networks, is that an actor who has control over some “Active Directory” orders the WSL enablement in hundreds or perhaps thousands of machines that connect to that domain (companies and complete branches). All antivirus programs and substitutes will not detect such changes because they are simply Microsoft® applications, legitimate and digitally signed, hence our responsibility to have knowledge of such an event.
This is when Pandora FMS and its flexibility can help us in our work: we publish an introduction to log monitoring (includes link to check the approach under Pandora FMS), as well as an article in which we explain the difference between filtering and selecting “syslogs” (that are generated even when we activate some Windows® feature), which are part of the common monitoring metrics in modern operating systems. That’s why the flexibility, we insist, is patent: we can configure Pandora FMS so that it informs if some characteristic is incorporated to some computer monitored by us.
This is used to suggest that antivirus applications start taking an “inventory” when they are installed and show a warning -or block it – of possible weaknesses. We also distinguish between what is already installed and the changes made: the first is the task of the antivirus, the second are events that can -and should- detect the monitoring tools.
“Malware” comes from the contraction of “malicious software” and as the first word comes from Latin malitiosus. But here’s our point: massifying the term “BASHware” with malignant denotation is incorrect, “malware” exists applied in different ways because the tools that we, the network administrators, migrate are entirely innocent. Now, if a person with malicious intentions develops scripts in BASH then we are talking about “badBASHware”.
Steps to use BASHware
Windows® has always integrated its own command line, but from Windows Vista® onwards it has a more powerful tool created to match the BASH/GNU features: Powershell®.
With this tool (Powershell®) we explain the next steps:
Enabling WSL in Windows 10®
Yes, WSL is only for Windows 10®, although in the last one we enabled the remote tools for a virtual machine with Windows 7®. Powershell is active by default, we run it with administrator rights and enter the following command (we must then restart the computer or simply wait for some other frequent Windows Update® task to do it):
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
It is also possible to enable it through a Windows terminal window:
dism /Online /Enable-Feature /All /FeatureName:Microsoft-Windows-Subsystem-Linux /NoRestart
WSL: enabling developer mode
The second thing we have to enable – and that makes the process we are proposing even more difficult – is the developer mode and making it permanent. This is accomplished by modifying (or adding) a key in the Windows® registry.
Warning: mishandling the Windows registry can lead to system corruption and even prevent system startup and even recovery. Please always test on disposable virtual machines.
In order to do this we use the command “New-Item“, to add the following key:
New-Item -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock" -ItemType Directory -Force
and define its property with this one, a little longer:
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock" -Name AllowDevelopmentWithoutDevLicense -PropertyType DWORD -Value 1
Since we must check if such a key exists before setting the property to a value other than zero, system administrators like to develop scripts to save us from repeating the task again and automating everything. In this link you will be able to read a complete script ahead of its time -year 2016- and the only objection it is that it doesn’t capture the response of the New-Item command and then register in the syslog the work done with its own function intended for that purpose, called Write-CMLogEntry. A hacker cares to record for the audit logs we mentioned in section 2.1, a “cracker” is not aware of this as it boasts about not leaving a trace!
Choosing Favorite BASH
Not many to choose from, but Microsoft has behaved democratically by adding more GNU distributions in addition to Ubuntu, which is the default. To date there is support for:
- openSUSE Leap
- SUSE Linux Enterprise Server
- Debian GNU/Linux
- Kali Linux
- Short-term: Fedora
- And many more are on the way
The most logical thing is to write for Debian and its son, Ubuntu. In any case, if we want to know which we have available we introduce:
If Ubuntu is listed, without further delay:
wslconfig /setdefault Ubuntu
Or the one you need or want, changing the last word for one of the ones that appears in the list. We are already halfway towards achieving our BASHware test!
Configuring the default user
The goal here will be to guarantee the necessary privilege, another setback for the reason of the statements of the personnel of the software of the popular window; we execute it in a sale of Windows 10® commands:
- Ubuntu: «ubuntu config –default-user root»
- openSUSE Leap 42: «opensuse-42 –default-user root»
- SUSE Linux Enterprise Server 12: «sles-12 –default-user root»
Needless to say that since we are here we will be able to create our users for different tasks, that is, each user will leave different registers according to the BASHware assigned to execute. With the famous command to add users:
sudo adduser new_user_name
The icing on the cake: syslog, the event logger, although preinstalled, is not enabled by default in WSL. That problem is still open on the Github page at the time of writing and that is out of our reach and it’s a good thing we always keep it in mind.
We quickly explained that Wine is software that, installed on GNU/Linux, allows certain Windows® applications to run. This is where the very remote possibility presents itself: to be able to run programs beyond the reach of antivirus programs or Windows® itself. Precisely, monitoring takes care of keeping track of these situations, although the line separating the tasks of security and monitoring is extremely thin. To illustrate this point we will say that, by way of example, data is one thing and information is another: the latter is obtained from the former by means of a process or algorithm (monitoring); this information is converted back into data when requested by the personnel in charge of security.
To install Wine, if we choose Debian or Ubuntu:
apt-get install wine
We may well install a graphical system for WSL and run Wine but we don’t want to go that far; in Wikipedia there are instructions on how to do it.
While this article is written from the point of view of a possible vulnerability, we have also focused on the antivirus defenses and the control mechanisms of the OS itself against possible malBASHware. Also remember at all times that Pandora FMS is always and will be a useful tool due to its flexibility, which we can adapt to our work and the personalized alarms we have created. We can add your possible results to the Integria IMS incident management software, since it has the ability to take hardware inventory, as well as to record and categorize the requests of your users in your technical support center. Ten, a hundred or even thousands of computers: both programs are capable of satisfying the demands of your work!