Loop Denial-of-Service (DoS) Report

Description

The Shadowserver Foundation published a once off Loop DoS Special Report on the 19th Dec 2023, of a list of hosts, together with their respective network services, which they had identified, to be the cause of endless loop patterns, a possible indication of a potential loop DoS attack, in respect of the jurisdiction,  following the publication of a paper detailing research into the subject of Application Layer Loop DoS vulnerabilities by security researchers, Yepeng (Eric) Pan and Christian Rossow of the CISPA Helmholtz Center for Information Security, which is an international research center for Information Security and privacy located in Saarbrucken, Germany.

On the 26th Mar 2024, the CISPA Helmholtz Center for Information Security published their CISPA Advisory on Application-Layer Loop DoS

The Shadowserver Foundation, and CISPA, in their respective documentation and Advisory, to illustrate the Loop DoS Attack vector in a popular UDP based application layer protocol implementation,  use the example of two DNS resolvers, that respond with an error message on receiving an error message as input, If an error as input creates an error as output, and a second system behaves the same,  these two systems will keep sending error messages back and forth,  indefinitely.  In effect, an attacker can cause a loop among two faulty DNS servers by injecting a single, IP-spoofed DNS server failure message.  Once injected, the servers continuously send DNS error messages back and forth, putting stress on both servers and any network link connecting them.

Traffic loops at the network layer can occur due to accidental router misconfigurations.  This potential problem of network loops was recognised by the pioneers of the internet and they stopped it by design with the introduction of a dedicated Time-to-Live (TTL) header field in the Internet Protocol which is to prevent packets from looping indefinitely.   An IP router decrements the value of this TTL header field when it forwards a packet to the next hop.  By discarding packets with a TTL=0, routers, enforce that IP packets do not spin infinite cycles,  thereby mitgating loops at the network layer.

There are no such mechanism or systems in place to stop Traffic loops that occur at the Application layer and the existing Network layer defences such as the TTL header field in IP do not stop them.  The actions required to mitigate Traffic loops at the Application layer are quite different to those used to mitigate Traffic loops at the Network layer.

The Shadowserver Foundation commenced a Loop DoS Report in respect of the jurisdiction w.e.f. 20th Mar 2024.

The Shadowserver Foundation Loop DoS Report has a default severity level of 'High'.

Problem

The Shadowserver Foundation daily Loop DoS Report identify hosts, together with their respective network services, within the jurisdiction, that have been found to be the cause of endless loop patterns, a possible indication of a potential loop DoS attack.

Shadowserver Foundation - Loop DoS Report - Tag Index.

Note: The Shadowserver Foundation has included in the 'Tag' column of their report, a list of terms, which identify network services that have been found to be the cause of endless loop patterns, a possible indication of a potential loop DoS attack.

No. Tag Description UDP Port
1. dns. The Domain Name System service (DNS) is a globally distributed service that resolve a fully qualified domain name (FQDN) to a numeric IP address which computers use to connect to each other.  Every interactions such as visiting or accessing a web page, sending an email, the retrieval of a picture from social media, use DNS to translate human-friendly domain names to an IP address.  DNS queries contain sensitive information about the websites, users intend to visit, and without adequate security,  these queries can be intercepted by malicious actors.  Implementation of DNS security measures help to ensure the confidentiality of DNS data, and to protect the privacy of the user.  RFC1034 and RFC1035, which were both published in 1987, by the Internet Engineering Task Force (IETF), contain the official specifications on which the modern DNS is based.   However, security was not a primary consideration in its design and several solutions have been developed since in order to make DNS secure. No. 53.
2. ntpversion. The Network Time Protocol (NTP) is a network protocol for clock synchronisation between computer systems over packet-switched, variable-latency data networks.  The NTP protocol works by having a client send a query packet to an NTP server that then responds with its clock time.  The client then computes an estimate of the difference between its clock and the remote clock and attempts to compensate for any network delay.  The NTP protocol implements a hierarchical system of time references.   At the highest level, hardware reference clocks are referred to as Stratum 0.  These include Global Navigation Satellite Systems (GNSS) and national time and frequency radio broadcasts.  These clocks are very precisely synchronised to national time and frequency atomic time standards.  They are some of the most accurate time sources available.   A Stratum 1 NTP server, is the primary network time server, (Authoritative NTP server), and it must have a direct connection to a hardware (Stratum 0) clock, therefore the firewall policy must allow the NTP service, for the Stratum 1 NTP server to reference the external hardware (Stratum 0) clock. No. 123.
3. tffp. The Trivial File Transfer Protocol is a simple protocol that provides basic file transfer function with no user authentication or directory listing capabilities.  Due to its simple design, TFTP can be easily implemented by code with a small memory footprint.  It is the protocol of choice for the initial stages of any network booting strategy like BOOTP, PXE, BSDP.  It is also used to transfer firmware images and configuration files to network appliances, such as routers, firewalls,  and IP phones.  Today, TFTP is virtually unused for Internet transfers. No. 69.

