Hack Like a Pro: How to Exploit SNMP for Reconnaissance
Welcome back, my rookie hackers!
The more we know about a system or network, the better our chances of owning it and not leaving a trace for investigators to follow. One of the often overlooked sources for information is the Simple Network Management Protocol (SNMP). Many rookie hackers are not even aware of it, but it can prove to be a treasure trove of information, if you understand how it works and how to hack it.
SNMP runs on UDP (connectionless and efficient) on port 161 and enables a network administrator to gather information on and manage network devices. Each networked device responds with information about its make, model, etc. when queried by the master.
All this information is then stored in a database called the Master Information Base (MIB). If we can access the MIB and know how to read and interpret the info, we can then know each and every device on the network. If we can crack the password on SNMP, we may be able to control each networked device. This would allow us to change configurations, take devices offline, etc.
There are at least three versions of SNMP. The first, SNMPv1 or just SNMP, was not secure. SNMPv2 was developed to be more secure, but was not backwardly compatible to v1. SNMPv3 is secure and backwardly compatible, but very often, not implemented.
SNMPv1 has a default community string (similar to a password) for the admin of "private" and a default community string for everyone and everything else of "public". The admin password permits the admin to change configurations of devices remotely, while the public password only allows us to view the info in the MIB. Many times, system admins leave these passwords in the default configuration due to lack of knowledge or laziness. Before you try any hack on SNMP, make certain you try these default passwords first.
Even if the system admin does change the default passwords, they often change them to a variation of public/private or something else very simple. Generally, these passwords are relatively easy to brute-force with a dictionary attack.
In this hack, we will look at what info we can harvest from the SNMP MIB if the network is using SNMPv1 and we know the community string. In a future tutorial, I'll show you how to break the community string.
All of the tools we need for this hack are built into BackTrack, so we have no need to download or install any new software.
In this hack, we will use a tool called snmpenum. It gathers information from the MIB over SNMP for any IP address, if we know the community string.
To start, go to BackTrack -> Information Gathering -> Network Analysis -> SNMP, and finally, snmpenum.
When you click on snmpenum, it will open a terminal that will look like this.
Note that the syntax for running snmpenum is fairly straightforward. All you need is the IP address, the community string, and the config file. If we do a long listing on this directory:
- ls -l
We can see that there are three text files that are our configuration files for snmpenum. We have one for Windows, one for Linux, and one for Cisco.
In this case, we will be running snmpenum against a Windows machine that still has its default SNMP community string (password) set to "public" that is on our internal IP address of 192.168.1.101. Note that snmpenum is a Perl script, so it ends with .pl. To run it, we must precede it with the "./".
Simply enter this information as follows:
- ./snmpenum.pl 192.168.1.101 public windows.txt
When we run snmpenum, it gathers all the information in the MIB database on the target machine and displays it on the screen. The amount of information covers several screens, but it will return users, installed software (see below), hostname, OS, uptime, services, open TCP ports, open UDP ports, and more!
Here we see the listening ports:
Here we can see all the running services:
Now that we have gathered all this information on the system, we can better develop a strategy for exploiting it. We simply need to then find the known vulnerabilities for that OS, those services, those ports, etc.
In addition, with the uptime, we can gauge when the system was last patched. If the the uptime is say, three months, we know that the system is vulnerable to any new vulnerabilities discovered in the last three months as a patch would require a reboot of the system.
Keep coming back, my rookie hackers, for more adventures in hackerland!