Using Empire, I generated a bash launcher and saved it on the target (Whonix workstation 13). Added +x and ran it. This launcher runs a base64 encoded python script.
The steps above require some convincing aka social engineering (or just being naive about security of this or that system). The rest doesn’t.
Seconds after the script silently runs (and deletes itself) I have a shell into Whonix Workstation.
I use a ruby keylogger module, and hey, I’m lucky today, the user runs sudo apt-get update and I get his password with the keylogger.
The password is changeme. I probably could have skipped the last step
I use the sudo_spawn module with the password and get a new agent with root permissions.
I use a persistence module (add a file under ~/.config/autostart, or alternatively a cron tab), restart the workstation and voila I have persistent access.
Point #1: all the default payloads in metasploit and empire are detected and automatically removed by Windows 10 defender.
Point #2: I didn’t use more than the standard payloads of a system that was mostly written in 2015 / 2016 and is accessible to anyone with basic linux knowledge.
Point #3: I don’t imply Whonix workstation is less secure than windows, but I do hope the above is food for thought. We can’t discount human mistakes.
Point #4: I will try that on Tails too.
This will include not only sudo but also a comparison of app’s hash to some online DB of threats’ hashes (unless user expressly accepts the risk). Alternatively keep it local and regularly update.
Eventually everything can be turned off. If the user turns off defender’s virus protection / anti virus, ignores browser warnings about attack sites etc, there is nothing that can help him.
In theory, we could make Whonix a walled garden like Apple iPhone where the user may run only certified (by software vendor) commands / programs. However, users would request a superuser mode. What we do then?
a) explain how to enable the superuser mode?
b) become like apple and make that only accessible to users who have the level of using jailbreaks or let them download superuser mode software-forked Whonix elsewhere?
c) provide two flavors of Whonix, Whonix walled garden edition and Whonix superuser edition?
In case of a):
What would prevent the social engineering to include “you need to enable superuser mode”?
In case of b):
Is that what you are suggesting?
In case of c)
How does that sound?
Option b) is not going to happen. Purely theoretical discussion. I wouldn’t be in Libre Software if I would be compatible with non-opt out (or obfuscated difficult opt-out) nanny software restrictions.
Option c) is unlikely but let’s see the discussion.
The supermode vs non-supermode is actually not that theoretic. There could be “safe-boot” and supermode boot. Similar to Tails greater has by default “disable root login” (still has probably?). GitHub - tasket/Qubes-VM-hardening: Fend off malware at Qubes VM startup seems like a nice balance.
r u trying to be smart or Moran? u run the program with allow root execution/installation inside whonix and you are saying “oh hey look at the payload its working?”
I agree that a) doesn’t solve the social engineering aspect and b) is too restrictive. I’m not sure option c) is practical. What I’ve found is that to enjoy the benefits of Whonix sooner or later you need to revise some of the scripts, install something. If it’s for the sake of Tor before VPN or for setting up onion sites. Could Whonix keep this flexibility and still allow only certified applications in a “walled garden” version?
I think detection of known threats is important, if at all possible. A walled garden mode is too restrictive and often requires ways around it, as you described.
Of course new threats or anything crafted for a specific target will not be affected by that. Handling known threats will already be an important step.
Could Whonix keep this flexibility and still allow only certified applications in a “walled garden” version?
Yes.
“wallet garden” mode would only be activated if some condition is met.
[1] Under consideration I have kernel parameters and/or Qubes qvm
service files.
To get back to flexibility: disable “walled garden” - which would mean
disable that kernel parameter and/or Qubes qvm service.
[1] In a later version these conditions could be set by default.
One form of a non-contentious implementation of “wallet garden” for
example would be if a Qubes-Whonix VM on Qubes with the appendix -only-torbrowser in its VM name could result in user user only being
able to run torbrowser and no other application. Or perhaps a qvm
service “allow-torbrowser” would be better. It’s just brainstorming at
this stage. First, identify ways a user can run an application: a
terminal emulator or better said shell, dom0 qvm-run, … Qubes gives a
lot flexibility. Perhaps at boot time /usr/bin and others could be made
unreadable for user user using linux user permission access rights.
The tool how to disable “walled garden” could be along the lines “better
don’t this today if the first time you got the idea of doing this,
research this using search engines, don’t run commands you don’t
understand, ask multiple people for advice on this”. Advanced users
could always have a one or two clicks “yes, i know what I am doing,
disable wallet garden and never ask me again”.
Of course new threats or anything crafted for a specific target will not be affected by that. Handling known threats will already be an important step.
Handling known threads sounds like signature detection which sounds like
antivirus. Now, making Whonix into a signature chasing project is
unsustainable. Others have failed to do so. If anywhere, antivirus would
be a better place to try that. See also on why antivirus are failing
concept:
Of course they are (signature detection), try a custom Payload and see how useless the Windows “Defender” is…
A simple Reverse SSH shell would have done the same…
True but we can’t try to mitigate Human stupidity, social engineering can’t be stopped by software. If you can convince someone to do these stupid things, you can make them disable every security we throw in their way.
Everything can be exploited if the Person using it is not educated enough to know the dos and don’ts, there is no mitigation for that.
Just look at most Malware that runs on Windows, they use no 0days or advanced exploits, they use the stupidity of the User to execute something for them. Nothing can fix that except Education…
I think it is a waste of time to try to create a walled garden, because the same user is going to disable all that because the Attacker told them to do so.
For the security minded People there are enough ways to prevent that (qubes dvm’s, air gapped pc’s, sandboxes etc)
What known threats ? If you run something that you aren’t supposed to run it isn’t a “known threat”…
TLDR:
People are stupid and the Cost outweighs the benefit
By “Known threat” I don’t mean expressly known to the specific user running them, obviously, but a malware already circulating around, that was discovered and included in places such as virustotal. This is something easily avoidable if it is checked by user / any protection system on the OS. Not dealing with known threats, with the reason being existence of many unknown threats, doesn’t make much sense to me. The known threats are a cheap tool in an eyes of an attacker.
I won’t be so quick to use words such as stupidity. Even a well informed person can be tricked in time of need to run something he isn’t supposed to, modesty in this respect is more useful than vanity.
Yes, I guess the practical solutions for security minded people is more isolation of applications and similar schemes. I do that myself. However this also has increased costs in terms of resources, time spent, required level of knowledge.
Blacklisting / signature-based identification is pretty basic really but it does help many people. You can call them stupid if you like. Not only Win10 Defender does it, also Firefox and Chrome with “attack sites” lists, as well as gmail (they won’t allow attachments of known threats or anything suspicious enough and there is no way to turn that protection off).
When we aim to have Windows users move to Whonix for greater anonymity and privacy my opinion is we need to think about providing at least the same level of security if not higher.
That is what i meant, these “treats” are easily avoidable by the User.
I disagree with that, it gives a false sense of security, users stop thinking about treats and blindly trust these systems.
These basic “security systems” are easily avoided by a real treat and the user wouldn’t think about checking them because his Antivirus hasn’t warned him.
Antivirus is a lost cause, just look at the snake oil/antivirus market, nothing there can really secure your stuff,it just give you a false sense of security, while exposing your system to their crappy software that often creates a bigger attack surface than before.
We got that by default with Linux, if the user isn’t doing stuff he isn’t supposed to do, like install or run something before checking it…
Creating a completely locked down system wouldn’t be too hard.
You could block all outgoing traffic by default, run each application as their own user and whitelist the applications through the firewall based on the UID.
Root could be locked down pretty easily so root can only be gained via a chroot from another device (assuming no privilege escalation exploits occur).
They keylogger in this post could likely be defeated by running everything in an X11 sandbox or using wayland.
A lot of dangerous binaries (su, sudo etc.) could be disabled by setting their mode to 000.
Setting process limits with something like /etc/security/limits.conf may help by preventing more than a few programs being run at the same time.
This could all probably be enabled via a boot parameter like lockdown=on.
I have been thinking about the “ChromeOS” version a bit.
When starting from a complete OS (including host) you could have some filesystem image or iso (like the current live iso) with bootloader + kernel + initrd + squashfs. This brings up the Whonix host. From there you can boot the GW and WS either via the qcow2 files or in a similar way as the host with kernel + initrd +squashfs.
Host and guests are all based on a minimal Debian XFCE installation so share much of the same code.
You could then maybe make use of this: filesystem - How do I use OverlayFS? - Ask Ubuntu (first answer)
and this https://tails.boum.org/contribute/design/incremental_upgrades/archive/
to create a squashfs with a smaller size (maybe 1-1.5GB).
In this way maybe (!) future updates to this system could be smaller in size. The update would be a binary patch to the host filesystem (either just the squashfs or the whole filesystem image). You probably want some A/B mechanism where you update system B from A and then boot B, or if it does not boot, fall back to A again.
Problem is:
It would be a completely new setup. Whonix would be responsible for all updates (requires timely rebuild and upload)
Devs would need to keep a base image around all the time to have something to diff against.
Larger changes to the base would require rebuilding. Some config stuff which is unlikely to break could maybe be kept on a persistent overlay.
You need some data partition for apps (flatpak, snaps, appimage) anyway. Some messengers like qtox are available in that form, also programs for cryptocurrencies like electrum or monero-daemon are available. There are more, but beyond that everything else requires a rebuild or someone creating an “app” for that program.
Upgrades need to be done from the host or maybe from within the guest if you still have some ro root of trust (ro grub somewhere, or BIOS?)
Advantage would be:
Everyone runs the same OS which could easily be verified.
This is maybe not always an advantage (see recent iOS exploits) but currently most users would share the same OS anyways (plus maybe some programs they installed manually). Each reboot would bring the whole system back to a sane state.
squashfs with some patches can be build reproducible. If you build from debian snapshots or some kind of git repo with all the required packages then you could also distribute the trust to some extend and others could rebuild the exact OS.
Yeah. I am not discounting the idea just yet but seems a pretty big burden.
Yes, which then wouldn’t be included in verified boot.
Yes, this would be big. Since Debian isn’t stateless, everyone has kinda their very own unique Debian system with no easy way to see the difference in files between distribution default and user customization. Upgraded builds aren’t guaranteed to match newly created builds. Perhaps a majority of issues come from that.
Just now created:
On verified boot:
I am wondering if we hit the maximum of what is doable with Debian. A stateless system and verified boot sequence might require porting Whonix to another linux distribution. It’s not clear to me which Linux distribution has it all. Ideally, it would also support reproducible (deterministic) builds or work on that and provide that in the future.
