Answer to moderation note
Okay, if that’s a more appropriate category.
Root network is sys-net. That then chains with sys-vpn1. That chains to sys-vpn2. That chains to sys-whonix.
Edit: sys-net → sys-firewall (but you knew that.)
Re: dom0: Well, boot loader hashes changed after the exploit. There is a possibility a ran a dom0 update in the background, and just forgot to note it. Other then an update, or an update attack of some kind, I have no clue as to how they broke out of the VM.
Perhaps they didn’t, and just targeted all the VMs connected to that IP.
The common denominator is the compromised qubes shared the same IP, were loaded, and all had flatpak apps.
There might have been a compromise thru flatpak… and never escaped the VM sandbox. Attacker just might have targeted machines connected to the IP (Tor exit node) with a flatpak fingerprint.
I’m going to test both these solutions.
Just a quick question:
If OpenSnitch is installed in sys-firewall, that would cover all traffic thru all qubes right?
Would doing that potentially open a security hold via an OpenSnitch exploit?
And you couldn’t use something like sudo netstat -tupa to see which process was connected to that IP address?
Yeah. But did those 3 crash (at the same time) or did a VM (or more) crash which was connected to one of those?
You could also break out of the VM by Xen/Qubes/RAM/CPU bugs. No need for an update attack. But of course it still could be an update attack.
IMO, this is a bit insane for a “typical” (non-honeypot) computing scenario; at a minimum how is sys-firewall not in there?
Something like:
sys-net → sys-firewall → sys-vpn1 → sys-vpn1 → sys-whonix
Or, something like:
sys-net → sys-ips → sys-firewall → sys-ids → sys-vpn1 → sys-vpn1 → sys-whonix
Architecture for a honeypot might look like this:
sys-net → sys-vpn1 → sys-vpn1 → sys-whonix
Do you realize how this architecture design impacts your security “goals”? Unless you’ve rebuilt a custom sys-net, sys-net has been built using the default, full/desktop of either debian or fedora and is connected to your LAN uplink (no idea what protection this may or may not provide) which, seems to be the case for many happy Qubes users. However, when you couple this with the architecture you used, you potentially open easily avoidable attack vectors.
Hypothetically:
Let’s say you’re browsing the dodgiest of dodgy sites (because you’re using tor and that’s all it’s good for 
) and somehow, someway, some type of RCE or client-side + LPE exploit-chain exists in any of the applications/services which you are using/may be running/connecting via with a full distro …
With this an adversary may want to begin running a service of their own on port 31337 on your node. At a minimum, this service would be easily accessible from you LAN (the network your sys-net connects to as an uplink). Should your adversary be of “boogie man” status and, they were able to traverse sys-whonix → sys-vpn2 → sys-vpn1, how LOVELY of you to have “left the door open”!
Whereas, even adding sys-firewall (simple L3) with default deny rule implemented would at a minimum protect you from an attacker on your LAN accessing the listener on port 31337. That said, NOTHING is “safe”, until you make it so to your standard.
Example:
Even users who chose to create/use a sys-pihole, would have had to defend agaist vulns like this:
It could, should it be applied as the NetVM Qubes-wide but, this was not the intent of my suggestion. In it’s default configuration you’d lose the fine-grained traffic control/identification which OpenSnitch provides and you’re seeking. I made some progress with a “proper” sys-OpenSnitch but, it’s nowhere ready for prime-time. Besides, nobody tests/uses any of my other salt stuff. 
To be clear, you would want to identify any abnormal traffic flowing in/out of you questionable hosts. To do this, you would want to install the quasi-L7 OpenSnitch firewall directly to the host. Yes, writing to this system is forensically unsound so, if you plan to perform forensics on the disc, be sure to make forensically sound backup of the system/disc in question.
What’s a “security hold”?
1 Like
It’s not very likely that an update attack would allow you to break out of the VM. It can be used as the initial attack vector, but you could still need a Xen or CPU exploit to break out of the VM.
1 Like
If it is an update related to VMs, but not in case you update dom0. It is technically not breaking out of a VM, but you would have the same problem.
off-topic banter
If you’re not joking, then you’re severely naive at how things run outside your little cloister.
Tell this nonsense to 2 of my colleagues who are dead. Tell it to my other colleague who was wrongfully committed to an insane asylum, and kept pumped up with drugs to keep him silent.
And for someone you might even be able to relate to, tell that to Assange.
Like most good obedient slaves, you’re severely ignorant to how the world runs. Try traveling a bit. Try stepping outside those lines painted for you by the good old USSA. Try working on anything beneficial to humanity, that directly confronts the cartels that run this prison planet.
If you have something useful to offer the problem at hand, I’m all ears, and I do appreciate it. If you have another string of derogatory comments, well… in the words of a mentor of mine, “you can go $%^& ______”.
Re: Security and privacy.
No, I hate this shit. I hate having to dedicate so much hashing power for this shit, that in the end does not create anything of value. It only prevents the destruction of value.
I would love to leave this shit up to other people, and instead focus on creation. But in this dystopian world you seem to be completely naive to, we don’t have that luxury.
Re: network
This was the string. All qubes connect to the firewall via sys-net first:
sys-net → sys-firewall → sys-vpn1 → sys-vpn1 → sys-whonix
And for that particular application it gave the other side the perception exactly what I was looking for. And if it hadn’t we wouldn’t be talking now.
Re: dom0 update. I cannot rule it out. But whenever I update I’m fastidious about noting it down, rebooting, and checking the hashes when the updates are done. It was a long computing session thru the night. I can’t rule out that I just missed something in a tired state. That’s the only vector I can imagine unless there was some zero-day that could break the vm sandbox.
Re: A bad update:
No, qubes were taken down in a coordinated attack. Likely Flatpak was the security hole.
Re: Security hold: Security hole (but you knew that).
Cheers
You guess wrong.
It was assumed all qubes connect with sys-net as a starting point and then go thru the firewall. Who wouldn’t? That would have been redundancy to restate that.
comments about style of discourse
And I appreciate where you have something useful to offer. If you’re going to be derogatory, well, the Law of Correspondence is pretty universal. With that lead in… you’re not that special. There’s plenty of others more technically competent than you who are happy to help, free of the attitude.
But thanks for your help when you were actually being helpful.
1 Like
Since you specified sys-net originally, but didn’t specify sys-firewall (comment 14), I can’t fault cayce for assuming you’d left sys-firewall out. Far from default-assuming both were there, you specified one and not the other.
comment about style of discourse
But I do agree his attitude later on has been abysmal.
1 Like
off-topic banter
I thought it’s been made abundantly clear by now that I’m NOT posting on this forum to make “friends” nor bother much with social nicieties. Rather, to share any insight I may have gained from decades of experience in an effort to try and be helpful to others. Take it or leave it …
As OP is busy feighning about being in a “life or death” situation, spewing about “how the world runs” because they feel as though their position as some social-justice warrior somehow makes them a superior individual with respect to other’s, attitude ought be low on the list of “demands”. If my “attitude” is too much to bear, wonder what the reaction would be should an actual threat present it’s self (as the OP is SO scur’d of).
off-topic banter
GREAT, I 
being wrong, really aids the learning process. 
Highly recommended, you really ought try it sometime!
So, call HQ right NOW and have them send the forensics team to your location or, at least ask them what the documentation of your org’s incident response plan dictate your “next steps” will be.
Ass-umptions are always key ingredients to sound DFIR processes!
I dunno, maybe a user who stated otherwise?
Not so much if something in direct contradiction to “that” which had previously been stated.
side discussion about doubting the OP
Talk about assuming…you’re assuming OP’s description of her own situation is false.
On the basis of what?
Answer to @SteveC
I don’t doubt that the OP is scur’d but, for starters:
- Being too lazy too take the steps necessary to ensure the “safety” of their endangered life?
Or, maybe to take a step back:
- Being too lazy to provide accurate information to those they’re asking for help during a time of crisis resulting in squandered time/effort? This always goes over well and is appreciated during disaster recover/incident response “drills”.
Or, maybe:
- Spending too many years in the SOC having to explain to management how a paranoid
just just burned up two weeks of external consulting resource budget and as a result, now the team can no longer attend the con/training?
Or maybe, maybe:
- It’s the trail of confusion left in the litter of their posts?
But, probably:
- Because I’ve never met an operator who “brags” about the EOW of their team members for the sake of personal sympathy/attention. Full f*cking
.
1 Like
It’s not impossible, but if you follow recommendations and don’t install software in dom0 it becomes very difficult to use an update attack against dom0.
I don’t think it’s easy to backdoor a package in eg. the Debian repo, but maybe for a state sponsored actor could do it if they picked something rarely used, but trying to backdoor the Linux kernel or Xen is on a completely different level, it wouldn’t go unnoticed.
2 Likes
Moderation note
I tried to restore the readability of this thread by liberal use of the “details” tag.
We encourage to read about staying safe, our discussion guidelines, and our code of conduct to help keep things positive and on-track. We welcome newcomers and returning users wanting to discuss Qubes and seeking to contribute.
Everything that is not a direct answer to the question posed in this thread belongs into Forum Feedback.
5 Likes