 Thanks everyone for coming today. Let's get started. We'll start off by, is my mic on? Is my mic on? Anybody? Yeah? Any questions on the assignment before we get started into the parts? Now's the time I can answer questions for everyone. So like the RFC for known host says that IP address should be included. Yeah, so you should just filter out. You should write a little quick thing to filter out IP addresses. And like if you are making some dummy entries, like does it matter that corresponding host should also be presented to the DC password? No, you don't have to check that at all, right? You're just trying to find as many possible hosts as possible. As many hosts as possible. So you don't have to try to coordinate them and try to find out who's actually a real host or not, you just want to see. Like your evidence is, I found this in this file, that means somebody thinks it's a host. Is Astrid a valid entry? Is Astrid a valid entry? I would say no. You can include it, I guess. How about if you have one host twice? I think that's too easy to pass at the same to wait. Or is it out to have an open one? Let's say one user has general valid entries, and the other guy's as well. You're trying to be efficient, so I would output a set. I mean that just means your work is going to be more efficient and going to be not cause much problems. Hey, answer your questions on the assignment. So if you just came in, please sit down. So is the valid ID address of a host is acceptable? No. Yeah, we wanted to be hosting. Should be easy, right? Do you know the format for an ID address? So what if I type in a suitable amount after the exact and it comes from Astrid? Oh, you're talking about in part 3? So if you type in a pseudo command and it prompts, it doesn't mean prompting I actually don't think it'll prompt. I think it should fail because you don't have a TTY going. Yeah, you should just do whatever it does. Just display the output. If there's output, if there's not, don't worry about it. Just the compilation test cases, basically. So yeah, it doesn't have all the test cases yet. I'm still working on that. It's actually a lot more trickier than I expected because instead of just simple test cases where it's like input output, it's like I have to change the environment and know how I changed it and put it back and then the server has to run it continuously and I've got test cases on that and the output depends on what you assume. The smoke test should now tell you whether they keep the files correct. So that's good first. If the package that's all and it's not as small, that's your job. That's your job. And you know, when you think about some information like that, it can be helpful to your fellow students. Then it sounds like you probably didn't talk. In a package's file, you should be able to do that. You can share those files. If that doesn't work, then email me and we'll try to figure it out. For the web server part, should we only display the result of the command to standard out or should we do it to a web browser? Or should we send the HTTP through the web browser? So you should reply. The body of your HTTP reply should be the standard output of that command. It should be whatever the output is, that's what it is. It's just the response from the HTTP server. So HTTP doesn't really care about HTML or whatever. It's actually a transport. It's JSON or text or whatever. You should just set the body to be whatever the standard is. But you also need to make sure that it works. You can't just throw output back, right? The browsers don't like that, right? You have to actually specify the content length of the output that you're sending back. That's the key important part of the HTTP protocol. What if the command is incorrect? You don't care, right? You're not in the business of verifying or validating or anything like that, right? You just try the command and you return the standard out. Should we kill the command ourselves if it takes too long or produces too much output? Good question. I would say let's not worry about that. That's probably a good test to make sure that you're actually creating a forking server, right? So that way you can service multiple concurrent requests. If it takes forever, you can just leave it. What if you wanted to delete all the files on the system? That could take a long time, but you don't want to stop that early. Cool. Yeah? Windows actually also will respect a host's file. You have to put it in some place completely different than I can remember. Anybody know? Like someone sent system files or something? It probably also other ways to do it on Windows, but I'm not a Windows expert. Anything else? Questions? Now's the time to ask questions, right? Because I can answer in front of everybody. When like 10 people come up after a class to ask questions, right? This is not a good sign that we've got all the questions out now. Can you imagine the test cases? So you want to be able to find all the hosts. That's really what we care about. So finding all the hosts, the individual test cases, that test different parts. So making sure you find all the hosts that we put in there in the specified file. So you want to be able to find all the hosts. That's really what we care about. So finding all the hosts that we put in there in the specified file. Cool, yeah. So for the SSH known host file, this is for just part two. How are we supposed to get over it? If the host name is like... If you can't read it and you can't... If you wouldn't be able to SSH to it, then yeah, you should just drop it. Yeah, you shouldn't worry about that. You're trying to do the best effort as much as you possibly can. If it looks like a host name, if it's a host name, you should return it. You shouldn't try to interpret it to try to understand if it's valid. Any other questions? Yeah? Hey, I can't hear the question, so... If there are any actual issues like... So in that scenario, we just return an add-on. I should keep going, right? Your only output should be the host names. That's your only output. Correct. You're just trying to see what that user can see. All right. Cool. So let's get back to our... Okay, so what was our goal? What are we trying to accomplish with ARP spoofing? What is this attack trying to do? Changing the ARP table name to... Yeah, it does, but what do we want it to do? What's the high-level goal? Yeah, we want to be able to snoop on traffic between two hosts on our network. Right, exactly. And the mechanism that we're going to use to do that is we're going to use ARP spoofing to tell each of the machines actually if you want to talk to that other host, talk to me. So that's our goal. What is this attack valid, guys? So why can we even do this attack? What is it about ARP that lets us do this attack? Legal broadcast. Yeah, it can allow illegal or... there's no authentication on the broadcast, right? So any machine can broadcast anything. What about the replies? What about the replies to our broadcast? What was it that hooked up the replies and the requests? Yeah, so the source IP and the source address, right? But really nothing. There's nothing that actually links it that says, hey, I made this request. I got this response. So the ARP protocol you can think about, there's no state there. You just broadcast, and then you get replies. And any time you decide to update your table. Specifically, this is the key thing. So part of the thing, why we're studying vulnerability classes is we want to understand kind of underneath these attacks, like why do they work? What is it that's key and fundamental about how they work? And so in this case, it's the fact that replies without a request will just be accepted. The OS gets a reply. It says, it's not keeping track of did I actually make this request? Do I want to know this information? It just says, oh, okay, well, let me update my table. So the basic idea is the attacker is going to send spoof ARP messages to two victim hosts. And the idea is it wants to put in their cache, hey, when you talk to victim A's IP address, send their traffic to my MAC address. And when you talk to victim B's IP address, send their traffic to my MAC address. And so that that way this host sends their IP packets to the attacker's host. And the attacker host then needs to act like a router, right? And make sure that these packets get forwarded properly. Because otherwise, right, if we just drop these packets, well, we've only hijacked one packet, right? We want to actually hijack that entire string between the two hosts. Okay. So we have our network, right? So are we considering networks of networks and internets and all that kind of stuff? No, we're just, exactly, we're just focusing on the subnet, right? This is an attack that only works on a subnet. So we have host A, who's at 192.1681.100 at a certain MAC address. And then we have host B that's at 192.1681.10 at another MAC address. And we're the cool hacker on host C, right? And you can tell that we're evil because we're wearing a black hat. So that's actually where the term black hat comes from. Not this diagram, obviously, but in general. Black hats are bad guys. White hats are good guys. It actually comes from like old western movies where like the bad guy always had a black cowboy hat on, the good guys, the sheriffs had like white cowboy hats. Alright, so the idea is we want to we want to hijack all traffic from host A's and B's. We want them to come through us because in a normal network switch environment we don't see any of their packets because it's not coming to our port. So in a switched environment, host A any traffic destined for the MAC address of host B only gets sent out on its port, not on host C's port. So we're never going to see that traffic. So the art table for host A looks like this. It has an entry in its local cache that says, hey, .10 is at this specific MAC address. And if they've been communicating, host B is going to have this exact same thing in its art table. It's going to say, hey, .100 is at this MAC address. And then host C, I know both of these, right? So I have all of these on the network too because I can broadcast, I can ask all of this. So what's my goal with these tables? What do I want to have happen? Host name, the mapping between the host B and the MAC address should be of host C. The MAC address for the host name B, that should be the MAC address of host name C inside the table. Right. So these art tables are linking the IP address to the physical MAC address. So what we want to do is we want to put on host A, we want to say, hey, when you want to talk to host B use the bad guys MAC address. And in host B we say when you want to talk to host A, use the bad guys MAC address. So we can do that by sending out an ARP reply to host A that says, hey, in case you were wondering, 1, 9, 2, 1, 6, 8, 1.10 is at this MAC address. Right. And ARP is stateless. So then what does host A do with its art table? Updates it. Just puts it in there, right? Changes it. But that's not it, right? So I still have to send host B because host B is still caching the MAC address. So I also send out to host B, I say, hey, here's, you know, host 100 is at this MAC address. And did these have any requests? No, right? That's the great thing. You send out these replies. So now what happens when host A wants to send an IP packet to host B? That's interesting. Was it? Yeah, so it's going to say, hey, I want to talk to host .10. Okay, that means I take my IP packet and I need to send it out in the Ethernet network on the subnet. Which host do I look at? Oh, I look at my ARP table. I already have an entry for it. That means I talk to this host. So that means that it's going to send this Ethernet packet to me and, you know, we get this packet. So what do we do now? Now we've got this secret data. Is that all we do? What was it? Send a normal reply to the host which was actually supposed to be sent to the host. Do we want to send a reply? Yeah, so we want to forward this actual message. Because we don't know how host B is going to reply. So we want to send this out. And, you know, obviously we don't want to use our own MAC address to send this out. We want to use the one that we have saved for host 100. So we say, yeah, here we go. Boom. Here's your message, host B. And what else do we have to change about this packet? IP. Do we change IP? I guess we did change IP. Okay, IP should be 100. Definitely. So we have this MAC address. We're making it seen as if it's coming from that other host. There's no authentication. So we saw in the Ethernet protocol the source MAC address is just specified as 6 bytes in the Ethernet protocol. Nothing else. That's it. So we can change it. We just send the packet out. And then host B gets it. And it thinks, oh, yeah, perfect. I got this packet from host 100. Time to, I got a reply. And so when it replies it's going to use this ARP mapping here and going to pass the reply back to host C where that host C packages it up and sends it back to host A. And now we successfully man in the middle of their traffic. You see this is a literal VR being the man the woman in the middle. All the traffic is literally flowing through us. And through that we can see all this secret dash, which is pretty awesome. The IP changes when host C is trying to contact host B. I mean, it is trying to send to the IP dot 10. But we are actually at, no, but we are actually at host C site 137. So this IP here? Like when host A is trying to send the packet to host B. Yes. The other, the MAC address is to host C. The IP is to host B. So when the packet be delivered to us, although the IP to the address changes. So the delivery right only has to do with the MAC address at this point. Because it's a subnet. Exactly. It's a subnet. So the switch says hey. Can we move to the next one? Sure. When the IP is 100, will it not update our tip because the internet is something else? This is an ARP. Yeah, I know. Actually, that's a good question. I don't think by default it will, right? Because then you're just updating on every single packet that you get. And probably a lot of overhead is my guess. So you know, you don't think, that's kind of the point, right? You're caching the ARP replies. And so you don't want to cache other stuff. So at host C at the back, should I do something in the virtual level? Because if I get a packet with the address, that is not fine. I should crop it. Yeah. So we'll actually see how to exactly set this up. There's a couple different ways. You can actually set your host C to act as a router. So that when it gets, it will accept packets from other IP addresses and then forward them on correctly. So that's actually the easiest way to do it. You could write a little program to do this. You could change your interface so that you actually give it also that IP address too. You could do that. And there's a lot of technical ways to do this. How long did the entries in the ARP cache stay? Good question. I don't know if the top of my head. But yeah, that's the purpose of a cache, right? It's only for so long in a fixed number of time. Plus for the network to be stable, right? You don't want these entries to just be updated all the time. Sorry, you wouldn't want these entries to just be permanently set in stone forever, right? And then as soon as something changes, the network crashes. I believe they probably will try it if they fail to send the packet. Maybe if they... Well, no, that doesn't make sense. There's definitely a timeout. I just don't know exactly what it is. Which actually leads us into the problem of that hey, occasionally when the cache fails, host A and B are going to send broadcasts to say, hey, how do I talk to 192.168.1.10, right? And then the legitimate host is going to reply back and then it'll update the tables and so the poisoning our poisoning is going to go away. So the idea is most of these tools will repeatedly send our replies. So that way you're actually making sure that that entry is fresh and in the database or in the ARP cache for both those reasons, right? So if it ever expires or if for some reason the host legitimately sent a reply, you want to make sure we're getting in there first. So these are kind of I think this is a good example going to show that some here we have an attack, right? Like theoretically it's actually pretty simple, right? It's like I've poisoned these other machines and their ARP caches, right? But there are a lot of other tricks that you want to use in order to increase the exploitability and to make sure you're persisting in this attack, right? And these have to go through how is this cache actually used? Not just a theoretical concern, but it's actually much more practical. Okay, so there's a lot of cool tools you can use to do something like this. DSNF is a collection of a bunch of network auditing tools. Actually, so DSNF is kind of goes to what do you do when you want to, when you have sniffing, what are the bad things that you can do? So DSNF has a bunch of programs that will look for and parse certain protocols to look for interesting usernames, passwords, emails, files, and it will automatically parse that and spit it out for you. And then it has other tools to do ARP spoofing attacks, DNS spoofing attacks, and it also can do active man in the middle attacks on the web or SSH. So it's a fun little suite of tools to play around with. EnterCAP is another one that is actually pretty useful for doing man in the middle attacks on lands and it has support for ARP spoofing attacks so you specify your source and destination and then you can say, hey, I want to intercept these two traffics. You can try to intercept SSH, SSL connections, which gets into how kind of trivial all this stuff is. So this is why it's so important that your software is actually checking for that the SSL certificate is valid, or that the HTTPS certificate is valid. I'll actually say an example. We did some research looking at Android applications and we found that a good portion of them they were using HTTPS to connect to their backend server, which is like, hey, also good. But then we saw that they implemented a method called I actually can't remember the exact name, but something about should it was a method that got called when an SSL error happens and a good percentage of the apps implemented that and then proceeded to ignore all SSL errors. So even though they were using HTTPS, truly you could just man in the middle and intercept that and completely own all traffic between that app and its backend, which could give you into the app. So it kind of goes to show that this stuff is really important because on a network, it's easy to think that we're on a trusted, as soon as you plug in your computer directly through a cable, right, that everything should be good and handy and safe, but actually we've seen it's trivial to do an ARPS booting attack. So with Enercap, these are some steps about how to do that. So you're trying to define hosts of how to poison certain groups so you can specify IP addresses to try to poison and then you set up, this is when you set up IP forwarding on your system so that that way any traffic that comes into you is going to be routed correctly. Then you start, you just start poisoning the machines, so this is going to listen to the interface, it's going to spit out all of those ARP replies right, hopefully poisoning the machines, and then you need to make sure you're collecting the traffic so that you're actually getting all of those packets and then later you can check this dumped up PCAP file. So should you do this on ASU network on wireless? No, no, no, no, no, no, shouldn't have taken that long. Everyone should have shaken their heads. No, no, no, I mean busy. But you can very easily set up your own network in a virtual environment, in a virtual box, you can set up two, three, four hosts, you know, you're at home and you get explicit permission from your housemates, also could be another thing to do right on your own router, your own network. It's kind of fun to play around with. So how do we defend against this? What are some ways that we can think of, do we go back and change ARP ARP protocol? Set a timer, after which you can accept another ARP reply. But what if I'm always faster? What if I'm sending it out all the time? It could be. I'm actually kind of curious as to why they don't do that by default. I'm going to say the same thing, but I guess a follow-up would be some kind of metric or something where if you're getting a bunch of requests on a certain one, maybe you disregard that one and look for the one that's unique. Hey, do you do some kind of analysis to try to determine how fast are they getting updated? When the MAC changes, we could authenticate with the actual host to see where the latest... How do you authenticate? How do you know? The only way you know how to talk to them is through the MAC address, right? Can I ask them for the... I think they're kind of expensive though, right? So when any of the attackers comes in the middle and he's poofing the new MAC address, so it's broadcasting, so the receiver... So the sender who has sent a message would also get the message, right? No, specifically, right? No, not the sender like the first host in, like host C is the bad guy, he doesn't broadcast, he replies, so he can target specifically those two hosts. So neither of them sees that their own MAC address has changed. And then the packets only go into the specific host, right? So the packets for C only is sent out to C's port and then he changes it so that it seems like it comes from A. But when they are updating it for the first time? Yeah, so this is an ARP reply. An ARP reply is a directed reply. It's not a broadcast. It does not get a broadcast. ARP reply would be the directed reply, but what about the ARP when you request? So when C would be making a request to get the MAC address of B, so it would be sending its MAC address of A, right? Or the IP address of A. We don't need to do any requests right here, right? We can go back and look at this, right? So we don't do any requests, that's the whole point is we can reply without ever making a request. So the idea is we reply to our host A even though they've never sent a request ever, right, for this thing. So over here in this reply, so when host A would be getting the reply, like this IP address is at MAC address this thing, but he can verify over there, like it's not the MAC address he's having that IP address. But what's the difference between But he can just send an alarm like someone is poofing on the channel. But how do we know? Because MAC address is changed. IP address is changed, right? That happens all the time especially in a cloud environment where you have machines coming up and down and you have different MAC addresses with different IP addresses. But over here when A is getting the reply it's getting the same IP but different MAC address. But that's a normal network function. That's why you need this, right? Can you incorporate the number of hops through the router and use that as like a tune sum? Can you use the number of hops through the router? You mean with this initial IP packet? This IP packet? Because when it goes to C it goes to the router twice. But who sends this packet? Yeah, but like they incorporate it in whenever A wants to talk to B, they incorporate it into the message that it wants to send to C. Right? Yeah, maybe you could possibly encrypt it, but by default, right? The time to live, post A, then send it to C. If C just trivially sends it back you will decrement the time to live again. But post C can always change that, right? And set the TTL as one more so it's like you never actually got there on the hops, right? That's going to be right back. I'll write a signature of an ARP spoofing attack, but what's the difference between an ARP spoofing attack and just regular updates, right? Because if you have to spoof someone's packet, then you have to send MAC packets like you have to flood the ARP you can't just flood your packet and send it one by one then it will be a regular communication. So if you have to continuously send an ARP spoof, that can be a significant difference. Yeah, that could probably work, but part of the thing for an IPS, right? So IPS is an intrusion prevention system, or an IPS intrusion detecting system, right? Where do those usually sit on a corporate network? Gateway, right? Usually at the end, right? That's where the graphic is coming into the network. Oh, I don't have to. I'm just talking like, let's say one machine is your web server, one machine is your database server, right? I don't need it, and we're on a separate network. So I guess it depends on where you have network visibility, right? Oftentimes organizations only have visibility on what's going in and out, but oftentimes not in between. If they're on the same subnet, they're not going to be connected to the gateway. They're connecting on the same switch, right? Gateway implies we're going to do hops, but here we're on the same subnet. Yeah? Whenever a replay comes in changing the MAC address, we can send a request to the previous MAC address before it closed. Does that work if they do change though? Yeah, then I think you have to update ARP to then include a way to verify that it actually did get. Whenever a packet comes to HostB, can you verify if the IP is coming from the same network expected to come from? So on HostB we can check, well this is a mistake. It should be from 100 to 10. So it's exactly the same IP packet. The only thing that's different is it actually came from our port on the switch instead of HostA's port from the switch. But everything else looks identical because we're spoofing that it came from that IP address, and we're spoofing the MAC address that it came from too. So the switch thinks it came from there. Let's go over there. Yeah, I think that's the easy solution that they should be doing, but for some reason they actually don't. Okay, let's look at some of the other ways. One way that actually kind of goes back to that, what if we just essentially disabled ARP and statically put in all the ARP mappings in all of our hosts? Would it stop the attacks? Yeah. But if it legitimately changes, it might be a problem. It would be a huge pain. How do you maintain something like this where every time one machine changes the MAC address, you have to go into all the other hosts and update their ARP tables to make sure that they're updated correctly. Yeah, this would be crazy. But one thing is you actually could do this, right? So maybe instead of saying, okay, yeah, that's crazy for the whole network, maybe we do that for our protected, our very important servers, our DNS servers, our gateway servers, our database servers or something like that. Yeah, other things, right? We can say we ignore unsolicited ARP otherwise. So that's kind of what we talked about, right? Update on timeout. So like, you know, updating on a timeout, like we said, so wait a little bit. These kind of prevent, right? But as part of the defense, what kind of things do we want? So we want to prevent, one way would be we want to prevent the attack, right? What else do we want to know about the attack as administrators of the network? Yeah, what would that be? Who it, or even before who is the attacker? We definitely would want to know that. We want to know that, what do we want to know even before that? Some information that's implied in there that we want to know. Was it? Yeah, that's kind of a symptom, right? So that's we want to know that that thing is happening, right? The motivation behind the attack probably, like what, what data are they trying to It's a little tricky because you're going to read their mind. No, we could see what data are being transferred. So what are the possible ways someone can attack? What are the possible ways? Yeah, but what about just the fact that we're under attack, right? If we have static entries, we will definitely probably won't be attacked. The attack won't be successful. But we actually won't know that we're being attacked, right? So actually as part of security, often you want to make sure you're protected. But in case there is a problem, you want to know about it, right? So that you can try to infer, okay what kind of damage did they do? What did they try to do? And then actually try to infer what was the motivation behind this attack? Was it just a random thing? Was it a rogue employee that was doing it? Was it malware on an employee's machine that was trying to do the network to steal our information, right? So the other thing to think about when you think of defenses, defense isn't just stop it or prevent it, right? It's also about can I actually detect it so that I know that something bad happened. So yeah, one thing would be, hey let's look at all packets, right? Let's look at the packets and try to monitor when this thing happens, when we have this kind of thing, right? So we could listen for art packets on a local interface and keep track of this pairs and then we can report suspicious, any kind of suspicious activity, right, or any changes in mapping. How can we detect? So what's a sniffer? What do you say a sniffer was? The passively monitors the traffic. Yeah, so passively monitors the traffic. So how do you even detect a sniffer? So what do we know that a sniffer does? Maybe we can use some of those traits to try to detect. Keep the IP address in, IP and the MAC address changes continuously. We're talking about just sniffers, right? So this is on a hub network or anything, right? So I'm not doing any art spoofing, I'm not even sending out any packets, right? So that's what passive means. So passive means I'm not sending out anything, just passively listening to everything that's going on. Encryption? Encryption, what do you mean? Whatever data you're sending, encrypted. Oh yes, we should definitely use encryption, yes. Oftentimes we may not have the choice, right? Maybe using a mail server that doesn't support encryption or something like that, right? And this is about detecting, right? So using encryption doesn't tell us if somebody is sniffing on our network. It just makes sure that they, if somebody is sniffing, they won't be able to know the contents, assuming that we did the encryption right and everything else is correct. The time to send the packets takes a lot longer than that normally it would. So what do you mean why? Because it sends through the router to the man in the middle person and then sent back out again. What about not even a man in the middle? Is that still true on a hubbed network? So that would be a way to detect if your traffic is being hijacked maybe, right? So you could try to see if, keep track of the latency between you and your hosts and if it changes significantly then maybe you're being hijacked or maybe your network's just slow. If someone is sniffing, that means to say they might be busy doing that activity. If you try to ping them, they might not respond because... Yeah, so that's one of the things. So what do we know about sniffing, right? So we first have to put our interface in promiscuous mode, right? And we're going to listen for traffic, right? Consuming more resources during that time. Consuming more resources. I mean that's kind of goes with the same thing, right? You're kind of inferring that it's consuming more resources because it's taking longer to respond to your things. So one thing, so if we're on the machine, we can actually just look. We can look at the status of our network interfaces and say, are any of my interfaces in promiscuous mode? So this is, I see it's not really readable here, but there's this promiscuous flag that ISConfig will tell you about if that is in promiscuous mode. So as an administrator you should know if your interfaces should be listening to all traffic or not, right? By default they should not be. So if you see this it means something bad could be happening. Is this it? I mean if you're on the host, is this it? You're done? What if they're inside your operating system and inside your kernel, right? If they put in a root kit in there they can easily, easily change this and completely say, of course, I don't know, nobody's sniffing here, right? So this is kind of difficult. We can look for if, so back to our closing attacks, right? So yeah, we talked about they're very noisy so we can detect that, we can develop a tool to detect that, right? We can look for, so suspicious DNS lookups, right? So we saw that TCP dump, if we use the, if we don't include the dash end flag it will try to resolve every IP address it receives into a DNS entry. So it tries to do a reverse DNS lookup and say who has this IP address and then gives the host name. So we can actually inject a fake IP address or fake entries in there and see what replies of what DNS entries are being, what DNS requests are being sent. So we can trap it in a sense so we can generate connections from fake IP addresses that aren't actually real, right? We can send that traffic out and then we can see if there's any attempt to try to resolve that name, right? So in this way we're using kind of some of the default behavior of the tool against the attacker because they try to resolve the DNS entries. And then we can also look at latency, right? This is kind of another side effect there. So the idea is if the NIC is in promiscuous mode, the network interface card, right? Then it's going to try to process every single packet by the program that's sniffing it, right? And so we can try to use ping. We can analyze the response time of the host of the host, right? We can try to see if it's up, what it's doing, measure the latency to see the time between packets. And then we can generate a huge amount of traffic to other hosts, right? Other machines on the network which shouldn't affect significantly the latency of host A. And if that latency spikes then we think, aha, we've probably found a sniffer on the network. We can actually use some, so this is actually where it gets really cool. So we can use some finger printing of specific operating system behavior and how they work. For instance, on Linux, when an interface is in promiscuous mode, the kernel will accept packets that have the wrong Ethernet address with the right IP address. And they'll reply. So what we can do is we can send ping's ICMP requests to that interface card with the wrong Ethernet but the right IP address and if we get a response back it means that that interface is in promiscuous mode and is listening. So this isn't the default behavior, but because it's special behavior that only happens when the card is in promiscuous mode and sniffing all the traffic, we can actually use this as a fingerprint to try and detect these behaviors. There's tools that obviously do this, so you don't have to go do this yourself. Yeah, these tools try to do all these techniques to try to determine this. But it's actually a pretty difficult problem and a lot of this you have to whether you actually want to do this in your network, I guess it's kind of an open question where you have to balance, well, what's the benefit of detecting somebody sniffing on the network versus what are they actually getting. That should really be thinking about encrypting everything so that way it's never going to be an issue if somebody sniffs on my network. You have to think of how Google used to in their data centers because they had private communication links between data centers and between inside their data centers that they didn't encrypt any of that traffic. Then they found out through the Snowden leaks that the NSA actually had a tap on all of their internal communications that they were using to suck up data. Then so Google decided, hey, great, we're going to encrypt all the traffic in our network, everything. That was a case where they didn't think they had a sniffer on their network and they probably could not have detected it by any of these means. It was only when they had proof that it was actually happening that they did something about it. The other way we can do it is try to control the network access. Part of the problem is that attacker C on host C was able to just plug his or her machine into the switch. Why don't we try and block that if we stop that there and so only trusted hosts can connect to our local network. Then now we can say, okay, it's probably unlikely to have some random machine or at least eliminate one threat vector of somebody randomly comes and plugs their computer into our local network. Is this true that they require physical access? I see some nods, I see some shaking heads. Anybody want to voice an opinion? Yeah? Do you need to physically be on the subject? Yeah, right. All you have to be doing is executing code on a machine on the network. Hopefully you also have made higher privileges to do some of these attacks. This is the threat of attacker comes in and jacks into your network. That's really bad. But even when you fix that by controlling the network access, you have to worry about somebody downloading some random piece of crap software or random app on their phone that actually goes and tries to sniff and stuff on the network. So the main way to do this is a standard called 802.1x which is a way to do port based access control. So the idea is your laptop basically you connect to the switch and then the switch says hey you need to authenticate before you can actually use this switch and send traffic out. And then you somehow present some credentials but depending on how your network is it's like Kerberos or Active Directory I think all that stuff is supported here. So once then you authenticate then now you actually can do this. Then you get network access. I was actually trying to think. I actually don't know. I wonder if the ASU encrypted uses something similar to this. Probably because you have to download your key file first or something by putting in your passwords and that kind of stuff. So anyways, this is a way to prevent so that that way random people can just jack in and get access to your network and be able to do ARP spoofing attacks and all kinds of cool stuff. Alright, we got one more minute. Are there drive by download attacks under this category? So this are there drive by download attacks? Yeah, when we try to open Wi-Fi. Oh, okay. So couple terminology things. So accessing open Wi-Fis is usually called reward driving. Yeah, so that's accessing open Wi-Fis. Drive by downloads are when you visit a page on your browser and the JavaScript on the web page takes advantage of either the... Anyways, it exploits a flaw in your browser when your browser plugins to get code executed on your machine so you have some malware on your machine. And actually these kinds of attacks like ARP hijacking, right? If I hijacked your HTTP connection, I can inject some malicious code some malicious flash object, some malicious flash file in there and so that way you get that. I can do a drive by download with like an ARP spoofing, ARP hijacking across. Cool. Alright, we're going to go, we'll do IP spoofing on Monday so we'll look at how we can do this and then we're going to go into how we talk between subnets, right? So how our traffic actually leaves our subnet.