 I guess before you start, I'll do like five minutes of questions. Okay, no questions, though. So for the part three of the form, if it, the format is... And no command? Yeah. I'm saying no. We're saying like there has to be something after the slash, so I'm going to lay it right here so I don't look like a plus, right? There has to be something there in the added command. For the first part, I need somebody who will say, can I get a question? You probably submitted the wrong slope test. Is it a Latin for each slope test? If you click the wrong one, it'll submit an old one. That's probably what happened. I'm going to resubmit a new slope test one, and then here's that one. Do you have a question? Can we use the C-socket code provided on this website? Yeah, it's long and excited. Anything else? The question in here was, can we use the code provided in the link to the C-socket library? Yes, it's long and excited. Comments? I would say where you use it would be best. A comment is that I got this code from this link. That's probably fine. I'm not that. Somebody in the class is going to have to take a class. Can we get another one? Yes. Anything else? That's the one. That applies. We just got two minutes back. We are almost at the end of network security. We're actually making awesome progress. I'm super happy. We talked on Monday about TCC spoofing. What was the essence of TCC spoofing? What's the purpose? Why are we trying to do that? We're establishing a new connection as if it came from somebody else's IP. That's the key there. With spoofing, we're not disrupting an existing connection. We're trying to make it seem like this TCC connection comes from a different source IP. That's the key idea with spoofing. Here with hijacking, we're going to look at something different. We're going to talk about how can we try to inject data into an already existing TCCD string. Hijacking is as it sounds. For TCC spoofing, we're spoofing where the source comes from. We're trying to establish a new connection. Here, there's an already existing connection. Stopping, stop. I can hear all of you whispering. For hijacking, there exists an already established TCCD connection between two hosts. The idea is we want to inject and take control of this attack. The idea is we're going to use spoof TCCD packets that have to do what? For us to let's say inject data into a packet, what is that, into a TCCD connection? What would we need to do? We need to get the sequence number right of whichever side we're trying to inject the packets on. Is that easy or hard? Hard. Hard is just as hard as trying to spoof a TCCD packet. Because we have to somehow know that sequence number. So how are we going to deal with that? We can guess it. Maybe from the network and we can sniff the packets. What else? We can sniff it. We can guess it. Yeah, we can just hope to get lucky. We can use this technique to insert data in a string. Why might we want to insert data into a TCCD string? What do you do with this? Put on your bag. Okay, so we're going to use this to explain a lot of what we can do. Sounds like this is like an SSH connection. You could put a back door on our system or whatever. So if SSH is a little tricky, the first S stands for secure, which means it's using encryption between the two endpoints. But for something like Telnet, which is SSH essentially in the clear, if you just inject one command in there and that gets sent to the server, that command will get executed. The name is one command to be able to maybe add yourself to the system. What else? Don't worry, this class will change that. Maybe send a fake web page. Yeah, so maybe it's an HTTP request. And so maybe you could either send a completely different web page, or even worse, you just inject some JavaScript that actually tries to exploit vulnerabilities in their browser to get malware installed on their system. Anything else? Like corrupt the connection so that denial of service? Yeah, what if it's a phone call from one general to another, telling them to attack and send an airstrike at a specific time? There you may not even care about injecting data, you just want to disrupt that connection. So all kinds of ways you can do this, right? So if anyone wanted to reset an existing connection, the tricky part is we need to have the correct sequence and acknowledgement numbers in order to pull this off. So this is something that's actually very difficult. And we can do this as we saw with Spoofing. We can either eavesdrop the traffic between the client and the server, or we can guess, right? And if we can guess correctly, as we saw, sometimes sequence numbers are not generated very randomly. And so if we can guess, then, hey, that'll actually give us a way to inject packets into here. There's a really cool paper. If you want to read more about this, I highly recommend this paper, because it describes how to do this. So, okay, you need to perform this attack. What are some of the risks? So you're sniffing, you see a sequence number, now you know what the next packet does end. Now, what if they're sending a lot of data across so that sequence number is constantly increasing and you can't time yours to get into there? So one thing you may want to do is just wait, right? And wait until that connection is relatively quiet where there's not a lot of packets going back and forth. So quiet also means we want that data to be acknowledged, right? We want both sides to have acknowledged those data. Then we inject the data, so we send a packet. What do we have to do with that packet to make sure it's correct? Sequence number, so this tells it what the data is. What else? The acknowledgement number of the other side. Source what? Source port. Destination port? Source IP and destination IP, right? We have to make sure that all of those are correct. This way it looks to the computer receiving this packet, hey, this is the next packet in this stream. So now put yourself in the shoes of the TZPIP sack. You receive a packet. What is the next thing you're supposed to do after you receive a packet? Send an acknowledgement, so you're going to say, so let's say the sequence number is at 100. You're sending 100 bytes, so they're going to send back an acknowledgement of 200. What does the other side do when it gets an acknowledgement of 200? Yeah, it's going to send a packet back that says, no, no, the sequence number is 100, what are you, crazy? And then what happens? So there's no packets that they missed, right? One side thinks the sequence number is where in this example? At 200, the other side thinks it's sent how much? 100. 100. So they keep sending acts back to each other, where one says, hey, I've only sent up the sequence numbers 100, the other side says, no, I've read up to 200, the other side says 100, the other side says 200. They keep doing this until what happens? It keeps going forever until a packet gets dropped and they're like, yeah, that's what I thought. And so we actually end up in a weird circumstance because this desynchronizes the connection by injecting data into the string, right? Both sides think they're at different parts of the conversation and so this can actually cause a lot of disruption when you're doing this, but if you inject that packet to get access to some system, then you don't really care if those two can talk about it Okay, so yeah, this is just what we're talking about. So the receiver of the injecting data acknowledges it, the other one says, actually, I only sent up to this and then they keep on sending that until finally somebody drops a packet or they miss a packet and they think everything's fine. So yeah, and this is a problem because now they can't really communicate with each other because we desync these clients. So we can try to, if we are, what can we do to avoid this if we are, let's say, actively in the middle of their connection? So we are one of the hops along the IP route. What can we do? We can drop, yeah, we can drop one side's acknowledgement, the side that we just sent the data from, but then what would we have to do after that? You could modify it to make it sound like it was acknowledging frankly. Yeah, so you could just acknowledge it so you would have basically one side thinks it's at 200, all the packets that come back, you substitute, or you subtract 100 from their acknowledgement number and so it would act back 100. The other side goes, yeah, we're definitely at 100. It would send another 50 bytes and so you would increment then that sequence number by 100 bytes. So the other side thinks it's at 200, whatever, bytes and you would keep doing that. So if you're in the middle, you could actually pull off this kind of connection. So yeah, so let's take a look at this. We can send a spoof TCP packet with the correct sequence number with 30 bytes of data. So the client sequence number, the server sequence number, the server responds back with an act of the client sequence number plus 30 because we just sent 30 bytes of data. The client acknowledges the client sequence number and again this keeps going. So this is a very powerful attack because it allows us to inject data when two machines think that they're just talking to each other. So this is why we have to have additional layers of security on top of TCP and IP. This is why they built TLS, which they use for HTTPS, which actually guarantees that the communication is encrypted and nobody else can inject packets or if they drop packets, it's detected. The same with SSH, so I don't know the exact, it's called like this, it's a layer over telnet that causes those to be secure. So we actually see this act storm when we try this. So there's just a bunch of acts back and forth between each of the two endpoints, dot 23 and dot 10. And they're all acknowledging the wrong packet. So they keep doing this until finally it stops. So very cool attack and the thing that should scare you is this is absolutely feasible on things like web requests, right? So you're on a Wi-Fi, a public Wi-Fi where we already know that everyone can sniff all the packets on that Wi-Fi. You make your request for, we always Google that problem because they're all encrypted, but you make a request for whatever, cnn.com, right? All it takes is somebody on that local network to be seeing that request and able to respond as if they were cnn.com. And now your browser is looking at and loading code as if it was from cnn.com. We'll find out in the web section why that's so bad. There's a couple other things on Tyra because they increasingly become important. So we talked about, so here you're able to inject data into a conversation so there you'll be able to affect the integrity of the conversation. By sniffing you'll be able to affect the confidentiality. So the other attack we've looked at a little bit, right, are attacks against availability. So what do you mean for that? You need, well, a lot of computers in bandwidth, is that the only thing you need? Can I take down your system with one computer? What bandwidth? Maybe. What do I need? Leverage. I need leverage. So I need something where I can maybe turn one packet into 20 packets, right? Or another way to think about that, I'll think about it here, we can think about it in terms of memory. So can I send you one packet which costs me how much memory to send out one packet with SCAPI? Sending out one packet, how much memory? On average, I'm not looking for the exact amount. So to send out one packet, are you keeping a packet's worth of data in memory? What are you using SCAPI when you just create those packets and send it? You set that up when you create the packet and then you send it out on the wire and you just delete it, right? It takes zero memory to send a packet assuming you don't ever want to, you don't care about the response. Like sending an ARP reply is nothing. You build a packet, you send it and it's gone, right? Because you've done your part, everything else has to take care of that. So we're going to look at attacks that kind of take advantage of this. So a SIN flooding attack is one of the most common denial of service attacks against infrastructure. And so there's a lot of them that have been... So the idea is, what happens here? Well, the attacker starts a handshake with a SIN... So it starts the first step of the SIN packet. So think about this. We send a SIN packet from us to the website we're trying to take down. What happens on that side? They send a SIN act back. But what do they have to do on their system? What does their TCPID stack have to do? It has to allocate memory to do what? Yeah, it has to know the sequence number that we sent and it has to remember the sequence number that it sends us so that it can verify that the act got back correctly. So at the very least, it's got to allocate memory and how long does it have to wait for a reply? Till it times out, right? There's no hard guarantees. This is something that each stack has to decide for itself. At some point, it has to time out and free that memory up. But the idea is, I've now sent one packet to your machine. It cost me zero memory. But when you get that packet and send it back, that requires you to allocate some, let's say, a packet's worth of memory. So if I can just send a bunch of SIN packets, as many as I can possibly with my bandwidth, for that whole window of time, you're going to keep this data structure allocated in the kernel, waiting for a reply back. You'll send back a bunch of SIN acts. And eventually, you'll run out of memory. Well, depending on how much memory your system has, right? If you have a ton, it's a different story. Would that be like a layer three? I'd say sometimes a third. Yeah, I don't think of it in terms of layers. I think of it in terms of what is it targeting. So in this case, it's targeting the memory allocation of a high level of kernel, specifically the TCP-IC stack. So yeah, I guess level three would probably be right, since it's using TCP. But for me, it's more about the effects. What does it actually do? It causes them to allocate memory when we as an attacker don't have to allocate memory. And so the very cool thing here, so what does this mean that we can do? Do we care about their reply? So what does this mean we can do? Spoof. Yes, even those TCP, right? We can spoof the source IP because we don't care about getting those SIN act packets back. In fact, we don't want to get those because it's going to mess up our bandwidth, right? We want them to go somewhere else. So we just want to send out as many SINs as we can from as many different IP addresses as we can. And what does it look like to the attacker? Are you into the victim? Heavy traffic. Heavy traffic. It's just a lot of people trying to connect, right? You're thinking, awesome. My website is super popular. But then you realize, hey, but nobody's actually completing this handshake, right? I have all these other things connected. So this is the key problem, is these half open sockets where we've completed two parts of the freeway handshake and the server has to keep open these sockets until finally the time's up. So, how do you fix it? Just recycle the memory of the oldest received pending connection. Ooh, tricky. Let's see. I think in that case, you'd still... So how could... You would be dropping packets. Yeah, that's what I'm trying to think of how much that would affect. But it would depend on the window. Yeah, it would depend on how long... Let's say if you think how long could you go without looping over the same packet and how fast can the attacker make you keep allocating this? Yeah, you could basically force... If somebody else can complete the connection in time, then they'll be fine. But yeah, you're bandating it, kind of, right? You're not going to run out of memory, which is good. You still are not able to allocating probably any new sockets. So what else? Set a threshold. Set a threshold in what sense? What do you have to set a threshold on? From who? From everybody? Do you want a hard limit on the number of people who can access your website for a second? That's a tough one. Whatever limit you set, the attacker... The other thing is the attacker can change their IP address. So you can't say all packets coming from this I set a limit on. So if you set any kind of limit, as the attacker, I just fill up that limit and now nobody is legitimate and connect to your website. What else is coming here? If we have more than half open connections, then we start dropping from the start the whole list of half open connections. Yeah, so maybe kind of a similar reusing. You just kind of start dropping stuff as soon as they get old. But at some point, right, they can... I mean, assuming they can start sending enough packets, if they can send more packets then you can, you know, you're kind of posed there. Yeah. Only allocating memory... Yeah, so that's getting to the root of the problem, right? The root of the problem is you are allocating memory. But what do you have to... What's the challenge you have to solve there? If you don't get a reply back in that time, just drop that one here. So, yeah, so that's like kind of closing the window, but you're still susceptible, right? I mean, if I can still send a bunch of packets at once, you're still being formal there, yeah. What if you prioritize trusted users? Like users that have established connections with you before. And so, they'd be less likely to attempt that. And then you are more... And then you're more likely... You make it more likely to see a drop packet from people that you don't know. So you want to know new users to your website? You're fine with that. You want to prioritize the users who've been there before that you know... Interesting. The downside there is that the attacker can spoof their source IP of who's already been there. They'll just spoof good users. And so you still don't have any way to distinguish that. I want to go back to this idea of eliminating the... the storage. So this is... When you're trying to think about this, I always... When I'm trying to think of security solutions to a problem, right? The way you want to... You want to treat the disease not the symptoms, right? So you don't... But sometimes it depends on the problem. Sometimes you can't treat the disease. So you have to come up with different kinds of band-aids or work-arounds. But if you can get around this fact of let's not allocate memory every time you get a SIN packet and send out a SIN Act packet, then it doesn't matter. Then it becomes a bandwidth race, right? But still in the bandwidth, they send one packet, I send one packet, right? There's nothing... There's not very much leverage there, right? And these are zero data packets. So what's the problem with not... Can we even not allocate memory here? Yeah, so the core problem is we need to know, does our sequence number... Does the sequence number that we chose match the acknowledgement number that they send back? So the trick is essentially they... Well, okay, so we can actually take a little look at the way that they do this. It's actually pretty much all the ways that you guys just came up with thinking about this. The main one is SIN cookies, which we'll see right now. And there's an RFC that actually has descriptions of all of these and mitigations to them. So the idea with the SIN cookie is exactly this idea of let's embed in the sequence number that we chose the sequence number that they sent us. And so that way when they send it back, we can essentially reconstruct this. So the idea is it will be constantly changing, but the other thing is it needs to be changing, right? Because you need this to be random. The sequence number shouldn't be guessable, right? So if it's just a direct... They send me this acknowledgement number, I send back this sequence number, right? That's much more easily guessable than choosing a random sequence number. So I'm not going to go into the details here, but basically it's a key hash off of a counter and the source IP, destination IP, source port, destination port. And so by doing this, the attacker when it gets back the acknowledgement number, it can verify that it actually generated this acknowledgement number without storing any data. So it gets a SIN, it creates a special SIN act, not special, but it creates a SIN act with a special sequence number and that way when the other side sends the final act back with that sequence number plus one, plus its own acknowledgement number, it can reuse this algorithm to figure out was this a SIN activity that I sent? So this is the... So the... That's how I'm going to draw it back. Yeah. Okay, so it can include... Okay. So this is kind of a whole class of attacks that basically take advantage of the fact that a server, that a client by sending maybe one packet or a certain number of packets can enforce the server to hold on to some finite resource. And there's actually a lot of other attacks like this. For instance, socket descriptors, so every time there is a new successful socket connection, the server has to create an object, a socket object, which has a file descriptor number and there are limits on your operating system about how many open sockets you can have at once. So if I can connect to you enough times to eat up all those sockets and for this case I may need to use more than one machine, right? But if I can do this and have you create a bunch of sockets and I just don't do anything or say anything on those sockets, then now nobody new can connect to your server. There's a number of processes. So this is in some architectures. I think it used to be the case, well, some servers will, when they get a new connection, they will fork a new process. So there are hard limits on servers about how many processes can be spawned. Otherwise, everything crashes down. So you can make them exploit that. You could, this is a really cool one. Actually it's in a vein on some modern one. The idea is you as the client have the server send you a bunch of data but don't acknowledge that you ever got that data. So in the kernel, they still have to keep a buffer of all that data that they sent because they may need to retransmit it. And if you do this enough times, you're getting them to store all of this data in their buffers, eventually overflowing them. So there's similar things here that people have done with HTTP. So there's to overload HTTP servers. So there's an attack it's called, I think it's a slow Morris attack. The idea is you make an HTTP request to the server, but you never complete that request. So you send like the G first and then a couple of seconds later you send the E and then you send the T and the servers have no way to really detect this because they're getting data from you, right? It's just very slow. So you could actually take down servers with just like a laptop because you don't need a lot of these connections open to use a lot of their sockets. So this is, if you look that up slow Loris you can see sample code for this and how to deal with that. But that's kind of like a timing thing which is kind of cool. It's using the fact that I can take up a lot of your time and you're not going to stop me. Any questions on this kind of resource attacks? That leads us to the end of network insecurity. So at this point you all got a crash course on networks and you know, they're incredibly important. I can't stress this enough. So what I've been thinking about a lot is part of this section have you ever heard this interview question that people will ask of what happens when you type in www.google.com into your browser and then hit enter? Like what exactly happens after that point? Have you heard of this before? So you should look this up or think about what your answer would be if you got asked this in an interview with the company. Right? And I hope I've done a little bit to expand your knowledge on that segment because now you should be able to talk about everything and what happens on the networking level. So we have to first do a DNS we'll have you do a DNS we have to have your DNS server in there it's going to send you a VP packet but first you need to know who's your gateway where is this IP server so it's going to be a routing table and it's going to send out if it doesn't know it's gateway's Ethernet address it has to send out an ARP request to find out it's gateway's IP address it's going to send out a DNS request it's going to get that back then it can start the process of figuring out which one of those IP addresses to use and then send out a request and then that doesn't even get all those points from what happened when you enter that into where it gets to the network so you have system calls and library calls and everything that's happening in there So it's a cool thing to think about and you have the knowledge now you know how things actually work and you know how they can break and you cannot be trusted this is one of the key things here when you get a UDP packet can you trust that source IP address? No, fundamentally no because we've seen how easy it is to smooth that and this really is the building block to a lot of other attacks that we're talking about because next we're going to go to binaries and so one of the ways we can data into a binary is through the network and so we need to be able to understand what's going on there and when you're building applications that rely on the network, what kind of things can you assume? Where is the trust there? What things can you trust in the network? So we're talking about sniffing, spoofing hijacking, denial of service group forcing group forcing we'll talk about that later we talked about some tools and we came up with countermeasures and kind of discussed some countermeasures but some of these as we saw are core internet protocols and they are fundamentally broken so we saw we can't have a flag day anymore where everybody just shuts off the internet and then we update and we turn it back on so we have to live with this and build on top of it to provide secure solutions