Tor and netvm trace

[Alex Dubois]

Hi

Wouldn't the fact that netvm is not disposable add risk to tor users being tracked.

If a netvm is being compromised at time T

It could send at T+x beacon signal giving IP address (location), tor input node and tor tcp source port for a given laptop.

Alex

[Axon]

Alex Dubois:

> Hi
>
> Wouldn't the fact that netvm is not disposable add risk to tor users being tracked.
>

Wouldn't the attack still be possible intra-session with a disposable
netvm? Why the focus on disposability? (I also wonder what kinds of
netvm compromises would actually persist across netvm reboots, given
Qubes' TemplateVM structure.)

> If a netvm is being compromised at time T
>
> It could send at T+x beacon signal giving IP address (location), tor input node and tor tcp source port for a given laptop.
>

I thought part of the point of Tor is that your ISP can already get this
information. (What they can't determine is where your encrypted Tor
traffic goes on the second and third hops.) Have I misunderstood you?

> Alex
>

[Alex Dubois]

> On 4 Jan 2014, at 08:55, Axon <ax...@openmailbox.org> wrote:
>
> Alex Dubois:
>> Hi
>>
>> Wouldn't the fact that netvm is not disposable add risk to tor users being tracked.
>
> Wouldn't the attack still be possible intra-session with a disposable
> netvm? Why the focus on disposability?

Because an attack on the wifi driver imply proximity. You want this intrusion to disappear once you've moved on.

Ideally you would want this refresh to happen at regular interval if transparent.
Xen introduced microvm to allow just that to happen in few microseconds.

> (I also wonder what kinds of
> netvm compromises would actually persist across netvm reboots, given
> Qubes' TemplateVM structure.)

As of today, a netvm reboot is not sufficient to remove a penetration. This is what I am challenging. I see benefits in being able to boot netvm with /rw in write mode to set config, hook scripts, etc... But then set it read only so that attacks do not persist a reboot.

>
>> If a netvm is being compromised at time T
>>
>> It could send at T+x beacon signal giving IP address (location), tor input node and tor tcp source port for a given laptop.
>
> I thought part of the point of Tor is that your ISP can already get this
> information. (What they can't determine is where your encrypted Tor
> traffic goes on the second and third hops.) Have I misunderstood you?

Ah yes you are correct for tor.

Also for the rest, the original attacker may not have the power to track his target in any location, also if he owns the netvm, he gains this capability.
>
>> Alex
>

[Joanna Rutkowska]

Generally: a compromised netvm gives the attacker all the same as if the
attacker compromised the hotel or airport wifi, or controlled your ISP.

So, in all practical cases, the netvm compromise is *not* a problem,
because we should be *always* assuming the above is taking place
(untrusted wifi, ISP).

joanna.

[pow(n00b, 3)]

Actually there might be one more problem with netvm compromise: vpn credentials could be stolen if they are saved in netvm.

what would be the implications of moving the network tray applet from netvm to firewallvm?

[Joanna Rutkowska]

On 01/06/14 13:45, pow(n00b, 3) wrote:
> On Monday, January 6, 2014 12:19:30 PM UTC, Joanna Rutkowska wrote:
>>
>> On 01/04/14 10:17, Alex Dubois wrote:
>>>
>>>

>>>> On 4 Jan 2014, at 08:55, Axon <ax...@openmailbox.org <javascript:>>

One should not run VPN client in the netvm -- instead one should create
a vpnvm (of a proxyvm type) and run the VPN client there. Exactly to
prevent what you described. See e.g.:

http://theinvisiblethings.blogspot.com/2011/09/playing-with-qubes-networking-for-fun.html

j.

[pow(n00b, 3)]

There's no easy way to configure vpn in proxyvm though. and there is no visual indication whether the vpn is active or not :/

[Hakisho Nukama]

> --
> You received this message because you are subscribed to the Google Groups
> "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to qubes-users...@googlegroups.com.
> To post to this group, send email to qubes...@googlegroups.com.
> Visit this group at http://groups.google.com/group/qubes-users.
> For more options, visit https://groups.google.com/groups/opt_out.

You could enable network-manager in the service tab of your vpnvm.

[Alex Dubois]

Alex

I completely agree with that. I am raising the point that a compromised netvm is a beacon which may give your physical location after you have left the compromised hotel and a launch pad for the next xen vulnerability.

A disposable netVM would to the same level ss a normal disp VM mitigate some of that risk.

How much effort would it be to do a disp net VM?

Thanks
Alex

[Joanna Rutkowska]

In any other system than Qubes OS, a compromise of any of the networking
subsystem would be fatal already...

> A disposable netVM would to the same level ss a normal disp VM mitigate some of that risk.
>
> How much effort would it be to do a disp net VM?
>

A dispVM would not change anything here.

Besides, you can easily just restart your regular netvm and, thanks to
template fs sharing, you will get a clean, new root fs-based netvm. This
is the same as in case of a DispVM, except for your home dir survival,
which you need anyway because one needs to store all those WiFi config
and passwords somewhere.

joanna.

[7v5w7go9ub0o]

Franz, perhaps much of this thread is worthy of inclusion in the
"security practices" section?

I'd be happy to reformat as a paragraph, but ISTM it is more useful as a
dialogue for both addressing the specific TOR/netvm question, and also for
understanding a broader Qubes operational concept.

[Franz]

Security Guidelines are intended as a practical help to take immediate action to improve your security. The above seems more an exchange of ideas about the discussed opportunity to implement a disposable netvm. But AFAIK there is no practical action a reader can take. So is seems more suitable for the mailing list than the wiki.

Best

Franz

[Axon]

Alex Dubois:

But there are other ways to identify someone as a Qubes users which
doesn't entail the discovery of his/her physical location. For example,
an attacker who compromises an AnonVM can learn that it belongs to a
Qubes user without learning that user's physical location.

[Alex Dubois]

I think this is not correct if the user use a tor VM (Assuming the netvm is not compromized) as any outbound packet will go via tor and be anonymized.

 

[Alex Dubois]

It would however be nicer to have these loaded into a disp Net VM via qrexec from dom0. (But I understand it do be extra work and that you would prefer a patch)

Because if my netVM is compromised, I will have a difficult job to make sure /rw is not used to bootstrap a small rootkit.

 

joanna.

[Axon]

Alex Dubois:

>
> On Tuesday, 7 January 2014 03:52:54 UTC, Axon wrote:
>> But there are other ways to identify someone as a Qubes users which
>> doesn't entail the discovery of his/her physical location. For example,
>> an attacker who compromises an AnonVM can learn that it belongs to a
>> Qubes user without learning that user's physical location.

>> I think this is not correct if the user use a tor VM (Assuming the netvm
> is not compromized) as any outbound packet will go via tor and be
> anonymized.

The packets will go through the torvm, but those packets can contain
information which indicates that they're coming from a Qubes AppVM. This
was in the previous thread about the TorVM itself. IIRC, things like the
internal IP address, possibly machine description attributes, etc.
Things that would identify you as *a* Qubes user. This would diminish
but not destroy anonymity.

[Joanna Rutkowska]

Thank god there are more than 3 Qubes users world-wide these days :)

joanna.

[Axon]

Joanna Rutkowska:

Actually, I was wondering how many there are for this very reason. I
suppose there's no way to really know, but would you care to guess at a
ballpark estimate?

[pow(n00b, 3)]

These same things may also be used to fingerprint unique Qubes users too. For example, screen size, IP, MAC, browser/kernel version, installed packages etc. I am against using a TorVM until Qubes has a standard a standalone/template VM just for Tor, like Whonix

[Joanna Rutkowska]

You probably mean: standardized AppVM for anonymous browsing, not TorVM,
right? Note that TroVM is just a proxy, and user apps, such as a Web
browser, do not run there.

j.

[Joanna Rutkowska]

And probably we can just run Whonix VM as an HVM. Although if we wanted
to more closely integrate it with Qubes, there would always be some
footprint, such as e.g. Qubes agents running in the VM (detectable if
the AppVM gets compromised during browsing). I think it would be easy to
determine it is a VM running under Qubes, even if it was a pure HVM
without any Qubes tools installed inside (again, assuming the VM gets
compromised).

But then again, thank god there are more than 3 people who use 1600x900
resolution ;)

