Simple Network Management Protocol – SNMPv1 Threat Assessment

Written by peanuter on January 20, 2013 Categories: Threat Assessment Tags: , ,

SNMPv1 is a UDP protocol used on thousands of devices and most business networks in the world. It is a completely insecure protocol which makes it a broad target for attacks. It is my hope that after reading this document you will have a firm grasp on how to assess the security of an SNMPv1 implementation and get a coveted compromise on your target network.

Diagram which shows individual points of external attack against SNMPv1. A definitive threat model showing weaknesses at every potention angle.

This is a diagram exposing weaknesses within the SNMPv1 Protocol Implementation

As you can see the threat landscape for this protocol is broad and deep. I am sure your mind is puzzling over the various vulnerabilities that can be exposed by potential misuses of the protocol.

There are two levels of authentication you can obtain with SNMPv1. Read which commonly has the community string ‘public’ and Read/Write who’s community string is normally ‘private’.

Since this is a UDP connectionless base protocol by design spoofing becomes a concern unless ingress filtering is used on the target network. Spoofing can allow an attacker to attempt to penetrate equipment without exposing there true IP. Later you will find a modified version of snmpblow that allows for a spoof based bruteforce attack against Cisco’s SNMPv1 implementation to do a complete remote compromise which illustrates this vulnerability.

To scan for SNMPv1 I prefer onesixtyone-v0.7 a fast concurrent SNMPv1/SNMPv2 sweeper.

