saddns.net/4/4.3

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