Comments on TCP Reset Worries
I attended Paul Watson's talk at CanSecWest this week on "Slipping in the Window" (.ppt slides, .doc paper. Paul was inspired by last year's Black Hat 2003 Las Vegas talk "BGP Vulnerability Testing" by Matthew Franz & Sean Convery (.pdf original talk). I attended that presentation as well, and found Matt and Sean's conclusion to be accurate: why bother with lower layer attacks when you can own the router? In other words, so many routers are misconfigured, it's not necessary to resort to spoofing or other elaborate games to disrupt global routing.
Paul dedided to focus on the likelihood of successful reset attacks against routers speaking BGP. He found that Matt and Sean's estimates for the time needed to guess the right TCP sequence number to reset a TCP connection were overstated. Matt and Sean did not take into account TCP receive windows, meaning a reset with a sequence number within the window would be accepted by the target. This makes it easier to reset a persistent connection, and TCP implementations with large windows are even easier to disrupt.
Matt and Sean posted an updated version of their paper acknowledging Paul's finds (.pdf).
A well-written advisory by the UK's NISCC states "an established connection will abort by sending a RST if it receives a duplicate SYN packet with initial sequence number within the TCP window." This means tearing down established connections can be done with SYN packets, not just RST packets.
CIsco published an advisory titled TCP Vulnerabilities in Multiple IOS-Based Cisco Products explaining the issue and listing fixes. It's important to note that since Cisco IOS 10.2 (very old!), IOS rate-limits RST packets by default. According to Cisco, "in the case of a storm of RST packets, they are effectively limited to one packet per second." This countermeasure effectively renders Paul's reset attack too slow to be workable. However, SYN packets are not rate-limited.
Cisco's rate limiting is not the only way to mitigate this attack. Anti-spoofing measures and not letting arbitrary traffic to inject itself between BGP speaking routers are other countermeasures.
I don't foresee the Internet dying at any time in the near future due to this discovery. Owning the target routers would probably be easier. Remember this is mainly a threat to persistent connections. No one is going to kill your Web browsing sessions with this sort of attack, but they would make your life miserable if you tried to download an .iso via FTP. Of course, how are attackers going to know what sessions to target?
Incidentally, while browsing Cisco's site I learning their IOS Upgrade Planner and Feature Navigator appears to be working again.
Update: Raven Adler spoke to the DC Security Geeks on 27 April about the BGP issue. Her talk was professional and informative. She worked on the same issue several years before Paul Watson's discoveries. She reported being involved in an incident response where an intruder physically attached a rogue laptop to a public peering point switch to disrupt and/or inject routing.
Paul dedided to focus on the likelihood of successful reset attacks against routers speaking BGP. He found that Matt and Sean's estimates for the time needed to guess the right TCP sequence number to reset a TCP connection were overstated. Matt and Sean did not take into account TCP receive windows, meaning a reset with a sequence number within the window would be accepted by the target. This makes it easier to reset a persistent connection, and TCP implementations with large windows are even easier to disrupt.
Matt and Sean posted an updated version of their paper acknowledging Paul's finds (.pdf).
A well-written advisory by the UK's NISCC states "an established connection will abort by sending a RST if it receives a duplicate SYN packet with initial sequence number within the TCP window." This means tearing down established connections can be done with SYN packets, not just RST packets.
CIsco published an advisory titled TCP Vulnerabilities in Multiple IOS-Based Cisco Products explaining the issue and listing fixes. It's important to note that since Cisco IOS 10.2 (very old!), IOS rate-limits RST packets by default. According to Cisco, "in the case of a storm of RST packets, they are effectively limited to one packet per second." This countermeasure effectively renders Paul's reset attack too slow to be workable. However, SYN packets are not rate-limited.
Cisco's rate limiting is not the only way to mitigate this attack. Anti-spoofing measures and not letting arbitrary traffic to inject itself between BGP speaking routers are other countermeasures.
I don't foresee the Internet dying at any time in the near future due to this discovery. Owning the target routers would probably be easier. Remember this is mainly a threat to persistent connections. No one is going to kill your Web browsing sessions with this sort of attack, but they would make your life miserable if you tried to download an .iso via FTP. Of course, how are attackers going to know what sessions to target?
Incidentally, while browsing Cisco's site I learning their IOS Upgrade Planner and Feature Navigator appears to be working again.
Update: Raven Adler spoke to the DC Security Geeks on 27 April about the BGP issue. Her talk was professional and informative. She worked on the same issue several years before Paul Watson's discoveries. She reported being involved in an incident response where an intruder physically attached a rogue laptop to a public peering point switch to disrupt and/or inject routing.
Comments