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

[Mike Perry <mikeperry@xxxxxxxxxxxxxx>]

On 2/4/20 3:15 PM, David Goulet wrote:
> 
> 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.

For completeness of understanding and to be thorough, there is an
interesting wrinkle in
http://www.hackerfactor.com/blog/index.php?/archives/868-Deanonymizing-Tor-Circuits.html
that might deserve some additional investigation.

Specifically: the "Forward in Reverse" subsection, which is covered in
more detail under "The Reverse Attack" here:
https://www.hackerfactor.com/blog/index.php?/archives/779-Behind-the-Tor-Attacks.html

The "Oddly, sometimes the connection would succeed" sentence is a red
flag sentence. If you are inclined to be paranoid, there is indeed a way
to hide a real attack in what looks like a simple ntohl() bug here.

This "sometimes" connection behavior is often seen in tagging attacks,
where the adversary abuses Tor's AES-CTR mode stream-cipher-style
properties to XOR a tag at one end of a circuit, and undo that tag only
if the other endpoint is present. In this way, only the connections that
actually succeed are those that the adversary is *certain* that they are
in both positions in the circuit (to perform Guard discovery, or if they
are the Guard relay, to confirm deanonymization).

If you want to hide your tagging attack as what looks like a simple
ntohl() bug here, you send your intro2 with the reverse IP address.
Then, when your middle node suspects a candidate rend cell (via timing +
circuit setup fingerprinting, to have a guess), it can confirm this
guess by undoing the tag by XORing the cipherstream with ntohl(ip) XOR ip.

Because of our stream-cipher-style use of AES-CTR, the busted rend cell
contains AES-CTR-cipherstream XOR ip. This means that when the adversary
XORs this position *again* with ip XOR ntohl(ip), they undo the tag:
  AES-CTR-cipherstream XOR ip XOR ip XOR ntohl(ip) =
  AES-CTR-cipherstream XOR ntohl(ip)

Aka a correctly performing rend cell tag hidden in what looks like a
very common networking bug.

This cipherstream tagging weakness has had a few proposals to fix, most
recently:
https://gitweb.torproject.org/torspec.git/tree/proposals/295-relay-crypto-with-adl.txt


BUT DON'T PANIC: There is also an alternate explanation for the
"sometimes succeed" red flag in this particular case, other than a
tagging attack.

Because Tor will actually use the rend relay fingerprint to try to find
an already-open connection before opening a new one, it is possible for
rends with a correct fingerprint to connect successfully, even if the IP
address is wrong, so long as a previous TLS connection to the correct IP
exists.

So most likely, this is just a poorly written Tor client, *but* there
still is the possibility that it is an attack cleverly disguised as a
poorly written Tor client.. :/


It may be a good idea for Neal's/our monitoring infrastructure to keep
an eye on this behavior too, for this reason, to test for the side
channel usage + rend XOR "correction" vs just dumb bug that is sometimes
connecting by getting lucky (and thus never properly reverses the rend
IP address). If this is indeed just a bug, when these rends do succeed,
the IP address should never be correct.

The way to do that would be to build rend circuits using 3rd hops that
you (the service operator) control, so that that 3rd hop can check if
the rend succeeds because the TLS connection happened to be open (benign
behavior) or because the reversed ntohl() got corrected somehow (attack).


Thank you for your vigilance, Neal!


-- 
Mike Perry

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev