 All right, welcome to class. Monday, what was it, 23rd? A little loud, a little loud. Okay, well something's weird. I don't know, are you having a good act? Good. So, we are going to get started. So last week we went over the history of software and security, so we looked at notable security breaches and notable actors. We also talked about ethics. Ethics is incredibly important in this class. Don't do anything stupid, don't go to jail, don't do anything illegal. Only hack in and break into something that you don't know where you have permission to do so. Any questions before we get started? All right, we'll start right in. So the first, so this course, we're basically going to cover very broadly three different topics. We're going to first start off with network insecurity, so we're going to look at different layers of the networking stacking. We're going to study how can we break and override the security of the network itself. Then we're going to move up to the application layer, so we're going to look at binaries and see how can we exploit and what are possible vulnerabilities in binaries. So we have the application security, and then we'll go to the third one, which I can't remember, web insecurity, so we're going to study the web and understand and look at all different ways the websites' web applications can be insecure. So that's going to be broadly the three topics we're going to cover. So why do we care about the network when we're studying security? It's the first point of anyone in the back? Yeah, it's really so, is maybe you've heard this joke, what's the say of this computer? Thank you. It's all a joke. Yeah, so what's the say of this computer? Well, it's turned off in a room that's locked, that has a lot of garden on it. So yeah, so using the network is how applications talk to each other, it's how users access applications, and this allows hackers and attackers into our systems and into our networks. And so it's critical to study and understand, okay, how does networking actually occur and what areas can an attacker maybe compromise that to take over your systems or your data, your network? Okay, and very broadly, we're going to go on a crash course. So who very deeply understands all of the networking stack? Like the ladies. Yes, but everything about all the layers. Kind of. Okay, so part of studying security why I love it is we have to study things in depth and we have to study where all the layers interact. So we're going to get a, you're going to get a crash course in the networking stack. If these things are unfamiliar to you or I'm saying things that are crazy and you don't know what IP or networking is at all, you should review and look these things up on your own time to supplement what we're going to go over here in class. So the IP suite very broadly, we think in the set of protocols that's going to be used to transfer data between nodes of a network. We kind of broadly preferred the whole thing as kind of TCP IP. So that's kind of this shorthand term that we use for this. We're going to see and those of you that are studying this in the OSI model, you know, you got these nice model of beautiful of how all the layers work. So each layer does different things. You're going to look at that. We also have link level protocols. So these define how, for instance, over a specific physical link, how things stop to each other. So we kind of are going to generally group these into link level protocols, so the physical protocols. Above that, the internet protocol. So how do we actually get a packet from one network to the other, right? When I send a packet for me at Google.com, how does it actually get there? Transport protocols are helping that process and application protocols are really kind of the high level thing that we'll be talking about. So we can kind of, I'm sure you say, now we're getting seeing this stack at the very bottom layer. We got the physical layer, right? So how does, for instance, my laptop on the Wi-Fi talk to the Wi-Fi router, right? That would mean that's a one connection. They're talking to each other over some physical medium. In this case, it's wireless signals and I'm not a wireless person, so I don't really want to get too much of that. When you plug in an ethernet cable into your computer, your computer's talking to the end of that cable over ethernet. So this would be the physical layer. Above that, we have different things to make the link level work. So how does, so your hardware interface, your mid-card, how does it actually talk to other things on this network? And we'll see. Above that, we got kind of the internet layer, Broadway as we're calling this, some kind of IP in there. Above that, we got two different transport layers. We'll talk about protocols TCP and UDP. And finally above that, we finally get all the applications that we know and love. So HTTP is web, what's SMTP? Email, right? Simple mail transport protocol. And we also have DNS. So what does DNS do? Yeah, domain name, right? So it resolves the name of your browser into an actual IP address that you can talk to. What about NFS? A lot of us people. Yeah, network file share, right? So this is how you can share files on a network. Very broadly. So I'll share fun facts. When I took networking undergrad, we had to name the whatever, five or seven layers. I got all of them except for the last one, which I can only remember started with a P. So I put the pizza layer. Unfortunately, that was not correct. It's the physical layer. But it's very close. I feel like I may have got a smiley face. I don't know. So IP addresses. So every host on the network has an IP address. And for now, we're gonna kind of ignore IPv6 because I kind of add some complications here. We're gonna focus only on IPv4 but a lot of these have little concepts of life. So what would be the analogy of the IP address in sending, let's say, a piece of mail in the United States? So I want to send a mail from me to ASU or somewhere else. How does it get there? What do I do? What do I have to do? So somebody, has anybody sent a piece of mail in their life? Can you drop it off at like a local postal service? Yes. But what do you drop off? Let's have a postcard. What's the letter with the information on it? What kind of information is on it? Add address, two addresses. So what's one address? So the address would be the recipient's address. Is that all you put on there? And the sender's address. The sender's address, right? So the destination address, the sender's address. Why do you put the sender's address on there? Because it's the wrong address. Yeah, so if something goes wrong, they know how to send it back, right? Or maybe that, what if you send it to an address that doesn't exist, right? Because that piece of mail doesn't go away. So, similarly to physical addresses, right? The building that ran, I had no idea what the address is, but I know we have an address and if you took out your phone, you'd find it. The break yard where my office is is 699 South Mill Avenue, right? That's the physical address of that. And similarly, every host on the network will have an IP address. And we'll go into more details about what these things mean. So IP addresses are 32 bits. So how many IP addresses does that give us? Two to the 32. Two to the 32, good. It's like four billion something, something, something? No. No? You just put it on two million. What is it? About two million? No, it doesn't matter. Okay, so it's two to the 32, right? So we have this many bits. This is how we can address other nodes on the network. And it should be very familiar to you. Hopefully you've seen this decimal dotted notation. So this means we split that 32 bit integer up into the first eighth bit. So the first byte is the first number. So it's gonna be anywhere from zero to 255. The second one's zero to 255. Second one's zero to, or the third one's zero to 255. The fourth one's zero to 255, right? So using this, this is kind of a quote, quote, human readable way to represent those 32 bits rather than just having the straight number, right? You just take this and turn it into a decimal number, whatever that 32 bit address is, but that would be very hard to understand. Okay, but the other thing that this gives us is these network IP addresses aren't just random, right? You don't just get assigned some random 32 bit number. We actually have different classes of network. And this is a little bit of the older style which is class based routing. So the idea is depending on the first, in this case it was class A, seven bits, 14 bits, or 21 bits, that would tell you what network to go to and then the remaining bits would tell you what host within that network. So this was the original kind of way that IP addresses were done. Your network had to be within one of these classes. Unfortunately, the drop back here is, here you have either two to the 24 hosts, two to the 16 hosts, or two to the eight hosts. That was all you could get. And so this proved very inflexible because you'd be a small, some network organization, you'd get two into the 24 hosts which you could never possibly fill. So you have this unused IP address space. So then they came up with this class list routing system where instead of every network kind of fit exactly in one of these things, blah, blah, blah, IPv6. So yeah, so part of the problem here is two to the 32 sounds like a lot of hosts, right? But once you start splitting them up into chunks of two to the 24 or two to the 16, right? You lose and you get a lot of waste in there. So, and as all of the number of devices that we have are exploding, right now we need kind of a more fine-grained way to define classes. And also we are actually, eventually you want to completely switch protocols to IPv6 which has 128 bits for addresses. But here you have two to the 128 bit addresses that you could use. So the size and number of addresses we can have increases a lot. Okay, so Sider, the important thing here is we can place the network IP and host IP boundary on any bit in between the 13th bit or the 27th bit. So you can have a network that's as small as 32 hosts. So if it's all the way in, or 27th, it was on the 27th bit, or you can have 524,000 hosts. So this gives networks a lot more fine-grained learning and clarity in how they allocate IP addresses. Okay. So IP, we're gonna look at IP first. So IP is really kind of the glue of the internet. So it provides the other important things around that. Connectionless, unreliable, best effort, datagram, delivery service. All right, so this means, so it's IP, we'll try to get whatever you send from your IP address to a destination IP address. But it offers almost zero guarantees. Right, we can see here, it's connectionless, what does that mean? Right, so we don't connect directly to the IP address that we wanna talk to. If you think about, you have two to 32 hosts on the network, how could they just all directly talk to each other, right? So we definitely can't do that. So we don't connect directly to the host that we wanna talk to. What about unreliable? Yeah, we have no guarantee, we have no idea. We just send something. We don't know if it's gonna get there. Best effort means, well, it's gonna try really hard, but it's not gonna guarantee that it's gonna get there. Does it seem like something you wanna build an entire multi-billion dollar economy on? Yes. Why yes, because it is. Here's your proof, currently it is. So what's the positives of these aspects? What was that? Speed. Speed, who's saying that, I can't. Okay, sorry about all your sounds. I think you heard the sound from here, okay. Yeah, so it can be fast, right? So because it doesn't guarantee it's gonna get there, but maybe it can be faster, what else? Easy to implement. What was that? No-overhead. Easy to implement, it could be easy to implement. What was that about? No-overhead, less latency. Less latency? Yeah, so maybe they can get packets up there quicker. Topology doesn't get prudence. What was that? Topology, among the hosts, it doesn't get prudence. Yes, so topology doesn't get prudence because you keep splitting into stuff into their own network. Cool. What about non-unreliable? I feel like it's a very negative term. Are there any pros for being unreliable? You're unreliable, you're an awesome person. You're not locked into a bunch of transactions. What was that? You're not locked into a bunch of transactions. You're not locked into a bunch of transactions? Do you mean? Does it give you more flexibility? More flexibility in what sense? Yeah. Very good for heartbeat, like when we send the heartbeat to others on this. Yeah, so kind of all these things are saying similar things, right? We make, the IP is in kind of the middle layer, right? We're writing applications on top of that. Maybe our application doesn't need to be reliable, right? If you think about a phone call, like a Skype call or a VoIP call, right? If I'm talking the most important thing is that that packet gets to you quickly, that voice packet, right? One of those packets ends up getting dropped, but whatever it might, you'll hear maybe a little pickup or you won't hear any difference at all, right? And so, but now if I'm making a payment to my bank system and I'm saying transfer a thousand dollars from my account to somebody else's account, I'd probably want all of that packet to that request to make it there, right? And so the idea is that you could build the reliability on top of these other protocols. And so for the IP layer, we can keep it more simple and we can allow different types of applications to be built on top. I think I can choose. Do they want to have deliverable? Do they want, well, integrity is also an interesting thing. So there's also no guarantee that when I send something, you're gonna get the exact same thing. There's a great long post a lot of backgrounds. Somebody debugging a SSH connection error from one post to the other. They would find that it would crash every once in a while, like a connection would get terminated and they did a lot of digging and they found out that one router was flipping one bit on all packets to always be one. And so the other side would get it and they would get that sink and so it would blow up. So yeah, crazy stuff can happen in the network but the protocols don't guarantee anything. And the other cool thing, this is the core feature of IP. It guarantees that if I have an IP address, I can send a packet out to somebody else's IP address and it will try to get it there as best they can. So for direct communication, when we're talking, when you're talking directly to the next hop on your network, there's a lot of protocols I go into here and we're not gonna really go into there. I highly recommend, especially for those of you that want to be security professionals and security people, you have to start reading RSCs. Do it for fun, do it because it's awesome. So RSC 791 describes exactly what an IP datagram looks like and this is very cool stuff. There's no magic in here, it's all laid out. So there's first four, so this is bit zero to 32. So the first four bits are version number followed by a service type, followed by the length of the packet that the IP diagram is going to send, followed by some identifier, some flags, a fragment offset as we'll see in a second, a time to live field, a protocol field, a check sum, a header check sum, so it does have some type of error correction things in here, the source IP, the destination IP, important thing in here, you can already kind of design this in your head. These have to be 32 bits. We're sending from one IP address to another IP address and so they each, just like when we're filling out a letter, we have to put our address, the source IP address, and the destination IP address. Why is source IP address important? What was that? Almost like, like if a network, it's very soon recognized. Actually, if there is an error, it has to send it back to the sender. Yeah, so errors just like on the post office, what about if I send you a letter and I said, well, I'm giving you $100, but I don't put a return address. Are you gonna be able to claim your $100? No, because you don't know where to send that letter response back to to say, yes, I want this money, please transfer it to this address, right? So this means that the node that's getting that IP address that IP packet can reply to it, right? Because it just needs to reply to the source IP address. There's an option field, there's padding, which will make sure that we don't do 32 bits. And finally, we have the data that we're gonna send in the packet. So, some interesting things in here where things kind of start to bleed. So what's the time-to-live field? It kind of sounds very cool. It sounds like James Bond or like 24. It's like two hours. How long does time-to-live do you have? How long to wait for a response for like an endowment? How long to wait for an endowment? Not quite, yeah. Is that the number of cops before it expires? Yeah, so the idea of the time-to-live is every hop. So if you send it to your router, that router sends it somewhere else, that router sends it somewhere else. Every router will decrement that time-to-live value by one. And when it reaches zero, then they just drop it on the floor. So why is that handy? What was that? Increase traffic. Increase traffic? Session five. Loops. Yes, it's the network ever gets in a loop where I'm toward either over here, the person towards the here, towards the back to me. Right, we mentioned a network loop. Otherwise this packet will travel forever in just part of our network. Right, so with the time-to-live value, we know the packet will die at some point. And the other thing with other uses, so usually, well, sometimes, depending on the configuration of the router, it will send a message back to the source IP address that said, hey, I dropped your packet. Sorry, blame me. So that way at least you know and we'll see that actually comes in the play. The other interesting thing here is we have a protocol field. And this protocol field actually defines what type this data is. Which is kind of this weird blurring of the IP layer and the other layer, other layers on top of it that we'll see. So normally it'll give up 20 bytes. So we have version of this set, the header length. So this specifies how long the header is because they have additional optional fields that we can put into the header. A TOS, so a type of service, which is the first three bits are priority and quality of service. These are pretty much never used. Right, so they thought it was a good idea. And, but copy you, who's gonna say whose traffic is more important than other people's traffic? I've heard that the military network uses these flags for different types of confidentiality. But I don't know though, that's 100% true. So don't go on it, but do look up to check. The total length, so we got the total length of the diagram packet and an ID, which is the unique identifier for the diagram. So we'll look at this in a second. So the important thing here, total length means we can send the letter that has at most 65,535 bytes. It's pretty long letter, right, in one IP packet. So we have flags, different flags, and an offset, which we'll talk about in a second, time to live, protocol, check sum, and finally the addresses. So there's options. So these options can have different security things in here. It used to be that you could ask every packet or every router on each of the ops to put these little timestamps that said when they got it and who they are into the option field. So this way you can see when the packet got there what route it took. They've sent basically to disable all of these things because if you're running a network, you don't want people who you're running traffic on to know how your network works. This is an interesting one, the source route. So you used to be able to say, hey, I want to talk to this other IP address, and what I do is send it through these routers so you can specify the path that I can take. Why would that be a good thing? What was that? Yeah, maybe I know a really good path to the network to get to that other system, right? What's the bad thing? Increase the traffic. I can increase the traffic to one particular router and kill it, right? So I can force a bunch of traffic through this router and it's not designed to handle that, right? And so this is one of those things where they thought, oh, this would be a cool, flexible feature of the network and they end up not doing this anymore because it introduces security problems. Lots of other to read the RFC of your internship and all these other optional fields. And so the IP gets our traffic from one node to the other. We'll see exactly how this is done. So the IP packet though is encapsulated inside a physical frame. And so that is going to have its own frame header and the data of that frame will be the IP packet, right? And the IP packet, the data that's inside the IP packet will be another protocol that has its own header and other data that we'll see. So how do these packets actually get from one node to the other, right? That's kind of a key question we want to think about here. So the first, so what are the two scenarios? Well, one would be that IP addresses in some completely different network, right? Google.com is not in my local network. So my packet has to multiple hop multiple routers get from me to Google.com. The other option is maybe the computer I'm trying to talk to is on my local network. Maybe I can talk to them directly. So that's where directory delivery comes in. So if we're in the same local network, then I can just deliver it directly. So this is where we get into that side of routing. So the idea is if I'm on this subnet, let's say 11, 10, 20, we have this machine. So we have a machine at 11, 10, 20, 121 and another machine at 11, 10, 2014. So how do I know just from three pieces of information, the subnet and the two IP addresses that these are on the same network? I didn't see any. Exactly, so by the class list routing, right? When I say this is the subnet, I mean, this is the network and everything that is gonna be host on that local network. So this means everything here from 11, 10, 20, one to now 254 will be on the same network. So we have IP addresses here, but they actually need to talk to each other. So there's another address they have, which is a physical address, right? So this is, in this case, would be the Ethernet address or essentially the MAC address, right? So that's the term used for that. So the idea is I'm dot 21. I want to send a message to dot 14. The first thing I ask is, hey, is this host on my local network? I compare that on my routing table rules and see, oh, I'm on this subnet. Yes, that host is on my subnet. Great, I don't need to talk to anybody else. I can talk directly to this host. And so we want to send the packet from 20.121 to 20.14. Now, the problem is this is the IP packet, right? So the IP packet says this IP wants to talk to this IP address, but we're not talking over IP. We have a lower-level protocol here, right? The IP packet isn't the one that gets sent. We have a lower-level protocol that's fraying this link layer protocol. And so here I have the two for MAC addresses. I'm not gonna say I'm gonna start with nine and I'm gonna start with eight. So the idea is 121 needs to essentially ask, hey, I'm trying to talk to dot 14. What's the physical address of dot 14? And somebody will say, oh, OA. And then they'll say, great. So then it'll encapsulate that IP packet into a link layer packet that says it's from O9 to OA. That will get sent across this network and it will eventually get, not eventually, so it will get to this machine. It will look at it and say, oh, this is for my MAC address, great. Oh, it's for my IP, awesome. This is the packet meant for me. So we look at the internet frame to see exactly what it's doing. So we have six, we have, wait a minute. This must be in bytes. Six bits is not enough for that. Okay, cool. So we have the destination MAC address, the source MAC address. So just like before we need to know how to get back to each other, the type of packet and the actual data that we can send. And finally, a CRC, so we'll check some so that we can try to identify any errors. So if the type is 0800, it's an IP diagram. It is 806 in hex. It's an ARC request. And it's 808, it's reverse ARC request. So how much data can we send in an Ethernet frame? Yeah, 1,500 bytes. How much data can we send in an IP diagram? 65,000 bytes. Huh, seems weird, right? We'll deal with that later. We're gonna keep going with Ethernet. So Ethernet is a web-based link-layer protocol. Has all kinds of nice features. The addresses are all 48 bits. They are different types of requests. So you can send at least 46 bytes and at most 1,500 bytes. And it has a CRC check, which can detect very simple kind of bit flip errors and crackdown. But they're gonna get funny, I mean, each layer doesn't promise reliability on this stuff, but they have all these features, like checksums and CRC values, just to try to improve the reliability at each level. So the question is, how does .121 know how to talk to .14? Just like, well, I'm not there yet. Just like on DNS when you type in Google.com into our browser, we know from what we've just seen, my computer needs to send out an IP packet to some Google server. So it needs to know, how do I translate this name to this IP address? We talked about it uses DNS. Similarly here, we need a mechanism to turn an IP address into a physical address, a link-layer address. And so that is where ARC comes in. So ARC is the address resolution protocol. It basically, this is its job, it's a protocol to allow mapping of IP addresses to link-layer addresses. It's kind of weird, right? You think about, it's now, this is what I'm saying, that there's not this beautiful separation between all the layers, right? Here we have a protocol that translates between IP layer kind of to link layer, but how do we send these messages out? We have to develop another layer below that, and so they kind of use the link-layer to find how to do this ARC thing, but it's a link-layer. How should it know what IP is, right? But it kind of has to to make these things actually work so. This is when we start getting down to the details, you can see that these beautiful abstractions start kind of breaking down. Okay, so host A, so our host A wants to know the physical, the hardware address associated with the IP address of host B. Remember the machines only want to talk to each other about IP addresses, right? So basically host A says to everyone, broadcast to everyone on the network, says, hey, who's got IP address B? And then host B will be reading those messages and read that and go, oh hey, I'm host B. And so it will reply directly to that message to say I am host B and I can be found on this MAC address. And then host A will cache that response so that it doesn't have to keep making these requests. And to optimize things is a little bit of a improvement here. When host A sends this request, it includes its own IP address. So this way people listening on the network can see who's has what physical address is, right? So essentially host A says, hey, I'm host A on physical address foo, who's host B? And host B will listen to that, cache store foo host A was, that it's on physical address foo and say, hey, I'm host B, I'm on physical address bar. And now they can actually both talk to each other over their local network. So messages, hardware type, a protocol, a hardware size, a protocol size, and the sender ethernet sender IP, target ethernet target IP, right? So this is another one of these blurring of layers, right? This packet, I mean the format of this frame uses IP addresses even though it's in a link level, right? Which is technically a higher level protocol. The option fields specialize into requests or reply. The sender ethernet IP and the target ethernet in a request is empty and the target IP is the requested IP address. So you can actually do this on your own if you're on a network. So you can run this Arc-A command which will print out basically your ArcCache. So if you Google, there's a way to flush this from your cache so you don't mount anybody's MAC addresses. So the idea is we have 192.168.1.100 and 192.168.1.10, they wanna talk to each other, right? And so host A, you can use the pain command which we'll get into exactly what that does so that essentially sends an IP packet from .100 to .10. And so I'm looking at this traffic so this is the TCP dot dot of the traffic here. We can see that, so 8046, so it starts at eight. So host A's physical address sends out an Arc and Arc who has, so who has .10 tell .100. And so that's the Arc request getting sent across in the local network. Host B will reply, so this is from zero to eight. So what's all these Fs? What was that? Somebody wanted to raise their hand. Yeah. Is it black or empty? Almost, kind of. Black, broadcast requests. Yeah, so it's all ones. So we've got Fs, it's all ones and that means it's a special address that means send this to everybody on network. So everybody is listening for these requests. So they get an Ethernet frame from somebody with all Fs or somebody to all Fs, they will read it. Cool. So then we have one, the MAC address zero, sorry, zero sending to eight and reply and say, hey, 192.168.10.10 is at zero. Which now the Arc reply gets sent. And then we can see the echo packet is in here. So this is an IP echo packet, we just have pain work, we'll end up in a second. But we can look at the Arc cache and we can see that now post A has cache that B is at that address. Cool. And post A has cache that 100 is at that address. So they actually both get to learn each other's addresses. Questions on this? We're going to talk about how to hijack these things. But for right now we need to understand the basics, yeah. Is the host C going to save the MAC address and the IP address in this cache? Maybe. Depends on things we're going to talk about next. Yeah. I think I understand what the Arc is. What's the 60 colon? The 60 colon that, let's see, we have to go back here. It is one of these values. I don't know what it wants. I'll stop ahead. It would be like a separate port number. It doesn't have ports at this level. It's because Arc request is requested from transport there. No, no, it's that Arc is at the link layer. So this is an Ethernet frame. So there's no transfer level things above it. It's probably one of these, either this, not the off field, maybe the size. It could be the size here or the vertical size. I don't know, how are you going to be able to get that? How will the host update their cache if the IP address has changed? Ah, so, that's a good question. If the IP address, so the IP address changes, then you're not talking to the same machine, right? Your connection will drop. So dot 10 decided to change its IP address to about 20. If they never tell host A that, then host A will never, can't talk to that machine anymore. But if, so, that would be one thing. The other thing would be if host B changes its MAC address. So host A would probably try talking to it, not giving it a reply and then do our thing over again. The cache will also invalidate after a certain amount of time to do it. But that probably doesn't exist with dot 10, yeah. Is that why all this gets dropped sometimes if you're like roaming? Like, would you be like changing radio towers? Because that's not the thing for them. Yes, calls also can get dropped when you're roaming because your IP address may change when you get through the tower. So it may not necessarily be the MAC address changing, but yeah, you're basically essentially detaching from this network and going on to another network and attaching yourself. So you get a new IP address, yeah. What happens with multiple machines that the static IP address makes? What happens with multiple machines get the same IP address? Does anybody face the situation? I can't see it. It's nightmare. It's one of the worst problems you've ever had in a network. I've done this with some research stuff. It would be insanely. You try SSH-ing to your machine and it would work and then you exit and try to do it again and it's a key fail. And you keep trying it and sometimes you get it. So yeah, you basically, whoever wins on the awkward play, that's who most people start talking to. Yeah, it's, yeah, it's horrible. I don't wish that on anyone, yeah. So in that diagram, all three machines, most A, B, and C are connected physically or they are connected to one router and it's a big complication. We'll get that in a second. They're either on a switch or a hub. So you can think about there, are ethernets plugged into either switches or hubs. That's kind of all we're getting into right now. We're gonna get into how those work, but essentially you think that they'll get all those packets, the link layer packets will lose all machines. I see them. I see them if people get to it in a second. What PING uses to talk to other hosts. So it's just an IP level for them all. Arp-dutch-A is showing host A's Arp-cache. Okay. And then why do we want to go for PING? To show that it actually gets, it didn't know it before, which is why it has to do the Arp-request. And then after there, it's the entry for B is in host A and the entry for A is in host B. How can you get two hosts with the same IP address? Does that mean that if I know the IP of Google.com, I can have a host with that IP address? So the important thing to remember is right now we're talking only on local networks. So for this local network, you need to configure every machine to say, this is your subnet, so this is when you talk to locally. And this, well, and this is your IP address. This is either done dynamically through DHCP. So when you first plug your computer into basically a router or when you connect to that ASU wireless, you send a message that says, hey, I'm new here, this is my physical address, I need an IP address. And then the router will listen to that and give you an IP address and say, great, you use this. The other way to do that is to statically assign each host an address. So that's part of configuring and hosting and those V is saying, okay, this is your IP address, this is what's subnet you're on. So how does it happen where two can have the same IP address? We, I think it happened for us when we ran out, we had too many hosts on our network and so the DHCP started reusing IP addresses or when we had static IP addresses that were in the range that DHCP would use. And so eventually it would get to those and everything would fall. ARP, ARP is IP link layer blue. Is there any questions? I think I didn't answer a question. Couldn't you be a little crazy? A little crazy. So all of these things necessitate that we are on the same local network, right? Local network is defined as whatever is on your subnet. So for the site or list routing, the site you're routing, whatever is inside your local network is a host on your network and you can talk to. So it's important if you're ever trying to demo weird networking issues or trying to set up complicated networks, you can understand each host on its subnet if things are going to talk to any host on that network. So we'll imagine this scenario that these are basically, so the key kind of that we've all been talking about is how are all three of these computers able to talk to each other? So there's two main ways this happens. One is either through a hub. Does anybody actually use the hub or my hub? What's the difference between a switch and a hub? I remember correctly that a hub just rotates around to each of the computers where I just switch to the green model at the same time. Almost, right? Yeah. I think it has packed every machine on every PC, whatever on the network it is, which does it based on that. Yes. So I think you're trying to, almost looks like a token-raining network thing, which I don't remember all the details about. But so a hub, any package that comes in on one port, so you gotta think, I don't know what you're saying. Yes, it does. Yeah, any package that comes in on any one port, it sends out to all the ports. Right, so it's essentially any package that A sends would also go to B and C. What a hub is, there's a very technical difference between hubs and switches. All I'm pretty sure now, almost everything's gonna be switched, yeah. Because one hub is one collision domain. What was that, today? One hub is one collision domain on a physical layer. Yes. Which separates the collision layer. Exactly, so you'll get a lot of collisions that happen. What would you use a hub and what would you use a switch? Hubs are cheaper, I think, is the real answer. They're probably worth cheaper, I'm sure now they're... So like a technical reason you'd use one of those? Not as my knowledge. That's probably failure? Maybe, although, I don't know, I've been around in switches very early today, oh yeah. Couldn't you use a hub's achieve network type? You could use, well, yes, we'll get into that. Yes, you could use it as a very cheap, so if you wanted to, I'll say, listen in on all of the traffic from A and B and B and C, you can plug into the fourth port here and see all the traffic that's coming across there. So a switch, the difference is, a switch is listening to all this traffic, it's building up its own ARP table internally. So except it's not mapping IPs to MAC addresses, it's mapping ports to IP addresses, sorry. Physical ports on the router, sorry. Physical ports on the switch to MAC addresses. So for instance, when it sees a MAC address, a link layer packet from most A with that MAC address, let's say that's on port one on the switch, it'll say, oh, I know that this MAC address is on port one. And it's gonna send a broadcast, so it will send that out to every packet, every port on that switch. When the reply comes back, the first thing it'll say is, oh, this means on port three, this MAC address is there, and it looks it up in its table, this is a, sorry, I keep saying packet, I believe I mean frame. This is a frame, an ethernet frame for zero eight. I know that it's only on port one, so I'm only gonna send the packet there. So it keeps a mapping of physical ports to MAC addresses so that once it knows that host A, host A's MAC address is on port one, it won't send ethernet frames to any other port except for port one, is that make sense? So then you get rid of some collisions that have a lot of updates. Okay, this also applies to the attacker of talking about also applied to wireless networks with some caveats that we'll try to get into when we can, but it's helpful to think about these kind of just wired local networks. Yes, it doesn't have one. Well, the switch generates some sort of error to send it to because it doesn't do it. If it doesn't know a port, it'll send it to all of them. Okay. So it defaults into basically a pub like behavior if it doesn't know. Okay, so now, even with that very quick brief amount of information that we've studied, we can talk about attacks that we can reform against the local network. So what do we want to do? So you're on a local network, let's say you've plugged in or you've taken over a machine on the network, right? That could be either scenario is valid. What do you want to do as an attacker? Gain information. Gain information, what kind of information? I'll just read the address to this, like the architecture. Okay, I may want to do some reconnaissance to look at the architecture of the lab of the network. See who's, based on what he says, see a post-plugging network, who had the address in the LIDI for you to get their information, MAC addresses, who had the address? See other IP address, see other MAC addresses. What do you want to do to your network? Yes. You want to deny traffic to a particular host? Yeah, maybe I want them to deny traffic. Maybe there's an automating machine that's constantly looking at traffic. Maybe if I kill that, I didn't want some other attack at their website or some of the system. What else? Let's go to someone else who hasn't talked yet. In the system, pull it. Yeah, I may want to intercept their traffic, right? I may want to see what host A is sending to host B, right? What if those are credit card transactions that are getting sent over the local network, right? I'd love a fall. A bad guy would love it. I'd like to overload a certain host with another service. Yeah, so you can take a host off the network. You can steal data. What else? It must be put through. I may want to pretend to be another host, right? I may want to have people think that I'm the database server, so they talk to me and send me all the data instead of sending it to the real database, right? Anything else, Dad? After intercepting their units, that's the one. Yeah, I may want to not only intercept it and steal it, but maybe I want to alter it and change it as it's going across, right? Yeah, all kinds of nefarious things that we want to do. We want to maybe, in first data host, perform another service attack and access information, right? And so, this is actually one of the things that we think is normal. When we went back to the first day, we talked about security, right? What is security? Confidentiality, integrity, availability, right? So the denial of service and its availability, being able to sniff traffic that should be secret is confidentiality and being able to alter data that you shouldn't be able to alter would be integrity. And so, there's going to be various ways we're going to do this. One of the ways we're going to do this is basically three techniques we're going to look at. Sniffing, spoofing, and hijacking. So in the case of sniffing, we're actually listening to all the packets that are coming across on the network. In spoofing, we're going to pretend to be another host and try to inject traffic into the network. And in hijacking, we're essentially going to try to demand a little type of thing where we're going to take over a connection and have all the traffic flow through us. Okay, hubs versus switches. We covered this one already. Early switches, early hubs. Hold on. Early hubs, all traffic broadcasts everywhere. Modern switches keep track. Basically, we'll be ending questions on this concept of switches. Cool, so now this does become important when we try to think about how, what can be, what data and what information is being sent to us on our board that we hear about. So, one of the things we can do on the local network is just listen and see what's happening. So this is network sniffing. And this technique, and part of the reason why we covered this is because this is really important when we talk about exploiting applications over the network or when we talk about web applications. Actually, looking at the traffic and seeing what's really going on is an incredibly effective technique. And so, a lot of the attacks we're going to look at start with sniffing, right? So sniffing, in essence, is being able to look at and see the traffic that's getting sent to a machine. And it's actually trivial. This may shock some of you if you're not familiar with how insecure everything is. This is trivial to do. You can do it. I can do it on my laptop. You can do it on your computer's turtle. You set your network interface to promiscuous mode. So what this means is that your OS, your computer is telling the network interface, listen to all traffic, not just those with my MAC address or with the rod and pass MAC address. So we'll look at all traffic. So once we do that, if we're on a hub, it's game over, right? On a hub, we're seeing all traffic that's getting sent. So all we need to do is just look at what's being sent to our port. What's the problem on a switch, though? Now, we're not gonna get that traffic. The switch is smart. It knows that only our MAC address, it's only seen MAC address traffic on our port. So why would it send a traffic? So how do we get around that? Are we just screwed? We don't. Make it think we're on the same port as one of the users. We can make it think that we're on the same port as one of the other users. What else? Start messing with its cache. We can maybe mess with its cache to make it think that that host is on our port. So when thinking about a physical switch, it would be hard to change our port to somebody else's. Without physically changing it around. But that would be a very interesting one. And you get about a window of when it's in a cache that you can get all of the traffic. Yeah. Could you change your MAC address? We could maybe change our MAC address. Yeah, we'll just look at that, yeah. So the key problem, right, is when we're using a switch, we need to essentially trick or convince the switch that, hey, we need to send a copy of that traffic to us. So those are the high level rules. We'll look at how we do that. But talking about why do we want to sniff a lot of high level protocols that we actually still use nowadays. FTP, which is the file transfer protocol, and we use FTP up with files. Yeah, a lot of us native web servers. If you're using FTP and not S FTP, all of your credentials, your login credentials are sent in the clear. True story. Pops, let's pop. Email access, I can't remember one of the programs I was saying this for. Post-opless protocol? Nice. Yeah, your password can get sent in the clear. If you're using HTTP to send a username to the password when you log in, if you don't see that beautiful green lock, your password is getting sent in the clear, and that means anyone who can see your traffic can look at it. IMAP, so IMAP is another type of pop-like thing about access to your emails. Also, not included in here, S M T P, is also your passwords. Your password's not sent over to your clear text, but your email is sent over to your text. So you should think about email like a postcard, that the mail in can read your postcard. The text of your postcard, it's not a letter that they can't open, they can read it. Okay, so by sending traffic, it's possible to collect username, passwords, files, mail. And if you're doing pen testing, usually you'll try to, you'll capture some traffic and then transfer it somewhere later to do this analysis. So true story, when Giovanni, my advisor from Santa Barbara, when I was doing my PhD, we did some pen testing on a security, well not a security company, but a company in Santa Barbara, and we did a tap and we looked at all the traffic that they were sending, and it turns out of course people were using FTP to upload files to a marketing server. So of course we got the passwords to those and then we just logged in and were able to do some fun stuff over there. So it happens, this stuff happens, right? So how do we sniff? So we need tools to collect, analyze, and even maybe replay traffic if we want to mess over the traffic. This is actually one of the most used tools in the security professionals tool kit, I would say. I mean obviously it depends on your job, specific job. TCP dump is a great tool. I highly encourage you to just play with it, just see what's getting sent. TCP flow takes TCP up output and because, well as we'll see, we haven't gotten to the TCP layer yet. The TCP is just what the packets getting sent back and forth, maybe any intermix with other packets in there. TCP flow takes all those and says this is the communication for most A to O's B and this is everything that got sent back. TCP replay allows you to replay traffic. This is actually fun in all types of scenarios, well after the five scenarios or something, you can take traffic that you sniff and replay it against another host. The graphical tools for this is Wireshark which is a very cool, very well-known tool. It can be a little clunky depending on what you're doing, but what I usually do is I will usually use TCP dump to actually capture the traffic because I know it's very good and it'll work and I will write out the traffic to a file so use the option to write it to a file and then I'll pull that down and look at it in Wireshark to actually look at the traffic. So yeah, Wireshark has really cool stuff. We'll give them the TCP risk of looking stuff and Wireshark also provides part search for a lot of protocols. So it will be able to take a bunch of TCP packets and say, oh, this looks like HGV and so we'll give you one HGV request. How do I encourage you to check out download these tools, play with them locally, see what you can see. So is that an ethical thing that I just told you to play with these things? Yeah, it depends on how you use it. Why may be no or yes? Do you own the network that you're sniffing on? Probably not. To click traffic that attackers are sending against you. Yeah, so that can be a good way of looking at it, right? You want to make sure you're not under attack or that it will be messing with you. So when you run one of these commands, right, all it's going to do is turn your network interface into permissivism to get all the packets that are getting sent, but is it messing with the switch at all? Messing with the switch at all? It's not gonna mess with the switch. What is it really doing? Just listening to what's being sent, right? So yeah, it is one of these very fine distinctions, but in my mind you're not doing anything active. It'd be like if one of you was running around shouting your ASU password and username, right? I can listen and hear it and write it down. Maybe I shouldn't tell you to stop doing that. But if I went in and logged into your ASU account with that information, that would be really one of that at all, right? But the fact that you're going around shouting out your passwords, I have ears I can listen. It's kind of my view on things. It's like, and it's interesting to see what kind of stuff you can see. Cool. So TCBNU, that's the output of the tool that we saw earlier with the art packets. So that's TCB, fan line output. It actually is really cool, so it's not. It's based on libpcap, which is a library that allows you to write your own Snippers. So you can use libpcap to write your own Snippers to do all kinds of cool stuff. And you can specify an expression that will tell it exactly what package you're interested in. So this is going to be something interesting when you are actually looking for an attack. You can say, hey, give me all of it, or send packets, or SINAC packets, or packets with weird fly set, or packets just to this host if you're only interested in one thing. Also, how do you recommend if you're doing a kind of networking setup, network administration, knowing TCBNU and using it can be super helpful. So last year when I was doing this class or no, maybe that was a different class. Anyways, I was setting up a web exploitation server, and I thought I got it all set up in our network, and I go to access it, it's working great, and then I try some exploit, and then it just doesn't work. Like, I wouldn't get any response back from the machine. So then I had to use TCBNU to make sure my machine was sending it out, and then I had to use TCBNU at our server if I was not getting any traffic, so when I moved for a route I was not getting any traffic, and then I finally realized that ASU was a web application firewall that was blocking all traffic that looked like a web attack. So I slightly changed what I was doing, it went through anyways. And then I changed it to HTTPS and everything that I liked to look at any of that traffic. So anyways, highly useful tool. The interesting thing is that you need to be root in order to set, so root is administrator. You need to be administrator in order to set your interface to promiscuous mode. So there actually is stories at the DEF CON after the flag, where people would find zero-day vulnerabilities in Wireshark, and they would send out traffic on the network that would exploit those vulnerabilities to the crash people with Wireshark. So you would try to look at the network to see who's attacking you. You'd load in Wireshark and the whole thing would just crash. It may do even worse, but I don't think they actually did that. So this is another thing to be cognizant of. You have a program that's just listening to random things on the network. That's why I usually like running my listening with TCP now, because it's just gonna write out when it gets to a file, and then I'll analyze it later in Wireshark, it's just not running as root. Lots of options on TCP now. I'm not gonna go for all of them. The important ones that I use are dash end. So without dash end, it will try to, every IP address that it sees, it will try to translate that to a DNS name, which means like things take forever even if they need a bunch of DNS requests. So yeah, I disable that all the time. I tell them which one to read from, which network interface. The S packet, I think a newer version, you don't have to worry about that because it will automatically after all traffic. What used to be when space was a concern, it would only capture the headers of the packets. So you wouldn't do this on a competition or something and realize you didn't get the data you thought you got and so everything, nothing was fine. Anyway, so yeah, you can specify hosts, specify different subnets to listen to traffic, different ports, direction, so you can specify source or destination. You can specify a protocol, so you can say I'm only interested in packets and I have a source even in the address of this, IPs, ARP traffic, reverse ARP, all kinds of fun stuff you do. And you can make really complex, yeah, seeing all kinds of stuff. All right, so yeah, some tzv dump. So you tzv dump on interface key zero, that dash end would not translate to dash x, we'll output it all in x. You can specify size, writing out, reading in a file. So what's the difference here between these prompts? It would exist. Yeah, one is with that hash and one is with the dollar sign. So this is kind of a convention stating that going to the dollar sign needs to be run as root, right, in order to work. It doesn't make sense because we're listening to a raw network interface, we need to be able to be a root to set it to a permissivious mode. Here, we're reading from a file and so we don't need to be a root, so that's why it's different. Cool. Limbtap, very cool library that you can write snippers in C, custom snippers to do whatever you want to do. The problem is, even with these fancy awesome tools on a switched environment like we were talking about, we only see traffic that's dedicated to us and broadcast traffic, which is kind of lame. We can't directly sniff. And so, what do we do? Well, what was that? Sniff on the gateway. Sniff what? Sniff on the gateway. What do you mean on the gateway? So even if you're on a switch, if you don't want to get out to the internet, if you put your snipper on the gateway, you sniffed everybody's traffic. Okay, so let's assume that we are a machine on the network, right? We can't change the way we're plugged in on a switch. We're physically, either we plug ourselves directly in or we take it over a machine on the network, right? Either one is kind of the same situation. So we can use different techniques. So essentially, the switch uses a table with MAC address port mappings. In some cases, because switches are physical devices, right? They have limited amounts of memory for this cat. What they'll do, if you just throw a bunch and say, oh, I'm, whatever, I'm MAC address zero and one and two and three and four and five. After a while, it runs out of memory and so it just fails open into a hub. It says, oh man, there's way too much MAC addresses here to know which way to send, but I'm just gonna send all ports to everyone. Right? And so this way you essentially force the switch into hub mode by overloading. This is where you get into active attacks. This definitely would be unethical on some of you don't know. But these techniques are fun if you can get the permission of people you live with to play with on your own switches. These are kind of fun things to do. We can duplicate the MAC address like we talked about some of these days, right? We can clone somebody else's MAC address and then we'll get all those packets, right? It may send it to both. The switch may send it to both. The switch may just send it to us, but either way, we're getting the packets. We're getting that data that we want. We can use our sniffer in order to set that track. Now, this is the cool one is when we arcs through the forwarding. Because what's part of the problem here? We just duplicate their MAC address. There's still a race condition when you can respond or if respond to whatever we need to set up. Exactly. Or if we're just trying to silently eavesdrop on a connection, right? Well, yes, we may get one packet, but if the other machine doesn't respond, we're not going to get any future packets, right? So although this is going to be good maybe to try and get some things, ultimately somebody's going to notice because things aren't working correctly. So we can take this up to another level and do what's called arc spoofing attack. So the goal is we want to submit all traffic in between two hosts in a switched environment. And the idea is we're leveraging, we're taking advantage of the fact that arc doesn't have any notion of, oh, here's this request, oh, here's this response to that request. Replies without a request are accepted by the host that requests them. So, basically the attacker is going to poison the cache of both victim machines to make each of them think that its MAC address is the correct MAC address. Then when they want to talk to each other, it'll all get set through the attacker's system. And our host, the attacker's host, essentially acts as a router and routes the packets between the two. So the idea, so we have our switch, we have host A, we have host B. I think he was going to say most, yes. We're doing a better job. We're host C now. Now we're on this switch and we're back. That's what the block has to do. So we know we're 1, 3, 7. So the idea is that host A in its arc table has 1.10 is at MAC address 0, 0. It was over here. And host address dot 100 is at MAC address 0, 8. So this is the way the arc tables look like normally, right? Before the attacker's done anything, the attacker says 100 is at 0, 8 and 10 is at 0, 1. So the idea is that host C, the attacker sends an arc reply to host A that says, hey, dot 10 is at this bad MAC address. And so it updates its table. And host B says, oh, by the way, host dot 100 is at this MAC address. And so it updates its table. Now, whenever host A wants to send a packet of host B, it's first going to go, it's going to send the host, the destination MAC address to be the host C's MAC address. So the packet will first go from A to C. C will get it. So the ethernet of that port will be sent to this. The switch says, oh, I know who that is, Tom. That's on port two. That's this one. It gets sent here. And then when we send it out, all we do is change that ethernet address to be B's actual ethernet address. And we'll see that it gets sent that packet there. And the same way with the replies. So part of the, yeah. You're not supposed to be on someone's network. Won't they notice that you're connected? And like someone might not authorize to be on the network. Connect to the system. So like open Wi-Fi networks, right? Does anybody authorize you to be on them? Also, even just ethernet, right? If you find a plug in the wall in any building here, you can just plug in and you're on the ethernet. Same with any building. The other thing about a host C is an employee's machine. Right? And you trick them to download and install some malware. Now, essentially that machine is now acting as the attacker and has full capabilities of that machine. So even though the user's not physically present on the network, they're still there and able to control it. Yeah. Is there some way to mitigate this at the switch level? Like if a smart switch runs off and say, well, I'm seeing two replies that were not in-get request and try to filter it that way. Could you maybe visit the switch level? Possibly, but you would have to then have a switch, remember every ARC request and make sure that it got corresponding replies, otherwise you'd drop it. I think in that sense, it would probably, it's probably one of those usability security trade-offs where nobody's willing to take the performance in on that. And then you might open it up to, what if I just make a bunch of fake requests that I had to reply to that I'm actually exhausted and trying to do a lot of that anyways. And look at where you probably can send between two machines if there's any data. So you would send like keys between two hosts that were encrypted somehow over the network. And then once you receive that, those keys in when you do e-crickle the function or a key thing you have, didn't you know? That would require completely changing the link layer for the calls and all the switches and everything else. But that wouldn't be a problem. Yes, if you could go back and completely change everything. So there is such thing as like stateful ARC cache, right? So why is it that you use? They're stateful ARC caches, and it kind of depends on the system, right? And that's part of the thing, right? Is what if one of the packets, what if their request got dropped or something, right? You may want to know that. So yeah, it's tricky. You could always just wait until somebody, their cache gets flushed, and then they say, hey, who's this, who's got this address? And then you just go there before the other person, right? And then you can poison it back up. So yeah, cool, all right, we'll stop here and we'll continue on with it.