Analysis of an attack on an I2P user

legalizer.cc

8 min

View Original

The history of the I2P network dates back to 2003, in connection with which it has acquired rumors, conjectures and articles about vulnerabilities, some of which are no longer relevant. Before starting the main story, let's outline the solved problems, the mention of which you can still meet. Don't let them bother you.

Common misconceptions

Story number one: I2P does not scale well, and with a large increase in nodes, the network will be paralyzed, because reference nodes - floodfils - will not cope with the flow of information. Say I2P works only until it is popular, but if the total load grows, the network will fall. F - floodfills
In fact, the number of floodfills grows with the network, and to access a certain hidden service, all floodfills are not required at all. Each hidden service publishes its full address (called a lisset) on the two floodfiles closest to the DHT. In turn, the DHT coordinates change almost randomly every day.
Upon receipt of a published lisset, each of the two floodfils duplicates the information to the other three floodfils that are the closest in a logical sense. In total, the lisset is published on at least four practically random routers, which are accessed when searching for the address of a particular site or other hidden resource. In short: the network is distributed and the resources for processing lissets grow along with the total number of nodes. Since the beginning of the I2P scalability tale, the network has grown exponentially and is still functional without any hint of floodfill overload. It is also worth adding that a transition to a new encryption is underway, designed to reduce the load on floodfiles.
Story number two: The router hosting a particular hidden service can be identified by the router's encryption key in the hidden resource's lisset. The model is based on the fact that the onion encryption used in tunnels is not sufficient, and first of all end-to-end encryption is applied to the message with the router's key, which must decrypt the message and transmit it to the local endpoint. It is assumed that the hidden services have unique keys, and the router has only one, and, having the identifier of this key, you can track other user tunnels. In fact, this threat was eliminated in the early stages of I2P development. A modern lisset contains an encryption key that has nothing to do with the router. Each hidden service uses a unique key,
Story number three: I2P tunnels can be intercepted. Interception does not mean decrypting traffic, but identifying the owner of the tunnel. The attack requires the maximum possible number of routers with good uptime for their constant participation in transit tunnels. The essence of the attack is to wait for the moment when the victim's tunnel will mostly (or entirely) consist of malicious routers. Transit nodes do not know anything about the total number of routers in the chain, but the default tunnel length is three hops. If we assume that three routers controlled by an attacker communicate with each other within the same tunnel, he can most likely assume that the end link of the known chain is the owner of the tunnel. In case of interception of the user's outgoing tunnel, an attacker can find out where the user is accessing, if, by unreal luck, at this moment he knows a lisset containing the data of the input tunnel of a hidden resource, which will coincide with those where the information is being transmitted right now. In fact, this attack is practically not feasible at the moment, when the number of nodes in the network is many tens of thousands. In any case of tunnel hijacking, it is impossible to say with complete certainty that the node assumed to be the owner of the tunnel is not just another transit router. Also, such an attack cannot be called targeted, but rather random, unpredictable and very costly. The chance of any successful execution always remains negligible. where the information is being sent right now. In fact, this attack is practically not feasible at the moment, when the number of nodes in the network is many tens of thousands. In any case of tunnel hijacking, it is impossible to say with complete certainty that the node assumed to be the owner of the tunnel is not just another transit router. Also, such an attack cannot be called targeted, but rather random, unpredictable and very costly. The chance of any successful execution always remains negligible. where the information is being sent right now. In fact, this attack is practically not feasible at the moment, when the number of nodes in the network is many tens of thousands. In any case of tunnel hijacking, it is impossible to say with complete certainty that the node assumed to be the owner of the tunnel is not just another transit router. Also, such an attack cannot be called targeted, but rather random, unpredictable and very costly. The chance of any successful execution always remains negligible. is not just another transit router. Also, such an attack cannot be called targeted, but rather random, unpredictable and very costly. The chance of any successful execution always remains negligible. is not just another transit router. Also, such an attack cannot be called targeted, but rather random, unpredictable and very costly. The chance of any successful execution always remains negligible.
Reseed

