[dns-operations] Client Side Issues

[Simon Waters]

On Friday 25 July 2008 15:45:54 Jon Kibler wrote:
>
> By default, all windows systems run a service call DNS Client. It is my
> understanding that this is a caching resolver. Is this vulnerable? Has
> Microsoft patched it? (I have never seen a need for this service, so for
> a couple of years now, I have been advising my clients to disable this
> service via a group policy.)

It is a local name cache. It improves performance for name lookup.

Microsoft released patches for client (stub resolver) only systems. So I 
assume they fixed this when they broke Zone Alarm, I haven't checked yet.

The Checkpoint website still suggests uninstalling the relevant Microsoft hot 
fix as a workaround for the Zone Alarm problem. Is that good security advice?

It looks like Microsoft also rolled in another undisclosed DNS poisoning 
vulnerability fix to some patches, but without knowing what the CVE numbers 
refer to this is guess work on my part.

> I have never really spent any time looking at the BIND light weight
> resolver. Is is similar to the Windows DNS Client software? Are there
> vulnerability issues with it?

Patches were released for various resolver libraries. 

Looking at systems here, I see older Linux stub resolvers using the same port, 
and patched ones using apparently random ports.

> I guess these questions really should be more general: What are the
> client side issues to with this vulnerability, what should be done about
> them, and are all the client side resolvers patched?

Step one - prevent spoofing. 

If you prevent spoofing of your recursive resolvers on your networks, then the 
only clients vulnerable are those choosing to use recursive resolvers on 
remote networks (OpenDNS users for example).

For enterprises this means closing traffic to and from port 53 except for name 
servers. For ISPs it is more complex.

Realistically I can not, and will not, patch all our internal stub resolvers 
systems in the foreseeable future (and there aren't that many!). Some are 
firmware based, some are on unsupported OS versions for a reason (that reason 
is sometimes risk v cost, or lack of resources). Thus the only sensible 
strategy is to mitigate the threat via other means. In almost all cases this 
means stopping spoofing, and regulating port 53 traffic at chokepoints.

Other approaches welcome. [Maybe a new job with less diverse systems, and more 
time to dedicate to system maintenance]
Possibly rate limiting might work in some situations, like it did for ICMP 
DDoS floods, I'd be wary of rate limiting port 53 traffic too heavily, 
although if it was important recursive resolvers will try again in a few 
seconds.

That said DNS spoofing is a lot of work to compromise one client system, so I 
assume the bad guys will target unpatched recursive resolvers first for big 
operations (phishing), and the spoof attacks on individual stub resolver will 
be reserved for more targetted abuse, or for when all the big recursive 
resolvers are already patched or owned.