[tor-dev] CVE-2020-8516 Hidden Service deanonymization

[David Goulet]

On 04 Feb (19:03:38), juanjo wrote:

Greetings!

> Since no one is posting it here and talking about it, I will post it.
> 
> https://nvd.nist.gov/vuln/detail/CVE-2020-8516
> 
> The guy: http://www.hackerfactor.com/blog/index.php?/archives/868-Deanonymizing-Tor-Circuits.html
> 
> Is this real?
> 
> Are we actually not verifying if the IP of the Rend is a node in the Tor
> network?

We (network team) actually don't think this is a bug but it is actually done
on purpose for specific reasons. Please see asn's answer on
https://bugs.torproject.org/33129 that explains why that is.

Onto the bigger issue at ends that the post explains. I'm going to extract the
relevant quote that this post is all about:

    Remember: the guard rarely changes but the other two hops change often.
    If he can repeatedly map out my circuit's last node, then he can build a
    large exclusion list. If he can exclude everything else, then he can find
    my guard node. And if he can't exclude everything, then he can probably
    whittle it down to a handful of possible guard nodes.

That is indeed a known attack. One can create a set of relays from the 3rd
node (last one before connecting to the rendezvous point) selected by the
service and doing enough requests to the service, you can end up with a very
large set of relays that can _not_ be your Guard due to how path selection
works as explained in the blog post.

You probably won't end up with one single Guard but rather a small set of
relays that could be it. For instance, if the service has setup ExcludeNodes
then they will all be in your set.

And the reason for private nodes is probably because this way you eliminate
noise from other tor traffic so _anything_ connecting back to your ORPort is
related to the onion service connections you've done. You don't need to filter
out the circuits with some custom code (which is very easy to do anyway).

That is unfortunately a problem that onion service have. These types of guard
discovery attacks exists and they are the primary reasons why we came up with
Vanguards couple years ago:

https://blog.torproject.org/announcing-vanguards-add-onion-services

But one thing for sure, simply forcing rendezvous points to be part of the
consensus will _not_ fix this problem as it is fairly easy to pull this type
of attack by simply using a normal relay within the consensus.

Hope this help!
David

-- 
Bbbgg4u8CrNOEpbT98JqIsuQesh4Pr607DGrz6pE1F8=
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20200204/fd760730/attachment.sig>