 Hey folks, it's Tuesday, new month, is it a new month last week? I don't know, I don't know, I don't really know where we are. Okay, so we're on networking. So homework one grades are sent out. As I sent out the main list, I made a little mistake on mapping the grade to the part number. So just increment all the part numbers by one, two, three, four. It should be very clear. I just don't want to send you all another email. Homework two will be graded tomorrow by next class. So every homework two grade and the midterm grade will be graded shortly as well. So you get the same emails but now appended with your new score every time so you'll know where you are. And on Thursday we'll have a new awesome networking homework assignment because we will finally, through today, cover enough of networking that we can have an awesome assignment on this. Yes, more assignments, yes. We like that. Your projects are actually fun compared to some other stuff, so. Cool. Alright, I'll do more next time. Well, security stuff, you have to actually break stuff. I don't know. My philosophy is I can stand up here and teach you and even force you to memorize all of the theory behind all of these attacks but until you can actually do it yourself, that's a completely different gap in knowledge. So being able to actually do attacks is way different than knowing the theory behind an attack and how that works. So that's the goal. Cool. Alright, so we're talking about TCP, so what is the point behind the three-way handshake that we started off with on Thursday? Ensuring you have a connection. Ensuring you have a connection where? What kind of connection? It's a stable connection. Is there a secure connection? Correct, I would definitely not say secure. But we know that we have a, so with the three-way handshake, so we're going to first send what type of packet from the client to the server. The client wants to initiate a connection and what's the first packet it sends? No, it has to, it will send an IP packet but that will be encapsulated inside a TCP packet. That's the first point we're talking about, the TCP level. What's the packet that it's going to send to the server? TCP packet with a SIN fly? With a SIN fly, so you guys have a SIN packet and then the server is going to get that and send back what? A SIN-AC, so a SIN and a MAC packet is half-right but I don't want to say that because it makes it too easy. So SIN, SIN-AC, and now what does the client know for certain? Nothing's out there. The client knows that there's a connection to the server, so they know the server's ready to talk but what does the server know? Is the server ready to talk now? It doesn't know if the client got his acknowledgement, exactly. So at this point the server says, hey I'm ready to talk but I don't actually know if the other side is ready because maybe it went off line, maybe the packet got dropped, maybe somebody had to be under six cables, whatever, however that happens, we fundamentally don't know this. So this is why in order to complete the handshake, the client has to send back an ACK message to the server to say, okay, good, now we are good to go, right, we have established this communication channel. So like I said, burn into your brain, this is one of those things, tattoo it on your arm if you have to. SIN, SIN-AC, ACK, until we move to something besides TCP then you'll have an out-of-date tattoo. So at this point we've just established, so this is the important thing to think about is if we want to send any, so have we actually exchanged any data yet? No, all we've done is the client has started a connection to the server and once this three-way handshake occurs, now we know we can start sending data, right, how does this compare to UDP? There's no guarantee that the packet proceeds and no, it's, get the term but it's unordered. Yeah, so in UDP we just send the data to a port, right, so there's no, so actually if you think about it, the packets, to even talk to another server on TCP, we need three, wait, wait, wait, wait, wait, one, two, three, we need three essentially trips or round trips from us, the client to the server and the server to the client, right? So this actually adds a decent amount of latency to your communications, right? So rather than just sending in the first packet all the data you want to send, we actually, so if you could think of this and the way I think of this is this is kind of the overhead you have to pay in order to guarantee that the other side is receiving your packets, right? Without this you just use UDP and you start throwing data at them but you have no way of knowing whether they actually receive any data on that other side, cool. So now we want to send data, what do we do? What are the guarantees that TCP provides us about the data? In order, which means the client, the server or the client which everyone is sending data will receive the data in the same order that the other side sent it, right? So it's in order, what else? So we have to think of what are all the properties we actually want from this? So it's in order, what are the properties? It's all there, yeah. So if, the way I think about this is if they receive data N, that means they receive N minus one, N minus two, N minus three and all the data up into that point, cool. So how do we actually do that, right? So we go back to our nice drawings because, you know, so we have our client, we have our server, the client sent a SYN packet, the server sent back a SYN ACT packet and the client has now sent back an ACT packet, right? What did they actually use to know that they were talking to the right machines? Or how did the server let the client know that this packet is a reply to the first packet? Sequence numbers and acknowledgement numbers, right? So the client when it first initiates the SYN packet creates a sequence number for the client and the server when it sends back in this packet it puts as its sequence number a new server side sequence number so we'll call this sequence S and it acknowledges sequence C plus one, right? And so when the server, when the client sends back it's going to send back sequence of server, sequence of clients I believe plus one and sequence of server plus one. So what we're going to do is essentially now we want to communicate and now we actually both have these numbers that specifies where in the sequence we've actually sent data. So remember, so using kind of the same ideas in that when we send an initiate, when we send a SYN packet we don't know that that actually made it there until we get back the SYN ACT packet. So we're going to use a similar idea to deal with data exchange. So the client or whoever, remember it's multiplex or full duplex so each side can send data, but let's say the client is sending data to the server how will they know that the server has gotten it? In general, they just hope the connection that the client sends 50 bytes to the server. Do they just say, yep, they definitely got those 50 bytes. Yeah, the server, they need to wait for the server to tell them yes, I read up to 50 bytes. And this is the core idea here. It's actually pretty simple when you break it down. The details are a little complicated, but the idea is every time you send a message that acknowledgement number acknowledges the last sequence number that you saw from the other side. So you can think of it as I've seen up to, and remember so they're both random, right? So they both use random numbers, but they're going to be auto incrementing from there so you can think of them as starting at zero, right? So if you zero out essentially where they start so that that way they can say one side, so I send you 50 bytes, and then the other side will send an acknowledgement to say, yep, I've seen up to 50 bytes. And then I send you another 50 bytes, and they say, great, I've seen up to 100 bytes. And now the client knows that the server has seen those bytes, that I lose my... Man, who is using all these batteries? I don't think so. There's like a whole charging system. There's always something to do while I talk. This one in, cool. So there's a slight... So another thing to think about, so let's say I just wanted to send, we know an IP packet can send up to 65,000 bytes. So as the client, can I just send 65,000 bytes and 65,000 bytes and 65,000 bytes to the server? Why would that not be a good idea? Yeah, it's a lot of information to send. A, we actually don't necessarily know what we're talking to on the other end. What if we're talking... I guess you used to be able to use a notion of a phone, but now they have a lot of processing power. But what if you're talking to some super low-powered IoT device that only has a main memory, that you literally doesn't have 65,000, that has literally nowhere to store all that data you're sending. So there's another component that will kind of gloss over, but it's important to be aware of, is each side actually includes in its header its window, which says I will accept up to 2,000 or 1,000, whatever bytes. So that way the other side knows to respect that and will only send data that's inside that window. And so now once one side has sent data, the other side will send an empty act packet back if it has nothing to send and increment its acknowledgement number to say, great, I've seen up to like 50 or 100 as we saw. And so this is how the communication proceeds. So the client, let's say, sends 25 bytes to the server. So it's saying sequence number 6575. It's acknowledging that the last thing, so remember every time there's a communication, you acknowledge what you've seen so far. So I've seen up to 7612, and it's an act packet with 25 bytes. And so the server gets this and says, great, I'm still at sequence number 1612. So from the server to the client, I was only set up until that. And I've seen 6575 plus 25, so at 6600 bytes. That's what I'm acknowledging I've seen up until. The server can then send 30 bytes, so this doesn't have to be a null byte, a zero byte acknowledgement. And then the client will then acknowledge that with an empty data packet that should acknowledge 30 bytes more. So this is how this works. So let's look at this and see. You can think about the client wants to send some data to the server, right? So there's a bunch of data stream oriented, so there's no things as new line you just send whatever data you want to send to the server. And the server has some stuff it wants to send to the client, to the client. So the client sends a packet, says, okay, here's 50 bytes. Let's say everything starts at sequence number zero. So when the server gets that, what should it respond back as the acknowledgement number? 50, right? It's seen up until 50 bytes. Now at this point when the client receives this acknowledgement, now it knows that the server has absolutely for sure seen those 50 bytes. Those are seen by the other end. It's 100% that the server got it, right? So that's how you get that guarantee. So let's say I send, and we won't go into it, but you can send multiple packets, multiple bytes. So you can say let's say I send 50 bytes and then 50 bytes. So it's inside the window. I can do that. It's pretty small. And so the client, actually maybe the better way to do this, is this is the client's view. And the server's view. Oh, that's, what's that? Okay, server, no. Server, okay. The server sees when it gets its first packet of 50 bytes, it says, great, I've seen up until here, it's acknowledged by sending an ACK packet with the sequence of an acknowledgement number of 50. And so now everybody knows that the communication is here. So let's say I send this 50 packet and that packet gets duplicated somehow. So there's two packets that say, so the client is going to send a packet saying this is sequence number of 50, and here's 50 bytes. So the server's going to get two of these packets. So let's say we can't get them both at the same time. So the first packet comes in, what does it do? Yeah, same as before, right? It says, great, here's the 50 bytes I need. Here it is, send back an ACK. Acknowledge, do I acknowledge 50? 100, so I've seen 100 bytes so far, right? So we're good. But then it gets the next packet in, does it add that 50 bytes? Here? What does it do? It just drops it, because it knows the packet that it gets in says sequence number 50, and it says, okay, sequence number 50, wait, I've already seen the data from sequence number 15 to 50 bytes. So this packet is useless to me and I'm just going to drop it. Similarly, let's go back to our example, so we send two packets, right? This is sequence number 50, here's 50 bytes, and then sequence number 100, here's another 50 bytes, so these are two packets from the client to the server, sending this chunk of data and then this chunk of data. So let's say this first packet gets dropped somehow. So the second packet comes in, and what does the server do? The server sends a packet without being nullified. But what does it do in its internal state? So this is the server's view of the data that's trying to be sent. So has it already seen that data, like in the last case? No, it hasn't seen this data before. Does it know where it goes? Yeah, sequence number 100, so it goes 50, 100, and it goes, this data goes here, right? But, so now it can put 50 bytes in here, but when it sends an acknowledgement back, can it say that I have seen, remember the acknowledgement says, I have seen up until 150 bytes, can it say that? No, but what has it seen up until? 50, so it'll send back an acknowledgement of 50, and it'll wait. And so the client will see that and say, hey, I sent two packets, and the server has only seen up until 50, so I should resend those, right? Because the server knows what the client knows, and something has happened, so it'll probably just resend these bytes. If this packet goes through, then it says, okay, great, these are 50 bytes here, and then I'm going to act at 150 because I've seen up until there. And now they both have seen and know that each other has sent a total of 150 bytes up until here, and they've transmitted exactly those contents. Yeah? Will it act? It'll act for both of them. It will act for both packets, that is to say. Yeah, exactly. But the client will only care about essentially the latest. So there's a lot of other details and mechanisms in here of exactly how long you wait before retransmitting and what you do about drop packets and all this kind of stuff, but it really sits here. But it's important to understand how this actually happens, component in here. Cool. So now, so we set up a connection, we started talking, what else do we want to do? We want to shut it down, right? We want to say we're done talking with you, right? Because we can't just, it's not a C string, we can't just send an old byte, right? We're agnostic of whatever content we're sending. We usually don't care what the data is, the bytes of the data, but we want some way to say, hey, I'm done talking with you, let's shut down this connection. So this, because we have a dual duplex, so either side can send, either side can actually say I will not send any more data on my string. So it uses a fin flag. So fin, I believe it's like, probably short for finish. And so the other partner then will act back and say, great, I acknowledge that I've seen this fin tagging and that way both sides know that A was not going to send any more data to B ever. Then B can still send data to A until it decides it's done. So it sends a fin packet to B and it's all over. So it's actually a pretty simple process. So basically the client will say, hey, I'm finished talking with you and the server will acknowledge that and then will also send its own fin packet back to say I'm also done talking with you and at this point, the four tuple of source IP, source port, destination IP, destination port is no longer considered a connection between the two. At this point they cannot send each other any more data. So now that we just had a crash course in TCP, what are some of the security attacks or potential things that we want to learn about a remote, let's say, server? So what do we want to learn about in UDP? Exactly, what ports are accessible on that system which tells us about what services are running on that remote system. So we want to do a port scan, right? We want to do a TCP port scan. This is, there's actually a file system which, or there's a file called ETC services that you can use. It's actually pretty funny to look at and read. There's actually a fax port, like an FAX. I'm not exactly sure why or what it has to do with fax machines, but maybe it has something to do with that. And the only reason I mention that is because kind of what we had to do, oh, yeah, this weekend we were competing in a hacking competition and it's a long story, but we basically had to get a payload that we wanted to execute, like a bash command, but it had to be at most four byte max and at every four line four byte break the first the letters had to be in alphabetical ordering. So we did a net cap to our host on a port and dump out a file but we basically had to use these port numbers to figure out what were port numbers that started with X's and Z's so they would actually fit alphabetically in this payload we were generating which was absolutely ridiculous but oh, sorry, and it turns out there's a simple way to do it which I was probably did it the hard way. Anyways, the point is it's a super interesting file like I actually never looked in there but I started poking around and there's a lot of random services. Cool, so how do we implement this? So we want a port scan using TCP, how would you do it? You'd send SIN packets to all of the ports and if you received a SIN act then you know that there's a service there. Yeah, so we can well we can actually do something that's a little more high level than that so when we think about it from a normal user land program you open and make a connection on a socket using the connect system call which connects you to a remote system so you would say connect on all the ports 1 through 65,000 on that victim host. The interesting thing here is that this will actually cause a handshake so this will cause a 3-way handshake so you'll do a SIN, SIN act and then an act and then you would say a FIN to cancel the connection and if the handshake is successful then the service is available right? If it's not, we didn't talk about it but there's a reset RST flag that usually is sent so if you try to talk to a system or if you try to let's say initiate a 3-way handshake but you don't do it correctly, you miss one of the steps and you just start talking the other side will tell you to reset like you screwed up this connection so stop talking to me so this is good because you don't need to be rude to do this connect scanning you can just any program can do that the disadvantage here is like a little mention is rather than sending just one packet and getting a response here you're sending essentially one packet, you send one you get one back and you send another one then you have to send FINs so it's actually really annoying but you can use end map, if I talk about end map again you can use end map as an option for this and you can scan a host and it will tell you as we talked about by default do the first 1500 hosts and it will tell you which ones are open on the system but this is a little noisy right? it's sending essentially the equivalent of three packets for every port that you want to test and so well why would we not what's the disadvantage of being noisy so the more noise the more traffic that we generate the more likely it is for somebody to see we're doing something weird usually we're worried about their systems so maybe they have a system that's looking at network traffic but any of this kind of stuff so what we can do is then go to Will's idea and say we don't need to actually do a three way handshake if we send a SIN packet to a given IP in a port if we get back a SIN act we know what open, if we get back a reset we know or nothing else then we know that it's closed right? and this is called basically half open scanning because you are not completing the three way handshake let's start a connection and then they respond back and say okay let's start talking and then you just never talk to them again and if you can actually keep the connection open or you can send a reset packet to the server to be like hey why are you talking to me like don't talk to me and a super interesting thing here is usually because this connection is only is done by the operating system by itself so a connect if you do a three way handshake to the server now any data you send will be sent to the process that's listening there so let's say you're scanning and you're doing a connect scan of the web server the web server itself will see that somebody tried to connect and maybe you didn't send anything so it was a weird connection but that may get logged by the web server whereas here a half open scan is the program that's listening there so often times it's like completely ignored and so you can do this also with nmap nmap has all these crazy options always read the man pages they're super handy and so you can actually see if we use tcp dump we can actually see the SIN scanning so we can see that this is scanning that's fine this is just let's say another SIN scan so we're sending to 128, 111, 41.38. 78 78, 81, 82, 80, 79 and then we get a reset back from 78, 81, 82 but we get the SIN back from port 80 so that's what tells us that there is a port open on port 80 what else might we want to know about the remote system so we may want to know what services are running what other kind of information we want to know so we can figure out at least what network applications are running or what servers are running because we can port scan but why would knowing the operating system be useful? Google what the bugs are for that version that's probably been cached what operating system well it could make the argument that every version of every operating system is unique operating system because it's not identical to the previous or later versions so the version is innate in knowing what code is actually running on the system so just saying, oh it's running Linux or it's running in some DB and that doesn't mean anything you have to know the actual version it may or may not it depends on the different granularity levels to think about it definitely would be useful to know is it a windows box a macOS box or a Linux box at a high level even better would be to say hey it's a Linux kernel version 4.1.12 and then you can look up in the CDE database are there any remote code execution vulnerabilities against that target operating system so this is what we want we want to get that level of granularity how can we actually do that though so you have to mix the information on a poorly routed 404 page or some default somewhere and maybe both why do I have to run it if someone might need to be in certain environments possibly send an outform things that don't necessarily conform to the T6P protocol and see how it responds but why wouldn't they respond differently because they're implemented by humans so the key idea is they all have different TCPIP implementations in the operating system kernel itself and so the specifications if you read them are not 100% specified of what everything should actually do so they may make different decisions so what do you do if somebody sends a reset packet in the middle of your communication do you ignore it do you continue what happens if somebody sends you a reset packet that you've never talked to before do you send a reset packet first like no you talk to me weird first don't talk to me again or you just drop it there's all these weird decisions that get made and it turns out you can actually use these to fingerprint very specifically in the operating systems of remote systems or what happens if you just send a thin packet so this is another example so what if I just send you a thin packet out of nowhere do you ignore it or do you tell me that's a reset you shouldn't be sending a thin packet what if we flip random flags that are never used in the TCP packet some implementations will actually reuse those mics when sending a reply back to us why because they do don't affect the normal operation so I think of it like you have you have completely different implementations of these TCP IP stacks and so what you're doing is trying to find out behavior deviations there that obviously don't affect normal operations but still tell you something about the operations what happens if I send a packet to you with a SID flag set a reset flag set and a thin packet the specification does not say what you should do there but you have to do something so how you reply is another fingerprinting mechanism and even things like what TCP numbers do you initially select there could be some bias there or what's your initial TCP window size this is actually a really big one that's pretty easy to fingerprint how do you use then you can move up you can try at all levels not just TCP games you can try what about ICMP messages what happens if I ping you or send an ICMP ping message do you respond back what happens if I send you a weird ICMP message it's all kinds of stuff what error rates there how much data do you include there and a really interesting thing so when we just talked about being stealthy and generating less noise clearly here we're going to send a lot of packets to the remote system but not for all of these features if you can see what traffic that machine is sending you may actually be able to get the initial TCP window size which may tell you something so there's actually tools that do passive OS fingerprinting that just observe traffic so you use TCP now and then you run that through POF and it will actually tell you a rough idea of what those operating systems are so you can explore them further you can also I believe Nmap has an option dash O to do this fingerprinting so you can run this against the remote system and figure out oftentimes vary closely what operating system is running now I will say there is it does get a little bit murky you have to take your results with a grain of salt sometimes you'll scan something that's an android phone you're like no that's a server there's no way that's possible because android devices use a Linux kernel it can be difficult maybe to tell sometimes so cool so that's very fun games that you can play that are actually really relevant to performing penetration tests so what other attacks have we played in the IP and UDP game what other attacks have we looked at any time you think about a new domain you want to think what what are the attacks that worked in the last domain and do they work here what are the attacks we talked about with UDP we talked about port scanning possibly we can talk about that later that's a that we could spend a while talking about what we talked about even at the IP level spoofing what was that when you instead of you send the server whatever the service is an IP that it should trust like something an IP that would be from the internal network or from a port that it knows right so the basic idea is we want to talk to our remote service and make it think that this packet came from another machine that is not our machine right and when we say another machine we mean IP addresses here so we want so this was easy and trivial to do in IP and with UDP why have to reply right all they get is a UDP packet and there's data in there and they just have to deal with that or respond to that packet with whatever data they have right and there's no authentication at the IP level of IP addresses right so we have no idea the remote server it gets a packet and it has no idea that it actually came from this IP address so can we apply these same ideas with spoofing TCP spoofing so we saw that IP can be so we looked at UDP and we basically agreed that UDP doesn't add anything on top of IP so the same IP level attacks work on UDP but does TCP actually add some security there sending it to you and someone else and then you send the acknowledgement back oh I didn't get that packet send it back to me just keep doing that over and over again yeah so let's say okay so we have a client just like before we have a client and it's attached to some network and then we're here and then we have a server and if we wanted to send the UDP packet and spoof it send it to the client and spoof it as it sorry send it to the server and spoof it as if it came from the client what would we do so we create a UDP packet and we wrap that in an IP packet where we put the source IP as the client and the destination IP as the server and bang we just send that packet out it gets to the server oh it looks like this client CIP is sending me this request and this UDP data D I will process it and respond to it however I would do that but now let's say there's a TCP service there let's say it's a website that's got some admin functionality that is they white-listed that the client IP can access that admin functionality but nobody else can so we want to fundamentally make a request to the server impersonating the client so we have some data that we want to send how can we do this so let's think about it this way the previous model apply can we take that data in the TCP packet and the source source port is going to be whatever 41 and destination port is going to be port 80 and then we wrap that in an IP packet so we have the IP level the source is C and the destination is S and we send this packet what happens server will reply to the client with what reset because there's no connection established between the client and the server in TCP we can't just send that what do we have to do first before we send that and shake we need a SIN we need to get back a SIN AC and then we need to send back an AC so let's break that apart so can we send the SIN we make a TCP packet what if we did TCP packet whatever the ports and we send SIN flag and we encapsulate that in an IP packet that has source of C of S can we do this we can make whatever packets we want we can spoof at the IP level we can create whatever TCP packets we want we can send this packet so we send this packet to the server what does the server do the SIN AC the server says oh somebody is trying to contact me great so it sends back a TCP packet with the ports switched with a SIN and what does it put as the IP addresses there the source is what server and the destination is client so now where does that packet go so that packet so that packet is going to go from the server to the client and let's say we are in a completely different network we cannot see that packet which often happens so then why don't we just make our own AC packet we just create a SIN packet why don't we create an AC packet and send that out why what do we have to include in our AC packet the sequence number that the server said remember talk about sequence numbers so our initial packet that we send we'll call it a sequence sequence number C so we choose this this is not an unknown value the server when it sends back a SIN AC it includes the sequence of the server and as it acknowledges the sequence of the client so if we want to reply back with an AC packet we must know the sequence number of the server if we do not know that we cannot initiate a connection to the server so what do we do is TCP fundamentally secure now what can we do we can send our own first and we might be able to catch a sequence number from that we can send our own from ourselves to it and get the sequence number from that and then use that sequence number to generate what the sequence number should be for the one that sends the other one so we can guess that's essentially guess the sequence number so depending this then goes back so the idea here should be if I can guess that sequence number then I can spoof TCP packets and TCP connections and I've essentially completely broken TCP right so you want it to be the case that if I send you a SIN packet and you send me back a sequence number should I be able to guess the next sequence number that you use we would want that to be a property of our TCP stacks unfortunately that may or may not be the case so there's actually been a long history of breaking the sequence number generators of the way that they generate sequence numbers in these things and you only need to get right once so even if it takes you 60,000 tries 100,000 tries as long as you're right once and that allows you to compromise the server's security you want so fundamentally you want this to be the sequence number is I believe 32 bits 2 to the 32 is a lot of guesses so you will be very unlikely to get that but if you're able to reduce that because it's not as random as it should be then that would be really good for you as an attacker but let's say it's super cryptographically secure random number generator it's using like it's got a hardware entropy thing that's adding a bunch of randomness and it's just like crazy random there's no way to guess it no matter how many requests you make to that server you will never be able to guess that sequence number better than brute force 2 to the 32 especially for a generator to be a 1 every single time so what do you do game over go home yeah so the idea is we now basically have to see that packet right so we need to see that reply we either have to guess that sequence number if we cannot guess it then it is basically impossible to do this remotely without being on either of their networks so where could you be for the scenarios you can be on the client network and you can do some ARP attacks to see this packet what else where does that tube rock so think about in this diagram right you could be connected to the client network maybe physically maybe on their wifi maybe you've broken into another machine on that network whatever it doesn't matter you have a presence you can on their local network but is that all are there other avenues what if the client is really secure or something be on the server network yeah you can be on the server network right if I can somehow be on there and sniff the traffic there and see that packet then I can respond with the correct sequence number with my final act what else any other options do you compromise anything that's in between them yeah so remember the packets have to hop right there's actually this is an oversimplified model right there's actually switches in here that these packets travel between so I can compromise or take over any one of those switches local networks and see the traffic there so there's actually a lot of ways depending on your threat model so to see those packets it's a pretty old attack it was first discussed in 1985 and you can actually still read this paper and there have been famous attacks so Kevin McNichon used this in an attack and so the idea is basically if there's any kind of IP based trust you can try to invalidate this trust one thing you have to worry about is going back to our example can you guys see that let's take a look okay so assuming I send my first SIN packet to the server the server replies back with a SIN act what's the where is that SIN act packet going to go the server is going to send back S is going to send back this SIN act packet that we've drawn here where does that packet go and back to the client the client gets this and what's the client going to do is reset because from the client's perspective it is not an issue to the connection if you're like a random somebody randomly coming up to you and getting a line oh that's going to be like right in the middle of a conversation with you so if my mom's doing great I don't even know who you are what you're doing so just reset this conversation if you want to talk to me let's do it the right way so C will send back a reset packet which is not good for us because that means that even if we successfully guess when that packet comes back the server will kill that connection so we either have to beat that reset packet or what else can we do we can intercept it stop it so far the local network we can definitely do that what else do we do we can take out the client we can send so much traffic to the client that the client never sees that SINAC packet coming back so it never has a chance to respond with a reset so either that would stop the SINAC coming to the client or it would stop the reset from coming back yes we can intercept the SINAC then we're good cool so we can try to kill B we can try to kill the client we're trying to intercept with and then we have to either eavesdrop the SINAC packet or guess the correct sequence number so I realize it's confusing because I've been using A and C, S and A and now we're using A, B and C in a completely different manner but y'all are smart people so you'll be able to figure it out so C is us the attacker A is the client B is the server A packets we then as the client send a SIN packet to the attacker sorry to the two server A server A responds back with a SINAC packet to B with its own sequence number 55002 so we need to send an acknowledgement packet back with 54003 and so however we can do that by either guessing that number or intercepting this packet we can then send from the client to A from the attacker to server A we can send back an AC and so now we've actually spoofed a connection from B to A but actually it came from us the client it's actually super fun to do so we can actually try to go further so spoofing initiates a connection right and says this connection is coming is B trying to initiate a connection to A but we may want to actually try to inject data into an already occurring TCP string so one way to think about this is this is why we talked about public wifi networks are so bad is because anybody could be doing this to you and anybody could be who's on that network could be injecting some malicious that takes advantage of exploiting a browser to execute arbitrary code on your laptop or your device so this is why this is so bad so the idea of TCP hijacking is now instead of we want to initiate a connection from B to A now A and B are already talking and we want to inject extra data in there so think about SSH as a bad example because it's encrypted but think about like a telnet session which is not encrypted so it's the same thing remote access and there let's say adding additional so they're sending commands so if you could inject your own commands into that TCP string that will execute on that server so you could give yourself remote access or something and I did so let's see do we like this is this better than the way I used to do it the problem is now I can't see it so the drawings will only get worse which I guess we're going to go up so now we have already let's see so the client now already has a TCP connection open to the server so what does this mean if we say that there already exists a connection between the client and the server Sessions been created so what are the important attributes there in the session so we know the source we know that there's a source IP what else source port set server IP and server port so this port tuple is important so we know what flow is what else do we want to know if we want to try to inject data into here sequence number right so we need the server the sequence number of S and the sequence number of C because they each have sequence numbers and it's going to be constantly changing through this communication so what we're going to try to do is then inject a packet into this already occurring conversation we may even though want to let's say what's the new technique for this we can even maybe we don't even want to insert data maybe we just want to reset this connection so maybe this is a connection from a web application to its database server and it has a failure mode when it can't connect to its database it just lets everybody in or something which would be more common than you think so if we can disrupt this connection then that would actually be really good but in order for our packets to be accepted by either side what must be true what do we need to actually do with our packets and how do we do that we have to change like what has to be true in our packets IP the source IP the source port the destination IP the destination port all those have to be correct what else sequence sequence numbers we've got to have the right sequence and acknowledgement numbers if we don't we're going to completely mess everything up so just like before right this is actually essentially the same problem we can either eavesdrop on the traffic so we can see the traffic we can know the sequence numbers and all the ports or we can try to guess the sequence numbers and acknowledgement numbers again if these are not randomly generated we can completely break the security of this TCP connection and there's a paper on this if you want to check this out in more detail so how does this actually work okay this is actually really cool so we're going to walk through an example here so I want to check some data so let's go so there we go so even if you don't know Telnet it's SSH without encryption so the S in the first SSH stands for secure it's secure shell Telnet is the non-secure version of that it should be called non-secure shell because all your commands everything are sent over plain text whereas SSH encrypts the communication so nobody can see what you're saying or tamper with it but let's say we have a telnet session from C to S right and let's say we're eavesdropping on the traffic so now we can inject our home command here so do we want to just launch this I can't see this so telnet from C to S so let's say the user is logged in typing away typing a type they're using VAM or Emacs and working on their homework assignment do we want it inject packets then depends on what our goal is why mess with them if they're in VAM and insert random characters into their stream yeah so we can mess with them while they're typing but in order to actually do that we have to guarantee we have to have the correct acknowledgement and sequence numbers right and so if there's constant communication those sequence numbers are constantly changing so as an observer it's very difficult to like inject the packet at the right time so that the sequence and acknowledgement numbers are the same even if you're saying everything because they may be jittering the network you don't necessarily know when your packet will get there so what you really want to do is wait until the user like goes to go for something so there's no more communication on that channel so at that point you've been listening and so you know the current sequence number of C you know the current sequence number of S and you know both the IPs and the ports so you as the attacker you're going to create a TCP packet have the ports be correct it will have its act flag it will acknowledge so who do you want to spoof in this scenario so who do you want to spoof here do you want to inject some information in this which direction do you want it to go yes it does depend on what you want I think let's say to tell that example I don't think if you send out a back to the client it can be executed on the client but maybe that's not true but maybe there's some weird way to do that but in general the response back to the server is whatever your commands are so we want to get it all depends on our target so our target here is the server so we want to create an IP packet that source is from the client and the destination is the server so this is the act flag we also have we actually know the sequence number so it's actually pretty easy all we have to do is say the current sequence number is the sequence of the client and send this packet out so we send this packet out the server gets it and then what happens remember we have our views it's actually kind of important so let's do this the client thinks it has sent up to sequence number of client and the server side view has also until we do anything they're both in 100% agreement that this is the sequence number of C right so we send our packet spoofing it from the client to the server the server gets that and then how does that change its view here well that's okay it doesn't know that yet but from its view the client has now sent so this would be let's say our payload is 100 bytes whatever the length of the payload is is what it's seen and now our payload is in here the operating system will pass this up to the SSH or the talent process which will then process this and execute this command but so when the server gets this packet what does it send back to the client an act of what does it acknowledge up to how many bytes has it seen sequence C plus 100 so we go back to our thing so we send this packet out from A to S S will then send the packet to C a TCP packet sequence C plus 100 the client gets that packet and says no that's not right the sequence number it will acknowledge back and say actually my current sequence number I only sent you up to sequence sequence of C and then the server will get that and say no I've seen up to sequence of S sequence of client plus 100 they'll keep sending each other packets packets forth until one of those packets gets dropped and they said that's right that's what I thought we are at whatever is correct so you actually as an adversary you desync their views so they both have different views where these server thinks they're up here and the client knows they only send this much traffic so you've actually completely messed up their communications and from here on out they cannot talk to each other anymore so as an adversary then you've sent your payload your payload was executed so what do you want to do because they're going to keep doing this weirdness that's going to be all this weird traffic that's going to be generated from the server side of the client the server will essentially deliver back down to you could but that would be you have to so it all depends on where you are if you are actually a person in the middle and you are on a router and can replace packets what you can do is you can basically substitute 100 bytes from whatever acknowledgement the server sends to the client so then there you've kind of hidden that data there so you have to actively be able to drop their packets or change or alter their packets often times you may not be able to do that because you can't necessarily control what they send so why not just tell them to stop talking have you ever come back to a SSH terminal and have your connections be dropped it happens all the time you don't know why random stuff happens constantly maybe it was a whatever the physics person with the beams that come and flip bits camera rays I'm not crazy this is a real thing because you're not crazy or you're not in agreement I tell you a story about the super computers so flipping bits maybe some bit randomly flipped somewhere and that caused the connection to end whatever so if you can already spoof this you just send your thing you send this packet and then you send a fin packet and you're done and the communications dropped maybe they'll reestablish but you've already had a communication there this is just basically the idea is you've essentially desynced it and so here we can see this so you spoof this and you will get an act back and you'll keep getting these weird acknowledgments back and forth so you can use these spoofing techniques if, and this is the key if you can or if you've dropped the sequence number then you can completely break the TCP connection and inject that into it so even though it seems like there's an additional level of security because you send a packet and you get a reply right there's actually not a lot I mean fundamentally there's not a lot more security components there so we talked about taking a server offline how would we do that so we talked about we're basically breaking your confidentiality by injecting into the string or integrity by injecting into the data string right but what about availability of tax what kind of availability tax could we do here and we've actually already seen that those would be useful right sometimes we want to as an adversary make sure that a certain machine does not respond so you want to take out another machine how do you do that so the way to think about it is there's actually different ways and it actually really corresponds to the layers of the networking stack so you could literally send so much traffic that it saturates the Ethernet cable connected to that computer and literally not enough data can come there that is hard to do that would be a hard thing to do easier would be one level up would be try to hit the router try to overload the router that's right before the hop to that system so the router can't handle the amount of packets that are being sent again that is also hard to do why can you do that from your computer at home probably not what's going to fail first your home router or the router that's in front of an amazon.com server probably your home router those network commercial grade switches are pretty high grade and you have to think about it in terms of leverage so to be able to do that you need to be able to send out as many packets as it takes to take down that server so if your machine is not physically capable of doing that then you cannot do that so then another way so actually most denial of service attacks are all about leverage so I send you 10 bytes and if I can send 10 packets per second and your switch is processing 10 packets per second I don't have any leverage there because I have to send if it takes 500 packets per second to take down your server I have to send 500 packets per second but if I find a way where I send one packet per second and that causes 100 packets per second to go through your switch now I found some leverage where I send one packet and I get 100x leverage so we can actually take this idea to attack on the server side so one way I can take down a server is make it consume too much memory we've got this from the server's perspective so a client sends a SIN packet to the server what does the client then have to do what's inside that SIN packet it addresses important numbers and what else a sequence number and then the client sends back what a SIN act what does the server do they send a SIN act and then what happens from the server's perspective they wait, they just have to wait and when they get the acknowledgement back how do they know that it was an acknowledgement to the initial SIN packet the sequence number matches the port and IP address so think about it this way I as an attacker I send one packet a SIN packet and I can cause the server to store memory because they have to remember the sequence number the IP addresses of the ports but I don't have to store anything I store zero amount of information all I have to do is send SIN packets so this is a SIN flooding attack you flood the server with SIN packets and for every SIN packet for however long they wait for the SIN for the final act they will hold that memory so you make the server use more and more memory so it can't accept any more incoming connections then we'll wrap up now