Evaluating Qubes OS as a Penetration Testing Platform
This article discusses several pitfalls during installation and should help you decide if this OS fits your needs. This article is based on my experiences running Qubes OS RC3.2-RC3.
About the Author
Andrew Douma is a vendor-neutral IT Security Professional. He performs professional audits, penetration tests, and risk assessments. He designs secure networks and engineers high-assurance systems in the Cloud.
More stories by Andrew
Buying a professional penetration testing laptop for 2017 | Finding the right exploit code| Antivirus in 2017: Why? Which? How? | Penetration Testers’ Guide to Windows 10 Privacy & Security | Full Disk Encryption with VeraCrypt | Hacker to Security Pro! On the Shoulders of #InfoSec Giants| Securing an Android Phone or Tablet (LineageOS) | Password (IN)SANITY: Intelligent Password Policy & Best Practices
Since you are reading this, I’ll assume you are are looking to improve your security posture. If so you will want to adopt the habit of verifying the signature of software you download.
I recommend you first gain a detailed understanding of when you can trust an SSL connection and when a GPG encrypted or signed file. Ensure your machine’s ca-certificates and openssl version are up to date.
Time to download the latest Qubes ISO and verification files:
curl -O https://mirrors.kernel.org/qubes/iso/Qubes-R3.2-rc3-x86_64.iso
curl -O https://mirrors.kernel.org/qubes/iso/Qubes-R3.2-rc3-x86_64.iso.asc
curl -O https://mirrors.kernel.org/qubes/iso/Qubes-R3.2-rc3-x86_64.iso.DIGESTS
(alternatively use your favorite up-to-date browser)
To verify authenticity and integrity of these files, install the relevant Qube keys:
gpg — fetch-keys https://keys.qubes-os.org/keys/qubes-master-signing-key.asc
gpg — edit-key 0x36879494
(make sure to verify this output!)
“5 = I trust ultimately.”
You are now ready to verify the downloaded ISO and proceed.
gpg -v — verify Qubes-R3.2-rc3-x86_64.iso.DIGESTS
openssl dgst -sha512 Qubes-R3.2-rc3-x86_64.iso
gpg -v — verify Qubes-R3.2-rc3-x86_64.iso.asc Qubes-R3.2-rc3-x86_64.iso
Assuming everything checks out: proceed and create a bootable USB with one of the many graphical (1) (2) and command line tools. It is a matter of trust, cryptographic verification, and your personal preference.
My new Thinkpad came with Windows 10 Pro installed out of the box, which I used to bring the system BIOS up to date. If you have an SSD, I recommend updating its firmware as well.
Security researchers have already found similar issues with the Lenovo System Management Mode (SMM).
Every BIOS is different. I recommend you use a search engine to investigate options unique to your variant and version.
- I disabled Intel AMT, which controls the Intel vPro features. There is a third option to disable it forever, which cannot be undone.
- I disabled SecureBoot, as Qubes OS does not yet support it, I enabled only Legacy Boot.
- I disabled all Boot devices except for my SSD and USB devices. Upon successful installation, I disabled those as well.
- Pitfall: Intel PTT (TPM 2.0) does not make use of Intel TXT. Qube’s Anti-Evil-Maid requires this. Switch your BIOS to TPM 1.2 and enable TXT. This action will reset your TPM storage, including any SSD encryption keys present!
- I set high-entropy User and Master passphrases everywhere. Note that Lenovo does not permit the use of special characters.
Booting off the created installation medium, I’m greeted by the familiar Fedora setup wizard.
- Pitfall: Leave the default LUKS filesystem encryption enabled. Despite having transparent SSD FDE encryption enabled, you will need it to make use of Qube’s Anti-Evil-Maid feature.
- I opted to create a USB-Qube but use the SYS-NET Qube for networking and USB devices. The logic behind this was to make it easier to work with a myriad of wireless adapters.
It is time to reboot, enter all the passphrases, and login for the first time.
When logging in for the first time, you will be greeted by a prompt, select the default option. The Qubes VM Manager will start up anytime you log into your account.
I added “an additional shortcut” for Network Connections to my SYS-NET Qube to allow me to connect to my lab’s Wifi network. No NetworkManager app icon appeared for me by default — unsure if this is a bug or a feature.
The Qubes VM Manager can check for dom0 and domU updates, which should be your second action. I ran the following commands in the Terminal of each domain.
For the Fedora-based dom0:
sudo qubes-dom0-update && sudo dnf -y update && sudo dnf -y upgrade && sudo dnf -y clean all
For every Fedora-based domU:
sudo dnf -y update && sudo dnf -y upgrade && sudo dnf -y clean all
For every Debian-based domU:
sudo apt-get -y update && sudo apt-get -y dist-upgrade && sudo apt-get -y autoclean
Fedora SSD tuning
Fedora needs some tuning to ensure the enabled filesystem encryption doesn’t diminish the longevity of my drive. There are a few files I needed to modify.
Internet sources on this topic are outdated and contradictory. Please do read the man pages.
sudo nano /etc/default/grub
Here you can add rd.luks.options=discard or luks.options=discard to the GRUB_CMDLINE_LINUX parameters.
Edit: today’s version of dracut honors crypttab options set below, making this step unnecessary.
After which you generate the configuration file:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
Though allegedly not required for a fresh Fedora 24 install, I had to edit another file:
sudo nano /etc/crypttab
At the end of the line add ‘discard’. Note: ‘allow-discards’ is no longer mentioned in the crypttab man page.
Assuming you opted to use LVM this too will need a tweak.
sudo nano /etc/lvm/lvm.conf
There you set issue_discards=0 to issue_discards=1. After which you need to rebuild your initramfs and confirm the crypttab got included:
sudo dracut -f --regenerate-all
sudo lsinitrd | grep crypttab
After you reboot you can test if everything is working and ensure it stays that way:
sudo fstrim -v /
sudo systemctl enable fstrim.timer
Christopher has done a couple of nice writeups on his blog.
It is rare for all the hardware to work out of the box when running Linux.
I copied the following script to my dom0 user’s home directory to enable middle button on my TrackPoint:
xinput set-prop “TPPS/2 IBM TrackPoint” “Evdev Wheel Emulation” 1
xinput set-prop “TPPS/2 IBM TrackPoint” “Evdev Wheel Emulation Button” 2
xinput set-prop “TPPS/2 IBM TrackPoint” “Evdev Wheel Emulation Timeout” 200
xinput set-prop “TPPS/2 IBM TrackPoint” “Evdev Wheel Emulation Axes” 6 7 4 5
And a file to automagically execute it:
I did not test HDMI or sound output nor pass through. I am certain there is more tinkering needed — now and after every major release.
Kali Linux Installation
I was able to get the current Kali 2016.2 XFCE up and running without issue. In a standalone HVM template named kali-2016, blessed with 30GB of disk space and 4GB of balanced RAM.
To download the ISO onto my system I had to increase the personal disk space to 4GB for a connected domU. After verifying its validity, you can start installing Kali by executing in dom0:
qvm-start kali-2016 — cdrom personal:/home/user/Downloads/kali-linux-xfce-2016.2-amd64.iso
Remember that you will have to setup a static IP as DHCP will fail (see Qube VM Manager > VM Settings > Networking).
I stuck with the default options, and the resulting system does not have any of the Qubes software agents. Following any of the current Linux HVM tips will break the install.
Qubes R3.2-rc3 supports Windows 7. Support for Windows 8–10 has been “under development” for some time.
I did not take the time to test this due to a lack of interest and a legitimate Windows 7 license key.
Use cases for Qubes
I can recommend Qubes to all Linux nerds looking to improve their defensive security posture.
If you are someone who enjoys running or testing an assortment of Linux and BSD distributions. This OS offers a user-friendly solution as long as you have the right hardware.
The use of virtualization to compartmentalize your digital life is a leap forward. You will need to force yourself to adopt secure routines and learn the ins and outs of this modded Fedora OS to avoid human error.
It is a pleasure to be able to chain guest domains together with various network setups:
- Tunneling my Kali 2016.2 traffic through SecurityOnion 14.04.5.1 gave me a quick way to test the effectiveness of IDS evasion techniques.
- Having multiple domU’s connected to a virtual penetration testing lab over a VPN domU.
- All while retaining the ability to do research online.
You can find plenty of arguments on the subject. I will try and approach this from my own point of view, as a heavy *nix user, security engineer and pentester.
There is room to improve the security and audit ability of a default Qubes OS install. Executing CISOfy’s Lynis tool on dom0 and several domU guest domains is a good idea. At the end of the day, you are responsible for hardening and maintaining as many domU systems as you setup.
I would most like to see Qubes make use of Kernel hardening options such as PaX/PIE/SSP/grsecurity. SELinux is even disabled by default. The IPTABLES ruleset could also use some tuning all round. (Feb ’17 update: check out ColdKernel)
After the initial stock install, I recreated all domU’s based on a fresh qubes-template-fedora-23-minimal, applying my tradecraft to harden them. If I continue with Qubes OS I will have to equip the dom0 with OSSEC or at least AIDE.
The SYS-FIREWALL domU is your shield. With it compromised I would consider it game over. It is hard to skip over the fact that it’s based on a standard Fedora 23 install. Not only does this have a negative impact on RAM and disk-space consumption, your attack surface is unnecessarily increased.
Luckily I stumbled onto Thomas Leonard’s qubes-mirage-firewall Github repository and blog post. He came to similar conclusions early 2016. Using his latest flambda-test branch I replaced the SYS-FIREWALL with the MirageOS unikernel. Improving system response time and reducing resource consumption to 64mb of RAM and 1 vCPU.
It has been an exciting week-long journey!
I want to commend the Qubes Team for their accomplishments and the Fedora Team for their progress made since the Fedora Core releases. I for one am excited to see what Qubes OS 4 will bring, early 2017.
That said it does not seem workable to use Qubes during offensive engagements.
New clients become repeat customers, knowing I do my job efficiently within their available time and budget. Running Qubes OS would slow me down.
For example, during an internal network penetration test:
- I want to be able to quickly lower the security of my system
- Bridge together several (wireless) network interfaces
- Enable IP forwarding to complete my MiTM attack, or
- Serve up an exploit or a malicious login portal
This is cumbersome when your network devices, firewall, and attack tools are so separated. I would need more time to explore this, which is a precious commodity nowadays.
Then dd my copy of Windows 10 Pro onto my SSD and setup a multi-boot system. Likely hosting my attack tools under VMWare/VirtualBox alongside a variant of BSD and Linux.
Qubes will likely serve as a more portable version of my hacker lab.
Do you have any advice? Corrections or additions?
Please do not hesitate to reply! Feel free to share your experiences, advice, and questions in private or through the comments section.
Click the ♡ to recommend this article.