Subject: RE: [ietf-dkim] Threats Issue - Large DNS records make servers targets for spoofed source amplification attacks abuse

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 27 Feb 2006 09:32:19 -0800

OK, so we need to have some appropriate language here in the threats
document. 

In particular we need to be aware that this sort of attack might be
performed as a DDoS attack.

The only solution to this sort of thing is going to be to find a way of
suppressing DDoS type traffic, in particular spoofed source address
packets. This is not very hard for ISPs to do, if a machine is
generating reams of spoofed source address data then it has been botted
and should be either refused service or moved to an isolation network.

> -----Original Message-----
> From: william(at)elan.net [mailto:[email-masked]] 
> Sent: Monday, February 27, 2006 11:19 AM
> To: Hallam-Baker, Phillip
> Cc: [email-masked]
> Subject: RE: [ietf-dkim] Threats Issue - Large DNS records 
> make servers targets for spoofed source amplification attacks abuse
> 
> 
> I think you misunderstood what I said. DKIM does not cause 
> any greater issues for "misconfigured systems" (i.e. public 
> dns servers that allow recursive queries) that already exist. 
> But it does make any dns server that deploys large DKIM 
> records just as good for use in amplification attacks as 
> those "misconfigured systems" that do allow recursion.
> 
> On Mon, 27 Feb 2006, Hallam-Baker, Phillip wrote:
> 
> > As a matter of policy it is a bad idea to attempt to 
> architect around 
> > misconfigured systems.
> >
> > This should probably be mentioned in threats but the only long term 
> > fix here is for recursive DNS servers that accept unrestricted, 
> > unauthenticated requests to have code in them to make sure they are 
> > not doing this sort of thing.
> >
> >> From a tactical perspective amplified DNS attacks are 
> vastly easier 
> >> to
> > control than a random spoofed source attack, simply drop 
> the traffic 
> > from the offending sites which will in any case be seeing a 
> heavy load.
> >
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]] On Behalf Of 
> >> william(at)elan.net
> >> Sent: Monday, February 27, 2006 10:46 AM
> >> To: [email-masked]
> >> Subject: [ietf-dkim] Threats Issue - Large DNS records 
> make servers 
> >> targets for spoofed source amplification attacks abuse
> >>
> >>
> >> There have been a lot of discussions going on in the last 
> few days at 
> >> NANOG and other dns operations lists that are related to issue of 
> >> public recursive dns servers being used to amplify an attacks:
> >>   http://www.gossamer-threads.com/lists/nanog/users/89657
> >>
> >> http://lists.oarci.net/pipermail/dns-operations/2006-February/
> >> thread.html
> >>
> >> The general description of the problem is that bad guys 
> are sending 
> >> spoofed udp packets to servers in a way so that the servers would 
> >> send data (to spoofed source) that is considerably larger then the 
> >> original request - thus the amplification. For more 
> information, you 
> >> may want to read 
> >> http://www.us-cert.gov/reading_room/DNS-recursion121605.pdf
> >>
> >> In current case with DNS abuse documented above, most (almost
> >> all) dns servers only have records that a small and so the servers 
> >> are not good targets for any significant amplification. So 
> attackers 
> >> are basically poisoning recursive nameservers with their own large 
> >> data as a way to get them to become good targets and good 
> amplifiers 
> >> - this has been quite successful and is currently major 
> issue for dns 
> >> operations and security folks.
> >>
> >> Getting back to this group work - you are expecting to introduce 
> >> large DNS records as a mainstream for many dns servers. This would 
> >> make such servers a great target for use in amplification attacks 
> >> even if those servers are not configured to do recursion. 
> This is bad 
> >> and potential for such an attack and abuse for anyone 
> using DKIM must 
> >> be documented and it must be made clear that servers with DKIM 
> >> records may become targets for use in DNS amplification 
> attacks. In 
> >> fact the larger the record you put in dns, the better 
> target for such 
> >> an attack it becomes!
> >>
> >> Note that there is currently no good solution to this 
> issue for UDP 
> >> protocols (most either do TCP-like session establishment before 
> >> sending large data or they are engineered so that responses can be 
> >> limited with ACLs to only specified group of systems, i.e. 
> local LAN 
> >> in case of DHCP).
> >> My personal view is that if there is a way to avoid 
> introducing large 
> >> records into UDP one query-response situation, that it absolutely 
> >> must be done. So I would see as best solution a 
> replacement of public 
> >> keys in dns with an approach that uses a lot smaller 
> fingerprints in 
> >> DNS.
> >>
> >> --
> >> William Leibzon
> >> Elan Networks
> >> [email-masked]
> >> _______________________________________________
> >> NOTE WELL: This list operates according to 
> >> http://mipassoc.org/dkim/ietf-list-rules.html
> 
> 

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 27 Feb 2006 20:32:43 -0800 (PST)

> performed as a DDoS attack.

There are two issues here:
  1. The design of DKIM makes it easier to perform such attacks with no
     good workaround for those who are being used as targets (they are not
     targets directly but for purposes of threat documents you can call
     it that). It would be advisable to look for similar solutions that
     do not have this issue but can deliver similar results for email
     security provisioning.
  2. The direct issue for DKIM in current form is that those who deploy
     it are are making their systems available for such attacks and could
     as a result both contribute to the attacks on the net and have their
     system experience something close to denial of service when it happens.

> and should be either refused service or moved to an isolation network.

You're obviously not an operations guy when you say its easy. The
spoofing issue is nothing new (its decades old), but it obviously has 
not been solved. There are some applications and sites that depend
on being able to have their upstreams accept packets from non-local
nets (I can find and direct you to nanog posts that described that)
so while ingress filtering can be (and has been) deployed by some and
it stops this at the source, it can not be deployed by all. As for the
target (or rather intermediary which dns servers end-up being used for), 
it really has no way to know if packet it received is spoofed or not.

Note that this arises as an issue only for ICMP and some UDP protocols.
With TCP this is not as much a problem because full TCP communication
would require establishing of a session which requires the source to
confirm the sequence # sent by the destination SYN (read about 3-packet 
handshake, if you do not know). As such because most of the internet 
communicates using TCP protocols, we typically do not have to deal with 
these problems even though possibility of spoofed packets is always which
is what smurf and similar attacks (like fraggle) use exploit.

The rebroadcast with amplification by means of 3rd parties has been a 
major issue however and was previously widely used (end of 1990s and
early this decade) and to do it what was exploited is that network 
interfaces on many routers were configured so that if packet came to 
broadcast address, it would send multiple replies to all servers on
local network which would then echo replies back to spoofed source.
This security hole has been closed by all network engineers changing 
router configurations and vendors changing defaults.

As of this year miscreants switched to using DNS servers as way to amplify 
their attacks and this again became major issue and again network engineers
are talking about steps everyone should take together - i.e. those with
dns servers that are configured both to serve domain zones and as name 
servers for clients (so doing recursion) being reconfigured and those 
functions separated or appropriate ACLs added to dns server config. This 
is seen as same-level problem as when everyone had to go through and close 
open mail relays - probably a problem more familiar to folks on this list.

However as I'm pointing out the recursive dns servers is only one way to
do it which derives from ability to poison them and then cause them to
reply with large response (so as to use them for amplification). If dns 
server is not recursive, but has very large dns record it can also be 
used for amplification (slightly worse amplification factor of 1:20).
The smart way to avoid this becoming an issue is to either use TCP or 
to use UDP protocol with fixed and fairly small response packets.