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.

Comments

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: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 has been around for over 15 years, and the problem and solution were well known before that.

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: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: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.