Hardening Qubes-Whonix

[Patrick]

Good ideas! Yes, please add!

Store all login credentials and passwords in an offline vault VM (in a password manager?), and only using Qube’s secure cut and paste into Tor Browser.

Yes. And also copy something else into the clipboard after pasting so the password is purged from the clipboard so it cannot be accidentally pasted elsewhere.

Select ‘Clearclick’ and ABE (Applications Boundary Enforcer) protections in NoScript which are not enforced under default TB settings (due to some known bugs on certain websites);

Should not TBB do that on high security setting? Was this discussed by Tor Project? Add a bug report against TBB?

Run Tor Browser in the highest security slider position and only sparingly allow Javascript for trusted sites**

Needs to be added.

I think the last two points are already mentioned somewhere in the documentation.

Never type directly into Tor Browser to avoid typing profiling i.e. use a text editor in an offline VM and cut and paste into Tor Browser; and

Keyboard input is mentioned here:

Surfing Posting Blogging

Not sure if the importance of that information is properly highlighted. I am wondering if the Whonix wiki information structure can be improved. There is some overlap for the following pages.

• https://www.whonix.org/wiki/Computer_Security_Education
• https://www.whonix.org/wiki/Security_Guide
• https://www.whonix.org/wiki/Warning
• https://www.whonix.org/wiki/DoNot
• https://www.whonix.org/wiki/Surfing_Posting_Blogging

[Patrick]

You might also like to install newer Tor versions. As per Whonix 13, Whonix by default uses deb.torproject.org jessie, stable version. The following deb.torproject.org Tor suites providing newer Tor versions could also be interesting for you:

• jessie-proposed-updates
• experimental
• nightly

If at least one person would use any of these (jessie-proposed-updates seems reasonable, experimental seems more risky and nightly really only for testers), that would also help Whonix development a lot - because then you’d run into issues before anyone else, allowing us to contact Tor Project about possible changes that mess up the whole Whonix concept before these changes make it into Tor stable releases and creating a huge mess.

[torjunkie]

Hi,

Re: jessie-proposed-updates -> doing this already, and 2.8.10 is working nicely.

Re: NoScript and ABE -> It is not required, as Tor Browser now blocks all access to 127.0.0.1 by default. So scrap that recommendation.

See https://trac.torproject.org/projects/tor/ticket/11493

Re: NoScript and ClearClick (Click jacking) protections, it is not enabled by default because certain false positives occur, typically on webpages relating to CAPTCHAs, some banking websites, some embedded PDFs etc.

An open ticket exists, with the feature having been temporarily disabled. I think we can recommend users set it to on, with a suitable warning about false positives.

See here: https://trac.torproject.org/projects/tor/ticket/14985

For interested readers, Clickjacking refers to:

https://noscript.net/faq#qa8_1

“Clickjacking” we designate a class of attacks (also known as “UI Redressing”) which consist in hiding or disguising an user interface element from a site you trust (e.g. the “Send” button of your webmail site or a pre-configured “Donate” Paypal button) in a way which leads you to click it without knowledge of what you’re exactly doing. In the impressive proof of concept by RSnake and Jeremiah, you clicked anywhere in their apparently innocuous page, believing you were doing nothing dangerous, but in reality you were activating your microphone and/or your webcam for Flash access, allowing the remote attacker to spy on you instantaneously.

More in general, an attacker can frame a portion of a certain web page you trust inside a different page under his control, decontextualizing it or making it transparent: this way he can easily trick you into interacting with it, and you end to perform a financial transaction or allow him special permissions, without remotely suspecting that something evil is going on.

If JavaScript is allowed on the malicious site, this becomes much easier because the invisible target page can be automatically positioned exactly under your mouse pointer, so anywhere you clicks the evildoer wins. However this attack can work even without JavaScript being allowed: the attacker just needs to trick you into clicking on a seemingly innocuous link or button.

