[TOOL] Snmpfuzz - SNMPv1 Fuzzer

• Previous message: SecuriTeam: "[NEWS] AlterPath Manager Information Multiple Vulnerabilities"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: list@securiteam.com
Date: 14 Mar 2005 11:12:09 +0200

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html

- - - - - - - - -

  Snmpfuzz - SNMPv1 Fuzzer
------------------------------------------------------------------------

SUMMARY

DETAILS

Oulu Protos is a great tool for finding SNMP implementation
vulnerabilities via fuzzing. However, it lacks a few things. The main
problem when using it is difficulty in determining which particular SNMP
packet has caused a crash. This particularly applies to blackbox testing
without an access to the device, as usually happens in penetration
testing. Also, you can not send a single testcase packet, only the whole
battery. And there is no user-friendly interface.

Snmpfuzz sorts out this problems. The CLI is easy to use, sending a single
testcase is not a problem and there is additional flexibility in testing
by setting the amount of forks and processes, as well as timeout. But the
main thing about snmpfuzz is the ability to determine which particular
packet was harmful for the target. This can be done by two methods applied
simultaneously:

1. ICMP port unreachable packets are sniffed out and shown in console. The
last SNMP packet that is likely to be the cause of the problem is
encapsulated inside of the ICMP port unreachable. This is the most simple
and efficient way to discover which packet has crashed the tested
service/device.

2. "SNMP pings" (SNMPv1 get requests for SysDescr object) are sent in
accordance to the timeout set. They are also affected by a --nodos option
(see below). If a reply for such packet ("SNMP pong") is not received, the
service is down. If an option --kill is set, the scan stops as soon as
there is no SNMP pong received.

When a problem is detected (ICMP port unreachable received, no SNMP pong),
check out the contents of ICMP port unreachable. Also, you can suspect any
of the last N packets, where N is a variable supplied to the --maxprocess
option. To be 100 % sure, send these N packets to the target one-by-one
using a single packet send option (--file).

When the problem has occurred, it could be because:
 * SNMP service crashed
 * host crashed
 * host resources exhausted

You can't distinguish these conditions using snmpfuzz alone, so we
recommend to run an ICMP ping at the same time in a different terminal.
When a crash is detected, have a look whether the host still responds to
pings.

When snmpfuzz is ran with all default options, a single mode in which only
ICMP listener is forked. The queries go one after the other, not in
parallel, and an SNMP ping will follow every single query if a --ping flag
is enabled (recommenced). In such case, discovering which packet produced
the crash is straightforward - it's the last one.

Now to the --nodos option. In a testing process we have discovered that a
Cisco 2600 router against which the tool was run hangs due to the CPU
resource exhaustion. The cause of an exhaustion appears to be SNMP
"pinging" for SysDescr. When running a scan with --fork and --ping,
enabling --nodos option will prevent this from happening. On the other
hand, omitting --nodos appears to be useful in SNMP services stress
testing.

Of course, in SNMP trap acceptance testing the NMS on port 162 may go down
without any interference with SNMP querying process via port 161. In this
case, dissecting ICMP port unreachable messages is the best and only way
to determine the problematic packet.

Remember, at the end, the best way to find out how and when the crash has
happened is to run a debugger on the SNMP service problem.

This tool was mainly tested on Cisco hosts since it was written when
working on "Hacking Exposed: Cisco Networks", namely a section on the
blackbox approach to hacking Cisco SNMP services. It is distributed under
GPL. Please give snmpfuzz some credit when publishing new vulnerabilities
found with it.

ADDITIONAL INFORMATION

The information has been provided by <mailto:andrew@arhont.com> Andrew A.
Vladimirov.
The original article can be found at:
<http://www.arhont.com/index-5.html> http://www.arhont.com/index-5.html

========================================

This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

• Previous message: SecuriTeam: "[NEWS] AlterPath Manager Information Multiple Vulnerabilities"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]