Re: Exploiting SNMP?

[Ron DuFresne <dufresne () winternet com>]

If I recall correctly it does not work on on windows default installs as
it;s not supposed to be installed or enabled.  though an additional
bugtraq posting suggested dell enables it on their newer servers:

From: Will Backman <whb () ceimaine org>
Subject: SNMP Enabled on Dell Servers
Date: Wed, 13 Feb 2002 18:15:26 -0500
To: bugtraq () securityfocus com

While Microsoft says that SNMP is NOT enabled on any version of Windows,
my new Dell PowerEdge with Win2000SP2 came with it installed and
running.  Besides the current exploits, it uses the stupid defaults that
NT4.0 has, which is a community string of PUBLIC with READ-CREATE.

I figure the new holes in SNMP will case a lot of scanning for the
service, and there may be a lot of folks who do not realize that the
vendor might have installed it and turned it on in the OEM media.

Will Backman
Network Administrator


Thanks,

Ron DuFresne


On Thu, 14 Feb 2002 foob () return0 net wrote:

> Has anyone tried exploiting the SNMP problems disclosed in the recent CERT
> notice, and original investigated by the University of Oulu?
>
> http://www.cert.org/advisories/CA-2002-03.html
> http://www.ee.oulu.fi/research/ouspg/protos/testing/c06/snmpv1/index.html
>
> Running the supplied java applet against Windows 2000 causes no service
> failure, and no noticable impact on the system.  Sending the raw packet
> data to UDP 161 has the same null impact.
>
> On Solaris (7, sparc), the snmpdx agent either stops responding after
> certain requests (the deamon stays active, but the MIB is not browsable
> anymore), or the daemon aborts with a Bus Error.  This latter case can
> only be triggered by one packet (#5922) as far as i can tell.  Whats more,
> it doesnt always abort - if some snmpdx is healthy, and has been servicing
> valid requests this packet has no impact.
>
> If I understand SNMP correctly, the data in this particular packet
> specifies a long OID (by setting each section to some maximum value) and
> also specifies a format string (%s%x%n) in the value portion.  Replacing
> the format string with 'abcdef' does not affect the impact - indicating
> that the OID is causing the SIGBUS, not the format string.
>
> Yes the stack is corrupted, with data supplied in the OID.
> But the SIGBUS is caused by attempting to dereference the a register
> containing data from the OID.  If this can be bypassed, eventually the
> program will jump to our specifiedd location.
>
> The problem (perhaps just my limitied knowledge of SNMP and sparc) is that
> the data in the packet cannot be modified greatly - most changes to the
> 'interesting' parts of the OID do not impact the snmpdx service.
>
> Is anyone else looking at exploiting these issues?
>
> The fact i cant recreate the MS problem is a little worrying - they've
> released patches, but from here it didnt even look vulnerable!
>
> If people are interested in / working on this, I can forward some more
> information on the solaris problem.
>
> - foob

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Cutting the space budget really restores my faith in humanity.  It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
        ***testing, only testing, and damn good at it too!***

OK, so you're a Ph.D.  Just don't touch anything.