Using Cache Snooping to Estimate Code Spread

I've stayed out of the whole Sony DRM affair because I felt Windows guru Mark Russinovich has forgotten more about Windows internals than I will ever know. I try to avoid commenting on issues out of my league, and Windows rootkits are generally not something I know how to analyze at the host level.

However, today I learned of a Wired story that incorporates new Dan Kaminski research. Dan has provided a conservative estimate of the number of systems on which the Sony DRM software is installed, based on Luis Grangeia's cache snooping methodology.

Essentially Dan used his Deluvian Scanning Platform -- DoxPara Infrastructure Validation Project (DIVP) to ask name servers if they had cached results for the hosts associated with Sony's DRM. For example, in the following I query a name server to see if it knows how to resolve www.bejtlich.net. The key is to tell the name server not to perform recursion; if the name server can't answer my request on its own, it has to report the authoritative name servers for .net:

orr:/home/richard$ dig @kis.visi.com www.bejtlich.net A +norecurse

; <<>> DiG 9.3.1 <<>> @kis.visi.com www.bejtlich.net A +norecurse
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29658
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 14

;; QUESTION SECTION:
;www.bejtlich.net.              IN      A

;; AUTHORITY SECTION:
net.                    44802   IN      NS      k.gtld-servers.net.
net.                    44802   IN      NS      l.gtld-servers.net.
net.                    44802   IN      NS      m.gtld-servers.net.
net.                    44802   IN      NS      a.gtld-servers.net.
net.                    44802   IN      NS      c.gtld-servers.net.
net.                    44802   IN      NS      d.gtld-servers.net.
net.                    44802   IN      NS      e.gtld-servers.net.
net.                    44802   IN      NS      f.gtld-servers.net.
net.                    44802   IN      NS      g.gtld-servers.net.
net.                    44802   IN      NS      h.gtld-servers.net.
net.                    44802   IN      NS      i.gtld-servers.net.
net.                    44802   IN      NS      j.gtld-servers.net.

;; ADDITIONAL SECTION:
a.gtld-servers.net.     155541  IN      A       192.5.6.30
a.gtld-servers.net.     159964  IN      AAAA    2001:503:a83e::2:30
b.gtld-servers.net.     156332  IN      A       192.33.14.30
b.gtld-servers.net.     159476  IN      AAAA    2001:503:231d::2:30
c.gtld-servers.net.     156283  IN      A       192.26.92.30
d.gtld-servers.net.     156283  IN      A       192.31.80.30
e.gtld-servers.net.     156283  IN      A       192.12.94.30
f.gtld-servers.net.     156283  IN      A       192.35.51.30
g.gtld-servers.net.     156283  IN      A       192.42.93.30
h.gtld-servers.net.     156283  IN      A       192.54.112.30
i.gtld-servers.net.     156299  IN      A       192.43.172.30
j.gtld-servers.net.     156299  IN      A       192.48.79.30
k.gtld-servers.net.     156299  IN      A       192.52.178.30
l.gtld-servers.net.     156299  IN      A       192.41.162.30

;; Query time: 49 msec
;; SERVER: 209.98.98.98#53(209.98.98.98)
;; WHEN: Tue Nov 15 16:12:49 2005
;; MSG SIZE  rcvd: 503

As you can see, kis.visi.com did not know how to resolve www.bejtlich.net, so it gave the .net generic top level domain server list.

Next I ask kis.visi.com to resolve www.bejtlich.net, but I just use the host command and I allow kis.visi.com to ask a name server that knows how to resolve www.bejtlich.net:

orr:/home/richard$ host www.bejtlich.net kis.visi.com
Using domain server:
Name: kis.visi.com
Address: 209.98.98.98#53
Aliases: 

www.bejtlich.net has address 66.93.110.10
Using domain server:
Name: kis.visi.com
Address: 209.98.98.98#53
Aliases: 

Using domain server:
Name: kis.visi.com
Address: 209.98.98.98#53
Aliases:

I get a response -- www.bejtlich.net is 66.93.110.10. Now when I use dig again and specify no recursion, kis.visi.com responds with the IP -- it has been cached.

orr:/home/richard$ dig @kis.visi.com www.bejtlich.net A +norecurse

; <<>> DiG 9.3.1 <<>> @kis.visi.com www.bejtlich.net A +norecurse
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42310
;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;www.bejtlich.net.              IN      A

;; ANSWER SECTION:
www.bejtlich.net.       7194    IN      A       66.93.110.10

