600,000 TFTP Servers Can Be Abused For Reflection DDoS Attacks

An anonymous reader writes: Researchers have discovered that improperly configured TFTP servers can be easily abused to carry out reflection DDoS attacks that can sometimes have an amplification factor of 60, one of the highest such values. There are currently around 600,000 TFTP servers exposed online, presenting a huge attack surface for DDoS malware developers. Other protocols recently discovered as susceptible to reflection DDoS attacks include DNSSEC, NetBIOS, and some of the BitTorrent protocols.

Public TFTP server ?

[lbalbalba]

Perhaps it's just me, but why would anyone want to run a *publicly* accessible tftp server in the first place ?

Re:

[zenlessyank]

So you can create click-bait articles. "Could" "may" "possible" are all click-bait words in titles. Here is a good click-bait title...... "Republicans may like getting their salad tossed after Jeb Bush buys ranch dressing manufacturer." See??!! It's cool ain't it?

Re:

[nukenerd]

Here is a good click-bait title...... "Republicans may like getting their salad tossed after Jeb Bush buys ranch dressing manufacturer."

Cool, but where's the link?

Re:

[Anonymous Coward]

You wouldn't *intentionally*.

Re:Public TFTP server ?

[msauve]

Same reason someone might want to run a *publicly* accessible http server - to make content available.

The correct question is why do ISPs allow packets to enter their networks with spoofed source addresses, something upon which reflection attacks depend. BCP38 [ietf.org] has been around for over 15 years, and the problem and solution were well known before that.

Re:

[Anonymous Coward]

Same reason someone might want to run a *publicly* accessible http server - to make content available.

Alright, Ill bite: exactly *what* kind of content would one be likely to intentionally want to make available over the internet through tftp ?

obviously, google is offering a public pxe boot over-the-internet service we havent been told about.

Re:Public TFTP server ?

[Antique Geekmeister]

> obviously, google is offering a public pxe boot over-the-internet service we havent been told about.

I've done it when hurried. It's sometimes easier to run an internal DHCP relay pointed to a well configured externally accessible DHCP server and TFTP server to get fast PXE setups in a remote environment. It's especially useful if you have a DMZ or NAT'ed internal network and set up the TFTP server outside the local VLAN.

I only open them to external traffic temporarily, but many home users and beginning sysadmins frankly insist on exposing their internal hosts, with public IP addresses. The practice of publicly exposed services, includiing TFTP, is so rampant on campuses and small businesses that a very real part of me hopes that IPv6 is never fully adapted, to ensure that the limited IPv4 address space _forces_ people to surrender unnecessary public IP addresses and take the elementary step of activating NAT simply to reduce the ease of abusive access to the Internet at large.

Re:

[Antique Geekmeister]

And oh, yes: many firewalls, routers, and publicly exposed servers are configured by people who do not even realize they've exposed a TFTP service.

Re:

[Anonymous Coward]

The article is about TFTP, not FTP. Note the initial T, it's a different protocol from FTP and is much simplified. It is seldom used for anything apart from network boot protocols.

Re:Public TFTP server ?

[Zocalo]

I think you and others are missing the significance of that extra "T". TFTP is designed for things like Thin Clients, desktop VoIP phones, and similar devices, to load configurations/firmware off the network quickly so that they can boot off them right there and then. It's not designed for stuff that you would typically download on a PC, validate the checksum of, then load onto a target device as you would device drivers, a software ISO or other application package like you might with FTP, without the initial "T". TFTP is horribly insecure by design because its primary use is to shove data across a local network as fast as possible, typically with a bare minimum of validation to ensure the image isn't corrupt, so that the remote device can be running the code as fast as possible; a valid image is going to mean the code it contains getting executed, regardless of whether or not it was what was expected to be on the server or something a black hat had placed there.

Re:

[rubycodez]

You are funny, "real Cisco people" and their Cisco devices are a major contributing factor to the problem. Including Cisco using TFTP to boot a lot of their crap. Including the ingrained cisco doctrine they brainwash their cert-weenies of using single cisco device to be the common tie-together of multiple secure and insecured networks.

Re:

[Cramer]

Cisco does not use TFTP to "boot a lot of their crap." TFTP is the recovery mechanism -- and historically, the default means of transferring firmware and configs (in and out) -- they boot from their local storage. Unless specifically, and explicitly configured to do so, IOS devices are not tftp-servers. (it's typically only enabled as part of call-manager setup as that's how phones get firmware, configs, ringtone, etc.)

Re:

[rubycodez]

yes there are cisco architectures that boot switches and routers from a central IOS tftp store. I've a few clients that had that.

funny you brought up their shitty voip phones and the insecure tftp they use that is useless/dangerous on a distributed internet. smarter phone vendors use better protocols

cisco, living in the past, pandering to morons with disposable income. with their brainwashed cisco cert weenies

Re:

[Cramer]

