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.
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)
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.
|
