Another bunch of slides with no context. Is there an accompanying video to go with these, or can we gleen solid info from this?
My takeaway from this is that DNSSEC is done wrong from the outset here, and hence all these vectors are possible. The vectors don't seem particularly nasty if we verify the integrity of DNS from the get go.
Hey, I'm the author of the talk, but I'm not the one who posted this. I'll give you some context :)
It's the slides from a talk I gave yesterday at Derbycon - https://www.derbycon.com. It was recorded, but it doesn't look like the recording is up just yet - it will be on http://irongeek.com in the next couple days (and maybe tweeted from @irongeek_adc sooner - he's already posted a few videos from talks later than mine, but I was in kind of a weird room).
Anyway, this talk doesn't really have anything to do with DNSSEC. These attacks would work just fine with or without DNSSEC. It's simply abusing DNS the way DNS was supposed to work.
And finally, I'll definitely be posting more information (releasing the tool, the video, etc) on my own twitter account - @iagox86.
I think DNSSec solves a different problem, one where someone is maliciously tampering with DNS requests.
This is a discussion of what you can do with an ordinary DNS client and server.
More interestingly, there doesn't seem to be much software out there for monitoring DNS requests and spotting anomalies, is anyone aware of software that does this (preferably FOSS)?
You're absolutely right - as I replied to the parent, this talk has nothing to do with DNSSec, it wouldn't affect this one way or the other.
I also didn't find any great tools for finding anomalous DNS activity, but I didn't look that hard either - I wanted to get the basic functionality written before I started looking at evasion.
The traffic is definitely unusual as-is (I could make it much more discreet, but WAY slower - dnscat1 had those options), and there are definitely techniques to detect it, but I'm not sure what tools could be used.
Hey, I'm the guy that wrote the talk and you're right - Iodone is similar in some ways.
Some quick background - I wrote the original version of dnscat a few years ago, and AFAIK Iodine was made at the same time. dnscat was designed to be an all-purpose DNS relay.
dnscat2 was re-written from scratch with one thing in mind - pentesting. It's NOT a general purpose DNS tunnel, and I've actively avoided adding features that would make it that way. It's for offensive security, plain and simple.
I realize I didn't call that out very well in the slides, and I should have. Next time! :)
Thanks for the background! I didn't know about the original dnscat - that's why I mentioned iodine in case someone was interested in trying this out as a tunneling method.
And thanks also for your thoroughly enjoyable talk.
My takeaway from this is that DNSSEC is done wrong from the outset here, and hence all these vectors are possible. The vectors don't seem particularly nasty if we verify the integrity of DNS from the get go.