This is the third article of this series of articles on vulnerability assessment of SNMP Service. In the previous two articles, we have covered how to set up SNMP service and how to discover SNMP enabled devices on the network using the Nmap tool. We also covered the tool onesixtyone – which is part of a backtrack suite of tools. Using this tool, we can quickly narrow down our scope by identifying devices that are running with default configurations. Intended Audience: While this entire series of articles was written keeping in mind people who have basic knowledge but want to learn more about SNMP, from this article onwards, we will jump right into the exploitation part. Hence I’ll assume that readers are already up to speed and have the basics clear. In case you are a newbie and have stumbled upon this article directly, I recommend you read Part I & Part II of this series first before jumping directly on to this part. For Advanced users who already have the required knowledge and are already up to speed, you can use this article as a reference guide. I am planning to cover exploitation tools for SNMP protocol, and from here on, these will be completely hands-on articles. Objectives: This article will focus on a tool called “snmpcheck” that can be used to harvest the information from hosts running default installations of SNMP. Using “snmpcheck” tool, we can enumerate information like system up time, host name of the remote system, users on the remote system, software installed with their exact versions, a list of running processes and a list of all TCP and UDP ports and many other details. Assumptions: For this article, we assume that a reader has access to the following:
A host running SNMP service with default SNMP configurations. Backtrack Linux ISO or a Virtual machine with Backtrack installed which will be needed to launch our tools. Readers can also use other Linux installations; however, in that case, they need to set up the tools that we’ll cover on the box on their own.
Snmpcheck Usage: Snmpcheck runs through the SNMP’s MIB retrieving the information stored and displaying the same in a user friendly manner which could be read by a layman. As discussed in my previous article, MIB is where all the interesting information is stored and this is what we need to query if we were to manually extract the information. The tool automates this task and gives us exactly what we need without going into the technical details of SNMP syntax. “Snmpcheck” basically uses Perl’s “Net::SNMP” module and creates SNMP requests which in turn are sent to the target to probe the remote host’s SNMP configurations. However, this will only be possible in cases where the community string of the remote host is known to the tool, without which the authentication will fail and we’ll not be able to retrieve any information from the target. This is was the reason why we explicitly discussed the community string related information in the last article. It is “the” most important piece of information as without it any of our tools are hardly of any help. We can use multiple switches (also sometimes known as options) to pass additional parameters to the tool. This way we can get the tool to deliver our desired result. Let’s examine each switch one by one.
“t” – This switch is used to specify the target IP address on which we want to run the tool. “t” is a mandatory switch. Tool can never work without a target. “w” – This switch is used to confirm whether the target IP address has write access enabled or not. “w” is an optional switch. Not all devices will have write access enabled, but if any of the network devices has write access enabled and if we can brute force the community string for SNMP write mode, we can even make configuration changes on the remote host. “p” – This switch is used to specify the port number on which SNMP service is running on target node. This is an optional switch and if the end user does not specify a port number when running the tool, then snmpcheck will take the default configuration. By default, the tool is configured to run on UDP port 161. “c” – This switch is used to specify the community string. This switch is also optional. Default configuration is “public”. “v” – This switch is used to specify the SNMP version in case the user knows what is running on the target box. This switch is optional as well. Default configuration for this switch is “version 1”. “r” – This switch is used to specify the number of retries. It is required in case an end user wants to explicitly instruct the tool to try for “x” number of times before giving up on a host. This switch is optional as well and defaults to a single retry. “d” – This optional switch disables connection to TCP ports when specified, thus avoiding the overhead time (maybe a couple of seconds) which snmpcheck would otherwise take. “T”– This switch allows the end user to configure a specific timeout (in seconds). Unless explicitly specified, the timeout is set to 45 seconds since this switch is optional. “l” – It enables the logging feature of the tool when specified but it need not be mandatorily specified though. “h” – This pulls up the help menu of the tool which can aid the user for quick reference of the switches they can use to fine tune its behavior and output.
Now that we have good information of what snmpcheck is all about and the options it supports, let’s fire it up against our vulnerable system.
Invoke the tool To invoke the snmpcheck tool, navigate to /pentest/enumeration/snmpcheck directory. It is a Perl script with the name snmpcheck.pl. The following screenshot shows how we can invoke it on backtrack. Running the tool To run the tool, we need to point it to the target IP Address using the “t” switch and specify the community string using the “c” switch. The exact command is shown in the following figure.In the above command, I am piping the output of the command to a text file – snmpcheck_results.txt. This way, every time we need a quick check on results, we have the text file Result: Snmpcheck will generate a lot of output and hence it is a good idea to pipe out the results to a separate file. Also the output file will be very helpful later on as we may need to use our Linux skills to run grep, sed or awk commands for efficient text processing, thus retrieving only the necessary information rather than running through a dump of data when all we are looking for is a single line in the entire file, or a couple of them for that matter. Following is an excerpt of output which has been captured by piping it out to “more” command.
These are only some of the screenshots of the entire file. The output is indeed huge as it lists down a lot of data. The best way to check it out is by running it against your own network or vulnerable host. Check if Write Access is enabled: There is one important piece of information which we still have not checked: “write” access. We haven’t yet verified if write access is enabled on the remote server. If it is enabled, it will even permit us to make configuration changes on the remote host or node.We can check whether write access is enabled or not by adding one more switch to our initial command “-w”.The command looks something like follows:
I am piping the output of the command to “grep” to focus only on the details that we are interested in, i.e. checking whether write is enabled or not. If the output of the above command is blank, then it means that write access is not enabled on the remote host. I’ve not included a community string in the above command since default configuration is “public” which indeed matches with our target’s community string. I included the community string using the switch “c” in the first command for the purpose of demonstration, as one will have to explicitly specify the community string where it is different from the default. Let me quickly demonstrate how the output would look if write access is not enabled. I ran the tool a second time after disabling the write access on the concerned target and this time, we have a different output. “Snmpcheck” timed out, and the output is significantly different from the previous one. One thing notable here is that the tool did connect to the remote host, so the timeout shown is definitely not a connection timeout. However, this timeout is in its attempt to connect to the target in “write” mode.
What Next?
We already know how to extract data from the SNMP service using the Snmpcheck tool. In the next article I’ll cover one more tool that could be used by readers for data extraction from the SNMP service.
References: These are only some of the screenshots of the entire file. The output is indeed huge as it lists down a lot of data. The best way to check it out is by running it against your own network or vulnerable host. I am piping the output of the command to “grep” to focus only on the details that we are interested in, i.e. checking whether write is enabled or not. If the output of the above command is blank, then it means that write access is not enabled on the remote host. I’ve not included a community string in the above command since default configuration is “public” which indeed matches with our target’s community string. I included the community string using the switch “c” in the first command for the purpose of demonstration, as one will have to explicitly specify the community string where it is different from the default. Let me quickly demonstrate how the output would look if write access is not enabled. I ran the tool a second time after disabling the write access on the concerned target and this time, we have a different output. “Snmpcheck” timed out, and the output is significantly different from the previous one. One thing notable here is that the tool did connect to the remote host, so the timeout shown is definitely not a connection timeout. However, this timeout is in its attempt to connect to the target in “write” mode.
What Next? We already know how to extract data from the SNMP service using the Snmpcheck tool. In the next article I’ll cover one more tool that could be used by readers for data extraction from the SNMP service. http://en.wikipedia.org/wiki/Simple_Network_Management_Protocol
