Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Version detection: version.bind / fallbacks #977
The goal of this PR is to use data from a Project Sonar Internet wide survey of DNS responses to a
Note: Core version detection fallback logic was changed.
The DNS query response packet over TCP and UDP only differ by one field. The TCP version contains a two byte length field at the start of the response data. This means that we can use the same match lines for both probes if the regex is constructed with this in mind and fingerprint fallbacks work cross protocol. This PR implements cross protocol fallbacks by making changes to
Prior to the above, match lines were implemented separately in the TCP and UDP
To address this I have:
I've tossed some notes on cloning the repo and pr as well as building Nmap here:
Example output - No match
Custom version.bind response of
A "not implemented" response which has been softmatched in order to allow the chance for other probe/matchlines the opportunity to determine more information about the service. There are similar for Format Error, Server Fail, etc. responses.
With BIND as configured on some older OS X 10.6 systems I was unable to fingerprint the service/OS over TCP or UDP with or without this PR.
Here is the base64 encoded version of the single-packet PCAP:
I've also submitted this as a new fingerprint.
With BIND as configured on an old Ubuntu 7.10 system I was unable to fingerprint the service/OS over TCP or UDP with or without this PR.
Base64 encoded version of the single-packet PCAP:
Perhaps off topic, but while testing this for @TomSellers I noticed that DNS instances configured to return non-default or non-standard responses for the
In cases like this, as currently written nmap will say the following about the endpoint:
It will also provide the missing fingerprint data to be submitted to nmap.org, but it seems to imply a bigger problem than there actually is. In reality we know that the endpoint is DNS/domain and we did get a version response, it just doesn't look like any version we've seen before. I'd argue that showing what we did get for the version response is more useful than masking it. In many cases this will be enough to inform the user that some sort of hardening or custom configuration may be in use on the DNS server in question and that perhaps the fingerprint isn't good enough for general distribution with nmap.
Thanks @jhart-r7 for the feedback. I've incorporated the matches as well as your feedback about echoing the banner when not matched.