Some 300,000 IPs vulnerable to this Loop DoS attack

As many as 300,000 servers or devices on the public internet are thought to be vulnerable right now to the recently disclosed Loop Denial-of-Service technique that works against some UDP-based application-level services. It's said that certain implementations of TFTP, DNS, and NTP, as well as legacy protocols, such as Echo, …

[Mr Anonymous]

Mikrotik fixed, download available no charge

Notified: 2024-01-17 Updated: 2024-03-19

Statement Date: January 17, 2024

CVE-2009-3563 Unknown

CVE-2024-1309 Unknown

CVE-2024-2169 Affected

Vendor Statement

Our TFTP service is affected, we have resolved the issue in 7.14beta6 version. Stable versions after 7.13.2 will include a patch for this issue.

Version 17.4.1 download available no support contract needed. 2024-03-11 . 7.13.3 was available on 2024-01-25.

[Kevin McMurtrie]

Infinite error loops?

Error, missing security patch

Error, missing security patch

Error, missing security patch

Error, missing security patch

Error, missing security patch

Error, missing security patch

...

[petef]

TFTP on the public Internet. That's a thing?

[Anonymous Coward]

Agreed but as with the SMB debacle one could ask the same question of Windows machines on the public internet.

[Rich 2]

Windows should never be on the public internet

Some years ago, I had a server housed in a "real" server house. The amount of noise on the network from windows boxes was ludicrous, and my guess would be that many of the owners of those machines had no idea! The rest just didn't care (what other excuse can there be?)

[Anonymous Coward]

Even if it's not public

It's still a defense-in-depth concern. Attackers often like to drop something nasty like this after they have pivoted into local access and want to cover exfiltration/encryption by blinding and distracting your IT staff. It looks like a local attacker might be able vent some of the traffic to WAN hosts as well, similar to prior amplification/reflection attacks.

Link and service busting UDP storms can be very distracting once they get going, and allow an attacker to down or degrade critical services on systems not otherwise vulnerable or under their control.

Good news is that this should be blockable at the network/firewall level even for hosts where a workable patch isn't promptly available.

[jake]

Old stuff.

"This sort of application-layer loop has been a known problem as far back as 1996, the CISPA duo noted."

Further back than that ... We were cautioned to not make multi-party loops possible back in the days of the NCP ARPANET, in the late '70s. A mentor allowed as to how somebody (himself, I suspect) made a similar programming error with the young SABRE system in the early 1960s.

[that one in the corner]

Re: Old stuff.

And how many stories of application-level infinite loops have we heard of through the years, bringing systems to their knees?

For Out-of-office auto-reply storms, just read almost any of the "Who, Me?" discussion pages!

Hmm, given the ease[1] with which you can get lists of valid corporate email addresses, I'm almost surprised that triggering these externally isn't a holiday sport.[2]

[1] oops, "apparent ease, according to press reports"

[2] yes, I'm easily surprised. The cough? Just seasonal allergies, thank you for asking.

[Anonymous Coward]

Re: Old stuff.

There are infinite infinite loops.

[ldo]

Re: There are infinite infinite loops.

Thankfully, they are only countably infinite (ℵ₀), not uncountably infinite(ℵ₁).

[Paul Crawford]

Re: There are infinite infinite loops.

Many a room at the hotel Hilbert...

[Mike 125]

Re: Old stuff.

> Old stuff

https://en.wikipedia.org/wiki/Sorcerer's_Apprentice_syndrome

[Anonymous Coward]

Jenkins

See also e.g. CVE-2020-2100 for Jenkins. Thankfully they removed the "feature" that caused that as a result.

[Andy Non]

Reminds me of

