I want a "Red Teaming"
Michael Schneider
How to use Qubes OS in Windows Environments
For the penetration tests I conduct I need a system which offers a high degree of freedom but prefer a more locked down system to write reports on or otherwise handle customer data. For this reason, I considered switching my work system to Qubes OS in hopes of combing these two qualities on a single computer. Many other features Qubes offers are also enticing, such as the strong security assurances through virtualization provided by the Xen bare metal hypervisor and the flexibility of implementing many different system architectures. Qubes provides the tools to integrate multiple operating systems running alongside each other into functioning workflows.
Qubes has the concept of TemplateVMs. These VMs act as templates for other virtual machines called AppVMs. An AppVM inherits the file system of its TemplateVM but lacks the ability to persistently change anything on the template. From a technical perspective an AppVM uses the inherited file system regularly just like a normal VM would its native file system. However, all writes to disk are stored in a temporary CoW buffer which is destroyed upon VM shutdown. This approach makes it possible for the AppVM to handle the file system normally without needing special drivers of any sort and without having to trust the AppVM to leave the template unchanged.
This simple concept can offer significant security advantages. For example, a Windows image can be hardened and configured as needed in a first step. Then, an AppVM is created which uses the Windows image as a template. When one wants to use a Windows application, the application is started inside the AppVM. Every time the AppVM boots up, the fresh windows image is used. It is impossible to break anything on the system across reboots. Even when the AppVM is fully compromised during usage and malware embeds itself deep inside the operating system, the AppVM is squeaky clean after the next restart. This, combined with multiple AppVMs for different applications or applications with different security requirements, can contribute to a strong security posture.
An AppVM can persist data on the filesystem to explicitly whitelisted locations but this also does not change the template. The data is stored on separate storage belonging to the AppVM. The home directory is often unlocked for persistent writes in order to keep user files and app settings. It is good practice to limit write locations to what the specific AppVM requires. For example, an AppVM for Microsoft Word may only have access to Documents\
, AppData\Local\Microsoft\
and AppData\Roaming\Microsoft\Word\
.
A system like Qubes OS has the potential to provide improvements in two areas, namely client security and increased freedom for employees on the client.
Practically everyone will pursue tasks with different security requirements as part of their daily work activities. On monolithic systems such as Linux and Windows, all these tasks are accomplished or controlled from the same system. The same system which uses the lowly trusted browser chat application also talks to development and production environments, visits links in emails, executes the highly trusted password manager utility, and routinely opens files of complex formats from coworkers and externals. All these processes are supposed to be appropriately isolated by the operating system. The attack surface which needs to be secured by OS developers and through configuration by system administrators is huge. This is where a system like Qubes OS can show its benefits. Tasks with different security requirements can be isolated from each other in different VMs. VMs for highly trusted, security critical work can be locked down to without affecting any other task. For example, an AppVM for HR work can only access the employee management system. All other applications can be removed, and network accesses blocked on this VM. Such measures would be impossible to implement on a conventional work system.
In the security model of client systems, restriction of possibilities for attackers and monitoring are important tools to pursue desired security levels. Modern client systems in companies are thus often heavily restricted. More freedom for end users does come with increased risk. The heavy restrictions do however come at the expense of usability. Depending on the tasks that need to be accomplished, the restrictions can hinder productivity and ultimately affect employee satisfaction. Virtualization has the potential to provide a high degree of security without having to put such heavy restrictions on the entire client system. For example, untrusted applications can be installed and run without endangering sensitive data of another application on the same computer and without granting it access to the internal network.
A requirement for the work system is the ability to run recent Linux and Windows systems. The Windows system needs to be able to be integrated with Active Directory and the Microsoft Office suite must work. Microphone and USB-Devices also need to be accessible.
On the positive side, the UI integration of Linux and Windows systems is great. Qubes offers the possibility to have individual applications which run in their own VMs displayed in their own window, as if they ran natively on a monolithic system.
One can also access the complete desktop environment of a VM, like virtual systems are normally seen, if there is need to do so. The performance of Linux systems is not distinguishable from native systems. The UI on Windows systems is only slightly less responsive. As expected, there are no limitations to software inside virtual machines and the entire virtualized network stack left none of my wishes open.
The usage of AppVMs is not easy to combine with an AD joined Windows system and could not be integrated as part of my usage tests. Furthermore, there is no easy way to attach USB devices to a Windows VM, as USB passthrough is not supported here. The only way that could be identified was to pass through the entire USB controller to the Windows VM as a PCI device. If a Windows VM needs to access a USB device, the VM which currently controls the USB controller and the Windows VM need to be shut down, before control of the USB controller can be handed over. This requirement of shutting down VMs during ongoing work on these can of course be a major inconvenience. Since the entire USB controller is moved, all USB devices already passed through to other VMs are lost. Also, no VM can use USB devices while the controller is assigned to a Windows VM. This process can at least be automated with a simple script, which also demonstrated some of Qubes’ practical management tools. Unfortunately, this does not alleviate most of the inconveniences with this process. The script is executed in the management VM dom0. The shown device ID 00_14.0
can of course differ.
#!/bin/bash qvm-shutdown --wait $1 qvm-shutdown --wait $2 qvm-pci detach $1 dom0:00_14.0 qvm-pci attach $2 dom0:00_14.0 qvm-start $1 qvm-start $2 echo "assigned usb controller from ${1@Q} to ${2@Q}"
Windows VMs also can’t play or record any sound. This limitation can be worked around with USB devices, but as mentioned, these are inconvenient with Windows VMs.
Improving support for the Windows OS is currently not a priority for the small Qubes development team. The low level of demand shows that Windows OS does not play a significant role in many techie circles, which make up the primary user base of Qubes. However, Windows OS does still play a significant role in many non-IT-centric and big corporations, as well as companies, which work closely with these. Unfortunately, Qubes OS cannot seamlessly combine these two worlds.
The use of virtualization on the client side as Qubes does, bears significant potential for enterprise client deployments. Some industries, specifically automotive industry, where software vulnerabilities can be devastating, have already recognized the advantages of virtualization. Modern infotainment systems integrate various components with different security requirements. For example, the vehicle brakes should not be affected by vulnerabilities in the Bluetooth system. Virtualization plays a key role and is actively promoted by the industry in projects such as Automotive Grade Linux. The Qubes project is unlikely to fill the technology gap for enterprise client use cases based on the current developments and their stated mid-term milestones.
Our experts will get in contact with you!
Michael Schneider
Marisa Tschopp
Michèle Trebo
Andrea Covello
Our experts will get in contact with you!