Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Security Bug Networking

New 'Loop DoS' Attack May Impact Up to 300,000 Online Systems (thehackernews.com) 10

BleepingComputer reports on "a new denial-of-service attack dubbed 'Loop DoS' targeting application layer protocols."

According to their article, the attack "can pair network services into an indefinite communication loop that creates large volumes of traffic." Devised by researchers at the CISPA Helmholtz-Center for Information Security, the attack uses the User Datagram Protocol (UDP) and impacts an estimated 300,000 host and their networks. The attack is possible due to a vulnerability, currently tracked as CVE-2024-2169, in the implementation of the UDP protocol, which is susceptible to IP spoofing and does not provide sufficient packet verification. An attacker exploiting the vulnerability creates a self-perpetuating mechanism that generates excessive traffic without limits and without a way to stop it, leading to a denial-of-service (DoS) condition on the target system or even an entire network. Loop DoS relies on IP spoofing and can be triggered from a single host that sends one message to start the communication.

According to the Carnegie Mellon CERT Coordination Center (CERT/CC) there are three potential outcomes when an attacker leverages the vulnerability:

— Overloading of a vulnerable service and causing it to become unstable or unusable.
— DoS attack on the network backbone, causing network outages to other services.
— Amplification attacks that involve network loops causing amplified DOS or DDOS attacks.

CISPA researchers Yepeng Pan and Professor Dr. Christian Rossow say the potential impact is notable, spanning both outdated (QOTD, Chargen, Echo) and modern protocols (DNS, NTP, TFTP) that are crucial for basic internet-based functions like time synchronization, domain name resolution, and file transfer without authentication... The researchers warned that the attack is easy to exploit, noting that there is no evidence indicating active exploitation at this time. Rossow and Pan shared their findings with affected vendors and notified CERT/CC for coordinated disclosure. So far, vendors who confirmed their implementations are affected by CVE-2024-2169 are Broadcom, Cisco, Honeywell, Microsoft, and MikroTik.

To avoid the risk of denial of service via Loop DoS, CERT/CC recommends installing the latest patches from vendors that address the vulnerability and replace products that no longer receive security updates. Using firewall rules and access-control lists for UDP applications, turning off unnecessary UDP services, and implementing TCP or request validation are also measures that can mitigate the risk of an attack. Furthermore, the organization recommends deploying anti-spoofing solutions like BCP38 and Unicast Reverse Path Forwarding (uRPF), and using Quality-of-Service (QoS) measures to limit network traffic and protect against abuse from network loops and DoS amplifications.

This discussion has been archived. No new comments can be posted.

New 'Loop DoS' Attack May Impact Up to 300,000 Online Systems

Comments Filter:
  • This vulnerability does not surprise me at all.
    • This attack should not have surprised you then. See https://insights.sei.cmu.edu/d... [cmu.edu], posted in 1996. One version of this 'new' attack relies on built-in features of inetd, a Unix service that has been deprecated in most OSs. This really isn't new, and that it was given a CVE just means that there are still vulnerable, very old, versions of inetd around. Using the attack against other UDP-based services, like DNS, has also been known about for year.
  • by ffkom ( 3519199 ) on Saturday March 23, 2024 @02:51PM (#64339371)
    ... is creating such "loop DOS" risks, in general. Given how with the omnipresence of "IoT" or "Smart" devices there is basically is no more network environment one can trust to convey only legitimate traffic, every service must not send anything to unauthenticated peers without limiting the rate of such responses.
    • by gweihir ( 88907 )

      Actually, no. The problem is screwed up implementations by people that do not really understand how the network works. Almost all vulnerable software is vendor crap. For ntpd, for example, the last vulnerable implementation is about 15 years old though and no sane UNIX or UNIX like system has echo or time running for UDP, or at all.

  • Comment removed (Score:4, Informative)

    by account_deleted ( 4530225 ) on Saturday March 23, 2024 @02:55PM (#64339387)
    Comment removed based on user account deletion
    • by gweihir ( 88907 )

      I somehow doubt that. They tested the most likely candidates and I expect they scanned all reachable IPv4 addresses.

    • Am I right to believe that this is just an unsolicited response packet auto-generating another error packet indefinitely? Because if so, that's not a bug in UDP. That's a shitty program design flaw. Doubly so when using UDP. The entire point of UDP is that the datagrams are unreliable.

      Retransmissions with UDP are common place. If you need session management, use TCP. If you decide to use UDP anyway, you'll need to keep track of connected peers on your own, and you'll need to ensure that the peer is in the
  • Cool attack (Score:4, Informative)

    by gweihir ( 88907 ) on Saturday March 23, 2024 @03:36PM (#64339485)

    As far as I can see, basically it is cappy vendor implementations, except for ntpd in a version about 15 years old or older and some UNIX cruft that nobody should have active (echo, time, daytime,...). As a result I have no servers with this vulnerability.

    Still, cool research and if somebody has those crappy vendor implementations, this may be a serious problem.

  • In my experience over 30 years, most vulnerabilities are not complicated or hard to understand, it's just a matter of looking at things other people never bothered to look at. AI hacking tools are going eat our fucking lunch, if they aren't already.

No spitting on the Bus! Thank you, The Mgt.

Working...