After checking logs on my router I’ve confirmed a hack. Many root ssh sign-ons over many many months. The user was LAN because of my building type. There were strange quantity uploads that don’t match up for my browsing habits.
I know who the hacker is, and they are aware I am qubes user.
I need help with auditing my system. I’m not expert qubes user. Maybe power user. But not coder.
How can I start to audit Dom 0 and its dependencies? I don’t know where to start with auditing Dom 0. I don’t know how or what I can do to cross-reference a clean dom 0 state. However, I’ve never touched dom 0 myself so that’s probably a good start.
In a panic I reflashed the router. However I completely backed up qubes from the moment of hack detection.
It’s my hope they only got the router. But the uploads don’t make sense. I’m scared.
Please help. I cannot work until I audit this system.
Long time qubes user. Love it. Thank you for qubes.
Unfortunately I am not knowledgeable enough to help you, but I would like to note that dom0 has no networking, so it would be extremely hard to hack it. One would need to find an escape from VT-d hardware virtualization to escalate the privileges from a VM with networking, which is extremely rare. Do you have any reason to think that dom0 was compromised, too?
See also: Frequently asked questions (FAQ) | Qubes OS.
So your router was hacked? Router like some external adsl/wlan/whatnot box? Guess what, those are hacked every day, but that doesn’t mean your computers are hacked.
In fact, I consider my wlan/wifi router as malicious as any public wifi. I consider it owned.
The reason is they are sophisticated enough to understand and execute a method such as blue-pill. The attacker is not an individual, but a large team. I have no reason to believe I’m not compromised, hence the necessity for auditing. They wouldn’t even need to learn blue-pill. It would be an automated and adapting (machine learning) tool in their arsenal.
I have the Asus RT-AC68U with openwrt. That’s what was hacked. I’m assuming with my limited knowledge because I don’t have ssl installed on openwrt and they captured my password in plaintext through browser login. I don’t have access to the buildings adsl/wlan box.
Okay everyone thank you for your responses. My plan is to just reinstall qubes, and whonix, I’ll keep the backup for auditing later. But I believe if we can keep this thread going, I hope it leads to a how-to-audit-qubes manual to benefit the rest of the community.
Since I am just going to redo my most used templates, please recommend if I should do anything else such as hardening qubes and whonix this time around. I don’t believe this problem for me will go away.
As with any “tool” when not in use put it away “turn off” your computer. Why the hell would you leave your computer running 24/7. It’s not good practice.
1.) Someone is always able to attempt to get in it.
2.) Electronics do have a lifespan. They don’t live forever,you can only write to then so much and the old power surge/outages only decrease this life span
3.) Burning up un-needed electric.
4.) You don’t change your passwords enough. If they were able to access any of your devices.
Friend, based on this piece of information and your overall description, I recommend you buy a new laptop from a store directly (no shipping), and install Qubes on it, and don’t ever leave your new laptop away from you.
It is easier for the adversary that you described to infect your firmware (evil-maid) by visiting your home in your absence, opening your laptop and putting the new firmware in, rather than implementing a remote hack. Your adversary probably wouldn’t bother deploying a sophisticated hack that will go a away when you reinstall Qubes.
And it’s very difficult to verify the firmware hack. It’s impossible to remove it unless you ship your laptop back to the company it made it.
Main device was never 24/7. I checked the logs on the router that showed me the ssh logins over months. That too wasn’t always on. But the logs show me what it was doing when it is on. However I’ve never myself logged in to my router until I noticed strange upload quantity by way of another metric system. Thats when I saw some other ssh that definitely was not me.
The building has poor network security but good physical security. I have access to the buildings cameras. I also have hidden cameras as a backup. No one touched my box. I also have TPM setup. My bios hasn’t been tampered with. I bought the motherboard cash during travels. @fsflover No interdiction. Yes I use coreboot. My only concern is network.
Can we get back on topic? I simply want to learn how to audit a qubes install. I’m sure I can’t be the only one curious about this. The solution to audit cannot always be “throw away computer and just reinstall from source” can it? Maybe I’m wrong. But I think it’s would be a good skill to have to be able to audit one’s system. I just personally don’t know which way to go about it. But I’m willing to learn! If some nice person can offer guide. Thanks u.
If you do not trust the software running on your device, you cannot trust what it says to you during a “verification”. So I don’t see any reliable way to check that. Try this instead:
I asked Joanna about this a long time ago on one of the Qubes mailing lists. I can’t find the thread right now, but you can probably find it with enough searching. I’ll try to summarize the conclusion, but my memory is pretty terrible, so I apologize in advance for getting anything wrong.
Based on what I can recall, the upshot was basically that there’s no way to be certain that a computer has not been compromised and that this is true of most computers in general, not just those running Qubes. Basically, the idea is that no matter how thorough of an audit you perform, there can always be something malicious that you failed to detect and that this is a practical concern, not just a theoretical one. Therefore, any “OS audit guide” can at best say: Here are some things to check. If you don’t find anything, then the computer might be fine, but it might not be. There might be something you missed. There’s no way to be certain. (Such certainty might be possible with a formally-verified system, but Qubes is not such a system.)
This is part of the reason we don’t have any such “audit guide” for Qubes OS. We don’t want to deceive or mislead or users by offering security guarantees that we know are unachievable. We strive to do the opposite: To be frank and transparent about our security limitations. The other reason (probably the main reason) we don’t have such an “audit guide” is that it would be extremely time-consuming to create and maintain, and not just anyone can do it. For example, I wouldn’t be able to write it, because I lack the expertise to do so. It would have to be our best security folks, and they’re always busy with more important things, like building and maintaining Qubes OS itself.
However, none of this prevents the community from writing its own guide.
I’ll move ahead with reinstalling. And redo whonix and such.
Could you link me to the mailing list?
Also if I wanted to figure out and start studying all the working parts of qubes and start picking it apart file by file, how exactly would I do that? Is there like a map of the OS and all it’s parts? Or how could I go about mapping it myself?
I’m guessing the best place to start is from boot to gui login. I’m just not sure how I can produce a print out or log reading that would show me every thing loaded, including all dependencies.
