 Okay. All right. Well, thank the, you know, few of you that are here for being here. Appreciate it. I just told everyone the answers to the midterm before we started recording so that's really good but you know, I'm sure you'll be fine, even if you didn't do that. Let's see the assignments going well. You know, I think you're all learning a lot about how difficult it is to establish trust, especially on an environment like an online forum or a messaging service where you have no way of verifying people's identities or who they are and those kinds of things and people can easily create new things and so yeah, you know, be vigilant, be nice, use physical reality is also a good, you know, thing like actually seeing someone and it can be a good thing so anyways, you'll figure it out. It's, and it'll all be over at the end of spring break so that should be good. Cool. Alright, so now we're going to jump back into networking. So we have been talking about the address resolution protocol and the address resolution protocol let's go back to our nice kind of split diagram here. So our kind of technically sits at the link layer. But it actually has to deal with the IP layer and the link layer. So remember so in the situation that we're talking about here, we want to send some IP packet from one machine to machine where on to another machine. What do we need to know about that machine. What address IP address yeah we need to be very specific right so many types of addresses as we'll see so we need to know it's IP address. And for those on the chat the midterm thing was a joke. I'm sorry for doing that to you. It was a joke. I didn't mention anything. So we need so we have our IP address we want to send a message to another IP address, and that's all we have. So we talked about we can use cider and we saw that notation for determining what's part of the network what's part of the host of an IP address, and that's used to determine whether a host is on your local network or remote network. And where this comes into play and is important is when we want to do direct delivery so this is when we get a packet or when we want to send a packet, and we have the target IP address, and we say is it in our local network. Now to answer that question do we just need to know their IP address and our IP address. What else do we need butter. We need no not quite not yet we're get we'll get there we do need a MAC address to send it over the link layer but how do we determine whether something is in our local network and we can use direct delivery versus remote network. Yes, so the subnet mask the cider, the net host split all those are same ways of determining, we need a way of determining is this IP address on our local network. So let's look at some examples on Tuesday. So once we've determined that and we've said yes, it is on the local network. We now want to send some IP, some internet frames we want to use the link layer to send that packet on our local network. The problem is, we don't know the MAC address so MAC addresses are six bytes, which are different than how big how many bytes are IP addresses. So that was a trick question I phrased it slightly differently but you know so it's helpful to think about these things in different ways and how they're represented so. Okay cool so we got that and then. So now that's where our comes in so our comes in when I want to make, I want to send an IP packet to somebody on my local network. I need to know their MAC address in order to send a ethernet packet but I don't know their MAC address. Do we know our MAC address. Yeah we should wear that system if we don't have a MAC address it's like not having an IP address we can't talk to anybody. So we need to know our MAC address, we know our IP address we know our net mask and then we also know the targets, the destinations IP address. Cool. So this is a protocol that will see allows you to ask basically all hosts on your local network. Hey, who has this IP address, and then they'll respond back with oh this IP address is at this MAC address as we'll see. So that we can then use it in direct delivery. So it's actually kind of crazy to even send out a packet. Before we need to do that we have to figure out that MAC address so we need to send other data at the link layer in order to figure that out. So our request is fairly simple we'll look at it here and then I'll show some examples so essentially. So we can use on the so we have to host here like in our example we have host a 192 168 100 host be 192 168 1.10. And they have two different MAC addresses I'm not going to read them out loud. A good check what would be like a cider notation, like a slash something that would say that Jose and host be on the same local network. Last 24 what else is that the only one slash 16 in the chat right anything from 24 to 16, all the way up to I think the most you can do is slash seven I think or slash eight or slash seven but yeah all of those right and probably down even further than 24 I don't know exactly 100 impacts and binary I'm sorry for that but if you did that then you could figure out exactly how far you could go. This is another way to check. Oh if I have these two IP addresses how do I make sure they're in the same local network so you can think about that in that in that way. I guess another check. The same net mask. I'm seeing some nodding on in person and then I'm seeing a blank stairs, and I'm getting crickets in the chat. So why yes, somebody argue to me why it's yes, they should have the same that they don't have the same stuff that fast, when we compare them to each other, we're comparing capital markets, we'll be saying this one has this many bits of its network address, and this one has X number more or less. Yeah I think that's very good I'd say you're comparing capital oranges is good what I'd say is flip around the situation right because we want to know if we send a packet from a to B, and then B responds back. If I could do the same calculation and say is 192 1681.100 within my net mask. If it says no it's going to send a packet somewhere else and chaos one suit so this is why you need all hosts on your local network to have the same net mask. So it's about the having to communicate back and forth right that's kind of the key principle here. And if they're not set up the same, you could have some IP addresses on your local network that you can't actually talk to because they don't know how to respond back to you. It may actually work it just kind of all depends but it would be bad and not fun. Okay, so with an ARP request. So what we're going to do is, we can use a John Linux you can use the ARP dash a command to show you the operating systems cash of what IP addresses map to what MAC addresses why does your operating system want to cash that. You don't have to ask every time right it would be insane if every packet you want to send a message you're starting along communication between a and B. Right you're sending packets back and forth we know what was the minimum size of an ethernet frame is a big or small, smallish right. It was 1500 bites, how does that compare to the size of like an IP packet IP packet had two bites. So 16 bits for the size. How many bites is that IP packet. 16 bit size, what's the maximum value can happen 16 bits, you have to calculate it out. Yeah, 65,000, whatever whatever whatever three, five, five, there's threes and fives and the rest I don't remember two to the 16 right or to the 15 minus one. So that's kind of helps you kind of conceptualize so if there's a huge file being sent back and forth between host A and host B let's say a gigabyte file. By using ethernet I could split up that data into chunks of size 1500 and to send those across. And if I had to do this ARP request to say hey who has this MAC address every single time that would greatly reduce performance. So this is why your operating system will say hey, oh, it'll check its cash and say oh I don't know who has what MAC address maps that IP address, let me ask the network, which we'll see in a second. It asked everyone and then once it gets a response it updates its cash and it uses that for a quick set of time I think it varies depending on the operating system of how long it keeps it around. It's something on the order of the day. So cool. Okay, so we're gonna look we're on host a we're looking at the ARP cash we get nothing out that command shows us nothing it means that there's a fresh ARP cash you can actually use this command. Also you read the man page you can clear your ARP cash. You can ping 192 1681.10. So this is we're going to try to send an IP packet to 192 1681 10. We saw IP is a special case of an ICMP packet, but that detail doesn't matter. But before we can actually do that so what this output is. This is something you're going to get more familiar with is that this is just the the TCP dump is an application that looks at a network, and you can configure it to show you what's going on. So what's going on here is we are. So the way our ports we first have to ask because we don't know. It's kind of an interesting conceptual problem you're at the link layer, right. You're trying to ask, who has this IP address at the link layer. So you need that message to go to everyone because if you knew where that message was supposed to go, you wouldn't have to ask. So that's the special address. So on the far left is our host AS MAC address 80467 for a three. The next is all one so ff ff ff ff ff this is a special notation in in at the link layer. The special situation at the link layer which is the broadcast address. So no physical map address can have all ones as its MAC address. And what this means is it tells them the network or the switch hey, this message is meant for everyone on the network. So when you send this message out it gets blasted to every machine on your local network. So they're going to be listening for it so it's an ARP request, and then the middle part is basically what TCP dump parsing the ARP request, which you can look at the docs if you're really interested about exactly how that happens. And that it corresponds to ARP, who has one nine two one six eight one dot 10 tell one nine two one six eight one dot 100. So when you send this out, it goes every single machine on this network, including host seed gets that message. So what does host seed do when it gets that message throws it away why they look at the packet, they say, Oh, this is for one and two one six eight one dot 10 that's not me dropping. Well, I'm not going to reply. Right every machine gets that every machine has to decide what to do. Every machine gets it and what does host be do it looks, it says, Oh, that is my IP address. Great somebody wants to talk to me I'm so happy. Do they send a broadcast message back. Why say it again. Yes, so this is one of the key things when you're thinking through these communication protocols what information does what side have during the process. So host a, at the start of this process does not only knows the IP address doesn't know the MAC address of host B. And so it broadcasts out widely to everyone on the network, hey, who has this, I what MAC address corresponds to this IP address. Now when host be gets that it gets all the information in this message, right. It has the IP address it's supposed to respond to right it says tell one nine two one six eight one dot 100. It has the, the MAC address of that host. So it has the host MAC address the source MAC address has that. And so it has all the information to respond, just targeted back to host a so that host C never has to see it. Yep. So that again, once it gets a reply, and that's how when once we've done ARP, it gets the reply back it updates its ARP cache and now it can start a communication directly to host B. So the ARP request that goes out so the ARP request goes out and this is where this really important this middle line here because I'll see we'll also get this ARP request. And then host B will send an ARP reply back. Which says, hey, from 0131D 98 be a host bees MAC address to MAC address 80467 for a three ARP reply one nine two one six eight dot one dot 10 is at 0131D 98 be eight. So it's able to reply back. And then as soon as host A gets that now it says, aha, now that I know this mapping. And I know that the IP address I'm trying to talk to instead of IP packet to is on my local network, I know how to send that data. So it then goes forward and we sent we can see IP packet so we have a packet. So the Ethernet header so we have a host A's Ethernet host bees Ethernet and IP packet from one nine two one six eight one at 100 to one nine two one six eight one dot 10 and I seem to echo request. And then that gets to host B assuming it's still up and it's configured to reply to us it'll reply. And so it says hey from host bees MAC to host A's MAC IP address one nine two one six eight one dot 10 is the source IP address and the destination is one nine two one six eight one one nine two one six eight one nine two one six eight one dot 10 is at this MAC address and host B will say host A's IP address is at host A's questions on this. Let's see how we kind of get this. So that all the packets are the yellow thing larger square is the Ethernet headers, the Ethernet frame, any second call the frame but whatever, which encapsulates inside of it the IP packet. So that's kind of exactly how this this data goes between there. What's the 16 the 80 on your talking about on this slide. Oh, next to the ARP and the IP. I don't know I think it's some. It's one of the flags. So the other. When you get into this you'll use tools like. So we'll show you this how to capture the traffic how to analyze it there's graphical tools that will parse it into all its constituents parts. This is just kind of showing a high level of what you might be interested in from this packet. And then the STCP dump for more information you can say show me the exact like raw bites of that packet and then you can decode it manually or something if you want to. Cool. So, you now know how data moves in a local network from one system to another is exactly what's happening right now with my machine to that to the wireless router that somewhere. The IP packet is currently flowing packets are flowing from me to the router so as we'll see multi when you want to do non so when you need to send an IP packet to somebody not in your local network. You first send it to essentially a router or a gateway that knows how to get it out of there, but that step is exactly what we just talked about. So you have to do art to figure out the MAC address and then you send it not to the destination because it's not to the destination but you send it to the next hop and their job is to get it somewhere else and their job is to get it somewhere else. And it goes all the way. And believe it or not, hopefully believe it. You actually know enough to conduct some local area network attacks. And why is that so what made we want to do. So pretend now you're in some network somewhere. You're not compromised so see, or you just maliciously you broke work, you broke their Wi-Fi password so now you're onto their network, or you've plugged into an ethernet port in a company. You're now on the local network what what might you want to do what would your goals be as an attacker at higher level what would I what would I want to accomplish as an attacker. I may want to talk to people on the network right see what's on there. Maybe there's an unencrypted file share or something or something that doesn't require authentication. What else. I may want to personally being another user or another machine. Maybe there's a trust relationship established between host A and host B, where host A is the. The source code repository and host B is some developer machine and the developers machine can just access it without authentication but anyone else for marketing or whatever would have to authenticate. Yeah, somebody mentioned in the chat snipping conversations I may want to ease drop on the communication between host A and host B. Why might that be useful. There's a lot of information, maybe there may surprise you but there are many protocols still in use today that transmit passwords over the network in the clear without encryption. And if you get a hold of that communication you can just get those passwords. This actually happened when we were doing a pen test of a company. We got a tap of their network communications and we just kind of listened to it and later analyzed it and we found out like oh there's this ftp site that they're using to upload content and it has a. They're using the ftp that they're using they didn't use the secure like SFTP or anything so the password just right there and so we were able to log on and like use that to do stuff. There's this is, well, anyways, so we'll get into all the nasty stuff but yeah so I think. Our goals we may want to impersonate a host on the network right we want to pretend to be somebody else, you're getting a good lesson and you know, trying to pretend to be somebody else or another identity. Denial of service, we may want it so that host A is just off the network and can't talk to anybody. We may want access to information like you talked about this could be through snooping or other types of means, and we may want to tamper with some of the delivery mechanisms. And so kind of what it kind of comes down to three basic attacks so this is whenever you're thinking about networks or other types of communication mechanisms. I'm thinking of these three main avenues of attack. How do I so sniffing here is the same as kind of wire tapping or listening. How do I, how do I see what's going on on this network spoofing is pretending to be a different host. So how do I pretend to be a different host on this network as host C can I pretend to be host a. And finally hijack. So how can I if host A and host B are having a communication. How can I hijack their communication and either pretend like one of them said something that they didn't or maybe delete messages or something like that. So these are kind of the three main attacks that we want to be thinking about. So, one of the main things thinking about what we're talking about here. If I'm hosting and I'm malicious, and I want to sniff all traffic on the network. So in this diagram I just have like a wire black line right connected to other black lines. So if I just listen and all will show you how to do this. Hey, give me everything you get. Don't just drop because by default the network card won't even bother your OS and CPU. If it gets a. If you get an Ethernet message that's not meant for you it just drops it. It's smart enough to do that. But you can tell me everything. I want to see it. And so if you do that, can host C, like if host A and host B are having a conversation, could you listen in on what they're talking about? It depends a lot. It all depends on the network architecture. This is where the details of what's going on actually are really important because they're important to you as an attacker of what you can do. And it actually comes down to the difference between hubs and switches. So, I'm trying to wonder if there's any here because a big one back there. Everybody know what I'm talking about when I'm talking about like a switch, like a thing that you plug Ethernet, a bunch of Ethernet cords into right the back of your Wi-Fi router will probably have it's at least got one port to connect the cable box or whatever to it for the cable modem. So I'm going to show the networking box, but anyways, so early network switches were simple hubs. So they were device that looks exactly like a normal switch that you plug Ethernet cords into. What they would do is basically they were not very smart. They just worked on a principle of whenever any data came in on one of the ports, it went out on the other ports. So will that get the data to where it needs to go in this diagram? It's great. Packet comes from host A, boom, send it out everywhere. Packet comes in from host B, boom, send it out everywhere. Sounds pretty easy. I think you could do that, right? What's some of the downsides of that approach? Yeah, it's very easy to listen to traffic. All you have to do is host C is just start listening and you'll get every packet that's on the network. What about non security things? Yeah, it's a lot of overhead. You're getting every, if there's a large conversation between A and B, you're getting every single packet, which may or may, which may or may not be efficient. And if you as host C wanted to talk to another host D who wasn't involved in that communication, host A and host B are using all that bandwidth. So your communication between C and D is severely limited and there may be like problems there. So it's a bad, it's not a very good way of using resources. And so modern switches are much more, and there's, you'll find marketing terms of like L2, L3, whatever, blah, blah, blah switches. That stuff's not really important. What's important is understanding what they do and how it relates to what you're doing. So in this simple example, does host C need to know about this IP echo reply packet? Why not? To understand that you have to, well, I don't know how to say this, but kind of yes, but what about this specific packet? Like if you just looked at this packet and you were omnipotent, would you know exactly where it went? This one right here, the last one. You definitely know, when you say everyone, what specifically do you mean? Yeah, but what machine, right? There's only, there's very few things we have to actually tie identity. We actually don't know there's a technical machine there. Like host C actually could be connected to another hub, which is connected to other hubs, right? We don't actually know that there's a machine on the other end. But what can we tie things to? So I have three ports on this switch, so we'll go each line, right? So host A is connected to port one, host C is connected to port two, host B is connected to port three. So let's walk through it step by step. So this, you are the switch. You're my, my switch is now. So you get a packet on port one that says the source port is eight, I'm sorry, the source MAC is 804674A3 and the destination MAC is all ones, the broadcast MAC. So as the switch, where do you have to send this packet out? Everywhere, why everywhere? It's the broadcast. Do you need any other information besides what's contained in that packet to make that decision? No, because the person, whatever that machine on the other end, somebody's asking you send this to everyone. So you just send it to everyone. Boom. It goes out to everyone. All right, that one's easy. So the reply, so the reply from host B. So host B says, okay, I am 0131B98B8, send it to MAC address, I'm trying to send an ethernet message to MAC address 804674A3. Now you're the switch. What port does that, should that go out on? So that's how we can do it. The why is because host A on port one, there's some posts that have the MAC address 8046704A3. And if we're smart about what we're tracking in those two packets, as soon as we see this packet want this very first ARP request, like let's assume we know nothing right all those systems are off. We send them all on. There's no network communication. The very first packet is a packet on port one of this of this ARP request. Now, we just said we know where to send that that our request we send it everywhere. But this also tells us something about the things that are connected to our ports. It tells us, oh, on port one, there's something with the MAC address 8046704A3, which means that if I remember that, and I get something that's destined for that, I can just send it right out to that port. So that's what the switch does is it keeps track for each port. What are the source MAC addresses I've seen there. And that way when it gets something it just sends it out just to that port. Make sense. Is that more complicated than just sending everything out everywhere. Yeah, it gets way more complicated right so the hardware has to handle that the software that runs on the switch has to handle that all these things have to deal with this. You get a lot of nice performance benefits now a connection between just two things will only use the bandwidth of those two ports and not everyone's bandwidth. So that's way better. Can you just keep track of one MAC address to one port. And multiple MAC addresses that are on one port. Yeah so there may be we could have a, like we said we could have a switch plug into port three, and that switch has four ports itself, and one of those is host B but then there's also those D and E and F. Right, so there may be four source MAC addresses that come out of this port which we'd want to keep track of. Yeah we have. We need to be able to keep track of it, but there's physical limits. So this is actually one thing that will come up there actually are physical limits on how well. I actually don't know what modern limits are but you could imagine if you were writing the software, you have some limit of how many MAC addresses you could see on a certain port before at one point you just have to be like okay I'm not keeping track. What does this mean for us? What does this mean for us listening? So we'll go back here, we'll say we are host C. We want to listen, we want to sniff her traffic in the network. If we're on a hub, what does that mean? Yeah, so there's after the list set the network card to listen to everything. And then we're going to get every single reply, but every single packet on this network. If we're a switch, if we're connected to a switch, what will we get? Yeah, we'll get the broadcast traffic. It's not that we won't get anything about the network, right? We'll get every ARP request because that goes inherently to everyone. We'll get any other broadcast traffic that will go to everyone in the network. And so, you know, this could tell us about IP addresses on the network, just sniffing that will tell us, oh, there's this IP address, there's this IP address, we can actually see a little bit of who's talking to who in the network because we can see from the ARP request. Will we see any of the ARP replies? No, why not? Yeah, they're directed and not broadcast. So we'll be able to see all that, we'll be able to see any, there's some things that are like IP broadcast and stuff. We may see some of that, but we're not going to see the data communication between host A and host B. And that's why this stuff is important. So the name for this mode that I talked about is promiscuous mode. That's the, you as an attacker don't usually need to do this. The tools that you're using will do it, but it's just a way to tell the sick Ethernet card or whatever it is. But tricks do come in, whether your network card actually allows this or not. So some network cards with, sorry, I say network card, I mean, I think most if not all Ethernet ports and adapters will do this. I don't know of one that doesn't, I'm sure something will, but Wi-Fi is one like wireless networking is one of the areas where not all of them will allow you to do this. So people who do this will get like an external Wi-Fi adapter that they know is able to do this and then they'll plug that into their machine. Also, you're way better if, especially we're doing wireless stuff if you have an external antenna that can be large it doesn't have to fit into like the contours of a laptop. So it should be much better. So we have this problem, right? If we're on Ethernet, if we're on like physical Ethernet, then we need to kind of convince the switch like how do we get all that data? We want all of that data. And so we'll look at that first we'll go into tools. So this is actually really important and fun to use. I will tell you, even if you're sitting there or thinking about this on Zoom or watching the recording and thinking, well, I'm never going to attack a network so I'm just not going to pay attention or learning of this stuff. I will tell you, being able to understand what's going on in a network and how networking works will help you at whatever job that you have. I had this insane, well, I've had a couple of insane issues. One time I set up a web security project for one of my classes a while back, and it was running off of our servers in our lab at ASU. And I was doing this thing where I was trying to test some things, and my connection was getting dropped, and I had no idea why or where it was happening. All I had to do is I got on as many machines as I could that were close to those hops. I ran these tools to look at the network traffic of what exactly was happening. And I was able to determine like, Oh, there's some firewall somewhere that's blocking my traffic because it looks like a, it's looking for like web application, exploitation techniques. Another useful another thing where this came up is when we had this crazy, like networking outage in our lab where the networking would go like down for 30 seconds and then up for 30 seconds and like down for 30 seconds. And the way I proved that that was happening was I had one script running that was doing like a ping every second and logging to a file whether it got it or not. I set up TCP dump on all of the things outside of our network to show like, look, the packets are going and leaving our network, but sometimes they're never returning. And so I was able to show this to networking people and they're like, Oh, yes, this is bad, we will fix this. And so they I don't know what the eventual problem was, but it's incredibly frustrating experience when like things kind of when things only go down for limited amounts of time. It's crazy. So these types of essentially can think of these as like network debugging tools can help you in your career in crazy cases where you're maybe debugging something in production. It doesn't quite make sense of what's going on being able to look at the raw network and understand it is a very valuable tool. So there are command line tools that you can use for this, like I mentioned TCP dump. This is kind of the brand and butter collects the traffic. You can have TCP dump just output like we saw those little like summaries of the packets. You can also have TCP dump dump to a file which is very useful so that's what I typically do is like dump the traffic to a file, and then copy it down to my local machines like an analyze it with like a graphical UI. So TCP flow is really cool we'll get in we'll see TCP but and TCP dump don't be. I just realized I use it so much I don't even think about it but it collects everything so it's not just TCP UDP literally almost everything so for anything on a network it will collect TCP flow can break apart a packet into different flows which we'll see TCP later TCP replays pretty cool it allows you to replay recorded traffic so you can record traffic and be like oh replay this at this other host, which can help you with debugging some issues. Well, yeah wire shark is the most well known one it works really well it's open source, and it's available on all platforms. This is what I use for network analysis. It's, it has a number of parsers so it will try to figure out what kind of packet it is and show you graphically which we'll look at a second here. One of the things that's great funny is that I don't have been heard of this happening recently but when I was doing my PhD and we were playing the DEF CON CTF finals. So, because you can see all the traffic on your network one of the good strategies is to record the traffic, analyze it trying to look for vulnerabilities that are exploits that people are sending you and then ricochet them back to the other teams you would recognize them. So we had automated systems for this but one of the cool things that people did is they, and also you will open it up in wire chart to look at it and try to understand the exploit. And so people would find a previously unknown vulnerability and wire shark. They wouldn't weaponize it to the point where it would take over your machine but it would crash wire shark, and they would just include that in their attacks so if you ever tried to like, look at that packet in wire shark you would just crash immediately so there's a lot of interesting things of how people weaponize these things so let's take a look where we have in time. Oh we're doing great. I don't even know if I have a fire shark installed here. Cool. So I can use. If config there's a lot of different commands, every operating system is different. This is part of which you can't see anything of what I'm doing. I'm going to download wire shark in the background while I talk. Hopefully. But yes, every operating system is different in terms of how you look at what network interfaces are on your system. It will also be very complicated because many things will add. So if you're running things like Docker or virtual machines they'll add network like virtual devices that are not actually part of the machine, but allow really cool things to happen so. There we go. It's my wire shark. All right, almost up. There we go look at that, boom software. Okay, and then let me change my displays so you can actually see what I see. Option drag boom. Cool. So if config is there's also IP adder I think is the latest like Linux way to figure out all this information but I'm not running that right now. So the way to kind of read this is you'll have the device name so this is like a name specific to your thing will be I don't know some flags. MTU is that maximum transmission unit that we talked about so that's the physical device with the max size of data it can transmit. So let's see, like in this example there's the ether, but the IP address so one nine two zero zero one. This is the local LO zero or is your local network. And yeah net mask. That's what I mentioned previously. So we can see I think we already looked at this but we can see that in zero is my wireless because I'm only connected to wireless. So this network. So the way to use TC man TCP dump. Yeah, cool. So obviously, like I always say, read the man page so you can understand what these tools are what they do. There's a lot of crazy options in things like TCP dump. You can do things like capture capture traffic to a file and then once that file reaches 10 megabytes create a new file. So you, you have your data into certain size chunks. You could even do when we were doing def con CTF, because we wanted to get all the traffic but we also need to do some analysis. You can also do things like after you're going to rotate a file. You can rotate it based on time or size and then you can tell it Oh when you rotate call this script, the shell script and then that shell strip can do something with that new file which we did was process it. Yeah, all kinds of cool stuff in here. Some important important things. And slash and so one of the things that that will do is try to make the output nicer to you and it will try to do things like, Oh, if I see this IP address and I know it maps to this specific host, I'll tell you the host name and not the IP address. Usually you want to not look at any of that. So, anyways, we need to be done slash and so and for not showing me all that stuff. I for what the interfaces. So where do you want me to find these packets that we're going to be looking at. And bigger. And then. Yeah, and then you can put filters. So that's the other thing that's really cool is, you can do this expression. So with this expression you can say, give me all packets that arrive to or departing from this host sundown. I can ask for IP packets specifically, there's a whole language in here and you can combine Boolean operations and you can either parts to get the data that you want. This helps one of the key things if you're. If you're staging into a remote system, and you just run TCP dump. Without specifying anything, it will also show you all the packets that are coming from you and your remote machine, which causes more things to do which causes more packets to do and it just like goes forever and you will get lost there. But we can just do where we. Yeah, TCP done. You can run it and at first it'll say hey, because getting raw access to the device is not something that is normal so you need to be root to be able to do this and just set promiscuous mode and all this stuff. So I can do that. And I'll see a bunch of packets right, what are these packets that are getting sent a zoom, it's definitely zoom, right. So one of the things that comes up is this UDP packets remember we talked about a little bit UDP doesn't have any guarantees so a lot of audio and visual streaming will will be in there. No I do not think your IP is in here I think where I'm connected to zoom and you're connected to zoom but that would be funny. I would do things like say, just give me the TCP packets. So now I don't have any of those IP packets. I bet there's still some zoom stuff in here as well with the chats you would want over TCP. There's probably also Dropbox I'm running Dropbox so it's connected to its thing like there's a lot of stuff going on. I could also ask for our packets. We're getting a ton of art packets here. And so we can see that this nice view gives us a summary of what's going on but if I really wanted to dig into these packets because I thought something was going on. I guess that's w temp. Okay, so it's listening now instead of printing us that output it's printing to this file so it's writing out to temp output. I control C to kill it, and it says great I captured this. It says package drop why might packets be dropped. Not quite a firewall because these are coming to me right if they were dropped I would never know about that in the first place. Yeah, not quite transmission issues. It's basically like if you're. Remember what you're trying to do is something not normal. You're trying to like listen to all packets so that your operating system will do its best job. But it's not going to compromise the system just to get you every single packet on the thing right there could be like 10s of gigabits per second like numbers of packets so sometimes the colonel is like whoops I had to drop something because I don't have enough. Like memory is not free I just don't have enough memory for all this stuff. Okay so we have this file this temp output, and I should be able to open up my handy dandy wire shark. A very good rule of thumb is to never run wire shark as pseudo as root. So with wire shark you can listen directly on network interfaces and it uses TCP dump under the hood. The problem of course is if somebody is running stuff to pop your thing it's not very good so it's always better to record to a file with TCP dump and then. Because even though well, even though you're using pseudo with TCP dump it drops permission so it's fairly well tested I guess I'll open gratuitous art it's a little. Be a technical thing. But now I can dig in so the way to read this is so I'm seeing all of the art. So we asked for our packets right. Right here so I can see okay and then below it parses it into the different formats so the frame here. So this is an ethernet frame. There's all kinds of additional information here, then the actual packet so this is the source is from 1880 90 F8 to a 11 to this broadcast address. And then we can actually see so the other really cool thing is on the bottom is the raw bytes that are captured up this packet and then as I'm going through the structure, it's highlighting which parts of the raw packet correspond to this structure. And oh which part in here specifies that it's IPV for like moments this and hardware size and protocol size and the opcode for ARP, and the target MAC address the sender IP address like, so we can see these are all encoded. What we can present right and we talked about it. Let's look at something more interesting. Okay, so now I have TCP packets, and you can search for them, I should never hopefully can't see what why should I not be able to search for this hello message in here and find it. Yeah, hopefully it's encrypted right otherwise zoom is doing something really really bad. I can do things like this. Yes. So here I'm just using curl to access some IP some websites. Open. So I can. So this is the other cool thing that wire shark will do so if you can see this, it's coloring the track, the packets right so we have some TCP, then we have this get requests. So we're going to look through here this HTTP. So we're getting slash on example calm, and we'll actually see the raw response. So if this had any sensitive information we would actually see it all in here because we captured all that traffic. So that's why HTTP has actually no proprietary no protection we can just read that as is HTTPS does not. And so it can yeah anyways wire shark is awesome. It's super fun to look through this stuff. Questions on this. So, turns out. So our core problem as we talked about is when two machines talking to switch network as host see we never get any of their packets. So, now, so we looked at previously how our works. Now what if we apply this security mindset that we've been developing to this analysis. So let's think about it from the perspectives of each of them. So host be host be gets a packet that says hey, this is the source MAC address. What can host be trust in this packet. Can they trust the math, the source MAC address way to think about it is put yourself in a scenario, I will see and I have control. Can I make a packet that says, I'm, I'm, my MAC address is 804674 h3. I think it's gonna stop it. The broadcast is probably the only thing that it can trust and there's one thing right, but it knows that this was destined for everyone. And it fundamentally doesn't know that the machine that has been the IP address 1921681 out of 100 has the MAC address 804674 a three. And then so it responds. Now, put yourself in the context of host a. What did host a know before he gets the ARP reply. It doesn't know some things, it's not nothing. I'll say it doesn't know some things. It knows the IP address it was trying to contact right it knows hey I'm trying to it knows it's IP address. It knows the IP address that is trying to contact, and it knows it's MAC address. Right. So it's MAC address it's IP address the target IP address those the only three things it knows. Now, when it gets this ARP reply back, what can it trust from this packet. It can trust the source, but sorry the destination map. So we can trust this first part that says oh this is destined for me it must be for me, right, it's, it can just check that right it doesn't have to spoof anything like that. So we can check that great. Does it know that this packet actually came from a machine with this MAC address. Well, this could be spoofed as host C. We can just write this out on the network and the switch will take it and send it over. And then we can see what it's about can it trust this ARP reply 192 168 1.10 kind of it's the IP address that it's looking for so it can know oh this is I just asked for 192 168 1.10, and this is a reply for 192 168 1.10. Can it trust that it's actually at 0131D 988. So it didn't come from C. Who's to say that C doesn't reply with its own MAC address and its own information. And so we're getting in here is there's actually a fundamental problem on local networks of this of authentication right, we have no way to tie the identity of this machine. When we get an ARP reply back, we have no way of knowing that there actually exists a machine with this IP address and this MAC address on the network. So we got an ARP reply. And so this leads us to ARP spoofing so what if, let's say, and be you're trying to communicate with each other. What if we're able to trick them that what if we're able to trick host a that host be MAC addresses host see back address, and we're able to trick host be that host a MAC addresses is is host sees MAC address. It's the same with all their communication. It all goes to see, right, it will all go to see, because they'll think it's sending it to that MAC address, it'll go, remember the switch doesn't know anything about IP addresses or anything all uses the MAC address. It says, Oh, this is destined for overseas MAC address good. And when the sense of packet the same thing and we'll go to see and see knows can know the true value so we can actually then forward the packet to host be correctly maybe altering it or doing whatever it wants in between. So this attack is ARP spoofing. So the goal is we want to sniff and maybe even then modify all traffic between two hosts in a switched environment. And the core problem is this stateless nature of the ARP protocol right I just send a request. Please somebody tell me who has this IP address or who what's the MAC address of this IP address. And then we just respond, right, we just say yeah I'm over here trust me. And so you can see that these protocols that work to basically like fundamentally run the internet, we're never designed for, you know, when you're designing this stuff, we never think like oh but what if there's an untrusted computer in our network. They look at you like what are you talking about there's eight people in this room we're the only people running machines like we're administrators we run all the machines in the network of course they're trusted right they weren't necessarily thinking about those. So one of the crazy things is actually most. Most machines will not keep track that oh I sent out an ARP request. They just will accept any reply. So if you reply with an ARP reply, even though they never asked. They'll just update their, their cash. You can think about it from the operating system perspective. It's actually a lot simpler. Right, if you only need to keep track. So if you only need to implement one functionality of Oh, I need to know what IP what MAC address this is. So you just send an ARP request. There's nothing else that whatever it gets an ARP reply this updates the cash, and you're good to go you don't have to do any other functionality you don't have to send you have to do things like okay but I send a request how long do I wait for a time out before I get a response and got it out of all this stuff. And so, we can actually as an attacker. We can send multiple things. So one way is we can just send spoof ARP messages to both victims and essentially poisoning their cash so why is it why are we calling this like poisoning their cash. Yeah, because it's not necessarily valid but it's under my control right as an attacker so I'm controlling the value that's inside your ARP cash, that is what I want it to be so I want you to. It's invalid, but it's a valid cash entry that's kind of the tricky thing right that's why invalid valid it's incorrect for the state of the network, but based on the protocols involved it's totally fine. And it's attacker control so that's kind of the voices. So, then they'll just send their IP packets to us, and we basically inserted ourselves in the middle of their connection. And then the attacker host can then act as the router because the attacker knows the true IP address and max of each of the things, and then make sure the packets go correctly where they need to go. So let's walk through this real quick. Okay, so we have host a 1921681 out of 100. And host C is our bad guy 1921681.137. So we're all in the same local network. And what I'm going to draw here is their caches of each machine, these are the our caches so post a said knows that. So let's say it's set up correctly maybe there was an ARP request followed by an ARP reply that we didn't get involved with. 1921681.10 host B 1921681 out of 100. And host C knows right host C knows the true MAC addresses of everyone. So the very first thing we'll do as host C is we will send an ARP reply from C to host A. And that our reply will say hey 1921681.10 is at my MAC address the attackers MAC address. I'm just going to update my table, and it will also will also send a ARP reply to host B saying okay 1921681.100 is at this, it updates its table and and what we can do. You know we may be worried about time out so we can just send us every minute. Every second, if we really want to. And that way they'll just keep updating their internal caches the cash entry will never get stale, and they won't ever have to do an ARP broadcast to say hey what's this who has this IP address was MAC address. So now when host A wants to send a packet to host B. Right, it's the exact same process that we talked about. It's a local ARP cash, and it says, Oh, do I know the MAC address of 1921681.10. Yep, here it is. Great packets that I'm going to send we'll get sent to host C. And to make sure that they don't actually know what's going on, we'll see we'll take that change the destination MAC to be the host bees MAC address, and just send it out. And with that way then the reply will also go the same way, right, it will go right here. And then it'll go back. Crazy, right. There's very little the other way you could do this. So, is if you could raise the ARP reply. Right, so you could, if host A makes an ARP request. And either try to be the question is if you want to be first or last right so if you, if you kind of lock in that entry, as long as you can beat host B, or you could also maybe trigger denial of service so to send a ton of traffic to host B from this system or another system, so that host B doesn't get that or is delayed in processing that. So host A then broadcast, hey, who has this IP address, your host C is not loaded so it can respond quicker than host B. That would be another way to do it. There's all kinds of tricks that you can play here with how to make sure you win, win the race in the way that you want to. But most operating systems don't do that they just, as soon as you get this reply you just update your cash. So you don't even need to do that you just start to spam ARP replies to your two victims, and then they just update their cash entries and now everything flows to you. So yeah like this is why legitimate and this actually so one of the worst networking cases you can be in is when you are on a network and to host at the same IP address, this actually causes the same thing. You send our request of who has this IP address, and two machines respond so you get non determinism of which one you're actually talking to this happened to us. I was doing my PhD in our lab, because we've ran out of IP addresses and apparently like the DHCP server was giving out the same IP address to different machines and I would SSH into a machine. Sometimes it would be fine and then other times it would say, this is the wrong host like this is a super scary warning I was like, what is going on this doesn't make any sense and then I was actually like using network tools that you look at what's going on you're like, way, why am I getting to our replies back that's insane so. So yeah this is not an old attack this still works. Most tools will repeatedly send spoofed our replies to keep the catch in the desired state. The other thing, so there's a tool you can actually use to do this so that there's a tool, you know, like we've been talking about in the class. So it's definitely your advice to test these things do this in a local environment, especially now in this day and age you have multiple machines multiple devices like set up an environment where you control all the machines and everything involved or get your roommates or whatever you're able to do this. That's why when I was messing with this and have a bunch of machines but I live in a house with other people and so I'm like hey can I mess with your guys computers for a little bit like sure do whatever you want so. Yeah, you learn how to run a cat and you can get their traffic going through you and you run tcp dump on another thing and you're like oh my God I literally am getting all the traffic that they're sending. And we've already seen an example of. Basically, we're also, you know, once we've done this right we were spoofing our replies, we can use this exact same principle to spoof IP packets. Because, again, nobody on the network is checking that we actually have that IP address. We actually didn't talk about how we get the IP address but that's actually a separate issue because it doesn't really matter. So IP spoofing is basically sending a data, an IP datagram packet impersonating another host as the source address, but exactly what it sounds like so you can have multiple machines on the network. And the attacker machine in this case 1110 2121 can send a packet pretending to be 1110 2076, which is the phone device to 1110 2014. There's a IP packet there. Now the problem is where is this packet going to go back when when dot 14 replies where's it going to reply to. The dot 76 Yeah, so we need to use to get that reply we need to use our poisoning or something to make sure that we got that reply. The fundamental principle as we look at sending and doing spoofing across multiple networks is how do we ensure that we get that reply or how do we deal with the fact that we won't get that reply if we never get it in the first place so. Yeah, you can think of it this was like a packet that like an FS like network file system uses GDP. This was a packet that said delete. Right. All your dad is gone. And that's because they're usually so spoofing again. Trust relationship something that says hey 1110 2076 is trusted by 1110 2014. If we can just do whatever we want on the system anyways then we don't really need any of this fancy stuff right. One of the key reasons why you can't, especially in a local network, you can't trust the IP addresses because nobody is checking that anybody is exactly who they say they are. All right, questions, just learned enough to be dangerous on a local network, and hopefully understood why, right, like why these things actually arise and why you can do this. Cool. All right. Of course, when you come back from spring break and you've completely forgotten everything about networking will continue on indirect delivery so have a good spring break and I will see you week and a half or whatever Tuesday after spring break.