DEMO: Ping of Death

Why Study the Ping of Death

One thing about the ping of death is that it's not really an effective attack nowadays. It is really for older systems like Windows 95 and how Windows 95 handles this particular issue. So it really is not an effective attack in most cases.

If this is not really a super effective type of attack, why are we studying it? I feel like there are a few great reasons for this.

• Just to be familiar with the term, so you understand what it means. It still comes up now and then.
• Because it's a great example of protocol and application weakness. It's both a protocol and an application weakness, and how they interplay with each other, so we can see how that comes out.
• It really drives home the point of don't keep legacy equipment around. This is the type of stuff that's never going to get patched and fixed, because this is on older legacy equipment, and new software, new applications, new operating systems don't have the same issue.
• To make sure that we avoid the misuse of this term, because it is still a term that's used out there now and then. You'll still see it, but we won't apply it to the wrong type of attack.

Maximum Transmission Unit

Before understanding what ping of death is, we first need to understand what maximum transmission unit, or MTU, is. This is the max that can be sent across a network connection. For instance, for Ethernet, it can only have a payload up to 1,500 bytes — typically, at least; generally it's 1,500 bytes. So all your equipment is expecting a certain length of Ethernet frame, and that frame is not to surpass a certain amount of bytes.

Here's that Ethernet frame. The payload to the Ethernet frame is limited to 1,500 bytes in most cases. And then you have the frame itself and details in the frame itself. We can see that that adds up to — well, we have up to 18 bytes here and we have another four bytes here, so that's 22 bytes. So our maximum transmission unit for the frame is 1,522.

But for the payload, which would be IP in this case, we're going to be talking about IP version 4. Specifically, I'm going to show you the IP version 4 header. That's going to exist right here inside of the payload.

The IP Version 4 Header

Here's what an IP version 4 header looks like. We have several fields here that we can enter data into so we can get this packet from one location to the next. One of the pieces of information that's stored inside of this IP version 4 header is the source IP address — this is where this packet is coming from. And then we've got the destination IP address — where is this packet headed to? So we've got lots of information on the delivery of a packet.

One of the pieces of information that's in here is the total length. This is the total length of the packet. In other words, that maximum transmission unit of a packet, 1,500 — the actual size of it would go into here to let whatever is receiving this know how big that packet is.

But take a look at what we have here. We have 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16 bits for this. Sixteen bits. So to figure out how many different possibilities we have with this, or to identify the total size of this packet, we can take 2 to the 16th power. 2 to the 16th power is 65,536. That means that we have a range that we can identify between 0 and 65,535. So that is the range of how big an IP packet can actually be.

Remember, the maximum transmission unit for Ethernet is 1,500 bytes, but the maximum size of an IP packet can be 65,000. So that's a big difference between those two.

Why the Sizes Differ, and Fragmentation

If an Ethernet payload can only be 1,500 bytes, then why in the world are we allowing IP version 4 packets to be 65,000 bytes long? The reason is because this IP packet can traverse many different networks. It doesn't necessarily have to be always Ethernet. In this example right here, we've got two Ethernet networks, but in between we have these WAN connections, and they could handle maybe a lot bigger packets, so we wouldn't want to limit IP packets to just a certain size. Not to mention, maybe we want to do upgrades to Ethernet. There are times when we actually increase the MTU for a certain network to be larger, so we could allow that to happen on some of our networks. There are downsides to doing that, but it is something that we can do.

So then we have to ask the question: what if we get a packet that's 65,000 but is going into an Ethernet network that is only accepting a maximum transmission unit of 1,500? That's where fragmentation comes into play. What will happen to this packet is it'll be broken into smaller fragments and then sent across the link, and the IP header has a mechanism in place that we can do this fragmentation with. Notice we have a fragment offset and we have a flag. So if a packet gets broken up into several smaller packets, what will happen is we will turn this flag on on each one of these smaller packets and then we'll label them like a sequence number. We call this the fragment offset. So they'll have a fragment offset, and that way it can send it across the link and then get reassembled on the other side in the proper order.

Where the Attack Comes In

Here's where the big issue comes into place. Older systems are expecting this 1,500 maximum transmission unit. So now when you get all these packets that need to be reassembled, to put back together, that can cause problems on the older systems. They were only expecting smaller packet sizes, and they weren't expecting to have to reassemble these packets and then deal with these larger packets. Since these older systems weren't able to handle it, it caused problems on those systems.

Really, when you boil down what the issue is, it is a buffer overflow issue. There's a certain amount of memory that's been allocated for a packet, and now when the packet comes in and starts assembling all these fragments back into the packet, suddenly it overextends past what was allocated to store this. So the packet takes up more than the buffer that was allocated for it and starts overwriting other data that's inside of memory. Hence, that opens up the possibility of a ping of death.

Windows 95 was one of those operating systems that were susceptible to this, and all we have to do is send a really large packet, something that is maybe 65,000 bytes big. What's going to happen is it will break it down into smaller fragments. Those fragments will be sent across to the Windows 95 machine. The Windows 95 machine starts assembling those fragments, and then it fills up that buffer and overflows that buffer, crashing the system, and it brings that system down.

The Demonstration

Remember, this is for ethical hacking purposes only. If you're going to use this technique, only use it on your network or a network that you've got permission to carry this out on. Otherwise, there could be fines and jail time.

Here I'm on a Kali Linux box, and what we're going to do is just ping the default gateway, because quite honestly I'm not going to set up a whole Windows 95 machine and then see how it freezes up. We'll just have to know that if this was a legacy machine it could freeze up.

So I'm going to just start out by looking at what my address is. I'm going to do an ip a here. We can see that my address is 10.110.19824. And on this network the default gateway is 10.110.1. So I'm going to go ahead and hit enter on that. We can see we're pinging that.

Let's use this program hping. I'm going to do sudo hping3. We're going to do the dash one to say it's ICMP, so it's the ping packet. And we're going to do 10.1 10.1. I'm just not going to do the end there; I'm just going to hit enter and let's see what happens.

So I'm getting a ping back just like I would with a regular ping. But notice it's with zero data bytes. So I have not sent any bytes with this. This is well under what we can do here.

I'm going to jump this up. Let's do a dash d, and that's to specify how much data you want to send. We want to send 65 bytes. So I hit enter, and we can see we got the ping back there.

Let's say I want to hit my maximum transmission unit. Maximum transmission unit is 1,500 for Ethernet, so we'll hit enter right there. And we see we're pinging 1,500 bytes and it's working just fine. So that is good.

And then now let's go for the ping of death. The ping of death would be, let's just do a full 65,000. So we'll hit enter there. And as you can see, I'm not getting anything at this point in time. This isn't a legacy system that I'm hitting — that's the default gateway — and so it is probably just saying I'm not going to even respond to that. So that is what's happening here: we're hitting it with 65,000. If this was a legacy system, it would do that buffer overflow and then cause the system to crash, and we could then leverage this to do a denial of service attack.

The Attack Card

So here's the attack card on ping of death: essentially, we are sending an oversized ping packet to a legacy system, causing the system to crash, and it really is due to some sort of buffer overload. That packet gets fragmented out, and then when it gets reassembled it overflows the buffer that's allocated for the packet and it overwrites other data, which crashes the system. So this only works on older systems.