Every web browser is affected, because this attack doesn’t rely on any vulnerability or bug which might be fixed overnight: instead, it exploits very basic and standard web features which are implemented everywhere and are unlikely to be removed any time soon.

These recommendations (and those you vetted further above) could be added to a “Safe Tor Browser Settings and Use” section in the security guide. The guides could probably be all re-worked, but getting around to the Quick-Start guide is probably a higher priority.

Of interest, have you noticed the hardened Tor Browser privacy slider on first run states “You have unusual customized settings” and does not let you change the low-medium-high setting, unless you first select the button to “reset to default”?

I wonder if this is changing any standard Whonix changes and could possibly be a security/privacy risk if users revert to ‘standard’ TBB settings in the first instance… it’s worth investigating the differences via the ‘user set’ preferences in about:config changes with TBB hardened (not accepting this change) & TBB hardened (accepting this change).

Most importantly, the changes avoiding stacked tor do not seem to be affected (I checked - the relevant Whonix string is there for both).

[torjunkie]

Talking about .onions we could probably also add:

• Change the default settings for the Tor Browser search bar to reflect the preference for “DuckDuckGoOnion Search”

[Patrick]

Talking about .onions we could probably also add:

Change the default settings for the Tor Browser search bar to reflect the preference for “DuckDuckGoOnion Search”

It’s an interesting idea, but we need to figure out first why that is not the upstream TBB default. And open a ticket against TBB if not already existing.

[torjunkie]

Re: DuckDuckGoOnion -> I recall reading somewhere they didn’t set it by default due to concerns over the entire Tor Browser population overloading it. But no technical reason that I can remember.

Other possible additions:

• Using AEM (Anti-Evil Maid) by default where users have a TPM (trusted platform module) ***
• Setting passwords for Whonix templates by default (?) ****
• Installing later (‘unstable’) kernel versions in dom0 where possible *****

*** Is this stable enough for users? See https://github.com/QubesOS/qubes-issues/issues/2155

The rationale for this is that BIOS changes can be detected, and this is also possible by remote attackers according to Qubes threads. See also https://www.qubes-os.org/doc/anti-evil-maid/ and https://theinvisiblethings.blogspot.de/2011/09/anti-evil-maid.html

**** Marek seems to be of the opinion that VM exploit = game over, but I’m not sure whether Whonix shares this opinion i.e. script-kiddies may be frustrated by this change for example.

***** There is a real possibility of making your entire system unbootable or unusable (been there). However, as the kernel hardening project is mainlining various GrSec elements over time, there is significant protections available between the stable (4.4.X) and unstable (4.8.X) versions. See Kees Cook blog for further information on what has happened since 4.5 -> https://outflux.net/blog/

Also, Dirty Cow is patched in later kernel versions, but standard users are still affected using the 4.4.X series.

For example benefits of later kernels see below.

In 4.8 series:

SLUB freelist ASLR

x86_64 KASLR text base offset physical/virtual decoupling

x86_64 KASLR memory base offset

x86_64 KASLR with hibernation

gcc plugin infrastructure

hardened usercopy

seccomp reordered after ptrace

In 4.7:

KASLR text base offset for MIPS

SLAB freelist ASLR

eBPF JIT constant blinding

fix brk ASLR weakness on arm64 compat

LoadPin LSM

In 4.6:

seccomp support for parisc

x86 32-bit mmap ASLR vs unlimited stack fixed

x86 execute-only memory

CONFIG_DEBUG_RODATA enabled by default on arm and arm64, and mandatory on x86

arm64 KASLR text base offset

zero-poison after free

read-only after init

In 4.5:

CONFIG_IO_STRICT_DEVMEM

ptrace fsuid checking

ASLR entropy sysctl

strict sysctl writes

seccomp UM support

seccomp NNP vs TSYNC fix

[torjunkie]

The qvm-backup key derivation/management (backup encryption) is reported to be insecure. See here:

Issue: Improve qvm-backup key derivation/management

The technical reason is:

https://bqp.io/qubes-backup-encryption-added-to-crackstation.html

