Re: SNMP Detection

Tim,

I discovered another bug, since the one I responded to initially (which
Gisle discovered) is only present in the most recent development branch,
and not in Nmap 7.01.

The most recent problem here was the way Lua 5.3 (new in Nmap 7.25BETA2)
handles division and tostring functions on numbers. In some cases (such as
the first integer component of an OID), the number was being treated as a
float and rendered with an extra ".0" at the end. This resulted in OIDs
like "1.0.6.3.1.2.1.2.2.1" instead of "1.6.3.1.2.1.2.2.1" which is
obviously not correct. I changed a division operator in asn1.lua to the
integer floor division operator "//" and the problem went away. This may
have affected other types of scripts such as LDAP, but I don't think so.

Dan

On Wed, Mar 29, 2017 at 10:28 AM, Daniel Miller <[email protected]>
wrote:

> Gisle, Tim,
>
> I introduced this bug recently when I switched from bin.unpack("H") to
> stdnse.tohex() because the first converts to uppercase hex and the second
> to lowercase. I've fixed it in this instance by changing string literals to
> lowercase, and will be revisiting the changes I made elsewhere to make sure
> similar problems don't crop up.
>
> Dan
>
> On Tue, Mar 28, 2017 at 5:00 AM, Gisle Vanem via dev <[email protected]> wrote:
>
>> Tim Naami wrote:
>>
>> > I have a target with SNMP working and I have confirmed it is responding
>> using snmpwalk.
>> >
>> > When I use:
>> >
>> > nmap -sU -p 161 --script=snmp-interfaces 10.255.22.222
>> >
>> > I get:
>> >
>> > Starting Nmap 7.01 ( https://nmap.org ) at 2017-03-21 11:45 CDT
>> > Nmap scan report for testuser-pc.rhsnet.org <
>> http://testuser-pc.rhsnet.org> (10.255.22.222)
>> > Host is up (0.00053s latency).
>> > PORT STATE SERVICE
>> > 161/udp open|filtered snmp
>>
>> I think the snmp-interface.lua script is not up-to-date. Because I
>> get:
>> c:\> nmap -d -sU -p 161 --script=snmp-interfaces 10.0.0.1
>>
>> NSE: [snmp-interfaces 10.0.0.1:161] no decoder for etype: a2
>> NSE: snmp-interfaces against router (10.0.0.1:161) threw an error!
>> f:\MingW32\src\inet\nmap/nselib/snmp.lua:398: attempt to index a number
>> value (field '?')
>> stack traceback:
>>         f:\MingW32\src\inet\nmap/nselib/snmp.lua:398: in function
>> 'snmp.fetchResponseValues'
>>         f:\MingW32\src\inet\nmap/nselib/snmp.lua:513: in method 'getnext'
>>         f:\MingW32\src\inet\nmap/nselib/snmp.lua:557: in method 'walk'
>>         f:\MingW32\src\inet\nmap/scripts\snmp-interfaces.nse:430: in
>> function
>>       <f:\MingW32\src\inet\nmap/scripts\snmp-interfaces.nse:397>
>>         (...tail calls...)
>>
>> Completed NSE at 09:47, 0.10s elapsed
>> Nmap scan report for router (10.0.0.1)
>> Host is up, received arp-response (0.00018s latency).
>> Scanned at 2017-03-28 09:47:43 CET for 1s
>> PORT    STATE SERVICE REASON
>> 161/udp open  snmp    udp-response ttl 64
>> MAC Address: 1C:BD:B9:C0:63:C6 (D-Link International)
>> Final times for host: srtt: 182 rttvar: 4114  to: 100000
>>
>> --------
>>
>> But snmp-info.lua works fine.
>>
>> Since I know very little of Lua, I'm at loss as to what is wrong.
>> But I guess the ASN1 decoder should be extended somehow.
>>
>> --
>> --gv
>> _______________________________________________
>> Sent through the dev mailing list
>> https://nmap.org/mailman/listinfo/dev
>> Archived at http://seclists.org/nmap-dev/
>>
>
>

_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/