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 <whbat_private> Subject: SNMP Enabled on Dell Servers Date: Wed, 13 Feb 2002 18:15:26 -0500 To: bugtraqat_private 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 foobat_private 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.
This archive was generated by hypermail 2b30 : Thu Feb 14 2002 - 16:52:54 PST