(old challenges: packet1.txt, packet2.txt.... )

Challenge:

-------------

   This time another DNS challenge: The zone "evilexample.com" includes a hidden message. Find it :)

-------------

Answer:

Ok... here is the solution. I had two winners, both used a similar approach.

Many of you tried zone transfers. Zone transfers will not work in this case. Not that I haven't
messed up in the past and had the same DNS server configured badly to allow zone transfers.

In this case, the problem was actually a security feature. The zone "evilexample.com" is signed
using DNSSEC. DNSSEC adds signatures to all records. For example:

dig +short +dnssec A www.evilexample.com
70.91.145.9
A 5 3 3600 20101202040004 20101102040004 10620 evilexample.com. BP7/08B1bra06pzlZOkkYHzZ6YvZYcGMHmgC6TVnrdbwEtFWfK1sIkMC VrSrYOR82U+wznWASQ+JDHSv6/DGfA==

We get the answer (the "A" records for www.evilexample.com is 70.91.145.9), and we get the 
signature for this answer.

There is one problem with DNSSEC: How to we verify that a name does not exist? How do you sign
"nothing". DNSSEC originally used "NSEC" records for that. NSEC records will point to the next
record in the zone:

dig +short +dnssec NSEC www.evilexample.com
evilexample.com. A RRSIG NSEC
NSEC 5 3 86400 20101202040004 20101102040004 10620 evilexample.com. zTL82aD7eis7ZjChh2HV7Vy1kTeSa2k9vbfCcn9BGmisf0slzhWKiHHX b+7V1MF/HY9iIQIbYkkCp0EYI5FRCA==

so after "www.evilexample.com", we get "evilexample.com.

We can use this to enumerate the zone:

dig +short +dnssec NSEC evilexample.com
*.evilexample.com. A NS SOA MX RRSIG NSEC DNSKEY
NSEC 5 2 86400 20101202040004 20101102040004 10620 evilexample.com. Yy0/nCyAtuz9KZZDBtEWKCM8GZqz8fyhbdXxLKMSP3GuvAf0KtksP61S mH3BhSXHmdVUZYLvYYu4b7abBvzqNA==

.... leading to "*.evilexample.com"... and so on.

A little shell script to do it for you:

a='www.evilexample.com'; for b in {1..10} ; do a=`dig +short NSEC "$a" | cut -f1 -d' '`; echo $a ;  done

you will get something like this:

evilexample.com.
*.evilexample.com.
evilexample.com. *.evilexample.com.
adw9werafqwe.evilexample.com.
localhost.evilexample.com.
mail.evilexample.com.
shell.evilexample.com.
www.evilexample.com.

now you can just do an "ANY" lookup for these names to get all records. The one that sticks out:

dig ANY +short adw9werafqwe.evilexample.com.
localhost.evilexample.com. TXT RRSIG NSEC

Meaning there is a "TXT", a "RRSIG and an "NSEC" record. The "TXT" record:

dig TXT +short adw9werafqwe.evilexample.com.
"the hidden message is: embrace nsec3"


Which is the solution.

Things are a little bit faster / less systematic if you are just starting out with "any" record queries.

The hidden message is also the solution to the problem: NSEC3, a newer algorithm, uses hashed
names instead of plain text names. Sadly, current versions of CentOS may still ship with versions of 
BIND that do not support NSEC3. BIND started supporting NSEC3 with version 9.6 . CentOS 5.5 includes only 
BIND 9.3.6.



Lessons learned:

- if you implement DNSSEC, use NSEC3 records instead of NSEC.
- do not publish "secret data" in public zones.

and now let me double check that my other zones are using NSEC3 before saving this solution :