Quick question please, need help!
ljul...@gmail.com
Jon deps
> So I’m still learning about Qubes but I have a question please. I was told that if dom0 gets infected, everything in the laptop can be found and read. The ip is not a problem but I’m not sure about the MAC address? If they found out the latter by infecting dom0, what are the possibilities to trace that MAC address to the laptop owner?
>
I would guess no different than any other operating system / probably
your question is not specific to Qubes or this forum
the selling point for Qubes seems to be tied to Xen Hypervisor being
"bare metal" vs. other efforts at virtualization safety, which I
hear even windows is using to some extent now
Sphere
If dom0 gets pwned then everything else can be pwned and stolen, including your data
pwning dom0 properly and successfully however, is not trivial because dom0 has no direct access to network hardware to communicate in the first place and malicious actors would need malware to communicate directly to the C2 server for commands.
What's great about qubes is the fact that with proper hardening, it becomes very resilient thanks to the fact that it follows a 0-trust model.
Jon deps
maybe the argument is are you "safer" using hypervisors , because
'qubes' isn't really an traditional OS of course
Steve Coleman
> I was told that if dom0 gets infected, everything in the laptop can be found and read.
what it would take for someone to do this given the Qubes logical
architecture and the physical hardware enforced memory separation that
Qubes is built upon. For an adversary to circumvent your dom0 you will
likely have needed to have helped them do so, by first doing something
to deliberately break your security model.
Note to self: Don't do stupid things in dom0.
Since dom0 has no networking, just to get into dom0, the adversary would
have to first breach the sys-net VM and then somehow circumvent or
leverage a flaw in the Xen hypervisor to establish a communications
channel into Dom0 to take control. That is exactly why Dom0 has no
networking nor any user applications, so its actually *hard* to do
stupid things. The attack surface of dom0 purposefully is kept to the
absolute bare minimum. For this reason I use a separate stripped down OS
template for sys-net, just to make this VM as a stepping stone, a little
more challenging for the adversary. Faux hacker tools, process
instrumentation, and lots of land mines.
Or, you yourself would have to introduce some APT agent (e.g. inserting
an infected USB device) into Dom0, so that this APT agent can later
reach back out to the adversary, as to establish a back-channel, and
permit their gain of control over the machine. You would have to
unwittingly be their accomplice in the crime that you yourself are
wanting to prevent.
Neither of the above circumventions are easy, and thus the only sure way
for an adversary to get into your system is for them to have personal
physical access to your hardware, an alternate bootable OS on a CD/USB,
along with the LVM encryption passwords. That is where Qubes AEM comes
in. I have had to breach my own systems on occasion, while I already
know the passwords, and I have found that it can still be a challenge to
take control over a Qubes system without leaving some kind of obvious
evidence behind.
Note to self: Don't over-harden your desktop system if you want to
actually get your work done.
> The ip is not a problem but I’m not sure about the MAC address? If they found out the latter by infecting dom0, what are the possibilities to trace that MAC address to the laptop owner?
>
this phrase in this news group or the Qubes site and find out how to do
it. Basically, each time you boot you can script up the modification of
the MAC address to another value, so that, statistically at least, you
are never using the same MAC address.
Since the majority of networks assign the actual IP address to you, you
likely won't have much control over that address, and logically the IP
address belongs to the network, not you. Chances are that with a
different MAC address you will not likely be getting the same IP address
each time either, depending of course on how they actually allocate
their addresses.
Sphere
1. Proper use of firewall rules using qvm-firewall
2. Reducing the attack surface by only installing what is needed. Refer to usage of debian-minimal and fedora-minimal template in Qubes documentation.
3. Drop INPUT and OUTPUT in sys-net(only do this if you have proper DNS resolving mechanisms in place that are not reliant on sys-net, Qubes is reliant on sys-net for proper DNS resolutions by default. If you're interested then you can start by knowing how to use DNSCrypt proxy made by jedisct1 or using Stubby to make a sys-dns qube to do DNS over TLS resolutions.
4. Implementing the use of a VPN in qubes or highly relying on sys-whonix to torify your connections.
5. Picking only update sources that you could trust. IDK about debian but in fedora, by default, all updates are grabbed from mirrors and alot of those only support http which is bloody insecure thanks to being just plaintext and susceptible to MITM attacks. This can be changed by modifying /etc/yum.repos.d/fedora.repo and fedora-updates.repo
If you're interested in doing this then you can search up a thread I made about this here in qubes-users. Just put "Sphere" in search and you will definitely find it among the threads I have made.
6. Frequently updating your qubes after making sure you picked a source of updates that you can really trust.
"Since the majority of networks assign the actual IP address to you, you
likely won't have much control over that address, and logically the IP
address belongs to the network, not you. Chances are that with a
different MAC address you will not likely be getting the same IP address
each time either, depending of course on how they actually allocate
their addresses. "
@steve.coleman: I would like to add that IP address allocation from the ISP to you entirely depends on whether they provisioned you a Modem or a Modem + Router combo.
For the case of a Modem, you will be allocated a random IP address from a pool of IP addresses the ISP provides on the subnet that you, as a client, was allocated to. Some ISPs do not provide it by random and in the case of statically assigning you an IP address, they use your modem's MAC address and bind it to a specific IP address which effectively becomes your public IP address. This is exactly why VPN is very essential for privacy because any internet activity that does not go through a VPN could effectively be traced back to you by your ISP.
Do note that there has been wide confusion that's still happening about Modems and Routers thanks to some devices actually being labelled Modems but in reality they are Modem + Router combos that has a DHCP server which provides you your private IP addresses (Private IP addresses are IP addresses you use to access devices within your local network).
Andrew David Wong
Hash: SHA512
On 02/07/2019 10.15 PM, Sphere wrote:
> [...]
> 5. Picking only update sources that you could trust. IDK about
> debian but in fedora, by default, all updates are grabbed from
> mirrors and alot of those only support http which is bloody
> insecure thanks to being just plaintext and susceptible to MITM
> attacks.
>
Fedora packages are digitally signed. dnf checks the signature by
default. If the signature is not valid, the package will not be
installed.
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAl0cPUIACgkQ203TvDlQ
MDAn3g//fuZSym+J6RDgO6/gNBL2P+73EAZ9lRaiFc66ozwF0+fQsRqrGQgZz1TB
M8QA7h1Tp71JPNnXGRzZHe0XvWNLazZmr3hBiZ3fSpZelEgHUAdROUY+zAJg1J+L
ub87MFpTqqUxn/d+jp52OXbFNP2jy7mY3/aMypuI0R+y9K8uaNhwUoSJGLSLb6+r
jHFn9LIrG4txqCoCcSGMSi4/tppt12/g6c4EpRNGKbf556Iaxtikv8ar0WbLc7ke
AQRaP4Rbm9rLksiKx8n4fhMnF8jhBJ/7Obn/sLMYRy7n/gFqoVTECeB5KMW2Syqe
EZHz954rItZRJPyiwpsa0TmZ018K0kN3CSgxPqXVqIQdK2aq9xhUqxUtE8zg3B7Q
7TW1Aqv81Gif1Y0UFfCUKxMoQzSWD7FfhVVr6reZL2pSHFQ/rt8JbgG2XkYSM/IO
UFf8+HUzxhmbiq68MA50zhJ7mPp9KTw3RaG19CviBxNrS5PgjYIBTbpykhE2/Qho
Sv5x46l640MUgBGhnQyVCJunlAAOOyCDe8JaHnfqYmenw8abTe3REWxUa+04Qt31
U+xtVV9/CmEW3qTw9qUFxytUSsy3Xkd5l8pbuqBHlUbuNDtbd95NZhc7wc7Xr7OE
ABtfT6WzwbdbsWdc/67/Ry8VdXkIQKPoczeNMgzadLIQ1Ww6+Mw=
=Gxzq
-----END PGP SIGNATURE-----
Sphere
Is downloading packages from plaintext http susceptible to MITM?
Even if that is not the case, I believe we can't be for sure that there's no exploitable vulnerability on dnf involving packages poisoned either from the source itself or in transit through plaintext http.
Andrew David Wong
Hash: SHA512
> I'm not particularly knowledgeable about the verification process
> being done by dnf on the signature of packages so the question
> still lies on me: Is downloading packages from plaintext http
> susceptible to MITM?
>
modifies it, then passes it along to you. When you receive it, dnf
(technically gpgv) will not be able to verify the signature (since the
package has been modified), so the package won't be installed. In this
sense, the MITM attempt will fail. Of course, there's no such thing as
perfect security, so an MITM is technically possible if the attacker
were find some way to defeat this system, e.g., obtain a copy of the
signing key or craft malicious input that exploits a vulnerability in
gpgv. (This is why signing keys are closely guarded and gpgv is
intentionally simpler and harder to exploit than gpg.)
> Even if that is not the case, I believe we can't be for sure that
> there's no exploitable vulnerability on dnf involving packages
> poisoned either from the source itself or in transit through
> plaintext http.
>
we haven't discovered yet. This is, in fact, a fundamental tenet of
the Qubes philosophy: All software has bugs, and we can't fix them
all. As we speak, bug software is being written around the world. Even
if we tried, we couldn't fix them quickly enough to keep up with the
rate at which they're being produced. Instead, we compartmentalize.
Separate things in their own boxes so that when bugs inevitably bite,
the damage is limited. For the software we can't compartmentalize,
keep it as minimal as possible.
In any case, it would better to have both signed packages _and_
transit via HTTPS. If I had to choose just one, I'd pick signed
packages, since it wouldn't be difficult for an attacker to serve
malicious packages over HTTPS. But, again, both would be better.
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
MDA2XhAAkvv5gxEvQa+D1hgN0eyFeptmNV2ze1NkZrd979ZOC2vnTGNKefRyzcQ+
obBwKOUv8w3czdxRlKx1JJ7gthJYyEukWYIv3mxqYG8ZLx8ZMIvQBU4G7445nrtY
S2FaeVrLH6useEUUhpWRQQxWQnLJfuQseEYaS+8i4db9KhslBEcVUlp4BkUVnjcA
oCfSSiSjUX6YUP0wcq44dZKQBlzf1V9QYR+K/y+r0B5qngrFF2QyAsUy5fXNQPvA
NKbq5tKOU2zOHsuNVSCxokHI1uZkS5pU/hdNxEDslSBM3SiL+numYnrREamgdg9q
w0SPCXptJagD/EI3U9jk2CmTYt8kMajiHgDttSqEvG32rp+z1IZwJ0Ku6DTgk7O1
ce3GqD3b1NERjM8VDVdDor0T+4rEnPPfznvEHHcOzdXzS93rU4wxiCjLy4nXK0Ah
FqXHAu64u3Z+CKw05WbprcL3xJ1DVULJtPOnrwiiZ88UV327OFZwRJUSS22DrPsC
kkvHkJ6kUuM9IFNyXLjrWQnTbFCl+KFhGXDWPS3px8dQwK+l/3idQL4gnxAa8Ygy
Dv7ttr9OGqfSLmuZco+nU5KqJ44hgvvpRS/Y/0amumpbsxKJizKn34nLXSQjODc/
CPqDZCQOskKIMaUyD71r81Vj+/iCj21iZLv9Gh4POK0WrHdZXVY=
=fWbd
-----END PGP SIGNATURE-----