Writing

Feed Software, technology, sysadmin war stories, and more.

Wednesday, February 21, 2024

A vintage network attack called smurf

In the vein of my "flash" story from a few years ago, here's one about "smurf".

Back around 1997, there was something new going around in the realm of net abuse: "smurfing" a target. This one involved a nice little trick that let you send out a relatively small amount of traffic and let someone else turn it into a much larger amount of traffic, and then that response would be directed onto your target.

This required two bits of cooperation from the environment. First, you had to be able to transmit a packet of some sort with the source address set to your target. Yes, this does mean "spoofing" the source address, and any responsible ISP should filter that nonsense on egress, but back then it was all too infrequent.

Then, you also had to send it to either the network or the broadcast address of some particularly juicy network that was laden with hosts that would reply to that sort of thing.

For example, let's say you had a network 192.0.2.0 with the netmask 255.255.255.0 (a /24). Then in that case, .0 would be the network and .255 would be the broadcast address. Back in those days, firing a packet at either of those would usually make the router spew it out to the *Ethernet* broadcast address, and so it would hit every host on that subnet which could then decide to reply or not.

So, just imagine a packet "from" your target, seemingly addressed to dozens or hundreds of machines, which then all answer at once. The attacker sends out a single ~1500 byte ping (for example), and the victim receives that multiplied by however many hosts decide to reply - not great!

There were some things which could be done about this. Routers eventually got a config knob that let you turn off "directed-broadcast" or similar, so anything arriving from the outside for a network or broadcast address would just be dropped on the floor. Unix boxes of different flavors also started gaining the ability to have packet filtering rules. (This took far too long in some cases.)

Besides that, people running networks could follow various best practices and not let traffic that's claiming to be from somewhere else in the world egress from their network. Any packet like that is either a misconfiguration on someone's part (possibly yours), or maybe some dummy trying to attack someone else. Either way, it needs to be tracked down and dealt with.

Sometimes people would use this kind of stuff as a reason to "block all ICMP", and then they would just create other problems like breaking path MTU discovery, and that would cause connections to hang with large packets and weird non-Ethernet-MTU-sized links.

Another related attack tool back then was called "fraggle" and it did the same sort of directed-broadcast shenanigans, but which used UDP instead of ICMP. The effect was the same, and it also got around anyone who thought that filtering all ICMP was somehow a good idea.

The old days weren't always good days.