As soon as that physically different system shares the same USB-Sticks or netshares, you’ll have to re-calculate.
That code you speak of for exploiting dom0 would be of high interest. Can you elaborate, please?
1 Like
Not at all, to start with, proxy usage will be implemented through NetVM, not per app configuration. An attacker can leak data from this vm and its metadata, if he wants to leak data from other vms, he will have to bypass the hypervisor. In my chain, by the way, the most valuable data is stored on the host machine, to attack it you have to bypass the hypervisor and attack the host computer via local/virtual network (Because proxmox is another PC) or attack the software used to connect to the VM.
1 Like
I don’t have a POC at hand but it is basically something like
/usr/bin/qvm-run -u root sys-net 'echo <base64-encoded> | /usr/bin/base64 -d > <smallbinary_of_your_choice_ld_preload_systemd_component> ; <trigger_execution_of_rootkit_satellite'
echo <base64-encoded> | /usr/bin/base64 -d > <smallbinary_of_your_choice_ld_preload_systemd_component> ; <trigger_execution_of_rootkit'
Building tunnels is a standard requirement for offsec’s OSCP certificate. Air-gaps or in the case of dom0 pseudo-airgaps makes it certainly more difficult. But an attacker can enumerate very quickly on any qube with network access that this is a VM running on Qubes-OS.
Btw, dom0 runs audio and graphic drivers and firmware, the later carefully crafted by Intel. 
No, seriously, I would love to hear what I am missing here.
1 Like
To be more precise… that was the payload, not the exploit.
1 Like
Where do you run that script? If I understand correctly in dom0. But if you are „in“ there why running rootkits?
He is trying to tell you that the absence of internet in dom0 does not guarantee its security, any intruder who gets access to dom0 will drain it using sys-net or any other available NetVM.
1 Like
Well, sure. But once dom0 is owned, it‘s game over already. So I don‘t see the point. There still remains the greatest security risk of all: Layer 8. Someone tinkering in an unwise way with the barriers is not exactly PoC in my world.
1 Like
When attacker owns dom0 he likely wants to be as stealth as possible.
ld_preload or any essential binary are good places to hide. if blue team runs tripwire or something alike, attach or inject into that binary. of course that requires knowledge about the individual setup, therefore I would assume and start with the standard setup of dom0.
It basically boils down if vulnerabilities exist (which I would take for granted) and if those are exploitable (which can be MUCH harder) and if the payload is allowed to be big enough.
1 Like
If I ask you to git clone oh-my-zsh from a weird third party repo in dom0 you would probably kindly say no. So that would be very dubious, indeed.
1 Like
Well in Qubes case it does, in mine it doesn’t. Access to proxmox does not guarantee access to some data in VM because it is encrypted and unlocked only in runtime. And also the most important data is stored on another host. Also you can’t leak the real IP address because the physical killswitch won’t let you do it
Sounds a bit like the word “impossible”. Usually that boils down to “pretty time intensive and obnoxious”.
Anyway, are you using ansible playbooks or salt stack or something to orchestra your zoo of VMs?
1 Like
In my case this is not necessary, the “guest software” is minimal and installed manually in a few minutes. For the most part it doesn’t need to be updated, there is also some that is downloaded to the VM from the host machine at startup, but this doesn’t require additional installation. I think it’s possible to host things for orchestration if desired. For the most part, management for the vm is done through the proxmox web interface, which has functionality for networking/vm/etc.
1 Like
Again, to be more precise… Promox is orchestrating the VMs but installing and setting them up might be easier if a script is doing that for possible endusers.
I install the OS images themselves manually. But I’ll take your advice and look into solutions to make this less complicated.
For me templateVMs and dispVMs are a major argument for QubesOS.
Proxmox support templates too. But HVM templates not AppVM
Finally, there is nothing stopping you from combining my solution with Qubes on the host machine.
And you are running the admin domain on a different physical machine?
I haven’t experimented with Proxmox so far… so I don’t now almost nothing about it.
How ist Proxmox starting a VM and do you connect to the running VM via ssh?
That’s right proxmox allows you to connect to the created machine via VNC/RDP/SPICE, after which you can configure any other connection method, including SSH. I use seamless via SSH.
Yeah proxmox admin located in another machine.
1 Like
This is well known and has been stated before.
So the issue comes with moving from a qube to dom0, to execute that
payload - that is one of the risks that Qubes tries to mitigate.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
2 Likes