## page was renamed from DNS/毒盛/Kaminsky手法/2020/saddns.net/4/4.3
#pragma section-numbers off

= saddns.net/4/4.3 =
<<TableOfContents()>>

== 4.3 Public-Facing Source Port Scan Method ==

Even though a source port can be directly probed by any attacker
IP in this case, e.g., as in unbound and dnsmasq, it is imperative to
bypass '''the per IP rate limit''' (present in Linux primarily) to achieve
faster scan speed. 

{{{
We develop three different probing methods that
can overcome the ICMP rate limit challenge.
}}}
1○ If the attacker owns multiple IP addresses, either multiple bot
machines or a single machine with an IPv6 address, then it is trivial
to bypass the per IP limit. 

IPv6 address allocation states that each
LAN is given a /64 prefix [33], effectively allowing any network to
use 264 public IP addresses. We have tested this from a machine
in a residential network that supports IPv6 and picked several IPs
within the /64 to send and receive traffic successfully.

2○ If an attacker owns only a single IPv4 address, it is still pos-
sible to ask for multiple addresses using DHCP. We verified that
multiple private IPv4 addresses can be obtained in a home network.
In addition, we have tested this in an educational network where
a single physical machine is able to acquire multiple public IPv4
addresses through this method as well.

3○ If an attacker owns a single IPv4 address and the above
method fails for some reason (e.g., statically assigned IPs), then
the last method is to leverage IP spoofing to bypass the per IP rate
limit, and the global rate limit as a side channel to infer whether
the spoofed probes have hit the correct source port or not, i.e., with
or without ICMP responses.

As have been shown in the context of TCP recently, 
global rate limit can introduce serious side channels [11, 12, 26]. 

{{{
Here we leverage the ICMP global rate limit to facilitate UDP port scans 
which we describe next.
}}}
Figure 3 illustrates this. 

In observing the maximum globally allowable burst of 50 ICMP packets in Linux, 
{{{
the attacker first sends 50 spoofed UDP probe packets each with a different source IP
(bypassing the per-IP rate limit). 
}}}

If the victim server does not have any source port open among the 50,
then 50 ICMP port unreachable messages will be triggered (but they are not directly observableto the attacker). 

If the victim server does have 𝑛 open ports, then only 50-𝑛 ICMP packets will be triggered
(as the 𝑛 UDP probingpackets will be silently discarded at the application layer).

{{{
Now, the attacker sends a verification packet using its real IP address, 
e.g., a UDP packet destined to a known closed port, such as 1. 
}}}
It will either get no response (if the global rate limit is drained), 
or an ICMP reply otherwise.

{{{
If no port is found in the first batch, 
the attacker waits for at least 50ms for the rate limit counter to recuperate, 
and then start thenext round. 
}}}
Effectively, the scanning speed will be capped at 1,000per second. 

It therefore takes 60+ seconds to enumerate the entire port range consisting of 65536 ports. 

Nevertheless, it is a winning battle as the attacker can simply repeat the experiment 
and the probability that one experiment will succeed increases drastically
we note that this is a simple Bernoulli trial). 

'''Time consideration.'''

This approach does have a strong timing requirement.
The only thing the attacker has to send 50 spoofed probing packets and the verification packet in a burst so that they are all processed within a 20𝑚𝑠 window;
otherwise, the victim may start recovering additional tokens. 

The other requirement is that the attacker has to wait long enough for the 50 max tokens to recover. 
If the network condition is not ideal, the attacker can simply wait longer than 50ms.
{{{
Binary search to narrowing down to an exact port. 
}}}
Assuming there is a single open port out of the 50 in a specific probing round,
we can then employ a simple binary search to quickly narrow down to the exact port. 
During each round of binary search, we always probe the left half of range first. 

If it is a match, i.e., 50 spoofed probing packets triggered 49 replies 
and the attacker can observe one reply to its verification packet,
then we continue to search its left half. 
Otherwise, we assume the port lies in the right half and will conduct a binary search there.

Note that we will need to send “padding packets” to ensure the global rate limit is drained
when none of the 50 guesses hit a correct port. 
Padding packets are spoofed packets destined to known closed UDP ports,
e.g., 1, that are guaranteed to trigger ICMP replies.

Handling noises. 

DNS servers usually serve multiple clients at the same time, 
creating multiple outstanding DNS queries and source ports. 