The easiest way to deal with I2P is to block the reseed servers, one of which is accessed for the initial network pattern when the router is first started. Resid is an archive with a number of routerInfo files, in fact - a package with information about random routers through which the first user tunnels are built and automatic expansion of the local network base begins. All reseed servers are run by enthusiasts, and the reseed addresses themselves are publicly available. They are accessed by domain names and known IP addresses, so collecting everything in a list and blocking it centrally is not a difficult task. However, making it difficult for the first launch does not mean blocking the operation of the I2P network! In case of blocking, the use of a proxy is supported when accessing the resource, which easily allows you to bypass the restrictions of the local provider. In addition, any router can be launched with an existing network base, for example, taken from another I2P router. A new step in the fight against possible blocking is the use of additional encrypted communication channels. Currently, such a tool is the Yggdrasil Network, which serves not only to access resid, but also to fully use the I2P network. To an outside observer, Yggdrasil activity is comparable to connecting through a VPN. At the time of the publication of the article, I2P work through Yggdrsail and proxies are implemented only in i2pd, which is an additional argument against the outdated Java router. The second scenario of manipulations with reseed is an attempt to intercept the archive with routers on the way to the user in order to damage or replace it. This is protected by the HTTPS protocol, as well as a cryptographic signature. Certificates of holders of reside servers, i.e. their cryptographic credentials are distributed with the I2P router. After receiving the start package, the router verifies its signature. If the signature matches the certificate, you can be sure that the recid has not been tampered with. Holders of receivers - ordinary users, enthusiasts. They do not pass any verification and most often remain incognito. The relevance of reside servers is regularly checked by the community and, in case of a malfunction, the server is removed from the list in the next release of the I2P router. After receiving the start package, the router verifies its signature. If the signature matches the certificate, you can be sure that the recid has not been tampered with. Holders of receivers - ordinary users, enthusiasts. They do not pass any verification and most often remain incognito. The relevance of reside servers is regularly checked by the community and, in case of a malfunction, the server is removed from the list in the next release of the I2P router. After receiving the start package, the router verifies its signature. If the signature matches the certificate, you can be sure that the recid has not been tampered with. Holders of receivers - ordinary users, enthusiasts. They do not pass any verification and most often remain incognito. The relevance of reside servers is regularly checked by the community and, in case of a malfunction, the server is removed from the list in the next release of the I2P router.
Sibyl Attack and Eclipse

The Sybil attack and the Eclipse attack have a similar implementation. Their meaning is to flood the network with nodes controlled by the attacker, which will work for one purpose: to keep the user in the sandbox. Isolation routers do not report information about ordinary nodes so that the user does not get out of the blockade. This allows you to monitor the list of resources that the attacked user places on his router, as well as the list of those that he visits. To get information about the entrance tunnels of a hidden resource, you need to get its lisset from the nearest floodfill, as well as publish your resource lisset so that it can be found. In case of a successful attack, all user tunnels consist of nodes controlled by the attacker, as well as available floodfiles. The main difference between Sibyl Attack and Eclipse is that that the Sibyl model is not directed at a previously known user, and the Eclipse, on the contrary, implies the isolation of an initially known target. In any case, these attack models imply the use of modified I2P routers and high literacy of the attacker. Moving away from the generalized theory, we will analyze the possibility of implementing these threats.
Attack Eclipse in practice can be considered unrealizable. This is due to the system of resids, which are protected from interception. In the case when the router makes the first start with the copied network base, i.e. in fact, with a starter package not from a well-known host, but from another I2P router, we will assume that the source is a priori reliable. It is logical to conclude that a starter package from an untrusted source should not be used. Assuming that an attacker acts as an enthusiast and hosts a well-known reseed server, it should be especially noted that the I2P router uses several independent reseeders, one of which is randomly selected. This makes the probability of a targeted attack extremely small, which makes it pointless to try to implement it.
The Sibyl attack, which aims to monitor the network in general, seems more appropriate for the malicious reseeding model just described. But upon closer examination, it turns out that the profit of a fake resid will not pay off the funds spent on its organization. Firstly, it is necessary to have large capacities in order to introduce the maximum possible number of controlled nodes into the network. Secondly, it is necessary to develop software that will flexibly combine information collected from controlled nodes into one database. Thirdly, an attack aimed at analysis implies a long duration, which will not work, because malicious resid will be revealed by the community soon. The most obvious sign of such an attack is a non-increasing, or too low, number of known routers that is displayed in the web console. In a paranoid case, you should delete the entire local database of the router, which is stored in the netDb folder and restart the router, which will provoke a new call to a random reseed. If you have enough reason to believe that some reseed has been compromised, be sure to report it to the developer community. At the time of publication of the article, no attempts of such an attack had been registered.
Java router destination attack

