Neither SNMPv1 and SNMPv2c have any security beyond a plaintext community string. The default community strings for read and write access are ‘public’ and ‘private’ respectively. Some Cisco devices use ‘ilmi’ as the default community string.

We can use the tool ‘onesixytyone’ to attempt to brute force the name of the community string from a dictionary:

root@pwn:/pentest/enumeration/snmp/onesixtyone# ./onesixtyone -c dict.txt 10.0.10.51
Scanning 1 hosts, 51 communities
Cant open hosts file, scanning single host: 10.0.10.51
10.0.10.51 [public] Linux dev1 2.6.32-5-686 #1 SMP Sun Sep 23 09:49:36 UTC 2012 i686

The community string was successfully brute forced, and is set to the default, ‘public’.

We can now use ‘snmpenum.pl’ to enumerate the host based on this information (some parts truncated to save space)

root@pwn:/pentest/enumeration/snmp/snmpenum# ./snmpenum.pl 10.0.10.51 public linux.txt |more
----------------------------------------
	UPTIME
----------------------------------------
69 days, 23:25:26.39

----------------------------------------
	HOSTNAME
----------------------------------------
dev1

----------------------------------------
	RUNNING SOFTWARE PATHS
----------------------------------------
init [2]
[...]
/sbin/portmap
/sbin/rpc.statd
/sbin/syslogd
/sbin/klogd
/usr/sbin/acpid
/usr/bin/dbus-daemon
/usr/bin/memcached
/usr/sbin/inetd
/usr/sbin/atd
/usr/sbin/cron
/usr/local/sbin/openvpn
/sbin/getty
/sbin/getty
/sbin/getty
/sbin/getty
/sbin/getty
/sbin/getty
/usr/sbin/exim4
/usr/sbin/apache2
/usr/sbin/apache2
/usr/sbin/apache2
/usr/sbin/apache2
/usr/sbin/apache2
sshd: npn [priv]
sshd: npn@pts/2
-bash
/usr/sbin/apache2
sshd: root@pts/0
-bash

----------------------------------------
	RUNNING PROCESSES
----------------------------------------
[...]

----------------------------------------
	MOUNTPOINTS
----------------------------------------
Physical memory
Virtual memory
Memory buffers
Cached memory
Swap space
/
/boot

----------------------------------------
	SYSTEM INFO
----------------------------------------
Linux dev1 2.6.32-5-686 #1 SMP Sun Sep 23 09:49:36 UTC 2012 i686

----------------------------------------
	LISTENING UDP PORTS
----------------------------------------
111
161
514
726
35867
57858

----------------------------------------
	LISTENING TCP PORTS
----------------------------------------
22
111
1194
3306

Whilst making this information available to an attacker provides a wealth of opportunity for further attack, SNMP can be used for more than just reading data. SNMP can also be used to write data to a device. Consider the following attack scenario that I’ve seen before against a Cisco router. In this case, SNMP had actually been firewalled to only allow a specific host to connect on that port, however the community strings had been left at public and private, and remember that single packet UDP requests are easily spoofed. The Cisco router was 192.168.0.1, the allowed host was 192.168.0.2 and the attacker’s IP was 192.168.0.101. The attack steps were –

1. Send a spoofed SNMP write request from 192.168.0.2 instructing the router to dump it’s running-config to a TFTP server hosted on 192.168.0.101
2. Modify running-config received by TFTP to change the encrypted enable secret (root password) to ‘pwned’.
3. Send a spoofed SNMP write request from 192.168.0.2 instructing the router to load a new running-config from TFTP server hosted on 192.168.0.101
4. Connect to router and enter password ‘pwned’
5. Game over. We now own the router and can control and redirect traffic as we wish.

SNMPv3 was released to address some of the security flaws in previous versions. The most notable bugs in SNMPv3 apply to unpatched versions that suffer an HMAC verification flaw (CVE-2008-0960). Exploit at exploit-db.

The recommended course of action if SNMP is required on the network is to use an up to date SNMPv3 implementation.