 All right. Hello. Good afternoon. Okay, so people, so there's still time to solve the extra credit. Nobody has yet solved it. So I won't tell you anything about it until Tuesday. Did you get it? Could I have gotten it? Yes. I mean, that's a pretty, I mean, I know exactly, I'm not saying the answer is yes. Any other questions or five release my six. So you should still start it early, but it gives you time rather than make it to like during Thanksgiving. Okay, so we have been talking about TCP. So somebody remind us what is how does TCP initiate communication. So three step process. So in what way, who sends what first? So initiator sends a SIN request with a sequence number of their choosing. And then what does the server or the recipient then do if they want to choose to communicate? They return a packet with a SIN ACT flex. With a SIN ACT packet back, which then does what? What do they have in that packet? So first they put as their sequence number, a new number, so their own sequence number, and then they acknowledge the initiator sequence number plus one. All right, cool. So we can see kind of a visualization of this three way handshake, the client sends a server. So these are the important information from the TCP header. So we have source port 1397 destination port 22, what's port 22? SSH. Yeah, SSH port generates a random sequence number of 6574 acknowledgement number of zero and sets the SIN flag to one, all the other flags to zero. Yes. From using stuff. There should be a file, I think it's EDC ports or ports maybe, which has the number name mapping. There's also the, I don't know if it's ICANN, I don't know who, there is an official list of official ports also that you can look at. Yeah. I believe it's IANA. What is it? I believe it's IANA. IANA, yeah, the signal of new domain names, I think. Is that right? Yeah. So anyways, there's a list and you just, over time you start to learn the familiar ones, 22, SSH, AD is HTTP, 443 is HTTPS, I think. I don't know, just kind of learn over time. It's not important, you can always look it up, it's just there. Cool. Okay, so the server wants to respond to this. So we know that in this packet that's a response, so the source and destination ports are going to get flipped. Source port 22, destination 13987. The sequence number is now the server's new random sequence number. And the acknowledgement number is one plus the client's sequence number with the SIN and the ACT flag. So SIN, SIN ACT, and then finally the client will respond with an acknowledgement message that completes the handshake. So again, source port, destination port, sequence number of 6575, acknowledgement number of 7612. So this is showing that they're doing the same plus one operation here on the acknowledgement number that the server did for the client's sequence number. Does that make sense? Cool. And set the ACT flag, so SIN, SIN ACT, ACT, man we're ready to go, and now we need to send data. But what do we want to get? So what properties do we want to get out of the sending of data? Reliable, which means what? The server has to receive data from you. You want to know, or an application wants to know that data was received by the other side. So that it didn't get dropped along the way. Other things we talked about, the data didn't get duplicated. They didn't miss a byte of the communication that you sent. You know exactly how to do that. So the idea is actually pretty simple. And the whole idea is we're going to use the sequence and acknowledgement numbers. Kind of as you can think of at this point, they're starting at zero. So it's all relative based on this number. And what's going to happen is whenever one side sends data to the other, they're going to wait for an acknowledgement at the other side. So every packet that comes from one side to the other, the acknowledgement will be the last bytes that they saw from the other side. So let's walk through an example of this. So continuing off of our other example, because this is going to be better because the numbers need to add up. This needs to be very particular. That's why I don't want to do it by hand. So now that our circuit, our three-way handshake has been done, now we want to exchange some data. So the client in this case is going to send 25 bytes of data from the client to the server. Now at this point, does the client know that the server received this? Can it say reliably that the client received these 25 bytes? No, it can't say anything about that. And so what the server will do, and just like before, right, this is kind of the nature of getting this reliable communication, we need a message back from the server that says, yes, I saw that message. And then we can know for certain that the other side is up and received the information that we sent. So what is the server going to acknowledge? So if the server sends back a packet with an acknowledgement number of this sequence number, what does that mean? Yeah, don't you mean the sequence number plus one? So we're not doing any plus ones anymore. That's only for the initial setup. At this point, these numbers represent essentially what was the last byte that you... So if this was zero, right, the server would send back an acknowledgement with zero that says I've seen up to byte zero. So if we send 25 bytes to the server, we want to make sure that we saw how many bytes coming back. So what the server is going to do is actually a fairly simple concept. The server is going to increment the client's sequence number by 25 and acknowledge that and say I've seen up to this byte. So that's exactly what happened. So the server says my sequence number is still at 7612 because I haven't sent you any data between here. And I've acknowledged I've seen up until byte 6600. And now when the client receives this, do they know that the other side saw those 25 bytes? Yes, absolutely. Without a doubt, we know that... Well, we actually don't know that it was this specific server, but we know that somebody else is acknowledging that they saw that information. So we know that the information should have gotten there and now we're getting a response back. Yeah. Is the app like always one after a connection is made? Yes. I think in... Unless... So Finn is used when you want to close the connection. Reset is used to reset a connection, which is kind of like... That's usually when something went wrong. But yes, so that acknowledge flag is usually always set. How does it deal with like overflows of the sequence number and the acknowledgement number? It just rolls over and it keeps going. Yeah. So yeah, it does it very simply without anything fancy. So let's say the server in this message sends back 30 bytes of data back to the client in response to that. Then what is the client... What is the client going to send back to the server to acknowledge that it received that information? Yeah. So it'll take the sequence number of the server, 7612, add 30 to it and use that as its acknowledgement number. What's it going to send as its sequence number? 6600, exactly. So... Is that right? Good. Look at numbers add up. Always good. So in this way... So does... So in this case, this packet, like does the client... So in this case, the server wanted to reply to the client with some information. Here we're not sending any data. Do we still have to send this packet? The server knows that you received it. So the server knows that we received it, right? Otherwise, maybe we've never received it. So let's go over some cases that can occur very briefly. Okay. So we'll... We'll start out with... I don't want this to be easy. So we have our client, we have our server. The client's sequence number is zero. The server's sequence number is 100. Easy enough. So the client sends a packet to the server. That is 25 bytes again. And has... So we know it's going to have its own sequence number of zero and an act of 100. So... This data never gets to the server. What does the client do? So resend it. So one of the things is maybe this got dropped. Maybe something happens. So we can just resend it. We can retry a couple of times. Sequence zero. Act 100. 25 bytes. But now, the network all of a sudden got back up. This packet was stuck somewhere. And now the server receives two of these packets. What does it do with them? Why does it drop the second one? How does it know that it already received it? Based on the sequence number. Based on the sequence number, exactly. So if you think about it, the data, and this is when we think of this communication as a stream. So starting at sequence number zero for the client. So this is for the client. The client has all this data they want to send. This packet is at sequence number zero containing 25 bytes. Which means it is bytes... Well, numbering gets tricky. But the first 25 bytes, let's say. And we know this packet shouldn't be any different. Because it's not like the application can change the bytes that it originally meant to send. That doesn't make any sense. It's trying to send this 25 bytes. So if the server receives both these packets, it will say, oh, I already have that information for these bytes. So it actually may discard it or it may overwrite it. It kind of depends on the implementation. But it will be justified in throwing those packets away. Does that make sense? So this is how we get non-duplication. Like, we don't care about duplicated packets. We know IP can do that because there's no guarantees of the IP layer that packets won't be duplicated. But here, in this mechanism of using these sequence and acknowledgement numbers, we're able to ensure that we only have one copy of the data that is sent. So is there any difference in the case where our original packet is lost or S's reply is lost? So we send this original message. The server sends a sequence number of 100, an ACK of 25. I've seen up to 25. And I'm sending a 0 byte packet. What if that gets lost? Yeah, exactly. It's exactly the same. And it all again is a matter of perspective. So if you put yourself in the perspective of the client, what I know is that I sent this packet of 25 bytes, and I never got a reply. That's all I know. You don't know if that original message got lost or the reply got lost, and you don't care. So as long as you have some mechanism to retransmit a certain number of times and give up after a certain number of times, then you're good. We're not going to go into all the details here. TCP has all kinds of performance enhancements and all sorts of stuff we're actually not going to get into. But we want to understand the basic mechanisms here specifically so we can understand how to eavesdrop and inject information in these communications. Any questions? See, it's not that crazy. OK. And then, so we have initiating a connection. So you think about the life cycle of a communication. You initiate the communication with a three-way handshake. A send, send act, act. You then send data incrementing acknowledgement numbers to always letting the other side know exactly where you are in the stream and what you've seen. And then you want to stop talking. And you want to stop talking nicely. You want to go to the other party and just not say anything. You want to actually end the communication because you know you're done. So it's very easy. And because, remember, TCP is a two-way communication circuit. So either side can communicate. It's called duplex. So you can, it doesn't really matter what the term is called. But basically, the client can tell the server, hey, I'm never going to send you a message again. Or I'm not going to send you any more data again. Let me give you some more correct way. I'm going to send you some more data to you so I can send a thin packet, which now the server knows not to expect any more communications. The server will acknowledge that it saw that. And here we get another plus one to acknowledge that we actually saw that packet and were responding to it. And we sent 30 bytes. And now the other side, and then we can send a thin packet. And the other side will eventually acknowledge that it got all this data that we're no longer talking to each other. And now after all this, that virtual circuit is gone. Yeah. If a packet hangs and they've already established the finished communication and the server receives a packet, will it just drop it? Probably. I think it depends on the implementation. Or actually, I'm sure the spec may specify what usually happens in that case is you get a reset packet where the server will send a packet with a reset flag to you, which it says, like, completely restart this transaction because this communication will get something messed up completely. And that would be one of those things. You didn't follow that spec. I wasn't expecting you to send information, so I'm going to kill this. Yeah. Is there a protocol for, like, only the one who initiated the connection can send the thin packet in terminated? No. Because otherwise you could keep the other side hostage in some sense. Or, I mean, it kind of goes into the concept of timeouts, like, when do you? So let's say you start a TCP connection. If neither side sends any data, then that connection can theoretically remain open as long as possible until one side wants to send data. But you're using resources on both machines to actually keep this connection open, so you may not want to do that. You may want to timeout connections and all this kind of stuff, which is why we have to deal with those. Like, if you have a long-running SSH session, it can be a thing, yeah. So for the shutdown, is it just, is it a 30 bytes at the server sending? That's just because it had more data to send? Yes. Just in general, okay. Exactly. It doesn't have to go like this. It can just be thin, thin, and we're done. Or, thin, thin, an acknowledgement of the thin and then you're done. So how does, we said earlier with, like, reliability that we wanted it to, like, we want to make sure that, like, bits don't get flipped or something to that effect? How does this ensure that kind of reliability? I mean, it ensures that both sides are seeing it and that they're getting the same number of bytes, but the content isn't like... That would be basically in the checksum. So the checksum would not guarantee, because it's a checksum and not a cryptographic hash, but the checksum would give you a pretty good theoretical idea that it is the same. So yeah, that's why I think when I talk about that integrity, it's not quite the integrity that we expect as security folks and in a security class, but it is some kind of integrity. So if somebody randomly flipped a bit along the way, the other side wouldn't accept that and would drop that packet, and then the client would be able to tell because it didn't get an acknowledgement, and so it would resend that data. Other cool things, just really quickly, since we're on this topic. The spec also doesn't say anything about having to only send one packet. So at a time, you don't have to send data and wait for an act and send data. If you have more data to send, you can send multiple things at once, and there's a limit, I think, on how many in-flight packets one side can have. I don't know, you have to look at the spec. But the idea here is this is nice because the server can send, or the client, in this case, can send, let's say, 25 bytes, and then let's say, oh, it's gotten very quickly another 25 bytes to send. What's its sequence number that it's going to put? 25, because it's going to be this one plus sequence number plus 25. It's going to acknowledge that the last one it saw was 100, and it's going to send a new 25 bytes. So now the question becomes, what does the server do in the case that this packet is lost and it only receives this packet? If we think about this in terms of the string, we've received the data up till here, so what should we send as an acknowledgement when we get that second packet? Zero. Zero, why zero? So we send zero. Yeah, exactly. When you think about this as a string, what is the byte that we have received the most data up to? So in this case, we'd say, well, we've only seen up to zero. In this case, we say we haven't seen anything, but in the general case, we could say, so let's say we send zero to 25, 25 through 50, and 50 through 75 in three different packets. And let's say the middle one doesn't show up, but the second one sends. We would then say, hey, we would send back an act of acknowledging up to 25. I'm seen up to 25. And then it's their responsibility to resend these next segments to make sure they come back to us. Do I hold on to 50 to 75? That's a good question. I don't know. I think you're going to get sent anyways because the way you acknowledge back, because so from the client's perspective, they have no idea if you lost 25 to 50 or 50 to 75. So they're going to send both of them to you anyways. I think in this case, you may keep it, but I don't know. You're probably going to overwrite it when that new packet comes in anyways. Is there a limit to how much that is? Yes, so we're not going to talk about it because there's this not a dedicated networking course we're covering at a high level, at a high low level, the things that we need to study in order to understand how these exploits work and attack these things. There's a concept known as a TCP window where once I tell you, I will only accept up to this many bytes in flight. Otherwise, don't send me anymore because you can think about overloading another machine by sending way too much information and you have all kinds of devices on a network, right? You have massive servers and you have tiny embedded like Raspberry Pi devices with little memory. If I was like an malicious attacker and I was receiving packets from like a server, could I just say I've never seen anything and have them continually resend? Sure. You could at a certain point they will think that there's too much packet lost or too many packets are getting lost and they'll just stop the connection so you have to think of what you're really getting out of it. Is there a standard way that the checksum operates where you could theoretically flip multiple bits so that you still get a positive on the checksum at the end? Oh, for sure. Yes. This, I believe it uses like CRC32 but I'm not 100% certain. I don't do it in this class. In my grad class, I have an assignment where they basically have to break CRC32 and create another file that has the same checksum. So it's very easy actually to do. In that case, what would happen? Like other like... It would just work just fine. I mean, it depends on the application, right? Of what you're actually able to do. But yeah, it would just be... You'd send some stuff and what you've sent is not what was received. So this is why... For a lot of protocols like HTTPS you need another layer on top of TCP that does encryption and integrity of what we would expect so that we can cryptographically guarantee what we sent is what is received. And that uses all the encryption stuff we talked about. Cool. There's a lot of other information here but we hit the good ones. Okay, cool. Any more questions on the operation of TCP? Because now we're going to go into the... how we can go through the attacks that we've looked at before. Yeah. So, for the last one here... Mm-hmm. How can the server know that the client got the last one? This one? It doesn't know that. Sorry. This one? So the server sends 30 bytes? Yeah. How can it know that the client got it? Ah, it uses this... Good. So the... The thing is that if Finn means that I will no longer send you data I'm not going to send any more packets. So it could... It will acknowledge that it received these bytes so this acknowledgement should be 30 bytes above this sequence number so I'm going to say I've received those bytes and then this additional one is from this Finn. So it's part of that Finn that says, okay, I've seen up to... or I've seen 8807 which is 8777 plus 30 and this Finn means that I... I'm acknowledging that this byte incrementing me is one. So I saw that, yeah. What if it's just a response to that? The last one? If it was just a response to this it would be 8807 and then there would be another acknowledgement message with 8808 to acknowledge this. So it kind of depends on the timing here and exactly what happens. Is the shutdown basically a three-way handshake but with Finn's... like with Finn flag and the acknowledge flag? Or like a one-way handshake? I don't know, a two-way handshake? Like nobody really cares. I don't know. Like I say... Three-way in the sense that you have to send a request at the connection of the surface response and the... Right, yeah, because you just say I'm done talking and they say great and then they can still send you data and then you... they would say now I'm done talking and then you would say great and now you're completely done. But there are two directions so it's kind of like a two-way handshakes in some sense. So yeah, it's a little bit different and you could probably explore the spec and figure out all kind of weird stuff of what happens if you... like what happens if you set up Finn and then they sent you... you acknowledge it but then acknowledge the previous one where they resend data. Like I have no idea. There's all kinds of weird ways that networks can break and protocols can break. There may be really interesting security vulnerabilities present here too. But if you're interested in networking stuff we have a number of networking courses go all super deep in this stuff and understand exactly how all these things work with window sizes and the TCT... The other question is what to do when you drop a packet because that means there's likely congestion in the network so there's questions of how fast you send packets, how do things communicate. There's interesting differences between what the spec says you should do and what modern operating systems do because networks have gotten faster and better and more reliable so there's optimizations you can make super complex topics. For our purposes though going back to reconnaissance what do we want to know about the UDP applications running on a remote system? Versions? We also want to know what applications were running in the first place so that was the concept of the port scan. So similarly we want to do the same thing with TCP. So how do we do that? How do you build NMAP to do it? ICMP packets. ICMP packets will not are at the level of IP they have no concept of ports I believe. I don't know if that's 100% true but it's tricky. We can just send SIM packets everywhere? Send SIM packets everywhere. So just like every time a port scan we can send SIM packets to every single port on the remote system and what is our way of telling if that service is up or not? Don't respond how. The SINAC? Yes. I know. So if we send a SIN and there's an application listening it will send us a SINAC back. And then we can send a SIN or we can send an AC and then close the connection so that would be one way to do it. What if there's no application listening on that port? What would we expect the system to do? Maybe nothing? How could we figure out what should it do if there's no application running? Oh, we would send like there's nothing going on. What was that packet going to look like? Yeah, so it depends on the spec. We look at the TZD spec and we'd see what should happen if an application is not running or the remote system is not expecting incoming SIN packets. I believe in most systems it will send a reset. So it's actually pretty easy. We send 65,000 packets so a system, one for each port and we look at what we get back. If we get back SINACs then we're good. If you have an application listening to a port can only one port be used at any given time for an application? Yes. Well, one port per protocol. So that was the thing we talked about on Tuesday. I did talk with some people and I think you looked it up in class. You can have one application or two applications listen on the same port one TZD, one UDP, that's fine but you can't have multiple applications on your machine listening for incoming connections on the same port with the same protocol. Does that also mean that multiple incoming connections cannot go to the same port so like two people, doesn't make sense two people can't connect to the same port at the same time for the same application? Why not? It can't be different applications but depending on how you write your server application you would write it to loop over all incoming connections. So anytime the operating system gets a new connection it'll call your program you'll deal with it and then this is when you need multi-threading or multi-process in order to actually handle a response to that but you can have any number of open connections as an application. So you don't need to worry about that. You need to worry about handling it and what that means but you don't have to worry about not getting that incoming connection. Does that make sense? Yeah. So that was with UDP because UDP is has no built-in way of saying there's nothing listening here. TCP has this concept of a three-way handshake so it has built-in if you send a SIN and you're not expecting it send a reset I believe is in the protocol. So if you send a SIN to a port that it's not nothing is listening the operating system will send you back a reset. If you send a SIN to a port or something if you send a SIN to a port if you send a SIN to a port or something is listening the operating system knows that and it will send you back a SIN act to start the communication. It's ETC services. If you look on a Unix machine which includes Mac machines I think if you look at ETC services it shows you the port and like short name mappings. So the very simple way to do this is use the all connect to just connect to every different port on that operating system on that remote system and you know if the handshake is successful then the service is available. So what is connect and how can we figure out what connect is? What do I mean by what is it? What kind of function is it though? Who does this connect? I would assume it sends like a TCP SIN packet with the SIN flag but what does the OS and how do we figure out if that's the case? We look at the manual for connect which is what we're going to do now you can make me do this. Yeah, we'd read the documentation that should be your number one. Of course this won't work which will be funny. Okay, cool. So we have to read all of this to figure out you can actually get very far on network programming just with with the man pages I think I wrote a server once on a plane just using man pages it was actually really fun like all the information is in here you just have to figure out where to get it. So, okay. So I guess it doesn't say system calls great so this is BSD but whatever we can ignore it for now it's basically the same style as analytics so the system call which means the operating system is doing this which means the operating system is going to handle the SIN, SIN act so what applications can call a connect, can call the connect function sorry system call which is all a function yeah. Root, so only root applications should be able to make outgoing connections is it like any application as long as they have such a request that the operating system doesn't work? Yeah, think about your computer right so every application that you're running that's making an outgoing request is calling that function to connect to some remote system so any application should be able to run it so we don't need to be root and this is what is nice about this we can scan another machine without being root or our current machine how many so let's say we're scanning all 65,535 ports on a remote system how many packets will be sent with this? Protocol or the operating system says it's like the SIN 4 and it gets no response when it finds out that time okay so yeah so it depends on how many open ports there are so we think at the least we're going to send out 65,535 SIN packets and then the remote side for every application that's not running it will send us back a reset and then for every application that is running there what's it going to send us back? A SIN AC and then what are we going to send back? An AC so that's like it's her open port and two packets per closed port it's kind of a lot of traffic and you can do this pretty easily NMAP has this option I believe it's SP and it will look at all these ports doing connect scanning so you just look at connect scanning it will do that yeah it's an application running on a port but it just rejects of SIN so what do we get back? you would get back that that port is closed and if you think about it if there is an application listening on there how could you talk to that application? if it's not sending back a SIN AC how could you talk to that? the question is from your perspective what's the difference between it being closed between no application listening and it never sending you a SIN AC back yes there's no difference right in my mind right so if there's an application listening who's sending back a SIN AC yes and if it doesn't want to talk to you who's also sending back a SIN AC no I think well it's probably possible to write an application that does that directly in general if you're writing a normal application it would create a three way handshake the server then now knows your IP address and say kill the connection because I don't accept connections from that IP address does that make sense because that's usually how you base the blocking from but you'd still need to like talk to that application what's the next scanning in general does it actually use like banner grab a bigger printing or is it just port name resolution 1.2 port name all this does is look up in your services and maps the ports to the name actually and that itself may have a better list I don't know but yeah fundamentally I don't think it does anything beyond that it may have additional options definitely not the options we're using here is there a way to end the connection other than FIN because doesn't FIN just say I'm not sending any more data couldn't you still theoretically send more data into the connection you theoretically could I mean you can always send whatever packet you want to any other machine any point right the question is what are they going to do with it so in that case the other side would probably ignore it but said hey you said you're not talking to me so I'm just going to ignore this data or it could say whoa this is really crazy something must have messed up I'm going to reset my connection with you so it's going to be basically broken any other questions so yeah question general question why are there only 65,000 ports again and the bits are there for to represent a port and a TCP header and a UDP header yeah it has to be based on the 65 right so cool okay so now if we but how can we make this faster what is the so what bit of information for each port are we trying to learn is there an application listening exactly at what point through this process do we learn that bit of answer anyway when they when they reply to our sin request right when they reply with a sin act right we don't actually need to reply with our final act to start that communication so this is known as like sin scanning or half open scanning where we don't we never finish the three way handshake so we send a sin packet the server answers with the sin act if the port is open or with a reset if the packet is closed so this is what's nice is we again have that statement to be able to tell what it does and again the really interesting thing here we're going to see it's just that one bit of information is what we're trying to learn right is that application open or not and all we can do is feed external inputs to try to figure that out so we're looking at what's the difference what does the TCP IP stack do if we send a sin packet to a port when application is listening or not listening and here so we can send a reset packet or we can send we can just not send anything and let that connection time out one of the benefits here is this connection is never actually officially open so it may not be logged so if you have devices looking like in most operating systems it won't log and say hey there was a connection the application will never get that notification that says there was a connection from this IP address because there wasn't there was only the start of a connection and then something happens are some ports like TCP specific and some port to UDP specific or there are various port numbers that are more and protocols like I think it's more there are various applications that are specific to each port and there are applications that use specific protocols like DNS uses as port 53 I believe UDP I mean is it 52 somebody knows let me know but you can also run DNS server on TCP like that's totally possible it doesn't have to be UDP but it is for most purposes so yeah it's just kind of like there's UDP based applications and they are tied to specific ports and there's TCP based applications that are tied to specific ports so is the same amount of log or IP address it may not depending on what the operating system does so yeah because if it's logging let's say every incoming connection or you think about a web server right anybody look at a web server log like I can look at it actually freaked me out one time I was looking at the logs of the submission system after I had created a homework assignment submission or something and I was looking through the logs and I saw people starting to hit that assignment before I had released it and I freaked out I was like wait Ferris are you looking at the assignment right now he's like yes so I was like okay good this makes sense like I thought because I restricted it's only admins could see that and so if you want to be able to see that you'd like broke it into one of our accounts which I was very worried about so anyways the server will only log incoming connections when it has a new TCP connection and then it will create a log entry in the HTTP log that hey this IP made this request if you never initiate the connection there was never a request to log so it would not log it there maybe log somewhere else it's all I'm sure it's possible to configure an OS to log these things usually by default they won't be logged and so that looks like Nmap you can use the dash s option and so here on this system we can see that port 80 the HTTP port is open and we can look at the TCP dump of traffic of this machine so we can see that here we have the SIN from 128 111 4869 port whatever the random port doesn't matter 128 111 4138 which is the yeah yeah that's right no this 41 should not be here because port 78 what is going on alright whatever that's super weird but anyways these last are all of these so it's sending SIN packets to all of these ports and then it looks back a reset so there's a reset packet from port 78 so we know 78 is closed a reset packet to port 81 a reset packet to port 82 and then a SIN this is the SINAC packet to port from port 80 which means that's open and then we I guess this NMF resets that so it never starts the connection and there's various other ways I won't go into all of them but there's all kinds of ways that they do you can do if you look through the man page of NMAP you can look at all the different crazy options there and it's all about this idea of when I send this packet to a specific port on a specific machine does the TCP IP stack give me a different response if there's an application listening or not some of the things they do are what happened if I was called a Christmas tree scan where what happens if I set every single option flag in the TCP packet so what if I send a SINAC thin reset all of those what does it do it doesn't do something different if there's an application running it turns out yes in a lot of cases it does or a null there's a null scan of what happens if you send all zero bytes like no flag set you know all kinds of weirdness you can even go more complicated of exactly what we're talking about what happens if you send a SIN and then a reset what does it do does it do something different so there's all cases where you can fingerprint based on this and you may have to go into the specifics of how different operating systems go and use so this is useful for finding out what services are running on the remote system but how do we know what operating system they're running and is that a useful piece of information how does it do it how does it do it how does it do it why is that useful because there might be some vulnerabilities for a specific OS so you can exploit them yeah we maybe see that they're running Windows XP and there's tons of old vulnerabilities for Windows XP or even just a two month out of date version of the latest operating system could have known remote exploits that you can use to take over plus it gives you information about if they're running a whatever if you see there's an HTTP server and you also find out it's a Windows host it's likely that web server is IIS if it's a Linux host it's probably likely to be Apache or Nginx or one of these things so it helped you kind of refine what you're looking at and what you're looking for but yes how do you find out the operating system through Nginx we'll see that there is an option but we care more about why it works so how can we do this it seems like a very counterintuitive problem the problem is there's some remote system do we have access to the source code of that system do we have access to even execute things on that system but it's a complete black box to us but what can we do we can talk to it we can send packets to it that's about it that's the only thing we can do and the idea is kind of building on this port scanning idea and this port scanning concept and saying ok what does Windows do if you send a packet with all the flags set is that different than so if you think about the TCP or UDP or IP whatever if you think about their protocols and you study their protocols they will tell you very well exactly how it should work in the good cases specifications are usually very vague and leave out information of what to do in every single weird corner case that could ever happen and so who decides what happens in those weird corner cases the I would say the OS it makes it sound sentient the OS developer right so yeah the developers who wrote the operating system they need to figure out what do I do if I send a packet what do I do if I receive a data after a fin packet or a reset packet or a I don't know and how do I choose my window size and what do I do if I drop packets all these are decisions that are made by each individual implementation and so by studying and compiling this big large tree of differences you can actually remotely fingerprint the operating system version by using these as kind of so what happened if so all kinds of weird things like and also you get it's not just like un-behind undefined behavior in the spec but sometimes not following the spec correctly so do they reply incorrectly to a fin packet that could be one way of fingerprinting it what happens if we do weird combination of flags in the TCP header is there a pattern how they select the initial sequence numbers that we can use to fingerprint and detect the operating system what about the window size how do they use ICMP messages we saw that when we were sending UDP packets to unknown ports there was a limit on Linux to I think it was 8 messages per second that it would respond to does that same thing exist on windows does it send us a response or not each of these responses leaks bits of information from the system what's going on there error rates TCP options the crazy thing is that there's a tool called the POF which you can use on a data packet or just on the data that can try to infer passively without injecting any traffic what are the operating systems of the machines you're talking to yeah so if you knew how NMAP sent out packets or something like spoof your OS or somebody else's OS to make them think that you're using something that you're not yes for sure you'd have to tweak your OS tweaking the settings would be easiest if you could figure out what settings it uses to figure things out but it'd be I'd say it'd be difficult because a lot of these are kind of structural code based things so you're basically kind of changing your TCP ID stack to be more like windows which is weird right so you're probably going to introduce some other problems in there I would not recommend it and then you may find out your web server is leaking like it puts the Ubuntu Linux in the response better so you did all this work at this level and forgot about other stuff so NMAP it does have an option I think it's dash capital O is the one that does this that does OS fingerprinting I think it's just super cool if you're using your own machine see what it says it's a little weird now with all the like mobile devices and everything so things get muddy but it still does work easily well and gives you at least a good kind of target point and it can even tell you the other thing they do is they look at different versions of operating systems so let's say generally you can figure out a windows machine now we know that windows 7 does this behavior and then windows 10 does something different in a different circumstance so this way you're able to kind of detect even versions of operating systems theoretically yes it is hard to and I think that does exist for various specific applications but for most apps I don't know of a tool that does this automatically that can like generate this ability to fingerprint manually but there's all kinds of this concept of fingerprinting comes up a lot when you're browsing the web various like ad JavaScript tries to fingerprint your browser so that that way even if you clear your cookies or whatever it can link you like that's often times how it knows it's you even if you're using private mode or other kinds of things because it's using creating fingerprints based on the browser everybody's all browsers are going to be slightly different and machines are different all kinds of stuff so now I want to move to how can we so now we want to look at our old friends of IP spoofing and IP hijacking and say how does that work now in a TCP connection so if we go back to what we had and what we wanted we have our good friends Alice and Bob and they want to communicate with each other Alice wants to initiate a connection to Bob what is Alice sending to Bob sympathetic packet so we want to let's say we want to spoof so let's say we want to spoof a connection let's say from Alice to Bob so we're Eve we want to pretend to be Alice to Bob how can we do that so what packet do we have to initially send we have to send a sin packet right what does that sin packet look like so it has some sequence number it has a sin flag we know the from the source port is whatever we put doesn't matter the destination port is whatever port we're trying to say let's say this is a and so what scenario would this be let's say this is a web server that only allows admin access only from certain IP addresses and that's Alice so this happens a lot so we want to spoof oftentimes this is even local network so that's another trickier thing but let's say that we know Alice is IP we know if we're able to access whatever secret information we want so the destination port is 80, our source port is good and then so what's our source IP Alice's IP can't be our IP our IP and the destination IP and this is all in all the headers of the packet that we want to send is there anything in what we study that prevents us from doing this anyone agree with that okay Bob gets this packet what's that secret sensitive information that we so desperately want what does Bob do SINAC to Alice SINAC to Alice so Bob will create a SINAC packet and where does that go it goes to Eve why does it go to Eve could she ask nicely so let's think about this packet the SINAC packet so the the source port will be the destination port will be whatever we sent here what's the source port 80 so it will have we'll call this Eve sequence number right now so it will be a sequence number of Eve plus actually this will be the sequence number of Bob and it will have the acknowledgement of the sequence number of Eve plus one and it will have what flag set and then what about the IP Alice what's the source IP computers so source IP, Bob's IP destination IP Alice's IP so what happens to this packet in the network we've studied how packets move through the network so are we on a local network let's say no okay then it goes to Alice then it goes to Alice well either way it's going to go to Alice it just depends on how we could do if you're on a local network that can change so assuming we are not on the local network this packet will get sent back to Alice Alice gets this packet and what does Alice do is Alice expecting this packet no so she's going to say go away Bob stop talking to me reset this communication something weird Alice will send a reset packet to Bob and then Bob will terminate this connection so are we completely screwed as Eve can we not do anything what do we want what's our goal to talk to Bob as Alice how do we accomplish that goal how do we need to accomplish that goal we need to either intercept why that way we could modify it to come back to us not quite almost I think you're kidding we need to get the sequence of the right higher level right we want to make a request to Bob how do we get there in front of the TCP send a send three-way handshake we need to establish a three-way handshake first before we can even make a request to Bob right we've made the first part Eve made the first send request to Bob we don't do the send act we're not Bob Bob sends us a send act back so why don't we just send from Eve to Bob an act packet send act act to finish that connection sure but let's not let's say we're super Alice is in the other side of the earth and things got to come up in satellites and we're much closer are we assuming that Eve knows the send act packet that Bob sent or no why how does that change things well because if Eve doesn't know then it can't respond with the acknowledgement why not because it doesn't know Bob's sequence yes oh I think I have colors but I don't know how to use them yet oh there we go how about this why would that be good correctly yeah so the entire security of this whole thing without so if we assume that Eve has no knowledge of this packet that Bob sends Eve would need to create an act packet that acknowledges the sequence number of Bob plus one in order to start this communication otherwise Bob will ignore any packets we send to him so how can we do that I believe it's a 32 bit number it's going to be tricky intercepted Bob's SINAC if we intercepted Bob's SINAC how do we do that oh come on we studied a lot of ways to do that spoof their IP spoof where are you spoof their IP like Alice's IP where are you spoofing Alice's IP but we can't receive spoofing IP packets we can send so the only thing about it we can send a packet with any source IP that we want we can send any packet more or less that have our destination which is why we're not going to receive that SINAC back from Bob I guess unless we get it to the PGP level and we're able to pretend could we lesson on that communication how be more specific we've talked to we've studied network for two weeks now if we're on the same network as Bob we could pretend to be his gateway through the same local network as Bob we can poison the gateway of Bob in order to get that SINAC packet and then we're actually in the middle we can drop that packet and never send it to Alice so she never sends the reset that's one way what else hardware hardware? who's hardware the wiring yeah okay so good right I'm drawing this arrow there's switches along the way and there's physical communications so as long as at any point along here if you've compromised any of this as long as you can see that SINAC packet you can reply with the correct act what else we could do that in which case when can we do that so what has to be true we well we're only going to get that our request we're going to be using local network as Bob so if we're on the same local network as Bob we can do our poisoning games and we can play all kinds of games poison the gateway that's not the only place yeah depending on the security of this link so basically every link along here we can sniff stuff out and get that packet I was going to say if we were on Alice's local network we could also do our poisoning there right especially really about being on Bob's local network we could be on Alice's local network and still do our poisoning to get that packet so this a lot of abilities to do that but very much unlike IP we need to be able to so if you think about this the security of this whole scheme oh there's also other ways there are other ways aren't we assuming that we're not on local network I said that at the start wow I said at the start we're assuming we're not on the local network and then it's like what scenarios could we get that information and one is being on Bob's local network another one would be being on Alice's local network and possibly any of the local networks in between you could also maybe intercept things there but yeah what else why did you care about how many bits like the size of the sequence number why is that important just because you're curious and you forgot why did you want to know that size you can brute force it or guess it what if the sequence number is just based on the current time or what if the sequence number is always zero or what if the sequence number just I don't know increments by 10 every second right so this is the other thing so the security of this whole scheme relies on the randomness of the sequence number and not being able to intercept it along the way if we can get that then we can spoof TCP connections that pretend to be other people on the network isn't it like sketching since they're receiving a lot of random packets that yes it would be very noisy it all depends on how much right I mean brute force so brute forcing if you assume it's a completely random value then you would need what 2 to the 32 which is like 4 billion requests like you'll never make that in the time it takes Alice to respond but if you can window that down because you know like maybe you make a connection to Bob first and you know that his operating system has a relation between sequence numbers and you use that to search around that and maybe get it and another nice thing is you only need to be right once so you can continually do this but yes the more guessing you have to do the noisier it's going to be our sequence is there typically a relationship between sequence numbers and like the time in the operating system or they used to be yeah now they're more random they should be I'm not going to mistake my life on it but yeah so this was this has been known for a long time since back in 1985 of doing this this is everything that we did one thing you can do is you can take down this machine so you can if you want to impersonate that IP you just send a bunch of packets to flood that so it never gets the SIN act from the machine you're trying to get into so you send the SIN it sends a SIN act to that machine it's being flooded by packets from you so it never gets it and then you somehow guess get lucky get the sequence number plus one and do that it is possible because you think about anybody on your local network could basically do that the next thing is hijacking so what was the idea behind hijack well what was the idea behind UDP hijacking how is that different from spoofing yeah we send packets into an existing communication yeah so we want to hijack you can think of it as like data injection right so if you're thinking about an HTML so a web page I may want to inject some javascript code in that response that takes advantage of a exploit sorry takes advantage of an exploit in your browser in order to get any code execution on your machine those things that actually happen that people do and so the technique is very very similar there's an early paper on this that you can check out but the idea is exactly so again we have exactly the same problem because if we want to inject let's say two machines are talking to each other we want to inject some data into there and then we have to know the sequence numbers of both sides to be able to properly do that otherwise they'll be dropped and ignored so again we have the same limitations where we need to be either a person in the middle of the communication to be able to see the communication or we need to be on the local network of either of these clients and servers but so that's actually pretty easy and it's very similar to what what we've done the problem is you can't see this I mean not good ok, just as we saw here so you have the client and the server the client has sent let's say 100 bytes the server has acknowledged 100 bytes and they're not talking and now this is the time we want to inject some information so we inject as Eve a packet spoofing from the client to the server we get the acknowledgement numbers correct and we send 100 bytes what is the server going to send when it gets that reply gets that new data isn't it going to update its acknowledgement number by 100 and send it back to yeah it'll reply with an acknowledgement number of 200 what's the client going to do when it gets that yeah it'll actually send a message with this with a sequence number of 100 and be like actually I've only sent you up to 100 and then when they get that the other side will acknowledge that the last thing they saw was 200 and this side will send a sequence of 100 and this will actually continue basically forever because essentially if you think about it you've desynced both of the views the client thinks they've only sent 100 bytes the server has received 200 bytes but the client doesn't know about it so to solve this you have to man in the middle and change these sequence numbers so they're correct or you just leave it because at one point one of these packets will get dropped because they'll just be constantly talking back and forth one will get dropped and each side goes yes that's what I thought we are at 100 on the other side we are at 200 but now they can actually no longer communicate because they can't send any data to each other because their sequence numbers are off so it's the idea of what you can read about more here so yeah it generates an act storm it's actually really cool to look at it won't like time out at all no because they're yeah they're just it's part of the protocol yeah nobody's losing packets but each side is seeing the wrong packets come back so they resend what they think is the truth and the other side sends the truth back so it's like they just keep arguing until one of them can't hear one's argument okay so we talked about denial of service I'm gonna briefly go over we're so close alright we're gonna finish this out because I want to talk about binaries on Tuesday okay so the one thing we haven't looked at is availability of tax in the network these are actually used to be incredibly common as machines and bandwidth got better so meaningless send enough information or bandwidth to a system to take it down is more difficult but now with the rise of botnets and IoT devices where people have harvested 300,000 routers on the internet and controlled them to send traffic to one machine they're actually able to perform super sophisticated denial of service attacks one of these is just sending SIN packets to a machine so the attacker starts with a SIN the victim replies with a SIN and the attacker does nothing why is this a useful denial of service it will that's a good question I actually don't know let's say it doesn't because that doesn't affect what we're looking at here well the victim just keep waiting for like it'll keep waiting and what is it doing while it waits what have we caused to happen on that system there's some overhead to tracking them it is waiting for a response because it needs to keep track of that sequence number it has to store this IP this port I've used this sequence number so there's some state associated there what does the attacker have to store here yeah I mean it's constant right it's just sending SIN packets and never cares about getting the acknowledgement or doing that so basically all availability attacks denial of service attacks require some form of leverage so here I can send one packet that costs me nothing but it costs you whatever 20-30 bytes to store that and I can keep sending as many as I want and you will keep storing all of those until you can't store anymore and that means legitimate people trying to connect to your system won't be able to so it'll be down for them and the super cool thing about this and we know because we've studied IP packets if we don't care about the response and respond to the SIN act we can put whatever source IP we want so we can make this attack appear to come from anywhere because we don't have to initiate this connection so this is a so you can anyways there's a lot of ways to solve this one is to change your sequence numbers using this idea of SIN cookies to have an algorithm where you don't actually store any information on a SIN act packet it's pretty cool I don't want to go into them all kinds of stuff here so you can create connections actually create connections you can overload the number of processes and the number of threads that are listening to there so this was a common attack against multi-process Apache servers that fork a new process for every connection you just make a hundred or a thousand connections there's a thousand processes running on this server and the server grinds to a halt because it can't keep up with all of this this is pretty crazy so this is what we just talked about forcing the other machine to store memory for you so as a malicious client you could send let's say the data for a whole window size and never send the beginning size so they have to store all this data and they're just waiting for you to send that final byte so they can acknowledge everything and you can do that and never do that and send that from multiple sides very briefly firewalls everyone heard of firewalls cool so when we think of the policies and mechanisms firewalls are mechanisms to enforce a network access policy so if you think about it as an organization you want to make sure what incoming connections are actually what you expect them to be is kind of the way I think about it things like your web server should only allow incoming TCP connections to port A you don't need everyone on the internet to SSH to your server or to access any other ports so you have a device that sits on your network or software running on your system to drop all those other packets so most operating systems now actually have built-in firewalls mainly because your client devices nobody cares like you're very rarely running a server that accepts incoming connections so your machine should just drop any incoming connections they're kind of an important part of network access and mechanisms the other mechanisms I will briefly mention are intrusion detection systems so these are devices that monitor the traffic in your network and try to alert you of if it thinks that somebody has invaded your network so it's a mechanism that's trying to look at that detection piece how do you do this? are these devices easy to make or build? I was assuming it would be pretty complex but if you knew the makeup would look like why would you think it would be complex? because you would have to know the entire structure of the device that would be sending data to each other so it's going to attack your traffic if it is a notice how do you distinguish between attack your traffic and benign traffic do you think about a web server or a sql injection or a cross-site scripting against your web server how do you detect all possible instances of that this is actually an area of active research also a commercial area snort is a common intrusion detection system if you want to learn more about this I recommend running snort on your system and seeing what it says because you have this problem of false positive where it's looking for things but they aren't actually problems the whole problem of so this is the mechanism to do this but how do you actually define the policy of what constitutes an intrusion that's actually the key problem here is that intrusion part detecting can be easy other things are related intrusion prevention systems so the idea is if you detect an intrusion why make you want to detect versus prevent something the prevention would be stop that connection from happening or as detection says I log it somewhere why? yeah if you have mistakes or your detection system makes mistakes you'll block legitimate traffic all kinds of cool stuff we'll start on binaries on Tuesday I'll record it for those that aren't here see y'all later