Shaping attacks in low latency networks or why Tor does not save from special services



    Timing attacks are a well-known weak point of the Tor network and have been repeatedly discussed, including on Habré, where you can find about 10 articles, one way or another touching on this topic. Why do you need another one? There is a fairly common misconception that such attacks always require statistical analysis and are quite difficult to implement. Previously published articles relate specifically to this class of attacks. We will consider a quite realistic scenario in which a single request is enough to deanonymize a network user.

    Since the question of the possibility of deanonymizing Tor users is once again actively discussed in RuNet, I publish a “printed” version of a fragment of my presentation with PHDays 2014. The attack below is not specific to Tor and can be used against any low latency means of hiding the traffic source - VPN, chains proxies and even combinations thereof.

    We will consider a scenario for which implementation in Tor requires the following two conditions:
    1. Be able to interfere with traffic between the exit node and the destination node. This can be done with access to the destination server, exit node, or any point where traffic flows between them. That is, in fact, anyone can fulfill this condition by organizing their own exit node in sufficient quantities.
    2. Have passive access to traffic between the network client and entry node.

    And what about the special services? SORM equipment installed at any Russian provider is usually completely passive, and can detect, log and interpret (for example, restore correspondence in instant messengers) traffic that has the specified characteristics. It is practically impossible to track the presence of this equipment “from the outside”, since it does not generate any own traffic and does not affect the listener in any way.

    The attacker's access to SORM equipment fully satisfies the second of the attack conditions. This means that special services that have access to equipment and are able to organize a certain number of exit nodes in Tor have everything that is required, including a desire to deal with this issue.

    Attack principle

    From the exit node side, predefined changes are made to the traffic, not changing the transmitted data, but affecting the "form" of the traffic - the sizes of the passing packets and the delays between them change. Time characteristics in low latency networks do not change significantly, this fact is usually used in timing attacks. Packet sizes vary in a predictable way, as will be demonstrated. This means that repartitioning the traffic into packets of a certain sequence of sizes with a certain sequence of delays, it is possible to mark the traffic on the exit node side in such a way that on the entry node side this marking can be detected, thus a connection or request to the server with the Tor user can be associated.

    Moreover, in this traffic it is possible to transmit information for the listening party, for example, a unique identifier for a client request. That is, if there are 2 distinguishable options for packet size and 2 distinguishable options for time delays, you can secretly from the user pass 2 bits of information to each party listening to the encrypted traffic between the user and the entry node, starting from the second. In fact, more distinguishable states can be introduced, but there are additional restrictions, which we will consider below.

    How difficult is this being realized and how does it look in practice?

    I implemented an attack by redirecting exit node traffic to a proxy server, into which minor changes were made to organize traffic shaping according to a predefined template.

    What does “regular” traffic look like in Tor? This is a fragment of the traffic from the entry node to the client associated with the transmission of the results of the HTTP request without any markings being added to the traffic:



    There is TLS traffic, inside which there are blobs (packets) of information, mainly 3648 octets in size. The blob size is determined by the number of tor traffic cells that have a fixed size. At the TCP level, blobs are broken down into IP packets that are primarily 1414 octets in size, which is associated with the Path MTU. A TCP packet can contain both a fragment of one blob and the end of one blob and the beginning of the next. However, there are 560 octet blobs and smaller TCP packets. The splitting of the source data into blobs and the splitting of blobs into TCP packets depends on various parameters - server timings, the size of the buffer with which it transmits data, and network delays. When you re-query, the picture may be slightly different. However, statistically the same request to the same server will have a fairly clear picture. Since when loading the same web page a fairly large number of requests occur, with the transmission, as a rule, of the same requests and responses, that is, typical volumes of information with typical delays, by matching the data, you can try to find which resource the user is accessing especially if he visits him regularly. Classic timing attacks are based on this.

    But we are going the other way. Instead of passive timing measurement, we add shaping marking (maRk) to the source traffic from the exit node. The clean, unencrypted traffic that was passed by Tor now looks like this:



    How does the labeling work? We transfer small packets of two different sizes. The difference in sizes of several hundred bytes in this case does not affect anything, but allows you to visually distinguish between two different types of packets in the series. The delays between the two types of packets are 60 and 110 milliseconds, they are selected so as to show the most interesting picture on the output.

    When the same traffic passes through Tor, between the entry node and the user it looks like this:



    What do we see now. All blobs in TLS now have a size of 560 octets (which means we can manage the size of 3648 or 560 octets by sending large or small portions of traffic). By the way, in this place there is a problem of traffic amplification - the minimum data packet increases by more than 10 times. Each package we send comes as a separate blob in TLS. Moreover, the 1414-octet IP packet contains two full blobs and the beginning of the third, the 389-octet packet — the end of the third blob and the 619-octet packet — a separate fourth blob. That is, 4 IP packets of the source traffic come in 3 IP packets in the Tor traffic. Is this good or bad? Bad, since we lost some of the timing information.

    What happened and why such a strange sequence: it is caused by the peculiarities of the TCP stack, namely the joint operation of the Nagle algorithm and TCP delayed acknowledgements. However, between groups of packages and between packages in the group, the interval remains unchanged, that is, at least half of the information on the timings we receive. To “overcome” the waiting and grouping in the Nagle algorithm, you can send the amount of traffic so that the transmitted blobs exceed the MTU size (but not enough to form a “large” blob of 3648 bytes).

    If we compare the third picture with the first, then it is clear that a fairly clear and easily detectable anomaly is introduced into the traffic, which allows the tracking equipment to “work” when it is detected. Moreover, in the case of SORM, the detectability of this anomaly is sufficient for the evidence base.

    This attack can be applied to almost any encrypted or unencrypted connection, both in the direction from the server to the client, and in the opposite.

    What are the limitations?

    The “non-linear" behavior of traffic due to the Nagl algorithm can lead to the loss of part of the timing information, however, this loss can be detected on the receiving side and compensated by the redundancy of the transmitted information. In order for traffic to be shapable, it must be sufficient. It would seem difficult to mark in this way, for example, an ssh connection with a running bash and periodically issued commands, since it does not transmit enough data to form packets with the necessary maRk signatures.

    In fact, you can even mark a connection in which data was not transmitted at all. The fact is that even after the client application initiated the closure of the TCP connection, the data sent through Tor to the client side will continue to be delivered. This makes it possible, after receiving FIN + ACK in the connection from the client side, to send a marked portion of random data to it. This data will never be read by the client application, but it will still reach the client and thus reveal it. That is, the attack can be carried out completely secretively from the client, and the amount of information with which the connection can be marked is more than sufficient. A similar method can be applied in most VPNs, but, fortunately, it will not work with proxies and other application gateways.

    Is there a reliable solution?

    An attack can be more difficult to carry out when the client is actively working, since it is necessary to detect packets belonging to the same chain, extraneous traffic is noisy for the signature. You can also take on the relay role in the Tor network, which makes it difficult to detect tagged traffic. There are several ways to further complicate the attack: a combination of Tor, VPN and a proxy chain makes it difficult to guess the final form of traffic and partially eliminates the attack through a half-closed connection. You can complicate the detection by ruining the known signatures with non-standard parameters of the TCP stack. But there is no reliable way to completely eliminate such threats within Tor or widespread VPN networks. Shaping attacks, as a form of timing attacks, are outside their defense profile.

    The only reliable solution is to use a virtual link inside the encrypted connection, in which there is a constant stream of cells of a fixed length with a fixed bandwidth. This is how ATM networks (Asynchronous Transfer Mode) work, for example. Moreover, encryption should be carried out without data compression, that is, the consumed bandwidth should be unchanged. Such technologies cannot yet be widely used for everyday work, since the additional costs for the channel, which is actively used even at the time of downtime, are too high.

    Also popular now: