This is the fourth article on vulnerability assessment of SNMP service. So far we’ve covered the basics, discovery, and data extraction using various tools from the SNMP Management Information Base. We have also covered the point and shoot tool “snmpcheck“. We can quickly enumerate data stored in SNMP’s OID using it; however this tool is more or less point and shoot. Objective: While “snmpcheck” is easy to learn and is straightforward to use that you can quickly fire it against potential targets, it does not give us fine-grained control to explore the entire OID tree structure. In this article we’ll understand how we can get that control to only probe a particular OID tree. This way advanced users will be able to probe only what they want rather than programmatically firing multiple requests and getting all the information which may not be of much help to us at times. In this article, I’ll introduce users to another tool known as “snmpwalk” with which we can have fine grained control over what we want to probe on the target. Intended Audience: This article is aimed at advanced readers. For this article, I’ll assume that readers have a fairly good knowledge about SNMP protocol and have a good understanding about SNMP, OID tree structure, etc. User should know what OID’s are and how to navigate through the OID tree structure and identify an OID for which he or she wants to extract data. I’ll cover a bit of OID basics for the reader’s ready reference and as a quick help to others but it should be noted that this is not a replacement to self study. If you are not familiar with OID, it is strongly recommended to read up on MIB & OID and then use this article in conjunction with the knowledge thus gained to get the maximum benefit. Why explore additional tools? Well, there’s no problem in using only one tool. However, depending on necessity, we may need to use additional tools as well; hence it is always a good idea to do our homework well. When we are learning something, why not have more than one tool in our arsenal? It is always helpful as we can never know when something fails and other things work for us. Secondly, by using tools like “snmpcheck” we can get the job done, as at the end of the day all we want is to extract the maximum possible information, though they may generate too many requests. Obviously to probe each OID, the tool will need to send requests accordingly and then present the data collected to the end user at the end of scan. We may not always like to send so many packets, but we can’t control the tool behavior unless we modify it. At times it is not a very good idea to generate so much traffic, especially if one wants to work silently on the wire. We may be interested in probing the target with minimal possible packets to reduce our chances of alarming the target network’s Intrusion detection and prevention systems. Generating too much traffic is a sure shot way of alarming the IDS and IPS. Hence, advanced users may at times prefer to probe the target host very slowly but steadily by retrieving only the concerned data. In cases where the OID in question is a leaf node, “snmpwalk” will only generate one request, but if there is a sub tree to the OID in question, then “snmpwalk” will probe all OID’s that fall under that node and hence may generate good amount of traffic. This is the where the difference between an advanced user and a novice user shows. The advanced user might already know what he is doing, while the novice user may not really know the amount of traffic he might generate by probing a particular OID. I’ll cover both scenarios wherein we’ll probe a particular OID which does not have any sub tree and then one which does have a sub tree. Assumptions: For this article, we assume that a reader has access to the following:
A host or a network device running SNMP service with default (or vulnerable) SNMP configuration.
We’ll use Backtrack Linux Virtual machine which comes preloaded with “snmpwalk” and other penetration testing tools. Readers can also use other Linux installations; however they’ll need to install “snmpwalk” on other OS.
Having understood the motive and need for additional tools, let us now understand one more important topic before we jump onto the tool: “Object Identifiers.” A Brief Overview of Object ID (OID): I’ll very briefly explain what an Object Identifier (OID) is because this is the core concept on which “snmpwalk” works. Users can feed in a specific OID directly to “snmpwalk” to probe that object (in MIB tree structure). OID’s are very well structured hierarchically in the form of a tree structure. Each SNMP object is numbered and the structure looks something like the following:
In the above structure, the OID for ISO object is 1, while for org it’s 3, as it is the third object from the root. So if you want to reference ISO, we need to reference it using OID 1. Similarly, OID for org is 1.3 and for dod is 1.3.6. If you think this primer was not that helpful, it might mean that additional reading on this subject is required. We’ll now jump into the “snmpwalk” tool usage and understand how it can be useful for us in retrieving information from the remote host running SNMP service. SNMPWALK: “Snmpwalk” is a tool that uses SNMP GETNEXT operation to query the network device for a tree of information. When an end user feeds the OID to the tool using the command line, this basically is an instruction to GETNEXT operation as to what portion of the tree it should look into. Using GETNEXT requests, “snmpwalk” will query all variables listed under that particular OID (sub-tree) and the results obtained are presented via these requests to the end user. This tool has many switches, and there are few which are important. Instead of walking through each and every switch the way we did in the last article for “snmpcheck,” this time I’ll focus more on tool usage and demonstrate how OID’s could be used to limit out search criteria to reduce the number of queries that may get fired. Let’s first see how we can walk through the entire OID tree using “snmpwalk”. Our first command will go through every available object and return the values back to us for each of these nodes. The command is as follows: snmpwalk 192.168.1.101 –c public –v1 1 Snmpwalk is followed by the target IP address in the above command. The “c” switch is used to provide the community string and the “v” switch specifies the version of SNMP on the target system. I used “1” as the version since that’s the version of SNMP on the target box. The last “1” is nothing but the OID. Since we are giving the OID for ISO, snmpwalk will walk through the entire MIB tree and retrieve everything. Following is the actual screenshot of the command:
The output generated by the tool is very big, but I’ll share some of the snapshots of generated output (which is by no means complete) for the reader’s reference.
I’ve piped out the output of the command to “more”, hence it is shown page by page. If more was not appended, the entire output will be printed to the screen in order, but before a user is able to view any of the contents, the pages are scrolled up as additional content keeps getting appended. By piping out the output to more, we can view the content page-wise as the system will wait for user input and will move to the next line of the output only upon user interaction. We can also use “less” in piping out the output of the command which will provide more or less the same functionality. Alternately, you can write the output to a file as well; this way, the user can access the output every time they want. Following are other snapshots of output generated by “snmpwalk” for the above command:
The above screenshot is the last page of the output generated by “snmpwalk.“ I’ll now cover an example of leaf node OID. The following snapshot shows a different way of calling the tool rather than feeding the numeric OID. Users are encouraged to go through manuals to understand how best they can utilize snmpwalk as covering every aspect of the tool is difficult.
If you notice, instead of a numeric OID, I’ve provided a variable name directly to retrieve the value associated. I’ll cover some more examples for variable names before jumping onto the examples where I’ll use OID’s. Following is one more example to retrieve system related information – not a leaf object though!
You can repeat the command using variable names like sysName, sysLocation, sysServices, or sysContact to retrieve only the values associated with these variables. You can also pick other variables of your choice for which the information is required and fine tune the output accordingly. This is much more convenient when you want to avoid firing too many SNMP requests. I’ll now cover some examples related to OID’s. Let me first take an example and explain how to formulate the command rather than just firing up the tool with an OID. In my previous figure, where I’ve explained the OID tree, OID for “Private” is 1.3.6.1.4, but the tree does not end there. “Private” has a sub tree following it. One of the objects in the sub tree is “enterprise” which has a value 1 and has multiple children like “microsoft,” “cisco” and other private enterprises. So now if we want to run the walk for say “cisco,” we need to mention the OID 1.3.6.1.4.1.9, where 9 stands for Cisco and 1 stands for enterprise. We’ll not run this command though, as our target is not Cisco. However, the idea here was to explain how to arrive at the OID which we need to pass to snmpwalk. Following is an example of running the tool using a specific OID. Let’s say we want to run a scan for OID 1.3.6.1 (i.e. the Internet). The command will be as follows:
Similarly OID for system is 1.3.6.1.2.1.1 & that for sysDescr is 1.3.6.1.2.1.1.1. I am using the same objects for easier reference to readers as we’ve already covered system & sysDescr before when we passed variable names directly to snmpwalk. Following is the output achieved by walking through the tree using their OID’s for system and sysDescr respectively as shown in the following figure:
Readers are encouraged to read up more on the snmpwalk command using inbuilt main pages and the help provided by the tool itself when the tool is called without any options. References: http://en.wikipedia.org/wiki/Simple_Network_Management_Protocol http://www.net-snmp.org/docs/man/snmpwalk.html
