Re: DNS Discovery script

[Patrik Karlsson <patrik () labb1 com>]

On 12 jan 2010, at 23.20, David Fifield wrote:

> On Fri, Jan 08, 2010 at 10:56:23AM +0100, Patrik Karlsson wrote:
> > Hi all,
> >
> > I just posted a script on my blog that uses DNS Discovery to enumerate information from the MDNS/ZeroConf/Bonjour 
> > service. It decodes most of the DNS records and I have successfully tested it against several different systems 
> > including OS X, HP Laserjet printers, Ubuntu and Debian running the Avahi daemon.
> >
> > The script and some additional information is available from here:
> > http://www.cqure.net/wp/2010/01/dns-service-discovery-nmap-script/
> >
> > As always I'm open to feedback and suggestions. Also the scripts needs
> > more testing, so please let me know of any success stories or
> > failures.
>
> Here are my results from running against Mac OS X:
>
> 5353/udp  open          zeroconf        udp-response
> | dns-service-discovery:
> |   Service: _ssh._tcp.local
> |     Answers: 1
> |       _ssh._tcp.local PTR IN
> |         name: _ssh._tcp.local
> |     Additional: 5
> |       mac-mini._ssh._tcp.local SRV IN
> |         priority: 0
> |         weight: 0
> |         port: 22
> |         target: mac-mini.local
> |       mac-mini._ssh._tcp.local TXT IN
> |       mac-mini._device-info._tcp.local TXT IN
> |         txt: model=Macmini2,1
> |       mac-mini.local AAAA IN
> |         addr: fe80:0:0:0:216:cbff:feae:d4ac
> |       mac-mini.local A IN
> |         addr: 192.168.0.190
> |   Service: _sftp-ssh._tcp.local
> |     Answers: 1
> |       _sftp-ssh._tcp.local PTR IN
> |         name: _sftp-ssh._tcp.local
> |     Additional: 5
> |       mac-mini._sftp-ssh._tcp.local SRV IN
> |         priority: 0
> |         weight: 0
> |         port: 22
> |         target: mac-mini.local
> |       mac-mini._sftp-ssh._tcp.local TXT IN
> |       mac-mini._device-info._tcp.local TXT IN
> |         txt: model=Macmini2,1
> |       mac-mini.local AAAA IN
> |         addr: fe80:0:0:0:216:cbff:feae:d4ac
> |       mac-mini.local A IN
> |         addr: 192.168.0.190
> |   Service: _rfb._tcp.local
> |     Answers: 1
> |       _rfb._tcp.local PTR IN
> |         name: _rfb._tcp.local
> |     Additional: 5
> |       mac-mini._rfb._tcp.local SRV IN
> |         priority: 0
> |         weight: 0
> |         port: 5900
> |         target: mac-mini.local
> |       mac-mini._rfb._tcp.local TXT IN
> |       mac-mini._device-info._tcp.local TXT IN
> |         txt: model=Macmini2,1
> |       mac-mini.local AAAA IN
> |         addr: fe80:0:0:0:216:cbff:feae:d4ac
> |       mac-mini.local A IN
> |_        addr: 192.168.0.190
>
> This is good! There's a lot of information there. I think the output
> would benefit from being condensed. Like, the IP addresses are repeated
> for every service and they don't have to be. And the "Answers:" section
> doesn't appear to have any useful information.

Unfortunately this depends on what device your querying. Some devices put their answers in the answers section while 
others put their in the additional section.

> I guess what I'm saying
> is, there's no reason for the output to mirror the structure of the DNS
> packets. I think this is about all the relevant information:
>
> 22/tcp ssh
> 22/tcp sftp
> 5900/tcp rfb
> Hostnames: mac-mini.local
> Addresses: 192.168.0.190 fe80:0:0:0:216:cbff:feae:d4ac
> Device info: model=Macmini2,1

I have compressed the format somewhat. However running it against a number of different devices shows that there is 
relevant information in the text records for each service. (Try running it against a HP Laserjet och your Mac after you 
have enabled iTunes sharing). 

Therefore, I would like to group this information together with the service it belongs to. Also I'm thinking it could 
be possible that a service would be bound to a single ip on a multihomed system so keeping the address grouped with the 
service might not be a bad idea?

I'm suggesting an output more along these lines:

 PORT     STATE SERVICE  REASON
 5353/udp open  zeroconf udp-response
 | dns-service-discovery:  
 |   548/tcp afpovertcp
 |     model=MacBook5,1
 |     Address=10.46.200.173 fe80:0:0:0:223:6cff:1234:5678
 |   3689/tcp daap
 |     txtvers=1
 |     iTSh Version=196609
 |     MID=0xFB5338C04123456
 |     Database ID=6FA9761FE123456
 |     dmv=131078
 |     Version=196616
 |     OSsi=0x1F6
 |     Machine Name=Patrik Karlsson\xE2\x80\x99s Library
 |     Media Kinds Shared=1
 |     Machine ID=8945A7123456
 |     Password=0
 |_   Address=192.168.0.2 fe80:0:0:0:223:6cff:1234:5678

> Is there a reason you chose to write an mdns library instead of using
> the existing dns library?

Except for being an idiot, no.

> Does it not provide some function you need?
> Because DNS-SD is just another protocol on top of DNS, it would be nice
> to have just one library handle it. Or if there is an mdns library, have
> it require("dns") to do most of the work. In particular, there's no need
> for mdns.decode_dns_name to duplicate dns.decStr.

I have completely ditched the mdns library in favor of the dns library. However this required some additions to the 
library. In short I have added an answerFetcher for SRV records and two decoders for TXT and SRV records. 

I'm using the findNiceAnswer function to pull information from the response back to my script. As some servers return 
their answers i the additional section this didn't work for them. In order to address this I created a 
findNiceAdditional function with relevant additionalFetcher functions. This unfortunately involved some code 
duplication (because of current design of the dns library) from the answerFetchers to the additionalFetchers. Maybe we 
can address this somewhat better in the future?

I'm including the new version of the script and a patch for dns.lua.

Attachment: dns.lua.patch
Description:

Attachment: dns-service-discovery.nse
Description:

//Patrik
> David Fifield
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/

--
Patrik Karlsson
http://www.cqure.net




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