These are text notes that I made from a presentation Harlo Holmes from Freedom of The Press Foundation (FPF) gave at the HOPE 2020 conference: Qubes OS for Organizational Security Auditing. The talk mainly about explaining how Qubes is ideal for this use-case and showing off the tooling Harlo uses to do security audits on Qubes as part of the Digital Security Team at FPF.
These notes include most of Harlo’s remarks and they’ve been curated to have links to the Qubes documentation and well as other reference material. Some content is also adapted.
The content is released under the Attribution-ShareAlike 4.0 International License, just like the original video.
Provisioning Audit Environment
These are the main components of the security audit environment.
VPN Proxy Qube
Qubes takes a “lego-block” approach to networking meaning that if you have an application running on a qube that is connected to the internet, it’s not connected directly to the Internet. Instead it’s first connected to a qube called
sys-firewall - a qube with a firewall dedicated to keep connection the various application qubes you might run separate from one-another. And then
sys-firewall connects to yet another VM called
sys-firewall, which is a Hardware-assisted Virtual Machine (
HVM) - and that allows it to interact with all of the radios, Ethernet card or anything that physically allows you to connect to the internet.
Deals with connectivity. You use this qubes in-between the AppVM that’s running your internet-connected applications and your
I will not touch your Internet!
I brought by own Internet!
I don’t even trust my own Internet!
Thanks to Qubes’ lego-block approach, you can make it so every AppVM has is own route to the internet, no matter how convoluted it is (VPN over Tor, Tor over VPN, etc.)
This is where the bulk of the work happens. Here you analyze and compile all the data. It has your standard Kali tooling.
Use of python virtual environments
To install dependencies persistently without modifying the underlying template python virtual environments are used. This essentially installs the dependencies in the user-space. This is also used because by default TemplateVM are made to only connect to their respective package managers via the internet. So running pip on the TemplateVM would fail.
This is the VM where communication among team-members happens (on slack).
Safe space to view sketchy stuff. It’s non-networked DisposableVM that has tooling to interact with media visually and on metadata level to a modest degree.
This is a tool that watches out for OS modifications as it interacts with files
.desktopfiles for opening each file with the most appropriate application. This is done in the TemplateVM that serves as base for the Antarctica DisposableVM.
Network Recon Qube
A way to probe a network with physical interfaces rather than virtual ones.
Pretty much like the default
sys-net but with network analysis tooling like nmap and wireshark.
Use inter-qube communication to move recon data into Analysis Qube
The Qubes team always cautions users to always move data from more trusted VMs into less trusted VMs.
So, if in doubt that your Analysis Qube is more trusted than your Recon Qube, just copy and paste the dumps through the clipboard - since in the end it’s all just text files.
Another more trustworthy way is to take screenshots (which are taken from dom0) and then send them over to the Analysis Qube.
This qube is not connected to sys-firewall
The qube is not connected to any firewall proxy (like
sys-firewall), so there is a bit more elevated risk - but this is the only actual way to probe the network while using Qubes.
Plug in in a network peripheral
This qube gets attached a USB WiFi network peripheral (you don’t want to mess anything up with your
Going beyond this setup
There are a few things you can also explore to go beyond this basic configuration. Here are some examples you can explore.
Create your own RPC Policies
Qubes RPC Policies are the way you configure permissions of which Qubes can interact with other Qubes and define how they can interact.
You can see these as the equivalent to you phone’s permission system.
Make one-way communication from Net Recon Qube → Analysis Qube
Make it so the only files that can go out of the Network Recon Qube must go into the Analysis Qube.
If you have multiple Analysis Qubes (for different projects), then you’ll want to use tags on those and target the RPC policy at those tags.
Make your templates reproducible
Uniformity and standardization is key. Use SaltStack for provisioning uniform templates and setting up RPC policies.
SaltStack is a management system similar to Ansible or Puppet. It will ease up your setting up a lot.
You can follow this guide by Kushal Das: https://kushaldas.in/posts/maintaining-your-qubes-system-using-salt-part-1.html
Set data-retention policies
How can Qubes assist in a workflow that help mitigate data retention.
One example of how this happens is in the full exporting of the Analysis Qube to encrypted cold storage after we’re done with the analysis.
Qubes makes this easy with its backup utility.
Do not check the box to store the encryption password on dom0!
Communication with the clients is key, before, during and after the assessment. And while you as a security specialist may have preference for end-to-end means of communication, you sometimes have to meet your client where they are - especially during a pandemic.
In the particular circumstances of that pandemic we’re in, you may find yourself having to use Zoom a lot. And it has received strong critiques from the security community. To this end, we’ll use a setup with a DispVM to join zoom calls - so you don’t have a persistent zoom identity.
# Attaches the microphone and webcam to a desired qube # usage: # attach-webcam.sh dest_vmname for c in mic usb; do qvm-device $c a $1 $(qvm-device $c list | grep -E "Camera|Microphone" | cut -d' ' -f1); done
Is there anything that can be improved?
Do you have any other suggestions?
Contact Harlo on twitter @harlo