CVE-2023-36325: Attackers can de-anonymize i2p hidden services with a message replay attack

Published on 07/30/2023, 704 words, 3 minutes to read

tl;dr: If you host eepsites with Java i2p and are running older than i2p 2.3.0, update it as soon as possible. More details below.

A sufficiently determined attacker may be able to de-anonymize the public IPv4 and IPv6 addresses of i2p hidden services (eepsites) by using a combination of brute-forcing the entire i2p router set with a replayed message. This is CVE-2023-36325.

This issue was originally discovered by a user with the identifier hbapm6le75xwc342hnkltwfnnmt4ccafr5wyf7b6jhw6jxn3fwqa.b32.i2p, which I will refer to as "hbapm6". While hbapm6 was working on a custom version of i2p, they found that replaying messages sent down client tunnels to target i2p routers could cause the i2p software to drop the packet instead of sending a "wrong destination" response. This can lead to de-anonymization of a given eepsite by being able to correlate the public IPv4 or IPv6 address of the contacted router with packets being dropped.

This is fixed in i2p 2.3.0 by adding a unique identifier to every message ID and separating out bloom filters and other datastores so that such correlation attacks are harder to pull off in the future. These changes are protocol-compatible and all users are encouraged to apply them as soon as possible.

There is insufficent data as to what versions of i2p are vulnerable, but we are certain that 2.2.1 is vulnerable. It is likely that older versions of i2p are also vulnerable. Assume so.

This attack takes days to complete and requires a fairly detailed amount of knowledge of the i2p protocol in order to successfully de-anonymize target eepsites.

Users of i2pd are not affected.

With this understood, here is the CVSS score breakdown for this attack:

AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N/E:P/RL:O/RC:C/CR:M/IR:X/AR:X/MAV:N/MAC:H/MPR:N/MUI:N/MS:U/MC:L/MI:N/MA:N

Affected users should update to i2p 2.3.0 as soon as it is available.

The vulnerability has been mitigated by a refactor of the relevant codepaths involved with message parsing. Additionally, the network information database was sharded off with the hope of preventing future attacks.

On a side note, I have been very impressed with the i2p projects handling of the circumstances surrounding hbapm6 of the issues tracked as CVE-2023-36325. For an unknown reason, hbapm6 decided that the best way to get attention for these issues was to impersonate me. I was contacted by the i2p project due to hbapm6 acting very strange (IE: claiming to have a vuln and refusing to show proof of it or how they triggered it, if you have a de-anonymization attack for such a network, just share your code and demonstrate it when asked, it will save so much time for everyone involved), and after a month or two of cajoling, hbapm6 eventually managed to de-anonymize a throwaway VPS that was acting as an i2p router. This confirmed the vuln and lead to me filing this CVE.

I guess this is part of my threat profile now. Fun.

At the very least I got to have a conversation that was like (names have been changed to protect the innocent):

(hbapm6); Why all the snooping? [...] What is this, a game of Among Us?

(Me) <link to my website to an ascii art of an amogus with proof that I am the actual Xe Iaso>

I still have no idea why that person impersonated me. If you're out there and reading this and I wronged you somehow, I'm sorry and would like to know what I fucked up so I can change for the better.

There's some other vulnerabilities that are related to this, but none of them have viable attacks. Most of the changes being done are just various hardening to the pokey edges of the network database and other things. I expect that these are fairly minor issues and when the patch comes out you should probably update.

Facts and circumstances may have changed since publication. Please contact me before jumping to conclusions if something seems wrong or unclear.

Tags: i2p, cve, netsec, infosec