SAM Datagram Handling Enables Replay Attack
Opened 7 years ago
Last modified 3 years ago
#1336assignedenhancement
SAM Datagram Handling Enables Replay Attack
Reported by:ExtraBatteryOwned by:slumlord Priority: minor Milestone:
Component: www/i2p Version: 0.9.13 Keywords:
Cc:
Parent Tickets:
Sensitive: no
Description
At the moment the datagram protocol by itself does not guarantee that a repliable datagram is really directly coming from the address it appears to be from. It could just be replayed by anyone who ever received the datagram. This came as a surprise to me, as I thought I2P is very secure. I don't know if this problem is limited to SAM or affects I2P in general, as I don't know to which module the repliable datagram protocol belongs.
An attacker can listen to repliable datagrams, collect and store them and later re-send them as if the original sender had sent them, effectively achieving I2P address spoofing. There seems to be no way for the victim to notice that the datagram was just replayed. The attacker can arbitrarily choose the recipient and thus forward the collected datagrams to recipients not intended by the original sender, or simply send them at a different point in time or in an excessive quantity. This might be used to enable other attacks or disrupt distributed networks.
I have - using SAM v3.1 - confirmed that it's possible to do this, at least in the sense that SAM tells you that the datagram came from the original sender when in fact it was replayed by another sender.
An example: The attacker would first become part of the iMule Kademlia network. Thus the attacker would receive a lot of repliable datagrams from different peers, all signed by their original senders. The attacker can then re-send each datagrams at will to arbitrary destinations, fooling the recipients regarding the origin. A denial of service attack against a certain group of nodes could be performed this way.
Suggested solution: The attack is possible because the repliable datagram contains no info concerning the intended recipient (in the actual message). The solution would be to include the SHA-256 of the intended recipient's destination in repliable datagrams. This hash must of course be part of the signed text. A repliable datagram ought to be dropped if the included hash doesn't match that of the recipient's destination. This change might not be compatible, but one could allow repliable datagrams without the hash for another year and then start to drop them to fix the vulnerability.