Digital forensics

Vulnerability Assessment of SNMP Service – II

May 17, 2013 by arD3n7


This is our second article in a series on vulnerability assessment of SNMP Service. In the previous article, we learned how we could set up a SNMP Service on a Linux box (Ubuntu in our case). From this article onwards, we’ll start covering tools that we can use when we find SNMP service running on a remote machine. These tools will aid us in gathering important information.

Intended Audience:

This series of articles is written for people who have basic knowledge but want to learn more about SNMP, what needs to be done to perform security assessment of SNMP Service, and extract useful information that can be helpful in the further fine-tuning of VA or PT exercises.


For this article, we assume that the user has access to a machine running an SNMP service. You can also refer to my previous article to learn how to set up a vulnerable SNMP service on a Linux box.


In this article, we’ll first get into a little technical overview of SNMP, which will be helpful to the readers to understand the basic things that a penetration tester needs to know about SNMP protocol. This the bare minimum information required for a starter before jumping on to SNMP and pulling up tools against boxes. One can do that, however, that won’t help much because you may not know what you are doing and why you are doing so.

We’ll learn how to locate hosts running the SNMP service on a network. We’ll also explore tools that we can use for achieving this task. We’ll start with a basic port scan to locate hosts running an SNMP service on the network, and then we will learn more about a tool that can help us do a quick check on the network to find hosts that are running an SNMP service with default community strings.

SNMP – A Technical Overview:

I’ve covered a brief overview of SNMP in the previous article, however it’s not technical. Before pointing and shooting tools, we need to learn few basic concepts. SNMP or Simple Network Management Protocol managed network consists of 3 major components:

  1. Managed Device:

    A managed device is a device or a host (technically known as a node) which has the SNMP service enabled. These devices could be routers, switches, hubs, bridges, computers etc.

  2. Agent:

    An agent can be thought of as a piece of software that runs on a managed device. Its primary job is to convert the information into SNMP compatible format for the smooth management of the network using SNMP protocol.

  3. Network Management System (NMS):

    These are the software systems that are used for monitoring of the network devices. We’ll not get into much detail about NMS as they are not of much interest to us.

Following is a visual representation of SNMP Managed Network:

Now that we know what an SNMP managed network consists of, let us quickly get into the information which is of interest to us. We’ll review two major concepts about the protocol itself here. The first is known as Management Information Base (also known as MIB), and the second is Community Strings.

Management Information Base (MIB):

Management Information Base is basically a repository or collection of information organized hierarchically. We’ll not get into the technical details of how this data is organized at this point in time as it is not required for a starter. However, if you wish to write your own tool to retrieving info via SNMP, then it is important to understand it.

Community String:

An SNMP community string is a text string which acts as an authentication token (a password basically) between the management stations and network devices on which SNMP agents are hosted. Community Strings travel in clear text over the network, hence are subject to network sniffing attacks. Community Strings are sent with every network packet exchanged between the node and management station.

For the management station to discover and manage network devices, the device needs to be SNMP enabled and the community string sent by the NMS over the network should match the community string of the device. Also, the firewall on the remote device should be configured to permit the traffic, as firewalls will block the SNMP traffic by default.

There are two different modes in which SNMP operates and both of these modes have different community strings:

  1. Read only

    This mode permits querying the device and reading the information, but does not permit any kind of changes to the configuration. The default community string for this mode is “public.”

  2. Read Write

    In this mode, changes to the device are permitted; hence if one connects with this community string, we can even modify the remote device’s configurations. The default community string for this mode is “private.”

Now that we understand the important concepts that are required, let’s move to the next stage. It is known as Port Scanning.

Port Scanning:

Port scanning is a technique used to identify the services running on the remote host. We’ll not get into a detailed introduction of what port scanning is and how does it work, however for the sake of this article, it is sufficient to understand that we can use this technique to know if a particular IP Address on the network has SNMP service enabled or not.