I’ve added Qubes OS Version 3’s backup encryption to my online password cracking service, CrackStation. It was possible to do this because Qubes’ backup encryption does not correctly salt the backup encryption password.

To crack a Qubes OS backup password, follow the first steps of these instructions to extract the contents of the backup. Copy and paste the contents of backup-header.hmac into the form on CrackStation’s homepage. If the password is in CrackStation’s dictionary, and the Qubes user used the default backup settings, it will find the password in its lookup table, and return it to you.

…

Technical Details

The contents of backup-header.hmac is the output of the command openssl dgst -sha512 -hmac ‘’ backup-header. This computes the HMAC-SHA512 of the contents of the backup-header file using the password as the HMAC key. By default, the contents of backup-header is version=3\nhmac-algorithm=SHA512\ncrypto-algorithm=aes-256-cbc\nencrypted=True\ncompressed=False\n. There’s no salt involved in the computation of this HMAC, so if the user has left the Qubes backup settings as their defaults, the HMAC of this file will have been computed in exactly the same way as the HMACs in CrackStation’s hash database. That’s why a simple binary search lookup of the hash in the database can quickly reverse the hash into its corresponding password.

Thus, until this issue is sorted in Qubes 4.0, Qubes-Whonix users should probably use the following work-around for hardening purposes:

• Store Qubes-encrypted backups on a separate back-up disk that is already encrypted with LUKS

[adw]

The qvm-backup key derivation/management (backup encryption) is reported to be insecure.

“Insecure” is not quite accurate. The problem (as partially described by the quotation) is that we rely on OpenSSL’s encryption function, which uses a weak key derivation scheme (basically just a single round of md5). The backup system is secure as long as you use a high-entropy passphrase. Since you should be doing so anyway, this issue isn’t something that should necessary stop you from using qvm-backup. (I’m the one who originally reported this issue, and I’ve continued to use it without interruption.)

Thus, until this issue is sorted in Qubes 4.0, Qubes-Whonix users should probably use the following work-around for hardening purposes:

• Store Qubes-encrypted backups on a separate back-up disk that is already encrypted with LUKS

Yes, this is a good idea and won’t hurt. (I was doing this even before finding out about the weak key derivation scheme issue.) The only problem is that it doesn’t really work for offsite-backups.

[torjunkie]

Noted.

The recommendation could instead read:

• Qubes users must have a sufficiently long (high-entropy) passphrase to store encrypted back-ups due to OpenSSL’s weak key derivation scheme, which relies on a single round of md5. Failing this, another solution is to store encrypted backups on a separate back-up disk that is already encrypted with LUKS.

[torjunkie]

@entr0py

Do you mind cutting and pasting your sources.list (.onions) which works, so that I can edit the wiki somewhere to reflect the correct sources for those wishing to harden their Qubes-Whonix installation?

I’m a little confused which ones we are pointing to and whether it is just tor:// or tor + http:// - what else is new

Reflecting on what we have covered so far, a future wiki entry might look something like that below (with links to relevant wiki entries/stubs). It is better to have it in one place, so users have a quick reference and don’t have to search everywhere for this information:

Qubes-Whonix users can achieve significant hardening of their system by completing a number of additional steps after installation of the base system.

Successful completion of these steps below is dependent upon the user’s skill level and available hardware. Applicable steps are marked with ‘easy’, ‘medium’ or ‘difficult’ tags to reflect this:

