[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [Priority Support]

A bit of pentesting on Whonix Workstation (13)


#1

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 :slight_smile:
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.


#2

It’s not a multi user operating system. Rather, multi VM.

Any linux distribution that handles that better?

Perhaps Qubes with https://github.com/tasket/Qubes-VM-hardening

Any suggestions?

Whonix 13 is outdated. Whonix 14 was released. But I doubt it makes any differences for these purposes.

Related:

https://blog.invisiblethings.org/2011/04/23/linux-security-circus-on-gui-isolation.html


#3

“if you can convince a user to run a payload, their system is compromised.” ok.


#4

Perhaps:

  • Initial firewall whitelisting of applications
  • Every new app will require expressed whitelisting
  • 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.


#5

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?). https://github.com/tasket/Qubes-VM-hardening seems like a nice balance.


#6

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?”


#7

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.


#8

Henry:

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”.

(All presupposes integration with
https://github.com/tasket/Qubes-VM-hardening)

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:


#9

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

My 2 satoshis


#10

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.


#11

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…