joanna.

[pow(n00b, 3)]

Yes, I meant standardized AppVM. sorry ^^

[Axon]

pow(n00b, 3):

> On Tuesday, January 7, 2014 4:20:57 PM UTC, Axon wrote:
>>
>> Alex Dubois:
>>>
>>> On Tuesday, 7 January 2014 03:52:54 UTC, Axon wrote:
>>>> But there are other ways to identify someone as a Qubes users which
>>>> doesn't entail the discovery of his/her physical location. For example,
>>>> an attacker who compromises an AnonVM can learn that it belongs to a
>>>> Qubes user without learning that user's physical location.
>>
>>>> I think this is not correct if the user use a tor VM (Assuming the
>> netvm
>>> is not compromized) as any outbound packet will go via tor and be
>>> anonymized.
>>
>> The packets will go through the torvm, but those packets can contain
>> information which indicates that they're coming from a Qubes AppVM. This
>> was in the previous thread about the TorVM itself. IIRC, things like the
>> internal IP address, possibly machine description attributes, etc.
>> Things that would identify you as *a* Qubes user. This would diminish
>> but not destroy anonymity.
>>
>>
>>
> These same things may also be used to fingerprint unique Qubes users too.

Some (not all) of them *can* be, if you don't take appropriate
precautions, but the appropriate precautions are not difficult to take
(see below).

> For example, screen size, IP, MAC, browser/kernel version, installed
> packages etc.

Screen resolution: Sure, this could be used for fingerprinting, but it's
rarely unique.

Internal IP: IIRC, this is assigned automatically by Qubes, so I don't
see how this would allow an attacker to fingerprint a *unique* Qubes
user. (Care to explain?)

External IP: The attacker can't learn this by compromising *only* the
AnonVM. That's the point of having a transparent Tor ProxyVM (aka TorVM).

MAC: Again, protecting this is the point of the TorVM.

Browser version: This is easily solved by using Tor Browser in your
AnonVM(s), which you should certainly do if you care about this.

Kernel version: Definitely not unique, right?

Installed packages: This is easily solved by having a dedicated
TemplateVM(s) for your AnonVM(s), which you should certainly do if you
care about this.

> I am against using a TorVM until Qubes has a standard a
> standalone/template VM just for Tor, like Whonix

For the reasons I gave above, I don't think any of the things you
mentioned are good reasons to refrain from using a TorVM right now,
unless you have some pretty unusual anonymity requirements. You can set
up an appropriate AnonVM yourself right now with little effort by
following the guidelines above and in the TorVM documentation.[1]

[1]http://wiki.qubes-os.org/trac/wiki/UserDoc/TorVM

[pow(n00b, 3)]

Every little bit of non-standard info contribute to the entropy of the fringerprint.
 

Internal IP: IIRC, this is assigned automatically by Qubes, so I don't
see how this would allow an attacker to fingerprint a *unique* Qubes
user. (Care to explain?)

I thought MAC and IP addresses of AppVMs are assigned at creation and remained static. As long as all Qubes users end up with the same MAC and IP when they create their TBB AppVM we are OK.
 

External IP: The attacker can't learn this by compromising *only* the
AnonVM. That's the point of having a transparent Tor ProxyVM (aka TorVM).

MAC: Again, protecting this is the point of the TorVM.

Browser version: This is easily solved by using Tor Browser in your
AnonVM(s), which you should certainly do if you care about this.

Kernel version: Definitely not unique, right?

Installed packages: This is easily solved by having a dedicated
TemplateVM(s) for your AnonVM(s), which you should certainly do if you
care about this.

If TBB in the AppVM gets compromised then all above can be used to fingerprint the individual user. TorVM can only hide the external IP (depending on the capabilities of the adversary ofc), but fingerprints can be correlated with the other nyms of the user.
 

[Axon]

pow(n00b, 3):

No, of course not, because Qubes has no way of knowing that you're
making a "TBB AppVM." But I still don't see your point. If we're
assuming that this AppVM gets compromised by an attacker, then what does
the attacker gain by seeing that the AppVM has some Qubes internal IP
which was automatically assigned at creation, besides the fact that the
AppVM belongs to *a* Qubes user?

>
>> External IP: The attacker can't learn this by compromising *only* the
>> AnonVM. That's the point of having a transparent Tor ProxyVM (aka TorVM).
>>
>> MAC: Again, protecting this is the point of the TorVM.
>>
>> Browser version: This is easily solved by using Tor Browser in your
>> AnonVM(s), which you should certainly do if you care about this.
>>
>> Kernel version: Definitely not unique, right?
>>
>> Installed packages: This is easily solved by having a dedicated
>> TemplateVM(s) for your AnonVM(s), which you should certainly do if you
>> care about this.
>>
>>
> If TBB in the AppVM gets compromised then all above can be used to
> fingerprint the individual user. TorVM can only hide the external IP
> (depending on the capabilities of the adversary ofc), but fingerprints can
> be correlated with the other nyms of the user.
>

It sounds like you're confusing two distinct things (TBB in the AppVM
getting compromised; the AppVM itself getting compromised).

Also: "All of the above can be used to fingerprint the individual user"?
Can you provide some proof for that claim? Or at least some evidence? It
sounds like you're just repeating your earlier claim, ignoring my
response about each of those things.

[pow(n00b, 3)]

User runs AppVM and does some browsing assuming pseudonym NYM1, and shuts down VM. Later on, starts AppVM again, and does something else using NYM2. NYM1 == NYM2 to the attacker because user has a unique fingerprint.
 

>
>> External IP: The attacker can't learn this by compromising *only* the
>> AnonVM. That's the point of having a transparent Tor ProxyVM (aka TorVM).
>>
>> MAC: Again, protecting this is the point of the TorVM.
>>
>> Browser version: This is easily solved by using Tor Browser in your
>> AnonVM(s), which you should certainly do if you care about this.
>>
>> Kernel version: Definitely not unique, right?
>>
>> Installed packages: This is easily solved by having a dedicated
>> TemplateVM(s) for your AnonVM(s), which you should certainly do if you
>> care about this.
>>
>>
> If TBB in the AppVM gets compromised then all above can be used to
> fingerprint the individual user. TorVM can only hide the external IP
> (depending on the capabilities of the adversary ofc), but fingerprints can
> be correlated with the other nyms of the user.
>  

It sounds like you're confusing two distinct things (TBB in the AppVM
getting compromised; the AppVM itself getting compromised).

Both TBB and AppVM can be compromised.
 

Also: "All of the above can be used to fingerprint the individual user"?
Can you provide some proof for that claim? Or at least some evidence? It
sounds like you're just repeating your earlier claim, ignoring my
response about each of those things.

google Freedom Hosting takeover, FOXACID, QUANTUMCOOKIE, QUANTUMINSERT EGOTISTICALGIRAFFE, TURMOIL etc
 

[Axon]

The user should not be using the same AppVM for two different
pseudonyms. The user should instead create a separate AppVM for each
pseudonym. An attacker who already owns the AppVM can use more direct
methods (e.g., keylogger, screenshots) in order to learn that NYM1 ==
NYM 2 than relying on fingerprinting.

>>>> External IP: The attacker can't learn this by compromising *only* the
>>>> AnonVM. That's the point of having a transparent Tor ProxyVM (aka
>> TorVM).
>>>>
>>>> MAC: Again, protecting this is the point of the TorVM.
>>>>
>>>> Browser version: This is easily solved by using Tor Browser in your
>>>> AnonVM(s), which you should certainly do if you care about this.
>>>>
>>>> Kernel version: Definitely not unique, right?
>>>>
>>>> Installed packages: This is easily solved by having a dedicated
>>>> TemplateVM(s) for your AnonVM(s), which you should certainly do if you
>>>> care about this.
>>>>
>>>>
>>> If TBB in the AppVM gets compromised then all above can be used to
>>> fingerprint the individual user. TorVM can only hide the external IP
>>> (depending on the capabilities of the adversary ofc), but fingerprints
>> can
>>> be correlated with the other nyms of the user.
>>>
>>
>> It sounds like you're confusing two distinct things (TBB in the AppVM
>> getting compromised; the AppVM itself getting compromised).
>>
>>
> Both TBB and AppVM can be compromised.