an "infinite loop" I inadvertently created decades ago with an email auto-responder. My code replied to an incoming email with an "out of office" message, which bounced back again from the original sender as undeliverable (or they were out of office too, can't remember now), which generated another "out of office" reply from my end... several thousand loops later... oops.

[Anonymous Coward]

Trivial?

"It's pretty trivial, and basically relies on sending an error message to, let's say, vulnerable server A in such a way, using IP address source spoofing"

That's actually not trivial, as routers drop packets with incorrect source addresses. I guess if you are already on the subnet, you can do it. But then what's the point?

[Flightmode]

Re: Trivial?

Some protocols are more susceptible to this than you might think. This is especially true for protocols running over UDP that rely on having their own sequencing and error handling mechanisms built in to the protocol itself (as they can't rely on TCP to handle that for them). Many a protocol - TFTP and some flavours of SIP being the most common b*stards as any seasoned firewall admins will be aware - include the source and destination IPs in the packet payload, which means they can be different from the addresses used in the IP header. This will let your spoofed packets pass through the intermediate routers without being dropped. (And break any attempts at NAT without a clever enough stateful ALG in your firewall.)

[Marcelo Rodrigues]

Re: Trivial?

"That's actually not trivial, as routers drop packets with incorrect source addresses."

Routers SHOULD drop them. They don't always do. Sometime ago I was attacked by an amplified DOS, using NTP protocol. The perpetrator was outside my server network, outside the various NTP servers networks used as amplifiers AND they still answered to a spoofed message from "me".

So, yeah. They SHOULD drop - but it isn't necessarily true.

[Mike007]

Re: Trivial?

"Routers" don't pay any attention to the source address, the will only look at that field if you are doing something like policy based routing.

The only places where there is widespread processing of source addresses are when going through NATs. BCP38 is not as widely deployed as you may think...

[Cliffwilliams44]

Reminds me of the dreded Service Desk loop!

Service Desk software accepts emails to create tickets.

Service Desk Software sends email to sender notifying their ticket is created.

User has a rule to auto reply to email that they are out-of-office (instead of using the proper Out-of-Office method).

Auto reply is received by Service Desk software which creates new ticket, responds to user, rinse-repeat.

After about an hour, email system is completely overwhelmed!

[Mike007]

Re: Reminds me of the dreded Service Desk loop!

Company A buys a service from Company B. Uses their main email address for the account, which goes to their ticket system.

Company B sends an announcement/notification to Company A from their public email address, replies go to their ticket system.

This *should* result in 1 ticket at each end, but only if they recognise the "We have opened a new ticket" email as being related to the previous ticket...

We have experienced "incompatible ticket systems" before, we had to turn off confirmation emails on our ticket system while we changed that account to a different email address..

Although even when this doesn't result in a loop, I do wonder about the provider where our ticket system opens a support ticket their end every time they send us a notification that a server has rebooted... The only reason I can think of for why nobody has contacted us about this is because tickets they can resolve without doing anything help their stats?

[Manglemender]

Still?

Back in the heady days of modems and dial-up access, I setup my work email to forward to my personal email account so that, while travelling, I only had to dial-up once. For some reason that I never bothered to sort out, two copies of each email were forwarded. All worked ok until my ISP went broke while I was away on a business trip. One forwared message (sent twice) got two error messages, two error messages were forwarded... You can see where this is going. All mail services vert quickly ground to halt and I was not popular.

[Scott 26]

Years ago I worked for company A, and our division got bought by company B.

A let us still be onsite (it was a factory and our division's products were still manufactured by A, at least until we could find another manufacturer).

A set up an auto-fwder for all A emails to go to our B addresses.

Unfortunately they did this BEFORE B set up our new mailboxes.

So an email to A, fwds to B, B replies to A "doesn't exist", A fwds the reply to B.

Come in on Monday, need to check email from account managers/clients/etc... no chance. 1000s, if not 10,000s of "RE FWD RE FWD RE FWD RE FWD....." (why they rewrote the subject line, I don't know - I was a labrat back then and not in IT, praise Allah)

[vBuck]

Metis Flag

Why are people using the symbol of the Metis people as a symbol for a DDOS attack ?

[diodesign]

Re: Metis Flag

No - it's an infinite loop, not that flag.

C.