onesixtyone v0.7 ( http://labs.portcullis.co.uk/application/onesixtyone/ )
Based on original onesixtyone by solareclipse@phreedom.org

Usage: onesixtyone [options] <host> <community>
-c <communityfile> file with community names to try
-i <inputfile>     file with target hosts
-o <outputfile>    output log
-d                 debug mode, use twice for more information

-w n               wait n milliseconds (1/1000 of a second) between sending packets (default 10)
-q                 quiet mode, do not print log to stdout, use with -l
examples: ./onesixtyone -c dict.txt 192.168.4.1 public
./onesixtyone -c dict.txt -i hosts -o my.log -w 100

While using onesixtyone you will see that it is missing, what I consider to be a key feature, host list generation. Here is a simple perl script to do just that.

#!/usr/bin/perl
use Net::IP;
my $ip = new Net::IP (“@ARGV”) || die(“Usage: $0 192.168.1.1-192.168.2.254 > IP_List.txt\n”);
do { print $ip->ip(), “\n” } while (++$ip);

You will likely need to install a perl module to use it. In Ubuntu you can simply

aptitude install libnet-ip-perl

On other operating systems this should suffice

# perl -MCPAN -e shell
cpan> install Net::IP

In the end your results will look something like this. Two class C’s trimmed to save space on the blog.

# ./onesixtyone -c common.txt -i ips.txt
Scanning 506 hosts, 2 communities
24.30.60.4 [public] Linux WNR1000v2 2.6.15 #199 Thu Jan 28 09:49:57 CST 2010 mips MIB=01a01
24.30.60.25 [public] Linux WNR1000v2 2.6.15 #199 Thu Jan 28 09:49:57 CST 2010 mips MIB=01a01
24.30.61.62 [private] Linux WNR1000v2 2.6.15 #199 Thu Jan 28 09:49:57 CST 2010 mips MIB=01a01
24.30.61.211 [private] Linux WNR1000v2 2.6.15 #199 Thu Jan 28 09:49:57 CST 2010 mips MIB=01a01
24.30.61.246 [private] Linux WNR1000v2 2.6.15 #199 Thu Jan 28 09:49:57 CST 2010 mips MIB=01a01

A great way to glean information from SNMP after you have a valid community string is to snmpwalk it. If you want to see an example of its output and how much information you can glean from a machine here is a walk of snmpwalk_of_24.30.60.4. Take the time to review this but realize that another tool has been made called snmpenum which will gather more critical information and make it presentable for your audit report.

Organizational use of SNMPv1 can lead to a compromise on almost any business network. Such as gaining access to Cisco devices. I am sharing my snmpblow-revised for when the community string is not ‘private’.

Usage: snmpblow-revised.txt -s srcipaddr [-S srcport] -d dstipaddr [-D dstport] -t tftpsipaddr -f cfgfilename -q startpasswd -T forks

So this revised snmpblow allows you to bruteforce a password using a spoofed source IP address in the UDP packet as well as forking. I suggest when attacking not to go above 20 forks. Cisco devices will stop accepting SNMP queries to guard against a DoS situation. You will know when it was successful by seeing the cisco config showing up in your tftp’s file directory.

Inside of an organizations network you can be sure to find windows devices using the protocol as it is used to alert on workstation issues with network analysis software such as NAGIOS. I have seen wireless network intrusion detection systems utilizing SNMP and kernel modifications to detect attacks on Access Points.

We can identify the SNMP Community string used on a network merely by sniffing a machine. Here you can see the community string is ‘private’ using tcpdump.

# tcpdump -vv port 161
tcpdump: listening on all devices
11:40:51.570203 eth0 > nms.server.51524 > 192.168.1.14.snmp:
|30|60|02|01SNMPv1|04|09C=private|a0|50GetRequest(80)
|02|04|02|01|02|01|30|42 |30|11|06|0dE:cisco.9.13.1.3.1.3.1|05|00
|30|11|06|0dE:cisco.9.13.1.3.1.3.3|05|00|30|0c|06|
08system.sysUpTime.0|05|00 |30|0c|06|08system.sysName.0|05|
00 (DF) (ttl 64,id 0)

Many manufactures include hidden MIB OIDs into there SNMP implementations. A great example of this is Motorola Modem Hacking with Hidden MIB OIDs illustrating several sever security weaknesses exposed by the use of hidden MIB OIDs.

SNMPv1 Control Commands threat and attack model for assessing the security of there implementation.

SNMPv1 Control Commands threat and attack model for assessing the security of there implementation.

 

As you can see our threat landscape again is very large. I feel that the best black box fuzzing technique is to attack the system specific MIB OIDs.

There are several tools for automating fuzzing attacks. I dislike the concept of using a canned fuzzer for the most part but I am partial to reviewing what other people have built and implementing similar setups. For an example of a good fuzzer to determine how you wish to attack our control commands I suggest you review snmp-fuzzer-0.1.1.tar. 

Another aspect I want to leave you with to consider is SNMPv1 on the lowest level packet manipulation. When analyzing any protocol it is truly important you get down to the guts of the request itself and I have developed a simple perl script to help you do just that. SNMP_PacketGenerator will allow you to fiddle with any low level ideas you might have about the implementation you are reviewing.

Module installation require for SNMP_PacketGenerator

#aptitude install libnet-rawip-perl

Functionality offered with SNMP_PacketGenerator

# ./SNMP_PacketGenerator.txt
Usage: snmp_udp_poc.pl <our ip address> <there ip address> <ip packet length> <udp packet length> <source port> <udp checksum
Example: perl udp.pl 99.55.24.2 66.18.18.18 0 0 40 2011 0
By setting <ip packet length> or <udp packet length> or <checksum> to zero Net::RawIp will replace them with correct values.
Enjoy! peanuter@darpanet.org

Some ideas might be throwing valid SNMP requests with additional data after the data frame. Perhaps try issuing random data at each particular control command within the data frame itself. Adjust packet length and let Net::RAWIP correct the checksum itself. Issue a bad checksum and see if the SNMPd accepts the invalid packet! Issue the control command “get” on a valid server while running wireshark to strip sections of a different valid packet you wish to test. Do the same with control command “set”! Roll your own, and most importantly have fun while calling it research.

No Comments on Simple Network Management Protocol – SNMPv1 Threat Assessment

Leave a Reply

Your email address will not be published. Required fields are marked *