The last attack model is very complex, but critically dangerous in case of successful execution. The problem was published by the lead developer I2Pd and is not in the C ++ router, but it has not been fixed in the Java router for a long time. The model allows you to determine the fact that two or more endpoints are located on the same router, i.e. actually determine that multiple anonymous entities are physically located on the same computer. The possibility of an attack lies in the fact that all lissets in the Java router are stored in one place. As part of the attack, a full-fledged call is made to some endpoint (in English terminology - destination), which responds and saves the attacker's lisset. Then another endpoint is called, but the lisset for the response is not reported, and logically there should not be a response. If the answer comes the attacker concludes with certainty that the responding endpoint to which the lisset was not sent for the response is on the same router as the first resource to which the lisset was given. In I2Pd, the problem is solved simply and elegantly: a separate storage of lissets is created for each endpoint, which cannot be accessed by other hidden services located on the router.
A detailed examination of the frequently mentioned threats turned out that there are much fewer vulnerabilities in I2P than pseudo-experts like to say. Support free projects, report bugs and shortcomings. Free software is when without funding and most often without advertising, but on the conscience. Do not forget that SMS during registration is not the norm!

The material is based on text and illustrations from 

Routing in the I2P network. floodfils

Hornbeam

8 min

View Original

"Open Source" and "decentralization" are the two main badges that provide a good first impression of the project. Often, popular projects are cunning on these topics, or completely mislead their users, being proprietary and partially centralized. For example, the semi-open Telegram and the very prominently centralized TOR.

What do we know about I2P? I propose to understand in detail what ensures the connectivity and performance of an absolutely decentralized network: Floodfiles are a kind of bulletin boards.

Introduction to the topic

To begin with, intranet I2P names do not correspond in any way to any IP addresses, as they do in the traditional Internet. Therefore, there is no routing across networks and subnets, which is provided by the concept of IP. Moreover, the status of the network, directly related to anonymity, must be based on something. Agree, the question here is clearly not about optimally short paths from point to point, but rather about something the opposite: unpredictable routes and a ton of cunning cryptography.

Intranet resource identifiers, such as website addresses, do not contain any information about the physical location of the server. The familiar address ending in ".b32.i2p" is just a SHA256 hash of the full address, which includes a set of cryptographic keys. The full address, in conjunction with information about incoming tunnels, is called a lisset, which is necessary to establish a connection with the hidden service.

It is known that the hash function is irreversible, i.e. it is impossible to recover from the hash value the original data from which the unique string was taken. Understanding this leads to the logical conclusion that the received b32 address must be resolved in much the same way as it happens in a regular network, when the IP address of the target resource is determined from the domain name: the information is returned by the DNS server in response to a user request for a specific name. In I2P, instead of pre-known DNS servers, floodfills are used - bulletin boards where hidden resources publish information about themselves so that they can be contacted.

There are several fundamental differences from the traditional domain name system:

• In I2P, there are no registrants (do not confuse with binding short addresses ".i2p", as they, in simple terms, are attached to an already existing long address ".b32.i2p" for free);

• It is fundamentally wrong to constantly store a lisset in one place, because any of the floodfills can be malicious. The placement of information about a lisset should be unpredictable for floodfilers, but logical for those who are looking for it;

• Lizset contains not only the full address of the resource, consisting of cryptographic keys, but also information about incoming tunnels. All tunnels only exist for 10 minutes, so the lisset must be updated regularly to keep the resource accessible from the outside.

How a local I2P router finds a hidden service

The logic that allows a hidden resource (destination) to be published on an unpredictable floodfill (floodfill), and then another user to find this published lisset is quite elegant in practice:

The target address is taken (for example, the one that the user entered into the URI string of the browser) and today's date. The SHA256 hash is derived from this information block. Then the floodfile is searched in the local database of the router: all available ones are sorted out. On average, their number ranges from hundreds to a couple of thousand, depending on the operating conditions of a particular I2P router. To apply for a lisset, the one that, when using the EXCLUSIVE OR operation with the “target b32 address + today's date” block, will give the smallest value.

If the polled floodfill does not have the desired lisset, it returns three floodfills from its list that it thinks are the best for the address we want to access. After polling additional floodfills, in case of failure, the address is considered unavailable.

The publication of a lisset works according to a similar logic. The two most suitable floodfiles are selected for publication. When a new lisset is received, each of the two floodfils reports it to the three most suitable floodfils from its base. This is where the distribution ends.

The destination that publishes its lisset will check the quality of the publication. After sending a lisset to the floodfil, a response is expected. If there is no response, the lisset is sent to the next floodfill. In case of successful publication, the floodfill returns a list of its neighbors with whom it shared the lisset. There is a control appeal to the named neighbors. The received lissets are checked and, if they are all copies of what was originally sent by the initiator, the publication is considered complete. A lisset is published every ten minutes as the tunnels age.

