 Yeah, I haven't had time to actually look at the earn it act enough, so I don't feel like I'm qualified to comment on that. But yeah, I think as it develops, it'll definitely be something we can look at. Ooh, ASCII emotes nice. All right, can everybody see my screen? Cool, thank you. All right, so you can see that all your chats are on here, so just for those that joined late. I'm going to be recording the chats as part of the online recording so that people can see your responses. So, you know, that's also tied to your name. It'll be on YouTube forever, act professionally, which I know you will. All right, cool. All right, let's get started. So let's see. There have been some questions in, let's see, there we go, all right. There's been a few questions about the assignment, so they'll be, you know, please come to office hours. They'll also be a virtual recitation, so that'll be posted soon. Join that, the TAs will be going over how to use GPG and all that fun stuff. And definitely be thinking about how you want to do that. So only about a third of the students have actually uploaded a key to the server successfully. It's about 120, so I'd like that number to go up so that you're all doing the assignment and everything's going well. So yeah, so join, you know, you're already, if you notice you already had a head start on attending recitation section virtually, so we'll be continuing that. We'll be posting that in the chat. It'll also be recorded and posted online, so you can check that out. Cool. All right. Yes, Ethan. No, it's, we'll probably be up tomorrow. It's literally, it's going to be pretty simple for you. It's just submit the, submit the uploaded ones and it will tell you roughly how many signatures are on it. It won't tell you of course which ones are true or not true because that would reduce the point of this. So yeah, so you'll just export out your public key because that will then have all the signatures on it, turn that in, and that'll be part. So it'll be on Gradescope very soon. I just need to develop that. Cool. All right. Let's get on with some networking. It's how many, you'll be graded based on how many valid signatures, how many signatures on real keys, but you obviously won't know when you submit how many, we won't tell you how many valid signatures you have. We'll tell you how many signatures you have. That makes sense. Oh, yes. That's a good point. Yes. We will have, we'll be doing CTFs. We'll have two CTFs the rest of this semester. I'll make a post about this later today so we can schedule those in. The basic idea is you'll split up into teams. There will be a jeopardy style CTF. We can have several challenges of hacking challenges that we'll go through during class. We're setting up how to do, how to do this online in the best way. So if you have any suggestions, feel free to send it my way, the TAs way. We're kind of working with the TAs and the undergrad TAs to figure this out. No, office hours are not in person. Office out, everything is virtual now. So check Piazza for all the links for Zoom. Cool. Any extra credit CTF? Don't know about that. We'll see. All right. Cool. So going on to networking. What is CTF? Great question. Capture the flag. So it's basically like we're going to do an in-class hacking competition and that will be worth a portion of your grade. You can check that out on the syllabus. And so it'll be super fun, I promise. Cool. Okay. So we talked a lot on Tuesday about how networking works. So we've been looking at specifically how networks work for that kind of that first part of the network hop, right? So how do packets get from our machine to like our router or to the next hop on our local network? So as starting off, first of all, how does a host know whether a target IP address is on its local network or an external network? Yeah, mask. Yeah, the net mask. Great. So we talked about that, right? That's the way that the part of the information that a host needs to have in order to probably in order to figure out which hosts are local and which ones are remote is the net mask. Great. Awesome. Cool. So the next feature that we looked at, we need a way for, because when machines want to talk to each other on the internet, all they have is the IP address, right? So with the net mask, we have a way to tell is this IP address local or remote? If it's local, then I need to send it using the link layer to the next hop directly to that machine. And in order to do that, I need to know what's the underlying MAC address. So what is the MAC address, remember, is the hardware address at the link layer. So we need this address resolution protocol or ARP that actually does this translation so that two machines on a local network, one can ask another, hey, who has the IP address 192.168.1.10 if you do, tell me what your MAC address is. And so that's what they do. Cool. And so, okay, so then we talked about hubs and switches. So let me see if my drawing works now. I may have hopefully fixed this. Okay, that's a little bit better. Yes, nice. All right, cool. So as we talked, we talked a little bit about the difference between hubs and switches. So can somebody remind me about that? So what is the difference between a hub and a switch? Hub sent to all. And yeah, okay, cool. So we talked about that actually. I guess we didn't talk about exactly how switches work. But yeah, so hubs will send, and remember they both kind of all look the same, right? There's a box with different ports. You can think of different ethernet ports. Port one, port two, port three, and something like port four, yeah, cool. So hub not smart. Very good. Yes, I approve of that description. So okay, so on a hub, any data packet comes into any port. It comes out to every other port. And there's no kind of smarts in the system. So the really cool thing of what a switch does is a switch is smarter and keeps track of information. And specifically, it keeps track of what MAC addresses does it see on what ports. So if we have here, we have host A, which let's say has a, we'll call it MAC A, something like that. And here we will have host B connected to this port. And that has something like a MAC of B. Essentially, the start, and we'll say we have host C here with very similar details, right? So at the start, a switch knows nothing about the network. So it doesn't know where to send packets. So it will essentially broadcast all packets out everywhere. And then it will learn internally a mapping that says once it sees packets from host A, it will say, oh, MAC A, oops, that's on A, that's a P. MAC A is at port one. And then when host B responds, it will send back with MAC B is at port three. And that's how it knows. So wireless gets much more confusing. So I don't want to go into it very much. But wireless you can think of, if it's like thinking think of two ways on a unsecured wireless network. So if your wireless network has no password, it's essentially a hub and you can sniff all the traffic that's happening. If it's a secured network, it's much more like a switch and you can't actually see other people's traffic. Cool. So yeah, so this is basically how it does this mapping of MAC addresses to ports as packets are going. And so as that's actually happening. So this will get into specifically how we sniff. And so this is, oh, maybe, yeah, I will bring up my, so this kind of one of the key goals and one of the key attacks we always want to be thinking about inside of a network is how do, how can we sniff packets and how can we sniff traffic on the network? So some things that maybe you don't realize protocols like FTP, HTTP, some mail protocols like SMTP will send the username passwords in the clear over the network. So if you're able to see and read those packets, then you're able to steal that information. And so this is really one of the, sniff is, yeah, see or read both of. So sniff basically you can think of means read. See kind of, it really depends on the encryption, right? So if the network is encrypted, if the network traffic is encrypted, it doesn't matter that you can read it because you can't break that encryption. But maybe there are ways that you can break that. So there's other things to think about. So basically, so just like normally your network interface card will drop any packets that are not meant for you. That's what we saw. That's why hubs work is because your network interface will get all the packets, but anything that doesn't have a destination MAC address of let's say MAC address a will not be will not be shown. So so if it's in a hub, you can just actually read all that you set your network interface into promiscuous mode, which says send all the packets up on that network. And but of course, in a switch networks, this is why we looked at the difference between hubs and switches. If it's a hub, you don't have to do anything, you get all the traffic on the network. And if it's a switch, then you need to do a little bit more work and a little bit more information. Oh, sorry. Okay, so this is a kind of why we want to sniff, like I said, so a lot of protocols actually will transfer all of the authentication information in the clear. So username password. So when we looked at authentication, we were looking at how do we steal that authentication information. So we can do that by using by sniffing and identifying these protocols. So if you think this is something that is silly, who uses these types of things? Does anybody use, let's say, FTP for work, or maybe pop to access emails? Anybody know? Can maybe use the raise hand functionality? No, no one. Man, tough crowd. Some people. Good. Maybe you're just doing that because I asked. Well, thank you. Yeah. Okay. So we did, when I was in Santa Barbara, we did a pen test for our company. And part of what we did was use, we set up a tap on all the outgoing traffic of the network just to see what we could sniff. And so doing that, we ran this sniffer, collected all this data, and basically we found that somebody in marketing had a FTP site they were using. So we stole those username passwords. And then from there, that gave us access to their site, that gave us access to more information in the company. So these things are used kind of all the time. And so this is why this is such a useful tool. So there's a lot of different tools that you can use in order to sniff traffic. You can collect, analyze, and even replay traffic, which is pretty cool. I will say one of the super useful things you can kind of learn for your career is if you learn how to use effectively these sniffing tools. So specifically, when doing network debugging, like for instance, I was dealing with this crazy problem once where I was trying to set up a capture the flag system for my grad class, like an internal hacking assignment of web applications. And what I had to do was on the packets were somehow getting lost. And so I had to use TCP dump on all these different machines to figure out exactly where the data was being dropped so I could diagnose the problem and figure it out. So this thing comes up all the time and I will tell you if you learn how to use these tools and you understand networking, you will seem like a true expert to some of your colleagues when you have insanely weird networking problems that need to be solved by understanding exactly what's going on. So these are some of the examples of the tools. So TCP dump is a command line tool that collects traffic. It is basically the one I use a ton. And then you have other cool tools that can kind of rip apart traffic. So you have a tool that can replay traffic, something that can rip a packet of traffic apart into different flows. That's cool. And the other main tool is Wireshark. So this has support for a number of different protocols in order to parse and show everything that's going on. So hopefully, yeah, these are the most common tools using the industry for sure. Usually the way it works. So TCP dump is all command lines. So I can run and you need to run. So in order to set your network interface as promiscuous mode, you need to run it as root. Dash I sets the interface. Sick. Yeah, we'll talk about detection later on. So hold that thought once we really understand what's going on. Let me check what interface five. So I can do sudo TCP dump n. The dash n option means to not don't try to map IP addresses to their domain names because that can slow things down. Dash I interface five. And you can then specify a filter to say I only want let's say port 80 traffic. And then when I type in my super secret password, we should see a lot of traffic or nothing's happening on my computer. This seems sketchy. Let's just look at all of it. Yeah. All of these insane amounts of data and kind of the interesting thing. This is all UDP packets. So we can see the UDP here. We didn't get into. Yeah, this is definitely the stream, which is interesting. You can also see port numbers here. So this is my local machine to this port 80 one must be the port from zoom. So yeah, you can see a lot. And you can do things like five ARP. So you can look at all the ARP traffic. We'll see if anything actually comes up. Maybe I can try pinging Google.com in another window. Yeah, this is not a YouTube video. You can't rewind, but you can view it later on YouTube. So yeah, here you can see the ARP traffic. So I've used a filter to filter only the ARP traffic because I don't want to get all those crazy UDP packets from the stream. I want to actually see what's going on here. And yeah, OK, so yeah, so you can see all the ARP requests and replies that are happening inside my network. I can filter ICMP, which is the ping protocol. So I can see all of the ICMP echo request and reply. These are ping packets. So these are going from my IP address to this is we can see what the machine has mapped Google to on this window. So we can see 172.217.5.78. We can do echo request and echo reply. And this is sending an IP packet from us to Google and getting that reply in order to measure the time latency that it takes. Now, so if we wanted to do something, ICMP write temp test.pcap, now I'm going to store some packets. I'm going to send some ICMP ping so you can see what Wireshark looks like, maybe. OK. Or I don't have Wireshark installed on this machine, so I won't be able to do that right now. But I could do that later. So you can see Wireshark gives you a nice graphical interface that you can dig into these packets. But yeah, this is the basic idea. Let's do this. I can show you something interesting. So let's do port 80. Somebody remind us what's port 80? HTTP? Yeah, thanks, Ty. And I want the option dash A. So the dash A option tries to output the ASCII values of the packet if it can do it. Let's go to example.com. And so we can see a ton, a lot of different packets. We can see here this is our HTTP get request, get slash HTTP 1.1. This is our get request. And then this is the response from the server, 404 not found, I guess not super interesting. But these are all the different packets, HTTP packets that get sent in order to make an HTTP request to the server. Let's see. I don't know if this will work. I think it will try to redirect you. Yeah. So this is what the output that I got, which is a 301 redirect. So it's redirecting me and saying, hey, I don't speak HTTP, only talk to me over HTTPS. But this shows you that you can actually see exactly what's going on inside all of the packets that you're sending. And this is what allows somebody, if they can sniff your packet, somebody can see exactly if you're not using HTTPS and you're just using HTTP, somebody can maybe manage the middle of your traffic and see exactly what packets you're sending and getting back. Cool. Any questions on tools like this? Any questions on basically network sniffing tools, let's say? Oh, two raised hands. I think these were raised earlier with the, I'm going to lower your hand. Boop, boop. Yeah, those were from asking about using FTP and work. OK. Yeah, Ethan, go ahead. Yes, exactly. These tools show you and they'll be able to capture for offline analysis exactly what packets are being sent on the network. Yeah, let me. I guess I was a little confused. These are two different things. But the difference between what a net mask is doing versus the ARP, the Adjusters of Wichita protocol. Right, so ARP, maybe we can go up here. ARP is trying to translate between IP addresses and MAC addresses. So for instance, like we can see right here. So here we can see this is an ARP packet saying, hey, on this network, who has 192.168.0.27? Whoever has that tell 192.168.0.1. So 0.27, I think is my machine, I believe. And this ARP reply is saying, hey, this is at this MAC address. So MAC address is actually what's used in order to map in order to send locally over through Ethernet. Nathan, you can use on the participants mode. There's a raise hand somewhere in there in the participants mode. Yeah, so anyways, back to the ARP. So ARP is to deal with this in order to just do this mapping to say what MAC address has what IP address. And the net mask is used to determine which ones are local IP addresses. What IP address can you send directly a packet to on your local network and which ones can't you do that? And we'll go through later one things you can't do, but we'll actually go through attacks that can happen just on your local network without even thinking about other hops. Does that answer your question? Yeah. OK, cool. Great, OK, so we have sniffing tools. Cool, so now one of the key things when we went and looked at ARP, right, so let's think about kind of this scenario again. So to remind us, we had host A who was at this IP address who wanted to send a ARP request to Hopes B because they wanted to ping them first. And to do that, they needed to know the MAC address of their IP address. And so they sent a aren't ARPs the only protocol used for security? Think about that as we talk about this here right now. So, OK, think about this from the two different hosts perspective, right, and specifically putting on your security hat. So here we have this ARP request from host A. Host B gets this ARP request. What? So when host B gets this, so if we just, let's say, maybe we can do this, just zoomed in on this, this host B gets this ARP request that says, hey, who has, and this ARP request is, who has 192.168.10.1.10 tell 192.168.1.100? So how does host B know that this IP address is actually the .100 is actually trying to, is actually the one that made that ARP request? I wonder if I wait longer if I'll get more. Right, correct. So they can't even check the MAC address because they don't know, right? Nothing, each host independently creates their own MAC address. They have no way to communicate with them except over ARP. So all they know is they just got a packet that claims that this 192.168.1.100 needs a, is wants to ask for their MAC address. And then let's think about it from the other way. So now, where's my, there we go. So now this ARP reply comes back, right? So this ARP reply says, well, 192., oops, hello. Let's see, ARP reply 192.168.1.10 is at 0131D98B8. So if we look at this from, why are these so annoying? Thank you, Mac, what are you doing? All right. So if we look at this just from host A's perspective, right? And we say, host A gets this ARP reply. This ARP reply says 192.168.1.10 is at 0131D98B8. How does, how does host A know that that is actually host B's IP address and MAC address? Yeah, so if we think about it, if we even go back to thinking about this protocol, right? So this is really an ethernet based protocol. So all it knows is that it received a packet. So host A received a packet that was two, that was a, sorry, this is the source. So that it was two, it's MAC address. So it knows that it's for host A. And it knows that the source MAC address is 0131D98B8. And it's saying, hey, 192.168.1.10 is at 0131D98B8, right? So what it can guarantee is it knows that this was meant for it, right? This packet was meant for host A. But other than that, it can't guarantee anything about this header. For instance, what if host C created an ARP reply that actually said, hey, 192.168.1.10 is at C's MAC address instead of B's MAC address. Does host A have any way to differentiate those two ARP replies? Yeah, fundamentally no. With all the information that it has here, it has no way of knowing. And this is actually, it's kind of crazy. It's this core vulnerability in this system to map IP addresses to MAC addresses that we can use in order to do ARP spoofing. So this is an attack that allows us to do all kinds of really cool stuff. And basically allows us to listen in on the communication between two machines. So the whole idea, and one of the really interesting things is the ARP protocol is stateless. So what this means is that when you send an ARP request, you don't keep track like, hey, I'm waiting for this ARP reply of this specific thing. And it means that ARP replies without a request will be accepted. So let's go to the board. Let's try drawing a little network. So let's see, we have our switch here. Okay, we're giving up on that ugly switch. Okay, we have a, wow. We have a switch. We have A, we have B, and we have C. All right, or let's go Alice Bob and we'll change this now to Eve. We'll bring back our evil Eve. So one thing, okay, so now if host A, host A and B wanna talk, but Eve wants to be able to steal their communication or let's say Eve wants to pretend to be host B to host A, right? So host A will send out an ARP, an ARP request and which machines on this network will get that ARP request? Yeah, all of them, right, B and E, because it's a broadcast. So an ARP request is a broadcast that goes to everyone on the network. And it's saying, and the ARP request here basically asks who has the IP address of B, right? Goes to all the machines on the network and let's say Eve is much, much faster than B, right? So Eve gets this packet. Eve says, hey, I wanna pretend to be host B. So Eve can create an ARP reply and say, let's see, say IPB is at, let's see, I'm gonna just use M for MAC address. So MAC address of Eve, right? And she can create this reply. And remember the interesting thing about kind of networking and is that nothing prevents her from creating this packet, right? So she sends this out, who gets this packet? So if it's ARP reply, where's it going to? Yeah, just host A, right? So only host A gets this packet because the ARP reply, if we go back, remember the ARP request included the MAC address of who was requesting it. So that that way the reply could be sent just to that MAC address. So this ARP reply will be sent from Eve back to A. A gets this and what's it gonna do, let's say in its internal ARP cache? Yeah, add it to the ARP table. It's gonna say IPB is at MAC address of Eve, right? Now, when we think of what does the packet look like that A will send to Eve, right? If we think about it at the IP level, so what's, so now A wants to send an IP packet to Eve, right? So at the IP level, what's the destination IP gonna be? Justin asked if the ARP table could have multiple IPB entries, let's say no for right now, but we'll talk about that in a second. Let's say B doesn't reply for whatever reason, right? So the destination address is gonna be what? So this is a packet that A wants to send to B. So what's the packet gonna look like? Yeah, okay, so, yeah, remember at the IP level, A wants to talk to B, which is all only IP addresses, right? So the destination IP address will be the IP address of B. What's the source IP address gonna be, right? IPA, because it's coming from A. All right, awesome. So we have this at our IP level. Now remember this packet will then be enclosed inside of a MAC, an Ethernet link layer packet and it will have destination MAC and source MAC. So A will use its ARP table in order to figure this out. So what does it think the destination MAC is? Yeah, the MAC address of Eve and the source MAC, MAC address of A. Now, assuming this is a switch network, where is this packet gonna go, right? It'll send it out, the switch says, oh, it looks at the MAC address of Eve, it looks at the destination MAC and it will send this only out to E. So it goes to the switch and goes directly to E. Now Eve gets this, let's say Eve just wants to pretend to be a B, right? So Eve gets this packet and then Eve wants to respond to it. How's Eve going to respond? So we'll think about the IP level. So DEST IP, source IP and DEST MAC, okay. So at the IP level, right? So if Eve is trying to pretend to be B and reply to this packet, what's the destination IP address gonna be? So DEST IP address will be IPA and the source IP, IPB. And what about now the destination MAC address? MAC address of A and the source MAC, MAC address of Eve, awesome. And then again, we could demonstrate that these are in two different layers, the link layer and the IP layer. And this packet again, when Eve sends it out to the switch, where's Eve gonna send it out? Or where, sorry, where's the switch gonna send it out? Just to A, exactly, just to A. So B never even sees this traffic. Okay, cool. So fundamentally, this is how we can use ARP spoofing in order to impersonate a machine on the network, right? So here, host A has absolutely no way of knowing that we've essentially taken over the IP address of B, right, because all it knows is it thinks that the IP address of B is at the MAC address of Eve and it has no way of knowing this. And actually the situation is even worse because as some people brought up, well, what if B replies, hey, the IP address of B is at the MAC address of B? So this is only for local networks. So right now we are specifically focusing only on local networks. So, cool. Okay, so now with that, now we have the problem that people brought up of what if B responds and then we ask the other question of, well, what, like what happens to this ARP table? Is it just to get added here that the IPB is MAC address of Eve and the MAC address of B? So most systems will use a, so because of this stateless nature, so the simple fact is that the operating system of host A will not keep track of what requests it made. So it won't say, oh, I made a request and now I'm waiting for a response and then I update the table and then I drop this reply from B. It's stateless, which means that whenever it gets an ARP reply, it just updates the table. So this means that, so in this case, if we were first and we beat B, we set our ARP reply of IPB is that MAC address of E that would update this table. But then when B's reply got in, that would now change this to MAC address of B. So as an attacker, what can we do to ensure that our MAC address is always in there? Yeah, so either be last or spam it. We can do it every five seconds. We don't even have to wait when they send a request. We can just keep sending ARP replies and we will guarantee that we will have altered the victim's ARP cache such that it's our MAC address. So the MAC address of Eve. And we can just keep sending that. So now, okay, so now let's see. So people are kind of asking, okay, what kind of information can you access or what's the impact of this kind of attack, right? So one thing now, if there's on this network, if A and B have a trust relationship, so let's say host A says IP address of B can log in to me without a password, right? Now Eve by impersonating that, by Eve impersonating A, then by, yeah, by Eve impersonating A, or sorry, by Eve impersonating B to A, they could let's say log in to host A as if they were host B. So we can use that to that effect. And then we'll see that we can actually, so let's take this one step further. So we've only impersonated A to think that we're B, but what if we actually wanted to, so now any communication from A to B will get sent to Eve, but what if we wanted to actually try to man in the middle and intercept the communication between A and B? So right now we've only done one branch of that, right? We've only intercepted the communication from A to B, but now we can use this exact same thing to do it from B to A, right? We can use the exact same technique, trick B to think that we're A, and so any packet they send to each other comes to us. So let's think of how that would work. So we have Alice connected, Bob and Eve. Okay, so, and the important thing, like what Steve's saying, the important thing is that this attack will work no matter if it's a switch or hub. I guess the thing I didn't mention is that you can actually in older switches, you could overload them to become a hub. If you make that table between what ports have what MAC addresses, if you make it huge, it will like just crash and turn into a hub. Modern switches I think are much more adept at that, and so you have really cool techniques to do this here. Okay, yeah, so let's think about this. So we wanna intercept the communications with A and B. So we know based on our last example, the very first thing we have to do is to send them each ARP replies to make us think that they're the other. So if we draw, if we think of this as like the ARP table of A, oops, that should be a P, and the ARP table of B, right? So what we wanna do, so Eve wants to send packets, ARP replies, so it wants to send an ARP reply to A saying IP of B is at MAC address of Eve, and an ARP reply to B saying the IP of A is at MAC address of Eve, so that that way in the ARP table here, we have for A, IP of B is at MAC address of Eve, and then what do we want here for B? IPA is at MAC address of Eve, oops, yeah, great. Right, so now any packet they send each other will come to Eve, right? Okay, so we've sent our ARP requests, we've got this set up, now A and B start talking to each other, right? So now let's walk through kind of the packets that get sent, so we'll do it kind of the similar way. We'll do it just like we did before. Destination MAC, source MAC, source IP, cool, okay. So destination MAC, so now, so let's think, so host A wants to send an IP packet to host B, what's the destination IP gonna be? Yeah, IPB and the source IP, IPA, and the destination MAC, E and the source MAC, MAC of A, cool. All right, so that packet gets sent out, I like drawing these little boxes around it. Cool, that packet gets sent to Eve, now Eve wants to now not just, Eve doesn't want to impersonate B and pretend to be B, they actually want to send this packet to B, right? So now Eve, I'm gonna just put in here data zero, so this is the zero with packet, it's the very first packet that it gets sent in here, that's some data that's getting sent, so Eve gets this packet, now Eve wants to send it to B to get their actual response, right? So yeah, so we can do, so now if we take the same packet, so the destination IP addresses IPB, source IP is now IPA and the same data of that packet, we didn't change it, but now what do I need to have as the link layer in order to get this packet from A to B? Yeah, so exactly, great. So the destination MAC address will be the MAC address of B and the source MAC address is gonna be what? Oh, we're having some fights in the chat. Yeah, so why is it the MAC of A? Oh, sorry, why is it the MAC of E? Yes, because B thinks E is A, right? We've tricked B here into thinking that IP address of A is at the MAC address of E. So when we send this from Eve sends this packet, right, to the switch, it gets sent out from Eve to B, which means it goes right here to B. B gets this packet, replies to it, and so what's that reply gonna look like? So let's start again at the destination IP, let's call it data one, right? So the next reply, so the reply in this next packet. So where is B's reply going to go? So what's the destination IP address? Yeah, specifically IPA and the source IP address, IPB, right? And the way to think about this is you just look here, right? You just look at, it has this packet, it has a packet from, it thinks IP address of B, sorry, to IP address of B from IP address of A, so to reply to that, it just flips it, right? So it says, okay, I'm making a reply, that reply is gonna go to the IP address of A and the source IP is gonna be the IP address of B, right? Now the question is then what are the MAC addresses? So what's the destination MAC address? Yeah, the MAC address of Eve and specifically why? Why is it going to be the MAC address of Eve? Exactly, the ARP table here, right? Let's see, I don't really like this. Yes, but this ARP table, right? It looks up in its ARP table, it says, oh, I'm sending a packet to IP address of A, I look in my ARP table, I use destination MAC of MAC address of Eve and then the source MAC address will be the MAC address of B, sends this packet out and now, so this packet goes out, so B sends this packet, where does the switch send this packet? Yeah, directly to Eve and then Eve gets it, now Eve what? So the way to think about it is MAC address is used to send packets locally inside of a local network and IP address is allows you to send packets not just to your local network but to external networks as well. Yeah, so now Eve needed to take this packet, right? Send it back to A, so we want the same data in that packet, so we'll call it data one again, right? So the same data, let's say she's not messing with it. So what's gonna be the IP address here? Oh, IP A, source IP, yeah, great. Yeah, great, so it doesn't mess that up and then destination MAC, MAC A and source MAC, yeah, because remember, A thinks that IPB is that MAC address of Eve, so Eve wants to make sure that these match, great, cool. So that packet then gets sent to the switch, gets sent to A and now we've been able to all communication between A and B, this process continues, Eve gets to see all communication between A and B. I don't understand the question, if you trace the route, would you see Eve? So extras, yeah, so as part of, some of you are saying, yeah, there's much more packets than just A and B talking, right? If A and B were talking directly, you'd only have one packet but you have now A sends to E, E sends to B, B sends to E, E sends to A, right? So there's more traffic happening here but that's because we're literally, we've essentially inserted Eve in between A and B and so this is, so we've basically sent spoofed art messages poisoning their cache, right? So these are the steps that we took, we spoofed A and B and we poisoned their art cache, we then, we acted as a router basically. So every time we got a packet, we sent it to the right person and we were able to essentially man in the middle of the attacks. So here's kind of another example of looking at that, maybe we can do a brief, just walk through this going. I know there's a way, swap displays, there we go. Yes, so Eve, exactly. So Eve, yeah, Eve doesn't reply normally, like Eve will send these packets out so that it doesn't do, it doesn't operate as part of the normal ARP traffic. So here we have two hosts and host C wants to intercept them. Initially, so these below here are the ARP caches of each of the machines and you can see host C will send ARP replies to each of the machines in order to poison their ARP caches with its MAC address. And here we have the ARP reply to host B and remember the interesting thing here is it can do this without there being a request, right? So it can just send these replies as often as it needs in order to do this. Now, when host A wants to send to host B, some secret data, it will send it first to host C, host C will send that to host B. No, so that, yeah, exactly. So the ARP table is on each of the, I think of it as the host operating system has this ARP table. The switch also has a, not an ARP table, but it has a port, MAC to port mapping. So it maps for every port on the switch what MAC addresses has it seen there. So now host C can see that and we're able to, now, no matter the fact that it's a, let's say a, where's the ARP table? Actually, your operating system stores it. So that's when you do what happened to my participant list. I lost chat, what's going on? There we go, got you back. Okay, yes, so since this is a gaping hole in the protocol, there are, let's see, let me, okay. Yeah, where's the ARP table actually stored? Your operating system stores it. So I don't know exactly, it depends on each OS. Okay, cool. So, yeah, is this a gaping hole in the protocol? Yes, so we use ARP because of backwards compatibility and it's actually a fundamentally difficult problem. Like how do you, these are machines, so we'll talk about solutions later on, but it's kind of a difficult problem because you want this protocol that like any machine can kind of connect to your local network at any time. And so you need this mechanism because you, unless you and the way, one way you can prevent against this is by hard coding all of the ARP tables in all of your hosts and have them be static, right? But the problem is what happens if you get a new machine and plug it into your network, like it would be a huge pain to go update every other host on that system if you have even tens or hundreds of hosts. Yeah, so the switch also, it's difficult for the switch to do it because let's say both B and E are pretending, are saying their host A, or sorry, both B and E say they have the MAC address of B, how does the switch know which one's actually correct, right? It would need to let some through and it doesn't have enough information to know which one is actually which. So there are tools, one of the fun things is, there are tools to do this. So Ettercap is a tool that you can use to do this and automate this process of intercepting traffic. So mixing this with TCP dump. So what you can do is two machines on your network. You can pretend to, you can use Ettercap to manage the middle of their traffic and then you can use TCP dump to look at all the traffic on the network. Are you talking about my volume? I suppose there is, but I don't, don't you have a volume setting? Okay, cool. So you can use Ettercap to manage the middle of the machines and then TCP dump to look at all the traffic between them. You can also, we didn't talk about this, but in this example, we sent data zero, we just sent the data from one to another. You could actually data foobar, right? So Eve can alter and change the data between A and B and they won't actually know it. So there are some ways to protect against this, which yeah, we'll talk about a little bit. So some interesting things. There are technologies that you can do authentication at the switch level. I think it's 802.11x or something. So that each host actually authenticates to the switch or to the system. So that way you don't have a rogue Eve on your network. So there are some types of things against this. I will say if you, well now that since you're at home, if you wanna play with this at home, I highly recommend setting up two machines, A and B and doing this from a third machine on your local network. Of course, as always assume, make sure you have permission from people involved, but this is a super cool way to actually see this attack in practice and that it actually works. Now you can go look on how to do that. Yes, not on the ASU network. Don't do that on the ASU network. Do it at home on a network you control with machines that you control. Yeah, it's definitely possible to mess this up if you start sending weird ARP requests or replies. So you definitely don't wanna do that. It's not a nice thing to do, right? They probably have countermeasures, I would suspect, but I don't know for a fact. And Wi-Fi is, I think Wi-Fi is tricky. It depends on if you can do this. I'm not sure of all the particulars because again, the switch knows much more about your machine and your MAC address so it may refuse to route traffic from your MAC address that's not for you. So yeah, those kind of details all depend. Are we gonna discuss? So I'd say specifically ARP spoofing. Prevent it. Yeah, so like we said, you can prevent this by having static ARP tables. You can also look for machines on your, you can be monitoring your network for hosts that are sending ARP requests without a reply. VPN is not related to ARP or IP spoofing. It is unrelated. So VPN is basically a way for you to send your packets to somebody else for them to route it out for you and then send the replies back. Yes, did I say it wrong? I meant sending ARP replies without a request, yeah. Yeah, Ethan. So I guess what I've ended up like prevented is like when I go to like a restaurant or something and I join their Wi-Fi, like how do I know like there isn't interception going on that I am being tripped in some way? Yeah, you don't. So when you're on a open public Wi-Fi, it's, so the main thing to do use HTTPS, right? So that has, like we said, it has built-in identity detection for, so it's verifying the authenticity of the remote website using the public key infrastructure. So that's kind of the main thing, but fundamentally when you're on an open Wi-Fi network, anybody around you can be sniffing the traffic of that Wi-Fi network. And they could be using ARP spoofing attacks or other types of attacks based on just listening to your traffic. Yeah, thanks. Yeah, Gala. So you said for VPN, you're actually sending your information to another computer and that computer is sending it to whatever you want. So could that computer, the middleman, could they also sniff into your information? Yep. So yeah, the way basically VPN works is this is you, and here's your VPN server. So VPN basically ensures that this communication is encrypted from you to the VPN so that your user is sent from you to the VPN, that packet, so your packet that you wanna get sent out gets moved from you to the VPN. And then the VPN just sends out that packet. So you send a packet P, it's encrypted to the VPN, and then the VPN sends out P as if it was you to the network, to wherever it's going, and it gets the reply back, and when it gets the reply back, it sends it back to you. So it's good if you don't trust this first hop, right? So in this case of what we were talking about, a coffee shop or a restaurant that has unencrypted Wi-Fi, this will encrypt all your traffic to the VPN so at least nobody on the local network can sniff or understand what you're doing. I see, thanks. Yep, it also protects if you, let's say don't trust your internet service provider, or you don't trust your, let's say your country is monitoring all external traffic with like a great firewall, then this could be one way around that, cool. And the other type of attack that we can do locally is IP spoofing. So we can, just like we saw, and this is kind of inherent in what we've been doing here, so this is just a generalization of what we've been looking at, right? As we've seen, basically nothing in here authenticates the source IP, right? So when you get a packet, you don't actually know if the IP address is a, if the IP address is real or not, right? So in all of these examples, so let's say this packet here, right? So in this packet was a packet from IP address of B with a source IP of IPA with data zero. So inside this IP packet, so this IP packet remember came, this packet came from A to Eve, so from A to Eve, and then this packet went from Eve to B. So when B gets this packet, what does it know about the, what can it trust inside this IP packet? Yeah, so the destination IP address, so why the destination IP address? Why can it trust that? Exactly, because host B actually got the packet, right? It was meant for host B, so Bob can know and understand that it is definitely for host B, right? So can it trust the source IP address? No, and here's a great example where we're literally looking at a packet that got sent and E is essentially spoofing this source IP address, right? And nothing prevents it from doing so. Same thing with the data, it has no way of knowing if this data was actually sent by host A or not, it has no way of doing that. And so this is kind of a general notion that you can impersonate any machine on your local network and we'll see this extended to multi hop routing later of how this is done. So in this example here in the slides, we have, let's see if we can do this real quick. Yeah, there we go, right? So we have our little network and here we have our attacker. So our attacker's IP address is technically 111, 1020, 121. They are sending a packet though as if they were from 111, 1020, 76, the cell phone to 111, 1020, 14 and impersonating that IP address, right? Oops, so this shows that, and like the ARPS hooping example shows, nothing actually verifies the identity of that IP address, when we end this specifically and this is the thing to always think about and we'll be thinking about this as we get further and further into different types of networking protocols is you get a packet, what information in that packet can you actually trust? And as we've seen here, really the only thing at the IP level that you can trust is the destination IP that it's actually for you, right? You can't trust anything else, you can't trust the source IP, you can't trust even the data that you were sent, you can trust maybe the destination Mac because you know it's from you but you also don't, can't trust the source Mac necessarily, cool. Okay, questions on maybe the local attacks that we talked about? So for ARPS boofing you are impersonating different machines, right? You're tricking, you're impersonating different IP addresses on your local network. You're saying that this IP address is belongs to my MAC address. Yeah, so IP spoofing is a general idea. So you don't need to ARPS spoof in order to IP spoof, you can send packets on a local network pretending to be different IP address. Yes, so if, let's see if, you could still, I guess technically yes, if IP spoofing was impossible, ARPS spoofing would also not work. You could still ARP poison because you could send ARP replies saying that this IP address is at this MAC address. So man in the middle is, so conceptually. So here we have Alice and Bob and here we have essentially Eve in the middle. That is, so man in the middle gets you two things. You can sniff all the traffic but you can also alter or drop or do anything you want, right? So you can, so this is different. I'd say spoofing is different, right? So this is a man in the middle where A and B are talking. If I just have Eve talking to B, but I'm pretending to be A, right? So B gets packets thinking that their IP address A but they're really from Eve, that would be impersonation, right? I'm impersonating. Eve is impersonating A whereas here Eve is performing a man in the middle attack from A and B. No, the switch doesn't know anything about IP addresses. So most switches operate only at the MAC level. Yeah, so all it knows is ports and MAC addresses. I mean, yes, it is possible but usually, yeah, I mean ARP is used by everything. Like look at your machine, do TCP dump, look at the ARP tables that's used all the time. It's super important. Yeah, so a good thing to think about. So in this case, so here we have A, B and E, right? So here it's clear Eve is let's say evil and connected to the network. So you may think, oh, this is easy to prevent. Let's prevent people from connecting to our network. Well, A, you can have a network like ASUs where there's ethernet ports everywhere. So anybody can just take their laptop and plug in. But even if you didn't do that, the other thing to think about is, well, what if E was a developer machine by Eve that downloaded some malware that's now running as Eve, right? So E could be connected to the network. So this can let you an attack of when you get access to one machine on the network to get you access to more and more machines on the network. I don't know an example, like an explicit example of when this has been used in an attack, but it's, but it definitely can be. And it's one of the tools inside of a penetration testers toolkit to let's say pivot from one machine to another to maybe, or to maybe sniff or steal username passwords or other types of information between different machines. How do you avoid being? Yeah, so you can have a static ARP table, but the problem is you need to put that on every single host. So if you have a new machine on your network, on your local network, and we saw networks can range from 253, 255 hosts, however you wanna think about that, to 65,000 all the way up to much larger. So how are you going to go and add those, like you'd have to update the static ARP tables every time you got one new machine, you have to add it to everyone on your network. So the question is on Stuxnet. So Stuxnet was Stuxnet basically scanned local networks to infect different hosts and spread that way. I don't think it's specifically used spoofing. Oh, so the question about MAC addresses, yeah. So this is a huge problem if you ever have a system where you either have two IP address, like two machines with the same IP address on your network or two machines with the same MAC address, it causes insane havoc. This actually happened to me in my lab doing my PhD. We ran out of IP addresses and the DHCP server would be reusing IP addresses. So you'd SSH to a machine and half the time it would fail and half the time it would succeed. And that's when you need to use things like TCP dump in order to figure out what's going on. Yes, so you should be switching to non-encrypted protocols. So that's, or sorry, encrypted protocols, right? So that's why there's a huge shift to move everything over to HTTPS. Google actually, I think recently in the last year or so bumped up, they will bump up your Google search engine ranking based on if you have HTTPS or not. Let's see, when the first ARP request is sent from A to B and Eve is trying to spoof, wouldn't B still know where the original message came from? No, so that's, so yeah. So B would see, let's say that ARP request from A, but if you look like on my network, right, we were getting ARP requests, like the time that things spend in the cache is pretty small, like 15 seconds or something. I'm sure it's different for different operating systems. So the fact that they're getting an ARP request doesn't mean to be that it's definitely getting some information later. So it wouldn't know maybe that packet got lost or the other thing to always remember in networking, maybe A just went away, right? So A sends an ARP request to B, B sends an ARP reply, and then A just shuts off. Like B doesn't know or care that it never got any packets, right? Cool, any other questions? We can, yes, chat will show up on the recording. It's on the lower left of the screen. So everything that's on this screen is being recorded. Let's see, cool. Well, we covered a lot. One of the coolest attacks that is really fun in networking. Also, so next time we'll talk about indirect delivery and routing. So now we'll extend the concept of, so we talked about exactly how packets move in your local network from one machine to the other. And then we'll look at how packets move externally from your network. So how they move from your machine all the way to Google. So yeah, keep signing those keys. Keep helping each other out. And yeah, hope you're all staying safe and staying sane. Yeah, I changed coal, I changed it so that the chat appears this time. The submission link will be open soon, probably tomorrow, Justin. I'll post it on Piazza. Cool. All right, see you everyone.