Decrypt SNMPv3 messages

Analyzing encrypted SNMPv3

Unsniff provides excellent support for SNMPv3 analysis such as deep decodes, full bubble help, scriptability, and OID resolution. However SNMPv3 in privacy mode will stump Unsniff because of its encrypted payload. This article explains how you can continue to analyze SNMPv3 using the decryption features provided by Unsniff. By providing Unsniff with the privacy key information, you can automatically decrypt SNMPv3 PDUs which use the CBC-DES and CFB-AES-128 symmetric encyption algorithms.

Out of the box - Unsniff has powerful support for the Simple Network Management Protocol (SNMP). This protocol is of special importance to the networking community because of the visibility it provides into network elements.

Standard Features

Deep decode
Full online bubble help for all fields
Error handling
Fully scriptable using Ruby or VBScript
More detailed packet descriptions
IPv4/IPv6 - UDP/TCP transports supported
Support for SNMP agents running on any port
SNMPv1,v2c,v3 supported

Advanced Features

Unsniff also provides these advanced capabilities.

Decrypt SNMPv3 messages
Flexible OID to Name resolution (requires the SNMP Name Resolver plugin)
Built in MIB-Compiler (requires the SNMP Name Resolver plugin)

This article will explain how you can use Unsniff in an SNMPv3 environment in which authentication and privacy are both enabled.

About SNMPv3 security

Before we dive into the details of SNMPv3 encryption, let us just spend a couple of minutes recapping what we know about SNMPv3 security.
Before SNMPv3, there was (and still is) a protocol called SNMPv2c. This protocol saw rapid adoption by network element vendors due to its low overhead implementation and simplicity. Both network element and management system vendors loved it and it became deeply entrenched in some of the biggest data networks. The real problem with SNMPv2c was that it was insecure to a point of “even my grandma can hack it”.

-          All communications were in clear text
-          Most boxes shipped with a default community of “public” and it hardly ever changed
-         No authentication was done (anyone could send a message to the biggest routers, no questions asked)

SNMPv3 was designed to address the above problems with the introduction of the User Security Module (USM). Essentially, SNMPv3 treats authentication and privacy as two largely independent problems.

You can select

-         no authentication or privacy (which is no better than SNMPv2c)
-          authentication but no privacy (very popular )
-          authentication with privacy (best)

If you have a system in place for provisioning users - SNMPv3 is really painless and upgrades your security by several levels. This is the reason why more and more networks are slowly upgrading to SNMPv3.

Now lets get back to the main article.

Motivation for this feature

Although Unsniff has excellent support for SNMPv3 analysis, but it will be totally lost when presented with a network using SNMPv3 in authPriv (“authentication with privacy”) mode. Yes, that is the entire point of the privacy mode - to prevent tools like Unsniff from working ! Good.

So, why then are we providing this feature? Have no fear, this is not a malicious tool. Only people who have access to the required key material will be able to use this feature. There are many cases where decrypting SNMPv3 has proven to be very helpful to developers of management applications and network elements. Consider these scenarios:

1. A network management tool was working fine with SNMPv2c, but mysteriously died with SNMPv3. Using the decryption feature of Unsniff, the developers found that a wrong context name was being used. Since the context name is part of the encrypted section, there is no other way to have found the problem.

2. An admin observed that a high end router was sending a SNMPv3 trap at regular intervals to an unknown IP address. He was really curious what the contents of the trap were, but did not have privileges to modify the trap targets. Using Unsniff, he could find out the contents of the trap message which needed attention. Everyone was happy.

Using the Decryption feature

Decrypting SNMPv3 payloads in Unsniff is really easy. Once you provide the keying material, everything works automatically. Follow these steps

Step 1 : Enable SNMPv3 Decryption

Click on Plugins -> Configure from the main menu and scroll down to the SNMP item.
Enable decryption (see figure below)

Set SNMP Decryption in Plugin Configuration

Step 2: Provide Keying information

Select Tools->SNMP->USM Privacy Keys or Click the icon from the Unsniff toolbar
Press New in the “Manage USM Keys” dialog and enter the information below:

IP Address of the SNMP agent (router/switch/server)

User Name

Privacy Password (will not be displayed anywhere in Unsniff)

Privacy Protocol used (DES or AES-128)

Authentication Protocol used (MD5 or SHA)

Click OK to save these changes

Thats it ! You are all set. Now any encrypted SNMP packet from that IP address with that user will be decrypted automatically.

Viewing decrypted packets

Decrypted Packets are shown in Unsniff as “synthetic packets”. Unsniff generates these plain text packets and re-injects them back into the analysis engine. You can use the SNMP Request ID and Message ID values to correlate encrypted and plaintext packets.

Sample Capture

Do you want to experience this for yourself ? We have provided a sample capture file for you.

Download the sample capture file here [SNMPv3Article.usnf]
Double click the file to open it with Unsniff Network Analyzer
The capture file is annotated with comments ( just hover your mouse over the annotations to see our comments)

If you want to run the decryption yourself

Enter the following information into the USM Keys Window

Username	xinitial
Passphrase	iamprivate
IPAddress	192.168.0.100
Auth	MD5
Priv	CBC-DES

Export the SNMPv3Article.usnf capture file to libpcap format (Use File->Export from the main menu)
Import the libpcap file from the previous step back into Unsniff (Use File->Import->From Libpcap )

Enjoy !

Some common questions

Why does Unsniff lose the decrypted packets when we export the *.usnf file to libpcap (tcpdump) format ?

Unsniff uses synthetic packets to handle decryption. These packets do not have lower layer information such as Ethernet or 802.11. The lowest layer for these packets are IP (or IPv6). Formats like libpcap can handle only one link layer per capture file. Therefore for compatibility reasons, Unsniff will ignore all synthetic packets when exporting to the libpcap format.

Why is the decrypted packet not immediately below the encrypted packet in the packet list ?

The decrypted packet is re-injected back into the Unsniff capture engine. However, due to the multi-threaded nature of the capture engine, other packets could have gotten ahead of the decrypted packet. Thus it is impossible to guarantee that the decrypted packet will immediately follow the encrypted packet in the packet list.