4 ms·

This doesn't seem nearly as bad as 'hijacking' implies. > The attacker can now inject arbitrary payloads into the ongoing encrypted connection using the inferr

This doesn't seem nearly as bad as 'hijacking' implies. > The attacker can now inject arbitrary payloads into the ongoing encrypted connection using the inferred ACK and next sequence number. First, it's hard to get to this point. Then, you're injecting garbage because you don't know the payload encryption keys. So it's just disruptive, even though yes technically it is 'hijacking'. Unless I missed something, of course! I found the writeup to be vague on the payload encryption point. It should have explicitly stated the impact one way or the other.

aaronmdjones 7y ago
For your first point, this isn't hard if you're in the appropriate position (adjacent or upstream), as the post details. There are already tools available that can do all of this, example invocations are also there. For your other point, they don't need to know the keys (unless the traffic travelling /over/ the VPN is /also/ encrypted). That's the whole point. This is about being able to trick the machine into accepting traffic for a connection, from an interface that the connection's traffic isn't travelling over. If it's plaintext within the VPN, this sidesteps the VPN interface and you can indeed inject your own malicious plaintext traffic into that connection.
- jiveturkey 7y ago
  1. Yes, you have to already be in position. That's limited to specific actors. Once that is achieved, you have to probe for specific IP addresses the victim might be connected to. IOW a list you are targetting. Then the port probing and seqno guessing. These facts reduce the impact because it's not just "be a guy on the internet", eg like if there were an open database of PII sitting there for the taking, only needing discovery to find it. In no way am I claiming the attack isn't feasible. It's definitely a real risk, beyond the theoretical. 2. Thanks, got it. That makes more sense. I think I actually like this vuln. It reinforces the need for defense in depth. It reduces a takeover to an annoyance (could be critical for some apps, yes) assuming you use TLS at the app layer.
  - aaronmdjones 7y ago
    > That's limited to specific actors. 1) Anyone who can compromise the residential gateway in your home 2) Anyone & anything connected to the same home network as you (incl. any IOT devices; and no, they don't need Internet access) 3) Anyone who can compromise the residential gateway in whatever coffee shop you happen to be in 4) Anyone & anything connected to the same coffee shop network as you 5) ... ... and, like I said, easily scriptable, with the tools already available to carry it out. It's not a doomsday scenario, but it is pretty bad. The one saving grace is that most apps these days use some kind of application-level authentication and/or encryption, e.g. TLS.
loeg 7y ago
The impact is to unauthenticated TCP connections over encrypted VPNs. The attacker can inject arbitrary content into the TCP session, without knowing the VPN keys. If you are using an authenticating protocol for your cross-VPN traffic, such as TLS, then your connection over the VPN isn't vulnerable. If you are relying on the VPN encryption to protect unauthenticated communication, then you're SOL. The vulnerability isn't in the VPNs themselves, precisely, but in the way VPNs and packet routing interact.

aaronmdjones 7y ago

For your first point, this isn't hard if you're in the appropriate position (adjacent or upstream), as the post details. There are already tools available that can do all of this, example invocations are also there. For your other point, they don't need to know the keys (unless the traffic travelling /over/ the VPN is /also/ encrypted). That's the whole point. This is about being able to trick the machine into accepting traffic for a connection, from an interface that the connection's traffic isn't travelling over. If it's plaintext within the VPN, this sidesteps the VPN interface and you can indeed inject your own malicious plaintext traffic into that connection.

jiveturkey 7y ago
1. Yes, you have to already be in position. That's limited to specific actors. Once that is achieved, you have to probe for specific IP addresses the victim might be connected to. IOW a list you are targetting. Then the port probing and seqno guessing. These facts reduce the impact because it's not just "be a guy on the internet", eg like if there were an open database of PII sitting there for the taking, only needing discovery to find it. In no way am I claiming the attack isn't feasible. It's definitely a real risk, beyond the theoretical. 2. Thanks, got it. That makes more sense. I think I actually like this vuln. It reinforces the need for defense in depth. It reduces a takeover to an annoyance (could be critical for some apps, yes) assuming you use TLS at the app layer.
- aaronmdjones 7y ago
  > That's limited to specific actors. 1) Anyone who can compromise the residential gateway in your home 2) Anyone & anything connected to the same home network as you (incl. any IOT devices; and no, they don't need Internet access) 3) Anyone who can compromise the residential gateway in whatever coffee shop you happen to be in 4) Anyone & anything connected to the same coffee shop network as you 5) ... ... and, like I said, easily scriptable, with the tools already available to carry it out. It's not a doomsday scenario, but it is pretty bad. The one saving grace is that most apps these days use some kind of application-level authentication and/or encryption, e.g. TLS.

loeg 7y ago

The impact is to unauthenticated TCP connections over encrypted VPNs. The attacker can inject arbitrary content into the TCP session, without knowing the VPN keys. If you are using an authenticating protocol for your cross-VPN traffic, such as TLS, then your connection over the VPN isn't vulnerable. If you are relying on the VPN encryption to protect unauthenticated communication, then you're SOL. The vulnerability isn't in the VPNs themselves, precisely, but in the way VPNs and packet routing interact.