One must remember: there is nothing like safety by default.
I did interesting test in situation where everything in LAN was infected. Infected Win, Mac, Linux computers, infected all mobile devices iOS/Android. Infected router. Everything was turned off, except router.
I was curious how much time unknown pentester will take to brake uninfected laptop with installed from scratch Qubes 3.2/Whonix…
Ok. Let,s turn it on!
If it is connected to infected router, it’s matter of 5 minutes!
Firstly he broke fedora nerwork VM, then he did access to XEN, and start some code to change boot process, at this time I turn off laptop.
After some time I did research with this laptop, and it’s BIOS was changed on different version with backdoors.
One must remember, there is no safety if your internet access is honeypot.
Safety is no static. It is process of step-by-step hardening, not only Install and Go thing.
And, please, avoid public free wifi connections. One can be knowledgeable those WiFi can be infected as well.
Save your internet connection IP, like it’s your best treasure.
No system is “Safe by Default”. No system is is immune to compromise especially if the router or one or all of the systems on the LAN is infected with malware. This applies to any OS including Qubes.
Unfortunatelly I have lost all devices for test with this unknown pentester at this time. It’s interesting how much time he need to broke OpenBSD system.
But it’s hardware depending as well. Systems without disabled Intel ME and with vulnerable network interface will fail, no matter what system is installed.
If your ISP have dynamic\changing IP, go for it! My LAN was on static IP internet access. So even after rewrite ROM on router it was broken again. After change of IP attack stops.
It was hard time to rewrite every device BIOS and ROM in infected LAN. Because infected BIOSes have protection algorithms to avoid rewrite it
Please correct if I misunderstood. I think you are claiming that an attacker used known vulnerabilities in Fedora / Xen / Intel ME to attack your newly installed Qubes laptop that had not yet been updated. If so, then you are correct in pointing out that systems:
remain vulnerable until vulnerabilities are patched
require trusted networks / media to patch vulnerabilities securely
I believe OP conducted these tests i.e. pentesting. That’s how I understood it. Could be wrong though.
EDIT: I see now, an attacker compromised all systems on LAN and OP wanted to see how long it took a newly istalled Qubes 3.2. to be compromised. Thanks for clarifying that entr0py!
No modern high density silicone is safe. I did a lot (2-3K) of systems and networks that are safe even from a nuke in space (685 in one year OEM). That is why your water is not shut off by hackers, your traffic lights work most of the time, people do not take over emergency room equipment, US nukes are on 1990’s technology etc…(including North Korean things). I was taken through Qubes 3.2 and RC4.4 but nothing like 5 minutes (more slowly over days). If you want to be more secure have Fedora 27 Security Labs installed as a template and NetVM (some work! but a lot of things work out of the box).
This has to be in the political part of this forum!
Where did you even find the ROM for download for other devices such as the ROM of the network card? Let’s call these ROMS “hardware firmware” to have a term distinct from BIOS.
How did you even dump the original firmwares? Doesn’t this require special hardware?
Against attackers with access to CPU backdors, we’re of course very much hosed. No one should expect the Whonix project to sort out these astronomic scales of projects to get all the hardware secure from the ground.
Too bad. With your immense skills you would be an immense asset for the security community.
Please consider leaking the compromised firmwares.
Please understand that the Qubes OS Project cannot act on these sorts of claims when no details are provided about how to reproduce or verify the alleged vulnerabilities. If the alleged vulnerabilities actually exist, we’d love nothing more than to fix and announce them while giving due credit to the discoverer(s) (if we haven’t already done so), but in the absence of any actionable information, there is simply nothing for us to do.
Like most software projects, businesses, and websites, we receive several vague claims through improper channels about alleged security vulnerabilities every week (most of which are spam or phishing attempts). If we were to try to investigate even a fraction of these, we would never have time to pursue the main goals of the project. Given their lack of credibility, the only reasonable response is to ignore them.
By contrast, when someone responsibly discloses a security vulnerability through the proper channel, we always take it seriously. For details, please see: Qubes OS project security center | Qubes OS
These two comments are not entirely accurate (or, at least, might be misleading to some readers). It depends on the nature of the vulnerability. Every Qubes update must be validly cryptographically signed before it is applied. As long as the hypothetical vulnerability does not compromise this procedure, receiving updates through a compromised network will still be secure, since the packages will either be authentic (as proven by their valid cryptographic signatures) or will not be installed at all.
For dom0 updates, in particular, see: Dom0 secure updates | Qubes OS
(While TemplateVMs do not implement the same procedure as dom0, the default templates also require valid cryptographic signatures on all packages.)
Since the Qubes security model assumes that the network is untrusted, we usually respond to vulnerabilities that compromise the update process by releasing new ISOs in which the vulnerability is patched.
Agreed. Had my head up some rabbit hole when I wrote that. As in - a compromised (or unpatched) base install can override any update mechanism no matter how secure. Of course, in such a situation, all is already lost with no recourse. The point being that it’s imperative for any distro to provide patched images as expediently as possible - which Qubes makes every effort to do.
I dump my BIOS about once a week with the tools in UBCD and compare with what I had. There are BIOS editors and blasters and all type of hardware tools. Most of the of the shelf computers will not recover from a BIOS attack. Whoever does the attack MUST know your exact hardware otherwise it will be obvious.
Calling bullshit on that story. It is clearly a made up story.
Indeed it is theoretically possible to use unknown exploits to escalate privileges, but no way a “random hacker” will use so many 0day vulns to attack a random user/IP.
Just step 1 is really really hard. I can’t even remember the last RCE in Fedora (NetVM) and even if someone found a RCE in Fedora/Linux TCP stack, then they would most likely keep it very very secret.
