Qubes OS could be honeypot?

Honestly, I really hate this kind of conspiracy posts.

It seems as though most security people find an OS like Kali to be plenty secure.

Says who? Kali is merely a Debian installation with its own repository and loaded with offensive tools. It is all of the usual insecurities of Linux distributions, including lacking of app sandboxes and verified boot. Its defaults are also generally worse than your average Linux distro like Fedora due to it still using outdated and insecure technoligies like X11.

Also as far as I know on Kali or Arch only one process can be hidden with a process hider. On qubes their are endless terminals so maybe endless programs could be hidden.

Non-sense. There have been malware that hides its processes from usual tools like ps, yes. But what makes you think that only 1 process can be hidden??? What happens when your Linux installation (which generally has extremely poor security) gets malware? You are screwed.

In Qubes, the damage is limited to just the AppVM which got infected or the TemplateVMs which got infected and the AppVMs based on it, assuming that there is no VM breakout (which is much harder to carry out that simply infecting a Linux installation).

I am not the one to take advise on technical matters but I am elite when it comes to smelling BS and critical thinking and this place certainly has a fishy smell.

Conspiracy talking.

One thing I do know is you would have to be nuts or a computer scientist to trust qubes for anything other than political dissidence against an “enemy” of the United states and its “allies”.

Non-sense. One does not need to be nuts or a computer science to grasp the general design of Qubes OS. This is trivial stuff to understand.

Even the encryption is a joke against an adversary with the ability to farm out decryption to every windows machine on the planet or more than likely use all the bitcoin mining machines as a network of encryption cracking processor units.

More non-sense. There are issues with how Windows handle encryption by default (only doing TPM unlock instead of forcing pre-boot authentication and so on), but it is entirely configurable by the user.

If you think DARPA cant make Luks2 its B/tch you have not been paying attention.

More conspiracy talk. Unless you can make an actual technical argument, don’t make BS claims like this.

LUKS/dm-crypt does have some drawbacks, namely that the encryption key is loaded into memory instead of being held only in a Secure Element and so on. An honest discussion would focus on the actual technical weaknesses that we know of and attemps to fix them, rather than spewing out complete and utter non-sense like this. Also, you just claimed that Kali and Arch was “secure” above. Do you know what they use? LUKS.

2 Likes

I dont believe I made any real claims.

Yes you did. You make a bunch of claims that have no technical basis outside of just Qubes.

“Have you considered that Qubes may be a honeypot?” is a question.

Suggestive question to push a narrative.

**This is such a strange comment to me. What exactly do you mean. What “solid technical/scientific proofs” do you speak of?

Actual technical discussions. Not conspiracy. Unless you can actually prove that it is somehow a magical honeypot (through the source code, through reverse engineering, through just network monitoring, etc), just don’t make claims.

It is absolutely possible that something malicious slips through and have not been detected yet (this goes for any pieces of software, open source or otherwise), but you really should not be talking conspiracy unless you actually have found something.

Even the conspiracy about stuff like Windows is obnoxious.

I am not making any suggestions or accusations. Also windows, MacOS are without a doubt full of backdoors.

Conspiracy talk. Show me an actual backdoor. Shouldn’t be hard if know actually know that they have them.

That is how they work right? you only get to use them for a little while until they get out and then you patch them and close them forever. Then you call Mr Gates and he shows you the next one?

Please try to understand the difference between a vulnerability and an actual backdoor.

The over thinker in me does look back and think that my comment is a pretty good one to highlight if your going for the appearance of transparency while making the idea look like the ramblings of a crazy person not to be associated with.

Dude, you are talking conspiracy. There is nothing factual about what you said. What you are doing is not “overthinking”. What you are doing is purely just saying a bunch of stuff you do not have basic understanding of in an incoherent, rude, and extremely obnoxious manner.

Would you like to explain why? **Is it crazy to think that maybe nyx would be included in the packages of a tor dispVM? After all this is not supposed to only be for the Linux elite. **

