Determining UDP 161 port (SNMP) status using SNMPv3

[Tom Sellers]

Hello all,

I have been working with a security vendor's product
(as a customer) to determine why this particular software
determines that UDP port 161 (SNMP) is open on one device and
open|filtered on another. This product implements (under license)
certain aspects of NMap and their results track along with NMap's.

After looking at how the UDP port detection works, I think I have
a handle on the problem and a solution. Please correct me where
I am wrong.

If I understand correctly when it comes to UDP ports everything
is pretty much considered open|filtered unless an ICMP response
flags it as closed or a service response indicates that it is
open.


In my case, the problem port is SNMP.

When it comes to SNMP (UDP port 161) the SNMPv1public probe can
elicit a response if the community string is actually public,
resulting in the port being flagged as open. If the string is
not public then the host does not provide a response at all,
leaving the port state as open|filtered.

I believe that we can augment this port status detection by
adding a SNMPv3 probe. In my experience SNMPv3, when provided
with a bogus username, will respond with a packet that says
that the username is unknown. This response will allow NMap
to determine that the port is open. I have a probe that does
just this and I can build a match line for it. I think integrating
this probe or a similar one would improve NMap's port status
accuracy against SNMP daemons that support SNMPv3.

What I am curious about is:

1. This is essentially a login attempt. I know that the SNMPv1
probe tries to use"public" but I don't know if people will
consider this the same.

2. Would this be more appropriate as a NSE script as it could be
flagged as "auth" and only run when that is ok?

3. If using this probe is ok, what username should be used? I
have been considering using either "public" or null.



Feedback on this would be greatly appreciated.

Thanks,

Tom

[Fyodor]

Post by Tom Sellers
If I understand correctly when it comes to UDP ports everything
is pretty much considered open|filtered unless an ICMP response
flags it as closed or a service response indicates that it is
open.

Yeah, that is basically how it works.

Post by Tom Sellers
I believe that we can augment this port status detection by
adding a SNMPv3 probe. In my experience SNMPv3, when provided

That would be great! Maybe it will help provide useful version
detection information as well.

Post by Tom Sellers
1. This is essentially a login attempt. I know that the SNMPv1
probe tries to use"public" but I don't know if people will
consider this the same.

I think that is OK. I've never heard any complaints about the current
SNMP query which, as you noted, tries the public community string.

Post by Tom Sellers
2. Would this be more appropriate as a NSE script as it could be
flagged as "auth" and only run when that is ok?

I think it would be better as version detection. That is more
efficient (to write/maintain as well as to execute). And this is a
version detection purpose.

Post by Tom Sellers
3. If using this probe is ok, what username should be used? I
have been considering using either "public" or null.

Whichever one is most likely to work the best. Unfortunately I'm not
sure what that would be.

Cheers,
-F

[Tom Sellers]

I have attached a patch to nmap-service-probes that includes the probe/match
combination that I spoke of earlier. It sends a SNMPv3 connection request
that with the username sent to "public". The rarity has been set to 4, the
same as the SNMPv1public probe.

Thanks,

Tom

[Fyodor]

Post by Tom Sellers
I have attached a patch to nmap-service-probes that includes the probe/match
combination that I spoke of earlier. It sends a SNMPv3 connection request
that with the username sent to "public". The rarity has been set to 4, the
same as the SNMPv1public probe.
+match snmp m|^..\x02\x01\x030.\x02\x02\x20\x97\x02.{32,38}\x04\x06public\x04\0\x04\x00|s p/SNMPv3 server/

For version detection purposes, it would be best if we could at least
try to match individual SMTPv3 servers where possible. So if you know
what is running on the remote host, maybe try to include as much
context as you can with the match (this may be enough) and then
include the details in the match line. Then, if you have another
SMTPv3 server, maybe you will be able to match that separately. This
way we know more than just that it is some snmpv3 server. Now it may
turn out that SNMPv3 responses are so generic that we can't glean any
more details. But it is best to start specific and then we can
generalize it if needed when we receive correction reports at
http://nmap.org/submit/ .

