router-tcpaccess-DoS.txt

`Date: Thu, 4 Feb 1999 11:05:31 -0600  
From: HD Moore <[email protected]>  
To: [email protected]  
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 <[email protected]>  
To: [email protected]  
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  
  
[email protected]  
  
--------------------------------------------------------------------------  
  
Date: Fri, 5 Feb 1999 10:16:39 -0800  
From: John Bashinski <[email protected]>  
To: [email protected]  
Subject: Re: Widespread Router Access Port DoS  
  
[cust-security-announce people: The quoted paragraph is from a posting  
on "[email protected]"]  
  
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 <trusted-host-1>  
access-list 1 permit host <trusted-host-2>  
...  
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  
  
`