 All right. And on that, let's get started. It's 6 p.m. All right, cool. So we were just talking about IP Direct Delivery. So at this point in our networking goals, we know, so let's walk through all the things that we know. We know our IP address. We know in this example, we are 111.1.20. 20, let me think. Yes, you can see that. I actually hate that. How do I get rid of that? That obviously didn't work. Okay. This card, cool. So we are 111.10.20.121. And we are on the subnetwork, right? So this is what we talked about with a subnet mask. So our subnet mask here is a slash 24. So we know that any IP address that begins with the first 24 bits, that's the same as ours, which is 11.10.20, is going to be on the same local network. And here we're trying to send a packet to 111.10.20.14. So the very first thing that our system does is it says, is that destination IP address on the same local network? We check the subnet and we say, yes, 111.10.20.14 is on the same network because it has the first 24 bits, the exact same as ours. And so then we can do direct delivery. So then once we do that, we have to then send a packet on the local network. So, and that's what we're gonna be looking at now about how we actually do that. So we're gonna look at this actually in Ethernet, in terms of Ethernet. So Ethernet is a family of functions. You've probably heard of 802.11. Has anyone, does that number ring a bell for anyone? Yeah, in what context? Yeah, so this is the Wi-Fi family functions. Actually, fun fact, I actually just looked all this up like right before class. This is something that I know a lot about networking, but not a lot about Wi-Fi. So yeah, 802.11 is the Wi-Fi specification. So the 802 part actually is a family of functions that define all of the networking lower level protocols.11 is Wi-Fi and .3 is actually Ethernet. So they're part of the similar family of functions. We're going to be looking at Ethernet here. And the cool thing is a Wi-Fi actually borrows a lot of Ethernet. So a lot of the concepts still apply. Obviously it's transmitted over a different physical medium. So remember we looked at the OSI networking model and we had at the very bottom physical and then link. And so obviously data traveling along a physical Ethernet cord is going to be different than traveling physically through the air. How that happens, I don't know, you gotta be probably an EE slash physics person to really fully grok that, which I am not. So I stick mainly at the link layer. So, but then we can look just like we had the IP. Datagram had IP headers and then the body. We're going to be looking and studying at Ethernet and looking at what it has. So now here the number here is in bytes. So we have the destination, which is six bytes. How many bytes was an IP address? Yeah, four bytes, how many bits? Yeah, awesome, thanks. So perfect. So Ethernet actually funny enough has more addresses than IP. Why that is actually I have no idea that would be super interesting. But so, and so the source and destination, so how many different possible Ethernet addresses can there be? No, it's not 32, Ethernet addresses. Yeah, two to the 48, or if we want to be really lame, we can do two to the six, wait, wait, no, no, that should be two to the six. No, that's not right either. Anyways, two to the 48, right? So there's, we already said there's six bytes here. Yeah, that seems right. Somebody tell me if we're not correct there. Anyways, then we have what type of Ethernet frame it is and then finally the data. And this is where I mentioned before that Ethernet actually has a limit on the size of physical data that it can transmit. So it can transmit up to 1500 bytes in one Ethernet frame. And then we have at the end another CRC which we talked about before is a checksum. So this is a checksum that does some integrity checking but it's not a secure integrity check. It's not using cryptography or anything. So it's actually something that you can brute force and fix if you want to tamper with these packets as they go across. And so the type field specifies what type of packet it is. There an Ethernet frame it is. It could be an IP datagram. And so what's gonna be right here at the start of that IP datagram? Yeah, at the very start will be the version but what's the things that's at the beginning of the IP datagram? There are a bunch of fields. I'm not expecting you to memorize all the different fields. Yeah, the header, thank you, right? So the header and then that means the rest here would be the data. And that's kind of what I was talking about I mentioned the term like onions and layers. So you have at the very first you'll have the, basically this is a very simple Ethernet header. And then you'll have inside the data there, the IP header. And then we'll actually see inside here will be the TCP or UDP depending on what is being used there, that header and then finally the data, cool. And we will look at this ARP and reverse ARP in a second. And so Ethernet is actually used in a bunch of places. So like we talked about, it's used for physical Ethernet networking but also in a different protocols. Yeah, like we mentioned, the addresses are 48 bits and this is why if you've seen a hardware address or a Mac address, it looks like this. So what does this represent? So it's very much not like IP address. It's not in a decimal dotted encoding. Yeah, so this is each, remember we talked about it's six bytes, one, two, three, four, five, six, six bytes. Each byte is represented with in text encoding. How many, what's the range of a byte? So it's lowest, zero, zero. What's the max that we could put? 255, thank you. Right, or FF, yeah. So zero, zero all the way up to zero X FF. And this is why if you've seen a Mac address, it is, so we know it's 48 bits. We know it's also another way of thinking about that is six bytes. So each byte is represented by text value separated by colons. And that's how we represent Ethernet addresses. And the fun fact is just as a little preview, even though we're not talking about IPv6, this is also a similar way of how IPv6 addresses are represented. The source address, this is again, going over the protocol here, the type of Ethernet frame and then the data, minimum of 46 bytes, maximum of 1500 bytes, along with the final redundancy check. So it's a fairly simple format compared to previous ones. And now we'll dive into what this other type of ARP is. But before we do that, I wanna go back to this diagram. And if you recall, when we talked about this diagram, we talked about this nice kind of layers of the TCP IP stack and thinking about networking. We have the physical layer at the bottom, the link layer, the internet layer, the transport layer, the application layer. And we've talked about it when we've gone to the, the internet layer, we've talked about IP addresses, how they work, we've talked about this link layer. But if we go back, and they have these kind of like, in this diagram, they have these beautiful separation, right? They're all independent layers. But if we go back to our example here, I, so let's go with what we just talked about, right? So I know I am 111.110.20.121. So I know my IP address, I know my subnet mask, I know my, I know my, let's say my ethernet address. And how do I, let's take it back to the beginning. How do I know where I want to send or make a connection to on the network? So what do I need at the IP level to make a connection or to send data, let's say, because we don't actually make connections. Yeah, the destination IP, right? Even, yeah, exactly. Where am I sending this data, right? I need the destination IP. So I do that, I check, is this IP in my local network or not? I say, yes it is. And then I need to send it. I need to take that, that IP packet, send it on the ethernet level. But ethernet, what types of addresses does ethernet use? Yeah, it uses its own type of addresses, right? They actually even have different sizes than IP addresses. So it uses 48 bit addresses, but at the IP level, do I need to know the ethernet destinations ethernet address? No, I only need the IP address, but to actually send it out at that ethernet level, I need to know where to send it. So I actually need, and this is where this beautiful layering is actually a lie because there is not this clean separation between the internet level and the link level. You actually need a way to translate between them and to say, okay, I have this IP address. What's the physical, what's the ethernet level address, the link level address of this host, of this IP address? So you need a way to map it. And that is ARP, what we'll get into right now. And this is incredibly important because as a bit of a preview, as we'll see, if you can mess with this translation, you can actually trick somebody into thinking you're a different IP address. So this is the ARP is the address resolution protocol. And the idea is it allows a way to map IP addresses to link level addresses. Mainly when we think about this is ethernet addresses. And this happens at the ethernet level. So that's why the types that we saw here in, sorry, I'm still getting used to navigating this. This is why we saw the types here. So if it has a type is 0806, that means it's an ARP request. And we're essentially asking, hey, who has this IP address on the local network? And that packet actually goes to everyone in our local network and whoever has that will respond. So this is exactly what happens. And to do this, let's draw a diagram. I think this is better for things. Okay, cool. So what machine do we wanna be talking to on our network? Oh, come on. I have to come up with all the names here. You guys can't come up with anyone. Printer, thank you. Printer, and there comes the dog, hi. Oh, okay, okay. All right, so we are gonna be 192.168.0.10 and we'll be on a slash 24. Our printer will be 192.168.0. Let's go with 20, so it's easy. And then we'll say my MAC address is, let's see, I want this to be easy. Actually, I'm gonna cheat and I'm gonna call it M of M and I'm gonna call this the MAC address of the printer. So everyone make it, everyone good, but we don't have to write out that whole thing. We can define M of M is, I don't know, 0, 0, 0, 1, 0, 2, 0, 3, 0, 4, 1, 2, 3, 4, 5, 6, and this could be 0, 0, 0, 1, 0, 2, 0, 3, 0, 4, 0, 6, whatever. Okay, so if we think about this from the perspective of us, all we're saying is I want, I want IP, let's say we say I want to send that a D, doesn't look like a D, to 192.168.0.20. So that's what a, essentially an application on M will say. So the actual way this works is the user's application will ask the kernel and say, hey, I wanna send data, some data to this IP address and the kernel handles everything else. That's a little bit orthogonal to what we need. But M says, okay, so M goes ask the question, is 192.168.0.20 local? So what's the verdict based on this address here? Is it local? Yes, great. And specifically, and this is the key thing of what we meant by is it local? This means I should be able to find this IP address on my local network, be able to map that IP address to a MAC address and then send the packet directly to that machine on the local network. So that is what that means. And then it goes, great, it's local. So then I need to do ARP 192.168.0.20. And so what this works, essentially our machine needs to, and now we're in a bit of a catch 22. How do we ask a specific machine if it's IP address? Like, is it this IP address, right? We actually, what we need is a way to broadcast a message using Ethernet to every machine on our local network. So I'll add other things. So this will be like a Nintendo Switch. This will be some smart watch. What are the devices? We like fridges, I guess, connected to the internet now. So a fridge, oh, Alex is a good one. I'll add that in here. Cool. So using ARP, we make an ARP request at the Ethernet level and this goes to everyone. So we actually have a special MAC address that says send this to everyone. So we start the ARP. So we say, basically send out an Ethernet message that says who has 192.168. 0.20. So this is the body of our message. We wanna say who has this address, right? So that we can get that. And we need to send this out at the Ethernet level. So what were the two values that we needed to send out an Ethernet frame? There's only two, there's technically three, but I'll say the third one is the type. The type is gonna be ARP, so we have that. Yeah, the destination, what was the other one? Source, perfect. Okay, so what I'm gonna do is I'm gonna send this out and source should be easy, what's the source? Yeah, MM, thank you. And now DEST is actually gonna be FF, FF, FF, FF. Can I please stop writing Fs? No, FF, FF, one, two, three, four, five, six. So this is the special address on the Ethernet level that says send this Ethernet frame to every, lucky for you all, we don't give Fs at ASU. So that always struck me as really weird. I never really understood that. But I don't know, maybe it's a psychological thing. Okay, so what this frame does when we send it and we'll actually get into switches in a bit. But if you think this literally gets sent out, there's some physical interface here that sends out that packet we just made. And now because of that destination address, it gets blasted to every single machine on our local network. Does it go out on the internet? Yeah, why doesn't it go out on the internet? Exactly, because everything we're talking about here is local, this is all on my local network. So this is everything in my slash 24, it never goes anywhere else. This is an important thing that the really important distinction between the internet level and the link level is that at the internet level is used to communicate between multiple hops and also a single hop like we see here, but nothing from the link level ever goes out of its local network. If that happens, that can cause a massive problem. I've actually seen networks get taken down because somebody misconfigured some VMware or virtual box setup so that it was leaking stuff out. Anyway, so we send this out to every machine on this network. So what do each of these machines? So they're listening, their operating system is listening for this. What does the Alexa do when it gets that? Yeah, nothing, it just drops it. Why does it drop it? And how does it know to drop it? Yeah, it compares the IP address. So it looks at the packet, it says, oh, they're looking for 192.168.0.20. Great. Who has 192.168.0.20? It's not me, so I'm gonna drop it, right? Exactly. So every machine on this drops it, except for hopefully one. What if that machine is not up? Yeah, we get no response. And so actually the operating system then has to tell the application, hey, that IP address, it looks like doesn't exist on this network. So that host is down. So to answer the question in the chat, no. One of the devices can't tell it who has it because there's no way to communicate that information. So ARP happens in this request response thing. We also actually missed something here that I'm, well, we'll add that in a second. Okay, cool. Okay, so P gets this message and unlike the printer gets this and unlike every other machine in this network, it says, oh, hey, that's my IP address. They're talking about me. I'm the printer. I'm 192.168.0.20. And so this is an ARP request. And so it needs to send back an ARP response. What's the source of that ARP response? Hello, at the ethernet level? Yeah, the MAC address of the printer. What's the desk? Yeah, well, how come the desk isn't everything like this one? Right, no one else cares because only my machine actually asked for it, right? So we don't wanna send this reply to everyone. We'd be flooding the network, especially if we have a ton of devices, right? So we wanna limit the number of these broadcast devices that we send. Okay, do you guys wanna say hi to the dog real quick? Take a brief break, all right. Yes, please. Here we go, here's the dog. Okay, Chad's going crazy for the dog. I'll say hi, you're famous now. Does that have a name? Hi, internet, this is Bambi. Okay. Hi, Bambi. What are you saying? Okay, okay. Hi, Bambi. All right. No, she wants to play me. She thinks we're playing now, so I need to just ignore her so I can be class. All right, cool. Okay, so the ARP response. So we know that the destination isn't gonna be anything, and we know the destination is going to be M, M, so the MAC address of my local machine. And this means that when this reply gets sent out, it's only gonna come to M, so that's great. And what is this reply going to say? Blah. Okay, so this reply is gonna say who has this? It says 192.168.0.20 is at, okay. MAC address of P. Cool. Now when the M gets that back, now what does M know? Yeah, not just MP, but it knows that this IP address is located at this physical address. So it knows that that IP address, 192.168.0.20 is at the MAC address of P. So the source is MP, destination MM, awesome. And now the question is, every time a packet gets sent out, so let's say we do this, we send one IP packet from M to P, and then M wants to send a second packet. Should it have to do this same mapping over and over again and make this request and say who has 192.168.0.20 and do this? So probably not, we wouldn't wanna flood the network every time, would we wanna store these values forever? Yeah, also no, because P could drop off in a day, another machine may get the IP address 192.168.0.20, we don't know. And so what we want is, so what happens is every machine has an ARP cache. So yeah, so you could think of inside M, inside the operating system, and actually all of these machines have a little table that they store the mapping of IP address and port that they've seen. So it says .20 is MAC address of P and so it can cache that for a little bit and it won't do that look up every single time. Okay, one little tiny improvement we're gonna be here, if M wants to talk to P, what are the odds that P is gonna wanna talk back to M? Almost 100%. Yeah, probably very, very likely. And in our current scheme right now, does P know, so look at these two packets we've sent, does the printer know my IP address? Yes. How? Because you sent it a message. I didn't send it a message over IP, so just these ARP messages. Well, yeah. Right, so just these ARP messages, I haven't sent it an IP packet, which means that if I send an IP packet, it would then get an IP packet from 192.168.0.20, the printer would try to respond and it would say, oh, I don't know who 192.168.0.10 is. I need to do an ARP request, ask everyone who that is and get the response. And so as a bit of an optimization, what we do is we actually add extra information to the ARP request that says tell 192.168.0.10, which means that we can actually update our ARP cache and we can know, okay, 192.168.0.10 is MAC address of M. And yeah, and so that's actually a nice little optimization so that both of their ARP caches, when I make a request and you reply to me, both of our ARP caches get updated to have both of our IP addresses and MAC addresses. Questions on ARP at this level? All right, so let's just, so let's walk through another example of this to drive this home that should be fairly straightforward. We have two hosts, 192.168.1 is our network, dot 100 is host A, dot 10 is host B. And this is actually a command. If you're running a Linux type machine, you can run ARP-A and this will list the current ARP cache. So if you're curious what IP addresses and MAC addresses are inside your ARP cache, you can run that command to see right now. So host A wants to ping 192.168.1.10. We didn't see what ping is, but it's a packet that gets sent at the IP level. So it actually doesn't use TCP or UDP. We'll investigate that later. So we're on host A. We wanna send it to dot 10. And this is, these lines are the TCP dump output, which we'll see in a bit. So this is parsed. So we can see that. And this actually confirms to exactly what we want. So 804874A. So this is the source of that MAC address. So this is an ethernet frame, FFFF. This is the broadcast. It is an ARP. And it's saying ARP who has 192.168.1.10 tell 192.168.1.100. I think this was exactly what we had. Goes out to the whole network. Host A, B, and C all get this. Host B is the one that responds with an ARP reply. So host B says, hey, I'm 0133198B8. I'm sending this ARP packet to, oh, I guess I missed one thing in here. Oh, that is important, okay. I'm sending it to 804674A3. And, oh, no, I did that in there. Cool. Hey, it's always good in here. Get that right. Okay. So the reply says, hey, this IP address 192.168.1.10 is at 0131D98B8. And then the next lines here are the ping traffic, the ICMP. And then we can see, after we send those, we can see that the ARP cache on both host A and host B has been updated so that they each know about each other's IP address and ethernet address. Cool. Vibed with what we just went through. Cool. Now you've actually learned how, so this is how packets make it on your local network. This is exactly what happens if you ever want to talk to machines on your local network. So if you're a machine talking to your printer, talking to your watch, talking to your fridge or whatever. And even at this level, so we haven't even looked at how packets get outside of your network yet. But even at this level, we can actually start to attack and perform network attacks on networking at this stage. So, and this is what we're gonna look at first. So we're gonna look at how to attack local area networks and then we'll shift and understand and look at wide area network attacks. And sorry, we'll first look at how wide area network works which actually it builds on what we just learned about here and is actually very, very simple from there. We'll look at that and then we'll look at wide area network attacks and then look at TCP, UDP, look at those attacks on those. And yeah, that'll be kind of our networking focus. So, okay. So some of the goals that we have in a local area network when we want to do that attack. So sometimes we want to impersonate a host. Why would we want to impersonate a host? What are some, yeah, get packets meant for that host. That's a great one. What type of hosts? Can you like give me a concrete example of when stealing connections meant for a different host would get you to get that information or get information that you wouldn't otherwise have? Yeah, so let's think of, we can actually take the printer example a little bit. Well, that's not very interesting. The thing I like to imagine is you're on a corporate network. So rather than your network here being your home network, this network is a giant corporation, a big corporation. And so what are some hosts that we may want to try to impersonate on a corporate network that gets sent sensitive information? Yeah, you guys are thinking of where that data exists, but if I impersonate, let's say the CEO's laptop, nobody's gonna actually send that machine any sensitive information. Sensitive information exists on that machine and I may want to break into that machine. Right, so let's, this is good, let's, right. So now there's a malicious me here. I've got my way onto the network. Yeah, this is actually good. So the printer, so the CEO has to print stuff, right? So if I'm able to impersonate this printer, that data rather than getting sent to the printer will actually get sent to me. Actually a fun fact about printers, I don't know if you know this, but printers A will not print currency. If you try to print currency, there's actually something in the printer that detects it and will print out a notice instead of currency. I guess US currency, I don't know about other currency. The other thing is printers actually have a memory of documents that they've printed that have like the last 500 or so documents that they've printed. So be careful of what you print. Yeah, okay, so the CEO, we've talked about how important corporate reports are, right? The CEO could be printing up some reports that they need that are sensitive. So instead of sending them to the printer, they send it to you. Anybody working corporate environments? Yeah, so what are, so maybe usually there's some sort of HR portal where people can put in their username passwords, can put in their username passwords to sign in to some. So usually there'll be some kind of system where you can put in your username password, you can update your salary information, you can change the direct deposit where money goes. So what if you're able to steal everyone in the company's username password to there and change the direct deposits to account that you control? And you did this right before payroll, right? So if instead of the CEO thinks they're going to the HR website, but actually gets sent to me, and then like somebody else said, I'm very clever. So I actually send them to the, I send this request to the HR website and send it back so they never actually know that it was me, right? So there's a lot of interesting targets in here. You could think about like some type of database system. You could think about email, right? All of these sensitive systems that we may want to target inside some network. Yeah, so this is all reasons why we'd want to impersonate a host. That was great, you guys were good. We may want to DOS a system, why would we want to DOS a system? Yeah, maybe keep them off of it or maybe it's a security appliance or security system that we want to knock offline while we take care of all of our other aspects. Yeah, that's great. We may want to try to get access to information. So if we go back here and undo a lot of this or get rid of a lot of these lines, right? So our CEO has demanded a lot of power. So most people have to use a username password, but the CEO when they access the HR system they're automatically the admin and the CEO has been complaining about having to remember so many username passwords. So they automatically come as admin if IP is equal to the CEOs. So now what would happen if I spoofed and pretended to be the CEO when logging into the HR system? Yeah, bang, I'm admin right away, right? So similar things can happen with production databases and developers. So developers often need access to production database, but the, let's say marketing or other types of people don't. And so they may use IP in order to tell if somebody's a developer or not. We missed one little thing. How do I get on this network? Yeah, I may actually just plug in a physical ethernet cord, bang, right into the network and I'm in. I may, they may have a Wi-Fi network that I broke the Wi-Fi password because it's a really crappy Wi-Fi password. So I'm able to get on that way. I may, this may actually not be my machine. I'm not trying to pick on the fine people in marketing but I may have tricked somebody in marketing to execute some piece of malware that I wrote that gives me full control of their system. So now I have a toehold on their network and I'm now part of the local network because I've taken over a machine. I may have tricked or I may have bribed somebody in marketing and given them a USB drive to plug into their machine and little do they know that it takes over their system. Yeah, these are all cool ways that we can do that. Cool. Okay, so this is how I can maybe use local area attacks to get access to information. I may want to tamper with, oh, you thought that only happened in movies? Oh, no, that's a real thing. There was a study at the University of Michigan called users really do plug in USB drives that they find where they actually did a study where they dropped USB drives all over campus and measured how many people plug the devices into their machines. And I've also heard from, and there's actually this, the story goes even, not that study but there was the US secured networking. So actually the US military has its own separate internet called MilNet, which is separate from the internet. And what happened was is apparently they had an alert because one of the bases was sending requests to Russian IP addresses and that obviously freaked them out. When they looked into this, what happened was is somebody in that base had bought a USB drive from the like Bodega or the corner store that was like across the street from the base and ended up needed to transfer drives and plugged it into a secure classified machine even though they were not supposed to. And so the story is that the Russians basically planted these USB drives in these stores around this base for years beforehand and just waited until somebody plugged them in and eventually somebody did. So no, there is no way to detect if a USB drive is compromised before you plug it in. You have to like physically disable the USB drives like with some companies put epoxy over them so it's impossible to plug them in. But yeah, it's crazy. I mean, it used to be so bad that like you could plug in a USB drive and it would just do something. Anyways, so that's a fun story. Okay, so we wanna do all these things and what we're gonna study is basically three types of attacks. So we wanna study sniffing. So this is what we're gonna look at is we want to be able to listen to traffic that is not meant for our hosts. So be able to sniff traffic, spoof traffic, meaning we want to be able to pretend to be somebody else and hijack is when we want to actually hijack some communication here. So the first thing that we actually have to go back to here is in order to, so we actually do need to study a little bit about, so we've been kind of ignoring this router here or this, sorry, router is not the right term. We should be thinking about this as a switch right now. So what we set up here is that, oh, I went too far, sorry. Yeah, what we set up here is when we send out a broadcast request, it obviously has to go to everything else, but when we send out a, but when we send out with a source Mac port, it should go to just that machine. The question is, does that actually happen? So is, oh, well, I have a switch under my desk. I was going to show it to you, but I'm slightly worried that if I do that, it'll, I don't think anything will work. So let's not do that. What we can do is, okay, oh no, I drew my switch way too big. All right, I'm going to see if I can't find you a picture of a switch. Okay, so I just want to find a picture. And of course I have to put in networking switch, otherwise Nintendo switches pop up all over the place. There we go, cool. Yeah, this is a big one. Okay, cool, I like these ones. I don't know why, but this Zoom sharing through my iPad changes the date on my iPad for some reason. It's absolutely bonkers. I got to figure out what they're doing because that's weird that it makes it Tuesday, January 9th, every time I do this. Okay, so everyone's seen a device that's like this. Some of them are very small. They have like four or five ports. Some like this one are very big. They have like 48 ports. This is a switch. Yeah, see these? Usually if you're only ever used wifi, if you go look at your wifi router, usually you'll find ports like that so you can use your wifi router as a switch as well. Okay, so we're not going to go this big. So four port switch, P1, P2. So in the beginning, now is there anything? So we talked about ARP and how things get sent from one thing to the other. When I said that the reply, the ARP reply from P back to M only went to M. Does it actually matter if it only goes to M? Does that ruin the networking process? Yeah, no, it doesn't matter if everyone gets it as long as everyone drops it. So this is actually a hub. So a hub is a device that looks just like a switch that any packet on any port gets sent out to every other port. So what are some of the problems with a hub? So you can think of, well, from the security perspective, it's sending too much information to everyone. So if somebody is just listening, right? Has changed their network card so that it can listen to every packet and not drop it. It's just, so there's obvious security problems. There's also very clear performance, right? Now, if on your network, if let's say one machine is backing up data to another machine and fully saturating that bandwidth, right? Then the entire network is basically gonna be down while that's happening, which is not great. Now, so switches basically fix that problem. And switches are very complicated. There's a lot of crazy stuff that they do. But the thing that we will focus on right now what they do is they basically make that smarter. So they say, aha, I can actually know what port to send a reply on. So let's say that my actual, so I'm redrawing my diagram here. I have M over here. I have the printer on this port. I have my Alexa here because I've hardwired it. I have, ooh, we didn't talk about this, but my TV is also hardwired, right? And so when I send in from M, my ARP request, okay. So my source is MAC address of M. My debt, what was my destination again? Yeah, F and I will do dot, dot, dot. So I don't have to write it all. So it has to go to everyone. So can the switch stop that from going to everyone? No, it can't. This destination means it's gotta go to every single device on this network. It can't possibly stop that. So that ARP request goes to every single device. It's okay, being wrong is how you learn. Okay, P gets it just like we saw. It sends back an ARP reply. And that's gonna be source of what? MP and destination of MM, thank you. Okay, cool. So it sends this packet out. And now if this was a hub, it would get sent out to every other port on the switch. It would get sent out to P1, P2, P3. Everyone get that. But we know based on the protocol that not everyone needs to get this. What MAC address needs to get this packet? I keep saying packet, frame, whatever, but I like saying packet. MM, right? Whoever has this one. How can the switch know which port has this? Yeah, by itself it can't, right? This obviously does not have enough information to be able to tell. But what did it already see? If we think about what the switch already saw, it already saw an ARP request with a source of MM on which port? On port one, exactly. So the switch actually has its own memory and it says, okay, I know MM is on port one. And so when it gets this, so it originally has nothing in here. When this ARP request is sent, it updates its internal table to say, okay, MM is at P1. And then when it gets this ARP reply on P4, what does it do? Yeah, it does two things, right? It sends that packet only on P1 because of this table and it updates the table to say the MAC address of P is at P4. Yes, exactly. Everyone on port one gets a reply this is very important. And it's actually really important because you can have setups like port two actually is actually connected to another switch. This one is connected to a TV and a, oh, what did we say? A watch and something else. I'm getting tired of coming up with names. Camera, thank you. Yeah, so this is why it actually needs to, it can store, it's not just a one-to-one mapping between ports and MAC addresses. It can have many, many ports, many MAC addresses can be associated with ports. Is this infinite? Yeah, it fundamentally can't be, right? It's a machine, it has a limited amount of memory. So it can't have an infinite size in its cache. And so anyways, cool. So this is the important thing about switches. And so if we go back to our example, if I wanted to sniff all the traffic being sent to the TV, so let's think about this. One thing, so I mentioned earlier that there's actually, we call it a NIC network interface card. So my actual hard, like my ethernet device here that I've plugged in. We said by default, so like those ARP requests go to everyone, but everyone drops it and doesn't do anything with it unless it's for their IP address. I can set my NIC in promiscuous mode, which I can't remember how to spell, so I'm not gonna try it right now. So I can set my interface on promiscuous mode and look at every single packet that comes in on my network card, even ones that aren't necessarily destined for me. But so if this is a hub, so now if I say this is a hub, how do I listen to all the traffic on TV? So I'm connected to a hub. How do I listen to all the TV traffic? Yeah, it's auto-broadcasted to me. I actually need to do nothing. I just turn on promiscuous mode on my network interface card and it gets sent to me. And so I can sniff all the traffic getting sent to the television, great. So this is one of the clear security problems with the hub. It gets sent to you literally by default. Oh no, boop, no, there we go, switch, okay. But now it's a switch. So now what happens if I just turn on promiscuous mode? Will I get all of the traffic sent to M? I definitely won't get all of the TV's data. Will I get some? What will I get, let's say? Yeah, ARP or anything where the destination is all S, right? So yeah, this would be ARP request by other devices. I can maybe see TV sending out an ARP request, excellent. So I'll need to do extra work if I wanna actually, but this doesn't mean I can't do it. It just means it's not as simple, cool. So if it's switched ethernet then we need to actually trick them into sending traffic to us on. The benefit of a hub is it's incredibly cheap to make. I'm sure you can buy them. If somebody can go look on Amazon, the price difference is probably, I don't know. They may not even sell hubs anymore. Actually the, yeah, okay. So let's go into why we wanna sniff things. So we talked about this a little bit, but one of the things that you may find shocking is that a lot of protocols like FTP, POP is a way to access email. IMAP is another way to access email. HTTP is obviously like HTTP, but without HTTPS. Transmit authentication information. So username, passwords in the clear. And so when you sniff the traffic, you can collect username, passwords, files, males. And there's tools that will help you with this. So actually one of the fun things was when I did a pen testing a long while ago when I was doing my PhD, we sniffed all the traffic that was going out of the company and we were able to see that somebody had stood up some website for the company that they were using FTP to transfer files for. And so we were able to actually get into that site and then do some other stuff from there. But there's a lot of sniffing tools. Basically the one I use almost exclusively is TCP dump. TCP dump is a command line tool to collect traffic. TCP flow is a really cool one that will reassemble TCP flows from traffic. You probably won't need it exactly until you actually need it. TCP replay is a cool tool that will replay recorded traffic. Well, I guess you should, the thing to realize is even though these all begin with TCP they actually go much farther beyond just normal TCP. They do a lot of cool stuff. The graphical tools, I highly recommend Wireshark. So this is a, I guess I don't have it on this machine right here, but it has parsers for like tons of different protocols. So it will show you from, you can look at any specific packet from the Ethernet frame to the Ethernet, the IP frame, the TCP to HTTP to whatever, you could trace different connections. It's a really fun and really cool tool to use. And this, even if you don't go into security itself if you actually understand how to use these tools along with understanding how networking works you can, it can turn you into a bit of a magician at your job when you're diagnosing networking problems. I know I've definitely had to like try to figure out what the heck is going on when encountering some networking issue. And I do that by like being on a bunch of machines that are along the route that I know the traffic is taking and running TCP dump on all of them to understand exactly what's going on. And so once you're able to see that and know exactly what traffic is being sent and why that it's working or not working that helps a lot in debugging and understanding network issues. Oh, so one of the fun things of why I talked about hubs and switches is we talked about that a switch has a limited, a limited amount of memory here. And so what happens when you hit that limit? Should the switch die? Yeah, you maybe dump old stuff but what actually can happen some switches will turn there's a lot of different ways you can handle this failure mode but some switches will essentially turn into hub mode where they go, okay, I have way too many entries in my cache I have absolutely no idea what's on what port. So I'm just gonna send the traffic to every single port. So you can actually trigger that by making it think that there's a ton of entries on port one and hit that limit and make the switch fail over and turn into a hub. So that can be one way to do that. The other way to get traffic in a switched environment is what's called ARP spoofing. So to set that up, we've looked at ARP from the perspective of trying to accomplish some piece of information, right? We want to try and understand, we're trying to map and remember our goal here is to map this IP address 192.168.0.20 to some MAC address, right? Well, we didn't look at this from the perspective of security and how secure is this? So let's think about this from the perspective of the printer right now, okay? Headspace, you're a printer, you print things, you don't print currency, you know your IP address is 192.168.0.20, you know your MAC address is the MAC address of the printer, you have your ARP cache, you get a request, you get this ARP request. It says, who has 192.168.0.20 tell 192.168.0.10. You know this source MAC address and you know this destination, you know this destination got sent to everyone. But do you know that this source address is actually this? Why or why not? It's great when I ask a question and it says, I get a yes and then a no. Let's look at the switch, what we just talked about with switches. Does the switch, when M sends a packet, this ARP request out, the source of MM, it gets sent out to P4. Does the switch care who, what the MAC address is of somebody who sent that? No, can I just change my MAC address to the MAC address of anyone else? Yeah, can I change this destination of the ARP request? Ah, you can't talk about what should or shouldn't be able to do. You can only talk about what the protocols allow you to do, right? I can't really change that destination because it needs to go to everyone in the network. And if we think about it just from the printer's perspective, right, the printer doesn't know any of this and I'm zooming in so we can look at it just there, right? So we fundamentally, so we can trust the destination because that packet got to us, we can't trust that that's exactly that MAC address. And it's asking who has 192.168.0.20, that's me, tell 192.168.0.10, okay? Great, so I can do that. So I send an ARP response back that says, hey, I'm from MAC address of printer, send it to MAC address of M, 192.168.0.20 is the MAC address of printer, okay. What linked to these two requests? So if we think about it from the perspective of M, I sent this request and I got this response. How do I know this is a response in relation to my request? Fundamentally, and if you actually look at like, so what we're looking at in these packets here is exactly what's actually sent. So there's nothing that links these two requests together, right? There's nothing linking that says, hey, I made this request and I got this response, right? I know I made this request and I know I got this response. So let's say, does somebody wanna be a bad person? Can I use your name that doesn't start with one of these letters we already have here? All right, Christian, it's gonna be you, I think you were first. So Christian's goal is what we talked about earlier. They're trying to impersonate the printer, right? By me. So they're in my network. I send an ARP request to everyone, right? So my ARP request goes out to everyone, says who has 192.168.0.20, tell 192.168.0.10. Christian gets it and what does Christian do with it? Do they drop it? No, he sends a fake ARP reply, right? So Christian will send, sorry. Let's see if I can do this. Okay, there we go, perfect. All right, so what's Christian's ARP reply gonna be? Or I guess I called their response, whatever. So what's the source gonna be? The MAC address of Christian and the desk, MAC address of M and the body is gonna say 192.168.0.20 is at MAC address of Christian, cool. So that packet goes out, Christian sends his ARP reply, the printer sends its ARP reply. Now, what is M to do? How does it know which one's the real reply? Yeah, fundamentally it doesn't, right? It has no absolutely no way of knowing because when it gets it, all it knows. So the all it knows is it sends its ARP reply, so that all it can trust in these ethernet frames is that is essentially the source, or sorry, not the source, the destination MM, right? It knows because that's coming to us, it's meant for it, but it has actually no way of authenticating or verifying that this IP address is actually associated with this MAC address, right? That's fundamentally what the ARP protocol is supposed to do. But of course ARP was not created in the era of thinking about untrusted local networks, right? They were trying to get stuff to actually work, not to think about what happens if somebody untrustworthy is on your local network like Christian. So there's a couple of tricks we can do. Keep missing that, I'll go back up. So there's a couple of tricks we could do. One, if Christian wants to impersonate the printer to prevent this printer's message from coming back, Christian could DOS the printer, right? So if Christian is sending a bunch of traffic to basically take out the printer, the printer never gets the ARP request and so doesn't send an ARP response, so only Christian sends it back. And then when M gets it, what does it update its cache with? 2.20 is at what? Yeah, Christian's MAC address, thank you, right? And now when that M is talking to 192.168.0.20, it thinks it's Christian and so it'll send Christian documents to print and Christian will sit there and try to draw those documents correctly to send it back so that they know. Okay, DOSing machine may or may not work. It's kind of can be difficult to actually do in practice. So what we talked about is both replies may get there and it really does depend on the actual implementation of the operating system on what happens. So M's operating system may say, okay, I'll take the first response and I will update the first response whoever gets there first gets in the cache. Another option, and this is actually, I think much more common. The second option is the second person there gets the ARP cache. So actually, if you think about it, what's simpler? So a really simple way of implementing it is whatever I just get, I update the cache. And actually, because I know there's no link between, there's no way to link an ARP request to an ARP response, the simplest possible way of doing this is saying whenever I get an ARP response, I just update my cache. I see this ARP response. And so Christian knows this and so what he'll do is spam every second. Oops, hello. He'll spam that fake ARP reply every second. Bang, bang, bang, bang, bang. Updating that cache every single time. And then when M, when it finally drops out of the cache and M says, okay, I need to re-update my cache of who that is, it sends an ARP request and bang, Christian response goes in and updates it to his IP address. And that is the essence of ARP spoofing. So this fundamentally relies on the fact that now, okay, cool. So Christian's been able to impersonate the printer and this is great because this means that all packets that get sent to Christian or that gets meant for M to the printer gets sent to Christian. So Christian is now impersonating the printer. But of course, M actually wants the printer to print the document, right? They want their corporate earnings reports to be printed. And like we talked about Christian is, it's very difficult for Christian to just keep writing and pretending to be a printer, right? Christian is actually not a printer. At least I don't think so. I think Christian, say something in chat to prove that you're not a printer. All right, that's fair, I approve. Okay, so Christian wants the actual printer. And if the printer ever talks to M, Christian wants to steal that traffic. So what Christian will do is do ARP spoofing to both parties so that each of them thinks that Christian's Mac is the other's IP address. So that Christian sends out these fake ARP responses so that M thinks.20 is Christian's Mac address. The printer thinks.10 is Christian's Mac address. And so any communication between these will go to Christian. And then Christian can actually forward that and we'll look at how that'll work later of, they can actually forward that traffic to the correct person. Yeah, so the goal, and this is what it's called the ARP spoofing or ARP poisoning because you're poisoning their ARP cache. Cool, so we can actually see this in action here. I'll go through this example real quick and then I'll let you go. So here we have each of the ARP caches of each of the machines, host C, which is our, I guess, hey, Christian, you actually showed up in the slides. Like apparently host C is our bad person here. So host C, the Christian has to know which IP address and Mac addresses are the real ones. So they always have that mapping and Christian will send ARP replies to each of them saying, hey, 1.10 is at my Mac address and that will update host A's cache table. It will also send that to host B saying, hey, .100 is at my Mac address. And that way, whenever an IP packet is sent from 1.100 to 1.10 containing secret data, it'll come to me on the switch. Christian will get that and he'll actually send that out on the network again, 2.10, but replacing the destination Ethernet address because he knows where that goes and host B's response will go back through Christian. So Christian in this case is acting as a router and routing traffic between the two hosts. Okay. So there's actually a tool to do this if you want to play around with this, of course, ethical concerns here. Make sure you have the permission of your housemates or yourself, of course, if you're doing this. But yeah, you can play with this tool, Ettercap to do this on your local network. It's really fun. It's always fun to get your laptop and your other machine and see if you can man in the middle of their connections. It's pretty cool there. All right, so we're done there and then we'll move on to IP spoofing. Thanks everyone. And thanks Christian for being a good support.