The disposable VM comes from a disposable template. What packages being included in the disposable template is up to you to decide…

There are arguments to be made about removing unnecessary packages for attack surface reduction. But you are turning this into conspiracy talk right there.

One thing I will note is that nobody that I have seen here has yet to say that they trust qubes because made their own reproducible build and validated their hashes.

Doing that doesn’t mean anything unless you also verify the source code. And no one realistically verifies the source code for everything they use either.

The reason why people use Qubes is that the design of it is much, much better than your average Linux distribution and provides strong isolation for different groups of applications.

I dont break the law so I gave up. Unfortunately it looks like things like choosing what goes in or out of your body will be illegal before long so I am planning for the day when I will be a criminal.
I mean I am a libertarian so my live free or die tee shirt could already be illegal, It surly warrants a spot on the DOJs biggest threats to democracy list it would seem.

Conspiracy talk.

As of now Qubes is the winner by a mile against Windows and MacOS though as I know them for a fact to be working with the government any chance they get.

Conspiracy talk. Yes, Apple and Microsoft do work with the government, but that doesn’t mean they will do it at every chance they get or that they actually have a backdoor in theor operating systems.

Qubes is not always better than macOS or Windows either - it lacks things like verified boot, per app permission control, and so on. It being better at isolating groups of applications does not mean that it is better for all use cases or against all threats.

With the Anom phone, which was absolutely a honeypot

And some guy actually found the actual backdoor before the whole thing went down.

Not knowing when and how we downloaded qubes means nothing, if it phones home the Mac address of my router they know exactly where I am and who pays my isp or gives them the name and address on the bank card that ordered my motherboard.

What??? Mac address randomization is a thing. And how is the mac address of the network card even tied to your motherboard? What?

If you don’t want your ISP to know you are downloading Qubes, use a VPN or Tor.

You see this is the kind of thing that would would actually make me worry about qubes.
I am sorry if you really believe this but this is the exact kind of thing I would expect to here from a honeypot.

This has nothing to do with Qubes to begin with. This is basic opsec.

At least not for a regular person. I guess you could sniff the packets going in and out of the PC and check them all out but that doesnt sound doable for a typical person.

Perfectly doable for someone who’s got the time and energy for it. It’s not rocket science and is trivial to do.

**Word on the street is their are millions of dollars in reward money should someone find ways into qubes. If so dont be surprized if people dont offer them up for free for patching lol. **

If it was a honeypot why would the government pay people to find exploits for it?

Also to repeat I made no claims here

You made a bunch in your original post and you have just made a bunch more.

I take pride in my ability to change my mind when I receive new information though so I am not the type you cant win with.

You are talking conspiracy to mislead naive people.

There are probably not many here including the devs that could go thru the code and be sure a team of government super geniuses did not hid some extremely elegant never before seen hack in there somewhere.

You can say that about any piece of software, including Qubes’s upstream. Why make this whole thing about Qubes specifically?

4 Likes

Kali is merely a Debian testing installation with all the
insecurities that brings.

3 Likes

Ah yeah, I forgot about the fact that it is also Debian testing. This is even worse than Debian.

2 Likes

For the last few days, I have been following this thread about Qubes possibly being a honeypot. I think that this is a very valuable discussion, but so far I find it rather disturbing. There are many arguments for and against this proposition, but they are rather unstructured and so have no chance to come to a real conclusion.

What is needed, in my opinion, is a systematic approach to this question, and that needs to build a threat model, analyzing which threats are relevant and which are not. I will try to collect these arguments and structure them in the following paragraphs. Please excuse if it is a rather lengthy text, but Qubes is a complex system, and so the threat model is complex, too.

The first question is: Can / should we trust the ISO used to build Qubes?

This file is accompanied by a digest and a PGP signature, based lastly on the Qubes master signing key whom you have to trust as a security anchor. The fingerprint of this key is rather widely available, so there is some hope that you will get the real thing and not a fake one. Downloading the ISO file and checking it against its digest will assure you that you get the correct and unmodified file provided by the developers.