Recommendations

On the confirmation of a Loop DoS Attack, constituents are advised to implement the following recommendations.

No. Action Description
1. Investigate the Incident. Investigate the host and network service identified in the report, analyse network traffic and relevant log files, to establish whether or not, the host and network service identified in the report, are receiving unsolicited messages and if they are responding to them, resulting in an endless loop.  Establish the soure of the unsolicited inbound messages and the destination of the outbound messages.
2. Disrupt or Stop the Loops. On confirmation of a Loop DoS Attack, the most effective reactive measure to a Loop-DoS attack is to disrupt the loops.  To achieve this,  constituents can exercise a number of options, calibrating the level of response necessary, these option include:-  Apply a low Quality of Service (QoS) priority to the affected Network Service.  Deploy rate limiting to control the rate of requests sent or received by a network interface controller.  Drop network packets between the source and destination ports of the affected network services, and finally, if all else fails, shutdown or take the affected host or network service offline.  The implementation of any of these measures should terminate the Loop-DoS attack forcing the attacker to reinitialise the loops.  It is recommended that the software of the affected network service be updated to the latest version available.
3. Report the Vulnerability to the Affected Party. After disruption of the Loop DoS Attack, constituents are advised to contact the affected party, from whom the unsolicited messages emanated from, or the party to whom the messages were sent, report the vulnerability to them.   It is recommended that both parties to the incident, communicate and coordinate a joint response to the incident.
4. Monitor Network Traffic. Following confirmation of an endless loop or a Loop DoS Attack, it is recommended that network traffic to and from the affected host and network service be monitored and that such monitoring be maintained thereafter,  to ensure the prevention of any future recurrence.
5. Access Control - Perimeter Firewall. Implementation of the following rules on the perimeter firewall will reduce the attack landscape.  Restrict access to clients with ephemeral of dynamic ports.  Application Layer loops, by design, are between two servers,  where none of the servers use ephemeral or dynamic ports (49152 to 65535).  It is also recommended that communication from outdated or unused ports, protocols, and applications be blocked.
6. Ingress Filtering. Ingress Filtering is implemented as a predefined security rule on the perimeter firewall to ensure that incoming packets are actually from the networks from which they claim to originate from, this is a countermeasure against spoofing attacks.
7. Egress Filtering. Egress Filtering is implemented as a predefined security rule on the perimeter firewall to monitor and restrict the flow of outbound packets from one network to another to ensure that unauthorised or malicious traffic never leaves an internal network.
8. Local DNS Stub Resolver. A Local DNS Stub Resolver is a software component or service running on a computer, which converts FQDN resolution requests, from an application such as a web browser into a DNS request message.  The Local DNS Stub Resolver sends the DNS request message via the DNS firewall, to a DNS Recursive Resolver, the IP address of which is included in its configuration.  The DNS Recursive Resolver returns the result to the application or web browser.  Local DNS Stub Resolvers do not perform recursion themselves.  Instead, they talk to a Recursive DNS resolver, which performs recursion on their behalf.
9. DNS Firewall. A DNS Firewall is an optimal policy enforcement point for DNS-specific protection from malware and advanced persistent threats.  This is a DNS service that utilises Response Policy Zones (RPZs) with a threat intelligence (malware feed) service to protect against malware and APTs by disrupting the ability of infected devices to communicate with command-and-control (C&C) sites and botnets, preventing data exfiltration.
10. DNS Content Filtering. DNS Content Filtering intercepts DNS queries and determines whether to allow or block the requested domain based upon a predefined criteria.  DNS Content filtering is often used to block access to a malicious domain or website.  DNS blocklists such as DNS-based blocklists (DNSBL) and Real-time blocklists (RBL), are lists of known malicious domains and IP addresses that should be avoided.
11. Access Control Lists. An Access control list (ACL), contain rules predefined by the Network Administrator that grant or deny access to a system environment.  Strict ACLs, should be implemented to control which devices and networks are allowed to access and use the network DNS servers, including both the primary DNS servers and the secondary DNS servers.  Access to internal DNS servers should be restricted to authorised users and systems.  Networking ACLs manage network access by providing instructions to network switches and routers that specify the types of traffic that are allowed to interface with the network.  These ACLs also specify user permissions once inside the network.   A group of NTP servers at the same Stratum level are considered as NTP Peers to each other.   ACLs can be implemented on NTP Peers, that allow them to access NTP services on the local device however these ACLs can only provide minimal security for a system running NTP.
12. NTP Authentication. The purpose of NTP authentication is to verify a time source.   NTP Authentication does not encrypt the NTP packets, it merely appends a cryptographic signature to each network packet, enabling the NTP client to be sure that the NTP packet originated from the NTP server it is expecting from, and is not a spoofed packet modified by a man-in-the-middle attack.  NTPv4 introduced an autokey feature which used private/ public key pairs for authentication, however the autokey signature were found not to provide an adequate level of protection.  In 2020, the Internet Engineering Task Force (IETF) approved the implementation of Network Time Security (NTS) for NTP.  NTS provides cryptographic security for the client-server mode of NTP.  This allows users to obtain time in an authenticated manner.

Note:

The security measures in relation to DNS continues to evolved due to its two main vulnerabilities.

DNS Vulnerabilities
No. Vulnerabilities Examples
1. Authoritative Attacks. DDoS Attacks.
2. Caching Recursive Attacks. Cache Poisoning Attacks, DNS Hijacking Attacks, DNS Tunneling Attacks.

Additional Information

Loop DoS Special Report.
CISPA Helmholtz Center for Information Security, Germany - Advisory on Application-layer Loop DoS Attacks.
CISPA Helmholtz Center for Information Security, Germany - Anomaly-based Filtering of Application-Layer DDoS Against DNS Authoritatives.
Publications 2024 - Yepeng Pan, Anna Ascheman, Christian Rossow - "Loopy Hell(ow): Infinite Traffic Loops at the Application Layer" Click on [>> pdf].
Loopy Hell(ow): Infinite Traffic Loops at the Application Layer.
CISPA Helmholtz Center for Information Security, Germany - Loop DoS Report.
RFC8633 - Network Time Protocol Best Current Practices.
RFC8915 - Network Time Security for the Network Time Protocol.
RFC1034 - Domain Names - Concepts and Facilities.
RFC1035 - Domain Names - Implentation and Specification.
ICANN - DNSSEC - What Is It and Why Is It Important.
NsLookup - What is a DNS stub resolver.
Infoblox - DNS Firewall is not a next Generation Firewall.
Infoblox - Infoblox DNS Security Resource Center.
SAFEDNS - DNS Security Best Practices.
SAFEDNS - DNS Firewall & DNS Filtering.
SAFEDNS - DNS Tunneling: An Overview of Cybersecurity Risks.
SAFEDNS - DNS Poisoning: Understanding the Threat and Securing Your Online Experience.
Trivial File Transfer Protocol Used in New DDoS Attack.
RFC1350 - The TFTP Protocol (Revision 2).
TimeTools - What is a Stratum 1 Time Server.