;; AUTHORITY SECTION:
bejtlich.net.           7194    IN      NS      ns18.zoneedit.com.
bejtlich.net.           7194    IN      NS      ns8.zoneedit.com.

;; ADDITIONAL SECTION:
ns8.zoneedit.com.       704     IN      A       206.55.124.4
ns18.zoneedit.com.      384     IN      A       72.9.106.68

;; Query time: 49 msec
;; SERVER: 209.98.98.98#53(209.98.98.98)
;; WHEN: Tue Nov 15 16:13:20 2005
;; MSG SIZE  rcvd: 131

Dan used this technique to ask as many name servers as possible to resolve connected.sonymusic.com, updates.xcp-aurora.com and license.suncom2.com. When I asked the kis.visi.com name server about connected.sonymusic.com, I got these results:

orr:/home/richard$ dig @kis.visi.com connected.sonymusic.com A +norecurse

; <<>> DiG 9.3.1 <<>> @kis.visi.com connected.sonymusic.com A +norecurse
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10447
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;connected.sonymusic.com.       IN      A

;; AUTHORITY SECTION:
sonymusic.com.          1255    IN      NS      udns2.ultradns.net.
sonymusic.com.          1255    IN      NS      udns1.ultradns.net.

;; ADDITIONAL SECTION:
udns1.ultradns.net.     155728  IN      A       204.69.234.1
udns2.ultradns.net.     155944  IN      A       204.74.101.1

;; Query time: 53 msec
;; SERVER: 209.98.98.98#53(209.98.98.98)
;; WHEN: Tue Nov 15 16:29:38 2005
;; MSG SIZE  rcvd: 125

This means some system has asked kis.visi.com to resolve an unspecified sonymusic.com host before I did. There is no result for connected.sonymusic.com, however. Compare that result with the following for www.sonymusic.com:

orr:/home/richard$ dig @kis.visi.com www.sonymusic.com A +norecurse

; <<>> DiG 9.3.1 <<>> @kis.visi.com www.sonymusic.com A +norecurse
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37716
;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;www.sonymusic.com.             IN      A

;; ANSWER SECTION:
www.sonymusic.com.      211     IN      A       64.14.39.200

;; AUTHORITY SECTION:
sonymusic.com.          211     IN      NS      udns2.ultradns.net.
sonymusic.com.          211     IN      NS      udns1.ultradns.net.

;; ADDITIONAL SECTION:
udns1.ultradns.net.     147104  IN      A       204.69.234.1
udns2.ultradns.net.     147320  IN      A       204.74.101.1

;; Query time: 53 msec
;; SERVER: 209.98.98.98#53(209.98.98.98)
;; WHEN: Tue Nov 15 18:53:23 2005
;; MSG SIZE  rcvd: 135

Notice the answer?

Next I try querying for connected.sonymusic.com, and we check the dig results again:

orr:/home/richard$ host connected.sonymusic.com kis.visi.com
Using domain server:
Name: kis.visi.com
Address: 209.98.98.98#53
Aliases: 

connected.sonymusic.com has address 64.14.39.158
Using domain server:
Name: kis.visi.com
Address: 209.98.98.98#53
Aliases: 

Using domain server:
Name: kis.visi.com
Address: 209.98.98.98#53
Aliases: 

orr:/home/richard$ dig @kis.visi.com connected.sonymusic.com A +norecurse

; <<>> DiG 9.3.1 <<>> @kis.visi.com connected.sonymusic.com A +norecurse
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 284
;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;connected.sonymusic.com.       IN      A

;; ANSWER SECTION:
connected.sonymusic.com. 3592   IN      A       64.14.39.158

;; AUTHORITY SECTION:
sonymusic.com.          87      IN      NS      udns1.ultradns.net.
sonymusic.com.          87      IN      NS      udns2.ultradns.net.

;; ADDITIONAL SECTION:
udns1.ultradns.net.     146980  IN      A       204.69.234.1
udns2.ultradns.net.     147196  IN      A       204.74.101.1

;; Query time: 53 msec
;; SERVER: 209.98.98.98#53(209.98.98.98)
;; WHEN: Tue Nov 15 18:55:26 2005
;; MSG SIZE  rcvd: 141

The other two domains returned the gtld name servers. That means no one else asked kis.visi.com about those domains or hostnames recently.

Nice work Dan -- cool stuff.

Comments

Anonymous said…
I think you may be mistaken on your results. It looks like someone has looked up something in the sony.com domain, but "connected.sony.com" was not cached.

