Granted, I am aware Qubes is not Debian and only the virtualized Debian Template qubes may risk exploitation.
So, are these steps needed for further hardening the Debian based Template qubes or no?
I am brand new to Qubes, I am a noob. Please let me know if this applies
FYI, why this is important for me:
I am up against a well funded (he has millions of stolen funds from people I found out on-chain) highly skilled (he is extremely proficient in UNIX, OpenBSD, Python, SSH, JavaScript) adversary Thread Actor who has been Cyberstalking me to carry out ongoing Cyber Attacks against me after already stealing everything I have which was over $100K. Thus is why I am trying to cover all my bases and plan for any known weaknesses in my new hardened network, in my QubesOS, and its Template qubes as I am a huge fan of layering up for both privacy and security protections when I am serious instead of being lax (which I prefer lax, and being lax was fine up until this monster attacked my entire comms infrastructure — both my cellular connections and my fiber after Social Engineering me to trust him as a BF)
I’m going to share some information here which I hope will be helpful. I’m not sure if you are a “noob” with regards to administering computers in general or just with QubesOS in particular. It sounds like your situation requires that you have some understanding of how the computer works in order to keep your environment secure from the particular threat you face so I am going to point you to resources that have useful information, but I’m not going to point you to a “one size fits all” solution.
If escalation from user to admin is a concern for you then you will need to do more than mitigate this exploit because the default QubesOS security model assumes that user-to-admin is not a concern. This page explains why, and also includes instructions for disabling passwordless sudo. The community does not unanimously agree with passwordless sudo, but it seems to work well for most people as a default (keep in mind there is a significant sample bias to which people end up posting on this forum, and an even stronger sample bias to which forum users will decide to post on that particular thread, so the discussion there is not necessarily representative of the QubesOS community as a whole). It is possible that disabling passwordless sudo will prevent this issue from being exploitable but I have not looked at it closely enough to be sure.
Personally, based on what you have shared about the relevant threat I’m not sure if preventing user-to-root within a VM is something that you need to be concerned about. It is more of a concern for well-funded adversaries (state actors, global crime rings, etc) than for individual attackers even if they are skilled. However, if you have some reason to believe that this person might be able to access the resources of a well-funded adversary then preventing user-to-root would be a sensible precaution in my view.
For this exploit in particular, my base expectation would be that the same mitigation would apply to a Debian VM running in QubesOS but I would not be certain that it does. I would check that the mitigation works by trying the exploit before and after applying it (to confirm that I performed the exploit and applied the mitigation correctly, respectively). The article you shared does not include an exploit; my default source for reliable information about CVEs is NIST. The NIST page for this CVE has multiple links tagged as containing an exploit. It also contains links to the vulnerability announcements for Debian and Fedora. If I was mitigating this vulnerability, I would check for its presence in all templates (including Whonix if you use it).
This info you provided is really thorough, THANK YOU SO MUCH omg! This is so very super helpful, thank you so very much appreciated
I finally went down the blockchain rabbit whole tracing the ETH he stole from me and saw he has tens of millions of funds on-chain, be it all his I have grown skeptical now and have sided with some of my contacts that are more aquatinted with such dark stories. In that, he clearly is not gov at least not USA nor likely a US ally. Maybe he is a traitor of the USA, and might be doing work for Lebanon or worse a terror group; but I kinda doubt that too though it isn’t out of the possibilities still. At first I thought he was acting alone and was just some extremely high level Black Hat hacker sitting on tons of Zero Days that ironically recently have been published about (most of the recent Google Zero Days is what he hit me with those are now publicly disclosed oddly after I reported my case and went public pleading for help under my IRL name).
However, now I am starting to agree with some of my friendly good hacker contacts in that it seems he maybe a part of some global cyber crime syndicate. The thing is, I have a strong hunch based on circumstantial evidence that he is either the one supplying warez to such crime rings around the world or is at least near the top of whatever cyber crime ring he is involved in, but likely not the top head of such speculated crime ring from what little I can guess at based on the info crossed.
Personally, now at this point in hindsight I think he does business with global crime rings and sells them warez and exploits and in turn through those dealings along side his spyware blackmail campaigns or false setup framing “blackmail” plots then gains access to even more powerful people to bend to manipulate and/or bend to his will as he runs whatever the heck operation(s) he is doing. These are all my best guesses as time drags on, while still being under attack by him (or him and a crew); as well as upon further reflecting in hindsight on what transpired when he lied to me about his virtues & values when in reality he is a criminal Black Hat hacker and a really nasty talented evil powerful one at that.
I did not even consider this! Perfect idea
Again thank you
I will be going over the cited sources soon later today (it is a lot to take in, especially for someone like me that is not truly at that level but I am doing the best I can and new to QubesOS). If I have follow-up questions I will post within this thread.
On the specific questions, this vulnerability was patched for Debian-10,
fixed in Debian-11.
Qubes ships Debian templates with security repositories enabled, so you
would have got the updated version when you updated the template.
Qubes 4.1 shipped with Debian-11 templates.
Qubes 4.2 shipped with Debian-12 templates.
There is no need to take any additional action.
In any case the vulnerability affected a non-standard and specific sudo
configuration in Qubes, which a user would have had to deploy themselves.
As @skyvine has said, Qubes ships templates by default with passwordless
root enabled. In part this is for user convenience - in part because the
developers do not think that this is a significant security risk in
Qubes.
One reason that the question keeps coming up is that users will not
look back at previous discussions and consider the points explained there.
Ironically, a previous discussion from 5 years ago was titled “Kicking
the sudoers dead horse” - there’s been little advance in the arguments
raised since then.
There are many privilege escalation vulnerabilities - this is one. There
are few qube-dom0 escapes.
• That is a URL I followed from the sources you gave me, that Qubes Forum thread I been following the cited sources there and from there more cited sources — which is where I found this.
What is “separate key pairs” referring to? Would this be the Qubes full disk encryption passphrase(s), or is it something else?
I do have instructions that I haven’t carried out yet to update the default encryption the laptop was shipped with. In those instructions they stated there are a total of 8 slots allocated for disk encryption. So are these 8 slots in Qubes also known as “key pairs”?
Those instructions from an email by the vender selling certified Qubes computer pre-installs said:
Please clarify what the previous cited URL linked source I took a screenshot of is referring to, is it this; the LUKS key disk encryption passphrase(s)?
… and now mulling through these nested sources like this one I cited the URL to, I now wonder where will I find CLI info on how to “admin” from my dedicated admin account so never to log into the regular non-sudo user account in order to run such a command due to the real world risk of a spoofed Fake-SuDo keystroke spyware deploy — for when I want or need to do something in SuDo while mitigating such an attack vector
(although my hope is once I set everything up, I will not need to revisit anything on such “daily drivers” as a SuDo let alone as ROOT as I am trying to prep it for what I need then load what I need once hooked up to the internet on it and then lock it all down once everything is finished being setup thereby never needing to touch SuDo in any way except via a completely separate admin user that I may or may not set up for logging to better capture log evidence of any attempted or successful compromises/breaches;
BUT
if I do need SuDo still for something not anticipated or overlooked
then by that time I should have a procedure to reset everything once every so often like once or twice a year anyway so to start over maybe maybe … I haven’t decided on the whole reset method yet and wish to avoid it as it is just me for myself and then traveling to my mom’s to admin her network and devices and this will be time consuming for just me while I have other priorities such as trying to obtain an income so to recover my life and paydown debt after having over $100K stolen from me (which was all I ever had to my name other than my house and car) … once I am up and running fully online again I need to get back to money opportunities as my focus NOT being stuck playing a forever network and a forever system administrator for myself let alone my mom … and no, due to my new Threat Model I will not be setting up any remote admin functionality to help my mom I will just have to make the long drive to her place as I can’t risk opening those ports as my attacker is much more knowledgeable at SSH than I might ever be one day)
This is also what I needed to know, as I haven’t gotten to the step to setup the Templates thus I still have no idea what build versions those base templates are lol
Thank you!!!
Hmmmm, I respectfully disagree. I need to still restrict the user from Sudo login and it appears maybe have a separation of “key pairs” apparently which I had not known was a thing until reading sources today provided to me by @skyvine (due to the Threat Model I am under and even my mom got dragged into as well)
Yes which concerns me, and I heard rumors of these which is why I am attempting to cover as many bases as possible. I am not in a position to keep finding out how advanced my attacker is, I already underestimated him twice, once before knowing who was attacking me and then second after finding out who I had on my suspect list only to then realize he sits upon an arsenal of Zero Days (which most are now no longer Zero Days and recently patched by Google, though not all especially the MacOS, Adobe, and Android exploits he hit me with too). Knowing he is an expert in UNIX and OpenBSD I don’t want to find out if he can break through Qube’s VMs, so I rather put defenses up assuming he can and will.
Let me put it this way, due to the Session stealer Google exploit he had (when it was still a Zero Day) the only thing that ended his access finally was when I placed a FIDO passkey onto my Google account(s), every other method he still kept access it was mind boggling.
I cant see those images.
Can you summarise the points they contain.
I dont have any context for the use of “separate key pairs”, but I doubt
it’s related to disk encryption.More likely it’s the use of key pairs to
access a system by (e.g.) ssh.
First image is a screenshot block of text that text reads as the following,
Blockquote
This account should if course not share access credentials with the non-administrative account. They should not have identical or similar passwords, and they should have separate key pairs. Furthermore, you must not elevate from the non-administrative account to the administrative account, for the same reason you must not elevate from the non-administrative account to root.
Blockquote
The second image is also a screenshot of text from my email inbox that read as follows:
Blockquote We would recommend that first, you ADD a new key, and check this works. Then proceed to remove the original.
You can do this with:
sudo cryptsetup luksAddKey /dev/nvme0n1p3
This allows you to check the new additional encryption key works, before removing the generic one. You can add up to 8 keys at one time.
Once you are happy that this is working, remove the original with:
sudo cryptsetup luksRemoveKey /dev/nvme0n1p3
LUKS will prompt you for a password and remove the associated key.
Blockquote
Thank you, and my apologies as I am new to this forum and do not know how to insert “alt text” for image uploads here yet. I hope it is a feature but if it is I don’t know how to use it yet
(I clearly don’t know how to use this formatting Block Quote feature yet either ugh)
Well you can tell this for yourself by examining the name of the
template.
You can also look, in the template, at /etc/debian_version.
And at /etc/apt/sources.list which identifies the repositories from
which debian packages will be fetched. Both will confirm the Debian
version.
You can do this if you wish.
I do not think it will do anything to make your Qubes system, and your
data, any more secure.
If your attacker is as skilled as you think, then implementing a control
over root access will do nothing to stop them, and will give you a false
sense of security.
Spend time learning the system, use Qubes isolation to secure your data.
Yea I haven’t yet waded into the Templates because I fear if I do I will spend time setting them up before doing other steps. I need to do these other steps first in case I mess up and have to re-install which then will make my time setting up Templates wasted time which is why I am saving that as near the end of the steps I am currently moving through
I have planned all along to do this since settling on choosing Qubes for my last layer of defense protection. I have also introduced my mom to the concept and had her write down everything she needs to function on a computer and online and how she would be comfortable compartmentalizing her activities after she was recently trained by me for using MySudo doing a similar method. She now understands the concept and has been informed how Qubes isolation operates (has overlaps with how MySudo functions). I have a drawn up plan for her as I am working on her computer first before mine, as she needs me to be done with this and the network firewall stuff before the 1st of the Month so to pay bills in a safer way (we are both getting new IPs too btw).
I am hoping my attacker doesn’t pick-up with web crawlers on any of this
I am using a brand new pseudo-anonymous handle and profile image not generated on the infected phones and am typing/speaking differently than my IRL Social Medias
I can say certain things but I can’t go in detail of certain things I found and realized he is capable of because yes then if this shows in a search engine he could then figure out this is an alt handle of mine
I am being careful, no doubt
So far so good!
When I start working on the network I will make a new pseudo-anonymous handle again, since I ended up needing so much help for the OS I kinda feel like I am pushing my chances if I use the same handle for queries and collaboration help for the whole entire tech stack that I am building out to get back on my feet (my main way of generating income is online that is why)
Something that I sometimes find helpful when making risky changes is to open a disposable VM and try the changes there so that if anything goes wrong my template is still safe. This doesn’t work well for every change, especially if I need to test that the change actually propagates to AppVMs based on the template (I’ve made the mistake of using /usr/local in a template before ), but it can save a lot of headaches when appropriate.
Right now I am for example putting off the LUKS full disk encryption password reset because even the vendor of the laptop warns if I mess up I will have to reinstall QubesOS
eeek
But I will be doing that soon … today or tomorrow. In fact I am making other edits first, in sheer procrastination since I am scared ha … today or tomorrow yup have to eventually before putting it online
But then I saw on the GUI Desktop bar in “systems settings” drop down menu
“Change Disk Password”
I have not used it, but it looks like it just changes the disk password. I definitely wouldn’t depend on it to disable some kind of reset method implemented by the producer of the laptop…
There is no need for anything to be scary.
There are (as you know) 8 slots.
You are using 1 . add a new password to another slot, test that this
works, and then delete the old slot.
This is fully documented in many places online.
You can also consult man cryptsetup - man is your friend.
Good luck!
), but it can save a lot of headaches when appropriate.
