# Bellovin ESP Attack on UDP Packets

In Bellovin's ESP Attack, it is stated that:

If $L_A$, $L_B$ are using UDP, attack is easier:

• Wait till session ends
• Allocate $L_B$'s UDP port to $X_B$
• Replay all packets

So, how does attacker know the UDP port of legitimate user $L$? Isn't it encrypted (because the UDP header encrypted)? How can the attacker obtain it?

Also, if the attacker knows the UDP port number of legitimate user, why should he wait till the end of the session? He can sniff the packets and change the UDP port number. Then he can receive the packages in another port during the session. Is my assumption wrong?

• The article (pdf) states: "If $L_A$ and $L_B$ are using UDP to communicate, the attack may be even easier. $X$ can wait until process $L_B$ is finished, allocate the same UDP port number on host $B$ as $L_B$ used, and reinject the packets onto the wire where they will be received again by $B$. The kernel will decrypt them, and pass them along". I read it as assuming UDP port is public or/and in clear. – fgrieu Mar 29 '18 at 10:33
• The unclear part of it for me is determining the UDP port which $L_B$ used before. How can attacker know the port? Is it a fixed port which all users must connect here? – aselimkaya Mar 29 '18 at 10:36
• BTW: Bellovin's attack does not work if the IPsec transform includes an integrity transform; either ESP authentication, or AH. In fact, that was largely what Bellovin was arguing; that privacy without authentication is dangerous. – poncho Mar 29 '18 at 18:04

Also, if the attacker knows the UDP port number of legitimate user, why should he wait till the end of the session? He can sniff the packets and change the UDP port number. Then he can receive the packages in another port during the session. Is my assumption wrong?

Actually, if:

• The encryption is CBC mode or CTR mode (the actual block cipher doesn't matter)
• the SA was in transport mode (for CBC mode; it doesn't matter for CTR mode)
• the SA wasn't negotiated to be a specific UDP destination port

Then yes, you can modify the UDP port number. All you need to do is flip some of the bits from bits 16-31 of the IV (for CBC mode), or flip bit 16-31 of the ciphertext (for CTR mode and transport), and that'll flip the corresponding bits of the decrypted UDP destination port, with no other changes. For example, if the SA used CBC, and the legitimate user was using UDP port 2000, and you have UDP port 2001 open, you can just take the original packet, flip bit 31 of the IV of the encrypted packet, replay that, and that'll give you the original packet on the destination port of your choosing.

Another reason why not using an integrity transform is a Bad Idea...

• Oops, I had forgotten this part of the question. (+1) – Erwan Legrand Mar 30 '18 at 14:32

All UDP information (including the port number) is encrypted: https://tools.ietf.org/html/rfc1827#section-3

(Please note that the link above points to the specification of ESP as it was when Steven Bellovin published his USENIX paper. This RFC is now obsolete.)

Guessing the port number should be quite easy: use the netstat command to list UDP ports in use, ignore the ones with a peer address which does not match, and the ones used by known services.

Actually the answer could be found in the original paper a few lines bellow where the TCP case is discussed.

Still, on modern high speed net works it isn't that hard to make the sequence numbers wrap, and the attacker may be able to learn the necessary port numbers by polling via netstat on either machine.

This is very simple: the attack does not require much sophistication on the attacker's part. All that is required is a network capture and basic knowledge of UNIX system utilities such as ps and netstat.

This is Bellovin's point here: in this case tampering of the transmitted data is not even necessary to mount an attack. This is why waiting for the end of the process is mentioned. The attacks which can be performed while the process is still running require more work or more specialized tools. (Bellovin's main attack involves tampering with unauthenticated CBC encrypted data, as pointed out by Poncho in a comment.)

• Actually, that's a stale RFC, as the current IPsec implementations use a different packet format (although not differing in the point you're making). I'd point him to either 2406 or 4303 – poncho Mar 29 '18 at 15:14
• @poncho Agreed, although RFC 1827 was the current version when Steven Bellovin published his USENIX paper. – Erwan Legrand Mar 29 '18 at 15:43