"Cell Manipulation Attack Against Onion Services" (2023)

I haven’t read this in detail, and I don’t have the background to understand how important it may be, but I’m sharing this paper about a traffic confirmation attack against v3 onion services.

Cell Manipulation Attack Against Onion Services
Jianjun Lin, Yinliang Yue, Yijing Zhang, Xiaoyu Liu, XiaoDu Yang, Weilin Gai, Bo Sun
Cell_Manipulation_Attack_Against_Onion_Services.pdf.uuencode.txt (370.4 KB)

In this study, we proposed OREA-OS, a cell manipulation attack devised to compromise Onion Services. Through the manipulation of cells, two collaborating nodes within a circuit exchange information to unveil the anonymity of the targeted Onion Service. We conducted an analysis of existing de-anonymization scenarios and effectively addressed the associated challenges, thereby achieving successful de-anonymization of Onion Services. To assess the efficacy of our attacks, we conducted experiments on both private and public Tor networks. The experimental results validate the effectiveness of our approach, as we accomplished 100% accurate identification of the relationship between domain names and Internet Protocol addresses, with no false positives. Within our simulated private network, the recall rate neared 100%. On the public Tor network, the de-anonymization rate (98.6%) exceeded the successful download rate (98.2%). Furthermore, 99.2% of success attacks took less than 10 seconds to confirm.

A. Method Overview

The initial step for the attacker is to gather the domain names of the Onion Services that they intend to de-anonymize, while simultaneously introducing multiple malicious nodes into the network, in the hopes that the targeted Onion Services will select them. An Onion Service can be de-anonymized when it chooses a malicious node as the guard node and another malicious node as the IP/HSDir/RP concurrently. Although the middle node does not possess knowledge of the domain name itself, it possesses certain distinctive values (IPAKs/BSKs/RCs). We propose leveraging these unique values to ascertain the domain name. The attacker operates several malicious clients, continuously collecting metadata pertaining to the targeted Onion Services and constructing an inverse mapping from these unique values to the corresponding domain names.

The malicious guard node embed a signal by tampering with the command sequence of the outbound cells, while the malicious middle node functions as a decoder to extract signals from the command sequence of the outbound cells. Two malicious nodes can confirm that they belong to the same circuit by comparing the signals they embed and detected. The malicious middle node retrieves the domain name by querying the map with the received unique value, while the guard node knows the Internet Protocol address associated with the Onion Service. Consequently, the relationships between domain names and Internet Protocol addresses are revealed. The command sequence must be of sufficient length to accommodate the embedding of a signal, thereby necessitating that the attack induces the Onion Service to transmit an ample number of outbound cells.

1) Encoder Manipulation

Figure 4 provides an illustration of how the malicious node manipulates the command sequence when serving as the guard node. The red blocks represent RELAY_EARLY cells, while the green blocks represent RELAY cells. Our malicious guard node selectively marks the first 26 cells of the circuit to embed the signal. In cases where the HSLayer2Nodes and HSLayer3Nodes options are enabled for the Onion Service, the maximum circuit length that the Onion Service can establish is limited to 5. To ensure that Onion Services do not encounter circuit creation failures due to manipulation, the malicious guard nodes are prohibited from tampering with the first four RELAY_EARLY cells. The Command field of the fifth cell is modified to RELAY, while the sixth cell contains RELAY_EARLY. This abnormal command sequence (where RELAY_EARLY follows RELAY) serves as an indication to the cooperative node. The remaining 20 cells consist of 4 RELAY_EARLY cells and 16 RELAY cells.

The paper seems to be based on some earlier research:


As I read this I can see a lot of effort went into this. They demonstrate that onion service can be de-anonymized. Other than an academic purpose, does anyone know if this is actually being done in the real world; by whom and for what purpose. State actors? Rogue or not? What type of onion service; drugs, arms, human traffic, child porn, news information, Tor forum.

I can see from where these researchers work that they are well funded. Does this say it all?

You need to subscribe to read the articles mentioned.

I have read this paper and allow me to share my views.

“ Cell Manipulation Attack Against Onion Services”. This paper uses a protocol-level watermarking approach to achieve de-anonymisation of hidden services.

Tor protocol vulnerability: The relay and relayearly cells are interchangeable, as they are handled with exactly the same logic.

Paper Strengths:
(1) The feasibility of achieving de-anonymisation by attackers under different threat models is discussed. For example, an attacker controlling a client can embed watermark signals in the Client-IP-Guard-Onion service or Client-RP-Guard-Onion service circuit. Similarly, an attacker can embed signals in RP-Guard-Onion service, IP-Guard-Onion service, or HSDir-Guard-Onion service circuits.

(2) The watermarked signal is transmitted from the compromised guard to the colluding relay and it does not pass through the onion service. Therefore the method proposed in the paper is covert.

Paper Disadvantages:
(1) The paper concludes that only RP-Guard-Onion service, IP-Guard-Onion service, or HSDir-Guard-Onion service circuits are at risk of being exploited by an attacker. Unfortunately, controlling HSDir or IP nodes to achieve de-anonymisation requires overcoming the selection probability problem inherent to Tor, and it may be virtually impossible to implement either scheme in a real Tor network. (Note that Guard’s selection is also a small probability event.)

Is the method associated with IP-Guard-Onion service true? I checked Tor source code and found that sendme only exists in relay_data type cell. and figure 6 in the paper shows that sendme cell also exists in IP-Onion circuit, is figure 6 real? Or am I not understanding correctly?

The relay and relayearly vulnerabilities were published many years ago and were not the first discovered in this paper. Unfortunately, the Tor Project never fixed it.

By the way, the fix mentioned in the paper is to include the cell_command field in the integrity check. This solution is bad, because transit relays like RP and IP can’t avoid making changes to the cell_command field.