But is this really the system built from the correct sources?

Contrary to closed source software like windows, you have the possibility to dowload the sources, check them against their signature in github and build the ISO file yourself. This process is well documented and, according to cries for help in the forum, is used by a lot of Qubes users. So there is the possibility to have a Qubes installation media verifiably consistent with the sources.

But do you trust the developers to provide sources without backdoors?

This is rather a key question. As has been correctly pointed out in this thread, there exists the possibility that one or more developers might be forced or bribed to install a backdoor somewhere in the sources. If this were well hidden, most users will not be able to detect it. On the other hand, if not all developers were subverted - which is highly improbable due to their worldwide distribution - some of them will surely detect code that should not be there and start asking questions.

Here the canaries, which are published every three months or so, come into play. In these canaries, the Qubes team assures that the system is clean and not compromised and that no attempt has been made to force the introduction of unwanted code. While possibly one of the signers of these canaries might have compromised the system and be forced to state the opposite in the canary, it is highly improbable that all signers could be forced to sign such an untrue statement, just because they work in different countries and under different legislation. And since they are developers and understand the system, they would detect such a modification and reject signing a false statement - and not all of them can be forced to sign it anyway.

There is one more argument: Since Qubes is an Open Source project, the group of developers might, at any time, be joined by new developers, as has occurred several times in the past. Hiding a backdoor from these new members of the team will be impossible so thus even if a backdoor was installed at some time, it has no chance to stay undetected.

Could a third-party review detect backdoors in the source?

@anon11917472 rightly states that the openness of Open Source is of no additional value if no one inspects these sources. To get trust in these sources, audits have to be performed, analyzing the sources in depth and checking for potential security flaws. At least one such audit has been performed by the Freedom of the Press Foundation, for its SecureDrop workstation. The audit has shown some minor bugs, but no backdoors. It is, however, somewhat difficult to estimate the value of this audit, as its depth is, to my knowledge, not sufficiently documented. According to ISO/IEC 15408, an audit that would reveal backdoors in the sources should be done at level EAL5 or higher, but even at lower levels, backdoors might be found.

It would greatly enhance the confidence in the sources of Qubes if such an audit would be performed by one of the official certification bodies, and I think that it is a serious deficiency that, to my knowledge, this has not been done already. (For this, I have already contacted the BSI, the German government security agency, but they seem to have no one in charge of operating system security, and there is nobody available to finance such an audit!)

What implications of Qubes system Architecture are there?

Qubes heavily relies on compartmentalization and isolation of system components. This is somewhat ignored by the critique of @anon11917472, when they remark that an unhardened Firefox is used, which might pose some risk. I do that myself: For surfing, I just use the standard untrusted Fedora qube with the Firefox provided there. I have even added some extensions which may increase or decrease its security - I don’t know and I don’t care! This qube has no valuable data, just some files that were downloaded, could be downloaded again if needed, and will be thrown away after inspection. So, even if this qube were somehow compromised permanently, e.g. by inserting something bad into the Firefox profile, it does not matter at all. If necessary, I could throw the whole qube away and recreate it within minutes.

This situation would be different if an attacker could break out of this qube and attack other parts of Qubes, possibly even dom0. But this would require the attacker to find a loophole in Xen which could be used from one of the VMs. Such a loophole would not be a backdoor in Qubes itself, but an upstream fault in its supply chain. In order to get control over Xen, an attacker would have to cross the hardware ring protection provided by the processor and get from the maximum ring 1 allowed for VMs to ring 0 reserved for Xen, and this would be such a serious fault that it cannot stay undetected for a longer time. Such faults have existed for the whole lifetime of Qubes and they are a consequence of using Xen as its technical basis. But, if and when such a fault has been detected, it will normally be corrected within a few days and so has only a rather limited impact.

With this one exception, my permanent data are protected, as they are lying in a different qube, having no network access and no software like Firefox installed, and, just for enhanced security, being based on a different operating system (Debian instead of Fedora). All this except the last point holds true for dom0, which therefore cannot be compromised unless there is a serious flaw (or backdoor?) in Xen. But Xen, too, is Open Source and thus could (and should!) be subject to the same audits as Qubes.

For access to sensible websites, I use the Tor browser in a Whonix AppVM or, for higher-risk locations, from a dispVM based on Whonix. I assume that the Tor browser in its basic configuration, is more secure than the unhardened Firefox, and that any compromise of it, which would not only affect Qubes, but also Whonix and Tails, would be and has been quickly corrected.

What about the costs of an attack?

The arguments above, mainly the multi-party structure of the development team and the effect of compartmentalization, raise the needed effort and therefore the costs of a security compromise of Qubes considerably. So attackers working on the principle of getting most bang for their buck would surely give a wide berth to Qubes and instead attack systems like Windows or MacOS, where they have more targets, and success can be achieved without much effort. So, probably, you and I will have nothing to fear from such attackers, because we are simply not worth the effort.

But what about some possible high-profile users of Qubes? Such a user might be attacked with nearly limitless effort, for instance, if some three-letter agency decides to attack them. But such a user would - if they are serious - not use Qubes unprotected and without additional security measures. There would probably be firewalls, intrusion detection systems, and a decent network structure, and such a user could and probably would do source audits so that any backdoors in Qubes would be detected prior to its deployment. So even there is no need to use Qubes as a honeypot, as it would not work at all.

One should not overlook the fact that security is not only technical security but there are other ways to reach the goal of a security breach. Instead of spending a million dollars on subverting an IT system, the same result might be reached by paying a suitable user of this system a thousand dollars for the data to obtain.

Conclusion

Qubes is a highly but not absolutely secure system. Trying to use it, via some backdoors, as a honeypot would be extremely difficult and, from an economic view, might not make sense. Following this reason, Qubes is secure, and that is just what is claimed, to be a reasonably secure operating system. So, at least, I am glad to have it!

11 Likes

I expected that you would say something like this, but I’m afraid it’s simply not accurate. At the very least, by asking certain questions, you’re suggesting that some possibilities are more salient or worthy of consideration than others. Doing that isn’t necessarily a bad thing.

This is a security-oriented software project. We are in the realm of the technical – the domain of science and engineering. Whether something “sounds convincing” was never really a relevant criterion.

  • Unman is saying that something can be used as a honeypot when the method by which it is distributed is used to spy on the users who obtain it.

  • You are saying that something can still be a honeypot even if the method by which it is distributed is not used to spy on the users who obtain it.

  • You are both correct, because not all honeypots are the same. In some honeypots, the method of distribution is used for spying. In others, it is not.

  • Unman is saying “X is true.” You are saying, “No, Y is true!” But actually, X and Y are both true. They are just statements about different things, even though they sound similar on the surface. You think you are disagreeing with unman, but actually you are not.

Small correction: Descartes, not Kant.

To be clear, authenticating the developers’ PGP signatures doesn’t require the ability to read code. We have a guide here.

I’ll leave it up to @deeplow and others to decide whether a new forum section would be a good idea.

There are already quite a few open issues for things like this. Many of them will probably require community dev contributions.

As for guides, the type you’re describing would probably need to be community doc contributions.

That already exists. Simply click on the Nyx shortcut in sys-whonix’s menu.

1 Like

In that scenario, Qubes is unlikely to be the target’s weakest link anyway. The agency’s resources would likely be better spent on things like physical surveillance, obtaining surreptitious physical access to the target’s home, bribing/coercing associates, etc. than on trying to subvert a global software project with tens of thousands of (exceptionally paranoid) eyes on it undetected. Would an assassin rather attempt to subvert the supply chain at the automobile factory or instead sabotage the brakes on his target’s car?

2 Likes

It could be a backdoor similar to the dual elliptic curve deterministic random bit generator weakness, even with thousands of people looking at the code it could still take a really long time to discover the backdoor.