• Default the Debian mirrors in sources.list to available .onions (easy);
• Install all available apparmor profiles in the Whonix-Workstation and Whonix-Gateway TemplateVMs (easy);
• Enable seccomp in the Whonix-Gateway TemplateVM torrc file (easy);
• Use the hardened (alpha) Tor Browser series to resist fingerprinting and have additional memory protections (easy);
• Use the (alpha) Tor process sandbox to restrict exploitation opportunities (difficult - not yet implemented in Whonix; requires sandbox compilation - @Patrick, this requires a wiki stub somewhere);
• Implement MAC spoofing for ethernet and/or wi-fi via Qubes user documentation (medium);
• Use all instances of the Whonix-Workstation in a Whonix-Workstation DisposableVM - preferably uncustomized to resist fingerprinting (medium);
• Implement GRSEC templates for Fedora, Debian and Whonix templates in the Qubes system (difficult; only Debian currently available - @Patrick, we need a GrSec stub somewhere in the wiki for future copying of all steps);
• Tweak the Tor Browser to provide ClearClick protections, run the security slider in the highest position, restrict Javascript uniformly, and default to .onion searches via DuckDuckGo (easy);
• Store all login credentials and passwords in an offline vault VM (preferably in a password manager), and cut and and paste into the Tor Browser when required (easy);
• Never type directly into the Tor Browser to resist typing profiling (easy);
• Install newer Tor versions via Whonix config settings i.e. jessie-proposed-updates (easy);
• Install latest versions of the Linux kernel available to benefit from mainlined kernel hardening (easy);
• Use AEM (anti-evil-maid) in Qubes, in combination with a Trusted Platform Module (medium);
• Store encrypted Qubes backups with a sufficiently long (high-entropy) passphrase due to OpenSSL’s weak key derivation scheme, which relies on a single round of md5 or store encrypted backups on a separate back-up disk that is already encrypted with LUKS (easy);
• Install Qubes-Whonix with a sys-usb template to provide protection from malicious compromise of dom0. This requires available USB controllers and, in a desktop configuration, available PS/2 ports and adapters for the keyboard and mouse (medium).

What have I missed?

[entr0py]

Do you mind cutting and pasting your sources.list (.onions) which works, so that I can edit the wiki somewhere to reflect the correct sources for those wishing to harden their Qubes-Whonix installation?

These are non-Qubes-Whonix specific so would be good if others could see them too.

#### Debian onion mirrors

# deb http://ftp.debian.org/debian jessie main contrib non-free
deb http://vwakviie2ienjx6t.onion/debian jessie main contrib non-free

# deb http://security.debian.org jessie/updates main contrib non-free
deb http://sgvtcaew4bxjd7ln.onion jessie/updates main contrib non-free

# (optional - Backports)
# deb http://ftp.debian.org/debian jessie-backports main contrib non-free
deb http://vwakviie2ienjx6t.onion/debian jessie-backports main contrib non-free

#### Whonix onion mirrors

# deb http://deb.whonix.org jessie main
deb http://deb.kkkkkkkkkk63ava6.onion jessie main

#### Tor Project mirrors

# (optional - for direct Tor package)
# deb http://deb.torproject.org/torproject.org jessie main
deb http://sdscoq7snqtznauu.onion/torproject.org jessie main

#### Qubes - still waiting

deb [arch=amd64] http://deb.qubes-os.org/r3.1/vm jessie main

I’m a little confused which ones we are pointing to and whether it is just tor:// or tor + http://

Just http. Because apt-get is uwt-wrapped and gets sent straight to the Gateway. No apt-transport-tor.

[Patrick]

Use the (alpha) Tor process sandbox to restrict exploitation opportunities (difficult - not yet implemented in Whonix; requires sandbox compilation - @Patrick, this requires a wiki stub somewhere);

Just now created:
https://www.whonix.org/wiki/Tor_Browser#Tor_Browser_Sandboxed

Implement GRSEC templates for Fedora, Debian and Whonix templates in the Qubes system (difficult; only Debian currently available - @Patrick, we need a GrSec stub somewhere in the wiki for future copying of all steps);

That belongs to https://www.whonix.org/wiki/Grsecurity. Do these instructions work in KVM? If so, the existing page becomes chapter KVM. //cc @HulaHoop

[torjunkie]

Suggested entry below (Security Guide section) for the benefit of both Qubes and Non-Qubes-Whonix users. Tested and now working on my system for both templates.

Onionizing Whonix and Debian Repositories

