Date: Thu, 4 Feb 1999 11:05:31 -0600 From: HD Moore To: BUGTRAQ@netspace.org Subject: Widespread Router Access Port DoS +--------[ Router Access Port DoS The tcp access / configuration ports on most routers can be disabled remotely. These sit on port numbers like 23,2001,4001,6001, and 9001. The attack simply consists of shoving a few thousand bytes of any character down the connection, a couple times may be needed for some routers, with the length of time of the DoS related to the amount of bytes you send down the initial connection. Some Cisco's would have to be reset manually to fix this, others will recover by themselves given a few minutes, hours, or days. ComOS seems to be in the manual-reset category, as I haven't found one yet that recovers from a 1 minute attack onto thier access ports. Normal operation continues, only in a few freak cases did the router drop the entire network / reset connections as a result. The impact of this is that an administrator would need physical access to reconfigure a router after an attack like this. This is merely annoying for those who have a rack in the closet, and a huge pain in the ass for those 'remote' admins who may or may not be able to have someone reset them for them. The fix would be to set your ACL's to deny access to the configuration ports from outside your network. Specific information on affected IOS versions, code revisions, etc are not known at this time. If you would like to do some testing of your own and share the results I will write up a summary in a week or so. The exploit is just pathetic, and may need 3-6 runs of varying lengths to any substantial damage. Shorter attacks result in shorter downtimes for those ports, longer attacks do everything from locking the port out until it is reset to crashing the router itself. The one line bash$ exploit is: perl -e'print 0xFF x 10000' | telnet router.example.org 2001 . After disconnecting try to connect to that port again, it should say connection refused. While some routers will recover within 30 seconds to 5 minutes, older models tend to take days to ??? to fix themsleves. -HD -------------------------------------------------------------------------- Date: Fri, 5 Feb 1999 04:08:07 PST From: Mr. joej To: BUGTRAQ@netspace.org Subject: Re: Widespread Router Access Port DoS I believe there is some clarification to your 'DoS' that should be stated. What versions of cisco IOS are you refering to? But either way you are refering to 2 seperate, possibly 3 seperate features of Cisco IOS. Port 23 (telnet obviously) spawns a 'virtual terminal' when it receives a connection. This can be protected from 'unauthorized' access by an ACL. Instead of applying an interface specific ACL, you should place one in the actual Line VTY config. Regarding ports 2001, 4001, 6001, and 9001. Those are all 'reverse telnet' ports for the AUX port. In my experience I have seen several routers that do have this misconfigured, however a DoS attack against this port is of no importance. The simple fix is to apply 'transport input none' to the aux port. And if the administrator actually knows what he is doing, and needs reverse telnet ability to the router's AUX port, once again an ACL can be applied to only allow specific access. I agree that if the reverse telnet to the AUX is used, it can be tied up, just by connecting to one of the ports 2001, 4001 .... and no other port will answer a connection....(assuming no ACL is installed) However, currently I do not consider what you have stated a DoS attack. I have not seen any router 'reboot' from anything you have stated. Please post more information to clarify. joej Mr_JoeJ@hotmail.com -------------------------------------------------------------------------- Date: Fri, 5 Feb 1999 10:16:39 -0800 From: John Bashinski To: BUGTRAQ@netspace.org Subject: Re: Widespread Router Access Port DoS [cust-security-announce people: The quoted paragraph is from a posting on "bugtraq@netspace.org"] Yet again, I have to remind y'all that sending these to BUGTRAQ will not get you as fast a response as sending them in directly. At least not from Cisco; can't speak for 3Com or anybody else. This is very preliminary information for Cisco routers; I just saw the message I'm responding to about an hour ago. There may be more going on than this. We'll continue to test and characterize this, and will send out updates as appropriate. > The tcp access / configuration ports on most routers can be disabled > remotely. These sit on port numbers like 23,2001,4001,6001, and 9001. > The attack simply consists of shoving a few thousand bytes of any > character down the connection, a couple times may be needed for some > routers, with the length of time of the DoS related to the amount of > bytes you send down the initial connection. Some Cisco's would have to > be reset manually to fix this, others will recover by themselves given a > few minutes, hours, or days. ComOS seems to be in the manual-reset > category, as I haven't found one yet that recovers from a 1 minute > attack onto thier access ports. Normal operation continues, only in a > few freak cases did the router drop the entire network / reset > connections as a result. I was able to reproduce something like this. At least in my tests, it appears that the router isn't noticing that the TCP connection is being shut down by the initiating end. I don't yet know why; it could be a bug on either end. I'll assume it's a Cisco bug, and report it as such, but it would be interesting to know what sort of machine you were using for your testing. I'm using Linux 2.0.x with netcat as the traffic-sending program. Since the TCP connection isn't deleted, the virtual TTY (VTY) is not being released. If you run a bunch of attacks, you eventually end up with all your VTYs hung up on nonexistent connections. If you can reach the router at all, you can reclaim them with the "clear line" command, but if they're all hung up, you may not have a way to get in and do that. Although the router's getting into this state under these circumstances is very probably caused by a bug, and we will address that bug, it's very important that everybody understand that it would be possible to create the same condition *without* any bug. The easiest way would be to keep opening (and not closing) TELNET sessions to the router, until it refused to accept any more, then simply turn off the power on the initiating system, so that the sessions were never closed properly. That's just the way TCP works. It affects any system that accepts TELNET connections and doesn't use TCP keepalives. It may be aggravated by a bug in this case, but you can definitely make it happen without having a bug. There are several ways to mitigate this vulnerability in your Cisco configuration: 1. Don't accept TELNET connections from just any old host on the network. Do something like this: access-list 1 permit host access-list 1 permit host ... access-list 1 deny any line vty 0 4 ! Select all 5 VTYs transport input telnet ! Don't accept non-TELNET connections access-class 1 in ! ... and only from listed machines We very strongly recommend this configuration for *all* Cisco devices, regardless of this particular issue. It's just plain bad practice to let everybody on the Internet make interactive connections to your router. This is known to work, and should be the primary defense. 2. Configure "service tcp-keepalives-in". This will make the router detect dropped TCP connections. By default, it won't detect a dropped session unless it has output to send to that session... which it usually won't have for a long time, if ever. I have not fully verified that this one works against the "shoving bytes into the connection" attack; I can't reproduce the failure reliably enough to be sure that I've eliminated it. I would expect this to work. Even if it doesn't end up being a solution for this situation, it's a good idea in general. 3. Configure timeouts on the VTY lines, so that an idle session can't permanently occupy a line. You might do: line vty 0 4 exec-timeout 10 ! Disconnect if no commands for 10 minutes session-timeout 10 ! Disconnect if outgoing session and no input I don't think that this one will work with this particular problem, because the failure is at the login prompt. It's a good idea, though, if you want to keep your VTYs from being eaten up over time by dead sessions. It may be a few days before we have more information than this. -- J. Bashinski Cisco Systems Product Security IRT