Don't commit your DNSSEC keys
This post starts with a search to my favourite leaked credentials database.
Github.
I won't be getting into much detail in this post, this one involves either heavy reading/listening or some previous knowledge on the subject.
Now for some context.
I'll start by saying this post is going to revolve around the DNSSEC transmission method, which by those who don't want to waste 2 hours reading Wikipedia (big loss), you can watch this video.
What I'll be explaining in this post is how to spoof a legit DNS which has been configured with DNSSEC by using the human mistake of commiting it as my attack vector. By the way, I got this idea from the CTF of Hack.lu, DNSSoSECure, which got me absorbed for hours, learning, getting mad, giving up and picking it up again. It was overall a great experience.
Also I didn't solve it.
¯\_(ツ)_/¯
After the CTF ended, however, I couldn't stop thinking about why I didn't solve it, what did I miss, how could I exploit this experience to gain more knowledge of DNS in general. I read everything until I realized, why don't I actually look for commited keys?
After all, some CTFs do apply into real life.
Digital Ocean explains in great detail everything you need to know to set up a valid DNS with DNSSEC here.
So, in order to spoof this DNS we want to spoof, we'll have to find a git commit which has all the 4 keys commited plus the zone file needed for the RRSIG records.
When we find a decent commit with the proper keys, the we'll be able to take all of their stuff from the /bind directory and place it in our /etc/bind directory.
So the KSK and ZSK private and public key pairs plus the zone file will be able to authenticate our spoofed DNS address even though we're serving from a different IP.
Now the last couple things left to do are, sign the zone file:
dnssec-signzone -3 <salt> -A -N INCREMENT -o <zonename> -t <zonefilename>
Do the salt thing like DigitalOcean tells you, and also check for the DNSKEY record:
The downsides
Admittedly, not many DNSSEC keys are commited in Github that much, and even if they are, they are also revoked pretty fast thanks to the hundreds of users on the watch.
You could, however, set up a listener on a server to parse all new entries in Github and store those ones that may be interesting... for investigation purposes.
That's probably something worth writing about in another blog post.
Github.
I won't be getting into much detail in this post, this one involves either heavy reading/listening or some previous knowledge on the subject.
Now for some context.
I'll start by saying this post is going to revolve around the DNSSEC transmission method, which by those who don't want to waste 2 hours reading Wikipedia (big loss), you can watch this video.
What I'll be explaining in this post is how to spoof a legit DNS which has been configured with DNSSEC by using the human mistake of commiting it as my attack vector. By the way, I got this idea from the CTF of Hack.lu, DNSSoSECure, which got me absorbed for hours, learning, getting mad, giving up and picking it up again. It was overall a great experience.
Also I didn't solve it.
¯\_(ツ)_/¯
After the CTF ended, however, I couldn't stop thinking about why I didn't solve it, what did I miss, how could I exploit this experience to gain more knowledge of DNS in general. I read everything until I realized, why don't I actually look for commited keys?
After all, some CTFs do apply into real life.
Digital Ocean explains in great detail everything you need to know to set up a valid DNS with DNSSEC here.
So, in order to spoof this DNS we want to spoof, we'll have to find a git commit which has all the 4 keys commited plus the zone file needed for the RRSIG records.
When we find a decent commit with the proper keys, the we'll be able to take all of their stuff from the /bind directory and place it in our /etc/bind directory.
So the KSK and ZSK private and public key pairs plus the zone file will be able to authenticate our spoofed DNS address even though we're serving from a different IP.
Now the last couple things left to do are, sign the zone file:
dnssec-signzone -3 <salt> -A -N INCREMENT -o <zonename> -t <zonefilename>
Do the salt thing like DigitalOcean tells you, and also check for the DNSKEY record:
dig DNSKEY example.com. @localhost +multiline
And that's all you need.
And that's all you need.
Also, you should probably modify the zone file in order to make it point to your own IP address. That's important.
The downsides
Admittedly, not many DNSSEC keys are commited in Github that much, and even if they are, they are also revoked pretty fast thanks to the hundreds of users on the watch.
You could, however, set up a listener on a server to parse all new entries in Github and store those ones that may be interesting... for investigation purposes.
That's probably something worth writing about in another blog post.
Comments
Post a Comment