Yeah I don’t trust Qubes 100%. It doesn’t have to “be” a honeypot - if somebody high enough wants to they can fund 1 dude to join the project and sabotage it from the inside. Or they can assault the devs IRL and force them to push a malicious PR. Or (God forbid) snuff the poor guy out and take over his entire online persona, including his github or wherever they keep the sauces for this. “Hey guys it’s me Timmy your trusty Qubes OS maintainer” but it’s actually a talking piece of bacon.

With that said though, I consider my Qubes system my safest system other than one that’s fully airgapped and rigged to blow.

1 Like

The ken Thompson hack is interesting in that is turns clean source code into hacked binary thru the compiler. Not sure what that means but it sound elegant and very clever and it seems to have impressed the best of the best.
Using invisible unicode symbols as variables looks like it could be used in C++ as well but I dont feel like looking into it further.
But from what I am finding something being opensource does not inspire any confidence in me except for in extremely basic stuff. Once you get into thousands of lines of code written in multiple languages it appears to be impossible for even a small team of professionals to be 100% certain they didn’t miss anything.
Again I dont think Qubes is a honeypot. After looking into it it seems like it would be much easier for state actors just to slip a backdoor into some upstream code and save themselves the effort of running the website for years.
Either way I will continue to use Qubes as it is the best option and stick to my life long policy of not committing crimes or doing banking or sensitive stuff on the PC.

https://wiki.c2.com/?TheKenThompsonHack

http://underhanded-c.org/

https://blog.cloudflare.com/how-the-nsa-may-have-put-a-backdoor-in-rsas-cryptography-a-technical-primer/

Also TommyTran if you are waiting for Microsoft to admit to backdooring Windows you might be waiting for a while. I would suggest you research the term “plausible deniability”.
Microsoft also holds the authentication key for Windows and can put anything they want in Windows at any time. What better backdoor can you want more than being the one pushing closed source updates at will. I mean think bud. No backdoor LOLZ.
But you can read the Snowden leaks to find more examples or actual backdoors, for example handing the NSA preEncryption access to all of Outlook.com

This should get you started. Also its funny because I learned about qubes from one of the guys Snowden leaked too.

I have spent the last few days looking into it and am now confident to say that Qubes is almost certainly not a Honeypot.

Why am I so sure of it?
Because it does not need to be and nothing would be gained if it was that couldn’t be had for much less work, effort and money.

Why am I not absolutely positive it is not?
Because the US government prints money at will and is always looking for a project for no other reason than that you have to spend money to be able embezzle money and procure kickbacks.
Plus their children are always looking for a do nothing government job that pays in the hundreds of thousands of dollars and I can see being a honeypot forum admin as that type of gig.

Now I would consider the probability of that to be somewhere in the vicinity of a 0.00000000000000000000000000001% chance so please dont take that as me making a claim or take offense if you are a moderator. It is just within the realm of possibility as I see it.

My real belief is that the devs and mods are doing what they can and should be respected by all freedom loving individuals. I solute you and would lay down my life for you if I ever had the chance as you are some of the most high quality individuals that exist these days.

They appear to be the kind of people that would exchange a walk on part in a war for a lead roll in a cage and if we ever meet in the place where there is no darkness they are welcome to my rations and my blanket and bedroll.

I will continue to use Qubes because it is a great tool for 99.9% of the people that use it and I respect the effort and intentions of the devs and frankly there does not appear to be any better alternatives.

I will continue to learn and look forward to one day being able to build my own Qubes from source and have the knowledge to make it as secure as possible from government agents that want to spend a fortune in tax payer money to read my shopping list.

Also if anyone knows where I can get a good used oscilloscope that can output to a video recording device I am in the market lolz.
I guess I need eight of them, one for each wire in my Ethernet cable haha.

2 Likes

It’s not the topic of this thread but you accidentally touched a bit on my core competence (in-vehicle networking / ECUs). In your example of the assassin it might not be so clear, but let me slightly rephrase your question to make you think of the involved risks and scale:

Would an intelligence gatherer attempt to remotely compromise the software running in a telematic systems to gain on-demand access to the hands free (and other) microphones build-in or rather send a person to plant a microphone which could be discovered (the person and/or the microphone)?

I fully agree with your point about the ‘weakest link’, but couldn’t resist to digress a bit.

Also don’t forget that every microphone is a speaker and every speaker is a microphone.
If someone is clever enough and if the hardware is capable of outgoing and incoming signals or you can manipulate the busses and whatnot to a speaker someone could use a device that does not even have a “microphone” to listen in on you. Sure the quality would not be great but it would be perfectly fine for vocal clarity. For example those crappy speakers built into motherboards for warning tones and whatnot.

Enmus, with all due respect. I have been reading this forum daily since it was launched, however, today I had to make an account to respond to your comment.

Please reconsider to delete your post I’m replying to. You quoting “I’m just an idiot” & “but I am autistic” to formulate an [unsound] ‘argument’ on why OP should be disregarded, while in line with your post history & assumed cognitive abilities due to those, is very counter productive.

2 Likes

There are easier, non-technical solutions to technical problems, like that shown in this illustration :wink::

Password_get

8 Likes

Even the encryption is a joke against an adversary with the ability to farm out decryption to every windows machine on the planet or more than likely use all the bitcoin mining machines as a network of encryption cracking processor units.

No one, not even the US federal government, can simply turn the bitcoin mining machines into a network of encryption cracking processors. Bitcoin miners run ASICs—specialized computer chips that /only/ run the bitcoin mining algorithm. They aren’t general purpose computers and can’t be re-purposed for other tasks.

Thus the bitcoin mining network could never be used by an adversary to attack Qubes OS or to turn Qubes into some kind of honeypot.

A note from the mod team

This thread has caused a lot of spirited debate, and debate is always good. However the mod team would like to ask that people refrain from getting personal. This is against community guidelines and if this thread continues to move away from genuine debate about security into personal observations about other people, then we will have to take the sad choice to lock the thread

1 Like

The technical term for this process is “rubber hose cryptanalysis.” :smiley:

2 Likes

I think you are missing the point. I am not saying “lots of eyes, therefore no backdoor.” Rather, I am saying that it’s probably easier/cheaper for such an agency to sneak into one person’s house without being detected than it is to subvert a software project with many eyes on it without being detected. Does it follow that you can’t subvert a software project when there are many eyes on it? No, it does not. It just means that some things are easier/cheaper than others.

Nothing is 100% certain, secure, or trustworthy in life. Every time you take a drink or eat a bite of food, it could be poisoned. Every time you step out your door, a paid hitman could take you out. (In fact, you don’t even have to leave the house for that one.) The question was never whether Qubes is 100% of anything. The question is whether it’s better than the other alternatives available to you at the time. That’s the same sort of calculus you make with every decision in life.

Would require stealing secret keys, not just snuffing people out. That’s still very doable, of course. Just clarifying for the sake of accuracy.

Also, the code is all on GitHub, but that doesn’t mean GitHub is trusted. See:

Doesn’t matter. Code can either be open-source or closed-source. Pretty much everyone here would agree that closed-source is worse, as else being equal. It doesn’t matter how flawed or limited something is. If it’s better than the available alternatives, you will still prefer it.


Side thought directed at no one in particular:

It seems like many people seem to be seeking perfection in an imperfect world. Why? Has anything in your years of life experience thus far led you to believe that that’s a reasonable expectation? And why expect that from Qubes, in particular? Remember, the slogan is “a reasonably secure operating system,” not “a perfectly secure operating system.”


I completely agree with you, but that’s the primary difference between an assassin and an intelligence gatherer. The former’s job is to eliminate a specific target. The latter’s job is to gain relevant intel from everywhere. So, it makes perfect sense that their methods wouldn’t be suited to each other’s tasks.

1 Like

Sure, but you don’t have to be the primary target, honeypot could mean it’s a more opportunistic approach. X agency pays the developer to backdoor the system because they know it’s used by a large group of people of interest, and the average user ends up as collateral damage.