DNS is dead… long live DNS!

Most of us rely heavily (more heavily than we realise, and indeed should) on this rickety old thing called DNS (the Domain Name System), which was never intended to scale as it did, nor to defend against the kinds of attacks it is subjected to today.

The latest DNS related debacle is (as per usual) related to cache poisoning, which is where your adversary manages to convince your resolver (or more specifically, one of the caches between your resolver and the site/service you are intending to connect to) that they are in fact the one you want to be talking to. Note that these are not man-in-the-middle (MitM) attacks; if someone can see your DNS queries you’re already toast – these are effective, remote attacks that can be devastating:

Consider for example your average company using POP3 to retrieve mail from their mail server every few minutes, in conjunction with single sign on; convince their cache that you are their mail server and you will have everyone’s universal cleartext password in under 5 minutes.

The root of the problem(s) is that the main security offered in a DNS transaction is the query ID (QID) for which there are only 16 bits (eg 65,536 combinations). Even when properly randomised (as was already the case for sensible implementations like djbdns, but not for earlier attempts which foolishly used sequential numbering), fast computers and links can make a meal of this in no time (read, seconds), given enough queries. Fortunately you typically only get one shot for a given name (for any given TTL period – usually 86,400 seconds; 1 day), and even then you have to beat the authorative nameserver with the (correct) answer. Unfortunately, if you can convince your victim to resolve a bunch of different domains (a.example.com, b.example.com … aa.example.com and so on) then you’ll eventually (read, seconds) manage to slip one in.

So what you say? You’ve managed to convince a caching server that azgsewd.victim.com points at your IP – big deal. But what happens if you slipped in extra resource records (RRs) for, say, http://www.victim.com or mail.victim.com? A long time ago you might have been able to get away with this attack simply by smuggling unsolicited answers for victim.com queries along with legitimate answers to legitimate queries, but we’ve been discarding unsolicited answers (at least those that were not ‘in-baliwick’; eg from the same domain) for ages. However here you’ve got a seemingly legitimate answer to a seemingly legitimate question and extra RRs from the same ‘in-baliwick’ domain, which can be accepted by the cache as legitimate and served up to all the clients of that cache for the duration specified by the attacker.

This is a great example of multiple seemingly benign vulnerabilities being [ab]used together such that the result is greater than the sum of its parts, and is exactly why you should be very, very sure about discounting vulnerabilities (for example, a local privilege escalation vulnerability on a machine with only trusted users can be turned into a nightmare if coupled with a buffer overrun in an unprivileged daemon).

Those who still think they’re safe because an attacker needs to be able to trigger queries are sadly mistaken too. Are your caching DNS servers secure (bearing in mind UDP queries can be trivially forged)? Are your users machines properly secured? What about the users themselves? Will they open an email offering free holidays (containing images which trigger resolutions) or follow a URL on a flyer handed to them at the local metro station, cafĂ© or indeed, right outside your front door? What about your servers – is there any mechanism to generate emails automatically? Do you have a wireless network? VPN clients?

Ok so if you’re still reading you’ve either patched already or you were secure beforehand, as we were at Australian Online Solutions given our DNS hosting platform doesn’t cache; we separate authorative from caching nameservers, and our caches have used random source ports from the outset. This increases the namespace from 16 bits (65k combinations) to (just shy of, since some ports are out of bounds) 32 bits (4+ billion combinations). If you’re not secure, or indeed not sure if you are, then contact us to see how we can help you.

Proof Gmail IMAP (Gimap) supports IMAP IDLE

So for those of you with capable mail clients (like OS X Mail.app), here’s proof that IMAP IDLE works for delivering push mail:

$ openssl s_client -connect imap.gmail.com:993 -crlf
* OK Gimap ready for requests from 1.2.3.4 0123456789abcdef
. capability
* CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA XLIST CHILDREN XYZZY
. OK Thats all she wrote! 0123456789abcdef
. login samj@samj.net letmein
. OK samj@samj.net authenticated (Success)
. examine inbox
* FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
* OK [PERMANENTFLAGS ()]
* OK [UIDVALIDITY 2]
* 4498 EXISTS
* 0 RECENT
* OK [UNSEEN 1431]
* OK [UIDNEXT 25141]
. OK [READ-ONLY] inbox selected. (Success)
. idle
+ idling
---mail sent and deleted here---
* 4499 EXISTS
* 4499 EXPUNGE
* 4498 EXISTS

This is invariably why some clients ‘feel’ more responsive than others, and why you should find an IMAP IDLE capable client.

SSHKeychain 0.8.2 Post Install Problem on Leopard

It seems SSHKeychain breaks on (recent?) Leopard builds because it wants to find a group for each user (eg samj:samj):

#!/bin/sh
chown -R $USER:$USER "$2/SSHKeychain.app"
#chown root:admin "$2/SSHKeychain.app/Contents/Resources/TunnelRunner"
#chmod u+s "$2/SSHKeychain.app/Contents/Resources/TunnelRunner"

You’ll want to change the second ‘$USER’ to id -gn so it picks up your group name (eg ‘staff’) by itself, and while you’re there you can comment out the two TunnelRunner lines if you want to set up tunnels on privileged ports and don’t care about the security implications of setuid root binaries. You can do this by copying SSHKeychain.pkg from the mounted disk image, and right clicking to ‘Show Package Contents’… then you can browse for Content->Resources->postinstall, or apply this diff:

--- SSHKeychain.pkg/Contents/Resources/postinstall 2008-06-09 09:25:03.000000000 +0200
+++ SSHKeychainFixed.pkg/Contents/Resources/postinstall 2008-06-09 09:19:47.000000000 +0200
@@ -1,4 +1,4 @@
#!/bin/sh
-chown -R $USER:$USER "$2/SSHKeychain.app"
+chown -R $USER:`id -gn` "$2/SSHKeychain.app"
#chown root:admin "$2/SSHKeychain.app/Contents/Resources/TunnelRunner"
#chmod u+s "$2/SSHKeychain.app/Contents/Resources/TunnelRunner"

Hope this saves someone some time.