Yes, that's exactly my point.

>> Also: "All of the above can be used to fingerprint the individual user"?
>> Can you provide some proof for that claim? Or at least some evidence? It
>> sounds like you're just repeating your earlier claim, ignoring my
>> response about each of those things.
>>
>>
> google Freedom Hosting takeover, FOXACID, QUANTUMCOOKIE, QUANTUMINSERT
> EGOTISTICALGIRAFFE, TURMOIL etc

I already have. You still haven't explained how, for example, an
attacker can learn your NIC MAC address by compromising only the AnonVM,
or how an attacker can use data about installed packages to fingerprint
a user who utilizes a dedicated TemplateVM for a particular pseudonym.

[pow(n00b, 3)]

Ah, I think there's a confusion here. I've never claimed the MAC of physical NIC can be learnt by TBB AppVM compromise. I just said AppVMs are assigned random MACs on creation and that MAC can be used to uniquely identify a user using by correlating nyms.

Also I don't see a problem if all Qubes users use the same private.img, which is published and maintained on Qubes repo as a whole image, and a DispAnonVM and never update their TemplateVM nor customize the DispAnonVM. Even file timestamps in private.img can be a giveaway if users install updates at different times, or customize their TemplateVM.

Last time I checked Qubes R2B3 had an option to select a kernel version so I'm just assuming that not all AnonTemplateVM private.imgs are identical, given that they are custumizable and updateable at the users will.

[Axon]

Yes, you did. You said, "If TBB in the AppVM gets compromised then all
above can be used to fingerprint the individual user," and in the "all
above" list was: "MAC: Again, protecting this is the point of the
TorVM." This can refer only to the NIC MAC, since that's the only "MAC"
which the TorVM purports to protect.

> I just said AppVMs are
> assigned random MACs on creation and that MAC can be used to uniquely
> identify a user using by correlating nyms.
>
> Also I don't see a problem if all Qubes users use the same private.img,
> which is published and maintained on Qubes repo as a whole image, and a
> DispAnonVM and never update their TemplateVM nor customize the DispAnonVM.

Set aside the issue of updating for a moment: Why can't the default
TemplateVM serve this purpose?

Back to the updating issue: Not updating seems like a risk in itself,
since it means not getting any security-related updates. But, I suppose
if non-fingerprintability is a greater concern than getting security
updates, then one could simply not update or customize the default
TemplateVM (or a copy of it).

[pow(n00b, 3)]

Please go back a few post and find my comment about AppVM compromise. I've never said anything about NIC MAC.
Also Marek has commented here: https://groups.google.com/d/msg/qubes-users/NYzDPDFx9rI/0P7qJbTQK1AJ

If what Marek said is still valid, then an AppVM has static MAC and IP during its lifetime whereas all Whonix Workstations have the same MAC and IP addresses.

[Axon]

It is you who needs to go back and reread this thread. I don't know how
to explain it any more clearly than I already have, so if you still
don't get it, then I give up.

> Also Marek has commented here:
> https://groups.google.com/d/msg/qubes-users/NYzDPDFx9rI/0P7qJbTQK1AJ
>
> If what Marek said is still valid, then an AppVM has static MAC and IP
> during its lifetime whereas all Whonix Workstations have the same MAC and
> IP addresses.

Again, reread this thread. (Hint: It doesn't matter, because you
shouldn't be using the same AppVM for different pseudonyms anyway.)

[Alex Dubois]

Alex

Tor prevent mapping of client to real IP.

Qubes isolate clients but does not focus on no commonality between clients to prevent mapping.

Qubes could protect better real IP. User could take additional steps if it is a risk for him on his netVM

Just to close on why I initially opened this thread...