Or maybe I'm not reading it right.
5:55 PM
Richard Bejtlich said…
John M -- you are right. I missed the missing ANSWER section. I added material to point out the difference. Thank you!
6:59 PM
John Ward said…
Thats not the first time youve impressed me with dig. I really should heed your advice some day and learn more about DNS fundementals. Pretty interesting.
10:02 PM
Earl Crane said…
This comment has been removed by a blog administrator.
8:59 PM
Anonymous said…
Rich, thanks for the very helpful demo! I was curious so tried this out on my old school account - and was suprized to find out that nobody at CMU had queried the domain! (I went against several of CMU's domain servers) I guess CMU students stick to MP3s and don't bother with CD's - an interesting comment as to the issues of putting "untrusted media" in your machine - but that's already been made.

/afs/andrew.cmu.edu/crane % dig @128.2.1.11 connected.sonymusic.com A +norecurse

; <<>> DiG 9.2.1 <<>> @128.2.1.11 connected.sonymusic.com A +norecurse
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51716
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;connected.sonymusic.com. IN A

;; AUTHORITY SECTION:
com. 167038 IN NS e.gtld-servers.net.
com. 167038 IN NS f.gtld-servers.net.
com. 167038 IN NS g.gtld-servers.net.
com. 167038 IN NS h.gtld-servers.net.
com. 167038 IN NS i.gtld-servers.net.
com. 167038 IN NS j.gtld-servers.net.
com. 167038 IN NS k.gtld-servers.net.
com. 167038 IN NS l.gtld-servers.net.
com. 167038 IN NS m.gtld-servers.net.
com. 167038 IN NS a.gtld-servers.net.
com. 167038 IN NS b.gtld-servers.net.
com. 167038 IN NS c.gtld-servers.net.
com. 167038 IN NS d.gtld-servers.net.

;; Query time: 4 msec
;; SERVER: 128.2.1.11#53(128.2.1.11)
;; WHEN: Wed Nov 16 20:46:47 2005
;; MSG SIZE rcvd: 265

ps. first time posting on Blogger - don't know if this will come out quite right
9:05 PM
Post a Comment

Popular posts from this blog

Zeek in Action Videos

Image
This is a quick note to point blog readers to my Zeek in Action YouTube video series for the Zeek network security monitoring project .  Each video addresses a topic that I think might be of interest to people trying to understand their network using Zeek and adjacent tools and approaches, like Suricata, Wireshark, and so on.  I am especially pleased with Video 6 on monitoring wireless networks . It took me several weeks to research material for this video. I had to buy new hardware and experiment with a Linux distro that I had not used before -- Parrot .  Please like and subscribe, and let me know if there is a topic you think might make a good video.
Read more

MITRE ATT&CK Tactics Are Not Tactics

Image
Just what are "tactics"? Introduction MITRE ATT&CK  is a great resource, but something about it has bothered me since I first heard about it several years ago. It's a minor point, but I wanted to document it in case it confuses anyone else. The MITRE ATT&CK Design and Philosophy document from March 2020 says the following: At a high-level, ATT&CK is a behavioral model that consists of the following core components: • Tactics, denoting short-term, tactical adversary goals during an attack; • Techniques, describing the means by which adversaries achieve tactical goals; • Sub-techniques, describing more specific means by which adversaries achieve tactical goals at a lower level than techniques; and • Documented adversary usage of techniques, their procedures, and other metadata. My concern is with MITRE's definition of "tactics" as "short-term, tactical adversary goals during an attack," which is oddly recursive. The key word in the tacti
Read more

New Book! The Best of TaoSecurity Blog, Volume 4

Image
  I've completed the TaoSecurity Blog book series . The new book is  The Best of TaoSecurity Blog, Volume 4: Beyond the Blog with Articles, Testimony, and Scholarship .  It's available now for Kindle , and I'm working on the print edition.  I'm running a 50% off promo on Volumes 1-3 on Kindle through midnight 20 April. Take advantage before the prices go back up. I described the new title thus: Go beyond TaoSecurity Blog with this new volume from author Richard Bejtlich. In the first three volumes of the series, Mr. Bejtlich selected and republished the very best entries from 18 years of writing and over 18 million blog views, along with commentaries and additional material.  In this title, Mr. Bejtlich collects material that has not been published elsewhere, including articles that are no longer available or are stored in assorted digital or physical archives. Volume 4 offers early white papers that Mr. Bejtlich wrote as a network defender, either for technical or pol
Read more