In fact, I think it is worth noting somewhere that hardcore Qubes-Whonix recommendations could arguably include:
all apparmor profiles installed in the WS and GW;
enabling seccomp in the Whonix GW torrc;
running hardened alpha Tor Browsers if adventurous due to near-term (December) sandboxing opportunities;
following Qubes guideline for MAC spoofing (ethernet and/or wi-fi; yes, I’m aware of the wi-fi spoofing problems);
running all instances of Whonix-WS in a disposable VM;
possibly running the minimal Fedora templates for all networking;
purging all unnecessary Whonix files and template applications as per Patrick’s latest blog post;
possibly (?) running SE Linux in combination with apparmor via kernel changes in dom0, although I am yet to try that or see any reasonable guides or feedback on its success to date.
We could probably add entr0py’s recommendation to:
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.
Also:
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);
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
Run Tor Browser in the highest security slider position and only sparingly allow Javascript for trusted sites**
I think the last two points are already mentioned somewhere in the documentation.
** Analysis of the SVG exploit just patched in Firefox shows this would have provided protection against exploitation.
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.
Should not TBB do that on high security setting? Was this discussed by Tor Project? Add a bug report against TBB?
Needs to be added.
Keyboard input is mentioned here:
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.
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.
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.
“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).
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.
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 *****
**** 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 → codeblog
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
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
“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.)
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.
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.
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).
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
Just http. Because apt-get is uwt-wrapped and gets sent straight to the Gateway. No apt-transport-tor.
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:
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:
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?
[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.]
[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.
