Session 7 - DNS
Using the Domain Name System for System Break-Ins
Steve Bellovin presented this 1990 paper that he had witheld because
he thought it was too dangerous when he wrote it. Now, he says that
there are enough firewalls and new versions of BIND can help combat
this attack. Our telnetd's have checked for this attack for some
time now (several years). Essentially, the attacker sets up a DNS
server and can poison the cache of the DNS servers trusted by his
target hosts so that he can pretend to be whomever he wishes (to
exploit .rhosts files). Bellovin recommends against running caching
named's because their caches are more easily poisoned (they store no
authoritative information). Essentially, the defense comes down to
this: if gethostbyaddr() returns a name for an incoming IP address,
and that address does not match one returned by gethostbyname(),
then deny the connection.
Much more detail is available in the paper.
DNS and BIND Security Issues
Paul Vixie (paul@vix.com) of the Internet Software Consortium
spoke to Steve's DNS security concerns mainly. Here is an outline
of what he said:
Router Wish list:
- Routers should come as a default to look at source address and
compare it to the interface it actually came in on. Due to loops in
topology, sometimes can't be done, but it should be just a button
that naive router administrators can click to make it work.
DNS Weaknesses:
- Predictable UDP source port (only 65,000 possible)
- Predictable DNS query ID
- CNAME introduces arbitrary names
- CNAME targets are cached
- BSD ruserok(), "privileged" ports. He says it shouldn't be in
the resolver, because this tends to encourage people to use it for
the wrong things. On the Sun, ruserok() returns an error such that
the application thinks the host doesn't exist if the ruserok()
authentication fails.
- Finding all of the aliases of a host given the CNAME is hard
- wuftpd's expectations are not currently realistic - not accepting
connections from people whose forward lookups do not match reverse
lookups. With multihomed hosts, this is not realistic. Vixie turns
it off and encourages other people to do the same.
He is planning to integrate DHCP and BIND.
MIME Object Security Services: Issues in a Multi-User
Environment
Jim Galvin (galvin@tis.com) presented an overview of the
workings of the MOSS protocol. The idea of MOSS is to hash the MIME
object with a private key to give the functionality of PEM
(privacy-enhanced mail). New types:
- multipart/encrypted - contains 1) control info and 2) encrypted
MIME object
- multipart/signed - contains 1) cleartext MIME object and
2) control information
Goal is to allow backward compatibility -- non-MOSS equipped MIME
readers can still read multipart/signed messages in cleartext with
the unintelligible garbage (control information) at the bottom.
Problem of key distribution is still there. Also, to get an
unpredictable series of bits, they use a complicated
hash of concatenated bits of system status information (ps, df,
netstat, etc).