That’s,uh, unfortunate.
I doubt we will get any further with this.
I’ll pass on that.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Someone from the Qubes team isn’t going to want to reveal a physical address.
You could encrypt the drive with AES-256 bit encryption using many tools out there, rent a VPS for a day or two, and make it available to the team. You could also break the image into parts and send it. Additionally, you take the system offline and backup just dom0 and sys-firewall and sys-net and send those.
0 days do exist, is a 0 day was used on you, the team should know.
The reason people are skeptical of you is that are you saying a lot of things that seem to indicate a low familiarity with qubes, like saying the developers must be on drugs.
It would be hard to install a rat into sys-net because it’s using a template.
It would be hard to jump from permanent malware in sys-net into dom0 because they are isolated using Xen.
A bug affecting Xen compartmentalization that a good hacker could use to make that jump would be a big discovery, so if this really happened, and you aren’t lying, you should send that.
Some of the things are you saying seem so bizarre it’s hard to know if you’re not a bad-actor trying to look for a vector to do something bad. If this is real, just backup dom0, sys-net, sys-firewall and send them. You could even just use a strong password and send it to unman using unman’s public key, which I’m pretty sure is still somewhere on the internet (mit?).
Are you sure this is dom0’s thunar or could it be sys-net’s thunar?
Well, it’s here and on keyservers.
Being on drugs, I dont think I’ll have time for this.
On a general point, reports to the security team are limited:
Please note: The Qubes security team email address is intended for responsible disclosure by security researchers and others who discover legitimate security vulnerabilities. It is not intended for everyone who suspects they’ve been hacked. Please do not attempt to contact the Qubes security team unless you can demonstrate an actual security vulnerability or unless the team will be able to take reasonable steps to verify your claims.
I’m afraid that in this case, there’s little evidence of a
legitimate security vulnerability. If OP can provide that it might be
possible to take this further.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
1 Like
Help me understand this. A Remote Access Tool (RAT) would have access to the GUI. The Application menu gives access to a dom0 “Xfce terminal” , Then why can’t a RAT access that? It seems very possible to me.
If I remember correctly, there seemed to be nothing typed into the terminal. But I may be wrong.
What do you mean with “Access to the GUI”? The GUI runs in dom0, so when your RAT tool has access to the GUI, he is already in dom0 and dont need access to an start of the terminal.
All what you see on your screen is basically dom0. dom0 can start anything in dom0 and also anything in any qube.
If you, for example, click on “start firefox” in qube “untrusted”, your dom0 calls the start of firefox in qube “untrusted”.
If you click on a point in the screen of file manager in qube “untrusted”, your dom0 tells qube “untrusted”, on which point you have clicked and with which mouse button.
You need urgently an understanding, how qubes works. Otherwise, these type of questions makes no sense.
Please point me to web page that explains these things. Thanks.
Also is there a keystroke combination that I could have mistakenly pressed to pop up dom0 xfce terminal ?
I also recommend reading the docs in general:
Please understand, that your rat tool, that has occupied any qube, can do nothing outside that qube. And also it can do nothing in any sytem folder like /usr/bin or /var/log/ or or /etc or somewhere else.
All changes, that are made in that folders (except your home folder and folders, that are defined as bind dirs, exists only in memory and are not written to any file in that folders.
Dude, like i said before, a RAT could not run on dom0. It doesn’t have internet connection. How a RAT would work without internet connection on the victim’s PC? This is not possible. Also, it is very unlikely, almost impossible, that a trivial RAT that you installed on a qube (domU) escaped the VM and infected dom0. This would require a 0-day chain, which is not a trivial thing. Only top 0,1% elite hackers have something like that. Exploits for VM escape is one of the most difficult exploits to develop. And the majority of VM escape exploits need something special that doesn’t happen on Qubes, like 3D GPU Acceleration, a hardware/driver like Network Adapter attached to the compromised VM and more. Also, the hackers that has resources like that wouldn’t just use it on a simple RAT that you can install normally on the internet. That just doesn’t make sense. Read the documentation and introduction of Qubes to actually understand how the architecture works.
@connor.blane I don’t mean that the rat was installed into dom0. I mean the the rat was probably ran in sys-net or sys-firewall or untrusted, then it can access the pull down application menu, and invoke the xfce terminal for dom0. Xwindows allows inter window communication screen wise.
If like @murdock says, the gui is run in dom0, then I don’t understand how come the xfce terminal dom0 window appeared on my desktop. There seems to be no hotkey that brings that window up. And I was away from that laptop for a few minutes.
GUI runs in sys-gui or dom0 if you don’t use sys-gui. There’s no way a compromised qube gets control over the gui without compromising direcly the GUI domain of sys-gui/dom0. This just can’t happen if sys-gui/dom0 aren’t compromised. Probably you opened this terminal, have forgotten and, when you returned to your laptop, it surprised you. Don’t get offended, but i think that this is not a healthy type of paranoia.
There is no reason for me to open xfce terminal to dom0, I don’t know/remember the qubes commands. The only time I touched dom0 was when I was setting my wallpaper.
Okay. So you’re compromised… Good Luck!
I don’t mean that the rat was installed into dom0. I mean the the rat was probably ran in sys-net or sys-firewall or untrusted, then it can access the pull down application menu, and invoke the xfce terminal for dom0. Xwindows allows inter window communication screen wise.
No, it can’t. No qube except dom0 or sys-gui (if you use it) has access to any menuoption of dom0. Even an qube itself has no way to use the own menus. All of them is running inside dom0 or sys-gui.
And about inter window communication:
In every qube runs an own XServer. This XServer is responsible for all output from that qube. Your inter window communication can so only happens between windows in that qube. It exists no way to access a window of a foreign XServer, running on an different qube (and that from dom0 also).
If you like more deeper explanations, see GUI virtualization | Qubes OS
If like @murdock says, the gui is run in dom0, then I don’t understand how come the xfce terminal dom0 window appeared on my desktop.
Yes, slowly you got the point. It is not possible, that it happens like you has described. It must have another reason, why your dom0 terminal was open.
I’ve had an extra dom0 terminal window open shortly after login before. I didn’t think too much of it because I have one configured to autostart, but did wonder if the OS had opened another for some reason. No keyboard shortcuts that I know about.