Cheers,
-F

[Tom Sellers]

Post by Fyodor

Post by Tom Sellers
I have attached a patch to nmap-service-probes that includes the probe/match
combination that I spoke of earlier. It sends a SNMPv3 connection request
that with the username sent to "public". The rarity has been set to 4, the
same as the SNMPv1public probe.
+match snmp m|^..\x02\x01\x030.\x02\x02\x20\x97\x02.{32,38}\x04\x06public\x04\0\x04\x00|s p/SNMPv3 server/

For version detection purposes, it would be best if we could at least
try to match individual SMTPv3 servers where possible. So if you know
what is running on the remote host, maybe try to include as much
context as you can with the match (this may be enough) and then
include the details in the match line. Then, if you have another
SMTPv3 server, maybe you will be able to match that separately. This
way we know more than just that it is some snmpv3 server. Now it may
turn out that SNMPv3 responses are so generic that we can't glean any
more details. But it is best to start specific and then we can
generalize it if needed when we receive correction reports at
http://nmap.org/submit/ .

From what I can tell the packet is pretty generic, but there are two
places where the packet has host specific information. One includes an
encoded version of the MAC address, the other contains the first 4
bytes of the IANA SNMP private enterprise number for the manufacturer.
The enterprise number is not in a format where the number is easy to
put into i// strings but should be able to give us enough information
to generate a variety of match lines over time. The problem with this
is that I think that this field can be editted on the device itself.

I will dig into this some more tonight and see if I can improve the
submission.

Thanks much,

Tom

[Tom Sellers]

Post by Fyodor

Post by Tom Sellers
I have attached a patch to nmap-service-probes that includes the probe/match
combination that I spoke of earlier. It sends a SNMPv3 connection request
that with the username sent to "public". The rarity has been set to 4, the
same as the SNMPv1public probe.
+match snmp m|^..\x02\x01\x030.\x02\x02\x20\x97\x02.{32,38}\x04\x06public\x04\0\x04\x00|s p/SNMPv3 server/

For version detection purposes, it would be best if we could at least
try to match individual SMTPv3 servers where possible. So if you know
what is running on the remote host, maybe try to include as much
context as you can with the match (this may be enough) and then
include the details in the match line. Then, if you have another
SMTPv3 server, maybe you will be able to match that separately. This
way we know more than just that it is some snmpv3 server. Now it may
turn out that SNMPv3 responses are so generic that we can't glean any
more details. But it is best to start specific and then we can
generalize it if needed when we receive correction reports at
http://nmap.org/submit/ .
Cheers,
-F

Fyodor,

Thanks for challenging me on this patch. I have attached a new, better,
patch below. This patch does not make a log in attempt, but uses a basic, pre auth
request instead. It will match several vendors and trigger fingerprint output for
unrecognized services.

I gathered most of the information watching network traffic with Wireshark while
running the following command "snmpwalk -v3 -u public target_host".


There are 9 vendor match lines and 1 generic softmatch line. There are comments
for each match line that provide background info that may be useful when building
future match lines. All of this may be a bit wordy/unnecessary for the probes file.

For the most part, the last two bytes in the match lines are the Engine ID and are
vendor/platform specific. They are IANA numbers for the vendor. Sometimes the name
listed does not match the equipment manufacturer. One example of this is the QLogic
gear using an engine ID that belongs to Ancor Communications. This is a company that
QLogic bought/merged with years ago. For others I have no idea how the arrangement
came about.

Hopefully this patch will help by both improving the ability to detect UDP port 161
status on some devices and identifying certain platforms.

As always, feedback is greatly appreciated.

Tom

[Fyodor]

Post by Tom Sellers
Thanks for challenging me on this patch. I have attached a new, better,
patch below. This patch does not make a log in attempt, but uses a basic, pre auth
request instead. It will match several vendors and trigger fingerprint output for
unrecognized services.

Thanks Tom! This looks great and I've applied it.

-F