[vox-tech] inject false information into dns

[Bill Broadley]

I've gave a talk a few DNSSEC and DKIM talks and run a few DNSSEC 
protected domains.  I was involved in getting UCD to finally go DNSSEC 
which happened recently.  I was (AFAIK) the first DNSSEC enabled domain 
on campus.  Ah, rats, for years I was the top hit on google for DNSSEC 
and DKIM, but campus was hosting my slides and apparently killed the 
site 8-(.

Some points I wanted to make:
* Name servers have two main categories of functionality, Authoritative
   and Recursive.
* Authoritative only servers don't cache
* Buffer overflows/bugs in implementation certainly exist, but aren't
   a major point of concern these days.  Bind is large, and complex.  But
   sufficiently audited that the serious issues are getting fairly rare.
* DNS based Amplification attacks are a major issue these days
* DNS was by design a VERY insecure protocol, even assuming a perfect
   implementation.
* DHCP suggestions for a name server can get used or ignored.

Traditional MitM (Man-In-The-Middle) involved, er, a man in the middle. 
  So with a telnet connection someone who was between the source and the 
destination could listen in, record the username and password, then 
login from anywhere.  SSH prevents this by using public keys to exchange 
a secret key, which is used for that session.  So not only can someone 
not sniff a ssh connection, but they can't replay a session.

DNS has a much more serious issue.  The default uses UDP, and UDP 
packets don't have a source address.  So you can't tell where the packet 
came from.  So if you ask a DNS server for google.com anyone on the 
planet could send you (or the DNS server) a UDP packet that says 
google.com is some ip address in Russia.  So it's really 
Man-On-The-Planet, they do have to hit a rather narrow time window though.

Cache poisoning builds on this.  Normally you'd have a very short window 
between a request and a valid response to lie to the DNS server  with a 
forged UDP packet.  But say you can trigger a remote name server, say 
one for a large ISP to look up foobarbaz.google.com.  Then you know that 
A) it's not going to be cached, B) the DNS server is going to ask RSN, 
and C) since you know ahead of time you can send a valid looking answer 
in the very next packet.  The trick is you'd send two answers, one for 
foobarbaz.google.com and one for google.com.  At the time (2008ish) most 
name servers would accept both, and suddenly an arbitrarily large number 
of users would get the forged results.

That however was fixed quite a long time ago, so winning the race 
conditions are hard.  Additional protections have made this even harder, 
but not impossible.  The real fix is DNSSEC.

Neither of the above lets a remote attacker change the address a name 
server forwards to.  Not sure of any practical attack that would.  Sure 
a serious buffer overflow could, but at that point you'd likely just 
take control of the server instead of just redirecting dns queries.

DNSSEC used public key encryption to validate DNS requests.  A few points:
* DNSSEC does prevent cache poisoning
* DNSSEC does prevent MITM attacks
* DNSSEC does not require a secure network
* Room 641A is pretty much irrelevant
* DNSSEC can protect against local ISP
* DNSSEC can not protect you from those who sign the root.  Thus US Gov
   can get verisign and related to delete/change zones.
* However tinkering with the zones is easy to detect.

So basically a DNSSEC aware resolver typically stores the key for ".", 
called the anchor, then does query .com, then foo.com, and so on.  At 
each stages the key above signs the record on the next level.  So say 
for broadley.org (which is signed).  The root key is held by verisign I 
believe, which signs ".".  The public interest registry signs the .org 
domain, and my registrar allows me to upgrade the records for 
broadley.org.  So sure the USA government could pressure a registrar to 
delete or change my domain.  But that has little to do with spying 
hardware installed in various large network hubs.

Additionally even if the government did do that, you could immediately 
notice the change in signing key and if you knew me you could enquire 
why such a change happened.

So for instance:
$ dig +short +dnssec broadley.org ds
16276 5 2 7BCB5E40E630C8F77F168FFA1380BBBF25356A0B474FDDFA6F89FF1D 0AD4301B
16276 5 1 3397132E041EC17D59206FC318047D4D5128EB65

One is a KSK = Key Signing Key, and the other is a Zone Signing Key (ZSK).

Similar applies to SSL certificates.  If you are worried about secure 
communications with someone you can store their public key.  While a 
government can publish a new public key, they can't magically produce 
the missing private key.

So even the NSA has to be careful, faking a public key on any kinda of 
wide scale is lightly to draw significant attention.  The more they use 
it, the less effective it will be.  Various national governments have 
tried this to intercept communications with various email/messaging 
sites.  It worked for the less than wary, but left obvious signs. 
Google chrome for instance has protection built in for google.com.  So 
even if you have a zillion random CAs trusted by default, google chrome 
will not allow any of them to report a google.com signed cert, except 
for the CA they use of course.

You can be sure that pretty much any government can likely influence at 
least one of the CAs that are trusted by your default browser.  Thus the 
importance of tracking public keys.

If protecting yourself from some random hacker/cracker/phisher the green 
url bar, lock symbol, or related signs that a valid SSL cert is present 
is a good sign.  Of course you have to make sure it's paypal.com (with a 
l) and not paypa1.com (with the number one) and similar lookalikes.  In 
general it's safer to type in a link then to click on anything in an email.

But if trying to protect yourself from your ISP/local government then 
you need to watch the public keys for any suspicious changes.

If you are trying to protect yourself from the nsa/usa government you 
basically shouldn't trust any US based business or closed source software.

Sadly certificate authorities are anything but trustworthy.  So I prefer 
the ssh model.  You track the public keys of servers you trust and the 
client screams bloody murder if they change.  That way things are secure 
unless the end points are compromised.  Speaking of which SSH public 
keys are quite handy to store in SSHFP records when protected by DNSSEC.

Now for the practical advise:
* Do try to keep your private keys as secure as possible
* Pick good passwords, never use them for more than one site/service,
   preferably generated by a machine.  I susggest an open source password
   database like keepass (It works on windows, linux, android, and IOS).
* if you are worried about a MitM attack track the public keys, popular
   browsers have plugins like "certificate patrol" to help with ssl
   certs.
* Do not use ssh passwords, use certificates.  Optionally laugh at the
   brute force attempts.
* Do DNS right, use unbound with DNSSEC enabled locally.  It's fast,
   efficient, will validate DNSSEC, and talk directly to the root
   servers for you.  Hard to DoS, not subject to the marketing
   manipulations by your local ISP.  Will not lie to you about
   NXDOMAIN, and should work even if your ISPs dns servers die.
* If you use SSH manage your public keys somehow, dnssec + sshfp
   is one of many solutions.
* Don't click on PDFs from untrusted sources, doubly so in IE.

Sadly one of the things I'd most like to see for linux is signed 
binaries.  I'd love to have a certificate file for who *I* trust.  That 
way is someone manages to get a trojan binary on my machine it wouldn't 
even run.

For the cryptogeeks out there, this message is signed with DKIM, and the 
DKIM records in DNS are signed with DNSSEC.  That basically means 
someone with my username/password wrote this email, or at least someone 
with root on my mail server.  Granted it's not as strong as PGP/GPG 
which only requires a secure client.  But it's popularly supported. 
Anyone reading this email on gmail should see a "signed-by:	 broadley.org.

I think I've rambled on for long enough now.