Hacking Exposed Cisco Networks: Cisco Security Secrets & Solutions

2017-07-07 02:10:07

Unless you have managed to capture CDP traffic, actively fingerprining the audited hosts is the next step to be performed and the last step in our enumeration and finger-printing attack stage. And even if you have gotten CDP frames dumped and analyzed , it is a good idea to check whether CDP provides full information about the device, using active scanning techniques (unless you are very concerned about stealth). A multitude of portscanners and OS fingerprinting tools are available to the hacking underground . The majority of them are based upon Fyodor's Nmap and Fyodor's/Ofir's Xprobe (note we are talking about two different Fyodor's here!). Many are not actively and regularly up-dated and would not have fingerprints of the current IOS, CatOS, and PIX OS versions, as well as more exotic specialized embedded Cisco operating systems, in the tool data-base. Thus, for this chapter, we are going to stick to Nmap and Xprobe versions 1 and 2. We will also review two different device configurationsdefault and with unnecessary ports closed. In the wild, you can encounter both cases as well as many configurations fitting somewhere between them. Rules of active host enumeration and fingerprinting were discussed in the "Loot and Pillage" chapter of our book Wi-Foo: The Secrets of Wire-less Hacking (Addison-Wesley, 2004). One rule states that reliable fingerprinting should be performed using several tools not derived from each other; here we use two. A deriva-tion from this rule is that it makes sense to run the same scan a few times to be sure that the output is correctin particular, when User Datagram Protocol (UDP) scans are run. As a hacker, you would not want to do this, since it is easy to spot. But we are the legiti-mate penetration testers, right?

In a physics, chemistry , or biology lab, an experiment must be repeated at least three times to produce statistically significant results. The representative scans in this section were selected from among many logged scans and are the most typical. Even more, in the case when the amount of hops between scanning and scanned hosts influences the output of the scan, the comparative scanning results are provided for your reference. You would be surprised how the precision of both finding open ports and fingerprinting the OS can be influenced by the hop distance from the audited host.

Another ruleor better to say, recommendation is to progress from NULL TCP scans (perhaps run Nmap in the "polite" mode) to FIN, then XMAS (with all TCP flags set), then SYN, and thenand only thenfull connect scanning and banner grabbing . At least theoretically, NULL TCP scans are the least detectable. For example, good old Linux ipchains do not have options to write NULL scan detection rules. FIN and especially XMAS scans look odd and are easier to detect. [Stealthy] half-connect SYN scans are now detected by anything and full-connect scans can be seen in syslog output when no spe-cific firewalling or intrusion detection system (IDS) tools are in use. So if a NULL scan detects interesting open ports, an attacker can proceed to grabbing the banner of the service he or she perceives as potentially vulnerable without triggering many alarms. However, this recommendation is very general. Would it apply to various Cisco net-working devices? It is well known that various versions of Microsoft Windows are not exactly standards-compliant and thus do not provide any useful output when respond-ing to NULL, FIN, and XMAS scans. Would it be a similar case with Cisco hosts? There is only one way to find out.

Active Enumeration and Fingerprinting of Cisco Routers

Attack

Popularity:	10
Simplicity:	6
Impact:	9
Risk Rating:	8

Since many system administrators are reluctant to upgrade their routers ("if it does the job, don't touch it") and scores of old routers with obsolete IOS versions reside on the Internet, our first target is a Cisco 2503 with a rather ancient "code train." NULL, FIN, and XMAS Nmap scans turned out to be useless when run against such machinehere's an example:

arhontus#nmap -sF -vvv 192.168.30.50 -O The FIN Scan took 23.37s to scan 1663 total ports. Warning: OS detection will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port Host 192.168.30.50 appears to be up ... good. All 1663 scanned ports on 192.168.30.50 are: closed Too many fingerprints match this host to give specific OS details

The same applies to both Window and ACK scans, often used to evaluate various firewalls/filtering rules. Thus, we proceed further with a half-connect scan and then verify its results with a full connect:

arhontus#nmap -sT -vvv 192.168.30.50 -O Interesting ports on 192.168.30.50: (The 1654 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 7/tcp open echo 9/tcp open discard 13/tcp open daytime 19/tcp open chargen 23/tcp open telnet 57/tcp open priv-term 79/tcp open finger 2001/tcp open dc 6001/tcp open X11:1 Device type: router Running: Cisco IOS 10.X11.X OS details: Cisco 2501/2504/4500 router with IOS Version 10.3(15) - 11.1(20) TCP Sequence Prediction: Class=random positive increments Difficulty=404 (Medium) TCP ISN Seq. Numbers: 8E6CB417 8E6E66C1 8E701890 8E71CE9F 8E7383A0 8E753868 IPID Sequence Generation: All zeros

Next, we omitted the SYN scan output since it was similar to the full-connect scan results and skipped the OS fingerprint details to save space. The scans correctly deter -mined the device type and the IOS version range. However, the actual router model was not found, even though it was a close shot:

cisco2503#show version Cisco Internetwork Operating System Software IOS (tm) 3000 Software (IGS-I-L), Version 11.0(8), RELEASE SOFTWARE (fc1) Copyright (c) 1986-1996 by cisco Systems, Inc. Compiled Sat 27-Apr-96 01:23 by vprasad Image text-base: 0x0301DE2C, data-base: 0x00001000

Note the "Medium" difficulty of TCP packets sequence prediction and "All zeros" in the IP Identification number (IPID) sequence generation. The latter is actually beneficial in terms of securityit shows that this router cannot be abused by so-called idle or "zom-bie" scans that are sometimes used by attackers to conceal their IP addresses when portscanning. Of course, in this example, we scan only for the default (for Nmap) range of ports. Checking the full range from port 0 to port 65535 would surely take some time, but it is absolutely necessary when proper penetration testing is performed. When run-ning Nmap against one of our Cisco 2503 with -p0-65535 options, we uncovered two unknown services running on ports 4001 and 6001. While poking at them with other tools, such as THC-Amap, and feeding custom output using Hobbit's Netcat to find out what these services could be is surely interesting, it goes beyond the aims of this chapter and is omitted.

The next step is to grab the banners of services discovered . Again, a great variety of banner grabbing and service investigation tools can be used, including the already men-tioned Amap, Vmap, Arb-scan, Banshee, BanCh.pl, grabbb, mothra, and so on. In fact, the recent versions of Nmap are quite good at performing this task using -sV , or even better, the -A switch.

To illustrate banner grabbing of Cisco hosts in a "standardized" way, we are going to use the Nmap -A scan. (Note: do not forget to set a sufficient level of verbosity for ex-ample, -vvv when running it!) The results of such a scan run against our Cisco 2503 did not provide us with any information we did not know already after completing the full-connect TCP scan for the whole 16-bit ports range.

How about UDP ports? Both default and full-port range scans have demonstrated the same result, as represented here:

arhontus#nmap -sU -vvv 192.168.30.50 -O -p0-65535 Interesting ports on 192.168.30.50: (The 1473 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 7/udp open echo 9/udp openfiltered discard 19/udp open chargen 67/udp openfiltered dhcpserver 161/udp openfiltered snmp Too many fingerprints match this host to give specific OS details

Despite the fact that some ports are shown as openfiltered in the scan output, all ports listed are open. While port 161 is open because we have enabled SNMP on purpose, the rest of the UDP ports shown are open by default. The scan was unable to fingerprint the OS version and device type correctly. Taking it a bit forward, when using other Cisco devices evaluated, UDP scanning was just as useless in defining both OS version and device type.

An interesting fact is that the show ip sockets command, which is supposed to provide complete information about ports open on a router, in reality shows only the UDP ports, and not all of them:

cisco2503#show ip sockets Proto Remote Port Local Port In Out Stat TTY 17 --listen-- --any-- 67 0 0 1 0 17 192.168.77.5 45481 192.168.30.50 161 0 0 1 0

Thus, we recommend that you do not rely on this command when checking both TCP and UDP open ports on your routers and portscan them several times to verify show ip sockets output.

Since many of the network attacks we describe in this book are based on a running insecure protocol rather than the presence of a vulnerable service on a host, the Nmap supported protocols scan ( -sO ) is crucial. Cisco 2503 responded to protocol scans rea-sonably well, even when the scanning machine was positioned a few hops away:

arhontus#nmap -sO -vvvv 192.168.30.50 -O Interesting protocols on 192.168.30.50: (The 242 protocols scanned but not shown below are in state: closed) PROTOCOL STATE SERVICE 1 openfiltered icmp 4 openfiltered ip 6 openfiltered tcp 8 openfiltered egp 9 openfiltered igp 17 openfiltered udp 47 openfiltered gre 53 openfiltered swipe 54 openfiltered narp 55 openfiltered mobile 77 openfiltered sun-nd 88 openfiltered eigrp 89 openfiltered ospfigp 94 openfiltered ipip Too many fingerprints match this host to give specific OS details

Just as in the case with UDP scanning, the output provided by the supported protocols scan is not sufficient to determine the running OS and device type.

Finally, we need to reinforce our OS fingerprinting results using Xprobe. The first version of the tool is rather simple, relies on ICMP and UDP data to determine the target OS, and hasn't been updated. Nevertheless, it is still worth trying:

arhontus# ./xprobe -v -p 31337 -i eth1 192.168.30.50 X probe ver. 0.0.2 ------------------ Interface: eth1/192.168.66.101 LOG: Target: 192.168.30.50 LOG: Netmask: 255.255.255.255 LOG: probing: 192.168.30.50 LOG: [send]-> UDP to 192.168.30.50:31337 LOG: [98 bytes] sent, waiting for response. TREE: IP total length field value is <20 bytes from the original TREE: *** OpenBSD 2.6-2.9, Apollo Domain/OS SR 10.4 NFR IDS Appliance TREE: *** Extreme Networks switch Network Systems Router NS6114 (NSC 6600 Series) TREE: *** Cabletron Systems SSR 8000 Systems Software Version 3.1 B16 FINAL:[NFR IDS Appliance]

Unfortunately, Xprobe v1 was not able to define the OS run by the router. However, Xprobe v2 performed reasonably well in all four types of the scan when supplied by one of the following options:

open TCP port arhontus#xprobe2 -v -c /etc/xprobe2.conf -p tcp:23:open 192.168.30.50 [+] Host 192.168.30.50 Running OS: "Cisco IOS 11.2" (Guess probability: 65%) [+] Other guesses: [+] Host 192.168.30.50 Running OS: "Cisco IOS 11.1" (Guess probability: 65%) [+] Host 192.168.30.50 Running OS: "Cisco IOS 12.2" (Guess probability: 59%) [+] Host 192.168.30.50 Running OS: "Cisco IOS 12.0" (Guess probability: 59%) [+] Host 192.168.30.50 Running OS: "Cisco IOS 11.3" (Guess probability: 59%) [+] Host 192.168.30.50 Running OS: "AIX 4.3.3" (Guess probability: 50%) closed TCP port arhontus#xprobe2 -v -c /etc/xprobe2.conf -p tcp:6667:closed 192.168.30.50 [+] Host 192.168.30.50 Running OS: "Cisco IOS 11.2" (Guess probability: 67%) [+] Other guesses: [+] Host 192.168.30.50 Running OS: "Cisco IOS 11.1" (Guess probability: 67%) [+] Host 192.168.30.50 Running OS: "NetBSD 1.4" (Guess probability: 64%) [+] Host 192.168.30.50 Running OS: "NetBSD 1.4.1" (Guess probability: 64%) [+] Host 192.168.30.50 Running OS: "NetBSD 1.4.2" (Guess probability: 64%) [+] Host 192.168.30.50 Running OS: "OpenBSD 2.5" (Guess probability: 64%) [+] Host 192.168.30.50 Running OS: "NetBSD 1.5.3" (Guess probability: 64%) [+] Host 192.168.30.50 Running OS: "NetBSD 1.4.3" (Guess probability: 64%) [+] Host 192.168.30.50 Running OS: "NetBSD 1.5" (Guess probability: 64%) [+] Host 192.168.30.50 Running OS: "Cisco IOS 11.3" (Guess probability: 64%) open UDP port arhontus#xprobe2 -v -c /etc/xprobe2.conf -p udp:7:open 192.168.30.50 [+] Host 192.168.30.50 Running OS: "Cisco IOS 12.2" (Guess probability: 40%) [+] Other guesses: [+] Host 192.168.30.50 Running OS: "Cisco IOS 12.0" (Guess probability: 40%) [+] Host 192.168.30.50 Running OS: "Cisco IOS 11.3" (Guess probability: 40%) [+] Host 192.168.30.50 Running OS: "Cisco IOS 11.2" (Guess probability: 40%) [+] Host 192.168.30.50 Running OS: "Cisco IOS 11.1" (Guess probability: 40%) [+] Host 192.168.30.50 Running OS: "Linux Kernel 2.4.1" (Guess probability: 37%) [+] Host 192.168.30.50 Running OS: "Linux Kernel 2.4.2" (Guess probability: 37%) [+] Host 192.168.30.50 Running OS: "Linux Kernel 2.4.4" (Guess probability: 37%) [+] Host 192.168.30.50 Running OS: "OpenBSD 2.4" (Guess probability: 37%) [+] Host 192.168.30.50 Running OS: "OpenBSD 2.5" (Guess probability: 37%) closed UDP port arhontus#xprobe2 -v -c /etc/xprobe2.conf -p udp:23:closed 192.168.30.50 [+] Host 192.168.30.50 Running OS: "Cisco IOS 12.2" (Guess probability: 40%) [+] Other guesses: [+] Host 192.168.30.50 Running OS: "Cisco IOS 12.0" (Guess probability: 40%) [+] Host 192.168.30.50 Running OS: "Cisco IOS 11.3" (Guess probability: 40%) [+] Host 192.168.30.50 Running OS: "Cisco IOS 11.2" (Guess probability: 40%) [+] Host 192.168.30.50 Running OS: "Cisco IOS 11.1" (Guess probability: 40%) [+] Host 192.168.30.50 Running OS: "Linux Kernel 2.4.1" (Guess probability: 37%) [+] Host 192.168.30.50 Running OS: "Linux Kernel 2.4.2" (Guess probability: 37%) [+] Host 192.168.30.50 Running OS: "Linux Kernel 2.4.4" (Guess probability: 37%) [+] Host 192.168.30.50 Running OS: "OpenBSD 2.4" (Guess probability: 37%) [+] Host 192.168.30.50 Running OS: "OpenBSD 2.5" (Guess probability: 37%)

Note	You need to run Nmap prior to using Xprobe v2 to find out which ports to use. Not surprisingly, scans using TCP ports were more precise as compared to scans using UDP ports, and scans supplied with open ports were more exact than those supplied with closed ports.

Now that we have established a pattern of device fingerprinting, it is much easier to follow it using different devices. The router we have looked at is an old model with an obsolete IOS version. Let's have a look at another common Cisco router with the most recent code train available at the moment of writing and compare it with the previous example.

NULL, FIN, and XMAS Scans These did not produce any useful output, just as in the case with 2503/IOS11.(0)8. The same applied to Window and ACK TCP scans.

Both Half-Connect and Full-Connect TCP Scans These showed open ports and other inter-esting data but were unable to determine device type and IOS version. An example of a half-connect scan is provided here:

arhontus#nmap -sS -vvv 192.168.66.202 -O Interesting ports on test.dmz.arhont.com (192.168.66.202): (The 1658 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 7/tcp open echo 9/tcp open discard 13/tcp open daytime 19/tcp open chargen 23/tcp open telnet MAC Address: 00:02:16:9C:0A:80 (Cisco Systems) No exact OS matches for host TCP Sequence Prediction: Class=truly random Difficulty=9999999 (Good luck!) TCP ISN Seq. Numbers: B4001FB9 16115BD4 B01365B8 AA1CEFE D7F33985 B454BF51 IPID Sequence Generation: All zeros

Grabbing Banners This was more fruitful:

arhontus#nmap -A -vvvv 192.168.66.202 -O -p0-65535 7/tcp open echo 9/tcp open discard? 13/tcp open daytime? 19/tcp open chargen 23/tcp open telnet Cisco telnetd (IOS 12.X) MAC Address: 00:02:16:9C:0A:80 (Cisco Systems) No exact OS matches for host TCP Sequence Prediction: Class=truly random Difficulty=9999999 (Good luck!) TCP ISN Seq. Numbers: C7A8FBC9 9766C8D0 1168F7A6 E9270C94 3CE65D8 170CF393 IPID Sequence Generation: All zeros

While the device and OS types weren't determined, from the telnetd banner we know that IOS 12. X is used. This banner is not user- changeable , and to get rid of it one would need to go through a procedure of modifying the IOS image. This can be considered a basic form of reverse-engineering and might be illegal, or at least it would void the war-ranty.

UDP Scans These showed fewer open ports than in the 2503 example and were also un-able to determine the OS:

arhontus#nmap -sU -vvvv 192.168.66.202 -O -p0-65535 Interesting ports on test.dmz.arhont.com (192.168.66.202): (The 1476 ports scanned but not shown below are in state: openfiltered) PORT STATE SERVICE 7/udp open echo 19/udp open chargen MAC Address: 00:02:16:9C:0A:80 (Cisco Systems) Too many fingerprints match this host to give specific OS details

Again, the output of the scan did not exactly correspond to the output of the show ip sockets command:

cisco-test#sh ip sockets Proto Remote Port Local Port In Out Stat TTY 17 0.0.0.0 0 192.168.66.202 67 0 0 2211 0 17 --listen-- 192.168.66.202 123 0 0 1 0 17 --listen-- 192.168.66.202 520 0 0 1 0 17 192.168.77.5 34635 192.168.254.254 161 0 0 1 0 17 --listen-- 192.168.66.202 162 0 0 11 0 17 --listen-- 192.168.66.202 56057 0 0 11 0

In this case, the tables have turned and the command is more informative than the Nmap. This is an interesting artifact demonstrating that UDP ports could be missed by Nmap, even if multiple scans are run against the host on the same subnet and the ports scanned are chosen separately. And we are dead sure that Routing Information Protocol (RIP), Network Time Protocol (NTP), and SNMP services are running on this router since we have enabled them all. Thus, output of any UDP scan should be taken with a bit of salt, even if you're sitting next to the scanned host on the same LAN.

Supported Protocols Scan This did not show any useful information.

Xprobe Scan This is now our main hope for finding out more about the host's OS. For now, all we know is that it runs some version of IOS 12. Xprobe v1 isn't very helpful, showing the same (incorrect) output as in the case with Cisco 2503. Xprobe v2 was far more useful, apart from the case of closed TCP port supplied:

arhontus#xprobe2 -v -c /etc/xprobe2.conf -p tcp:23:open 192.168.66.202 [+] Host 192.168.66.202 Running OS: "Cisco IOS 12.2" (Guess probability: 59%) [+] Other guesses: [+] Host 192.168.66.202 Running OS: "Cisco IOS 12.0" (Guess probability: 59%) [+] Host 192.168.66.202 Running OS: "Cisco IOS 11.3" (Guess probability: 59%) [+] Host 192.168.66.202 Running OS: "Cisco IOS 11.2" (Guess probability: 53%) [+] Host 192.168.66.202 Running OS: "Cisco IOS 11.1" (Guess probability: 53%) [+] Host 192.168.66.202 Running OS: "Sun Solaris 2.5.1" (Guess probability: 46%) [+] Host 192.168.66.202 Running OS: "FreeBSD 4.3" (Guess probability: 46%) [+] Host 192.168.66.202 Running OS: "Linux Kernel 2.4.0" (Guess probability: 46%) [+] Host 192.168.66.202 Running OS: "Linux Kernel 2.4.1" (Guess probability: 46%) [+] Host 192.168.66.202 Running OS: "Linux Kernel 2.4.2" (Guess probability: 46%) arhontus#xprobe2 -v -c /etc/xprobe2.conf -p udp:7:open 192.168.66.202 +] Host 192.168.66.202 Running OS: "Cisco IOS 12.2" (Guess probability: 40%) [+] Other guesses: [+] Host 192.168.66.202 Running OS: "Cisco IOS 12.0" (Guess probability: 40%) [+] Host 192.168.66.202 Running OS: "Cisco IOS 11.3" (Guess probability: 40%) [+] Host 192.168.66.202 Running OS: "Cisco IOS 11.2" (Guess probability: 40%) [+] Host 192.168.66.202 Running OS: "Cisco IOS 11.1" (Guess probability: 40%) [+] Host 192.168.66.202 Running OS: "Linux Kernel 2.4.1" (Guess probability: 37%) [+] Host 192.168.66.202 Running OS: "Linux Kernel 2.4.2" (Guess probability: 37%) [+] Host 192.168.66.202 Running OS: "Linux Kernel 2.4.4" (Guess probability: 37%) [+] Host 192.168.66.202 Running OS: "OpenBSD 2.4" (Guess probability: 37%) [+] Host 192.168.66.202 Running OS: "OpenBSD 2.5" (Guess probability: 37%)

TCP Scan This scan was somewhat more precisenote the difference between the guess probability percentages of both scans. As to the closed-port Xprobe probes ( please for-give the tautology), the guesses split between Solaris and FreeBSD (closed TCP port) and various versions of Linux kernel (closed UDP port). The probability percentages were much lower than in the open-port scans and ranged between 21 and 25 percent. Thus, at the end, we can state that we are dealing with some Cisco device running IOS 12.2. It could be a router, an IOS-like system Catalyst switch, or even an IOS-based Aironet wire-less access point. Now comes the correct answer:

cisco-test#show version Cisco Internetwork Operating System Software IOS (tm) C2600 Software (C2600-IK9O3S3-M), Version 12.3(6), RELEASE SOFTWARE (fc3) Copyright (c) 1986-2004 by cisco Systems, Inc. Compiled Wed 11-Feb-04 19:24 by kellythw Image text-base: 0x80008098, data-base: 0x81999EC0 ROM: System Bootstrap, Version 11.3(2)XA4, RELEASE SOFTWARE (fc1)

As you can see, it was substantially more difficult to fingerprint this particular host as compared to the example with Cisco 2503 and old IOS.

Active Enumeration and Fingerprinting of Catalyst Switches

Attack

Popularity:	10
Simplicity:	6
Impact:	9
Risk Rating:	8

Of course, the second most commonly encountered types of Cisco devices on the Internet are Catalyst switches. As you probably know, they come in two flavorsIOS-like OS Catalysts and CatOS-based Catalysts, which have different roots. IOS is the original Cisco-developed operational system. CatOS has evolved out of the XDI, a UNIX-like kernel acquired by Cisco for use in equipment that developed into the mod-ern Catalyst 4000, 5000, and 6000 switch series. Thus, one would correctly expect the CatOS switches to behave quite differently from the IOS-based machines when finger-printed.

When scanning CatOS-based Catalysts, the first thing that stands out is the informa-tive response to NULL, FIN, and XMAS scans, which is identical for all three scan types. Thus, the discovery and portscanning of CatOS switches can be accomplished in a some-what quieter manner as compared to IOS-based machines. (Well, at least we are quite sure that NULL and FIN scans will not show up in the Catalyst logs!) An example of a NULL scan run against such a switch is presented here:

arhontus#nmap -sN -vvv 192.168.77.250 -O Interesting ports on gromozeka.core.arhont.com (192.168.77.250): (The 1662 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 23/tcp open telnet MAC Address: 00:40:0B:C7:13:FF (Cisco Systems) Device type: switchprinterfirewallrouter Running: Cisco embedded, Xylan embedded, Epson embedded, SonicWall SonicOS, Trancell embedded OS details: Router/Switch/Printer/Firewall (LanPlex 2500/Cisco Catalyst 5505/Cisco 6509/Trancell Webramp/Xylan OmniSwitch)/Epson Stylus (100BTX-NIC HP Secure Web Console, SonicWall firewall appliance 3.3.1) TCP Sequence Prediction: Class=64K rule Difficulty=1 (Trivial joke) TCP ISN Seq. Numbers: 81AB7C01 81AC7601 81AD7001 81AF6401 81B05E01 81B15801 IPID Sequence Generation: Incremental

In addition to finding the open telnetd port, the scan has also determined the high vul-nerability of the switch to session-hijacking attacks (predictable TCP sequence numbers) and its usefulness for idle scanning.

Tip	To find out how to use idle scanning techniques to hide your IP, consult the http://www.insecure.org site at http://www.insecure.org/nmap/idlescan.html.

It is quite obvious that the same output was obtained employing SYN and full-con-nect TCP scans. Also, an additional unknown open TCP service port 7161 was found when running full port range scans against the tested switch. Grabbing banners by launching Nmap with the -A option did not produce any exciting results, apart from the xff\xfb\x01\xff\xfb\x03\xff\xfd\x01\r\n\r\nCisco\x20Systems\x20Console\ string appearing in the fingerprint.

Unlike previously tested routers, a Window scan ( -sW flag in Nmap) targeting the Catalyst was successful in showing output that was identical to the results of NULL, FIN, and XMAS probes. However, any time an ACK scan was run against the switch from different hosts, it was unexpectedly terminated with a characteristic error:

arhontus# nmap -sA -vvvv 192.168.77.250 -O Starting nmap 3.75 (http://www.insecure.org/nmap/) at 2004-12-01 04:46 GMT Initiating ACK Scan against gromozeka.core.arhont.com (192.168.77.250) 1663 ports] at 04:46 Unexpected port state: 6 QUITTING!

UDP scanning of a CatOS-based switch for default and full port ranges has demon-strated open 123 (NTP) and 161 (SNMP) ports and did not provide any specific OS details. There is no show ip sockets command in CatOS to verify the results of UDP scans on the switch.

Finally, the supported protocols scan against the Catalyst flagged all 256 checked protocols as openfiltered and wasn't useful at all.

While Nmap has provided us a wealth of information about the switch, as you can see in the preceding code, the same cannot be said about both versions of Xprobe. While Xprobe v1 defined our Catalyst as DGUX/HPUX 10.x/OpenVMS with Process Software TCPWare!SunOS4.x , Xprobe v2 considered it to be a FreeBSD 4.4 machine.

To summarize, some characteristics stand out like big flashing neon lights when fin-gerprinting many CatOS switches:

Responsiveness to FIN, NULL, XMAS, and Window TCP scans

Error and termination of ACK scans

TCP sequence numbers prediction class and difficulty

Incremental IPIDs

Reliably defined as FreeBSD 4.4 by the current version of Xprobe 2 used

As to our specific example switch, based on the results of scans, we could tell that it is a Cisco Catalyst switch 5505 or 6509. We couldn't define the specific version of CatOS in use. Here's the correct answer:

Gromozeka (enable) show version WS-C5000 Software, Version McpSW: 4.5(12a) NmpSW: 4.5(12a) Copyright (c) 1995-2002 by Cisco Systems NMP S/W compiled on Feb 11 2002, 15:03:47 MCP S/W compiled on Feb 11 2002, 15:06:09 System Bootstrap Version: 1.4 Hardware Version: 1.8 Model: WS-C5000 Serial #: 002660741

So, the answer Cisco Catalyst 5505 was close enough, but still incorrect.

Let's now compare IOS-based Catalyst fingerprinting results with both Cisco routers and CatOS switches. Running NULL, FIN, and SYN scans against an IOS-based Catalyst switch rendered rather strange results, showing all ports as open. The OS fingerprint of all three scan types was uniform:

Device type: general purposeprinterrouterVoIP adapterbroadband routerWAP Running (JUST GUESSING) : Linux 1.X (93%), Tektronix embedded (93%), Apple Mac OS X 10.1.X (90%), Microsoft Windows NT/2K/XP (90%), Cisco embedded (90%), FreeSCO Linux 2.0.X (87%), Cisco IOS 12.X (87%) Aggressive OS guesses: Linux 1.3.20 (x86) (93%), Tektronix Phaser printer (93%), Apple Mac OS X 10.1.5 (90%), Microsoft Windows XP Pro SP1 or Windows 2000 SP3 (90%), Cisco X.25/TCP/LAT Protocol Translator ver 8.2(4) (90%), Cisco ATA 186 POTS<->VoIP phone gateway device (88%), FreeSCO 0.27 (Linux 2.0.38) (87%), Microsoft Windows XP Pro RC1+ through final release (87%), Cisco Soho 97 router running IOS 12.3(8) (87%), Cisco 7200 router running IOS 12.1(14)E6 (87%) No exact OS matches for host (test conditions non-ideal).

Investigating this artifact further, we conclude that the scan output was dependent on the amount of hops separating the host with Nmap from the Catalyst. At three and two hops' distance, all ports were shown as open; however, when scanned from the same subnet, all ports appeared to be closed, which corresponds quite well to the re-sponse of Cisco routers to NULL, FIN, and XMAS scanning. Alas, NULL, FIN, and XMAS scans of these routers did not produce any OS guesses at all. (Not that the guesses for our Catalyst shown previously were precise and useful!)

The NULL/FIN/XMAS OS fingerprints and guesses for the tested switch did not change with different amounts of hops between it and the scanning machine. The same cannot be said about the case of half-and full-connect scans, however.

Two hops away:

arhontus#nmap -sS -vvv -O 192.168.20.254 Interesting ports on 192.168.20.254: (The 1658 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 7/tcp open echo 9/tcp open discard 13/tcp open daytime 19/tcp open chargen 23/tcp open telnet No exact OS matches for host TCP Sequence Prediction: Class=truly random Difficulty=9999999 (Good luck!) TCP ISN Seq. Numbers: A99EFC4B 47B64308 3569CEAD 2204C2C1 DB1C606F FC1101E1 IPID Sequence Generation: All zeros

One hop away:

Interesting ports on 192.168.20.254: (The 1658 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 7/tcp open echo 9/tcp open discard 13/tcp open daytime 19/tcp open chargen 23/tcp open telnet Device type: router Running: Cisco IOS 12.X OS details: Cisco 7200 router running IOS 12.1(14)E6 TCP Sequence Prediction: Class=truly random Difficulty=9999999 (Good luck!) TCP ISN Seq. Numbers: A4C1F3F8 49892BF3 6426CB1E A69DB9F2 AEDC5A5D BD1CFC3D IPID Sequence Generation: All zeros

Same subnet:

Interesting ports on 192.168.20.254: (The 1658 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 7/tcp open echo 9/tcp open discard 13/tcp open daytime 19/tcp open chargen 23/tcp open telnet MAC Address: 00:0E:84:EF:F5:C0 (Cisco Systems) Device type: router Running: Cisco IOS 12.X OS details: Cisco router running IOS 12.1.5-12.2.13a TCP Sequence Prediction: Class=truly random Difficulty=9999999 (Good luck!) TCP ISN Seq. Numbers: A4C1F3F8 49892BF3 6426CB1E A69DB9F2 AEDC5A5D BD1CFC3D IPID Sequence Generation: All zeros

The precision of the scans increased dramatically as we got closer to the target. Note that in all cases, the device type was defined as router this is something we have con-stantly seen when fingerprinting IOS-based Catalysts.

The dependence of scan results on the amount of separating hops was not limited to the IOS-based Catalyst or Catalyst switches in general. We have seen perhaps the most outstanding example of this phenomenon when UDP scanning a Cisco 2503 router.

One hop away:

arhontus# nmap -sU -vvvv 192.168.30.50 -O Interesting ports on 192.168.30.50: (The 1473 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 67/udp openfiltered dhcpserver 161/udp openfiltered snmp 781/udp openfiltered hp-collector 835/udp openfiltered unknown 2042/udp openfiltered isis Too many fingerprints match this host to give specific OS details

Same subnet:

arhontus# nmap -sU -vvvv 192.168.30.50 -O Interesting ports on 192.168.30.50: (The 1475 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 67/udp openfiltered dhcpserver 161/udp openfiltered snmp 1407/udp openfiltered dbsa-lm Device type: routerswitch Running: Cisco IOS 10.X11.X OS details: Cisco 2501/2504/4500 router with IOS Version 10.3(15) - 11.1(20), Cisco Router/Switch with IOS 11.2

As you can see, while the remote UDP scans (including the UDP scan from two hops' distance shown when we were evaluating Cisco 2503 fingerprinting) could not deter-mine device type and OS version; when Nmap is run on the same LAN it is possible to fingerprint the device with a reasonable level of precision.

Let's return to our IOS-based Catalyst switch. Grabbing banners with Nmap -A has also demonstrated the Cisco telnetd (IOS 12.X) banner, commonly encountered in differ -ent types of Cisco switches. Interestingly, as in the case of the CatOS-based switch tested, the ACK scans were terminated with the very same error ( Unexpected port state: 6 ). Window TCP scans were fruitless. The UDP scans have demonstrated a variety of open services, two of them unknown:

arhontus#nmap -sU -vvvv -O 192.168.20.254 -p0-65535 Interesting ports on 192.168.20.254: (The 1469 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 7/udp open echo 9/udp openfiltered discard 19/udp open chargen 67/udp openfiltered dhcpserver 146/udp openfiltered iso-tp0 161/udp openfiltered snmp 162/udp openfiltered snmptrap 793/udp openfiltered unknown 948/udp openfiltered unknown MAC Address: 00:0E:84:EF:F5:C0 (Cisco Systems) Too many fingerprints match this host to give specific OS details

Again, the output of the scan did not correspond well to the output of the show ip sockets command:

molotov#sh ip sockets Proto Remote Port Local Port In Out Stat TTY 17 --listen-- 192.168.20.254 67 0 0 489 0 17 --listen-- 192.168.20.254 2228 0 0 89 0 17 192.168.20.100 38085 192.168.20.254 161 0 0 1 0 17 0.0.0.0 0 192.168.20.254 162 0 0 9 0 17 0.0.0.0 0 192.168.20.254 52349 0 0 9 0

Even when launched from the same LAN, UDP portscans were not able to provide any guesses regarding the OS running. The supported protocols scan run against the tested switch worked fine:

arhontus#nmap -sO -vvvv -O 192.168.20.254 Interesting protocols on 192.168.20.254: (The 250 protocols scanned but not shown below are in state: closed) PROTOCOL STATE SERVICE 1 openfiltered icmp 6 openfiltered tcp 17 openfiltered udp 53 openfiltered swipe 55 openfiltered mobile 77 openfiltered sun-nd MAC Address: 00:0E:84:EF:F5:C0 (Cisco Systems) Too many fingerprints match this host to give specific OS details

Finally, Xprobe v1 determined the switch OS to be Cisco IOS 11.x-12.x , while Xprobe v2 reliably indicated Cisco IOS 12.2 with a guess probability up to 91 percent when sup-plied with an open TCP port.

To summarize, the following properties may give away IOS-based Catalyst switches and distinguish them from Cisco routers:

The presence of a fingerprint, but no open/closed ports in NULL, FIN, and XMAS scans

ACK scans terminating with an error

Xprobe v1 producing a meaningful result

Supported protocols scan working and not showing Generic Routing Encapsulation (GRE) and routing protocols

Not surprisingly, there were significant differences between scanning and finger-printing results of IOS- and CatOS-based Catalyst switches, making these device classes easily distinguishable from each other by remote attackers. While we could determine the IOS version of the tested switch with a reasonable precision, it was not possible to determine the switch type. Of course, now it is time to provide the correct answer:

molotov#show version Cisco Internetwork Operating System Software IOS (tm) C2950 Software (C2950-I6Q4L2-M), Version 12.1(22)EA1, RELEASE SOFTWARE (fc1) System image file is "flash:c2950-i6q4l2-mz.121-22.EA1.bin" cisco WS-C2950T-24 (RC32300) processor (revision M0) with 20873K bytes of memory.

Active Enumeration and Fingerprinting of Other Cisco Appliances

Attack

Popularity:	10
Simplicity:	6
Impact:	9
Risk Rating:	8

Considering the variety of networking devices manufactured by Cisco, limiting this chapter only to routers and switches would have been an unforgivable mistake. Thus, it is time to turn to more specific Cisco appliances commonly encountered on modern-day networks, emphasizing the security relevance of such hosts. One such appliance type is, of course, Cisco PIX firewalls. Apart from the low-end 501/506 models (the latter being deprecated), PIX firewalls usually possess three interface types: private, public, and DMZ. For the purposes of this chapter, we are interested in scanning from the public interface side, since this is where the external attackers are positioned. For the purposes of a complete security audit, a firewall should be assessed from all of its interfaces, since internal malcontents can be as large a threat and servers in the DMZ can be broken into by external hackers and used to launch further attacks.

When enumerating and fingerprinting a PIX firewall, we follow the standard scheme used in the preceding examples. The firewall we are using has port 22 open to the out-side. This is not a default configuration, but it is not uncommon in the wild, and we wanted to demonstrate the difference a service exposed to the public side can make when fingerprinting a PIX.

NULL, FIN, and XMAS scans have shown all ports as open and did not provide any OS guesses.

SYN and full-connect scans could demonstrate only the Secure Shell Daemon (SSHd) running. The OS guesses were rather informative, thoughsee the example scan output in the next paragraph.

Grabbing banners was even more interesting:

arhontus# nmap -A -O -vvvv 192.168.66.108 Interesting ports on 192.168.66.108: (The 1662 ports scanned but not shown below are in state: filtered) PORT STATE SERVICE VERSION 22/tcp open ssh Cisco SSH 1.25 (protocol 1.5) MAC Address: 00:90:27:99:11:8F (Intel) Device type: switchfirewall Running: Cisco embedded, Cisco NmpSW, Cisco PIX 6.X OS details: Cisco Catalyst switch, Cisco Catalyst 4006 Switch running NmpSW 7.4(2), Cisco PIX Firewall Version 6.1(2), Cisco PIX Firewall Version 6.2(1) TCP Sequence Prediction: Class=truly random Difficulty=9999999 (Good luck!) TCP ISN Seq. Numbers: AC8CE25B F2C1853D 713E4DBB 821E3731 5C9EBFB0 6FF1F11E IPID Sequence Generation: Incremental

The banner showing both the Cisco origin of the device and the version of SSHd and SSH protocol running just shouldn't be there, especially if you take into account the vul-nerability of SSH protocol versions below 2 to man-in-the-middle attacks. Also, the incremental IPID sequence generation (idle scans!) and Intel Organizationally Unique Identifier (OUI) MAC address are shown when scanning on LAN. The latter fact is de-monstrative for PIX firewalls using Intel, rather than native Cisco Ethernet network cards or interfaces.

Window, ACK, and supported protocol scans did not provide any useful output. All UDP ports were shown as filtered.

Both versions of Xprobe have identified our firewall's OS as some version of Linux kernel 2.2.X.

Despite the absence of useful data brought in by Xprobe and all scans, apart from SYN and full connect, we were able to identify the host as a likely PIX firewall running PIX OS 6.1.(2)-6.2.(1). Catalyst switches are not very likely to run SSHd (though it is pos-sible!) and would show a different fingerprinting profile to Nmap and Xprobe, as demonstrated by the examples reviewed already. To avoid breaking the tradition, here comes a correct description of the tested PIX:

pixfirewall# show version Cisco PIX Firewall Version 6.3(3) Cisco PIX Device Manager Version 3.0(1) Compiled on Wed 13-Aug-03 13:55 by morlee pixfirewall up 132 days 4 hours Hardware: PIX-515E, 64 MB RAM, CPU Pentium II 433 MHz Flash E28F128J3 @ 0x300, 16MB BIOS Flash AM29F400B @ 0xfffd8000, 32KB

Cisco VPN concentrator is next in our logical sequence of evaluated devices. As with the PIX, the 3000 series Cisco VPN concentrators have public, private, and DMZ inter-faces (apart from the low-end models in the 3015 series). And as in the PIX firewall case, we are more interested in scanning from the exposed public side and follow the same enumeration/fingerprinting plan.

NULL, FIN, and XMAS scans have shown all ports as open or closed, depending on the amount of hops from the concentrator, and did not provide any OS guesses.

Half-and full-connect TCP scans have only demonstrated the Point-to-Point Tunneling Protocol (PPTP) port open:

arhontus# nmap -sT -O -vvv -p0-65535 192.168.77.240 Interesting ports on 192.168.77.240: (The 65535 ports scanned but not shown below are in state: filtered) PORT STATE SERVICE 1723/tcp open pptp MAC Address: 00:03:A0:8A:00:F9 (Cisco Systems) Device type: encryption accelerator Running: Cisco embedded OS details: Cisco 3000-series VPN concentrator (OS ver 4.1.2) TCP Sequence Prediction: Class=random positive increments Difficulty=1543284 (Good luck!) TCP ISN Seq. Numbers: 9A4442DD 99D1DDAF 99EF863F 99ED7B73 9A0328ED 9A70FF87 IPID Sequence Generation: Incremental

Nevertheless, the OS fingerprinting results were rather precise (also note the incre-mental IPID sequence generation). For the sake of comparison, here is the scan of the same concentrator (also in default configuration) from the private interface side:

arhontus# nmap -A -vvv -p0-65535 192.168.77.240 Interesting ports on 192.168.77.240: (The 65526 ports scanned but not shown below are in state: closed) PORT STATE SERVICE VERSION 21/tcp open ftp? 22/tcp open ssh Cisco VPN Concentrator SSHd (protocol 1.5) 23/tcp open echo 80/tcp open http? 443/tcp open ssl/unknown 988/tcp open smtp 993/tcp open ssl/unknown 995/tcp open ssl/pop3 1723/tcp open pptp? 5054/tcp open unknown MAC Address: 00:03:A0:8A:00:F8 (Cisco Systems) Device type: encryption accelerator Running: Cisco embedded OS details: Cisco 3000-series VPN concentrator (OS ver 4.1.2) TCP Sequence Prediction: Class=random positive increments Difficulty=3689871 (Good luck!) TCP ISN Seq. Numbers: C59F2D9D C4D1C499 C56369F7 C589CD49 C4E9FAB6 C552B034 IPID Sequence Generation: Incremental

Do you really trust all users and all hosts on your LAN?

The only banner, grabbed on the private side, is shown on the preceding scan output. In our humble opinion, naming the device and the SSH protocol version in a banner is not a good security practice. But things get worse when we look at the SSHd in more detail:

arhontus# ssh -v admin@192.168.66.240 debug1: Connecting to 192.168.66.240 [192.168.66.240] port 22. debug1: Connection established. debug1: identity file /root/.ssh/id_dsa type -1 debug1: Remote protocol version 1.5, remote software version X debug1: no match: X debug1: Local version string SSH-1.5-OpenSSH_3.8.1p1 debug1: Waiting for server public key. Warning: Server lies about size of server public key: actual size is 767 bits vs. announced 768. Warning: This may be due to an old implementation of ssh. Warning: Server lies about size of server host key: actual size is 2047 bits vs. announced 2048. Warning: This may be due to an old implementation of ssh. debug1: Received server public key (767 bits) and host key (2047 bits). debug1: Host '192.168.66.240' is known and matches the RSA1 host key. debug1: Found key in /root/.ssh/known_hosts:11 debug1: Encryption type: 3des debug1: Sent encrypted session key. debug1: Installing crc compensation attack detector. debug1: Received encrypted confirmation. debug1: Doing password authentication.

In contrast, a Linux SSHd with enabled version 1 SSH protocol support will show something like this:

debug1: Connecting to dyno [192.168.77.6] port 22. debug1: Connection established. debug1: identity file /root/.ssh/identity type -1 debug1: identity file /root/.ssh/id_rsa type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: Remote protocol version 1.5, remote software version OpenSSH_3.8.1p1 debug1: match: OpenSSH_3.8.1p1 pat OpenSSH* debug1: Local version string SSH-1.5-OpenSSH_3.8.1p1 Debian-8.sarge.4 debug1: Waiting for server public key. debug1: Received server public key (768 bits) and host key (1024 bits). debug1: Host 'dyno' is known and matches the RSA1 host key. debug1: Found key in /root/.ssh/known_hosts:9 debug1: Encryption type: 3des debug1: Sent encrypted session key. debug1: Installing crc compensation attack detector. debug1: Received encrypted confirmation. debug1: Doing challenge response authentication. Password: Response: debug1: Requesting pty. debug1: Requesting X11 forwarding with authentication spoofing. Warning: Remote host denied X11 forwarding. debug1: Requesting shell. debug1: Entering interactive session.

Thus, SSH connections with debug option turned on for the client can be a reliable way of identifying remote Cisco VPN concentrators and other Cisco appliances supporting the SSH protocol. Pay close attention to all the warnings in the debug, key sizes, remote software ver-sion, and all output related to the X server.

So far, this is the first Cisco appliance evaluated against which the ACK scan has worked, showing the unfiltered PPTP port. However, the OS guessing that accompanied our ACK scan wasn't correct:

arhontus# nmap -sA -O -vvvv 192.168.77.240 Interesting ports on 192.168.77.240: (The 1662 ports scanned but not shown below are in state: filtered) PORT STATE SERVICE 1723/tcp UNfiltered pptp MAC Address: 00:03:A0:8A:00:F9 (Cisco Systems) Device type: broadband routergeneral purposefirewall Running (JUST GUESSING): Elsa embedded (85%), HP HP-UX 10.X (85%), Secure Computing embedded (85%) Aggressive OS guesses: ELSA LANCOM DSL/10 office router (85%), HP-UX B.10.20 9000/897 (85%), Secure Computing SECUREZone Firewall Version 2.0 (85%)

To the contrary, the Window scan has shown port 1723 as closed, while providing exactly the same OS guesses as the ACK scan. At the same time, UDP scans indicated that all UDP ports are openfiltered without providing any OS guesses or even basic fin-gerprints. It appears that all UDP packets sent by Nmap were dropped. The supported protocols scan wasn't very fruitful either, showing all 256 checked protocols as enabled and running.

Both versions of Xprobe incorrectly determined the OS of our concentrator as either FreeBSD 4.6 or HP UX 11.0 with low guess probability percentage.

And now for the usual summary. SYN and full-connect TCP scans with a fingerprint-ing ( -O ) option turned out to be quite good at enumerating the test Cisco VPN concentrator (besides not many Internet hosts have a single PPTP TCP port open). In ad-dition, the pattern of response to ACK and Window scans was rather unusual and different from the output we saw when auditing other Cisco appliances. We conclude that the remote discovery of Cisco 3000 VPN concentrators is not a difficult and daunting task. As for the real version of our concentrator's OS at the time of testing, it is vpn3000-4.1.7b-k9.bin. So the Nmap OS guess wasn't 100 percent correct. (Well, nothing in this world is perfect.)

While on that note we could have ended this section, we just love wireless too much! Would a Cisco Aironet access point (AP) running IOS differ from routers and IOS-based Catalyst switches? Just as in the Cisco router's case, NULL, FIN, and XMAS scans launched against our AP did not bear any useful information. SYN and half-connect scans disclosed telnetd (open by default) and HTTPd (opened by us to monitor the AP). As an example here, we provide Nmap -A scan output, which shows open ports, ban-ners, OS guesses, and other useful data disclosed by the wonderful Fyodor tool:

arhontus# nmap -A -vvv 192.168.77.235 Interesting ports on 192.168.77.235: (The 1661 ports scanned but not shown below are in state: closed) PORT STATE SERVICE VERSION 23/tcp open telnet Cisco telnetd (IOS 12.X) 80/tcp open http Cisco IOS administrative webserver MAC Address: 00:0D:BD:A7:13:BB (Cisco Systems) Device type: router Running: Cisco IOS 12.X OS details: Cisco 801/1720 router running IOS 12.2.8 TCP Sequence Prediction: Class=truly random Difficulty=9999999 (Good luck!) TCP ISN Seq. Numbers: F639ED85 A38FAB91 EB6F734C CF2E5AAF CCFB3D4E E638F829 IPID Sequence Generation: All zeros

Indeed, this looks like a Cisco router, with a telnetd banner being the same as the one observed when scanning Cisco 2611 router and Catalyst 2950 switch. Just as though we were scanning a router, Window and ACK scans weren't informative. However, UDP scans demonstrated that ports are open on the Aironet access point that are not open on a typical Cisco routernamely, old RADIUS and RADIUS accounting services:

arhontus## nmap -sU -O -vvvv 192.168.77.235 Interesting ports on 192.168.77.235: (The 1472 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 67/udp openfiltered dhcpserver 123/udp openfiltered ntp 161/udp openfiltered snmp 162/udp openfiltered snmptrap 1645/udp openfiltered radius 1646/udp openfiltered radacct

It deserves to be said that this data does not correspond to the show ip sockets command output:

ap#sh ip sockets Proto Remote Port Local Port In Out Stat TTY 17 --listen-- 192.168.77.235 123 0 0 1 0 17 0.0.0.0 0 192.168.77.235 67 0 0 489 0 17 --listen-- 192.168.77.235 2887 0 0 9 0 17 192.168.77.5 47638 192.168.77.235 161 0 0 1 0 17 --listen-- 192.168.77.235 162 0 0 1 0 17 --listen-- 192.168.77.235 55001 0 0 1 0

Apart from different open UDP ports, the protocols scan ( nmap -sO ) of the AP has discovered support for "unknown protocol 159" from the unassigned 92254 protocol number range (RFC 1060) that was not seen while scanning Cisco routers. In addition, Xprobe v1, which could not correctly determine the OS of both 2503 and 2611 Cisco routers in the examples we previously used, worked fine when fingerprinting the Ai-ronet AP:

arhontus# xprobe -v -p 31337 -i eth0 192.168.77.235 X probe ver. 0.0.2 ------------------ Interface: eth0/192.168.77.5 LOG: Target: 192.168.77.235 LOG: Netmask: 255.255.255.255 LOG: probing: 192.168.77.235 LOG: [send]-> UDP to 192.168.77.235:31337 LOG: [98 bytes] sent, waiting for response. TREE: Cisco IOS 11.x-12.x! Extreme Network Switches.Linux 2.0.x!2.2.x!2.4.x.TREE: Cisco IOS 11.x-12x! Extreme Network Switches. FINAL:[ Cisco IOS 11.x-12.x ]

As to the second version of Xprobe, it defined the AP IOS as 12.2 in all cases apart from the closed TCP port probe (in which case the OS was defined as HP-UX 11.0i). This is similar to probing a Cisco 2611 router. Thus, it is quite difficult to distinguish a Cisco Ai-ronet AP from a Cisco router remotely, but some subtle differences may still allow it. These differences pertain to open UDP ports (but as you have seen, UDP portscans aren't incred-ibly reliable), supported protocols scan, and Xprobe v1 output. Our tools of the trade have defined the AP OS as some version of IOS 12.2, perhaps 12.2.8. This is a close shot:

ap#show version Cisco Internetwork Operating System Software IOS (tm) C1200 Software (C1200-K9W7-M), Version 12.2(11)JA3, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2004 by cisco Systems, Inc. Compiled Mon 12-Apr-04 14:36 by kellmill Image text-base: 0x00003000, data-base: 0x004D4834 ROM: Bootstrap program is C1200 boot loader BOOTLDR: C1200 Boot Loader (C1200-BOOT-M) Version 12.2(8)JA, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1) cisco AIR-AP1220-IOS-UPGRD (PowerPC405GP) processor with 14326K/2048K bytes of memory. Processor board ID FHK0741K0DH PowerPC405GP CPU at 196Mhz, revision number 0x00C4 Last reset from power-on Bridging software. 1 FastEthernet/IEEE 802.3 interface(s) 1 802.11 Radio(s)

Using IOS 11.X Memory Leak to Enumerate Remote Cisco Routers

Attack

Popularity:	8
Simplicity:	8
Impact:	9
Risk Rating:	8

If you have discovered a router with open UDP port 7 (ECHO) and some version of IOS 11, it's your lucky day. IOS 11 has a memory leak that allows remote dumping of data from router interface buffer queues. Unfortunately for the attacker, it is not possible to dump the data constantly; here we are dealing with getting the discrete chunks of data about 20K in size.

The tool to exploit the leak is written by FX and is called IOSniff. It decodes received packets and keeps packet checksums in a cache to prevent repeating output. One of our testing routers provides a perfect target for IOSniff:

arhontus#iosniff -i eth0 -d 192.168.30.50 -v Cache hit Added packet buffer with next = 0x0013D308 and cs = 0x2CFB Packet, 1680 bytes of potatial data: [0x0013D308]: FF:03:00:21:45:C0 -> 00:00:00:00:00:00 pure Ethernet stuff ...Y.F...........0..B............................(.......... .d............are .IOS (tm) C2600 Software (C2600-IK9O3S3-M) , Version 12.3(6), RELEASE SOFTWARE (fc3).Copyright (c) 1986 -2004 by cisco Systems, Inc..Compiled Wed 11-Feb-04 19:24 by kellythw....cisco 2611.....................Serial0/0....... .qqqqqqqqqqqqqqqqqqqqqndication LSA 1...Number of DoNotAge L SA 0...Flood list length 0.. Area 0.0.0.1...Number of int erfaces in this area is 1...Area has no authentication...SPF algorithm last executed 3w1d ago...SPF algorithm executed 1 3 times...Area ranges are...Number of LSA 11. Checksum. Added packet buffer with next = 0x0013608C and cs = 0xDBED Packet, 1680 bytes of potatial data: [0x0013608C]: FF:03:00:21:45:00 -> 00:00:00:00:00:00 pure Ethernet stuff @.>.i...Be...2..#)r.EW...P........Z.......6.,........... .:................4.............(CONNECT_DATA=(COMMAND=versi on))rsion 12.3(6), RELEASE SOFTWARE (fc3).Copyright (c) 1986 -2004 by cisco Systems, Inc..Compiled Wed 11-Feb-04 19:24 by kellythw....cisco 2611.....................Serial0/0....... .bbbbbbbbbbbbbbbbbbbbb0/1..R 192.168.11.0/24 [120/1] via 192.168.66.100, 00:00:12, Ethernet0/0..R 192.168.20.0/24 [120/1] via 192.168.66.100, 00:00:12, Ethernet0/0.. 192. 168.66.0/24 is variably subnetted, 3 subnets, 2 masks..R 192.168.66.9/32 [120/1] via 192.168.66.100, 00:00:1......

Of course, what you are likely to see are the PDUs most frequently sent and received by the attacked router. These may include Cisco Discovery Protocol (CDP), Hot Standby Router Protocol (HSRP), or Virtual Router Resilience Protocol (VRRP), and various rout-ing protocol updates and hellos. By looking at the captured packets for a sufficient amount of time, you can gather nearly complete information about the architecture of the remote network, including the subnet ranges, types of Cisco devices deployed, and their operational systems. In the preceding example output, we can identify neighboring Cisco 2611 router via CDP and see some fragments of Open Shortest Path First (OSPF) link state updates. From these fragments , we can gather the OSPF area in which the rout-ers are positioned, the absence of OSPF authentication in this area (!), and a partial routing table. Waiting for a longer time period would have provided us with a full rout-ing table and more information about the interfaces of routers involved. In vain, we have tried multiple Telnet and enable logins to/on the attacked router in hopes of capturing the login passwords with IOSniff. Sometimes, though, things just don't work the way you want them to.

Just for your referencethis is what happens if IOSniff is run against an invulnerable router:

arhontus#/iosniff -i eth0 -d 192.168.66.202 -v --==[ Phenoelit IOSniff ]==-- Cisco IOS 11.x UDP echo memory leak remote sniffer Timeout - may be lost packet? Your target does not seem to leak data.

The tool will simply timeout and quit.

Hiding Your Machine from Prying Eyes: Enumeration and Fingerprinting Countermeasures

Countermeasure

The recommendations to prevent attackers from enumerating and fingerprinting your Cisco appliances are as mundane as they are efficient. The first thing you should con-sider is using the latest version of the IOS or other operational system your hardware can support. If you have another look at the scans we've discussed and generalize beyond the examples shown, the following points are obvious:

Newer IOS versions have fewer ports open. In particular, this applies to those annoying "unknown" services.

Newer IOS versions are more difficult to fingerprint.

TCP sequence prediction on the newest IOS versions is practically impossible . The supported protocols scan against newer IOS versions tends to fail ( this is important ). In addition, newer IOS or CatOS versions would be freer from bugs that can assist in finger-printing and enumeration. A typical example of such a bug is the IOS 11.X memory leak described earlier.

The next thing is, of course, turning off all unnecessary services. Small TCP and UDP services (ECHO, Chargen, and others) should always be turned off. They are a part of networking history and have no place in the modern world. To turn them off, use the commands no service tcp-small-servers and no service udp-small-servers . To turn off finger, use the no service finger command; no ip bootp server switches off the bootp server we constantly saw on UDP portscans of routers. If you don't use SNMP, you can get rid of the service by issuing the no snmp-server command.

Of course, we are going to discuss SNMP security in more detail in the next chapter. Turning off the administrative web interface is done via the no ip http server com-mand, even though we didn't find the Cisco web interface, with its plain request for a username/password pair, to be very useful in fingerprinting. Exploitation is, surely, an-other story. On the other hand, the necessity of open services should also be considered in great detail. If the system administrator wants to enable access from the outside to, for example, SSHd, such access should be restricted to a specific IP address (or at least a limited IP range):

2611a(config)#access-list 101 permit tcp host 10.1.1.1 any eq 22 log

Tip	While many Cisco security sources show examples of restricting Telnet access to the appliance from the Internet side, we completely discourage using Telnet to administer any device across a public network. You never know who is sniffing.

To illustrate how removing unnecessary services can be efficient at confusing remote attackers, here are some scan results for some of the hosts we have used when illustrat-ing fingerprinting:

Cisco 2611:

arhontus#nmap -sT -vvvv 192.168.66.202 -O Interesting ports on 2611b.dmz.arhont.com (192.168.66.202): (The 1662 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 23/tcp open telnet No exact OS matches for host.

Cisco 2503:

arhontus#nmap -sT -vvvv 192.168.30.50 -O Interesting ports on 192.168.30.50: (The 1658 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 23/tcp open telnet 57/tcp open priv-term 2001/tcp open dc 6001/tcp open X11:1 Device type: general purposefirewall Running: IBM AIX 4.X, Linux 1.X, Microsoft Windows NT/2K/XP, Symantec Solaris 8 Too many fingerprints match this host to give specific OS details

PIX 515E:

arhontus# nmap -sT -vvvv -O 192.168.66.108 All 1663 scanned ports on 192.168.66.108 are: filtered MAC Address: 00:90:27:99:11:8F (Intel) Too many fingerprints match this host to give specific OS details

Aironet 1200 access point:

arhontus# nmap -sT -O -vvvv 192.168.77.235 All 1977 scanned ports on 192.168.77.235 are: closed MAC Address: 00:0D:BD:A7:13:BB (Cisco Systems) Too many fingerprints match this host to give specific OS details

Compare this output to the outputs of the very same scans when the assessed net-work appliances had more open ports, and note how dramatically the OS fingerprinting efficiency of Nmap has decreased. Of course, "closed port" mode tests with Xprobe won't be affected. However, in general, these mode scans are less precise than tests, in which known open ports are supplied to the tool.

"Knock, Knock! Who's There?" Portscanning, OS Fingerprinting, and Their Detection on Cisco Machines

Countermeasure

Detecting these annoying scanners pondering your Cisco hosts is an important task. The first thing you will need to do is to timestamp the logs:

cisco-2611a(config)#service timestamps log datetime localtime msec show-timezone year

Tip	Synchronizing the router with a remote NTP server is a very good idea and will be described in Chapter 10.

Then create a local buffer for logs stored on a router or switch and set the logging severity level:

cisco-2611a(config)#logging buffered 4096 debugging

Don't forget to set a general logging severity level and count for all logs, as well as stamp the logs with sequence numbers:

cisco-2611a(config)#logging trap debugging cisco-2611a(config)#logging count cisco-2611a(config)#service sequence-numbers

Of course, logging to a remote syslog server needs to be considered, since a router or switch crashed (by the attack?) will lose the logs stored in its buffer. If you have many routers, labeling the logs sent by each router using a unique string, router IP, or host- name (whatever rocks your boat) is more than helpful:

cisco-2611a(config)#logging facility syslog cisco-2611a(config)#logging host 10.1.1.5 cisco-2611a(config)#logging origin-id string Testing2611a

Then you can turn on all logging (using the logging on command). Afterward, don't forget to add log at the end of every access list you write ( log-input to log the interface to which the packets come as well). If you are using Context Based Access Con-trol (CBAC) instead of the casual Cisco access lists, or you are configuring a PIX firewall, IDS and logging can be done via the ip audit set of commands. However, as you will see very soon, CBAC IDS on its own is less than perfect for portscan detection.

On CatOS switches, logging is done via the set logging command:

Gromozeka (enable) set logging ? Usage: set logging server <enabledisable> set logging server <ip_addr> set logging server facility <server_facility_parameter> set logging server severity <server_severity_level> set logging history <syslog_history_table_size> (server_facility_parameter = local0local1local2local3local4 local5local6local7syslog server_severity_level = 0..7 syslog_history_table_size = 0..500) set logging <consolesession> <enabledisable> set logging level <facility> <severity> [default] (facility = allcdpdtpdripdvlanearlfddifilesysipmcast mgmtmlspagpprotfiltpruningsecuritysnmpspantreesystactcp telnettftpvmpsvtp severity = 0..7) set logging timestamp <enabledisable> set logging buffer <buffer_size> (buffer_size = 1..500) (severity levels: emergencies(0), alerts(1), critical(2), errors(3), warnings(4), notifications(5), information(6), debugging(7))

Now let's evaluate whether IOS access lists and CBAC IDS are efficient at detecting and thwarting portscanning and OS fingerprinting attempts. We are going to use a Cisco 2611 router to illustrate the point. The relevant router security configuration fragments include all logging settings we have described, extended Access Control Lists (ACLs) that block invalid TCP packets, and basic CBAC IDS:

ip audit protected 192.168.66.202 ip audit signature 1107 disable ip audit name ironcurtain info action alarm ip audit name ironcurtain attack action alarm access-list 101 deny tcp any any fin syn log-input access-list 101 deny tcp any any rst syn log-input access-list 101 deny tcp any any fin rst log-input access-list 101 deny tcp any any ack fin log-input access-list 101 deny tcp any any ack psh log-input access-list 101 deny tcp any any ack urg log-input access-list 101 deny tcp any any fragments log-input access-list 101 deny tcp any any log-input access-list 101 deny udp any any fragments log-input access-list 101 deny udp any any log-input access-list 101 permit icmp any any echo-reply log-input access-list 101 permit icmp any any unreachable log-input access-list 101 permit icmp any any time-exceeded log-input access-list 101 permit icmp any any echo log-input access-list 101 deny icmp any any log-input interface Ethernet0/0 ip address 192.168.66.202 255.255.255.0 ip access-group 101 in ip audit ironcurtain in

We use only the CBAC IDS to log the attack attempts. Signature 1107 is disabled since we are using RFC 1918 addresses. For the purposes of this example, all TCP and UDP connections to the router are explicitly denied, but pings , ping replies, ICMP unreach-able, and ICMP time-exceeded packets are permitted. To dissect the process of detection, we have enabled the IDS first without adding ip access-group 101 in to the inter-face and recorded all log messages:

arhontus#nmap -sT -vvv 192.168.66.202 048928: Dec 4 2004 16:56:25.450 GMT: %IDS-4-ICMP_ECHO_SIG: Sig:2004:ICMP Echo Request - from 192.168.77.5 to 192.168.66.202 arhontus#nmap -sT -vvv -O 192.168.66.202 048923: Dec 4 2004 16:54:02.208 GMT: %IDS-4-ICMP_ECHO_SIG: Sig:2004:ICMP Echo Request - from 192.168.77.5 to 192.168.66.202 048924: Dec 4 2004 16:54:35.188 GMT: %IDS-4-TCP_NO_FLAGS_SIG: Sig:3040:TCP - No bits set in flags - from 192.168.77.5 to 192.168.66.202 048925: Dec 4 2004 16:54:35.192 GMT: %IDS-4-TCP_SYN_FIN_SIG: Sig:3041:TCP - SYN and FIN bits set - from 192.168.77.5 to 192.168.66.202 048926: Dec 4 2004 16:54:35.192 GMT: %IDS-4-TCP_FIN_ONLY_SIG: Sig:3042:TCP - FIN bit with no ACK bit in flags - from 192.168.77.5 to 192.168.66.202

Exactly the same log messages were seen with SYN scans. Since the Nmap finger-printing mechanism ( -O ) is the same for different Nmap scan types, this option was omitted in the future scans to avoid message repetition.

arhontus#nmap -sN -vvv 192.168.66.202 048932: Dec 4 2004 17:01:04.928 GMT: %IDS-4-ICMP_ECHO_SIG: Sig:2004:ICMP Echo Request - from 192.168.77.5 to 192.168.66.202 048933: Dec 4 2004 17:01:31.901 GMT: %IDS-4-TCP_NO_FLAGS_SIG: Sig:3040:TCP - No bits set in flags - from 192.168.77.5 to 192.168.66.202 048934: Dec 4 2004 17:02:01.904 GMT: %IDS-4-TCP_NO_FLAGS_SIG: Sig:3040:TCP - No bits set in flags - from 192.168.77.5 to 192.168.66.202 arhontus#nmap -sF -vvv 192.168.66.202 048935: Dec 4 2004 17:03:31.046 GMT: %IDS-4-ICMP_ECHO_SIG: Sig:2004:ICMP Echo Request - from 192.168.77.5 to 192.168.66.202 048936: Dec 4 2004 17:03:31.146 GMT: %IDS-4-TCP_FIN_ONLY_SIG: Sig:3042:TCP - FIN bit with no ACK bit in flags - from 192.168.77.5 to 192.168.66.202 048937: Dec 4 2004 17:04:01.197 GMT: %IDS-4-TCP_FIN_ONLY_SIG: Sig:3042:TCP - FIN bit with no ACK bit in flags - from 192.168.77.5 to 192.168.66.202 arhontus#nmap -sX -vvv 192.168.66.202 048938: Dec 4 2004 17:05:28.853 GMT: %IDS-4-ICMP_ECHO_SIG: Sig:2004:ICMP Echo Request - from 192.168.77.5 to 192.168.66.202 048939: Dec 4 2004 17:05:28.957 GMT: %IDS-4-TCP_FIN_ONLY_SIG: Sig:3042:TCP - FIN bit with no ACK bit in flags - from 192.168.77.5 to 192.168.66.202 048940: Dec 4 2004 17:05:58.971 GMT: %IDS-4-TCP_FIN_ONLY_SIG: Sig:3042:TCP - FIN bit with no ACK bit in flags - from 192.168.77.5 to 192.168.66.202 arhontus#nmap -sA -vvv 192.168.66.202 048946: Dec 4 2004 17:09:10.378 GMT: %IDS-4-ICMP_ECHO_SIG: Sig:2004:ICMP Echo Request - from 192.168.77.5 to 192.168.66.202 arhontus#nmap -sW -vvv 192.168.66.202 048947: Dec 4 2004 17:10:06.076 GMT: %IDS-4-ICMP_ECHO_SIG: Sig:2004:ICMP Echo Request - from 192.168.77.5 to 192.168.66.202 arhontus#nmap -sO -vvv 192.168.66.202 048948: Dec 4 2004 17:14:21.074 GMT: %IDS-4-ICMP_ECHO_SIG: Sig:2004:ICMP Echo Request - from 192.168.77.5 to 192.168.66.202 048949: Dec 4 2004 17:14:21.174 GMT: %IDS-4-IP_UNKNOWN_PROTO_SIG: Sig:1101:Unknown IP Protocol - from 192.168.77.5 to 192.168.66.202 048950: Dec 4 2004 17:14:23.910 GMT: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=192.168.66.202, prot=50, spi=0x0(0), srcaddr=192.168.77.5 048951: Dec 4 2004 17:14:25.661 GMT: %OSPF-4-BADLENGTH: Invalid length 0 in OSPF packet type 0 from 192.168.77.5 (ID 0.0.0.0), Ethernet0/0 048952: Dec 4 2004 17:14:26.298 GMT: %IDS-4-TCP_NO_FLAGS_SIG: Sig:3040:TCP - No bits set in flags - from 192.168.77.5 to 192.168.66.202 048953: Dec 4 2004 17:14:26.947 GMT: %IDS-4-UDP_IOS_BOMB_SIG: Sig:4600:UDP IOS Bomb - from 192.168.77.5 to 192.168.66.202 048954: Dec 4 2004 17:14:27.376 GMT: %IDS-4-ICMP_ECHO_REPLY_SIG: Sig:2000:ICMP Echo Reply - from 192.168.77.5 to 192.168.66.202 arhontus#nmap -sU -vvv 192.168.66.202 048955: Dec 4 2004 17:15:35.247 GMT: %IDS-4-ICMP_ECHO_SIG: Sig:2004:ICMP Echo Request - from 192.168.77.5 to 192.168.66.202 048956: Dec 4 2004 17:15:35.351 GMT: %IDS-4-UDP_IOS_BOMB_SIG: Sig:4600:UDP IOS Bomb - from 192.168.77.5 to 192.168.66.202 048957: Dec 4 2004 17:16:05.365 GMT: %IDS-4-UDP_IOS_BOMB_SIG: Sig:4600:UDP IOS Bomb - from 192.168.77.5 to 192.168.66.202

As you can see, only the initial ping was detected with plain full-connect and SYN scans, and if we ran those scans with the -P0 option, they would have gone unmen-tioned. With CBAC, it is possible to add additional configuration-detecting SYN scans via a number of incomplete TCP connections using the ip inspect tcp max-incom-plete command set.

Detection of full-connect scans, though, presents a problem. ACK and Window TCP scans also slip in undetected, which is not good news. NULL, FIN, and XMAS scans are detected, but there are no means to distinguish FIN and XMAS in logs. To the contrary, the supported protocols scan ( -sO ) leaves an easy-to-spot, telltale signature. A UDP scan is detected and flagged as a UDP DoS attack (UDP IOS Bomb).

Now let's have a look at the Xprobe:

arhontus#xprobe2 -v -c /etc/xprobe2.conf -p tcp:23:open 192.168.66.202 048958: Dec 4 2004 17:21:42.942 GMT: %IDS-4-ICMP_ECHO_SIG: Sig:2004:ICMP Echo Request - from 192.168.77.5 to 192.168.66.202 048959: Dec 4 2004 17:21:43.227 GMT: %IDS-4-ICMP_TIME_SIG: Sig:2007:ICMP Timestamp Request - from 192.168.77.5 to 192.168.66.202 048960: Dec 4 2004 17:21:43.227 GMT: %IDS-4-ICMP_MASK_SIG: Sig:2011:ICMP Address Mask Request - from 192.168.77.5 to 192.168.66.202 048961: Dec 4 2004 17:21:43.231 GMT: %IDS-4-ICMP_INFO_SIG: Sig:2009:ICMP Information Request - from 192.168.77.5 to 192.168.66.202

Exactly the same signature set is seen when a closed TCP port is supplied.

arhontus#xprobe2 -v -c /etc/xprobe2.conf -p udp:161:open 192.168.66.202 048970: Dec 4 2004 17:42:12.117 GMT: %IDS-4-ICMP_ECHO_SIG: Sig:2004:ICMP Echo Request - from 192.168.77.5 to 192.168.66.202 048971: Dec 4 2004 17:42:12.126 GMT: %IDS-4-UDP_IOS_BOMB_SIG: Sig:4600:UDP IOS Bomb - from 192.168.77.5 to 192.168.66.202 048972: Dec 4 2004 17:42:22.126 GMT: %IDS-4-ICMP_TIME_SIG: Sig:2007:ICMP Timestamp Request - from 192.168.77.5 to 192.168.66.202 048973: Dec 4 2004 17:42:22.130 GMT: %IDS-4-ICMP_MASK_SIG: Sig:2011:ICMP Address Mask Request - from 192.168.77.5 to 192.168.66.202 048974: Dec 4 2004 17:42:22.142 GMT: %IDS-4-ICMP_INFO_SIG: Sig:2009:ICMP Information Request - from 192.168.77.5 to 192.168.66.202

Just as well, the same signature is seen when a closed UDP port is supplied. The se-quence of ICMP packets received appears to be rather typical for the tool. In addition, when UDP probes are used a flood is detected. Unfortunately, when Xprobe v1 was run against the router, no alarms were triggered.

The final step is to enable the extended ACLs on the interface ( ip access-group 101 in ) and rerun the tests. Now we can spot both full-connect and SYN scans by ob-serving a long list of denied connections:

arhontus#nmap -sT -vvv 192.168.66.202 049300: Dec 4 2004 23:43:35.354 GMT: %IDS-4-ICMP_ECHO_SIG: Sig:2004:ICMP Echo Request - from 192.168.77.5 to 192.168.66.202 049301: Dec 4 2004 23:43:35.358 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(46096) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(80), 1 packet 049302: Dec 4 2004 23:43:36.572 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(56722) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(23), 1 packet 049303: Dec 4 2004 23:43:37.573 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(56822) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(3306), 1 packet 049304: Dec 4 2004 23:43:38.583 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(56922) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(39), 1 packet 049305: Dec 4 2004 23:43:39.585 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(57022) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(828), 1 packet 049306: Dec 4 2004 23:43:40.586 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(57126) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(27001), 1 packet 049307: Dec 4 2004 23:43:41.592 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(57222) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(784), 1 packet <snip>

Note that the packets are sent from random high ports to random ports on a router.

arhontus# nmap -sS -vvv 192.168.66.202 049318: Dec 4 2004 23:45:15.915 GMT: %IDS-4-ICMP_ECHO_SIG: Sig:2004:ICMP Echo Request - from 192.168.77.5 to 192.168.66.202 049319: Dec 4 2004 23:45:15.919 GMT: %SEC-6-IPACCESSLOGDP: list 101 permitted icmp 192.168.77.5 (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202 (8/0), 1 packet 049320: Dec 4 2004 23:45:17.125 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(58923) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(22), 1 packet 049321: Dec 4 2004 23:45:18.191 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(58923) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(22305), 1 packet 049322: Dec 4 2004 23:45:19.261 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(58923) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(1530), 1 packet 049323: Dec 4 2004 23:45:20.262 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(58922) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(450), 1 packet 049324: Dec 4 2004 23:45:21.300 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(58922) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(18187), 1 packet 049325: Dec 4 2004 23:45:22.322 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(58923) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(336), 1 packet 049326: Dec 4 2004 23:45:23.327 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(58923) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(1529), 1 packet

While both scans look very similar, only two high source ports (58922 and 58923) are in use when the SYN scan is running. If we rerun the scan, the source ports would be different, but still only two of them will exist. This was applied to two different versions of Nmap tested, namely 3.75 and 3.45. It provides a clear distinction between Nmap full-connect and half-connect TCP scans in router logs. Looking into the further scan types, it is clear that the "only-two-high-source-ports phenomenon" also applies to NULL, FIN, XMAS, ACK, and Window Nmap scans. Of these scans, NULL, FIN, and XMAS are go-ing to be picked up by the IDS (signatures 3040 and 3042). NULL scans are not going to show up in the ACL logs, but you are likely to see the %SEC-6-IPACCESSLOGRL: ac-cess-list logging rate-limited or missed X packets message, common for all portscans. ACK and Window scans, however, can be confused with half-connects; so to distinguish between ACK, Window, and SYN or between FIN and XMAS scans, you will have to look at the packets using the debug ip packet <appropriate ACL number> <detail> command.

How about UDP scans? The log messages look quite similar to what we saw before with IDS alone:

049221: Dec 4 2004 20:16:52.402 GMT: %IDS-4-ICMP_ECHO_SIG: Sig:2004:ICMP Echo Request - from 192.168.77.5 to 192.168.66.202 049222: Dec 4 2004 20:16:52.410 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(35650) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(80), 1 packet 049223: Dec 4 2004 20:16:52.506 GMT: %IDS-4-UDP_IOS_BOMB_SIG: Sig:4600:UDP IOS Bomb - from 192.168.77.5 to 192.168.66.202 049224: Dec 4 2004 20:16:59.654 GMT: %SEC-6-IPACCESSLOGRL: access-list logging rate-limited or missed 4 packets 049225: Dec 4 2004 20:17:22.508 GMT: %IDS-4-UDP_IOS_BOMB_SIG: Sig:4600:UDP IOS Bomb - from 192.168.77.5 to 192.168.66.202

Nevertheless, note the additional line showing the TCP ping to port 80. This line opens all Nmap portscans following an ICMP ping. But since there are no more TCP packets to send, it stands out like a sore thumb when a UDP scan is detected.

To dot the i , lets have a look at Xprobe detection and its blocking by the current router settings:

arhontus# xprobe2 -v -c /etc/xprobe2.conf -p tcp:23:open 192.168.66.202 [+] Primary guess:[+] Host 192.168.66.202 Running OS: "HP UX 11.0i" (Guess probability: 38%) [+] Other guesses: [+] Host 192.168.66.202 Running OS: "Linux Kernel 2.4.4" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Cisco IOS 12.2" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Cisco IOS 12.0" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Cisco IOS 11.3" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Cisco IOS 11.2" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Cisco IOS 11.1" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Linux Kernel 2.4.3" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Linux Kernel 2.4.2" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Linux Kernel 2.4.1" (Guess probability: 35%)

Router logs:

049240: Dec 4 2004 20:21:47.046 GMT: %IDS-4-ICMP_ECHO_SIG: Sig:2004:ICMP Echo Request - from 192.168.77.5 to 192.168.66.202 049241: Dec 4 2004 20:21:47.050 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(16756) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(23), 1 packet 049242: Dec 4 2004 20:21:59.924 GMT: %SEC-6-IPACCESSLOGDP: list 101 permitted icmp 192.168.77.5 (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202 (0/0), 1 packet 049243: Dec 4 2004 20:21:59.928 GMT: %SEC-6-IPACCESSLOGDP: list 101 permitted icmp 192.168.77.5 (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202 (8/0), 3 packets 049244: Dec 4 2004 20:21:59.928 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(39868) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(80), 1 packet 049245: Dec 4 2004 20:22:00.281 GMT: %IDS-4-ICMP_TIME_SIG: Sig:2007:ICMP Timestamp Request - from 192.168.77.5 to 192.168.66.202 049246: Dec 4 2004 20:22:00.285 GMT: %IDS-4-ICMP_MASK_SIG: Sig:2011:ICMP Address Mask Request - from 192.168.77.5 to 192.168.66.202 049247: Dec 4 2004 20:22:00.297 GMT: %IDS-4-ICMP_INFO_SIG: Sig:2009:ICMP Information Request - from 192.168.77.5 to 192.168.66.202049248: Dec 4 2004 20:26:00.133 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(15273) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(65535), 1 packet 049249: Dec 4 2004 20:26:00.137 GMT: %SEC-6-IPACCESSLOGDP: list 101 permitted icmp 192.168.77.5 (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202 (8/123), 2 packets 049250: Dec 4 2004 20:26:00.137 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(20139) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(23), 1 packet 049251: Dec 4 2004 20:28:00.235 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(50273) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(23), 1 packet 049252: Dec 4 2004 20:28:00.239 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(50273) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(65535), 1 packet 049253: Dec 4 2004 20:28:00.239 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(2711) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(23), 1 packet arhontus#xprobe2 -v -c /etc/xprobe2.conf -p tcp:22:closed 192.168.66.202[+] Primary guess: [+] Host 192.168.66.202 Running OS: "HP UX 11.0i" (Guess probability: 38%) [+] Other guesses: [+] Host 192.168.66.202 Running OS: "Linux Kernel 2.4.4" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Cisco IOS 12.2" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Cisco IOS 12.0" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Cisco IOS 11.3" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Cisco IOS 11.2" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Cisco IOS 11.1" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Linux Kernel 2.4.3" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Linux Kernel 2.4.2" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Linux Kernel 2.4.1" (Guess probability: 35%)

Router logs:

049697: Dec 5 2004 01:27:43.795 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(2895) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(22), 1 packet 049698: Dec 5 2004 01:27:55.975 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(39086) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(22), 1 packet 049699: Dec 5 2004 01:27:56.011 GMT: %IDS-4-ICMP_TIME_SIG: Sig:2007:ICMP Timestamp Request - from 192.168.77.5 to 192.168.66.202 049700: Dec 5 2004 01:27:56.019 GMT: %IDS-4-ICMP_MASK_SIG: Sig:2011:ICMP Address Mask Request - from 192.168.77.5 to 192.168.66.202 049701: Dec 5 2004 01:27:56.027 GMT: %IDS-4-ICMP_INFO_SIG: Sig:2009:ICMP Information Request - from 192.168.77.5 to 192.168.66.202 049702: Dec 5 2004 01:28:16.069 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(57464) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(20), 1 packet 049703: Dec 5 2004 01:28:16.073 GMT: %SEC-6-IPACCESSLOGDP: list 101 permitted icmp 192.168.77.5 (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202 (8/0), 3 packets 049704: Dec 5 2004 01:28:16.073 GMT: %SEC-6-IPACCESSLOGDP: list 101 permitted icmp 192.168.77.5 (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202 (8/123), 2 packets 049705: Dec 5 2004 01:28:16.073 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(59382) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(65535), 1 packet 049706: Dec 5 2004 01:30:16.180 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(62548) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(65535), 1 packet 049707: Dec 5 2004 01:30:16.184 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(23964) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(23), 1 packet 049708: Dec 5 2004 01:33:16.331 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(39086) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(22), 1 packet 049709: Dec 5 2004 01:33:16.335 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(36385) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(65535), 1 packet arhontus#xprobe2 -v -c /etc/xprobe2.conf -p udp:22:closed 192.168.66.202[+] Primary guess: [+] Host 192.168.66.202 Running OS: "HP UX 11.0i" (Guess probability: 38%) [+] Other guesses: [+] Host 192.168.66.202 Running OS: "Linux Kernel 2.4.4" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Cisco IOS 12.2" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Cisco IOS 12.0" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Cisco IOS 11.3" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Cisco IOS 11.2" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Cisco IOS 11.1" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Linux Kernel 2.4.3" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Linux Kernel 2.4.2" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Linux Kernel 2.4.1" (Guess probability: 35%)

Router logs:

049710: Dec 5 2004 01:37:12.701 GMT: %IDS-4-ICMP_ECHO_SIG: Sig:2004:ICMP Echo Request - from 192.168.77.5 to 192.168.66.202 049711: Dec 5 2004 01:37:12.705 GMT: %IDS-4-UDP_IOS_BOMB_SIG: Sig:4600:UDP IOS Bomb - from 192.168.77.5 to 192.168.66.202 049712: Dec 5 2004 01:37:16.544 GMT: %SEC-6-IPACCESSLOGDP: list 101 permitted icmp 192.168.77.5 (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202 (8/0), 1 packet 049713: Dec 5 2004 01:37:22.798 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(60764) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(65535), 1 packet 049714: Dec 5 2004 01:37:22.830 GMT: %IDS-4-ICMP_TIME_SIG: Sig:2007:ICMP Timestamp Request - from 192.168.77.5 to 192.168.66.202 049715: Dec 5 2004 01:37:22.834 GMT: %IDS-4-ICMP_MASK_SIG: Sig:2011:ICMP Address Mask Request - from 192.168.77.5 to 192.168.66.202 049716: Dec 5 2004 01:37:22.846 GMT: %IDS-4-ICMP_INFO_SIG: Sig:2009:ICMP Information Request - from 192.168.77.5 to 192.168.66.202 049717: Dec 5 2004 01:38:16.597 GMT: %SEC-6-IPACCESSLOGDP: list 101 permitted icmp 192.168.77.5 (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202 (8/123), 1 packet arhontus#xprobe2 -v -c /etc/xprobe2.conf -p udp:161:open 192.168.66.202 [+] Primary guess: [+] Host 192.168.66.202 Running OS: "HP UX 11.0i" (Guess probability: 38%) [+] Other guesses: [+] Host 192.168.66.202 Running OS: "Linux Kernel 2.4.4" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Cisco IOS 12.2" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Cisco IOS 12.0" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Cisco IOS 11.3" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Cisco IOS 11.2" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Cisco IOS 11.1" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Linux Kernel 2.4.3" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Linux Kernel 2.4.2" (Guess probability: 35%) [+] Host 192.168.66.202 Running OS: "Linux Kernel 2.4.1" (Guess probability: 35%)

Router logs:

049718: Dec 5 2004 01:40:32.009 GMT: %IDS-4-ICMP_ECHO_SIG: Sig:2004:ICMP Echo Request - from 192.168.77.5 to 192.168.66.202 049719: Dec 5 2004 01:40:32.017 GMT: %IDS-4-UDP_IOS_BOMB_SIG: Sig:4600:UDP IOS Bomb - from 192.168.77.5 to 192.168.66.202 049720: Dec 5 2004 01:40:42.022 GMT: %IDS-4-ICMP_TIME_SIG: Sig:2007:ICMP Timestamp Request - from 192.168.77.5 to 192.168.66.202 049721: Dec 5 2004 01:40:42.026 GMT: %IDS-4-ICMP_MASK_SIG: Sig:2011:ICMP Address Mask Request - from 192.168.77.5 to 192.168.66.202 049722: Dec 5 2004 01:40:42.038 GMT: %IDS-4-ICMP_INFO_SIG: Sig:2009:ICMP Information Request - from 192.168.77.5 to 192.168.66.202 049723: Dec 5 2004 01:40:42.146 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(10014) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(65535), 1 packet 049724: Dec 5 2004 01:42:16.810 GMT: %SEC-6-IPACCESSLOGDP: list 101 permitted icmp 192.168.77.5 (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202 (8/0), 1 packet 049725: Dec 5 2004 01:43:16.863 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(60764) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(65535), 1 packet 049726: Dec 5 2004 01:43:16.867 GMT: %SEC-6-IPACCESSLOGP: list 101 denied tcp 192.168.77.5(23073) (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202(65535), 1 packet 049727: Dec 5 2004 01:43:16.867 GMT: %SEC-6-IPACCESSLOGDP: list 101 permitted icmp 192.168.77.5 (Ethernet0/0 0002.b365.bd03) -> 192.168.66.202 (8/123), 1 packet

The main conclusions from these tests are as follows :

The Xprobe fingerprinting capability is significantly decreased. The primary guess is never Cisco IOS and the guess probability is low.

Xprobe commonly sends TCP packets to port 65535 when fingerprinting.

It is easy to distinguish Xprobe TCP and UDP tests by the presence of signature 4600 and first TCP packets being sent to the open or closed port supplied to the tool prior to any ICMP probes.

We probably could have found more differences between the Xprobe modes but didn't dig any further, leaving this exciting task to all interested readers.

Unfortunately, Xprobe v1 tests again did not show in router logs.

Active Enumeration and Fingerprinting of Cisco Routers

Active Enumeration and Fingerprinting of Catalyst Switches

Active Enumeration and Fingerprinting of Other Cisco Appliances

Using IOS 11.X Memory Leak to Enumerate Remote Cisco Routers

Hiding Your Machine from Prying Eyes: Enumeration and Fingerprinting Countermeasures

"Knock, Knock! Who's There?" Portscanning, OS Fingerprinting, and Their Detection on Cisco Machines

Категории