Cisco's (enterprise) VoIP gear is not designed for, nor intended to be operated over the greater internet. VPNs sometimes work, but Skinny really isn't suited for many hops. (it's a very expressive protocol. Not quite to the point of button-down, button-up events, but close.) Their TFTP transfers come from the call manager (unless you intentionally set it up otherwise, which is just making a ton of work for yourself.) They support a mechanism for securing their configuration and all content they access (the

Re:

[Zocalo]

Not all ISP edge technologies allow access to customer traffic for the necessary source IP filtering before it has already been aggregated with traffic from a large number of other customers - typically several hundreds. That can either be down to the initial customer facing devices understanding IP, but not being able to do the necessary traffic inspection and filtering, or the initial traffic aggregation devices not even working at the IP layer, as the case with many active or passive optical network (AO

Re:

[msauve]

"Not all ISP edge technologies allow access to customer traffic for the necessary source IP filtering before it has already been aggregated with traffic from a large number of other customers - typically several hundreds. "

That's a non-sequitur. So what if they can only filter on the source being from a single, even large, subnet? That wouldn't eliminate reflection attacks within the subnet, but it would prevent them in the other 99.9999% of the Internet. And no, it's not difficult nor does it take expensi

Re:

[Zocalo]

No, it's really not. A typical AON/PON in that non-IP aware hardware scenario could have up to 512 customers on each optical segment (although 32-64 is more common) all of which will typically be connected at speeds in the tens of Mb/s or higher - all the way up to Gbit, with the right hardware. Each segment will consist of an OLT that hands the traffic off to the ISP's core IP network, so you will typically have multiple OLTs connected to a single IP router, which will mostly be optimised for BGP based r

Re:

[msauve]

Meh. Commercial grade routers will do this, easily, in hardware.

Re:

[Zocalo]

Yes, they well, albeit quite a large cost at the traffic and port-count scales we're talking about here. You're still missing the point though; the device already in situ doing the traffic aggregation for the ON networks I'm talking about works at layers 1 and 2 and simply *can't do it* - in many cases they only start to talk IP when they are ready to hand the aggregated data off to the ISP's IP core. That means the ISP has to either try filtering already aggregated traffic flows coming off what is essent

Re:

[msauve]

Instead of continually trying to obfuscate things by bringing up irrelevant L2 technologies, why don't you come right out and support your claim by naming a service provider router which can't do ingress L3 ACLs with minimal or no impact. Hell, there are lots of ISPs who do deep packet inspection on their customer's data.

Re:

[Zocalo]

Sigh. That you think L2 is irrelevant to PONs or that PONs use routers is telling; you don't understand the technology, do you? A PON is inherently L2-only between the end user's ONT (the CPE) and the core network hardware - the clue is in the name; "Passive Optical Network". IP traffic from each PON will typically be connected to an L3 core at 10Gb/s or more (40Gb/s and 100Gb/s are not at all uncommon in large ISPs), with dozens, or even hundreds, of PONs being terminated onto a single L3 core device.

Re:

[msauve]

You really should learn about broadcast domains and routers before displaying your ignorance.

Re:

[Cramer]

"Into their network" as in "from the customer in the first place". An ISP's interconnect is a poor place to do such checks. They should be done as close as possible to the customer. In the DOCSIS world, dhcp-snooping is enough. In a DSL PPPoE world, them sort of thing should be done at the BRAS.

The correct answer is that many ISPs are both lazy and stupid, and simply will not take the time and effort to setup their network(s) correctly.

Re:Public TFTP server ?

[gmack]

The answer to that question is not a good one. Many VOIP phones (older Cisco, Polycom) were designed to be used inside of an office and require a TFTP server on boot to load their user/pass from. Now we have a ton of VOIP providers who sold a ton of these phones to anyone who would buy them forcing the VOIP provider to keep their public TFTP servers for their customers. People assume this is secure since TFTP does not have a directory list function but the reality is that if you can guess the phone's MAC address you now have the phone's login info.

Now for the fun part: MAC addressees are 48 bits (6 byte) and you lose the first 3 bytes for the vendor prefix leaving 6 bytes (24 bit) for the address. That's 16,777,215 possibilities per device type on a protocol with no authentication whatsoever.

Re:

[Cramer]

I've never seen an Internet based VoIP provider using TFTP. TFTP is horrible across the internet. Every modern SIP phone I've encountered (with the exception of Cisco, who still want everything to run Skinny) can (and does) use HTTP. In fact, the Avaya phones I just setup almost insist on SSL/TLS. (they do eventually fall back to plain HTTP. And they want to use TCP/TLS to talk to the PBX.)

Re:

[gmack]

There is the key word "modern" It's the old crap that requires TFTP and I can think of two VOIP providers that I know for a fact offer TFTP servers. Other than that, I agree completely. TFTP is horrible over the internet and using it to provide SIP account info is beyond insecure.

Re:

[softnewsit]

Nobody does, intentionally

Re:

[Anonymous Coward]

A service can not automatically be used in an amplification attack just because it exists. The protocol design must be such that the server sends a bigger amount of data to an unverified source address than it has received in the request. UDP protocols are more prone to such design flaws because the IP source address is not automatically verified by a three-way handshake. A TCP protocol can still be used in amplification attacks if IP addresses are part of the protocol payload and can be faked to make the s

Re:

[Antique Geekmeister]

> The protocol design must be such that the server sends a bigger amount of data to an unverified source address than it has received in the request.

Not necessarily. The equivalent is not that of lasers, where amplification and synchronization occurs inside the device. DDOS does not require multiplication inside the attack vactor itself. It requires overwhelming volume at the target. DDOS is _cheaper_ and easier if there's an effective amplificaiton technique, but can be done quite effectively by distrib

Wrong Problem

[jon3k]

We'll never stop uneducated admins from attaching insecure services to public networks. The solution is BCP38 and preventing source address spoofing.

Yeas, so?

[gweihir]

TFTP is not at all intended for public reachability. The problem here is people not securing their networks properly with firewalls.

Re:

[volcan0]

yes, we have.