Hold-On Flashcards
an attacker who can observe and inject traffic
inserts fake replies to queries
DNS poisoning based on packet injection
Attackers against DNS fall into three categories:
off-path,
on-path, and
in-path.
lacks the ability to observe DNS queries and responses. Such an attacker will generally employ some means to trigger specific DNS lookups, but must guess the transaction ID and any other entropy (such as the source port and 0x20 encoding) in the request to forge a reply that the resolver will accept.
An off-path adversary
generally generate numerous packets in hopes of matching the request. Additionally, because resolvers do not issue new queries for a name that is already cached, off-path adversaries have difficulty targeting stub resolvers, since stubs, unlike recursive resolvers, do not generally accept and promote glue entries
Off-path adversaries
has the ability to passively observe
the actual lookups requested by a resolver
An on-path adversary
can directly forge DNS replies that match the full set of criteria used by the resolver to validate answers (other than use of DNSSEC). As long as a forged reply arrives at the resolver before the legitimate one, the resolver will accept the injected answer and become poisoned.
An on-path adversary
Absent a denial-of-service attack on legitimate servers, both off-path and on-path adversaries lack the ability to suppress legitimate responses. Thus, both of these adversaries necessarily create an observable artifact: the victim, if it waits sufficiently long, will receive both the attacker’s packet and the legitimate reply.
True facts
Only this is capable of blocking and modifying packets, can prevent the legitimate reply from reaching the victim.
an in-path adversary
Although in-path approaches have more power, on-path approaches have several advantages, making their use appealing for attackers
Censorship tools commonly use on-path rather
than in-path techniques to ease deployment and to make the system failure and load tolerant, as the censorship system can then operate on a traffic mirror rather than the live traffic.
works without modifying drivers, but suppressing legitimate replies requires hardware-specific access to the low-level air interface to detect and squelch a broadcast in flight
on-path WiFi packet injection
adds cryptographic authentication to prevent the
acceptance of invalid DNS replies
DNSSEC
does not suffice as a replacement for a mechanism such as Hold-On: resolvers need to maintain an open port for a period of time in order to attempt to validate all responses received for a query, not just the first.
DNSSEC
Hold-On can provide a robust defense against on-path injection only when combined with
DNSSEC
operates as a stub resolver to a known-uncensored remote recursive resolver, which enables accurate initial measurement of RTT and TTL to enable subsequent detection of unexpected replies
The current Hold-On implementation
Without DNSSEC, “Hold On” relies on attack packets exhibiting significant differences in “These 2 things” in order to distinguish them from legitimate replies.
IP TTL or RTT
If the attacker carefully crafts the attack packets’ TTLs, and only injects them just before the likely arrival of the legitimate reply (see Figure 7), our Hold-On technique without DNSSEC will fail to distinguish between the legitimate reply and the attack packet.7
True.
However, the resolver can still detect that an attack
has likely occurred (due to the differing responses). If the resolver cannot correctly determine the legitimate response, it should conservatively not return any answer—though doing so still enables attackers to impose denial-of-service
does not suffice to protect against on-path adversaries
operating in environments that users only occasionally visit, such as public WiFi hotspots; we lack knowledge of “non-sensitive” domains to look up in order to obtain estimates of RTT and TTL in the presence of non-injection
Hold On
a recursive resolver should also continue to listen
for replies even after it processes and forwards an answer
in order to detect attacks
If the resolver detects an attack,
it could revert to a more paranoid mode (performing active measurements of RTTs and TTLs for all new resolvers to detect subsequent attacks)
is effective at distinguishing legitimate replies from those injected by a widely deployed network censorship system.
a DNS forwarder that implements Hold-On
Packet injection by on-path adversaries poses a particular
threat against DNS
One particular use of such injection comes from those building DNS-based censorship tools. Even DNSSEC-validating implementations may be vulnerable, as
injected packets can cause denial-of-service if the resolver fails to wait for the legitimate reply before returning “Bogus”.
stub resolvers can use its presence to detect when packet injection occurs.
In addition, unless censors take additional steps, imperfections
in their packet injection tools can allow resolvers to not
only detect injection attacks, but also to potentially distinguish
between legitimate replies and injected answers based on
artifacts in the
IP header’s TTL field and in the round-trip time
when receiving replies
If a reply arrives too early, with an unexpected IP TTL,
or fails to validate (if DNSSEC validation occurs), the stub
waits for the potential arrival of a subsequent legitimate reply
before proceeding.
a Hold-On period
For censors who take steps to match the TTL and RTT of their injections with those expected for legitimate replies, “THIS” still allows detection that injection
has occurred; and, for DNSSEC-enabled resolution, prevents the censor from imposing denial-of-service on obtaining the correct reply.
Hold-On
