Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Security The Internet IT

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

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.
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • by lbalbalba ( 526209 ) on Saturday March 12, 2016 @09:44AM (#51684161)
    Perhaps it's just me, but why would anyone want to run a *publicly* accessible tftp server in the first place ?
    • 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?
      • 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?

    • by Anonymous Coward
      You wouldn't *intentionally*.
    • by msauve ( 701917 ) on Saturday March 12, 2016 @10:12AM (#51684223)
      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.
      • by Zocalo ( 252965 )
        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
        • by msauve ( 701917 )
          "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
          • by Zocalo ( 252965 )
            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
            • by msauve ( 701917 )
              Meh. Commercial grade routers will do this, easily, in hardware.
              • by Zocalo ( 252965 )
                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
                • by msauve ( 701917 )
                  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.
                  • by Zocalo ( 252965 )
                    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.
                    • by msauve ( 701917 )
                      You really should learn about broadcast domains and routers before displaying your ignorance.
    • by gmack ( 197796 ) <gmack.innerfire@net> on Saturday March 12, 2016 @11:07AM (#51684365) Homepage Journal

      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.

      • by Cramer ( 69040 )

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

        • by gmack ( 197796 )

          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.

  • We'll never stop uneducated admins from attaching insecure services to public networks. The solution is BCP38 and preventing source address spoofing.
  • TFTP is not at all intended for public reachability. The problem here is people not securing their networks properly with firewalls.

"The Avis WIZARD decides if you get to drive a car. Your head won't touch the pillow of a Sheraton unless their computer says it's okay." -- Arthur Miller

Working...