Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by timothy on from the doesn't-mean-they-should-be dept.

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.

47 comments

  1. Public TFTP server ? by lbalbalba · · Score: 4, Insightful

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

    1. Re:Public TFTP server ? by Anonymous Coward · · Score: 0

      It's not just you. W....T....?

    2. Re:Public TFTP server ? by zenlessyank · · Score: 1

      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?

    3. Re:Public TFTP server ? by Anonymous Coward · · Score: 1

      You wouldn't *intentionally*.

    4. Re:Public TFTP server ? by msauve · · Score: 5, Insightful

      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.

      --
      "National Security is the chief cause of national insecurity." - Celine's First Law
    5. Re:Public TFTP server ? by Anonymous Coward · · Score: 0

      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 ?

    6. Re:Public TFTP server ? by Anonymous Coward · · Score: 1

      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.

    7. Re:Public TFTP server ? by Anonymous Coward · · Score: 0

      The correct question is why do ISPs allow packets to enter their networks with spoofed source addresses

      I've been fighting my ISP for over a year for this reason alone. My guess is they're too lazy/cheap to hire some real Cisco people.

    8. Re:Public TFTP server ? by Anonymous Coward · · Score: 0

      "This housewife from Iowa created an publicly accessible tftp server, you'll be amazed at the end result"

    9. Re:Public TFTP server ? by Anonymous Coward · · Score: 0

      drivers? bios? firmware?
      install software and all its old versions?
      linux isos?
      mobile phone roms?

      Honestly, it is not that hard to type into google to find whats served on the internet by ftp.

    10. Re:Public TFTP server ? by gmack · · Score: 4, Interesting

      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.

    11. Re:Public TFTP server ? by Anonymous Coward · · Score: 1, Informative

      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.

    12. Re:Public TFTP server ? by Zocalo · · Score: 4, Informative

      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.

      --
      UNIX? They're not even circumcised! Savages!
    13. Re:Public TFTP server ? by Anonymous Coward · · Score: 0

      The correct question is why do ISPs allow packets to enter their networks with spoofed source addresses,

      That's easy: They are getting paid to accept those packets. If they didn't, they would get less money.

    14. Re:Public TFTP server ? by Zocalo · · Score: 1

      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 (AON/PON) deployments. The only way to do BCP38 in that case is to put a high throughput (read "highly expensive" on typical consumer ISP scales) packet filter in front of the aggregation device and do BCP38 there - passing the cost onto the end users - or mandate customers use an ISP supplied CPE that performs the BCP38 role, neither of which are very popular with customers, funnily enough.

      It's just not the ISPs we need to be bitching at about BCP38; it's also the manufacturers the ONTs used in AONs/PONs that don't allow for BCP38 before they fire the customer's IP traffic off towards the ISP.

      --
      UNIX? They're not even circumcised! Savages!
    15. Re:Public TFTP server ? by Anonymous Coward · · Score: 0

      The correct question is why do ISPs allow packets to enter their networks with spoofed source addresses, something upon which reflection attacks depend.

      Ummm, no. It is difficult for ISPs to determine if packets with spoofed source addresses are coming in (unless those ip addresses belong to the ISP).

      For example: my border router receives a packet from 8.8.8.8. Is that packet actually from 8.8.8.8 or was it spoofed? I have to depend on my upstream for that question.

      What ISPs can easily do is block outgoing packets with spoofed source addresses.

      Which is described in the document you linked to: http://tools.ietf.org/html/bcp...

    16. Re:Public TFTP server ? by Anonymous Coward · · Score: 0

      The correct question is why do ISPs allow packets to enter their networks with spoofed source addresses,

      That's easy: They are getting paid to accept those packets. If they didn't, they would get less money.

      That is exactly right. The real question is why they are paying to let packets OUT of their network with spoofed addresses. This is especially so given the lower difficulty of doing so and the fact the fact that they pay for the packets that cross out. Sure it is more expensive to configure the equipment to block it, but they only have to do it once and it can be done quickly with hardware at the IP level. No one would notice the few nanoseconds delay given that the ISP link is the bottleneck anyway.

    17. Re:Public TFTP server ? by Antique+Geekmeister · · Score: 3, Interesting

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

    18. Re:Public TFTP server ? by Antique+Geekmeister · · Score: 1

      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.

    19. Re:Public TFTP server ? by msauve · · Score: 1

      "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 expensive or specialized devices.

      --
      "National Security is the chief cause of national insecurity." - Celine's First Law
    20. Re:Public TFTP server ? by rubycodez · · Score: 1

      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.

    21. Re:Public TFTP server ? by Zocalo · · Score: 1

      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 routing and not packet filtering. Even assuming you need to do very crude source IP filtering on a single known subnet (which is usually going to be the case) and allowing for typical contention ratios you are still looking at tens, if not hundreds, of Gbit/s of data flowing through the first available device that can do IP level packet filtering, far in excess of what all but the highest end packet filters can handle, let alone when they are trying to run a full BGP stack as well.

      --
      UNIX? They're not even circumcised! Savages!
    22. Re:Public TFTP server ? by msauve · · Score: 1

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

      --
      "National Security is the chief cause of national insecurity." - Celine's First Law
    23. Re:Public TFTP server ? by Zocalo · · Score: 1

      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 essentially a core IP router, replace their legacy ON core hardware or replace all their CPE to fully implement BCP38, all of which entail a significant cost to be passed on to their end users - because it's sure as hell not going to be coming off the bottom line, is it? Convert that price into a per-enduser cost and dealing with the resulting price increases in a cutthroat market vs. ignoring BCP38 and dealing with (AKA "ignoring") the few people who can be bothered complaining ABOUT your customers being involved in DDoS attacks and it's a no brainer.

      What you *can* do, if you are trying to be a decent ON network based consumer ISP, is make new and replacement installs use more up to date hardware that does enable you to support BCP38, and over time you'll end up fully compliant - once you've sweated all your assets long enough to satisfy the beancounters and, by implication, the shareholders. You can, however, only do so if your chosen ON hardware vendor(s) can actually provide updated hardware that supports BCP38, which even now not all of them do. Hence my original closing point; we need to be bitching to the ON hardware vendors as well as the ISPs about supporting BCP38.

      --
      UNIX? They're not even circumcised! Savages!
    24. Re:Public TFTP server ? by nukenerd · · Score: 1

      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?

    25. Re:Public TFTP server ? by msauve · · Score: 1

      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.

      --
      "National Security is the chief cause of national insecurity." - Celine's First Law
    26. Re:Public TFTP server ? by Zocalo · · Score: 1

      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. ONTs are not routers; they are essentially modems - it's not at all uncommon for them not provide any packet filtering capability, although some newer ONTs also have a very capable IP/WLAN router in the same box, far too many are just fairly dumb devices that rely on a customer provided router (which almost certainly won't be configured for BCP38) to be plugged into them.

      Also, if you seriously suggesting implementing BCP38 on the core switches of an ISP as a viable generic approach, then you might want to have a think about how you expect them to manage connections (via any presentation) coming into the core from customers that have their own IP space, let alone customers of customers with their own IP space.

      --
      UNIX? They're not even circumcised! Savages!
    27. Re:Public TFTP server ? by msauve · · Score: 1

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

      --
      "National Security is the chief cause of national insecurity." - Celine's First Law
    28. Re:Public TFTP server ? by Cramer · · Score: 1

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

    29. Re:Public TFTP server ? by Cramer · · Score: 1

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

    30. Re:Public TFTP server ? by Cramer · · Score: 1

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

    31. Re:Public TFTP server ? by gmack · · Score: 1

      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.

    32. Re:Public TFTP server ? by rubycodez · · Score: 1

      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

    33. Re:Public TFTP server ? by Cramer · · Score: 1

      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 CTL -- certificate trust list.) Firmware has been signed since v5.

      And Cisco aren't the only ones using TFTP for boot-time configuration of VoIP hardware. The only phone I've yet seen that tried HTTP (HTTPS actually) first was an Avaya model made for the military/government markets.

      (BTW, if you watch any of the Google data center walk through videos, every phone you see is an Avaya IP phone. If paired with Avaya's call manager, they aren't running SIP -- they use H.323)

  2. WTF by Anonymous Coward · · Score: 0

    Who in the fark exposes a tftp server to the internet at large?!

    1. Re:WTF by softnewsit · · Score: 1

      Nobody does, intentionally

      --
      Go away!
  3. All services can be turned into a reflection DDOS by Anonymous Coward · · Score: 0

    Turn on Egress filtering, so you aren't part of the problem. Don't expose services to the Internet that don't need to be.

  4. Re:All services can be turned into a reflection DD by Anonymous Coward · · Score: 1

    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 server or others send data to those addresses.

  5. Wrong Problem by jon3k · · Score: 1

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

  6. Yeas, so? by gweihir · · Score: 1

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

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    1. Re:Yeas, so? by Anonymous Coward · · Score: 0

      This is the correct answer.

      I've only ever used TFTP for backing up router/switch configurations and hosting boot ROMs. I don't understand why someone would open a public TFTP server?

  7. Re:All services can be turned into a reflection DD by Antique+Geekmeister · · Score: 1

    > 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 distributing the transmission across a large enough array of attack systems. It can be done, for instance, by simply spreading a coordinated HTTP connection across many attacking systems, each of them with an appropriate bit of pre-programmed malware to attack at a specific time.

    The risks and difficulty of coordinating are much less if there is no amplification at the hosts involved in transmitting the DDOS, but it's not strictly necessary for DDOS. Even the "Slashdot effect" of a company mentioned in a Slashdot article can bring down a web service.

  8. No user authentication!!!! by Anonymous Coward · · Score: 0

    Combine this: "It is built on top of the Internet User Datagram protocol (UDP or Datagram) [2] so it may be used to move files between machines on different networks."

    with this:
    "...and currently has no provisions for user authentication."

    And you are not so much ASKING for trouble, you are DEMANDING trouble.

    At some point, somebody thought this was a good idea.

  9. SNMP by Anonymous Coward · · Score: 0

    I am shocked we haven't seen SNMP used in reflection attacks.

    1. Re:SNMP by volcan0 · · Score: 1

      yes, we have.