Where do floodfils come from

A flood file is a role that any router can take on. Naturally, such a router should be easily accessible for external requests: it should have an open working port and a white IP address. All the necessary settings are one parameter in the configuration file: floodfill = true.

router address

We figured out the endpoint identifiers: these are entities without physical addresses that are located on unknown I2P routers. And what about the addresses and identifiers of the routers themselves, especially since floodfiles are also routers in their essence?

A home internet router has an IP address, server applications on the regular internet have an IP address and port.

I2P routers also have an address: it is a set of cryptographic public keys. Router addresses are similar to the hidden endpoint addresses discussed above. The router address is a set of cryptographic keys - practically the same as the base64 address of the endpoint. The shorthand uses the SHA256 hash, which gives 32 bytes of output. In fact, this is an analogue of the b32 address. In order not to confuse router addresses and endpoint addresses, router identifiers (router ident) are encoded in base64 (the first line in the screenshot).

Traffic between routers is encrypted at the level of network transport protocols: NTCP2 (crypto analog of TCP) and SSU (crypto analog of UDP). This hides absolutely all I2P traffic from an outside observer, such as a home ISP. At the same time, transport cryptography is not tied to the keys of the router. Router keys are used optionally depending on the type of traffic passing through. Deepening into the topic of different layers of encryption can cause a cognitive disorder for an unprepared reader, so let's get back to the topic.

The router address does not contain information about connecting to it, only public keys. This also happens with hidden service addresses, where a lisset with incoming tunnels is needed to access the resource. The router instead of the lisset RI (router info) has a file that includes the full address and information about physical accessibility. This file is static, so there is no need to re-request it every ten minutes.

The resulting Router Info is stored in the local "netDb" directory. RI contains special flags (Router Caps) that report the router's bandwidth and the status of the flood file (or the absence of this status). In the future, the new router can be used as a transit node when building tunnels.

The lisset always contains only the short identifier of the first router of the incoming tunnel (gateway). To contact this router, the last node of our outgoing tunnel resolves the received node address through the floodfile known to it and, if successful, starts transmitting information to the incoming tunnel of our destination.

Moreover, when building a tunnel, the identifiers of the neighbor router are resolved in a similar way by each tunnel participant if the required Router Info is not in its local storage. But this is again a slight digression from the topic of floodfills to tunnels.

Network exploration

The term network research is understood as the regular appeal of each router to floodfiles known to it in search of new routers. This process is often referred to as network pattern expansion or probing.

The bottom line is this: a random value is sent, in response to which the floodfil sends the three closest in the mathematical sense Router Info. Proximity is calculated by the logical operation "EXCLUSIVE OR". In essence, this is a function of the standard floodfiling in search of an address, only the address is generated randomly, so the floodfil returns three neighbors that we could refer to while continuing to search for the "address".

Research appeals are carried out through special tunnels, which are undemanding to the speed of information transfer. As a rule, if transit tunnels appear on a router with low bandwidth, they are research tunnels.

Network exploration through tunnels (rather than directly router-floodfil) is a measure to combat Eclipse and Sibyl attacks, which are aimed at isolating the user in the perimeter of malicious floodfils that can intentionally ignore requests from a particular router. Thanks to the chain of hops in the exploration tunnel, floodfil doesn't know which router is actually requesting three new routers to expand its network pattern. The attack models on I2P are discussed in detail in the article .

This is how a completely independent routing system of an anonymous I2P network, built on floodfiles, looks in general terms. At the same time, floodphiles are not holding ten trusted organizations, Comrade Major or Angela Merkel, but thousands and thousands of volunteers.

A few words for floodfil holders

The floodfill mode increases the amount of router resources consumed. This must be taken into account on very weak devices such as single-board computers. Or it was necessary to take into account earlier ... Thanks to the development of I2P in the form of the introduction of modern cryptography, the issue becomes so irrelevant that in the near future it may be completely omitted.

The fact is that all calls to the floodfil come encrypted with its asymmetric encryption key. In the old implementation, this is the ElGamal key , which requires a lot of CPU time. The current mode of operation uses elliptic curve cryptography (encryption type ECIES_X25519_AEAD, code 4). As the network upgrades, the old resource-intensive encryption is a thing of the past, as the new type is used by default.

Already today there are successful examples of i2pd working in floodfill mode on OpenWRT routers. We will talk about the prospects for turning a coffee maker into anonymus in one of the following articles.

The original article was published on the ITSOFT data center blog.

Просмотры: