Tee Eff Tee Pee

Over the past week, I’ve noticed a pretty strong uptick in traffic to the default TFTP port, 69/UDP.

TFTP? What’s up with that?

[Note: I love me some python + matplotlib. Just sayin’…]

TFTP, or Trivial File Transfer Protocol, is a simple high-level protocol for transferring data. It is often used to boot or configure diskless workstations, X-terminals, and routers. TFTP sends information using the User Data Protocol (UDP) and generally runs on port 69/UDP.

Generally, there’s not a lot of call for TFTP to ever be open on the big, bad Internet. There’s no concept of login; no usernames, no passwords. It’s as insecure protocols come.

So, given that Internet-available TFTP servers should be as rare as hen’s teeth, what the heck is going on with the sudden spike in packets directed to 69/UDP?

When you’re confused by something that you’re seeing on the Internet, it helps to remember what I will, henceforth, be referring to as Liston’s Two Laws of the Conservation of Packets:

1) Packets don't lie.
2) Bad guys never do things for no reason.

If the ‘Net baddies are slinging packets, there’s always a reason. It may be a stoopid reason - but there’s always a reason.

Let’s take a look at the packets. Essentially, with the exception of the source IP, they’re all the same. This is absolutely some kind of tool. Here’s an example packet (grabbed from one of my ‘Net sensors) that shows us pretty much everything we need to see.

If you’re not familiar with the packet-level workings of TFTP, let me ‘splain. This is a TFTP read request (an RRQ in TFTP-speak) … pretty much the TFTP equivalent of an HTTP GET request. It’s, essentially, saying, “Hey, can you please give me the file named ‘x’?” If there were a TFTP server hanging out on this system, it would dutifully check to see if it had a file named “x”, and if it did, it would begin sending it. Otherwise, it would send back the equivalent of a “file not found” message.

TFTP is a pretty brain-dead protocol. As I’ve already said, there’s no concept of authentication; no usernames, no passwords. You can’t list a directory using TFTP… you basically need to know the filename you’re looking to grab in advance. This simplicity makes client code small and easy to write / integrate into low powered devices to use to grab a specifically named configuration file on boot.

So I’ll ask again: TFTP? What’s up with that?

I’m sorry. I can’t hear you. Please speak up!

Amplification is the name of the game…

Let’s say you’re a skeevy bot-herder and you’re looking to make some bank by performing a DDoS attack for hire. You’ve 0wned enough systems that your bots can generate around 200 Mbps of traffic. While that’s probably enough to knock one of your gaming buddies off the net when he’s camping on a spawn point, it’s not really DDoS-for-hire material.

But what if you could find a way to turn your 200 Mbps into a much bigger stream of data? What if you could multiply the size of your DDoS traffic? What if that amplification was, essentially, free?

Here’s what you need to do that:

• You need some way to send a single, relatively small packet and get back a MUCH bigger response.
• You need to be able to impersonate your DDoS target so that the response will go to them, rather than back to you.

Hello TFTP…

Because TFTP runs over a connectionless protocol (UDP), you can easily impersonate your target system. You simply send a UDP packet with a faked source address to a TFTP server, and it’ll happily respond back to the system from which it thinks the packet came. Better still, if you can find a real, live, Internet-accessible TFTP server, its response will be appreciably bigger than the packet you send… somewhere on the order of 30 - 100 times bigger.

That’ll turn your 200 Mbps into 6 Gbps - 20 Gbps, and that’s not too shabby.

But now, you’ve got one more problem… finding a TFTP server, UDP is a notoriously difficult protocol to use for a port scan. Ask anyone who’s ever done it about the joys of UDP scanning, and they’ll give you a pained expression and walk away shaking their heads.

Seriously. Go find someone right now and try it. I’ll wait…

I was right, wasn’t I?

If you are doing a UDP scan for targets, then you’re probably just looking for systems that don’t respond with some sort of ICMP unreachable error and calling it a win. When you find one of those, you’ll be painting that sucker with all the UDP-source-impersonating-TFTP-RRQ-love you can muster. Thus the spike seen above.

One of the downsides of monitoring Internet traffic for all kinds of badness is that whenever you see something shady like this going on, you’re left wondering, “Is it me, or is it everyone?” I don’t know. I’m seeing this on one system, but I don’t know just how widespread it may be.

TFTP? What’s up with that?

I’ll tell you what’s up with that:

If the bad guys can find themselves enough TFTP servers that have been left open on the Internet, then they can use the combined bandwidth of those TFTP servers to wreak all kinds of havoc.

So, even though the likelihood of finding one is low, let’s just say that the value of a TFTP server - if found - isn’t so very… well… TRIVIAL.

-TL
Tom Liston
Owner, Principal Consultant
Bad Wolf Security, LLC
Mastodon: @tliston@infosec.exchange
Twitter: @tliston
April 9, 2021