cisco-ios-identification.txt

`Date: Mon, 18 Jan 1999 09:48:52 PST  
From: Mr. joej <[email protected]>  
To: [email protected]  
Subject: Remote Cisco Identification  
  
Alpha Release: 0.9  
Released Through: Rhino9 Team  
By: JoeJ  
Shouts: Horizon, apk-, NeonSurge, Xaphan  
  
----------------------------------------------------------------  
  
Intro:  
------  
This release covers some information that was found sniffing a  
portscan session. What was found wasn't anything super special.  
I'm sure anyone running a packet sniffer while performing a port  
scan on a cisco has seen this. But it is the implications of  
this that are not fully understood.  
  
Cisco Note:  
---------  
It is documented that cisco uses port 1999. However I have never seen  
the details of its use. This may not be an immediate security bug, it  
may do exactly as it was intended. However I did not feel that everyone  
would be aware of how easy it is to remotely identify Cisco products.  
With the IOSLOGON, and HISTORY bug out there, it may be advisable to  
prevent your router from telling everyone what brand it is.-----Thanks  
to Aleph One for info----------  
>tcp-id-port 1999/tcp cisco identification port  
>tcp-id-port 1999/udp cisco identification port  
  
  
  
The Deal:  
---------  
Basically any Cisco Router or device running IOS code responds  
to requests to port 1999 different than any other port. Follow  
the diagram below for details.  
  
[Computer] [Cisco]  
  
SYN port 2000 -------->   
  
<-------- RST,ACK  
  
No big deal, that's how it should work. However:  
  
[Computer] [Cisco]  
  
SYN port 1999 -------->   
  
Includes the string 'cisco' in payload <------- RST,ACK  
  
Cisco products respond to SYNs directed to port 1999 with  
a RST. Which is normal but they also include 'cisco' in  
the payload of the packet.  
  
Implications:  
-------------  
It is now easy to scan a large range of IP addresses to find  
Cisco products. In the next week Rhino9 will hopefully release  
a Cisco scanning utility. Even if the device doesn't allow access  
to the telnet port it is now possible to determine Cisco hardware.  
  
  
Fix:  
----  
The easy fix is to specify an ip filter to deny incoming tcp  
communication to port 1999.  
  
  
Future:  
-------  
It is unclear why this happens. I'm unclear on the apparent  
implimentation of this feature. It may turn out to be a welcome mat.  
Either way Rhino9 will dig-in regarding this subject.  
  
----------------------------------------------------------------  
JoeJ & The Rhino9 Research Team - http://207.98.195.250  
----------------------------------------------------------------  
  
--------------------------------------------------------------------------  
  
Date: Mon, 18 Jan 1999 13:34:53 -0700  
From: Kurt Seifried <[email protected]>  
To: [email protected]  
Subject: Re: Remote Cisco Identification  
  
  
>Cisco Note:  
>---------  
>It is documented that cisco uses port 1999. However I have never seen  
>the details of its use. This may not be an immediate security bug, it  
>may do exactly as it was intended. However I did not feel that everyone  
>would be aware of how easy it is to remotely identify Cisco products.  
>With the IOSLOGON, and HISTORY bug out there, it may be advisable to  
>prevent your router from telling everyone what brand it is.-----Thanks  
>to Aleph One for info----------  
>>tcp-id-port 1999/tcp cisco identification port  
>>tcp-id-port 1999/udp cisco identification port  
  
Probably the big brother to:  
  
>From a CCNA study guide (slightly paraphrased):  
  
Cisco Discover Protocol  
layer 2 media and protocol independant protocol that runs on all cisco  
manufactured hardware (yikes)... Each device configured for CDP sends  
out periodic messages to a MAC layer multicast address. These  
advertisements include information about the software and capabilities  
of the platform (double yikes).  
  
show cdp neighbour  
shows a table with what is attached to interfaces (at the remote end).  
  
show cdp neighbour detail  
shows a whole lot more info, supposedly a great tool for trouble shooting,  
since it is protocol/media independant you can see if the remote side  
has a misconfigured address/whatnot. More detail on how to disable it/etc  
on page 78-79 "Router Products Commands Summary Rel 11.0" (just look  
up cdp in the index).  
  
You might want to see if there are commands to show info like the  
interfaces,  
networks, and whatnot, I suspect they might be in there (nice boner for  
cisco  
to pull). Then it would make for a truely great Cisco network discovery  
util.  
  
-seifried, MCSE, wanna be CCNA.  
  
--------------------------------------------------------------------------  
  
Date: Mon, 18 Jan 1999 13:40:23 -0800  
From: John Bashinski <[email protected]>  
To: [email protected]  
Subject: Re: Remote Cisco Identification (fwd)  
  
Context for [email protected]: somebody on the BUGTRAQ  
mailing list is talking about the Cisco identification port, TCP  
port 1999.  
  
> Intro:  
> ------  
> This release covers some information that was found sniffing a  
> portscan session. What was found wasn't anything super special.  
> I'm sure anyone running a packet sniffer while performing a port  
> scan on a cisco has seen this. But it is the implications of  
> this that are not fully understood.  
  
If you asked us, we would simply tell you.  
  
> Cisco Note:  
> ---------  
> It is documented that cisco uses port 1999. However I have never seen  
> the details of its use.  
  
It does exactly what you saw it do, and no more. Its primary use is  
for network management.  
  
> This may not be an immediate security bug, it may do exactly as it  
> was intended.  
  
It does indeed do what's intended, which is to allow identification of  
Cisco equipment. It's been in the software for about 10 years that I  
know of. We might not put it in if we were doing it in today's  
environment, but we've had no complaints about it (as far as I know) in  
all the time it's been in there.  
  
It can indeed be used to identify Cisco equipment. Personally, and I'm  
not necessarily speaking for Cisco when I say this, I don't see that as  
a big issue. There are many ways to identify Cisco stuff fairly  
reliably, starting with the reasonably distinctive default login prompt.  
"nmap -O" doesn't seem to have any problem, and I assume queso can do it  
as well.  
  
However, my opinion is not as important as customers' opinions. If  
customers tell us that we don't want the port 1999 hack in the system,  
we can certainly look into taking it out. We would, of course, first  
have to look for legitimate applications that were using it, and find  
other ways to accommodate those applications. A lot of dependencies  
can appear in an installed base in 10 years.  
  
Nowadays, the port 1999 hack has largely been superseded by the Cisco  
Discovery Protocol (CDP), which provides a great deal more  
information... things you do *not* want to have crackers know, like your  
software version number. Although CDP only runs on a hop-by-hop basis,  
on the local LAN, and can't be queried over the Internet, we advise  
customers to turn it off in firewalls and other very sensitive machines.  
  
> However I did not feel that everyone  
> would be aware of how easy it is to remotely identify Cisco products.  
> With the IOSLOGON, and HISTORY bug out there, it may be advisable to  
> prevent your router from telling everyone what brand it is  
  
I can see your point. The feature is pretty obscure, and it's obviously  
better to give hostile people as little information as possible.  
  
However, for protection from those particular bugs, Cisco customers  
should *not* rely on people not knowing that their routers are  
Ciscos. Ignoring the threat of login prompts or "nmap -O", attackers can  
always just try the exploits (assuming that they know what the exploits  
are) and see if they work. Also, if the device is known to be a router,  
there's about a 70 percent chance that it's a Cisco, just based on  
market share.  
  
Regardless of whether they choose to block out port 1999, we *strongly*  
advise customers who may be endangered by any announced Cisco bug to  
upgrade their software and/or apply a specific workaround for that  
bug.  
  
For those of you who don't know about the two bugs in question, they are  
explained at  
  
http://www.cisco.com/warp/public/770/ioslogin-pub.shtml  
  
and  
  
http://www.cisco.com/warp/public/770/ioshist-pub.shtml  
  
> Cisco products respond to SYNs directed to port 1999 with  
> a RST. Which is normal but they also include 'cisco' in  
> the payload of the packet.  
  
Yes.  
  
> It is now easy to scan a large range of IP addresses to find  
> Cisco products. In the next week Rhino9 will hopefully release  
> a Cisco scanning utility. Even if the device doesn't allow access  
> to the telnet port it is now possible to determine Cisco hardware.  
  
... and I'd appreciate some feedback on how important customers think  
that is. Again, if there's significant demand, we'll look at taking the  
feature out. However, if you're concerned about exposures of this  
magnitude, you should probably look at other issues, like CDP, and  
perhaps protecting yourself from signature scans.  
  
> It is unclear why this happens.  
  
Basically, because one of our engineers, sometime in the mid-to-late  
1980s, decided that there should be a way to identify Cisco equipment.  
I don't know the reasons for his decision, but I do know who he is,  
and can ask him if you really want to know.  
  
> I'm unclear on the apparent implimentation of this feature.  
  
??? I don't understand your question. It's implemented in the same way  
as all the other services in the Cisco IOS software.  
  
> It may turn out to be a welcome mat.  
  
Nope. Sorry. Feel free to test it however you like to verify that.  
  
> Either way Rhino9 will dig-in regarding this subject.  
  
Enjoy... and please report any security problems you find to  
"[email protected]". We do read BUGTRAQ, but not nearly as fast  
or as thoroughly as we read messages to "security-alert".  
  
-- J. Bashinski  
Product Security IRT  
Cisco Systems  
  
--------------------------------------------------------------------------  
  
Date: Tue, 19 Jan 1999 13:16:51 -0500  
From: Jared Mauch <[email protected]>  
To: [email protected]  
Subject: Re: Remote Cisco Identification  
  
On Mon, Jan 18, 1999 at 01:34:53PM -0700, Kurt Seifried wrote:  
> show cdp neighbour  
> shows a table with what is attached to interfaces (at the remote end).  
>  
> show cdp neighbour detail  
> shows a whole lot more info, supposedly a great tool for trouble shooting,  
> since it is protocol/media independant you can see if the remote side  
> has a misconfigured address/whatnot. More detail on how to disable it/etc  
> on page 78-79 "Router Products Commands Summary Rel 11.0" (just look  
> up cdp in the index).  
>  
> You might want to see if there are commands to show info like the  
> interfaces,  
> networks, and whatnot, I suspect they might be in there (nice boner for  
> cisco  
> to pull). Then it would make for a truely great Cisco network discovery  
> util.  
  
These items can also be found if you have the snmp  
community to the units (see ftp://ftp.cisco.com/pub/mibs/v2/CISCO-CDP-MIB.my)  
  
Based upon what you may (or may not) want to do with your  
network, you can turn cdp off globally via "no cdp run"  
in your configuration, or "no cdp enable" on a per interface basis.  
  
I primarily use this information for network debugging and  
network discovery, which is very useful in many cases when dealing  
with customers, but they may also consider this a security issue  
of people knowing what equipment they have.  
  
Notes:  
  
1) CDP is only avaiable for adjancet cisco products  
2) CDP information via snmp could be highly detrimental  
if you have a common snmp community without filters (ie: public)  
  
- Jared  
  
--  
Jared Mauch | pgp key available via finger from [email protected]  
clue++; | http://puck.nether.net/~jared/ My statements are only mine.  
  
--------------------------------------------------------------------------  
  
Date: Wed, 20 Jan 1999 00:16:37 -0600  
From: Basement Research <[email protected]>  
To: [email protected]  
Subject: Re: Remote Cisco Identification  
  
There are other ways in which Cisco routers can be identified  
reliably; sometimes down to the minor release number. We found  
some of these while gathering information for a paper on  
remote identification, which will be published at the NordU/USENIX 99  
conference in February.  
  
Briefly, some of these distinctive characteristics include:  
  
  
- All versions from 10.3 through 11.3 respond to a SYN on an open port  
with a SYN/ACK with an IP ID field of 0.  
- Versions from 10.3 through 11.2 respond on closed and open ports to  
packets not containing ACK, SYN or RST with a RST which contains an  
incorrect ACK number. On 10.3 and 11.0, we've seen ACK numbers which are  
either 16 higher or 4 lower than the sequence number sent to the Cisco. On  
11.1, we've seen numbers 16 higher than they should be, and on 11.2,  
the numbers have been 24 lower than expected. The responses do not  
seem extremely consistent.  
- versions from 10.3 through 11.1, and possibly others, will continue  
to resend their SYN/ACK in response to an open-port SYN, even after receiving  
a valid RST from the machine sending the SYN. Usually, a total of  
4 SYN/ACKs are sent by the router.  
- Since sessions to routers are few and far between, most window sizes  
returned by Cisco equal the default size used by the IOS. On 10.3  
through 11.1, the window wize is 2144. On 11.2, it is 4288. IOS  
only returns a non-zero window size when making the transition from the  
TCP listen state to the SYN_RECVD state.  
  
-speck  
Basement Research  
  
`