 That's first chat very briefly. I posted this in the Discord, but I wanted to make sure people had a chance to see this. So these were the summarized results of assignment three. You should have already got an email with your, with how you did on assignment three and all the other assignments and midterm. So we matched all those up into a grade book. So now we can keep track of everything. So pretty good. Like the amount, the app, I think the people who turned it in had a roughly an average of 30 plus signatures. That's very cool. Of course, we're not really interested in the successful people doing this. We're interested in the scammers, right? So it was actually kind of an interesting rate. So of the 400 something people that submitted this assignment, less than 10% decided to scam. So with just 34 people scamming, we actually had, I didn't do the total number. Oh yeah, total number of victims. So these 34 people were able to scam almost 200 people. So roughly half the class fell victim to at least one of the scams. Interesting of course is the average, the average number of successful scams per scammer was 11 successful scams. But of course this shows you why you shouldn't trust the average because it's insanely skewed, right? You can see that these are the top 40, I think. So the top scammer had 91, which is pretty good. It doesn't beat the record that was set last year, which I think was like 120 or 130. And so, I haven't reached out to that person yet, but maybe I'll do that. I can give us a little brief update on Thursday or something, but. So yeah, you can see that the scamming is very top heavy, right? It kind of follows this power law distribution where it starts with like 91, then goes down to 59, then 37, 36, 21, 15, 14, 12, 12, 12, 10, 10, and then pretty quickly down to one, right? So not a lot of scammers. So you have this kind of, this scamming is dedicated to these kind of top scammers, which I thought was really interesting to look at here. But the interesting thing is the victimization doesn't go the other way. So I think it kind of makes sense based on the nature of the assignment, right? So if you're trying to get your signatures and you're probably not gonna fall victim to all 34 scammers, right? That kind of doesn't make sense. Like how are you going to, unless you get, I guess, really, really, really unlucky, but that all scammers are operating at the same time in the same way and are targeted in you or you happen to fall victim to them. So the victims actually has a much more like straight or flat distribution. So we can see total victims, like 196. That's actually pretty good. So like the average person that was victimized only signed two fake keys. It's actually pretty good. Like if you think about it, so out of 30 keys that the average person signed, what's that roughly one out of 15 or something like that? I don't know that percentage, but it's a pretty small percentage of keys that were signed incorrectly. And then you can see, so then you can see the distribution here of the top victims, right? So 86543, it kind of goes to the three and then there's a bunch of twos and a bunch of ones. So you can see there's like this long tail of people who just fell victim once or twice to one of these scammers. And maybe that was you, but that's okay. That's this part of learning about how I think you all understand a lot better now of how to maybe try to verify identity. What are the ways that people can alter misinformation such that, and we talked about this before, so I'm not gonna get into all the details and all the tricks and techniques that people use. I just think it's interesting to see that even people who, and I don't know who these people are. These are just numbers right here. So if it's you, this is nothing personal. I'm not talking about you specifically. But people on probably the eights, I would guess they probably waited for the last moment and that's when there's more kind of scammers out there who are trying to get people. Whereas I think if you started the very first day there are likely very few scammers. So you're just opportunity of being scammed, right? Is much lower. And this kind of goes to the emotional factors that can play into getting scammed or getting phished if it's something that's affecting your job or it's something that you are like panicked, you're much less likely to detect something as a scam. So anyways, this was interesting to share. Yeah, I know this is in your email, you said that each signature was worth 1.28, so you're okay. It was, it adds a little bit of leeway to the things because sometimes you don't know whether that adds leeway to like signing adversarial keys and those kinds of things. So I like to add a little bit in there, but yeah. But I don't tell you that beforehand because then you would just do the bare minimum, right? Oh, was that when they start 30% while I set more keys I have to do the right chart? That's good though, that's, you know, I think that's good, right? Hmm, pretty good in the zoom chat. They're scammer, they've got scammed at 2 a.m. when they only had one signature left. So yeah, this is exactly precisely the moment where you're more likely to fall victim to a scam because you, because you're almost at the finish line you have that last one to do. Yeah. Those are not counted on here. So these are only real signatures on your ad, real signatures from real people on your adverse. So that's kind of the information discrepancy and the assignment, right? You all don't know which ones are which, but I actually do know because you upload them and so what I do to grade this is I get all of the submissions. I know exactly whose key is the public key, whose key is the real key, their adversarial key, and then I can keep track of the signatures on each. Yeah, so no, these are just signatures people who signed with their real key on an adversarial. And also we're in the class, right? So you could, I think some people use this technique that they artificially inflated their signature account bank by making a bunch of fake signatures on their key, pretending those were from other people in the class to show proof that like, hey, look, I'm doing this assignment. My key has all these signatures on it even though those are all adversarial. I mean, it's their adversarial key and they have fake signatures on there. So those obviously don't count as part of this calculation as well. What homework? What are you people talking about? Yeah, you guys are getting scammed. Okay, cool. Say that again. When I know it's down to people, I just don't think I ever used my adversarial to sign with this. So it doesn't count towards their signature bank. I believe so, I actually can't remember exactly how that's calculated. I may be very generous and I think it's calculated where those technically count, but in the assignment description, it's not supposed to count. Cool, all right. And then let's get back to networking. There's no homework assignment is released yet. Okay, sir. Getting all ahead of yourselves. Okay, cool. Okay, so we talked about TCP. Somebody remind me and remind all of us, what is the TCP three-way handshake? What's the first packet that gets sent to start a connected? SIN, so first packet is a SIN packet and this includes the requested sequence number of the client. And we know that the client because they're initiating the connection to the server. So when the server gets back, gets sees that SIN packet, what does it reply with? A SIN act and it specifically acknowledges an increment of the sequence number that it was sent and it generates its own sequence number. And then what does the client do when it gets this? Yeah, replies back with an act and it acknowledges the sequence number that was sent plus one and now they can communicate and send data. Cool. So we discussed this, how all this works. And now the question is just like with UDP. So we could do a UDP port scan by identifying what ports were open. What's the point of a port scan? Why do we want to do it in the first place? Yeah, louder. Find out which ports are active? Yeah, find out which ports are active. So which ones have services that are listening on them? Those are places where we can send data into the remote system. So we want to be able to scan a system and be able to know, oh, it has these ports open. This is again, like we use the analogy of breaking into a bank. This is that first step of that process where you have to analyze and say, okay, what are the possible entry points into the bank? We're doing reconnaissance of the bank. So just like with UDP, so UDP we had an interesting mechanism where we would send UDP packets to the port and then depending on the remote system, if it would send us an ICMP port not available message then we know for sure it's not available or we'd have to use different behavior depending on how long those things are open. So we want to do the same thing with TCP. So we actually really love the concept of port scanning because what, so for every port on the system, how much information do we want to learn about that? What are we trying to learn? If it's open or not, right? That's basically it. How many, if you were to represent that in terms of bits and bytes, how much information would you need to represent that? One bit, it's not a trick question, right? It's a one or a zero, like the most fundamental thing. Either the port is open or not. So all we're trying to do, and this is there's a series of super cool techniques here about how do we determine this single bit of information for every port on the remote system is something listening there or not. And so we have, so this is super cool. And you can see that there's tons of different ways that we can do this all to derive that single bit of information. So the first thing is what does knowing what ports are open tell us, right? A port is just a number, but just like IP addresses are just a number, we oftentimes want to associate human-identifiable names to that number. So if we go to, oh, good, it's mirrored. Oh, that actually worked well, okay, cool. So if we can't, ETC, whoops, no, services. So this is Linux systems have this ETC services file. You can also go look online for the allocated port numbers to services. And so you can actually see port, and I don't know what DDP is, that's interesting, but TCP and UDP are here. So the way to read this, these are all old protocols that really don't work. Okay, FTP is pretty good. So FTP, port 21, either UDP or TCP. So if you see traffic on port 21, likely it is FTP. Does that mean that it is for sure FTP? No, because any application can listen and send out on any port, right? Like this is just for ease of use for a client talking to a server, similar SSH. So when you're SSH into that system, you're talking on port 22. So port 22 is most commonly the SSH port. Telnet is port 23, Telnet is SSH without the security. So you can actually see every keystroke that is sent. SMTP, so how email is sent is on port 25. Let's see, any other interesting ones? A RAP port, probably doesn't do what you think. Oh, Gopher, Gopher was an early HTTP-like protocol. HTTP, there we go. So HTTP is port 80 by default. And if you look at HTTPS, that should be a 443. So you can actually just look through this and it's kind of over time, you get a feel for which ones or which names, yeah. So yeah, fingers away to ask a server for information about the users on that system. So each user on that system could set up a file that would say information about themselves. So if there was a server for the CS department, each professor could have a thing and in their file could say when they have office hours and what their office is, their phone number, all these types of things. I would highly doubt that anything is actually running the finger daemon. It's called finger D. Actually one of the first internet worms, which we're not gonna talk about here, spread through vulnerabilities in finger and other services. I remember when people just use IRC and have to figure out... Yeah, yeah, exactly. You could figure out what IP address they're coming from and then use that, but let's see. I mean, things that are more in use like SQL, although I don't know why these are all different. Oh, probably, yeah, MySQL. So like port 3306 is the default MySQL port. Anyways, you can just always look in here of course it doesn't guarantee that it actually is like that. And so the simplest form of TCP port scanning is very, very simple, right? We wanna get that one bit of information. So what do we do? We try to make a TCP three-way handshake for every single port on that IP address. So we first try port one, port two, port three, port four, how many bits in a port number? Yeah, 16. So two bytes. So how many possible ports are there? Yeah, 65,535. I'm gonna cheat. I just cheated by looking at that in the chat. Hopefully that person's correct, right? So what happens? Then the key is for everything where you're trying to get one bit of information, we need to think. So I send a SIN packet, I get back a SIN AC packet. I send an AC packet back. At this point, I've established the connection. So do I now know that that something is listening there, that that port is open? Yes, because I reached the third stage of this protocol. What happens in the negative case? So what happens if the port is closed? How will this change? Louder? How will it change? Yeah, we won't get a SIN AC back. We'll get either a reset or nothing. So we'll send a SIN packet and we'll get, we will not get a SIN AC back, right? The SIN AC from the server is an acknowledgement that says, hey, yes, something is listening and we want to talk to you. So we can use this in our port scan. So we can just use the system, the system call for this is connect. So connect is a way from user space that you as an application can ask the operating system, hey, please connect to this IP address and this port on TCP. And you just try opening up all of these connections to the victim host. So if it's successful, and let's actually look at the man page of connect because I don't remember it off the top of my head. So initiate a connection on a socket and remember sockets, we can open them, close them, whatever upon completion of value of zero return, otherwise negative one is returned. So I can fail in a bunch of different ways. So actually all you just do is try to connect to and the socket remember is going to be the IP port pair. So we just try connecting and depending on what this connect system call returns, because the important thing to remember is that it's the operating system that manages this protocol of SIN, SINAC, ACT, all it tells the application because it'd be insane to write an application that had to deal with that whole complicated protocol every single time. So the operating system deals with this. Now, so the advantages as we'll see is to be able to craft custom packets. You actually need to be root often. So you need to be root in order to craft a custom packet. And so using connect, you don't need to be root. You can just connect to any IP, any port and be able to determine if it's up or not. What's the downside here of doing this? It's only a lot of packets. How many packets exactly? Well, roughly. Yeah, at least 65,535, at least that for one port, let's say they're all open, right? You'll generate three times that amount, a SIN, SINAC, ACT, and then maybe you need to close it so you send a reset or a close or a fin and then it would send a fin, right? There's a lot of information that has to flow between each side there. And even if things aren't open, depending on how it's open or closed, if it tells you that it's closed, that's less packet. It's probably just two per close. If your system has to time out, it may keep sending a SIN packet for like 30 seconds. So it may send a SIN packet every five seconds for a minute, just trying to connect to that port. But we can actually look at this. So we can use, there's a great tool called Nmap. And let's, yeah, so we can use the tool Nmap. So Nmap, the dash lowercase S, oh, it has a lot of options. I don't remember what lowercase, I think ST is a connect scan, but let's actually look at that. So we'll install Nmap, we'll read the Nmap man page. It was dash ST, so tcb connect scan. So tcb connect scan is a default tcb scan type. Yeah, so the dash ST is its own thing. And you can redo this to see every type of crazy scan. This is the case when a user does not have raw packet privileges. This means when we're not root, it asks, instead of writing raw packets, Nmap asks the underlying target, underlying offering system to establish, blah, blah, blah. All right, so we can do, what's on my network? See, where's my gateway? Oh, cool, there it was, this is in my lab network. Yeah, that's fine, still should be good. So let's do sudo, okay, we don't need sudo. So we just do Nmap dash ST, we give it an IP address. It's gonna do some stuff. We'll look at what it's doing in a second. And then it tells us what it's doing. And then it tells us, hey, I just scanned this IP address 1090.91 and it has SSH open, it has HGP open and it has HTTPS open, right? Again, it's only saying these service names because of that file you can see hosts. It's not using anything there. And so let's, there we go. Okay, all right, so now I have two terminals. I'm gonna do, where's my, yeah, E and zero. Okay, so I'm gonna use TCP dump and I E and O zero. Probably as if I do this, it will show all of this traffic rate. We didn't have this before, not port 22 TCP and okay. I think this means there, so it's gonna scan, yeah, cool. So now we can kind of parse through these results and see what's going on. So it actually is pretty easy to understand if we just go through this output here. So yeah, so we can see this S flag. So we're sending a ton of SIN packets, right? So this is from my IP address 1090.79.177 to 1090.91.1. And 106. And you can see it's got some slight smarts where it's not going in order. I think it's picking random IP random port numbers or it's permuting it. So it says, oh, it says HTTP is closed. Ah, interesting. Thank you. Okay, so it says SSH is open. And let's see, I think I can search for this. If I said dot 22. Keep searching. Yeah, I don't usually use, it's like the less finder dot 22 call. Not 22 call. No, it's going all the way up. We'll look for this SIN packet. This would be much faster. We will do something different. Oh, we said not port 22. Okay, yes. That's why we didn't see it. That makes sense. Nothing else is open here. I'm just going to start scanning other systems. This is my network. So I can do this. Don't do this on something that you don't control. You scan your work network. You can do whatever you want. There's a way to scan ping. Yeah, there we go. Ping. No. We can do this. I think you can put as a target like a slash 24. And then I think it'll try scanning all of those IP addresses. So let this run to see. What it shows us that is open that is not port 22 or a different system. There we go. Awesome. 90 90. I think that's me, but that's okay. Cool. So then I can do. 10.90.90. Now we'll just do that one. Okay, cool. I can see that when I sent like a packet to 3, 7, 3, 7, 0, I got back a sin packet. Okay, let's open 22. And we will just. Okay. This will just show us the port 22 packets. All right, here we go. So we sent a packet to 10, 90, 90, 90 port 22 a sin. It replies back with a sin act. And then we reply back with an act. And then we reply back with a reset because we're done talking to it. And then we'll just tell us that port 22 is open. And if I run the same thing with port 21. I will see that port 21. The other side send us a reset. So this is getting back to, this is that one bit of information, right? The fact that it gave different information in these two cases shows us this technique. Cool. But we know. So let's think conceptually here. So at what step. So we have this three-way handshake, right? So if we send a sin act at what step of this process, do we know that the other side is open or not? The second step. So if after we send a sin, if we get a sin act back, what does that mean? It means sitting. It means they're willing to talk and that there's that port is open, right? For our purposes. What if we get like anything except for a sin act? We know it's closed. And do we need to send this final act back? We need to, right? The operating system will automatically do that for us. But if we tell the operating system, Hey, I want to send raw packets. If we're root, we can do that. And it will let us do that. And so this is called TCP sin scanning because you're only sending sin packets and you're just looking at what comes back and you never send that third part of the handshake. So it's also called half open scanning because they're the connection to the remote system is left in a half open state. So if we want to send back a reset packet, we can send back a reset packet. We can send back a reset packet. And as an attacker send the sin packet. The attacker sends back a sin act packet. If the port is open or we usually send a reset. If the packet is closed. And then instead of, if we want to be nice, we don't have to leave the connection open. We can send back a reset packet. I think this is done because the other side will keep sending the sin act back to us until it times out. So we can send back a reset packet. And we can send back a connection. And the cool thing is because we never reached the end of this sin, sin act act, whatever application is listening, never gets an event that says, Hey, somebody wants to talk to you because when we connect to it and we go through that final handshake, the operating system has to tell SSH or TPP or whatever, or sorry, SSH or the HTTP server. Hey, I want to talk to you or somebody wants to talk to you. Like you, here's a new connection. Whereas if it never gets there, it just, it doesn't ever talk to the application. So we can do this. Let's look at what the, it is dash SS. So let's look here. Point two or. No idea if this will work. Let's see. Dash capital SS. So I won't let me do this as normal. It's, you can't see that. Okay. So it won't let me do this as normal user. It says, it says I'm requesting a scan type which required privileges. So I will run this as pseudo. Okay. It ran the sin scan. And now we can look here. So for port 22, it sent a sin. It got back a sin act. And then it sent a reset packet. Right. Which is exactly what we wanted. Now in the case of port 21, which we know is not open, we send a sin packet and we get a sin reset. So now we're much, we're now much less noisy, but again, a different kind of way just to extract that one bit of information per port, which is what I think is the super cool thing here. Cool. And there's, you can read the end map things. There's all kinds of crazy options here of what happens if you send a, what happens if you send a packet. The interesting thing is it all depends on the implementation of TCP, because you can do things like what happens if I send a packet with the sin flag set, the act flag set, the push flag set, like every single flag is one. And as long as there's any difference in response, depending if there's an application listening or not, I can use that as a way to detect. So let's actually look at that real quick. Cause I think this is super cool. Okay. Yeah. So the TCP null is basically like what happens if there's no flag set. And some operating systems will send a different packet. If there's something listening or not. Finn X this is a, it's a silly name, but it's named after like a Christmas tree because like all the packets flags are set. So like it's all lit up. The packet is lit up. So we can look at that here quickly. And here you get less information like filtered because it doesn't know that it's actually open or not. It just knows the other things are closed. Let's. Yeah. Let's do it again. So it's easier to see. Okay. So we can see for port 21. We sent a packet with the fin flag, the push flag and the urgent flag set. And for port. 21. We got back a reset. So it's telling us in the case of port 21. We got back to port 21. We got back to port 21. Hey, go away. Now, when we sent this a thin push urgent to port 22. It never replied to us. So what did we learn in this case? Which of these two ports is actually open. Say it again. Which port 21 or 22. We go back here. Port 21 was FTP, right? Port 22 is SSH. So we know from previous scans that it is open. But we can see that there's different behavior here. Depending on if it's port 21, which was closed, the operating system actually sends a reset. Whereas if that port is open for port 22, it doesn't respond at all. Which is kind of crazy. I don't know why there is this difference that exists, but it does exist. And so the fact that the other side changes its response to us, depending on if the port is open or not means that we can determine. The key problem is and why and that tells us that. It says it's open or filtered. Because it doesn't know if that packet to port 22 just got dropped. Or that the response didn't get dropped. Right. We, all we can know is the information that we get when we get that, when we get a response. And so a packet not getting a response doesn't necessarily mean that that system never sent the response. It just means that we never got it. That makes sense. Or they never got our request, right? It could go both ways. It could go both ways. It could go both ways. Like think if I had configured my network. To block all port 22 traffic and just drop it and never reply. If you did this, you wouldn't know if that was happening. And that's why you weren't getting a reply because they never got it. Or for a different reason. Cool. Okay. The other thing that we can do that's very handy. So why would it be helpful to know what operating system. Your target machine is using. I mean, if I know what version it is, I may be able to look at metasploits or other types of things that have no vulnerabilities. A lot of vulnerabilities have proof of concept exploits that I could build from. So maybe that's how I get into the remote system. I may be able to then mix that with. Cause you could have something like, I think Apache runs on windows technically. So if you see that, there's an Apache web server. And it's like, I don't know what operating system. And actually may be more difficult to try to identify the version and everything. So the key thing that we can figure out here is because this, this whole TCP connection, right? This three-way handshake, the virtual data exchange, everything. Because this happens at the operating system level. Any subtle differences in there between how they respond between different operating systems can tell you which version it is. And which operating system it is. So this is super cool. We can use this to what happens if we send, if they send us a fin packet, but we keep talking, what do they do after that? What if we send undefined flags? What if we just sent a weird flags? What happens then? What if we send weird combinations of flags? All kinds of stuff. The TCP window size is something we didn't get into, but it's something that is standard for most operating systems. Do they send us ICMP messages or not? All these type of things go into, and so there's tools like P O F is a tool that can just listen to a network dump and give you an estimate as to the operating systems of the hosts involved, which is kind of insane when you think about it, right? All you have is network traffic and, but you can infer the operating systems and possibly the versions. The other cool thing is NMAP will do this. I think it's dash O. Yeah. Dash capital O is enable OS detection. So if I did this dash O, it will then send a bunch. Now this is an active thing. So it's actually sending packets to it. Should be. Oh yeah. We can see it's sending a bunch of packets. So, oh, sorry. It doesn't know exactly what version it is. That's weird. I'm kind of positive it's a Linux machine, but I'm not 100% certain. Yeah, there we go. This is more what I expected. So this is a, so it's saying that, hey, so there's a different possibilities of what it could be because the responses that it got. So you can think about like NMAP basically has this database of this big like tree that says, okay, if in this situation they do this, it means it's this set of operating systems. So you can build this really cool tree to kind of like search for what type of system it is. Let's do. See if it gets any better guesses, but has conditions not ideal. What do you mean? Maybe something's getting dropped or something, but anyways, this definitely tells us it's not a Windows machine, right? It's telling us that it's a Linux machine. It also tells us it's not free VSD or anything else weird. I hope I'm not ruining anybody's experiments with this, but there's so many things that can happen. Okay. So this was the weird one that we don't quite know what OS it's running. I don't know what OS it's running. I don't know what OS it's running. I don't know what OS it's running. So this was the weird one that we don't quite know what OS it's running. Oh yeah, here's a cool one. So it's telling us it's exactly, it knows exactly precisely what operating system is running on this machine. It's Linux kernel 3.2 to 4.9. So I could maybe use other things, figure out what's running on there. We could see these ports open. Why is there that port open? I have no idea what's going on here. SMTP seems like a bad thing to have open, but what are you going to do? Oh, this is cool. So look, it even determined that this is a switch. So it's a Cisco embedded switch. So maybe there's vulnerabilities for the switch that I can then use to propagate from there. Telnet is open on that switch. I'm sure that's great. So yeah, anyways, I think that's pretty cool. So like you can determine all this information from here. Just from running tools and understanding the way they do these things. So that's pretty cool. Questions on the port scanning or fingerprinting. Now we want to turn our attention to our favorite kind of attack spoofing. So what was the point of. UDP spoofing. When we looked at the UDP spoofing attack. So we can pretend to be somebody else's IP. Yeah, exactly. Right. So we can either with UDP, we can maybe pretend to be the client or the server, right? Depending on what our goal is, what our target is. So we want to do this, right? So that's a cool idea. So we want to. We want to do this. TZP spoofing. Right. So we want to impersonate another host. So again, when there's a trust relationship between IP addresses, we will, we'd like to impersonate. Another host when we establish a TCP connection. This is an insanely old attack. Published in 1985. Where this was first discussed. and kind of going on roughly ever since. So, okay, how do we want to do this attack, right? So, right, so there's some trust relationship here depending on IP addresses. So, node A, trust node B, this could be firewall rules that specify like, hey, only connections from this certain IP address are trusted, that could be all kinds of things. No login from certain IP addresses. And we as an attacker want to impersonate B with request to A. So, we need to first kill or take offline the person we want to impersonate. The problem is, as we'll see, any connections that get sent to them is, let's look at a diagram first. I think that's actually gonna be better. Okay, so we have our, we have a trust relationship between A, which is 211-356-5 and eight. So, 138-132.67. So, first thing we want to do is send a denial of service attacks. And so, we first want to make it so that that system doesn't respond. So, we can either send a bunch of packets to it, we can do this in a variety of ways. Then, we want to spoof a SIN packet as if we were from B. So, as if we were 13, 138-132-672-211-356-5 and to this port 513, whatever that port is, it doesn't really matter. And we create our sequence number. Is there anything stopping us from doing this, creating the second? No, right? Just like business classic, just IP spoofing, right? And UDP spoofing. We can spoof any packet. We can pretend that it comes from any IP address. Now, when A gets this, what's it going to respond with? It's going to respond with a SIN act to B. And it's going to say, okay, hey, great, I'd love to talk. So, it will send an IP packet to port a two IP address 211-356-5, the IP address for spoofing. Send from, sorry, this is the from. So from 211-356-5 to 138-132-672 that IP address in that port. Now, so B doesn't get this because it's down, right? It like doesn't get this packet. What do we as the attacker, as C, need to respond with in order to finish this communication? Yeah, we need to respond with an act packet. And specifically, we need to acknowledge their sequence number plus one. So we need to send a final SIN act packet with 54003 because we'll use their sequence number plus one. And so if we're able to do that, right? We'll talk about how we can do that in a second. But if we're able to do that, and we send an act packet from spoof it from 138-132-672-211-356-5, with our sequence number, which was 111-001. Do we know our sequence number? Yeah, we came up with it. Their act is 54003, which now here's where the tricky part comes in. So does this packet come to us automatically? No, right? Because it's going to our target. It's going to be, right? So by default, it shouldn't come to us. So how do we find this acknowledgement number? So how do we, or guess this sequence number, right? We could guess. Just guess, right? How big were the sequence numbers? I actually don't remember myself. Let's go look at the packets. So how big are the sequence numbers? 32 bits. So how many times would we need to guess to guess correctly? Yeah, 4.2, two to the 32, right? Or technically we only need to get one, I don't know. Yeah, at least one out of two to the 32, we will be correct. I don't know what our expected time is, but it's kind of a lot, right, to keep doing this. Okay. So that's a bummer. But what does that imply? So if we say that the chance of getting it correct is one over two to the 32, what does that imply? How is that? It is not reasonable. It's not reasonable to find that, but what does that imply about the distribution of sequence numbers? That it's easily distributed and each number is equally random, right? So if you had a poor, so this is what we talked about of like why choosing these initial sequence numbers is important is because if it's truly random, then you actually do get some nice security properties where the attacker would have to guess two to 32 tries in order to impersonate a TCP connection. But if they're not random, then you have a massive problem because people can guess it, right? And guess it very easily. That was actually the early source of these attacks is these sequence numbers were not generated randomly and you could just send some packets to A to get its list of sequence numbers. And then very quickly you could predict what the future sequence numbers would be. What's another way that we could do that? So let's say it is purely, the sequence number is purely random. Yeah, if we capture this packet, right? The information we need is in this packet and we actually know two attacks or at least one attack that we can do in two different locations to do this, right? So if we're on the local network of A, we can use ARP poisoning to get that traffic to us. If we're in the local network of B, we can also use ARP poisoning to get that packet to us. And then if we're actually in the local network of B, it's much easier to denial of service B because we can ARP poison them and just drop all the packets and never send them to B. We can also just be anywhere on the path from A to B and just observe that packet. Question in the Zoom chat are all the two to 32 combinations possible for sequence numbers? I believe so, I don't think there's any, because the sequence number is just where we're starting. So it's all based on diffs from there. Not even diffs, I think it's just addition because rollover doesn't matter. So I think all of them are equally likely or should be. Cool, so this is how we can spoof a connection. Now, the nice thing that TCP offers, it's actually inherent in the three-way handshake. There's additional security guarantees as part of that three-way handshake because of that sequence number. Assuming that the sequence number is sufficiently random, you do have some nice security guarantees, but that doesn't mean that it's impossible to do. Which then brings us to, so TCP spoofing is nice when there's a trust relationship. TCP hijacking is when we want to inject data into a current TCP connection. When might we want to do this? Yeah, so there's already, there could be a trust relationship or it could just be. So think about if I go to google.com over HTTP and you were to inject into that response and give me whatever content you wanted that made it look like it was from google.com. Like what if it showed a big login form, like the Google login thing? It's like, oh, you need to log in first. But when you type in your username password, it goes to me, the attacker, not to Google. You can also think of if you're a high value target and I have found a vulnerability in your browser, maybe I want to inject some JavaScript code that exploits that vulnerability in your, excuse me, in your browser. And I could do that by doing TCP hijacking so you wouldn't even know where I came from. You would think this packet, the data came from the other, whatever website you were talking to. So the idea is, and the key difference here is with spoofing, we were initiating the connection. With hijacking, there's already a current TCP connection between the two sides. We just want to inject some data in there. And we could also use this as a denial of service. So if we could send resets in there, we could maybe stop communication. Sometimes, depending on the condition, stopping a communication can be just as useful as injecting into it. But again, we have the core problem of we need to know the sequence at acknowledgement numbers, right? If we don't have that, then we're not gonna be able to actually inject data. So if as an attacker, we can eavesdrop the traffic that are going between either one, then we can do this attack, or if we can guess the correct sequence acknowledgement numbers, oh, I wish I had the date for this of when this was published, but there's also a one of like an early attack against TCP that still exists and is still possible nowadays. So one of the key things the attacker wants to do is to wait until the connection is quiet and there's not a lot of communication. Why do you want to wait until things are quiet? Yeah, if there's a lot of exchange of data back and forth, the sequence numbers keep changing and so it can be hard to keep up and it can be hard to inject your data right at the right moment where the sequence and acknowledgement numbers match correctly. So if you wait until there's a lull in the conversation, then you can inject your data. So the really cool thing that happens here is that as we'll see, this actually like desynchronizes the connection because both sides like A thinks that this, they've sent data up to a certain point, but B has received data up to another point and so they're actually not in agreement and they can't actually communicate further. It's kind of crazy and this actually keeps going forever. So basically whoever gets the injected data replies the other side like, great, I saw up to 10,010 and the other side says, sends an acknowledgement back that says, no, no, I've sent up to 1,000 and then they keep acting back and forth until, well, actually technically forever, but at some point one of these packets will get dropped and then they both think like, yes, that's what I thought. And then, but at that point, they can never send data to each other. So this is called an X storm, it's kind of cool. So let's look at how this works. So we're the attacker. So here we can see like kind of in the diagram that we're somehow in between the connection. So, oh yeah, okay. So the concept here is not crazy. So the concept is basically like, there exists a client sequence number and a server sequence number, right? So just like there's each side has the current state of the sequence number. And so we as an attacker inject data into that communication, we send a spoof TCP packet pretending to be from the client to the server and we set the sequence number equal to the client sequence number with 30 additional bytes of data. So we're injecting 30 bytes of data into the stream. The server sends acknowledgement of the client sequence number plus 30. So it sends an act and then the client gets that and it says, no, no, I'm acknowledging that I've sent up to client sequence number. And the other side says, no, no, I'm acknowledging that I've seen client sequence plus 30 and the other side says, no, I'm acknowledging that I've seen that I've sent up to sequence, client sequence. And so they continue like this forever and can't ever make progress to communicate. But at this point, you know, if this was a... So this is the nice, this is why we add encryption to things. So you can't really do this into an HTTPS connection because it's an encrypted communication channel and you can't just inject data. You can do this, but the other side won't accept it, right? It would know that that data is not part of the stream. But if this was a telnet session, so this is just the client is into a remote server. If you're able to inject a command that said like RM-RF slash, like delete everything on the system, the server would do that. And then it wouldn't matter that they can't talk anymore because you've just deleted all the files on the server. Like even worse, you could give yourself access to the server, you could add yourself to the authorized key file, you could change the password, like all kinds of crazy stuff. And if you're directly on the path between the client and the server, then you can prevent this desynchronization just by changing the sequence and acknowledgement numbers of both sides. So you inject your data, you keep track of the mapping, and then whenever one side acknowledges, you subtract from the sequence or acknowledgement number the amount of data that you sent. And this way you can have them continue to talk while still having done this. It's really cool. All right. And finally, we're going to look at some denial of service attacks. So we've looked at kind of how to establish a TCP connection. We've looked at how to port scan, how to spoof and hijack TCP connections. The other type of things that we want to think about is denial of service attacks, right? So this is useful as we saw as a prerequisite to conducting a TCP hijacking attack. But denial of service attacks are actually really common. So why is that? What are denial of service attacks used for? Yeah, so to disrupt communications. So I heard this used to be a thing. I don't know if it does anymore, but I think people used to use denial of service attacks against people and playing video games with them. So they figure out your IP address, they send a flood of traffic to you so your latency shoots through the roof and then you lose the game basically through no fault of your own. That's kind of like a trivial, in some sense, use case for this. Another one is if you're an online realtor and you sell some product and your website goes down and then you get an email from somebody, and then your website goes back up and then you get an email from somebody that says, hey, I noticed that your website went down. Luckily for you, I run a denial of service prevention service and I can make sure that that doesn't happen again. As long as you pay me some Bitcoins as kind of like basically like a protection racket thing when they're the ones who are actually taking your site down. And so that happens actually a lot to like small and medium sized businesses. If you're a big company like Amazon or Google, you have the capacity to deal with this. But if you're a smaller medium sized company who doesn't specialize in these things, but still the internet is critical to your work, it could be much more difficult. So these things still happen a lot. And the way to think about all of these type of denial of service attacks is the attacker needs a lever and needs specifically leverage. Because if you think about it, if I could just, if I could send enough traffic to overload the physical cables, then I can't, I'm gonna send a bunch of traffic and I don't really care. But if I had that much bandwidth, I already have a ton of bandwidth. So for attackers, they're looking for when they send some bit of data, it causes the attacker to send like 10x more data or to store 10x more data. So we can see this with a SIM flooding attack. So basically the attacker first starts the handshake of the TZB connection. It sends a SIM packet. The attacker sends a SIM packet. The victim replies with a SIN act. And then the attacker doesn't send anything else. So you may think like, well, this is kind of a dumb attack. Why is this useful? Right? Well, think about what the operating system has to do. So when the operating system gets a SIM packet, so it gets a SIN packet, it replies with a SIN act. How does it know that the act that it gets back is in response to this SIN act that it sent? Yeah, it needs to know the, so it needs to have the IP, right? Both source and destination IP. It needs both source and destination port because it has to establish that connection, know about that connection. And it has to have the sequence number that it generated, as well as it needs to store the sequence number from the other side. So the server sequence number and the client sequence number, right? So I can send one packet from the client to the server and I can get the server to store at least six pieces of information. It doesn't really matter how big they are, right? How much information does the attacker need to store? None, because it's not gonna establish the connection. Right? So it can just send for free one packet. It doesn't have to store any information and that causes some information to be stored in memory on the operating system of the target. And so what if it sends millions of these, right? From a bunch of different machines. So the server needs to store all of these possible pending connections. And this is what is the essence of a SIN flooding attack. And the beautiful thing is as an attacker because we don't care about that response, we don't even need to, we can spoof the IP address. So the attacker, the victim actually has no idea where this data is coming from and who's attacking them. They can look at the data, the network traffic, all they want, it's not gonna show my IP address, right? And fundamentally, yes, even though modern operating systems and computers have lots of memory, at a certain point you will get overloaded, right? Like at a certain point you just can't or what actually happens more frequently is operating systems have a limit on how many half open connections they have. Because how long does the server have to keep this SINAC, all this information around? It could be 30 seconds, it could be a minute, right? Because again, it doesn't know, it will probably try resubmitting the SINAC. It doesn't know that if that SINAC got dropped and that's why it's got the ACK back. So it needs to have some kind of time out in order to keep the data around of when the other side responds. So yeah, so usually they will have a limited number of half open sockets in this state. And so then as an attacker, it's great. I just fill that all up with fake traffic. And then when somebody real wants to connect to the site and sends a SIN packet, the OS says, should I have no more half open, like I run out of sockets? So it just sends a reset to that other side. So as long as I can cause any kind of problem in any kind of limit that your operating system has, whether it be memory, limits on half open sockets, then as an attacker, that is great for me. So different types of solutions to this. You can try filtering this. So this is actually what can happen a lot. You can try tuning the length. Now, of course, all this kind of relies on the fact that you can get into your server, right? If it's a remote system that actually may be difficult if you did not prepare for something like this. But we can increase the size of this queue, but maybe the attacker has tens of thousands or hundreds of thousands of systems that can make these requests faster than we can do that. We can reduce the timeout. So just like we talked about, that actually could impact people what if they're on like 3G on mobile devices, like the round trip time, and they have to go through up to a, the packets need to go to a satellite and back down and then over 3G, like it's, these actually can like the timeouts can take a long time for real data to be received. We could also maybe change things where when we get a new request, if we have a bunch of pending or we're full, we can drop those half open connections. We can limit the number of half open connections from a specific source. Of course, the problem here is they're spoofing their source IP addresses. The super cool thing is, what if we fix the fundamental problem, right? The fundamental problem here is that the attacker causes us to store data by sending us a SIN packet. But what if now there's a super cool defense against this and an RFC that you can go read about, which is talking about this notion of SIN cookies and we're not gonna go into the specifics here, but basically it says, okay, what if we derive this because if we look, so if we look, right, we send a sequence number from the server to the client and they send it back. So what if I could store information about this IP and this port inside that sequence number such that when they send it back to me, I can verify that, yes, I did actually send this value. So this is kind of the core ideas rather than me storing information about this connection, I encode it into the sequence number, send it to the other side, and that way when they send it back, so I store no data about the connection. When they respond, I can verify that acknowledgement number that was actually generated by me. That's pretty cool. I think you could do this cryptographically as well. This approach does not, my guess is it's because it was in the early days of crypto and crypto was not very fast. So that actually doesn't make sense to do cryptographic operations in response to attacker input, which would then the lever would be, I send you a SIN packet and you do a bunch of crypto operations so I can overload your processor. And okay, so we don't really need to go into all the details of how this works. The details are here, but basically we encode information into bits of the response of the MSS, which we didn't talk about as a field inside the TCP header. We do some hashing and then, and anyway, so this is super cool. I really like this idea of how to do this. And so kind of the point there is to be on the lookout for these other types of attacks that take advantage of limited resources on a target because this is how people can take down certain things. So for instance, like we saw, so how much memory is stored for a socket descriptor? How many, this is kind of a nice one. So how many threads or processes are given to manage that connection? So this was a classic attack back in the day where you'd have a PHP application and the way the PHP application works is you'd have a pool of workers, like 10 different processes that were ready to process incoming requests. This way you could serve concurrent requests. Now the problem is what happens if you make 20 concurrent connections to the server and then each of those requests goes to a certain process and now any new connections can't get processed until one of those is done, until one of those is free. So I can just continually make not even that many requests. If I can make, just continue to make, I don't know, 30 requests concurrently, constantly, I can like shut down your site. Even if you have a ton of memory, just one setting that you have that's not letting this actually work. Other cool things here I like are with this processor friend. One of the newer attacks is called Slow Loris, which essentially means like, how do you use, you actually send data very slowly to from one side to the other. So you send like data, like a byte at a time and this way the server is storing your whole connection open. You're paging this process that's literally doing no useful work and you can just do that with a bunch of connections and it actually doesn't take that much to take down a system. Okay, we're at the end here. We got four more minutes. So let's finish up here. So I mentioned this before, but just so that it's clear. So firewalls are, remember we talked about mechanisms versus policies, right? So firewalls are a mechanism to enforce a network access policy. So the idea is they're usually a physical system that operates on the edge of your network that has rules that says, okay, I don't want any packets that aren't directed to port 80, let's say. So if you're running a website, you would say, I'm gonna just gonna drop it the firewall, anything that's not port 80. So the policy is basically what to block and what to allow. You can make this as complicated or as direct as possible. So again, you have exactly all the same problems that we talked about when we talked about policies versus mechanisms. How do we specify the policy? What language do we use? How do we know if our policy is overly broad for what we wanna do? This is actually a key problem. What happens if our policy says, hey, if you get this, block it. But if you get this, accept it, but they're the same thing. So you can have conflicts inside your policy. So there's whole aspects here. How expressive is your policy? Can your policy express things that you wanna express in network terms? And then there's all kinds of ways you can look out of how to bypass firewalls because actually the types of things that you may or may not want is kind of difficult to actually do. So there's a whole area you can look at of how to bypass firewalls and get past these things. You can go through that in more advanced networking course. Other topics to touch on. So you may have heard this term intrusion detection systems. So basically the way an intrusion detection system works at some kind of it's a mechanism that monitors all network traffic to determine evidence of compromise. So it can do things like look for signatures that say, hey, this looks like a port scan. If you were just port scan, right? Whether that's actually indicative of a compromise that's highly unlikely. But intrusion detection systems, their job is to look through all of this crazy network traffic and try to determine, hey, did something bad happen? Because again, what we talked about in the very beginning and this is where all this stuff is related. So being able to know just like why do you have an alarm in your house? Well, because you wanna know if somebody breaks in. Like maybe you can't stop them, but it's much better that if you know somebody broke in so that you could take remediation steps rather than if they broke in and you have no idea that they were ever in you can't actually remediate anything. Key problems here, again, policy. How do we specify the policy of what to detect? And this is actually a huge research area. If you wanna do this yourself there's an open source system called Snort that you can set up. You can configure it with rules to look for different network stuff. It's an open source IDS. The other thing that people also come across is an intrusion prevention system. The key difference here is an IDS. IDS looks at all the traffic but can't actually control or stop the traffic where an intrusion protection system can actually drop packets that it thinks are bad for whatever version of bad. So the idea is if it sees port scanning it can drop it or if it sees something trying to send an exploit for some service it can drop those traffic. Anyways, very briefly there's all kinds of future directions in network security research if you're interested in going deeper. There's this whole concept of software defined networking where you can use software to reconfigure and change networks. We have some work in that, it's pretty cool. Firewalls you can make, like we said there's all kinds of ways of how to make better firewalls. Intrusion detection system is a crazy problem of how do you actually detect the tax at the network level? IPv6 as we talked about is a whole other area with different protocols and everything and it even includes things to do some type of network security stuff like IPsec. So with that we are done with networking we'll be on to binary security and application security on Thursday. Thanks everyone.