A PRIMER ON PROTOCOL IMPLEMENTATION INVESTIGATION AND ABUSE: CISCO SNMP ATTACKS
| | ||
| | ||
| | ||
Along with being useful in exploitation of Cisco networks with centralized management, SNMP attacks are also a good example of how we can tackle vulnerability testing of any network protocol that happens to run through a tested segment. Together with the exploitation of Layer 2 and routing protocols, described later in the book, this builds up a systematic approach to hacking network protocols (or, more likely, their vendor-specific implementations ).
Imagine that a typical SNMP community list dictionary attack against a tested host did not succeed, and neither did all the known attacks against SNMP implementations you have probably read about at Bugtraq, PacketStorm, Full-Disclosure, SecuriTeam , or similar sites. Or, perhaps, you are a beta tester who has full access to the device but wants to analyze its security from a black box, Black Hat perspective. What do you do next ?
You can proceed with a further attack in several ways, listed here in order of growing complexity:
-
Sniff, sniff, sniff for SNMP traffic, especially informs and traps. Sometimes, very interesting discoveries can be made this way, as you are going to see soon. Also, don't forget to do a full SNMP walk using both Requests for Comments (RFCs) and Cisco Management Information Bases (MIBs) if a read-only community is known. Analyze its output in great detail, as you might find surprises lurking.
-
Carry out a more extensive and intelligent community dictionary attack against the device, taking into account the standards and protocols it supports. This may lead to the discovery of hidden SNMP communities, perhaps with Read-Write (RW) privileges if it is your lucky day. (We know that the probability of such discovery is not very high, but if it happensas it has happened in the past you'll have your day of glory at the security sites/mail lists mentioned earlier.)
-
Perform stress testing of the targeted services by feeding them high volumes of input. In our case, this amounts to a User Datagram Protocol (UDP) flood, which can also be modifiedfor example, sending empty UDP packets to both ports 161 and 162 or trying all three versions of SNMP when flooding. All you can reach by stress testing is DoS, and this is rather boring; however, there is a catch. Networks with centralized SNMP-based management are likely to use SNMP traps for centralized logging. Shutting down SNMP agents on such networks by any means would significantly reduce the chances of an attacker being traced back when an incident response procedure takes place.
-
Do a proper fuzzing of the SNMP implementation by feeding it packets with specific errors, likely to cause an exception fault or overfillsnmpd memory buffer. Such errors include ASN.1 grammar violations; special characters and delimiters omitted, unbalanced, or misplaced; strings too long or short; variables used out of range; illegal packet fields; and state dependency violations (when an input is correct, but does not match the state of the service tested). If a variety of such tests fails, multiple errors can be combined in a single packet as a weapon of last resort spare for stress testing. The results of syntax testing, or fuzzing , in general could be anythingfrom a humble service DoS to a full-blown exploitation technique that hands you enable on a silver plate.
All of the aforementioned can be performed using netcat, a hex editor, and a few packet generation tools such as Nemesis and Isic, with a solid and thorough knowledge of the protocol involved. However, we do not expect you to be SNMP gurus and do not belong to this category ourselves . Automated tools have been designed to search for SNMP inconsistencies and vulnerabilities; these are both very handy and relatively easy to use. If necessary, they can be complemented by manual packet craftwork when zeroing in on a specific flaw thought to be discovered . You can also create your own test cases and scripts and integrate them into these tools before an attack takes place.
SilverCreek
| Attack |
|
The first SNMP standard compliance and vulnerability testing tool to be described is SilverCreek. You can buy the tool or get the evaluation version at http://www.iwl.com/Products/sc/ . The evaluation version imposes an obvious use time limit, and not all tests are operational. Both evaluation and full versions of the tool can be run on Windows NT, 2000, XP, and Red Hat/Fedora Linux. The complete suite has many bells and whistles, including both standard compliance and security test batteries controls in a single GUI, and it supports all three versions of SNMP. An embedded MIB browser, compiler, command execution tool, command TCL script wizard, MIB search engine, trap monitor and tester, and SNMP packet sniffer are also included.
As with the MIB browsers described in Chapter 6, the first thing you want to do is import or compile and import Cisco MIBs, as well as any additional private test suites. Then, if a Read-Only (RO) community is known, run an snmpwalk on the device in a separate window, if you haven't done so already. The results of snmpwalk are presented in a nice table, in which you can right-click through the rows for further actions (Figure 7-1).
Figure 7-1: Snmpwalking with SilverCreek
After that, you can proceed straight to the vulnerability testing part. You can either run the whole battery of tests or select those you want in particular and launch them one-by-one. It is recommended that you start from SNMPv1 testing and then gradually move to SNMPv2c and SNMPv3 (Figure 7-2).
Figure 7-2: SNMP vulnerability test using SilverCreek
By right-clicking the generated test output, you can view both the results of the test (with more than one probe packet sent) and a packet creation script generated to run the test. SNMP ping (see Chapter 6) is used after every test to verify that the targeted service did not crash and the device is still accessible. A separate console launched during the testing demonstrates all SNMP packets that were sent and received in both hex and ASN.1 formats (Figure 7-3).
Figure 7-3: SilverCreek console
The console also supports command execution for those who demand more control over the testing procedure. If the test has "failed," and a potential vulnerability is discovered, it is easy to generate a full-blown proof of concept exploit from the Tool Command Language (TCL) script used by SilverCreek to send the fatal packet(s) and the console output. You may want to add a few auxiliary options to the script (for example, the amount of packets to be sent and input for the target IP and port) or rewrite the packet generation routine in a language you prefer (for example, Perl) to produce a fully functional new attack tool. And even if the vulnerabilities test did not find any definite flaws, do not give up. Launch the test batteries from the standard-compliance section (Figure 7-4). After all, this is still SNMP syntax testing that can uncover potential vulnerabilities, even though they may not be that obvious.
Figure 7-4: SilverCreek agent compliance testing
In addition to a Diffie-Hellman utility, key change tests for SNMPv3 actually belong to the vulnerability testing area, since they evaluate, for example, whether a legitimate user can change the keys for other users. This constitutes a local attack and leads both to potential privilege escalation on a device and DoS (for the user whose key was changed). Also, Sample Toaster MIB tests are stressing components of the SilverCreek suite, which an attacker can use to determine whether a "semi-generic" DoS of the targeted server can be achieved.
SimpleTester and SimpleSleuth
| Attack |
|
This full commercial SNMP testing suite is similar to SilverCreek. SimpleTester is available for all Windows versions, Red Hat Linux and its offshoots, and Sun Solaris versions 2.6 and higher. You can buy the tool or download the evaluation version at http://www.smplsft.com/SimpleTester.html; the evaluation version is limited in both time of use and quantity of tests supported. Unlike SilverCreek, the vulnerability tester, SimpleSleuth, is a separate GUI that launches from SimpleTester's Tools menu. The tests in the SimpleTester are split into four categories: syntax tests, semantic tests, performance tests for agent stress testing, and user tests (Figure 7-5).
Figure 7-5: Main SimpleTester interface
The Tools menu also contains the obvious MIB browser, script generation, testing and command execution utilities, and user test suite builder for those who really know what they're doing. A Diffie-Hellman random number generator is included for keys generation in SNMPv3 testing. Presetting SimpleTester for a run is straightforwardfollow the Configure menu's step by step instructions. First, compile or import Cisco MIBs (Figure 7-6).
Figure 7-6: Cisco MIBsalways needed
Then go to Get Variables to Test and in a new open window, click Settings. Set up your preferences like the SNMP version, ports, save files, and so on, and then launch snmpwalk to collect Object Identifiers (OIDs) supported by the target agent (Figure 7-7).
Figure 7-7: Snmpwalk after the test parameters are set
Then you can follow up with SimpleSleuth, proceeding from SNMPv1 to SNMPv3. (Note that Figure 7-8 shows SimpleSleuthLite, the trial version of SimpleSleuth.)
Figure 7-8: SimpleSleuthLite vulnerability assessment
As in SilverCreek, you can right-click a test case to view the results and packet-generating TCL script that then can become a core of a new exploit. (By the way, the source code of all the 1100-plus TCL scripts used by the tool is freely available.) After all tests are done, open the View menu to generate the summary of testing in several formats, including HTML, and to see the summary of all errors (potential security holes) discovered. Again, do not omit the actual SimpleTestera lot of security- related tests are implemented there, such as sequential and parallel stress testing and Diffie-Hellman key ignition and key change functionality. We particularly liked the VACM (SNMP v2 Viewbased Access Control MIB) test battery for reasons that will be revealed a bit later in this chapter. And from a beta tester's point of view, the RMON (Remote Monitoring, RFC 1271) test tree appears to be very helpful.
Oulu University PROTOS Project
| Popularity: | 8 |
| Simplicity: | 4 |
| Impact: | 10 |
| Risk Rating: | 7 |
Both commercial tools we have described so far are great for professionals who can afford them and are probably irreplaceable for beta testers who check SNMP-standard compliance and security in new devices and operation systems. However, they are not likely to be used by crackers on the Internet or those penetration testers who adhere to open-source politics. And isn't penetration testing about doing what the crackers do, but fixing holes and submitting reports afterward?
Luckily, some open source tools are designed for testing SNMP security and uncovering new flaws in the implementations of this ever-present network management protocol. PROTOS ( http://www.ee.oulu.fi/research/ouspg/protos/ ) is a fine example of such a tool. While not being that pretty or straightforward to use, lacking a nice GUI and requiring a lot of manual work, the PROTOS suite is immensely powerful and can lead to many SNMP vulnerabilities being uncovered (despite the fact that currently only SNMPv1 is supported). A multivendor summary of such vulnerabilities can be found at http://www.cert.org/advisories/CA-2002-03.html , while a Cisco-specific advisory is available at http://www.cisco.com/warp/public/707/cisco- malformed -snmp-msgs-pub.shtml .
To run all PROTOS test suite releases, you need Java Runtime working on your system. How you install Java Runtime is obviously OS/package-dependent and we will not dwell on it here. In a nutshell , you should be able to type java somejavaprogram in a console and execute it. Alternatively, it is possible to feed PROTOS test cases (SNMP packets saved in raw binary) to a target service via netcat, which does not require Java Runtime but involves a lot of manual work. Four PROTOS JAR packages are available for SNMP vulnerability testing two send malicious SNMP requests (c06-snmpv1-req-app-r1.jar and c06-snmpv1-req-enc-r1.jar), and two send malicious SNMP traps (c06-snmpv1-trap-app-r1.jar and c06-snmpv1trap-enc-r1.jar). To see the structure of these packages, unzip them into previously created directories, one directory per package. You will see a wrapper in the FI directory, META-INF , README file, GPL (Gnu Public License), and a /testcases directory with saved binary SNMP packets.
A complete list of test cases for all four packages split by categories can be viewed at http://www.ee.oulu.fi/research/ouspg/protos/testing/c06/snmpv1/index.html#h-ref15 (which we did not deem necessary to reproduce here). These packets were originally created with a Codenomicon Mini-Simulation Toolkit ( http://www.codenomicon.com/products.html ) from a company based in Oulu, Finland. However, you can produce similar packets using Ethereal. For example, suppose you know of an SNMP vulnerability caused by a specific packet X. You send packet X with an attack tool of choice (could be SilverCreek or SimpleSleuth), capture it with Ethereal, and select the SNMP part of the packet (Figure 7-9).
Figure 7-9: A trap sent by PROTOS is captured.
Choose File Export Selected Packet Bytes. A window offering to save raw binary data to a file will open, allowing you to create your very own test case for PROTOS (or any other tool capable of pumping raw data out of a network interface). You may also want to manipulate raw binary data using a hex editor afterward.
Here are some useful hints on basic SNMP hex conventions:
Primitive ASN.1 Types Identifier in hex INTEGER 02 BIT STRING 03 OCTET STRING 04 NULL 05 OBJECT IDENTIFIER 06 Constructed ASN.1 type Identifier in hex SEQUENCE 30 Primitive SNMP application types Identifier in hex IpAddress 40 Counter (Counter32 in SNMPv2) 41 Gauge (Gauge32 in SNMPv2) 42 TimeTicks 43 Opaque 44 NsapAddress 45 Counter64 (available only in SNMPv2) 46 Uinteger32 (available only in SNMPv2) 47 Context-specific types within an SNMP Message Identifier in hex GetRequest-PDU A0 GetNextRequest-PDU A1 GetResponse-PDU (Response-PDU in SNMPv2) A2 SetRequest-PDU A3 Trap-PDU (obsolete in SNMPv2) A4 GetBulkRequest-PDU (added in SNMPv2) A5 InformRequest-PDU (added in SNMPv2) A6 SNMPv2-Trap-PDU (added in SNMPv2) A7
To run PROTOS trap-sending suites, execute
$ java -jar c06-snmpv1-trap-app-r1.jar -host <target IP>
and
$ java -jar c06-snmpv1-trap-enc-r1.jar -host <target IP>
You should see sent cases output, similar to this:
$ java -jar c06-snmpv1-trap-app-r1.jar -host 192.168.66.202 single-valued 'java.class.path', using it's value for jar file name reading data from jar file: c06-snmpv1-trap-app-r1.jar test-case #0: injecting meta-data 0 bytes, data 58 bytes test-case #1: injecting meta-data 0 bytes, data 58 bytes test-case #2: injecting meta-data 0 bytes, data 60 bytes test-case #3: injecting meta-data 0 bytes, data 60 bytes <skip>
The detailed trap sending suite of PROTOS is very handy, since we haven't seen other tools implement it to such an extent, and an IOS host can well serve as a network management system (NMS) accepting and forwarding SNMP traps and informs. To do that, the snmp-server manager command must be entered in a router configuration mode.
As to the more casual SNMP request tests, two additional options should be used when running an attack, namely -showreply and -zerocase . The -showreply flag allows you to see the replies to your requests received back from the agent, and -zerocase sends a typical SNMP ping packet asking for a system name:
Version: 0 Community: "public" PDU-Type: GetRequest GetNextRequest SetRequest RequestID: test-case index ErrorStatus: 0 ErrorIndex: 0 Single VarBind: ObjectName: sys.SysName (1.3.6.1.2.1.1.5.0) ObjectSyntax: empty (GetRequest, GetNextRequest) 'c06-snmpv1' (SetRequest)
This is the test case packet number 00000000. If no reply is received, the server is assumed to be dead. To use this test case, the RO community must be set to public. If it's not, open packet 00000000 in a hex editor and change the community value to public. Both -showreply and -zerocase are not used with SNMP trap tests because it is assumed that trap handling does not involve any replies sent back from an attacked agent.
The commands to run SNMP request tests are
java -jar c06-snmpv1-req-app-r1.jar -zerocase \ -showreply -host <target IP>
and
$ java -jar c06-snmpv1-req-enc-r1.jar -zerocase \ -showreply -host <target IP>
The output should look like this,
$ java -jar c06-snmpv1-req-enc-r1.jar -zerocase \ -showreply -host 192.168.66.202
with single-valued java.class.path , using its value for a JAR filename reading data from the file c06-snmpv1-req-enc-r1.jar.
test-case #0: injecting meta-data 0 bytes, data 40 bytes waiting 100 ms for reply...61 bytes received 00000000 30 3b 02 01 00 04 06 70 75 62 6c 69 63 a2 2e 02 0;.....public... 00000016 01 00 02 01 00 02 01 00 30 23 30 21 06 08 2b 06 ........0#0!..+. 00000032 01 02 01 01 05 00 04 15 63 32 36 31 31 2e 63 6f ........c2611.co 00000048 72 65 2e 61 72 68 6f 6e 74 2e 63 6f 6d re.arhont.com test-case #0: injecting valid case... waiting 100 ms for reply...61 bytes received 00000000 30 3b 02 01 00 04 06 70 75 62 6c 69 63 a2 2e 02 0;.....public... 00000016 01 00 02 01 00 02 01 00 30 23 30 21 06 08 2b 06 ........0#0!..+. 00000032 01 02 01 01 05 00 04 15 63 32 36 31 31 2e 63 6f ........c2611.co 00000048 72 65 2e 61 72 68 6f 6e 74 2e 63 6f 6d re.arhont.com test-case #1: injecting meta-data 0 bytes, data 40 bytes waiting 100 ms for reply...40 bytes received 00000000 30 26 02 01 00 04 06 70 75 62 6c 69 63 a2 19 02 0&.....public... 00000016 01 01 02 01 00 02 01 00 30 0e 30 0c 06 08 2b 06 ........0.0...+. 00000032 01 02 01 01 06 00 04 00 ........ <skip>
The possible outcome of all PROTOS tests can be split into the following categories, with an increasing event severity level:
-
Nothing happens. The agent is invulnerable.
-
The SNMP process hogs CPU and/or memory resources.
-
The SNMP service crashes and restarts.
-
The SNMP service crashes or hangs indefinitely without a restart.
-
Major device failure occurs, and the host hangs, crashes, and reboots.
The question is: which particular packet sent by PROTOS caused this unfortunate event (in particular when trap tests are used)? In the conditions of a testing lab, this problem can be resolved via plugging in a console cable and watching real-time logs as the tests run. When a successful hit takes place, something like this appears: 000013: *Mar 1 2005 00:00:34.764 GMT: %SNMP-5-COLDSTART: . This indicates that SNMP agent on host cisco-2611b is undergoing a cold start and rushes to verify the attack success to get that long-awaited Bugtraq announcement.
You can even run GnuDebugger (gdb) on the SNMP process, sit back, and watch (yes, it is possible under both IOS and CatOSsee the next chapter, as well as Chapter 10). However, even these measures may not give a definitive answer to your question. Neither does the -zerocase option, since you have no way of knowing that the crash wasn't caused by a packet sent a few packets agoafter all, not all crashes happen in a few milliseconds ! You can try to play with a -delay option and launch a parallel ICMP ping to watch. This may well work, but to succeed with -delay you will have to sacrifice the test speed, and sending ICMP and SNMP packets is not synchronized. In addition, on the Internet, ICMP and SNMP packets may take a different route. Remember, after all, that this chapter is centered around black box testing, most likely run from the Internet side!
This is why we have developed a PROTOS-based SNMP fuzzer that solves the problem of determining which particular packet has caused the fault and makes the use of PROTOS fast, simple, and easyso that even the inexperienced security consultants and beta testers can enjoy the power of this suite.
From SNMP Fuzzing to DoS and Reflective DDoS
| Attack |
|
A good example of how examining a protocol with fuzzing tools can lead to real-world attack tool development is CiscoKill by Kundera ( http://www.securityfocus.com/bid/4132/exploit/ ). It is based upon the "Cisco Security Advisory: Malformed SNMP Message-Handling Vulnerabilities" that, as already mentioned, was a result of running PROTOS against a variety of Cisco hosts . CiscoKill spoofs an SNMPv1 GET request packet and crashes Cisco 2600 routers running IOS 12.0(10). It is pretty straightforward to use:
arhontus / # ./ciscokill Kundera CiscoKill v1.0 Usage: ciscokill [-n number of packets] [-s source ip_addr] -t ip_target
Take note how specific the attack is toward a single IOS version and a given router platform. This is usually the case and strongly underlines the importance of very precise device fingerprinting (see Chapter 5) in any penetration-testing procedure that involves Cisco devices. Interestingly, a February 2005 reflective distributed DoS (DDoS) tool, SNMP DoS v1.0, by Fugi ( http://www.packetstormsecurity.org/DoS/snmpdos.c ), borrows code from snmpkill to run its attack, sending spoofed BulkGet (.1.3.6.1) requests to remote routers from the hostfile with a known RO community to force the routers to return reply packets to the target:
arhontus / # ./snmpdos SNMP DoS v1.0 Usage: snmpdos [-t target ip_addr] [-f host file] [-l loop count]
Thus, indirectly, one can also consider this DDoS to be a byproduct of PROTOS SNMP fuzzing of Cisco boxes in 2003, even though this particular and very dangerous attack has nothing to do with specific SNMP vulnerabilities and is rather generic by nature.
A case of basic SNMP fuzzing is sending zero payload UDP packets to a target. Earlier, we mentioned this in relation to protocol stress testing, with the difference being the amount of packets sent. However, both devices, for example, Cisco Catalyst 2900XL switch running IOS 12.0(5.2) XU, and software, for example, early releases of ZoneAlarm Personal Firewall, can be brought down with a few or a single zero payload UDP packet sent to the port 161. Generation of such packets is not difficult using standard packetcrafting tools such as Nemesis or SendIP, although a specific DoS tool is able to bring down the noted Catalyst switch model. It can be downloaded and compiled from http://www.securiteam.com/securitynews/5OP071P4AM.html ; the only input necessary is target and source IPs. A peculiar thing about this particular attack is that it succeeds when the SNMP service is not turned on, which raises the question: what is really listening on port 161, if snmpd is down?
From SNMP Stress Testing to Nongeneric DoS
| Attack |
|
While stress testing is neither pretty nor advanced when compared to detailed protocol fuzzing, it, too, can bear fruit, especially if it's done in a creative way. In theory, a device should not crash if it receives a legitimate SNMPv3 packet. Nevertheless, as stated in the advisories http://www.cisco.com/warp/public/707/cisco-sa-20031215-pix.shtml and http://www.cisco.com/warp/public/707/cisco-sa-20031215-fwsm.shtml , it is possible to crash a PIX firewall or a firewall Catalyst 6500/7600 blade even with a single SNMPv3 request.
Interestingly, neither Cisco Firewall Services Module (CFSM) nor the affected PIX OS versions 6.3.1 and earlier even support SNMPv3. Of course, the device should have the SNMP service running to be affected by this attack. On a PIX, this amounts to having snmp-server host <interface_name> <IP_address> or snmp-server host <interface_name> <IP_address> poll in the firewall configuration file; firewalls that can only send traps with snmp-server host <interface_name> <IP_address> trap are not vulnerable. Exactly the same applies to CFSM blades. The easiest way to generate a lot of SNMPv3 packets to test your devices for this flaw is to run an snmpwalk with -v 3 set:
arhontus / # snmpwalk -c <insert any community here> -v 3 <target IP>
Of course, you may need to spoof the source IP to bypass the restriction imposed by these commands. Net-SNMP utilities do not allow you to set up a custom source IP address. However, netcat does. Send an SNMPv3 packet using snmpget , snmpset , or snmpwalk and sniff it out with Ethereal. Then follow the instructions on dumping the SNMP part of the packet in a raw binary format. Afterward, you can feed the "test case" generated via NetCat using a command like this:
arhontus / # cat evilpacketdump nc -u -s <spoofed source IP> -v <target IP> 161
This technique can also be used for spoofing source IPs when sending all types of malicious packets. Thus, the time spent playing with Ethereal and raw binary format packet dumping when describing PROTOS wasn't in vain, even if you are not interested in SNMP and its security.
Hidden MenaceUndocumented SNMP Communities and Remote Access
| Attack |
|
All the SNMP vulnerability examples we have outlined end up with a DoS attack, which, after all, isn't that exciting. The main point in describing them was to show how they were developed, since exactly the same approach can lead to a discovery of some exploitable flaw that may, eventually, lead to enable. But are there already known security holes that can allow us to access a remote Cisco box using SNMP?
They do exist, and good examples are the hidden or undocumented SNMP communities that can be present on the attacked devices. These can be discovered via intelligent dictionary attacks or sometimes by typing show snmp group on an IOS device to which you have enable access. Various reasons could be used to explain the existence of undocumented communities, ranging from development process errors leading to remaining backchannels to Big Brother conspiracy theories involving three-letter organizations. In the case of the two most well-known undocumented communities in Cisco devices, namely Interim Local Management Interface (ILMI) and cable DOCSIS (Data Over Cable Service Interface Specification), the reason for their existence is standard compliance . Indeed, if you take a look at http://www.protocols.com/pbook/ilmi.htm , you can see the following:
-
ATM SNMP messages must be formatted according to SNMP version 1, not SNMP version 2.
-
ALL SNMP messages will use the community name ILMI.
-
names .enterprises353 atmForum MIBs administration requires RW access.
The same can be said about the DOCSIS 1.0 standard, which states the necessity of a cable DOCSIS RW community. (The standard document stating this is TP-OSSI-ATPv1.1I01-011221. The specification is on 2.1.7 CM Network Management Access and SNMP Co-existence [OSS-07.1], 1 Default Access.) Cisco had to comply with the DOCSIS standards to produce CableLabs certified SOHO Cable Modems ( http://www.cablemodem.com/ ; you can find the documents noted here on this site). In fact, Cisco has tried hard to convince CableLabs that its approach is insecure , but Cisco has had no success and had to fall in line. As a result, UBR920, UBR924, and UBR925 SOHO routers have a RW community accessible from the outside, which means an attacker can do anything he or she wants with these devices. (And that is why it is so important to understand all the SNMP commands described in Chapter 6!) A Cisco security advisory states that "this vulnerability is confined to a very narrow set of IOS releases based on 12.1(3) and 12.1(3)T, and it is fixed in 12.1(4) and 12.1(5)T releases and following." However, cable modems are rarely updated, and finding an ISP with thousands of such devices deployed is a DDoS packet kiddie 's fantasy. In addition, an attacker can sniff the traffic passing through vulnerable cable modems and grab thousands of user credentials and other useful information in a day or two. The methodology of mirroring and sniffing traffic passing through an "owned" IOS box is described in Chapter 10 of this book.
How about the ILMI RW community in IOS versions 11.x and 12.0? Unlike cable DOCSIS, it doesn't hand an attacker full access to the affected system and thus tends to be downplayed. ILMI is a part of asynchronous transfer mode (ATM) networking implementation, essential for ATM host auto-discovery procedure and LAN emulation over ATM (LANE). The ILMI string is always theredoesn't matter whether a physical ATM interface is present on the device or not. Cisco IOS versions prior to 10.3 are not vulnerable to this problem, first introduced in IOS 11.0(0.2). As for the affected devices, the full list can be viewed in the advisory at http://www.cisco.com/warp/public/707/ios-snmp-ilmivuln-pub.shtml . All Cisco IOS software releases of 12.1 and later have the flaw fixed, despite the ATM Forum specifications. According to our observations, the community is still there:
c2600#show version Cisco Internetwork Operating System Software IOS (tm) C2600 Software (C2600-IK9O3S3-M), Version 12.3(6), RELEASE SOFTWARE (fc3) <skip> c2600#show snmp group groupname: ILMI security model:v1 readview : *ilmi writeview: *ilmi notifyview: <no notifyview specified> row status: active groupname: ILMI security model:v2c readview : *ilmi writeview: *ilmi notifyview: <no notifyview specified> row status: active
However, trying to snmpwalk or snmpget it does not return any result and the requests appear to be dropped.
So what can a cracker do using ILMI RW? He or she can modify three MIB subtrees:
-
MIB-II system group that contains basic information about the system
-
LAN-EMULATION-CLIENT-MIB
-
CISCO ATM PNNI MIB
MIB-II system group modification can be used only for pranks , such as changing system.sysContact, system.sysLocation, and system.sysName, like so:
arhontus$ snmpset -c ILMI -v 1 <target IP> system.sysName s "you_are_owned"
Still, it should be noted that snmpgetting system.sysContact, system.sysLocation, and system.sysName values can prove to be very useful in social engineering.
As for LAN-EMULATION-CLIENT-MIB and CISCO ATM PNNI MIB, being able to alter their objects would work only if LANE is set up and running or Private Network-to-Network Interface (PNNI, a "Layer 2 routing protocol" of ATM networks) is in use. But if this is the case, the consequences of a cracker having RW access to these MIBs are grave. Consult the structure of MIBs involved at ftp://ftp.cisco.com/pub/mibs/v2/LAN-EMULATION-CLIENT-MIB.my and http://www.assure24.com/download/mibs/privatemibs/9/CISCO-PNNI-MIB.my and use your imagination to estimate what can be done to the network with a full access to these MIBs. Along with these two "malicious standard compliance" cases is an undocumented SNMP community in various Cisco devices that is purely an implementation error. Such a bug exists in routers running IOS 12.0(7)T, 12.1(1)E, and 12.1(2), and 2900XL and 3500XL series Catalysts running IOS 12.0(5)XU and 12.0(5)XW. This bug is a flaw in the Cisco implementation of the SNMPv2 informs functionality. If a system administrator executes the snmp-server community command, a "community" RO community is added as valid. If it is deleted with the no snmp-server community command and the device is rebooted, the RO community is going to reappear. In addition, if a separate community for sending SNMP traps was configured using the snmp-server host command, this community will also become available for general use and will reappear after reload. While not being a critical flaw, this bug can disclose a lot of information to attackers , which can be used in network enumeration and to take over the device using other SNMP flaws, such as the VACM vulnerability, outlined in the next section.
Finally, a different kind of SNMP vulnerability appears when a configured SNMP community cannot be changed. Cisco ONS15454 optical transport platform and ONS15327 edge optical transport platform software have a preconfigured public RO community that cannot be altered . An attacker can obtain a wealth of information from such a system by walking with this community, and the only thing the system administrator can do about it is to upgrade the Optical Network Solution (ONS) software to versions later than 3.4. Fortunately for these platforms owners , SNMP access to these devices is usually restricted to the LAN side, which means the threat is from internal attackers only.
Getting In via Observation Skills Alone
| Attack |
|
Sometimes getting into a device is as simple as scrupulously examining snmpwalk output or SNMP packets flying across the network. A nice example of such an attack is abusing VACM ( http://www.tools.cisco.com/Support/SNMP/do/BrowseMIBdo?local=en&mibName=SNMP-VACM-MIB ). VACM is a part of the SNMPv3 specification added to IOS 12.0(3)T and CatOS 5.4(1). It is a module that allows system administrators to configure access policies for SNMP device management and happens to contain the name of a configured RW community in cleartext. Practically all post12.0(3)T 12.0 and 12.1 code trains, including 2900XL and 3500XL Catalyst IOS 12.0(5.2)XU and 12.0(5)XW versions, as well as CatOS 5.4(1)5.5(3) and 6.1(1), are considered vulnerable. A curious thing about the VACM flaw is that a Cisco advisory was written to decrease SNMP process-related CPU overload, which is now corrected, that used to lead to VACM exposure if followed through! The "secured" version of the advisory can be viewed at http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a00800948e6.shtml .
Exploiting VACM is easyjust snmpwalk the device with a known RO community and get a RW on a silver plate. Look out or grep for output similar to this: ".iso.org.dod.internet.snmpV2.snmpModules.snmpVacmMIB.vacmMIBObjects.vacmAccessTable.vacmAccessEntry.vacmAccessWriteViewName. private". Or, be more specific and query explicitly for the flaw, like so:
arhontus / snmpwalk -c <RO community> -v 2c <target IP> 1.3.6.1.6.3.16
If a device is not vulnerable, you should get this reply: "SNMP-VIEW-BASED-ACMMIB::snmpVacmMIB = No more variables left in this MIB View (It is past the end of the MIB tree)."
The VACM bug is an excellent illustration of how privileges can be elevated from an SNMP RO to an SNMP RW community in a second.
Another flaw that can be exploited by simple snmpwalking is Cisco Virtual Central Office 4000 (VCO/4K) SNMP-based Telnet credentials leeching. This problem was fixed in VCO/4K software starting from version 5.1.4, but previous versions are considered vulnerable. The VCO/4K is a specialized programmable switch with advanced telephony capabilities such as voice services, switching for wired and wireless networks, and circuit/ packet-switched network gateway services. If you know a VCO/4K RO community, you can easily obtain a valid Telnet username and password to login to the switch. When snmpwalking is performed, watch for usernames and "encrypted" passwords in its output. They would be given away in strings such as enterprises .886.1.1.1.1.<integer>.1 = "username" and enterprises.886.1.1.1.1.<integer>.1 = " obfuscated password" . We have used " encrypted ", since the " cipher " used to hide the password is a basic ROT164(X) = 164-X substitution that replaces each ASCII character by one that is 164 places away. A small Perl script from @stake ( http://www.atstake.com/ ) for decrypting VCO/4K passwords is shown next:
#!/usr/bin/perl printf ("Cisco VCO/4K Password [De]Obfuscator\n"); printf ("\t\@stake, Inc.\n"); printf ("\tRex Warren, Brian Carrier, David Goldsmith\n"); printf ("Enter Password: "); $pw = <STDIN>; chop $pw; printf("Result: "); for ($pos = 0; $pos < length($pw); $pos++){ printf("%s", chr(164 - ord(substr($pw, $pos, 1)))); } printf("\n"); Happy telnetting!
And for the dessert, here is the simplest attack of all (but you do need a few stars aligned to succeed). If you have detected an Aironet 1100, 1200, or 1400 access point with IOS 12.2(8)JA, 12.2(11)JA, or 12.2(11)JA1 on the network, there is a chance that the snmpserver enable traps wlan-wep command is enabled. If that is the case, an access point will send its static WEP key in cleartext inside an SNMP trap to the NMS every time a key is changed or the application processor (AP) is rebooted. Sniff out such a trap, and the wireless network is yours for the taking. If dynamic WEP, Temporal Key Integrity Protocol (TKIP), or Counter-Mode/CBC-Mac Protocol (CCMP) rekeying is enabled, the flaw is gone. It was fixed by Cisco since the IOS release 12.2(13)JA1.
Advanced Countermeasures Against Cisco SNMP Attacks
| Countermeasure | In Chapter 6, we described a basic universal means of hardening Cisco SNMP services selecting hard-to-guess communities, access lists, restricting access to remote TFTP servers, and SNMP view Object Identifiers (OID) filtering foundation. Here, the focus is on using SNMPv3 and view filtering for the example vulnerabilities we've described. |
The universal answer to the problems described is switching to SNMPv3 altogether, abandoning the weak SNMPv1 security model. Of course, switching to SNMPv3 presumes using AuthPriv to supply both authentication and SNMP packet encryption.
First, create a secure SNMP group:
c2600#conf t c2600(config)#snmp-server group <group name> v3 priv
Then create legitimate SNMP users within the group:
c2600(config)#snmp-server user <username> <group name> v3 \ auth md5 <authentication password> priv des56 <des key>
Interestingly, when running show running-config , the SNMPv3 user is hidden for security reasons, and all that can be seen is the group:
! snmp-server group <group name> v3 priv !
Of course, it is possible to bring access lists (statement "access") and SNMP views (statement "read") into the game and even combine them. Both statements can be used with group and user definitions, depending on the level of access granularity needed. Here are some examples:
-
c2600(config)# snmp-server group <group name> v3 priv access 8 will add a standard access list number 8 to the SNMPv3 group security settings.
-
c2600(config)# c2600(config)#snmp-server user <username> <group name> v3 auth md5 <authentication password> priv des56 <des key> access 8 will add this access list specifically for a selected user.
-
c2600(config)# snmp-server group <group name> v3 priv read MyView will add a MyView to the SNMPv3 group security settings.
-
c2600(config)# c2600(config)#snmp-server user <username> <group name> v3 auth md5 <authentication password> priv des56 <des key> read MyView will add this view specifically for a selected user.
-
c2600(config)# c2600(config)#snmp-server user <username> <group name> v3 auth md5 <authentication password> priv des56 <des key> read MyView access 8 will combine MyView view and access list 8 for a user.
Moving more specifically to the views, this is how you block access to VACM objects, if for some reason upgrading the OS to a fixed version is not feasible :
c2600(config)# snmp-server view novacm internet included c2600(config)# snmp-server view novacm internet.6.3.16 excluded c2600(config)# snmp-server community <RO community string> view novacm RO
To stop cable DOCSIS abuse, a simple access list would suffice:
c2600(config)# access-list 50 deny any c2600(config)# snmp-server community cable-docsis ro 50
Finally, to block the "community" community abuse, always set a valid RO community string before enabling the snmp-server host command. If you don't want an accessible RO community and your aim is to generate traps, use an access list to block all access to it:
c2600(config)# access-list 50 deny any c2600(config)# snmp-server community <RO community string> ro 50 c2600(config)# snmp-server host <NMS IP> <RO community string>
Everything we have just outlined is IOS-based. How about CatOS? Well, in Chapter 6 we already reviewed setting SNMP views and access lists on CatOS, and this knowledge combined with the preceding description of bug fixes should be sufficient to block VACM and "community" access on the affected switches.
As for SNMPv3, setting it up on a CatOS switch isn't difficult:
Catalyst5000(enable) set snmp group <group name> \ user <username> security-model v3 Catalyst5000(enable) set snmp user <username> \ authentication <MD5SHA> <authentication key> privacy <DES key>
If you wish to add a view for MIB objects reading or writing to the SNMPv3 security settings on a Catalyst, use a command similar to
Catalyst5000(enable) set snmp access <group name> security-model v3 privacy read <View 1> write <View 2>
If you want to remove a user or user group, execute the same commands with " set " replaced by " clear ".
Brief SNMPv3 Security Analysis
How secure is SNMPv3? Can we actually rely on it for SNMP data and services protection? Let's take a brief look at how authentication and encryption of SNMPv3 packets is done.
SNMPv3 Packet Authentication
SNMPv3 packet authentication is handled using HMAC-SHA-1 or HMAC-MD5. The output is truncated to 12 octets, which is a basic anti-collision protection mechanism; 16 octets MD5 or 20 octets SHA-1 authentication keys stored in msgAuthParameters are used. This looks like a feasible authentication scheme. However, nowadays, MD5 is not considered to be highly secure. And even a more secure SHA-1 is starting to get cracks see http://www.schneier.com/blog/archives/2005/02/sha1_broken.html for reference. It is a pity that longer key SHA versions, such as SHA-2 384 bit and SHA-2 512 bit, are not supported by the standard. But even if so, such authentication schemes can still fail to a dictionary or bruteforce attack if weak keys are selected.
SNMPv3 Packet Encryption
To protect the confidentiality of SNMP data, 64-bit DES is employed. If you are familiar with the basics of cryptography, you can recall that 8 padding bits are in a DES key. That is why the actual DES key size is 56 bits, which is reflected by Cisco command-line syntax. It is somewhat surprising that a protocol standard finalized in the year 2002 years past the successful DES crackingstill uses this symmetric cipher and not AES (Rijndael) for data encryption. SNMPv3 uses DES in a Code-Based Chain (CBC) mode, which depends on a 64-bit IV (initialization vector). The IV is made by taking the last 8 octets of the 16-octet shared secret key and XORing them with an 8-octet salt value. Only the salt value, stored in the msgPrivacyParameters SNMP packet field, is transmitted across the wire. Here comes a second problem (the first being not using AES): there is no standard for salt generationit is left as an exercise for vendors implementing SNMPv3 in their software. This provides a venue for both intercompatibility issues and implementation errors. And just as with the authentication scheme, beware of weak keys that may fall to a dictionary or bruteforce attack.
To conclude, SNMPv3 is sufficiently secure, especially compared to the SNMPv1 security model. Alas, nothing is perfect.
| | ||
| | ||
| | ||
EAN: 2147483647
Pages: 117