 Cool. Well, hello again. Here we are. Tuesday, March 31st, and we're going to be continuing with what we've been talking about with TCP. So we've been making really good progress on learning about Neverking right now. And so what we're gonna do now is just kind of continue on that. I hope everyone is having fun cracking those hashes and learning about the different ways that password hackings password cracking is done in the real world and all the different kind of plethora of tools and what kind of what an adversary can do if they're able to get your password hashes. Cool. Let's see. Okay, cool. So let's Ooh, let me one second. Cool. All right. And cool. So let's see 130 people. It's pretty good. Okay. So let's continue on where we were starting off at. So we had talked about the, so let's do a little bit of an overview. So we talked about the TCP connection. So what's the kind of three really important packets that need to be sent as part of starting a TCP stream? Yeah, SIN, SINAC, ACK. This is something that's like I said, I've been repeating over and over again. It's something that's incredibly important and something that you got to really just burn into your brain. It's it's really, really important. So and you can also think about this a little bit further to say, okay, first the client sends a SIN packet, the server then sends a SINAC back if they want to talk and then the other the client will finally send an ACK. And then we saw and we talked about how sequence numbers and acknowledgement numbers are used to specify where we're starting our sequence from. And so so we talked about how data is exchanged by using those sequence numbers and how we can use those sequence and acknowledgement numbers to figure out when a packet has been dropped. And so one side can basically let the other one know that that that packet has been dropped. Cool. So the one thing we didn't talk about is shutdown. So what we're there's a flag that we didn't talk about the fin flag. So So and like we talked about the TCP is a duplex protocol so they could talk backwards and forwards. So both sides can talk to each other and over this channel. And so the fin a fin packet basically is one side saying to the other side, okay, I will not send you any more data. And so this means that one side is done talking to the other. So in this example here on the slides, we have basically that the client has said to the server, Hey, I'm done talking. Here's my fin packet. And so I promise to never send you any more information. And still the server can send more data. So that's weird. Oh, format shape don't want to do that. So still the server can send more data. And then finally, when they're ready to close the connection, they send a fin packet back. And finally, we'll get those both fins, the connection is then torn down. And we have no more no more connection there. So we have. So here we have how so we now know all the way. So we have since an act, the both sides then talk using sequence numbers and acknowledgement numbers. And finally, they use the fin flag in order to turn down the communication. There is one other flag that's going to be relevant that we'll talk about. So rst reset is this is a TCP flag that basically says yes, so fin permanently. Good question. So fin permanently affects the data transfer. Like once you send a fin packet, you're guaranteeing as part of this connection. And again, the other thing is what defines the connection. So what's the four tuple that defines the connection? Anyone? Bueller? That's two of them. Perfect. Awesome. So the socket is source IP, source port, destination IP, destination port. So what that's saying, when you send a fin packet, when one side sends a fin packet, it's saying, okay, we're not going to talk anymore on, I'm not going to send any more data on this. And it's permanently affects this data transfer. So if I want to now start up a new conversation with the server, I can, I will have to go through the entire setup phase. So I'll have to do a sin, sin, act, act, and start up a new communication with the server. Now, the important thing we didn't talk about is, if something goes wrong. So let's say like, what happened if a client just sent an act packet, like the third part of the three step handshake? And what if the client just sent this act packet to the server, but the server never got a sin packet, never got a, never sent a sin act. Basically, a reset is a way to say, Hey, I don't know what's going on, but we've got to kill this and start over from scratch, because something horrible went wrong. So reset kind of tells the other side, Hey, this went really, really wrong, we need to restart this whole communication. Okay, cool. So that's, and there's a, you know, we've just kind of scratched the surface here on networking, you can take networking classes that will go into all kinds of details here that we didn't cover, window sizes, how data, how many, how much data we can have at one time, how to deal with congestion, all kinds of super important things. But for now, this is all we need to kind of study and analyze this from a security perspective. And so just like with UDP, we can first talk about port scanning. So what was the idea behind port scanning? Why was port scanning important to pen testing and maybe under analyzing the security of a remote system? Yeah, so it's, it's exactly so you can definitely find out what ports that are listening. And the goal is to find out what's running on that system. So the ports tell you one thing of who's listening on what port and then you want to go further from there. So just like we saw with UDP, we can send UDP packets and if we don't get a packet back that says, hey, that port's closed an ICMP error message, that's how we can tell. So with TCP port scanning is super interesting. So there's actually a lot of different ways to do it. One of the easiest ways is to try to do this whole three way handshake on every single port. So, and this would be the function for this is connect. So it's also called connect scanning. But basically we try to connect to every single for a given destination IP every single port. So the attacker will try to open a TCP connection to all 65,000 ports on the victim host. And we know that if our handshake is successful, right, if we actually get a successful handshake with the server on that port, then hey, we know that this port is open. So let's maybe see this in action. Okay, cool. There we go. There's Fang. Yes, Nmap has all of these. So yeah, one thing to do would be you can try to target the 1000 most commonly used ports. And I'm not to look at the help page of Nmap because I don't remember all of the options, but we have this nice. Let's see. I know I have it somewhere. There we go. There is no way to obscure the ports being used. Yeah, exactly. So this is there's no real way to obscure this information because you need a service listening on a port. There's kind of more, let's say interesting techniques, if you wanted to think about like you could mess with this protocol and do weird stuff, but that's not really then nobody else can talk to your service. So I think it's just ST. Let's try this. Let's do dash H so we can look at what's going on here. Cool. So you always want to read the help. Let's see. Okay, good, good, good. Let's see. So here's where with dash P option, you can specify the port ranges. So somebody said so dash capital F would scan fewer ports. So it would give you things in a good more quickly to scan just the top most frequently used ports where you can specify to scan all the ports. Cool. Okay, yeah. So here's the options we want. So scan techniques. So we actually already saw the dash SU the UDP scan. And so ST is what we're calling here of connect scanning. So let's first run it to see what it outputs and then we can maybe run the wire shark to see what it's actually doing. So let's get there dash S. And now I already forgot what it was. SC was it C for connect scan? T T for connect scan. Cool. And we'll go with this machine. Okay, so wow, that actually went really quickly. So we can see that it actually did basically 1000 ports. So it's not showing me it so it didn't scan for everything. But this machine has a port 22 open port 3000 port 5000 8080 8081 8082. It's because I'm running some of our systems on this machine right now, which is what I just realized. And those are all still up. If we wanted to one to what was the format here for the ports, so we can go up and look at what the format was to scan. Let's see, we want to scan all of the ports. So we can do dash P Oh, one there we go. I'm just going to copy this. And this will take slightly longer to run. But as we can see, not that much longer. So we can see there's other TCP ports open on this machine, which we didn't see before 23778765. And so this then tells us all the different ports that are open on these. And it doesn't tell us anything about what these are. So the important thing to keep in mind is these services. This is what somebody was mentioning. These are just what service is associated with this port number. It does not mean that this is exactly what is running on this port. So we don't know that we'd have to like, study it more and kind of figure that out. But here, I've been able to scan 65,000 ports in very little time, because I'm on a local network. This is all something like I did this in two seconds. So let's, and maybe we'll just use TCP dump rather than wire shark for right now so we can see kind of what's going on. If I did TCP dump. Hello. Let's see. And I think it's five host 1921680134. Cool. So here's all my packets. We can see all going past. And okay, this is a lot of information, but we can at least see a little bit about what's going on. And this actually gives us insight into the TCP connection that we haven't exactly talked about yet. So let's just take one of these right now. So here's one packet that is getting sent from my machine. So I'm 1921680.27 port from 58657 to the target at port 19346. So this is checking is port 19346 up. And so we can see from the flags, it's sending a sin flag. And what this, and there's a lot of other things, we can see the sequence number, window size, a lot of other stuff. But we can see this is the first step of the three way handshake. So I'm trying to initiate a three way handshake, I'm sending a sin packet. And if we look for the response, which we know will come from this port, we'll see that what it sent is a reset packet. So that's what this r is for. So what it's actually sending back to us is a reset packet. And so that's the packet that you get if the other side does not want to complete the three way handshake. So instead of a sin ac that you're sending back, you send a reset packet. So this is why the reset pack is an important. And now let's grep for so if we look at maybe 8082. Let's go dot 8082. There we go. Okay, so I go back. So this is the initial packet that my machines. Oh, no, that's not right. Okay. You know, rather than doing this, let's do this in wire shark, write out temp test dot pcap scan it again. So it took two seconds should be very quick, run wire shark, open it up. It should be the same file. Cool. Okay, so now we can see visually all of these packets that we saw sin the reset packets. And so if I look for port 8081, of course, the IP 8081, that should filter it down. There we go. So it's filtering everything down. Yes, it's a lot of reset packets. We'll talk about that in a second. So there we go. Great. So here I am. This is a packet from me dot 27 to destination port 8081. And so I send a sin packet and just like just like a sin packet, I get back a sin AC packet. And then I send the AC packet so I'm completing the three step handshake. And then at that point, I reset and basically kill the connection. So rather than nicely shutting this down with thin packets, actually, you can see that TCP dump is sending a sin packet here to just kill this connection and say it because once a reset packet is sent, the connection is totally done. So it doesn't need to send any more packet. It doesn't need to send a fin and wait for the other side to send a thin it just sends a reset and kills everything. So if we think about this, so how many packets get sent? So there's two different cases. So there's two different cases. Port is up. Port is down. So in the case that the port is up, how many packets get sent or what packets get sent? Let's think about this. So there has to be a packet from us to the target. So what's that first packet that gets sent? Sin and then the packet that gets sent back. Sin AC and then back. Then what do we send? An AC and then what? A reset to kill it. Exactly. Great. And if the port is down, so we send again a sin packet and what do we get back? Sorry, sorry, sorry. Okay. How about now? Better? Okay. I try to mute myself when I'm going to take a drink. So you don't have to listen to that. Okay. Here we go. So what I can do is I can look for a port that was not in this list, right? And so here I've sent a sin packet again, because remember the first step has to be the same, right? In both cases, we send a sin packet. We'll talk about that in a second. So we send a sin, a sin packet to try to start the connection. And then the other side says, Hey, there's nothing listening here reset. So the other side sends us then a reset packet. And that kills the connection. So if we look back at 8080, we can see that what we send here, the last packet we send and maybe what would help here. Maybe I'll do N and V. So N is N map V is the victim and map sends an AC and then N map sends a reset. In this case, N map sends a sin, and then the victim sends a reset. So here just, you know, we can buy this protocol, we can see exactly that this reset gets sent. So what was the question? Yes, okay, so this is just an easy way for N map to kill the connection without sending a sin and requiring the other side or sorry, without sending a fin, and requiring the other side to also send a fin. And to be perfectly honest, I had no idea that this was the behavior of N map. The only reason I know that is because I'm looking at it right here in Wireshark to see that yes, this is the behavior that it does. So with this, it's able to scan a ton of things. So we can think we basically are sending a bunch of packets, right? For every open packet, there's one, two, three, four, basically four packets here that get sent two packets in the down case. Why would the victim send a reset instead of nothing in case the port is down or when we say down, it means nobody's listening. So I believe this is part of the TCP protocol. So specifically, it says, Hey, if the port is down, you want to one way to think about it is how does the client know that the port is not up versus the their sin packet got lost, right? So the client would kind of need some way to rather than just keep sending sins because maybe those sin packets got lost. This way tells the client, Hey, nothing's listening on this port go away. Does that make sense? Cool. Okay, awesome. One of the nice things, let me see. Yeah. So one nice thing is, and we'll talk about in a second, but I don't need to be root to run this command if you saw. And the reason is because I'm using these this connect function with dropping the packet be more secure. We'll talk about that in a bit when we go into this more. But the short answer is kind of yes, some machines do this. But really not getting anything versus getting something back. So this is actually the really cool thing about port scanning, as long as you get one bit of information that tells you that the port is up versus the port of down, you can determine that it's up. So in this case, if I send a sin, and this is actually an important thing to think about here. So here, nmap sends basically three packets, right, sin, act and reset. At what point does at what point does nmap know that the port is up? Yeah, when it gets this sin act back, exactly, just at this point, because you can see, if you think about these two procedures side by side, it doesn't know whether the port is up or not, right? So it sends a sin packet. And then it gets back either a reset packet or a sin act packet. And at that point, it knows which one it is. But in this case, I'm using I'm essentially asking the operating system to do this connect. So this is a connect. Yeah, so initiate a connection on a socket. So this is an operating system call where the operating system is going to connect to this for me. So nmap actually doesn't control this whole procedure. This is happening in the operating system right now in order to do this connection to the system. So technically, with what we're using right now, nmap can't. And so this is why this is called a just a connect scan, because the nice thing is, I don't need to be root. The disadvantage is it's very noisy in a couple different ways. So it's noisy in the sense that a, there's a lot of packets being sent, right? We saw that essentially these this act and reset are extra packets that don't need to be sent. Because we've already figured out that they're scanning or not. The other reason why it's noisy is we have to think about so let's say if we think about maybe this SSH server here, right? Let's say the SSH server itself is logging every connection to the SSH service, maybe the IP address or whatever. By doing a connect scan, once I send this act, that is in effect saying, okay, establish this connection with this remote system. And both applications that are listening there, get this alert that says, Hey, you have a new client that's trying to talk to you SSH, and then SSH can do something. So another way to think about this is SSH could be logging all of the IP addresses that try to connect to it, the service itself. So this is kind of noisy in multiple ways, one of a lot of packets and two, a lot of actually completed connections. But as we saw, we can be smarter than this. So there's just one example on the slides. We can do rather than do this whole communication, we just stop. We send a SIN packet. The victim sends us a SIN act back, or a reset packet if the port is closed. And then we never send and finish that three way handshake. So we can actually look at nmap. Let's go with that H. I believe it's, yeah, SS is SIN scanning. So this one, I do need root. So why do I need to run this as root? Yeah, so I'm not just messing with package directly, but I'm, I'm messing with the TCP protocol. So the TCP protocol, SIN, SIN act, act, this is all handled by the operating system. My program never sends these packets itself. It just tells the operating system, I would like to connect to this IP address on this port over TCP. But if I want to stop the operating system from sending that final act packet, I need to actually send these packets myself. So if you're root, root can create any packet that it wants. So you get raw access to the socket, you can send out whatever packets you want. And so when I run it in this way, now nmap will create these packets itself instead of the operating system. And we'll send this. So let's see this, we say we scanned it slightly faster. Let's let's listen here. Start the scan, kill it. And we'll reload this in Wireshark. Cool. So now we can look at all of the packets that are getting sent. So we can see just like before it makes sense, we're sending SIN packets. And we're getting a lot of resets for every packet that was not open. But for packets that are open. And actually, a cool thing, let's see, can I follow this TCP stream? No, not what I wanted. But in here, there we go. Okay, so it filtered out all of this in here. So this is us connecting to port 8080. We send a SIN packet, the other side sends us a SIN act, and then we set a reset to clean up. So in a, so here in the, we send nmap sends a SIN packet, the victim sends us a SIN act. And then we basically tell the other side, hey, go away, like, I don't know what you're talking about, I never sent you any kind of packets. And in the case that it's down, we send a SIN packet, and the victim sends us back a reset packet. Because we know at this point, so this this reset basically prevents the victim from continuing to send us SIN acts, because maybe they think the connection is still open. Any questions on this SIN scan? Or half open? So why is it called half open scanning? Yeah, you don't fully open the connection. You only have it half open. Exactly. Great, great, great. Yeah, what's different here is I never completed the three way handshake by sending this act. Exactly. It's in some sense, you can think of it as gas lighting, right? We're telling the victim this reset packet is being like, I don't know what you're talking about. I don't want to talk to you. Close the connection. And so the application that's listening on that port never gets the notification that there's a new connection because a connection was never established. So in this way, that SSH application never knows that we tried to make a connection to it. Of course, the operating system would know that this thing happened. And if anybody's listening to the network, they could easily see that we're scanning all these ports, because they get something similar to this wire shark that sees 1000s of the same packets being sent to different ports to try to figure out what's open. And I want to show one more. I don't have this on the slides. But I've actually, I guess, don't really usually do demos of this, but this is pretty cool. And since I have it here. And so you can see that there's a ton of different types of scan techniques. We can see, yeah, this was I think a cool one. And basically the idea is just if there's any type of difference in response from a packet we send and what we get in reply, then that would tell us something about what's open. So let's look at this X miss scan. Because this I think is pretty fun. So we'll do slash X, X, listen over here, run it over here. I'm not even sure if this will work. I'm done some long time. It did work. Great. Four seconds. Let's reopen this. Okay, and then see what what we sent. So this is us sending a TCP packet to port 25, right, source port this destination port 25. And what we're sending here, the flags that are set are thin, push and urgent. And so the idea is kind of all flags are set kind of like a Christmas tree, I think, or most of the flags are set. I think that's where the name X miss comes from. And so let's look at the difference what happens. So here's port 80 sends a reset act. But if we look at port 8080, let's see if we have a different. So here, it doesn't send us anything back. So this is kind of crazy. So the two differences. So if we send a packet to a port that is a thin push urgent, if there's nothing listening there, it sends us a reset. If there's something listening there, it sends us nothing. So we'll just look. So in the case that the port is up. So we send nmap then sends a was that thin push urgent. And the victim sends nothing. But if the port is down, we send a thin push urgent same packet and the victim sends a reset. Right, that was, let's say for 80. Yeah, so the victim then sends us a reset. So why do we send this packet twice? Here and here. Any ideas why do we send the same packet twice? Let's see, this is a second and like one second later. Yeah, so this is increasing our idea. So basically, the test here is getting nothing back exactly. And the question is, again, did this packet V get dropped or not? If the packet got dropped, then it would look exactly the same as if the port is up. So this increases our assurance that that port is still up. Great. Cool. So this was kind of a more exotic type of scanning, which is pretty interesting when you think about it, because you have this, basically, if you can boil it down to one difference in output, you can use this to scan ports. Cool questions on some of the kind of basics of TCP port scanning. Cool. So then so we can kind of, why would you use an XMS scan? No, we didn't really go over them. What they actually mean is not really important. It just, basically, somebody found out that this combination of flags and some TCP implementations will not send anything if there's something listening and it will send a reset if something is interesting. Why would you use it? One nice thing is we can see that a lot of less packets are being sent. Other things could be maybe like, let's see, some firewalls or something that's listening maybe there and easily can detect these kinds of scans. But yeah, so there we go. So yeah, but maybe an XMS scan, maybe it's not looking for these kinds of scans. I don't think that's exactly what push means. I think push is telling the operating system to tell the application on the other side, hey, send this data up as soon as you can, because it's ready to be processed. But it's more of a request. I don't think it's actually respected. But again, you can go look that up in TCP implementations. Cool. So on this theme of TCP port scanning, right, so we can scan to figure out what ports are open. One thing we also want to know is, well, what is that system running on that remote? What is that remote system running? So if we write what operating system is running there. And so it uses this key idea of differences and like one delta difference. So like here, different behavior based on a packet that gets sent. And so basically the interesting idea is we want to be able to fingerprint what is the operating system. So let's actually look at this. I believe it's very simple. I think it's dash. Oh, no, that's wrong. But let's see. H host discovery, oh, just dash capital O enable OS detection. So here I'm going to run OS detection. And look at this is pretty cool. So it scans some ports because that's the default. And it then told me that it's running Linux 3.x or 4.x. And probably is in 3.2 or 4.9. And then if I run this on my machine, which what was my IP address was dot 27. So I can run this against myself. The machine that I'm on right now. And it should hopefully tell me that it didn't work. Okay, that's great. Maybe it's because it's a local host that I'm doing this on where it's not doing that. But that's okay. Let's dump this traffic so we can look at it in a second. All right. Cool. Okay. So the idea is, if we've looked at and if you look at the TCP protocol, a lot of things are specified and that have to be specified for a protocol to work. So for instance, in things that we've talked about, right, if I send a sin packet from a client to a server, and if there's something listening, I will send back a sin act and they will send back an act, right? We've looked at all the different ways that packets are that this these protocols have to work. But we actually looked at a weird thing of like, what happens if somebody sends you a fin push and urgent packet? What does that do? Or what if there's a TCP? There's a port scan called the null scan, which doesn't set any flags. What do you do if you have a packet that has no flag set? There's all these kinds of weird corner cases that aren't specified in the protocol. So the RFC does not say what you should do if this specific packet occurs. And so because of this, by studying the differences between different operating system implementations, you can create these packets and be able to determine the version of the operating system based on the reaction to the packets. So for instance, what happens if I send, what happens if I send a fin packet and I keep sending data? What does the other side do? Does it reset or does it accept it? What if I send weird combinations of flags and TCP headers? How are the TCP window sizes that we didn't talk about this, but how do these things work? What about different error rates of ICMP messages, options? And so let's look at the traffic here. So let's see, we can see I'm send. Oh, this is all the sin scanning. I should disable that sort of an easier to tell. But probably let's go from the end and work backwards. Yeah, so here's some, here's ICMP ping and echo packets. Here's a UDP packet to a port. And then I got an ICMP destination unreachable, including all of this data, these Cs. Here's, wow, this is a weird packet. So here's a TCP packet with a sin flag set, an ECN echo, I have no idea what this is, a connection window reduced packet, and this reserved bit set as well, to a packet that it knows is open. So it knows that port 22 is open. And then it sends me back a packet, a SINAC packet with the same ECN set. That is fascinating. And maybe, and then it does a reset. So maybe on different operating systems, like maybe Windows doesn't set this ECN echo flag. And so it can use this to be able to detect exactly what type of operating system it is. So it uses all of these different types of detection techniques in order to detect this. And so one of the really interesting things is you can actually determine operating system version in a completely passive way. Just by observing the traffic, there are signals that you can use to determine the the operating system version. And so there's tools POF that you can download and play with that will listen to traffic and be able to figure that out. And so this is a super cool technique that enables you to really fingerprint different devices. Cool. Questions on OS fingerprinting? It's, why would you do it? So for instance, I have this IP address. So I now not only know exactly what ports it has open, but I now know it's running Linux. So let's say what if I knew that if I had an exploit for Linux 3.2 operating system, a remote exploit, I could just throw that at the machine. Or if I know it's a Windows machine that also gives me information about what services are running. So if it's a Linux machine on port 22, I would probably think it's open SSH is what's running there. If it's a Windows machine, but so I think it's a different machine there. Yes, so you can also that's why it doesn't say Linux 2.6 because it can detect that it's using some feature that's within Linux 3.2 and 4.9. So exactly, it can tell you and identify what different versions are based on when things in the implementation change. So this again is part of kind of remote reconnaissance. So you're an adversary, you want to try to break into a system, you need to know as much information as possible. What services are running that you can use port scanning, what operating system is it, you can use OS fingerprinting to do that. Okay, now we want to get to, so we talked about port scanning, we've talked about OS fingerprinting kind of in the reconnaissance. Now we want to move more into kind of the active phase of exploitation. So we want to talk about, and let's actually maybe we can think about this and discuss. Okay, so TCP spoofing, right? So I want to impersonate another machine. So let's draw a little diagram. Actually, I want to hold the page. Right. So here I have Alice. Here I have Bob. And they are connected to each other through the internet. And I am now, I am Eve. So now let's say I want to, the goal is thank you, I really pride myself on my internets. So the goal is we want to in spoofing, we want to impersonate a to B. Let's say B says, logins, logins from a do not require a password. And to be a little more precise, we'll say logins from IPA do not require a password. And so, so B has this trust relationship with A. So as Eve, we want to be able to log into Bob pretending to be a. So let's walk through, how do we got to do this? So, so what's going to be, let's see, we'll draw our little packets, source IP, destination IP, source port, all leave space for flags, sequence number, hack number. How do I do that? Okay. So now Eve is going to send a packet to Bob pretending to be a. Oh, snap. That's pretty nice. Huh. Look at that. Look at those boxes. All right, cool. So what's this packet going to look like? So he's going to send a packet from Eve to Bob. So what's the source IP going to be IPA exactly, right? So Eve wants to impersonate Alice. So she's going to send a packet IPA. So destination IP address, IPB, it's got to go to Bob, source port, could be anything. Let's use a 9999 and destination port we didn't talk about. So let's say port 22. So I'm going to talk to port 22. Eve will create some sequence number. We'll say she, let's say 10. Acknowledgement number is going to be blank. I guess technically zero, but let's say it's blank because it doesn't matter. There's nothing there. And then what flags will she set sin? Yes, exactly. Awesome. Cool. Okay. So Eve sends that out. That packet gets to Bob. Bob says great. Here's a packet from the great I have something listening there. I'm going to reply back. And so what does Bob's reply look like? So what's the source IP address? IPB and the destination IP address IPA. And the source port 22 destination port 9999. Bob will choose a sequence number. Let's say 40. And what will Bob's acknowledgement number be? 11. Why 11? Yeah, the sequence number plus one, right? So you acknowledge the other person's sequence number. It's kind of ugly. Right. So the sequence number plus one is what's acknowledged. And it always does plus one, but only in the sin sin act phase because of the weird ending this issue. Cool. Okay, here's the packet. Eve sends it out or Bob sends it out. Where does that packet go? Oh, sorry, sorry, we didn't do the flags. Thank you. Flags. What are the flags on this packet? Correct. Okay, thank you. Cool. Okay, so Bob sends this packet out now onto the network. Where does that packet go? It goes to a exactly. And so at this point has Eve successfully impersonated Alice to Bob, right? And, and this is very different when we talked about IP spoofing and UDP spoofing, right? Because in some sense, we only needed to get that that first packet, right? So in this case, it's a sin packet. But if it's a UDP packet, right, we would, this is essentially already impersonating Alice. But because we haven't completed the handshake, we don't know that this connection this connection is not actually correct. Or it's it hasn't been established yet, right? So even though we're able to spoof using because there's no protection in the IP level, we're able to spoof and specify this source IP address to be whatever we want, pretending to be Alice, Bob's reply actually goes to Alice. So now let's ignore for a second. When Alice gets this packet from Bob, Alice would be like, hey, that's really weird. Alice would probably send a reset, but we'll ignore that for now. So let's think in hypotheticals. So the AC, yeah, so the AC is technically zero here. But the point why it's blank is that it doesn't matter. It doesn't matter that there's any acknowledgement number in there. It's not used. Okay, so let's think about what packet would Eve like to send in like, let's say this is an ideal world packet. So how can Eve complete this handshake? What would the source IPV to complete this handshake? So if the packet was IPE, right, then that packet Bob would say, so that's actually, that's completely, we should have gone with this. But Bob would say, I don't know what this packet is, because it's not part of my four tuple, right, my four tuple of what makes a connection is source IP destination IP, source port destination port, right? So in order to complete this connection, we need IPA, we need the destination IP address IPB. We need the source port, what's the source port? 9999 destination port is 22. And now what's the sequence number? So it helps to think what was the sequence number in our first packet we sent, right, was 10, they acknowledged 11. So that means our sequence number now is 11. Right. And what is our acknowledgement number? 41, it's one plus the sequence number in the SINAC packet. Yeah, exactly. And then what flags are set on this packet? Cool. So in an ideal world, this packet would get sent from Eve to Bob. And now Eve has successfully spoofed Alice to Bob. So let's think about what is preventing this ideal world scenario. Yeah, the so if we think about what is out, what does Eve know from this, does Eve know the source IP? Yes, because she knows who she's trying to spoof in this original packet. Does Eve know the destination? Of course, that's who she's trying to impersonate Alice to the source port and destination port were both chosen by Eve, right? So both of these source port and destination port are both chosen by Eve. So Eve knows of them. What about the sequence number? Who chose the sequence number? It's not Bob, it's Eve. Yeah, Eve chose the sequence number here. Right. And she knows based on this connection, it will definitely be 11. Right. So Eve knows this sequence number from the very first packet that she sends. But where did this acknowledgement number come from? Yeah, this one came from Bob. This is Bob's sequence number. Bob generated the sequence number. So this goes back to what if, remember we talked about when we were talking about this protocol, let's see, what if every sequence number just started at zero, right? If every sequence number starts at zero, then would Alice, oh, sorry, would Eve know Bob's sequence number? Yes, if they all started zero, she'll always know. And so she'll be able to spoof this TCP connection. Right. So that's why that's essentially why we have this notion of starting with randomized sequence numbers, because the only thing preventing somebody from performing a TCP spoofing attack is knowledge of the sequence number. So if this sequence number and really this is this holds the entire key of preventing this spoofing is generating the sequence number. So if it's if it's easy, if it's the same for everyone, that becomes easy. If it's not exactly randomly generated, just kind of randomly generated, then that could be a problem. And so Eve's goal, the key thing to think about is maybe here, this is the crux of the whole thing is the sequence number. So for instance, if Eve never gets this packet, right, if Bob sends this packet to Alice, Eve never sees this packet. And this sequence number is random and unguessable, then Eve can't do that. So yeah, with a random sequence number, let's say, so she she gets one try. So I guess you can keep trying over and over again. You would basically have a payload in here that you could test if you were correct or not. So for instance, on SSH on port 22, you could have something that adds you to their authorized key list so that you can log in as them. And then you would just do this test, did it work, if not keep doing it over and over again. So you can detect as long as the attack gives you a way to detect. So she could guess she can brute force she could try doing that. And okay, or maybe she could guess it, right? So maybe, maybe it's not random. What are some other ways? So sequence numbers are I believe 32 bit is what we're talking about here. I'd have to go all the way back to here. Yeah, so sequence numbers are 32 bits. So it'd be a little bit difficult to get it to guess it. Right, you're talking about two to the 32 tries. I guess with enough time, maybe it'd be theoretically possible. But I don't know, I think it's your highly, highly unlikely, let's say. Yeah, but so if you so yeah, we haven't talked about this. So there's a couple things we can deal with this in a couple different ways. One, we could use a DOS basically denial of service a turn a off of the network so that a can't respond to be. We can also just be very quick if we're guessing. Basically, if you think he sends this, and then very quickly sends this packet, hoping that it arrives right after sends B. There's kind of ways to deal with that. But yeah, you do need to worry about a so that a doesn't send a reset packet. But because we can include data in this packet, if this is our payload, then that's actually pretty good. Cool. So it's not worse than two to the 32. Because let's say you just keep your sequence number static. I guess it is technically worse than two to 32. Yeah, I don't know, probabilities. You can just keep trying it. Eventually, I guess there's a chance that it would get get correct. I guess you'd be expected to do it into the 32 tries. But yes, you're trying to guess a 32 bit number. And these are kind of slows too. So that would be a problem. Okay. But what are we going to do? Yeah, we'll talk about tzb hijacking in a second, but we need to study this first. So okay, so this is the ideal world. We're basically saying, okay, we basically can't guess this already. So what does Eve need to do? So how can you even sure that she knows the sequence number? Any thoughts, right? So this packet, the SINAC packet comes back from B to Alice. Yeah, what if we what if we change Eve's maybe let's think perspective, and rather than just being connected on the internet, what if she's on the local network with B, right? And then, then if Eve is on the local network, she can use things that we talked about already of like our poisoning in order to steal the packets outgoing from B, right? So if Eve can look at all the packets that are outgoing from B, she knows the sequence number, and she can even drop this packet. And in order to impersonate a similarly, Eve could actually be on the local network of a. So if Eve is on the local network of a similar logic, she can use our poisoning in order to steal all the packets that are meant for a, and in this way easily impersonate B and easily get this packet that she needs to, right? This is the key packet. This is the key packet that she needs to get in order to read this sequence number, right? So, or the other vantage point, if we kind of think about all the hops that happen on here, what if Eve is somewhere on here, right? What if Eve is able to see the packets, maybe she's compromised a switch in the network, right? So she's not on either the local networks, but she can see the data that's coming back and forth between the two. And in this case, she could also get this sequence number and in order to send this packet. So in all these different ways, and this is why we looked at first local network attacks, because they're so powerful as a starting point in order to leverage and go further to do TCP spoofing attacks. So yeah, if we look at this, basically the step zero, we can kind of walk through this slightly in this form that we've been looking at. But you can do this. That's interesting. By first, so if this is the client, if C is our attacker, and they want to impersonate B to A, we first send a denial of service attack to B. We send a SIN packet from spoofing to B from B to A. They reply back with a SIN ACK, which B never responds to because they're out. And then we send a spoofed ACK packet that completes the connection. And this has actually been a well known problem. And you can read a lot about it. This has been known for a long time because sequence numbers were not very random in a lot of systems. So it's actually a big problem that they had to address over time is that the sequence numbers were not randomly generated. And so by talking to a remote machine, you could kind of guess and figure out what the next sequence numbers were being, decreasing your guessing chances from 2 to the 32 to something much more manageable and actually being able to do this. Oops, sorry. Yeah, so this was a super interesting. This has been known since like 1985, a weakness in the BSD Unix TCP IP software that the entire security of this system hinges on guessing these sequence numbers. Cool. And then, like we were just talking about, we can actually extend this in again to hijacking. So in this case, rather than spoofing, remember spoofing is we're pretending Eve is pretending to be a to B. So we're spoofing B hijacking is there already exists a connection from Alice and Bob. So there's already a TCP connection between the two. And what we want to do is inject data into that command. So we want to inject something so that a things be sent it and b think a sense it. And so we can do things like and again, it all comes down to guessing the TCP sequence numbers and acknowledgement numbers. This is a little more difficult because you need to get both directions, right? So Eve doesn't initiate this connection. Eve. It's an already established connection that has TCP and sequence numbers going. So you need to in order to inject any data. And some things you can do is you can just send a reset packet. And as long as the sequence and acknowledgement numbers are I wonder if you need that maybe you just need port numbers, but you can send a reset packet to kill the connection. It's like a denial of service type of attack to attack the availability of the system, or you can insert data into the stream such that the other side thinks the other one sent it. So in order to actually think about how we want to do this, right, if we're going to have to guess sequence and acknowledgement numbers or get it correct, we first want to wait and this is kind of silly. We want to okay, let's cool. So we want to first wait until the connection is quiet. So what do we mean by quiet? Let's see. Okay. So I am going to draw a whole new picture. Alice, Bob, and they're talking over the network. I hope that's better for you. And then let's say Eve. Let's say is on the same local network as Alice just to make this slightly easier. Cool. Okay, so we're not going to walk through the details of every single packet that gets sent. But let's just think a little bit. So we know, let's say the connection is initiated from A to B. So A sends a SIN packet B then sends a SIN AC packet and A then sends an AC packet, right? So again, they're talking back and forth, they're sending data back and forth, there is now a connection from A to B. And we want to inject traffic in it. So one of the easiest things to do is we want to wait until the connection is quiet. And what that means is both sides have sent data, it's both been acknowledged, and nobody's currently sending any data. So let's think about, so we'll think about the very last packet that we see. So let's say it's a packet. There we go. Cool. So source IP is from IPA destination IP IPB. We'll say that so why would it be why would it be let's say not SSH? Well, let's say why would it be useful to inject data if let's say A and B are having a remote connection? So let's call it we'll use telnet for right now. So we'll say it's a telnet connection, which is essentially SSH without the security. So without the cryptography involved. So why would I want to as Eve, why would she want to inject data into a telnet session? Yeah, to run arbitrary commands, let's check. I think it's port 21 23. Okay, close. Port 22 is SSH. Okay, so the very last packet. So it's an act packet. And just some random values. Okay. So the last packet was just an acknowledgement packet came from a to B that had no data that just said, Hey, I've, I'm acknowledging that I've seen for you up to 7831. And sorry, I'm acknowledging that I've seen up to you of 21 55 and the last that I sent you was 7831. And both sides agree, that's where they are great. So we get this packet. So this is a real packet from a to B. So this packet gets sent. Eve sees this packet. Now, Eve wants to send a packet that says, let's see, what do I want to do? Well, let's be really nasty. No, that's not very fun. We want to give ourselves access to the system. Whatever, we'll just say hello world. And a new line, I'll add that in there. So this is the data that we want to inject from a to B. So now we're Eve. So now this packet, we're going to be pretending to be a. So we want the IP address to be a destination address is IP address B. The source port is going to be 9988 destination port 23 sequence number is going to be what it's not going to be random. There's a communication already in process. So what was the last packet that we got? The last packet that we got, we send our sequence number was 7831. And we sent no data. So that means our sequence number is 7831, right? This is an existing connection. We only increment the sequence number when we send data. We sent zero data in this packet. So our sequence number will remain the same. It'll be 7831. And again, the acknowledgement number, we haven't seen any new data from the other side. So it'll be 2155. And we will have the act fly will be set. I'll separate this out a little bit that this is the this is the data that we're sending. So here we have data and here we have no data. So this is why the sequence number doesn't change between these two packets. Does that make sense? Thank you. So we'll talk about this in a second. So yes. So after we send that now we've sent 1234567891011121314151617181920, we've sent 20 bits of data. So now our sequence number is 7851 is what we'll think. We basically always send once the communication is established, we always set the act flag. So we're always acknowledging the last thing that we sent. Because let's say B sent us something in between, right? This way, we're telling B with every packet we sent what we think their sequence number is. Exactly. The act flag is part of the header. It does not count as data. Exactly. So this is kind of why I drew it here. So this is the IP header. This is the TCP header. And here's the TCP data. So if there's no last part, there's no data of the packet. So the sequence number does not increase. Good question. Okay. So Eve sends this packet. This packet goes to Bob. Bob gets this packet and it goes, okay, cool. So then what does Bob send back? So Bob source port IPB destination port IPA source port 23 destination port 9988. And Bob sequence number, remember, is 2155 from this acknowledgement. So it'll be 2155. And Bob will say, Great, I have seen up to 7851 because I just got 20 bytes from you. And so that's what I've seen so far. We need one more, we need the ACK. And it's going to send a zero byte packet just to acknowledge Yep, I got what you sent great. So Bob back to a cool. And then so Eve gets this or sorry. So Eve's already got done the damage, right? We've already executed this payload on the system. Everything's great. Then what is a gets this packet? What is a going to send back? So let's say Alice gets this packet back, right? Alice will say, Bob, what are you talking about? You're crazy. I haven't sent you up to 2155. Alice will send back. They won't reset, it will say, I don't know what you're talking about. It says, Bob, the last thing I sent you my sequence number is 2130, why do I say five? Is it actually no 78 sorry, 7831. And I acknowledge that I've seen up to you 2155. And it'll send that back as an ACK. Alice will send this from Alice to Bob. Yes, this is coming from actual Alice. So this is coming from Alice to Bob. Oh, sorry, thank you. And then when Bob gets this, it goes actually no, the last thing that I saw from you was I acknowledge that I've seen up to 7851. And then Alice will say, Bob, what are you talking about? The last thing I sent you was 7831. And this will literally continue forever until one of the packets gets dropped. And then they say, okay, great, that's what I thought. So we've essentially if you think about it, we've desynced each of their views of where they are in the TCP stream, right? Bob thinks that Alice is at 21 is at 2155. But no, no, sorry, wrong one. Yeah, Bob thinks that Alice is at 7851. But Alice knows it's at 7831. So they literally just keep sending back these ACK packets back and forth until one of them gets dropped. And then so this is called an ACK storm. So they just keep sending packets back and forth. And they actually cannot communicate now between each other because they don't know where they are in the TCP stream. And they don't really know why this has been this is actually a problem. And so we can actually get around this by if Eve acts as a man in the middle of this communication, Eve can actually translate the sequence numbers and acknowledgement numbers back and forth so they can continue talking. Or let's say if Eve has done her dirty work, she can just kill the connection, send a reset packet to stop things. So this is kind of like, I didn't want to send this, but this basically goes on forever, this whole process of acknowledgement packets. And it's this idea and this notion that we've desynchronized each one's view of where they are in the TCP stream of each other. So we can do this. And again, it again, requires us to be able to know the current sequence number and acknowledgement numbers, we can't do this unless we're in a perspective where we can actually view these things. And this then allows this. So the benefit here is I've been able to take advantage of a connection between A and B. I didn't have to impersonate any of them. What I was able to do was inject my data into the stream. So in this case, yeah, I know it's it's over. I'm just gonna I want to finish this because right in the middle, I think it'd be more of a pain to boot this back up and finish five minutes. So what I want is to inject this payload or another way to think about it, if Alice is your machine, and if B is Google, and I'm able to inject into the HTTP response and the HTML of Google, I can steal your cookie, I can impersonate you, I can execute JavaScript on your browser, I can do all kinds of really nasty things, pretending to be Google. So this is part of the reason why encryption is so important. So here in something like Telnet, there's no encryption here. So I can just inject this data directly. But if I was using something like SSH, I would not be able to. But we can see that we can hijack connections, but it's much more difficult than in the IP and the UDP time. Because there, we just could send a packet, we didn't need to know these sequence numbers and acknowledgement numbers. So these are really kind of the bedrock of this, surprisingly, the bedrock of the security of the TCP layer is these sequence and acknowledgement numbers. And this is why local network attacks are so important is because you can leverage them to do these higher level different types of attacks. Cool. All right, so we'll stop it here and we will close out networking on Thursday. You'll get your exam grades very soon, I promise. See you. This was fun.