We’ll use Nmap tool to perform a port scan on target system to check if SNMP is enabled or not. By default, SNMP runs on UDP port number 161. Unless explicitly configured, SNMP will not run on a different port.

Nmap could be downloaded from It is freely downloadable. Once installed, run the command as shown below on the target to see if SNMP is enabled.

Nmap switches This switch of Nmap is used to scan a UDP port. Since SNMP runs on the UDP port by default, we need to use this switch. Switch “p” is used to define the port number, hence 161 is followed by switch “p“.

Let us see what the output of above command is.

The following screenshot shows the output of the command:

As we can see, SNMP is enabled on the target machine. The service identified is “SNMP.” A detailed description of all Nmap switches and how it works is out of the scope for this article. However, if a reader is interested in these details, he or she can refer to the product documentation.

For readers interested in penetration testing of entire networks, please do note that you need to sweep the entire network, which may contain multiple subnets to harvest the details of IP Addresses which have SNMP service enabled.

The next step for us is to check if default community strings are enabled or not. If we find out any such host, consider it as a lottery because SNMP can give us lots and lots of information, which otherwise could have been hours worth of work for a penetration tester.

We’ll be using a small utility available in backtrack for the same. The tool is known as “onesixtyone“. To invoke this utility, just type “onesixtyone” at the command prompt and you’ll see something like the following:

Onesixtyone is basically a utility that can be used to bruteforce the SNMP community strings. It takes a list of hosts as an input and a password dictionary. It supports large dictionary files and is quick in checking if any of the passwords match. This is very helpful to penetration testers because during a pentest one wants to do quick checks to identify whether any of the hosts, out of a gamut of devices identified running SNMP, are running with default passwords. If there is more time and one wants to go ahead and check it against large dictionary, it could be done as well. The tool caters to both these requirements.

We’ll now run the Onesixtyone against our identified target to do a quickly check if it is running on the default community string. However, before that, let us create input files which we can feed to the tool.

We’ll first create a list of targets as follows:

If you have more than one target, you can use text editor like Nano or vi to key in the IP addresses manually.

Next we’ll create a community list dictionary which could be fed to the tool. In our case, we’ll only feed community string “public” because we want to check if it is the host. You can create a dictionary as shown in the following figure:

The “cat” command will show the content of the file on screen. Since our input file contains only one string, it is displaying the same back on the screen.

All right, we are good to fire up the tool now against our host. The aim of this step is to check if our target host is using the default community string “public” or not. The command to run the tool is as follows:

Switch “i” is used to input the target file which we created previously. This will be treated as a target list and every host mentioned in the input file will be tried one by one against the password dictionary that we fed to the tool using switch “c.” It is a very light weight and quick tool and produces faster result – thus avoiding any delays for penetration testers.

If a match is found by the tool, then we can dig deeper to extract the information that can be valuable during the penetration test. The following screenshot shows the result of the scan we just ran against our target system. The output confirms that community string is indeed valid.

If the scan fails to match the community string, no output is provided. The following is a screenshot taken after changing the content of dictionary file to a different community string and then running the scan against our target system.

As you can see, we don’t get any output of the above scan. This way we can quickly enumerate all live hosts to check which of them use default community strings to identify a juicy list of targets which can be further drilled to squeeze out important information.

What Next?

From the next article onwards, we’ll dig into tools that could be used for information gathering using SNMP. We’ll cover different tools one by one and see what all information we can gather using SNMP protocol. You’ll be surprised to see how much information could be obtained in this way by exploiting the default configuration of SNMP.


Posted: May 17, 2013
Articles Author
View Profile

arD3n7 works for a leading IT company and is deeply passionate about information security. As a researcher, arD3n7 loves anything and everything related to penetration testing.

Notice: Undefined index: visitor_id12882 in /www/resourcesinfosecinstitute_601/public/wp-content/plugins/infosec-user-info/infosec-user-info.php on line 117