As ENUM uses DNS, which in its current form is an insecure protocol,
there is no mechanism for ensuring that the data one gets back is
authentic. As ENUM is deployed on the global Internet, it is
expected to be a popular target for various kind of attacks, and
attacking the underlying DNS infrastructure is one way of attacking
the ENUM service itself.
There are multiple types of attacks that can happen against DNS that
ENUM implementations should be aware of. The following threats are
taken from Threat Analysis Of The Domain Name System [10]:
Packet Interception
Some of the simplest threats against DNS are various forms of
packet interception: monkey-in-the-middle attacks, eavesdropping
on requests combined with spoofed responses that beat the real
response back to the resolver, and so forth. In any of these
scenarios, the attacker can simply tell either party (usually the
resolver) whatever it wants that party to believe. While packet
interception attacks are far from unique to DNS, DNS's usual
behavior of sending an entire query or response in a single
unsigned, unencrypted UDP packet makes these attacks particularly
easy for any bad guy with the ability to intercept packets on a
shared or transit network.
ID Guessing and Query Prediction
Since the ID field in the DNS header is only a 16-bit field and
the server UDP port associated with DNS is a well-known value,
there are only 2**32 possible combinations of ID and client UDP
port for a given client and server. Thus it is possible for a
reasonable brute force attack to allow an attacker to masquerade
as a trusted server. In most respects, this attack is similar to
a packet interception attack except that it does not require the
attacker to be on a transit or shared network.
Name-based Attacks
Name-based attacks use the actual DNS caching behavior as a tool
to insert bad data into a victim's cache, thus potentially
subverting subsequent decisions based on DNS names. Most examples
occur with CNAME, NS and DNAME Resource Records as they redirect a
victim's query to another location. The common thread in all of
these attacks is that response messages allow the attacker to
introduce arbitrary DNS names of the attacker's choosing and
provide further information that the attacker claims is associated
with those names; unless the victim has better knowledge of the
data associated with those names, the victim is going to have a
hard time defending against this class of attacks.
Betrayal By A Trusted Server
Another variation on the packet interception attack is the trusted
server that turns out not to be so trustworthy, whether by
accident or by intent. Many client machines are only configured
with stub resolvers, and use trusted servers to perform all of
their DNS queries on their behalf. In many cases the trusted
server is furnished by the user's ISP and advertised to the client
via DHCP or PPP options. Besides accidental betrayal of this
trust relationship (via server bugs, successful server break-ins,
etc), the server itself may be configured to give back answers
that are not what the user would expect (whether in an honest
attempt to help the user or to further some other goal such as
furthering a business partnership between the ISP and some third
party).
Denial of Service
As with any network service (or, indeed, almost any service of any
kind in any domain of discourse), DNS is vulnerable to denial of
service attacks. DNS servers are also at risk of being used as
denial of service amplifiers, since DNS response packets tend to
be significantly longer than DNS query packets.
Authenticated Denial of Domain Names
The existence of RR types whose absence causes an action other
than immediate failure (such as missing MX and SRV RRs, which fail
over to A RRs) constitutes a real threat. In the specific case of
ENUM, even the immediate failure of a missing RR can be considered
a problem as a method for changing call routing policy.
Because of these threats, a deployed ENUM service SHOULD include
mechanisms which ameliorate these threats. Most of these threats can
be solved by verifying the authenticity of the data via mechanisms
such as DNSSEC [8] once it is deployed. Others, such and Denial Of
Service attacks, cannot be solved by data authentication. It is
important to remember that these threats include not only the NAPTR
lookups themselves, but also the various records needed for the
services to be useful (for example NS, MX, SRV and A records).
Even if DNSSEC is deployed, a service that uses ENUM for address
translation should not blindly trust that the peer is the intended
party as all kind of attacks against DNS can not be protected against
with DNSSEC. A service should always authenticate the peers as part
of the setup process for the service itself and never blindly trust
any kind of addressing mechanism.
Finally, as an ENUM service will be implementing some type of
security mechanism, software which implements ENUM MUST be prepared
to receive DNSSEC and other standardized DNS security responses,
including large responses, EDNS0 signaling, unknown RRs, etc.
The caching in DNS can make the propagation time for a change take
the same amount of time as the time to live for the NAPTR records in
the zone that is changed. The use of this in an environment where
IP-addresses are for hire (for example, when using DHCP [9]) must
therefore be done very carefully.
There are a number of countries (and other numbering environments) in
which there are multiple providers of call routing and number/name-
translation services. In these areas, any system that permits users,
or putative agents for users, to change routing or supplier
information may provide incentives for changes that are actually
unauthorized (and, in some cases, for denial of legitimate change
requests). Such environments should be designed with adequate
mechanisms for identification and authentication of those requesting
changes and for authorization of those changes.
A large amount of Security Issues have to do with the resolution
process itself, and use of the URIs produced by the DDDS mechanism.
Those have to be specified in the registration of the Enumservice
used, as specified in Section 3.1.3.
