 Thanks for waiting patiently. Morning everyone. What time is it? Obviously it's 10.30. So, anybody having questions before we start? We'll do like a little bit of quick questions. Yeah. Is it unethical to rent out the incoming file so that if we can't figure out what you're doing in the test, at least see what the file looks like so that when you go for it. Yeah, I'd say it's definitely. And that would be not ethical behavior since you're trying to get the, like printing a file out of the standard error is not really. I don't think there's anything especially tricky. I think it's only stuff that has been talked about. I mean, I could all look at it again to make sure there's nothing wrong. What's the comment test on the host file? Comment test on the host file. Maybe you're not reading it correctly. Maybe you're not testing it. That's also possible. Because we are having to debug your code a little bit. Yeah. So it's making it twice as hard to figure out. Twice as hard, that's a little. Yes. I'll say it's people that fast to the complex host test. There's only one test. The complex authorize key is the one. The authorize key is the one that's tricky that I don't think. Right. And then the host's one is the comment one. How about the people who have got that? Maybe not you, but those people have. All right. Great. Other questions? The actualize keys. It's really amazing the format. So I see that we have the things that look like you act and then host, right? And then we also have the field from the list. Yes. I decided on the group. But they didn't actually get what it means. So do we actually get the host from the from field as well? Yeah. Any place there's a host, right? So that's why you're. But do we actually get the characters like asteris and the question mark? Yes. Whatever you see that looks like it could be a host. Yeah. I mean, you should include those. Okay. That's not what we're testing. So. Are we supposed to include the host that are coming in out from the host? No. You should definitely not do that, right? Because a comment you should ignore. I'm going to stuff from other places. So I just want to be sure. Okay. Yeah. That's the only case. Yes. You're right. But yeah. Another case is right when it says like, don't read from comments. You shouldn't read from comments, right? Any line that starts with a hash? No. Depending on the file format. Yeah. Some of the file formats, it has to start with a hash to be ignored to be a comment. Some of it is a hash to the end of the line of the comment, right? So those are the things you should definitely ignore too. All right. Well, let's continue. So we were talking about hopefully blind IP smoothing. This is where we left off? We leave off on wrapping. I'm going to remember I meant to check beforehand, right? So we looked at a little bit of review, right? So we looked down on Wednesday. We looked at how routing is decided, right? How our machine, how each machine decides where packets go, right? Here they go to this host, to this other host. How do we know when it goes out, right? So we look at our routing table and we look at if it's matching a host address, if it's matching a network address, if it matches a default entry, right? And if there's a default, if it's not and it doesn't match anything, then we get a response back that says, hey, I couldn't route your packet. And so we can set up these routes either statically or dynamically using routing protocols. So on this terribly animated slide, right? So what this gets to is can we do, so what do we mean by blind IP smoothing? What do we mean by smoothing? We've looked at that, right? So what am I going to try to do here? Just make up an idea. Yeah, so I want to... Ideally, right there's this. We have these two hosts on the right. We have 128, 111, 4110, and we have 128, 111, 41, 135, right? And we have our other host that's on the 111, 10, 20, 121 address, right? So these hosts are on completely different subnets, which means any packets that we send out from one to the other, right, we're going to have to hop from R from us here over to there. So the idea is if there's a trust relationship right between 135 and .10, right? Then is it possible for us, all the way in this other network, to spoof a packet to make .10, think that it came from .135? So what we want to do is us, we want to send an IP datagram with the address of that trusted host, right, with 135 to make it seem like we're spoofing from address, right? We're saying, yeah, yeah, this is a packet from 135 to 110, right? So we can do that, right? We send out the packet, we submit the IP address, right? Our gateway says, okay, where does this packet go, right? That's part of the routing protocol. Only the destination is checked to decide where to route it. So then we say, okay, it goes here, it goes here, it goes here, it gets to .10. It's great, right? So .10 gets it, does it know that it came from .35 or from us? Yeah, .135, right? It seems like it came from there. It doesn't know that it came from us. But what happens when 110 replies to 135? When we walk us through what happens, right? So it's on the local subnet, right? It's going to reply to 135. It doesn't know to reply to us that the packet came from 135, right? So it says, okay, I want to send a packet out to 135. Hey, that host is on my local network. Great, so let me just send that packet back to them, right? So do we ever get, when we're trying to spoof, do we ever get the reply back? No, and that's the key here, right? This is why it's called blind. So we don't actually see the reply to our spoofing attempt. And this is why it's very, very difficult because, you know, how do you know if you've succeeded? How do you know if you've actually successfully spoofed that IP address and done what you wanted to do, right? And so, yeah, so the host that we're attacking, right, is going to reply to be impersonated with a spoofed host. And then we usually don't have access to that, right? Because if we were on the local network, it would be trivial, right? We'd be able to do it very easily. But since we're outside of their network and we're just trying to send an IP packet, we don't have access to that. So, yeah, this horribly diagrammed thing would say something like 135 is, we send that out, right? Every hot form is that. And the idea is, right, we're trying to take advantage of this trust relationship between these two systems. So what kind of defenses could we do against this at a high level? Does this work nowadays? Is this an old thing? Maybe in the Gateway 11, for the network which is identified where the packet should go into the local network, we should check if the from IP is also one of the local networks. Yeah, right. That would actually be an incredibly trivial thing to do. Surprisingly, it doesn't happen everywhere. You could understand maybe at a big network, it would maybe be difficult to understand maybe all the IP addresses, or maybe ingress and egress traffic goes through different switches or routers, so maybe they have different rules. For whatever reason, obviously in the backbone rank, that's a little too big to care because you're just throwing packets around. But yeah, so actually some networks do do this. So some networks do filter, and you can't actually spoof a from address from a network that's not inside that network. But in a lot of things, they could actually do this. There could actually be, I was thinking, another defense here, right? When dot 10 receives the IP packet, it could look at the MAC address and say, hey, this is coming from the gateway, and not from 135, right? So this is kind of strange. Maybe I shouldn't trust this packet. But yeah, honestly, don't do that by default, anyways, either. So yeah, so this just relies kind of on the basic routing protocol to be able to do this, right? You send it out of the packet, and it goes along the network. So we can also, right, so we also perform man-in-the-middle attacks in these routed networks, right? So what happens if we're able to control a gateway or a switch? We have everything, right? We can sniff all the traffic that goes in between us. We can intercept or block traffic that we don't like if we wanted to maybe, I don't know, censor something like an entire country. We could just get all the switches and all the traffic coming in and out and block things that we don't like. Because there's no other way for that traffic to get out. It has to go through our switch. We can modify the traffic. We can do a full man-in-the-middle where we actually impersonate another server, right? So they think they're talking to Google.com, but really, they're talking to us, and we talk to Google.com on their behalf. So what are some of the popular switch manufacturers, gateway manufacturers, like Enterprise, Cisco, right? It's a big one. How good of security do you think Cisco has? What do you think they care about the most? Probably two things, I would think. Availability, I guess. Availability, right? And performance, right? How fast can they sling packets? And can they do that without ever going down, right? Probably maybe like maintain, like, configurability or enterprise validity, or I don't know, there's probably some on the third one. But those are the two things, right? It's not really security is something that they care about because, hey, if someone used dumb switch, why would they, whatever. So it turns out there's researchers at Columbia who've done research into the identified laws which is going to be super confusing. Anybody know the name of the Cisco operating system? IOS with a capital I. Did not get anyone confused. So yeah, so they found remote code execution flaws in IOS and then they did a scan of the internet and they found tens of hundreds of thousands of hosts, not hosts, but switches that were vulnerable to their attack. Some of the stuff was actual, you know, real attack. Some stuff was just default username passwords on the switches. Some stuff was misconfigured, no authentication, no passwords. And then they developed a way that you could get in there completely control the switch and change it. But it would look, the configuration page would remain the same like they basically developed this really sophisticated root kit in this switch environment such that you couldn't tell that your system had ever been compromised unless you flashed or checked the BIOS. So this is, you know, you don't actually have to physically be one of those switches or in between. You just have to take over one of those switches, right, in that picture. All you got to do is take over one of these switches and you can man the middle and mess with a lot of traffic. And they showed that it's kind of trivial to do that. So this is why you should, yeah, there you go. Okay. So we discussed fragmentation at a high level, right? So what was fragmentation specifically in, like, IP and Ethernet? What's it used for? What's the purpose? The link capacity, the link capacity may not be... Yeah, so it's actually, I mean it's a little bit of a quality service thing, right? But the problem is, so the IP layer, you can send packets up to 65,000 bytes, right? But the link layer, right, that physical layer below that maybe can't support packets up to that size. So the idea is, well, we shouldn't... We're at a higher level, right? IP shouldn't care about whatever you use to transport the packets. But we have to know what to do when a switch gets a packet and it says, oh, this is 60,000 bytes. Oops, I'm on a link that's only 15,000 bytes. Did you just drop it? Right, I mean that's one option, but then how does the other one know what to do or what size to actually try and send it so that it will be successful? So they added this fragmentation set of options to IP, which seems like a good reliability thing, but we'll see it actually has pretty severe security consequences. Yeah, so the idea is fragmentation allows the switch or the gate router or the host even if necessary to split up an IP packet into smaller chunks. So it takes one large packet and splits it up into n number of smaller chunks. And obviously the case this happens, right, is when it can't actually be transmitted. So it could be anyone, a host could do it, an intermediary could do it, unless the IP packet has the do not fragment flag set and then you'll get an error back. So these, I remember it's our nice awesome IP diagram table of the headers. So these are the flags that are important. We have specifically the reserved bit, the don't fragment flag, which is what the host sets to say, hey, don't fragment this packet, and then another flag that says if there's more packets to come. So reserved doesn't do anything. The don't fragment controls if we want fragmentation to happen or not. And then the more fragments says if we actually have more fragments that are coming. So the way this works is, so if we can actually fragment the, so, right, we kind of got to think about this. It's a little bit of an engineering challenge. Okay, so I have this packet. I'm going to be splitting it into multiple packets. But then what does the host have to do? What does the host get? So receiving host. You should combine all the way. That's some way to combine these back back to one, right? Because the application layer doesn't care that this IP packet was split up into multiple packets, right? It just wants that one. If I send you an IP datagram of 60,000 bytes, you better receive the same 60,000 bytes on your end. You shouldn't care that it's been fragmented or changed, right? But it still has to be an IP datagram. That's the other key, right? So it's still an IP packet. So what about this has to be the same? What has to be different? Do we just split up the data and just send the data on its way? What was that? The header cannot be split, but... Yeah, we have to keep the header intact, right? We got to make sure that it's going to get to the same place. So the mtu should be larger than the header. Exactly, yeah. So we have to split it up so that the data minus the header is less than the mtu. Data plus the header is less than? Yeah. But we may change some of these flags. So the important thing is we copy the header to each fragment that we're going to create. So it's very thus identified, I guess. Yeah, so that's another thing, right? How do we know? How does the host know when it gets all these little fragments? How does it know which ones are fragments for me and which ones are fragments for you? So is it the source IP and the destination IP? No. It would be a sequence number. The identifier. Yeah, so that's actually when we looked at the identifier, right? The identifier or the weekly identifies that IP datagram. So we specifically can't use the source and destination, right? Because then any IP packet that I send to you, you may think, are they the same? Are they fragments? Are they not fragments, right? If I fragment two packets into multiple little packets, how do I assemble all of those little tiny pieces into the two separate packets? So that's specifically what this identifier is. So identifier is critical to copy to each of the packets. Then we know, in some sense, that ordering of the morph fragments flag. So that's set for all but the last. Then the important thing is that there'll be a fragmentation offset field which specifies, okay, from the original datagram, so like the original, so if we take a packet, fragment into two, right? The first one, the offset's going to be zero because that data is there. And the second one's offset should be the size of the first fragment. So that way the receiving operating system knows how to reassemble those packets. It can say, okay, I know this one goes here and I get a new one. Okay, I offset that from the start. That means it goes there, right? And that's how it gets there together. And then it has a total length field changes obviously because we're changing the size of the data, right? Makes sense. Then we just send each fragment as a separate datagram. So if this increases a little bit of risk, right? Because this means, hey, if any of these datagrams is lost we can't reconstruct the packet. So if anything's lost we just discard everything. So we can actually see this. If you send a ping request, so with the ping command, ping uses the IMCP, the Internet Control Message Protocol, an echo request. And you can specify a size to send. So you can actually do this. You can do a ping, set a large size, and then sniff the TCP dump to see that we have different packets here. So we can say that. So this is the, so we know we have, okay, how to parse this, these are time stamps. This is from IP.69 to .70. And then we can see that this is the fragment ID, or the ID of the IP packet. So we see all these packets. We know they're the same fragment because they're there. The frag would be the fragmentation flag. And then this would be maybe size and offset or something. I'm not actually 100% sure how to read the rest of this. I think this would be size. Yeah. And then TCP dump has seen all the fragments, so then it's able to reassemble them. And once it reassembles them, then it says it's an ICMP echo request. The one to the right will be the offset and to the left, off. The offset and then the left is the size, I think? Yeah. Because the last fragment would be... Ah, yeah, yeah. So this is offset zero. Right, right. So this is the first. So it's actually going in reverse order. In reverse order. Right, interesting. I wonder what that is. What also makes sense is this is the last one, right? Because it has the smaller size, right? So you try to do as much size as possible. What's 1480? Why is that a coordinate? That's the size of each... Why 1480? MTU size will be 1500. Yeah, so 1500 for Ethernet, and so... 20 is the header size of IP. Yeah, 20 bytes is the header size of IP. So we have header plus data is 1500, which is the maximum transmission size of Ethernet. So that's where that comes from. Cool. So actually, so it seems like a pretty simple mechanism, right? Split packets and packets, right? It causes a lot of security problems. One thing, a kind of classic problem, was what they call the ping of death. So the idea is the operating system, right, has to reassemble the original packet, right? The receiving host has to reassemble the packet. Well, it does this by calculating offsets, right? So what happens if I mess with that and I actually say that I create fake fragmentations and I make it so that where you place the offsets are actually more than the original data that I said that the packet would have? Or even I could make it, in this case, the ping of death was you would say, you would actually create fragments that created a packet larger than, what was the size of IP, 60? Yeah, so we'll see. So it's actually more than that. So the operating system only statically allocated the size of a max IP packet, because hey, this is the maximum size of an IP packet ever could be. But I can actually send and make it seem like there's more because it's just offsets and lengths, right? So I can get you to kind of overwrite that buffer. So it would cause a kernel panic. So what happens when a kernel panic happens on your system? Does it go out? If you've ever seen one, throws a bunch of warning messages and then it just shuts down, right? So you get nothing. So you were able to think about this, right? Just from an impact perspective, you're able to completely bring down somebody's machine just by sending some packets out. And what do we know? So ICMP, so a ping, right? Is ICMP? So that means it only uses the IP layer. So what do we know about the source and destination of the source of an IP layer packet? It's not checked. So I can make it seem like it's coming from anybody, right? I can send all these ping of death packets and make it seem like it's coming from you. And then you go, ah, my computer crashed, and then you look at the logs and you say, oh, these weird packets from Ryan. Okay, good. And then I'm going to go after him and think that he actually took down my system, right? So you can do this by hacking your IP address, which is also a really important thing. So we can actually see this attack in action. So we can see that we have an ICMP request here. So we can see we're fragmenting it, right? And so we have 148 so that we have all this up here and we're saying, okay, 1480 is the data. And we have all these packets. And so we get down to here. And then finally right here, I say at 65.120, I'm going to write 398 bytes. So how do I figure out the total number of bytes that I'm writing on this packet? The long packet offset plus the length. Yeah. I can look at the offset of the last packet, the highest offset plus the length, right? That's going to be the longest I've written. Somebody quickly in your head, what's 65.120 plus 398? I'm just kidding. It's 65.518, right? Plus the 20 bytes of the header for the original IP header. Means that we sent the machine 65,538 bytes instead of the statically allocated 65,535. And so the machine crashes. The kernel crashes. Pretty crazy to think about. I mean, maybe not one, but a few packets. And you can completely take down a system. But this isn't the only use of fragments. So what are some things that we have to think about? So this kind of shows that when you're receiving it, you have to think about the length and make sure you're not writing outside the bounds of that packet. So think about it this way from an attacker's perspective, right? What is an attacker control here? What is it? Yeah, of these fields, right? What is the attacker control? Source IP, destination IP, definitely. What else? Offsets, size, everything, right? So this is an IP packet. It just comes from the attacker, right? They can control every single thing in here. So what happens if two of the fragments are overlapping? What if I send a duplicate, a fragment for a duplicate data segment, right? With different data. Would that be useful? It's only a PCP, right? All this has is an ID, so we have the... The ID here is 4321, right? That's all we have. We have ID number, we have offset, and we have length. Those are only three things, right? There's nothing that says I can't create another fragment packet with the same offset, same length. And then the question is, what happens on the receiving end, right? Is it ignored because it already received that? Does it overwrite and change things? That depends, right? So in generally fragmentation attacks, they actually illustrate a really important principle that I want us to kind of think about. But we'll talk about some of the examples, and then I want to bring it up a little bit higher level. What does evasion mean? Packets on the network, right? So am I really evading anything? Can I make it so my packet just magically appear on your machine? Evading all the network? Not really, right? It's still got to come from me through all the hops to you, right? I can maybe... Well, so what do I mean by evasion? Evasion, not evasion. Yeah, so what's a firewall? Right, so it usually sits on the case, right? Of the network, and it has rules that say, hey, if a packet's coming to this host, drop it, or if there's a certain packet like this, drop it, or redirect, or whatever. So it's a way to control people accessing your network, right? What's an IDS? What does it stand for? Intrusion Detection System. Right, so what is that? It detects the signature of the packet. Yeah, at a high level, right? So it tries to identify attacks in traffic, basically. Okay, so it's looking at what's going on. It may have rules. It may have a learning algorithm. It may have all kinds of crazy stuff. It could be as simple as a hopefully highly-paid person looking at all the traffic and seeing if anything is weird. Be not very feasible for a lot of things. So IDS Intrusion Detection System. IPS Intrusion Prevention System. Basically, the main difference there is an IDS is completely passive. It just looks and will alert if there's a problem, where a prevention system does exactly that. So its goal is to try to prevent and cut off the attack if it sees something happening. Anyways, so yeah, so when we talk about invasion, right, we're talking about, hey, let's try it. So these are all security products, right? So if I send you an attack and your firewall drops it or your IDS triggers, does that further my goals as an attacker, right? Because the organization was alerted. It would be even better if I was stealthy, right? And so the best case scenario for the attacker is I get into your network, I attack your machine and you have no idea about it, right? So that's why evasion techniques are interesting. The important thing is firewalls and intrusion detection systems are looking at the traffic. So what they have to do is they have to analyze the headers, they have to analyze the TCP, you know, what ports it's using. The TCP, UDP is ICMP. Does it have any center act flags, right? These are all kind of a lot of higher level things that it's looking at. It looks at source and destination IPs, right? So what if we can play with the packets, right? What if we can, with fragmentation, right? If the firewall sees a packet, but the host sees a different packet, right, because of the way it put the fragments together, that's pretty good, right? Because then the, in essence, the firewall has seen a different view of the network and the traffic. So one thing we can do is we can try to avoid filtering by using fragmentation. Oftentimes the firewall is going to have to decide if it allows that packet through or not, right? It sees a packet if that's to say, do I allow it or not, right? And so with fragmentation, it doesn't have all the data, right? An IP fragment only has a part of the higher level data, right? So then it has to decide whether I let this go or do I not let it go, right? So some firewalls can make a decision on the first fragment to let it through or not let it through, right? So we can maybe trick it to let us through on the first one, but really the thing is actually kind of malicious what we want to get through. But it would analyze each different like packet, like if there is an entirely new format packet coming. It may. That's the important part, right? It depends. Now we're getting into how is the firewall implemented, right? They're all implemented differently. If we get the firewall to crash, that'd be great, right? It's definitely not working. We just do that enough that they actually disable their firewall and then I just get in their network, right? So another thing you could do is you say, hey, you send a first fragment with the very first part of the packet, right? So the very first part of the packet is TCP and you haven't looked at it directly, but it's going to contain the support numbers, right? So then the firewall says, okay, this is a TCP connection to the web server. Good. I'm going to allow this packet through, right? Then what we can do is we can actually overwrite those either ports or flags with other TCP fragments, right? So we can change the offsets so that it's actually overlapping with what we already sent. So we could change the packet to actually be to a different port, right? Or a different machine. So yeah, we could maybe even write the source or destination or we can change the flags. So we're sending a SINAC packet. SINAC... We're sending an AC... What the firewall thinks is an AC packet, right? It may say, oh, this is an ongoing communication, right? It's not in the start of a communication. I'm going to let that through. But then with an overwrite, we change it so it's actually a SIN packet. So we're actually able to start a new conversation with the host we maybe weren't able to do in the first place. So we can also... Yeah, so doing actually this packet... So if you think about it, right? If we're to do this successfully, we want to reassemble fragments, right? We have to keep track of all the fragments that we see. We have to store space on our... If it's an intrusion detection system or a firewall, right? If it's going to try to keep track of these, it's got to create space to store them, right? So, you know, oftentimes for performance reasons, they just won't, right? So if you fragment your packet, you get completely past the intrusion detection system or the firewall. And this is a key thing, right? This is what I said about that differing view, is if an IDS sees a packet differently because of our weirdness of offsets and the host operating system does it differently, maybe this card's that, right? Maybe two hosts have different behavior. Now the intrusion detection system is seeing different traffic. And then we can do this, like I said, for a goss attack, right? So we can try a ping of death attack. You know, it doesn't affect modern operating systems, but maybe they're firewall, whether they're IDS or old, and it can affect that. Yeah, so if it does try to build it up, right? What if we send a bunch of fragments but never complete them, right? A bunch of 665,000 but never send that last fragment. So it just has to keep, make these buffers larger, right? Waving around for that last packet so it can finally reassemble the fragment into a final packet, but we never complete it, right? We just keep doing this. At some point it's going to run out of memory, right? Whether it does that before it frees the packets or not. That would be an interesting thing to think about. So this is why I really like, like, you know, this is something that's, fragmentation is something like incredibly networking technical, right? That oftentimes we never have to think about because all the other layers do it for us. But the important thing is for security purposes, right? We need to understand exactly how this thing works and then we can actually derive a tax from it, right? The tax come from this feature so we think, okay, is it due firewalls process? So this is, I think, the key technique here, the key idea is the key question, does the security tool process this complex technical thing the exact same way as the host that it's protecting, right? Does it see it as precisely the same way? And if the answer is no, then we can usually bypass that security technique. So what do antivirus standards usually do? What do they do at a high level? Take a signature of the user. Yeah, so they have humans, right? Write signatures of malware all day and then how does it detect the virus? This is incredibly simple. So it has just this huge database of rules, right? Every time you open a file before it opens it or when it's downloaded or a file appears, right? It checks the signatures against that file. It doesn't match, it doesn't match it. It matches, it stops you from opening it, right? But often file formats like a zip archive, right? There's a specific file format with different files inside where a PDF has a specific file format, right? So oftentimes antivirus scanners want to look at and try to understand those file formats, right? They want to maybe just doing a raw, just doing a scan of the bytes itself isn't enough. They want to look at the files in the zip file or whatever, right? So a key question that actually comes from this, so there's a research paper that looked at and tried to ask the question, is it the same, right? Antivirus scanners see files exactly the same as the operating system. Is it possible to create a zip file that maybe the operating system accepts as a zip file but is malformed in some way, such that the antivirus scanner crashes and is like, ah, this is an invalid zip file. Well, I can still unzip it, I can still double click on it. So I found a lot of these cases where it's this mismatch between the security tool and it's able to analyze a tool and the operating system able to analyze a tool. Now they've taken this even farther where they actually try to attack antivirus and try to exploit vulnerabilities in the antivirus to get on your computer, which is even cooler, it takes it to a whole other level. Questions on this stuff? So now because it also gets into some other attacks of the network problem, we need to talk about ICMP very quickly. So ICMP is kind of like the debug mode where you get your debug packets at the IP level. So it's a way to say, you know, hey, so the ping command basically uses ICMP to say, hey, are you alive? Post IP address. If you're alive, say something back to me, so I know you're alive, right? Because otherwise you didn't have stuff like that. It'd be really hard to debug the network to see what the connection problems are. So this is at the IP level. It's a different type of IP datagram. We either have requests, responses, or error messages, right? So these are when you get a post down or no route to post. These are ICMP messages. And so the message format, right, it's an IP, the datagram with an IP packet. So it has a type. It has the code. It has a checksum. It has any data that you're trying to find. So this is an older one. All kinds of different types of messages. You can ask for an address. You can do timestamps. You can ask for... Try to ask for a timestamp. So if they'll timestamp things and try to synchronize clocks, it's obviously an older way, right? We have different protocols for this. There's a way to actually tell somebody, hey, you're sending too much traffic. It would actually be interesting to look at if this is actually used. And if you could use this maliciously, right? Could I kind of shut somebody up by sending these squelch packets? Okay. Now, parameters, somebody would tell you, hey, you have problems in that IP packet you just sent, right? Maybe your checksum was wrong, or maybe your fields aren't aligned correctly or something. Or maybe you actually sent more data than the fields specified. Hopefully you're never getting this because this means something's gone massively, massively wrong, right? Or you're writing your own IP there. One of the most common ones that we kind of all know, right? Echo, the echo message. And then the reply is, hey, here's a reply here of your data that you sent, right? So why is that important with the echo and the data? Is it useful? Is it just a vestigial appendage of the network? Check the name, then it's true. Check the leaf. Oh, you send a message then and you get a reply. Exactly, right? So if I say hello to you, can you tell me hello back and you say E, like O, L, L, U, H? I know something's massively wrong, right? We're never going to be able to communicate it because I'm sending you data and you're sending you data in the complete opposite way, right? So yeah, this is definitely useful. Or if there's even I saw this crazy case where somebody was doing this debugging analysis and they had weird, their SSH connections would fail at certain times and it wouldn't persist and it was really weird. The engineer actually traced it down to a certain switch was messed up such that it would change a specific bit on all network traffic to one. Like a specific bit would always be set to one and it would mess up network traffic when a big file was transferred, but only through that route and not through the receiving route. Like it was crazy, so they'd use like pings and all these things to see, and I got back to 000001 which is obviously very bad. We have a TTL exceeded, right? So when our packet, when that TTL field gets to zero if the switch has been nice it should send us a message back to say, hey, your packet just expired. That's something wrong. Gateways can use a redirect ICMP message to try to say, hey, if you actually want to talk to this machine you should talk to somebody else. Which we saw we could maybe use to try to poison traffic maybe to us or maybe we'll talk about that. And we can say destination unreachable, right? So this is when we try to send the packet to somebody that the gateway can't get to. Okay, so the echo reply it just kind of looks like this. We have the identifier, we have a sequence number and we have some optional data. Right? So we think, well this is an incredibly useful debugging feature for the networks. This is the most possible way this could ever cause a security problem, right? Okay, so Ping just kind of looks like this, right? When you send it, I hope. Most people have used Ping at some point to test their network connectivity. Yeah, you should do that if you've never done it before, right? Practice. You actually do have to be careful, like I said if you're doing it on ASU's network they block all Ping's. I don't know if they block the request or the responses but they're blocking it. When you try to ping Google from outside you get a reply. So you can ping yourself, you know, 1, 2, 0, 1, 2, 7, 0, 0, 1. Oh, Lord, trace route does work from, like, 8 minutes. Interesting. You're right, it does. Yeah. So maybe it's the replies then. Yes. We should look at that and figure out what it is. Cool. And then it also gives statistics about your pet hunt information to do that. It might get upset at the start. That's a good question. I think it would be fine. So I'm sending a Ping packet. If I, the test would be I'd look at the other end and say, am I getting that request? That's just what I want to find out. I want to find out if they're doing requests. If they're blocking the request, they're blocking the replies. So that would be my simple test to find out. We can always get away with saying it's for educational purposes or something. Being an academic is very nice. A lot of things that I do are research-related. Or can be. Or class-related, right? It's like something you want to talk about in class. Anyways, Ping is also very useful, because it'll tell you any packets were lost. It'll tell you statistics on how long it took for the packets to come back, right? So it'll give you the round trip time, the amount of time it took the packet to get there and then it'll go back. It'll do sequence numbers. So, when we send an ICMP echo request and we get a response back, what's one thing that we know? There's a few things we know. What's one thing we know? Close it? Yeah, we know that so we know that machine, we're able to talk to that machine, right? So we know that, hey, there's a correct path from us to them and there's a correct path backwards, right? They can talk to us, right? Over IP, which is really important. We also know that correctly, the data gets sent, right? We saw that, the data gets sent back correctly. We also know that that machine is up. If the machine, if we don't get an echo reply, does that mean the machine is down? No, and that's the important thing to remember, right? Just because we don't get a reply doesn't mean that that machine is down. There's nothing that says that a host has to respond to these requests. You know, if you ping like Bing.com or Microsoft.com, they block all echo responses, right? So you're not going to get any reply. Maybe they... So you can actually use this to try to identify hosts on a network, right? You say, okay, I'm on the subnet 192.168. 192.168.1.255, that subnet. I can try to ping every host from 192.168.1 all the way up to 254, right? And if I get replies, then I know that those hosts are up and responsive to me. So this is called a ping scan or an IP sweep. So you send an echo diagram, right? You just send echo requests to all these hosts and then you collect replies to determine which hosts are definitely alive. So you can use the tool... I don't have the command in here. You can use the tool Nmap is a really good networking tool to do these kinds of things. We'll see it at multiple points. And it does this. So you give it a subnetwork and you say, hey, do a ping scan on this subnetwork. It'll try all this. It'll get all the replies and it'll say, hey, this host is up. This host is up. So instead it tried 256 IP addresses and it got five hosts in there and it's able to do it in one second. The other cool thing is it can be used for an attack which is like, this is cool because you're able to do reconnaissance and understand what hosts are up because that can tell you where to attack where to go on the network. You can also use it for a denial of service attack. So I don't even know who the smurfs are. Some of us maybe not know. You should raise your hand if you can watch the video on Monday. Little blue people. So the idea of a smurf attack is I know about let's say three subnetworks. .1, .2, .20, different subnetworks. There's a machine I want to take down. I want to take down this .10 machine. I want to perform a denial of service attack again. But I'm just me. I'm just one machine. So I usually can't generate enough traffic to take this machine offline. I'm just one machine. I can't do it. But what if I sent a ping packet, an echo request from me or from, sorry, from 128.111.41.10 which is not me. I'm spoofing that source address. And I send it to 192.168.1.255. So what's 255? Is that an IP address? Broadcast, right? That's the broadcast address for this subnet. So what does a broadcast address mean? . Yeah, it's for everybody on that subnet, right? So what happens when I send this packet and they all get an echo request from 192.111.41. What are they going to do? They're going to reply, right? With however many hosts are on that subnetwork, right? So now I sent one packet and I got up to 255 packets sent for me to that host, right? I can choose another subnetwork, send one more packet to .2.255, right? And they're all going to reply back to that person. And then I do it to the third subnetwork, right? So I'm able to create all of these packets just from three packets here, right? So this is what's called a Smurf attack. So now machines won't respond to a broadcast pain like this. Because it's a problem. But it goes to show you how this thing is used to leverage and to even something simple, like a ping, a simple ping packet can be used for a dynamic service attack. Great. Cool, we got through a lot. I'm happy.