Date: Mon, 18 Jan 1999 09:48:52 PST From: Mr. joej To: BUGTRAQ@netspace.org 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 To: BUGTRAQ@netspace.org 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 To: BUGTRAQ@netspace.org Subject: Re: Remote Cisco Identification (fwd) Context for cust-security-announce@cisco.com: 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 "security-alert@cisco.com". 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 To: BUGTRAQ@netspace.org 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 jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. -------------------------------------------------------------------------- Date: Wed, 20 Jan 1999 00:16:37 -0600 From: Basement Research To: BUGTRAQ@netspace.org 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