Wednesday, October 31, 2012

A Preview of the Bitsquatting PCAPs

Recently I decided to make public the packet captures (PCAPs) of DNS traffic from my bitsquatting experiment (dnslogs.tar.7z, 56Mb, 7zip compressed). Currently I am working on an in-depth analysis of the PCAP data, including distribution of request types, domains, source addresses and more. In the meantime I wanted to share some interesting findings.

Internal DNS Leakage

Bitsquatting can expose internal DNS naming schemes, as evidenced by the various *.corp.microsoft.com DNS queries received:

dnshostprobe.redmond.corp.micrgsoft.com.
dubitsmsema01.europe.corp.micrgsoft.com.
l32web.redmond.corp.micro3oft.com.
ls2web.redmond.corp.eicrosoft.com.
ls2web.redmond.corp.iicrosoft.com.
ls2web.redmond.corp.mhcrosoft.com.
ls2web.redmond.corp.miarosoft.com.
ls2web.redmond.corp.micrgsoft.com.
ls2web.rmdmond.corp.micrgsoft.com.
msdcs.corp.micrgsoft.com.
pptestsubca.redmond.corp.eicrosoft.com.
pptestsubca.redmond.corp.iicrosoft.com.
pptestsubca.redmond.corp.mhcrosoft.com.
pptestsubca.redmond.corp.miarosoft.com.
pptestsubca.redmond.corp.mic2osoft.com.
pptestsubca.redmond.corp.micrgsoft.com.
pptestsubca.redmond.corp.micro3oft.com.
pptestsubca.redmond.corp.microsmft.com.
pptestsubca.redmond.corp.microsnft.com.
pug.redmond.corp.microsmft.com.
tk5-red-dc-02.redmond.corp.microsnft.com.
udp.corp.microsnft.com.
wpad.corp.mic2osoft.com.

Note: I do not intend to pick on Microsoft. It just happens that microsoft.com is very popular and I had registered several bitsquats of it.

XMPP/Jabber Interception and SRV records

My special purpose DNS server only replied to A and NS record requests. Had I examined my PCAPs earlier it would have also replied to SRV record requests (among others).

SRV records are used for specifying the location of services. Most people are already familiar with an application that uses SRV records, XMPP/Jabber.

 The XMPP RFC states:

The preferred process for FQDN resolution is to use [DNS‑SRV] records as follows:
1. The initiating entity constructs a DNS SRV query whose inputs are:
  • a Service of "xmpp-client" (for client-to-server connections) or "xmpp-server" (for server-to-server connections)
  • a Proto of "tcp"
  • a Name corresponding to the "origin domain" of the XMPP service to which the initiating entity wishes to connect (e.g., "example.net" or "im.example.com")

Sure enough Jabber and XMPP related SRV queries are seen in the PCAPs:

_xmpp-server._tcp.gmaml.com.
_xmpp-server._tcp.mhcrosoft.com.
_jabber._tcp.gmaml.com.
_jabber._tcp.mhcrosoft.com.

These were server-to-server XMPP requests with potential security implications in case of interception. The source IPs for all of these requests were originating from Google owned IP space. Google security investigated the issue and assured that the problem does not occur inside Google but because of users sending messages to the wrong address. Still, there is potential for Jabber/XMPP message interception via Bitsquatting.

There are also applications besides XMPP/Jabber that use SRV records, such as

Microsoft Exchange:
_autodiscover._tcp.gmaml.com.
_autodiscover._tcp.microsmft.com.

Communications Server:
_sipfederationtls._tcp.miarosoft.com.
_sipfederationtls._tcp.micro3oft.com.

and Active Directory:
_ldap._tcp.Default-First-Site-Name._sites.winseadatum.nttest.miarosoft.com.
_ldap._tcp.dc._msdcs.HEADQUARTERS.EXAMPLE.MIAROSOFT.COM.
_ldap._tcp.dc._msdcs.headquarters.example.miarosoft.com.
_ldap._tcp.gc._msdcs.corp.micrgsoft.com.
_ldap._tcp.headquarters.example.miarosoft.com.

SRV records are also used for Instant Messenger presence notification:
_rvp._tcp.mhcrosoft.com.

Admirers

There was at least one admirer of my Blackhat talk (with the source IP originating from OpenDNS -- perhaps this guy?):
i_enjoyed_your_black_hat_talk.ak.fbbdn.net.

Security Researchers

In the PCAPs one can also spot other security researchers doing their DNS research:

a2928671910p64332i56889.d2011100512000710682.t21941.dnsresearch.cymru.com.
a2928671910p63203i53360.d2011092618000714816.t68280.dnsresearch.cymru.com.
a2928671910p60764i58270.d2011121506000913657.t5877.dnsresearch.cymru.com.
a2928671910p45340i52044.d2010121318000323400.t15256.dnsresearch.cymru.com.
a2928671910p43510i45465.d2011041306000724298.t28165.dnsresearch.cymru.com.
a2928671910p39337i56369.d2011061518000722950.t32622.dnsresearch.cymru.com.
a2928671910p37870i35758.d2011032106000827854.t1980.dnsresearch.cymru.com.
a2928671910p29942i23408.d2010092418000330700.t53485.dnsresearch.cymru.com.
a2928671910p17176i61017.d2011091806000717437.t14914.dnsresearch.cymru.com.


To Be Continued...

Soon I will be posting a more detailed analysis of the PCAP data, but in the meantime you can always inspect the PCAPs yourself.

Update:
Part 1 is now up, Bitsquatting PCAP Analysis Part 1: Analyzing PCAPs using Unix command line tools.
Part 2 is now up, Bitsquatting PCAP Analysis Part 2: Query Types, IPv6.
Part 3 is now up, Bitsquatting PCAP Analysis Part 3: Bit-error distribution.
Part 4 is now up, Bitsquatting PCAP Analysis Part 4: Source Country Distribution.

No comments:

Post a Comment