When Whonix, Debian and Qubes packages are installed or updated, default settings point to repositories with a http:// URI.[1][2] However, experimental .onion support is already available for both Whonix and Debian packages, with Qubes .onion mirrors planned for the near-term.[3][4]

In order to install or update with the utmost caution, users may consider manually editing their sources.list to point to the Whonix and Debian .onion mirrors. There are several security and privacy benefits of this approach:[5]

• The user cannot be uniquely targeted for malicious updates (attackers are forced to attack everyone requesting the update);
• The package repository, or observers watching it, can’t track what programs you’ve installed;
• The ISP cannot easily learn what packages you fetch; and
• End-to-end authentification and encryption provides protection against man-in-the-middle attacks e.g. version downgrade attacks.

To use the .onion mirrors, it is necessary to change the whonix.list and debian.list files in the /etc/apt/sources.list.d directory in both the Whonix-Workstation and Whonix-Gateway TemplateVMs.[6]

(1) In the TemplateVM, open the Debian sources file in an editor with root rights.

If you are using a graphical Whonix or Qubes-Whonix, run:

kdesudo kwrite /etc/apt/sources.list.d/debian.list

If you are using a terminal-only Whonix, run:

sudo nano /etc/apt/sources.list.d/debian.list

(2) Cut and paste the following .onion mirrors and comment out (#) the corresponding http repositories noted in bold:

#deb http://ftp.debian.org/debian jessie main contrib non-free
deb http://vwakviie2ienjx6t.onion/debian jessie main contrib non-free

# deb http://security.debian.org jessie/updates main contrib non-free
deb http://sgvtcaew4bxjd7ln.onion jessie/updates main contrib non-free

(Optional - Backports)

#deb http://ftp.debian.org/debian jessie-backports main contrib non-free
deb http://vwakviie2ienjx6t.onion/debian jessie-backports main contrib non-free

(3) Save the new debian.list file

(4) Point to the Whonix APT Repository .onion mirror:

sudo whonix_repository --baseuri http://deb.kkkkkkkkkk63ava6.onion --enable --repository stable

Note: Users have four preferences available for Whonix packages: stable, stable-proposed-updates, testers and developers. Change the entry above to reflect this preference.[7]

(5) Check the .onions are correct and functional in your Whonix system:

sudo apt-get update && sudo apt-get dist-upgrade

Remember to repeat steps 1-5 for both the Whonix-Workstation and Whonix-Gateway TemplateVMs.[8]

(6) OPTIONAL testers/paranoid users step - create an onionized torproject.list:

If you are using a graphical Whonix or Qubes-Whonix, run:

kdesudo kwrite /etc/apt/sources.list.d/torproject.list

If you are using a terminal-only Whonix, run:

sudo nano /etc/apt/sources.list.d/torproject.list

Cut and paste the following text and comment out (#) the corresponding http repository noted in bold::

#deb http://deb.torproject.org/torproject.org jessie main
deb http://sdscoq7snqtznauu.onion/torproject.org jessie main

Save and exit.

Footnotes:

[1] https://www.whonix.org/wiki/Whonix-APT-Repository#Repository_Location_URI
[2] Whonix 14 will prefer .onion repositories by default, even when adding third-party resources
[3] Onionizing Qubes-Whonix Repositories
[4] https://www.whonix.org/wiki/Install_Software#How_to_install_or_update_with_most_caution.3F
[5] https://blog.torproject.org/blog/tor-heart-apt-transport-tor-and-debian-onions
[6] tor:// or tor:// + http:// entries are not required in Whonix because apt is uwt-wrapped.
[7] https://www.whonix.org/wiki/Whonix-APT-Repository#Whonix_APT_Repository_Overview
[8] Qubes users can repeat these steps in their Debian-8 TemplateVM to onionize installations and updates.

[Patrick]

torjunkie:

Tested on my system. Working, except for a 404 error on the Whonix server:

Failed to fetch http://kkkkkkkkkk63ava6.onion/dists/jessie/main/binary-amd64/Packages 404 Not Found
I think we can also add these .onions entries to a new user.list, instead of manually changing the debian.list and whonix.list so i.e so they are not later written over by packages updates?

The canonical way is:

sudo whonix_repository --baseuri http://deb.kkkkkkkkkk63ava6.onion --enable --repository stable

Won’t ever be automatically overwritten.

[With a small exception, if the onion ever changes (upcoming strong
hidden services keys) we’ll sed replace the old to the new onion
trough whonix-legacy package.]

[entr0py]

Tested on my system. Working, except for a 404 error on the Whonix server:

Failed to fetch http://kkkkkkkkkk63ava6.onion/dists/jessie/main/binary-amd64/Packages 404 Not Found

Wow, really sloppy. Sorry.

deb http://deb.kkkkkkkkkk63ava6.onion jessie main vs
deb http://kkkkkkkkkk63ava6.onion jessie main

I think we can also add these .onions entries to a new user.list, instead of manually changing the debian.list and whonix.list so i.e so they are not later written over by packages updates?

Whonix 14 ticket: https://phabricator.whonix.org/T399

---

@entr0py please check this is okay.

Looks good to me. Thanks!

[I need a wiki for the wiki. I know there are templates for #1 and #2 that generalize instructions for qubes-whonix & non-qubes-whonix. I don’t know where to find them though.]

(1) In the TemplateVM, open a terminal with Konsole.

(2) Edit the Debian sources file:

[6] 'Credit to entr0py for this information.

[6] Debian starts Onionizing

Community effort. Better to link to discussions I think - unless attributing to a well-known expert. [Plus I don’t want any blame.]

[Patrick]

[I need a wiki for the wiki. I know there are templates for #1 and #2 that generalize instructions for qubes-whonix & non-qubes-whonix. I don’t know where to find them though.]

Here is a list of all templates (since we have not categorized them):
https://www.whonix.org/wiki/Special:UncategorizedTemplates

(You can find such special pages through https://www.whonix.org/wiki/Special:SpecialPages.)

If you like to create any new templates, please just tell me the template page names and I create them.

[Patrick]

Qubes-Whonix users can achieve significant hardening of their system by completing a number of additional steps after installation of the base system.

(Many are general, non-Qubes specific.)

Successful completion of these steps below is dependent upon the user’s skill level and available hardware. Applicable steps are marked with ‘easy’, ‘medium’ or ‘difficult’ tags to reflect this:

I like the ordering in various difficulties.

https://www.whonix.org/wiki/Security_Guide is supposed to contain only items being ‘easy’ and perhaps ‘medium’.

https://www.whonix.org/wiki/Advanced_Security_Guide is supposed to contain only ‘difficult’ items.

Perhaps Security_Guide needs a face lift? Perhaps remove all non-actionable items? I.t. remove all items that are just knowledge. Move that elsewhere, to where? And then have only ‘easy’ and ‘medium’ difficult actionable items on that page? [Plus links to other actionable items that have a separate page such as grsecurity.]

[torjunkie]

Thanks!

Works with entr0py’s amended .onion mirror link, as does the canonical method for enabling the Whonix repository. @entr0py does the Tor project .onion mirror belong in the Debian sources file?

See edits above. If this is okay, I will insert it in the security guide somewhere.

Patrick - I agree re: security docs. If entr0py and Ego have the quick-start guide in hand, then I hope to take this on as a mini-project. It is one of the most important sections of the wiki.

My other main interests are getting the Tor sandboxing stuff working (when you have the time) and helping to test and document this, and seeing that GRSEC documentation and testing works in Qubes-Whonix. Most of this will hopefully just be cut and pasting from coldhacka’s blog with the appropriate attribution.

[entr0py]

does the Tor project .onion mirror belong in the Debian sources file?

No, if anything, it should get its own torproject.list. I would leave it out of the end-user security guide. Only for testers or paranoid. Testers Wanted! Tor - Stable Upgrades