As a result, the source port scan will likely discover many irrelevant ports.
However, most such queries are transient, and the port scan process can quickly discover
an open source port disappearing during the binary search and return to the linear
search. In contrast, we assume that the attacker-triggered DNS
queries will last significantly longer, e.g., on the order of seconds instead of milliseconds (see §5).

Another source of noises comes from packet losses and reordering. 
This may lead to both false positives, e.g., loss probing packets
or their replies, reordering between verification and probing pack-
ets, and false negatives, e.g., lost of the verification packet or its
reply (although very rare in practice). To mitigate reordering (which
may happen frequently if the jitter is large), we insert a delay, which
is empirically determined to be larger than twice the jitter, between
probe packets and the verification packet. When false positives do
occur, they are handled automatically in the binary search process–
it will detect no real port being open and return to linear search.
Even though they can be handled, excessive false positives will
drain the per-IP rate limit quickly. Specifically, given the token is
recovered at the slow rate of one per second, a false positive rate
that is higher than that will force the scan to halt until the token is
recovered. Effectively, a per-IP token is a “pass to scan”. To solve
this problem, the attacker may use two or more real IPs to gain
more “passes”.

In addition, DNS servers themselves may be subject to random
UDP port probing and therefore generate ICMP unreachable mes-
sages. This would cause false negatives: we may mistakenly think
there is no open port but in fact there is because the verification
packet will not trigger any ICMP unreachable replies due to the
noise draining the rate limit. Fortunately, not all ICMP replies are
subject to rate limit. For example, the most commonly triggered
ICMP echo replies are not subject to the limit.

== 4.4 Private Source Port Scan Method ==
As described in §4.1, if connect() is performed on a UDP socket,
the port effectively becomes “private” to the remote peer, 
invalidating the previous method.

Our idea then is to send spoofed UDP packets with the source IP
of the upstream DNS server. 

In the example of a DNS resolver being
the victim, we can send UDP packets probing different source ports
with spoofed IP of the authoritative name server. If it hits the correct
source port, then no ICMP reply will be generated. Otherwise, there
will be. We can then use the same global ICMP rate limit as a side
channel to infer if such an ICMP message has been triggered. At
first glance, this method can work but at a low speed of one port
per second, due to the per-IP rate limit on ICMP messages.

Surprisingly, after we analyze the source code of the ICMP rate
limit implementation, we find that the global rate limit is checked
prior to the per-IP rate limit. This means that even if the per-IP
rate limit may eventually determine that no ICMP reply should be
sent, a packet is still subjected to the global rate limit check and one
token is deducted. Ironically, such a decision is consciously made
by Linux developers to avoid invoking the expensive check of the
per-IP rate limit [22], involving a search process to locate the per-IP
data structure.

upstream server. 

Due to per-IP rate limit, the victim server will
always generate only one ICMP reply (in steady state) as long as
there is at least one inactive port scanned, which is the case in both
the left and right side of the figure. In the case where the 50 probes
hit 𝑛 private open ports (to the upstream server), the global rate
limit counter still decrements to 𝑛 because the victim attempted to
generate 50 − 𝑛 ICMP replies. In contrast, when all 50 probes hit
inactive ports (left side of the figure), the counter decrements to 0.
The rest of the procedure is identical as before, where a binary

search can be launched to narrow down to a specific port.
Influence on public-facing source port scan. With this knowl-
edge, we can improve method 3○ in §4.3 as follows: instead of
spoofing 50 different IPs in each round of probing, we only need to
use a single spoofed IP (or a 2nd IP the attacker owns) instead of
many different IPs (which sometimes can be a hurdle).
Handling noises. We point out that there is inherently less noise
in this scan compared to the one on public-facing source ports.
This is because every source port is now effectively “open” to only
one single remote IP which is originally specified in connect().
Therefore, assuming the victim is a resolver, most of its queries (i.e.,
noise) will be destined to a different name server than a specific
attack target. Other noise conditions such as packet loss and re-
ordering still apply. Similarly, noise handling techniques also apply
(e.g., using more than one IP to alleviate the per-IP ICMP rate limit).


This effectively means that the per-IP rate limit can be disre-
garded for the purpose of our side channel based scan, as it only
determines if the final ICMP reply is generated but has nothing to
do with the global rate limit counter decrement. As a result, we can
continue to use roughly the same scan method as efficient as before,
achieving 1,000 ports per second. Figure 4 illustrates the slightly
modified scan workflow. Similar to Figure 3, the attacker first sends
50 probes where this time all of which uses the spoofed IP of the


Figure 4: Fast Port Scanning of a Private Source Port



Figure 4: Fast