 Alright, so we're going to talk about UDP, so UDP is now at the application layer of the technology stack. So we saw, so we have our UDP packet, and what's the important piece of information that are in a UDP header? I'm always going to have to raise my hand or something, or say it. Yeah, port number. Yeah, so in the UDP header are destination port and source port, and that's what really UDP adds on top of IP. And that data is then encapsulated inside an IP packet, which is then encapsulated inside an Ethernet packet. So what we want to think about is, do the attacks that we saw at the IP layer, do they translate also to this new UDP? So let's think of it first in a different way. So a machine that hosts gets a UDP packet, how does it know to reply? So you're creating some protocol using UDP. Somebody sent you a request like, hey, what's the DNS name of Google.com? How do you reply to that? So you get a packet with there, so you create a new packet to the destination IP with the source IP as your IP. And then what else? Is it the port information? Yeah, so you need to know how to send it back, the port information. So you would use your, you would flip the source destination ports around as well. So this way when the receiving machine gets that packet back, it knows that it's a response to that request that it already sent. And so we can use this as an attacker. So if we, we can completely, just like with IP packets, we can completely spoof UDP packets. So when a machine, a server receives a UDP packet, it actually has no idea who actually sent it that UDP packet. So it's very similar to IP spoofing, where if we want to, if there's a trusted relationship between a client and a server, we can then as an attacker, send a spoofed packet with a spoofed source IP of the trusted client, a destination IP of the server. And then we'd have to set the UDP destination port to be whatever service we're trying to talk to and just change whatever the port goes back. So then what happens to that reply? What was it? Send it back to the client. Yeah, so the server is then going to change, create a, if the server decides that that needs a response, what it's going to do is then send the UDP packet back to the source IP with its source IP and destination IP with the port split. So you actually won't be then injecting, so you actually won't see this UDP reply, right? Unless you're on the path or on the local area network between both of the end posts. If you're just somewhere on the internet, you won't see that UDP reply, but you can completely spoof that original, that first request. So another thing we can do is we can do UDP hijacking. So in essence, this is, we want to, before we wanted to spoof the initial connection from the client to the server, in this way we want to essentially spoof the reply. So think about it this way. When a client gets a UDP reply back, how does it know it came from the server? What was that? So it knows that the packet that ever sees the source IP address is from the server. What's the other reason that it has to link that to the packet that it initially sent? What was that? Yeah, the source port number, exactly. But besides that, if we're, let's say, on, we could be on the local area network, or maybe we get lucky and do guess that source port, there's only, how many port numbers are there? Yeah, 65,000, and we know it actually won't be less than 10,000, because those are privileged ports, so on our receiving port it wouldn't use that. So we, all it takes is maybe 50,000 guesses to get correct. And so the idea here we're going to be hijacking is the client sends a request to the server, and we either capture that request, or we just guess, and we can get lucky, and the key piece of information we're trying to guess is what's the source port of that UDP packet that the client sent? Then we can, if we can beat the server's UDP reply, we can then get the client to get our packet of the UDP reply. So some of you are wondering again, what is, what's DNS used for? Look around. Yeah, I'm having a domain name to an IP name, right? It would be super annoying to have to browse the internet, typing in IP addresses. And so because of that, right, we want these nice domain name concepts. And so domain name DNS uses UDP, so I can't remember the port. I don't say it's 53, does anybody know what it is? Wow, okay. So the client makes a UDP request to the server on port 53 that says, hey, what's the IP address? Let's say it's google.com. So now imagine you're on their local area network. You're sniffing all the packets. You've played the LAN games so that you can see that request. If you beat the server back with a reply that says, actually google.com is the attacker's IP address. Now they'll be sent to your IP address for google.com instead of Google's actual address. This is one of the key flaws in kind of the one of the internet. So you can play all kinds of fun games and it all comes out to this UDP hijacking attack. So we talked about last week how we wanted to go out attacking, how we go about kind of doing a penetration test of a network. So what types of things do we... So we talked about the importance of reconnaissance, right? We want to understand as much as possible about the local network. And so what would be something that would be useful for an attacker to know about one given remote system? I'm only talking about one machine, one machine. So I just have an IP address. What other information do I want to know about that machine? So I want to know what are the servers that are running on that system? Is that the DNS server? Is that the system running DNS? Is it running a web server on TCP port 80? What does it have on there? And so what we want to do, usually what we want to try to do is map the network. We want to find out what hosts are up by using some kind of ping scan or something like that. And then for each host that we find that's up, we want to do a port scan to figure out what UDP ports are open. So how would you do this? How would you write a UDP port scan of a host? I mean, at a high level, it's very easy. You'll need to somehow determine from zero to two, five, five, three, five, whatever, right? Which ports are open, but how do you actually determine that? Say it again? I would like to find out what all servers are running on this machine or what all ports are open. You first want to know what ports are open because ultimately what's running on that port is dependent on that server. You can run, like, so for instance, the CTF is a good example, right? Ports, was it 21 and 22 or 20? 20 and 21 are FTP ports, but you can create your service and your server to listen on any port, right? Which is what they did to somehow get around some weird firewall thing that's happening. I don't know where. I have a hard time believing it's ASU, but I don't know. So that's the idea. So we first want to know what's there and then we know what's there. A, we can use, there's a list of registered servers, port numbers that map to specific services that doesn't guarantee that it's actually there, right? You have to take the next step to look, inspect, talk to that service to see if you can determine what's actually running there. But it's a really good starting point, right? Because if you don't know if a port is open, which means there's something listening, then you're not going to get anything. So how are we able to listen to the ports? Or how are we able to determine? Yeah, but how does it work? It's a request to make a connection and ultimately it resets that connection. On UDP? UDP, or TCP, for example. I'm not talking about TCP, I'm talking about UDP. Can we just, I don't know about UDP packets, but if you can just request across a set of the group forces, I don't know, just to see who's alive on the side of the ports. Yes, so we're definitely going to send a bunch of packets, absolutely. So we're going to send one packet basically per port number. What we're looking for is we're looking for one bit of information that tells us is there something listening on this port or not. And so the way to do that kind of depends, you know, depending on the system. So UDP is actually the hardest as we'll see TCP is a lot easier because of how it actually works. So essentially we're looking here at the UDP case of a negative case. So we send a packet and we will get an ICMP port unreachable message if there's nothing listening on that port. The problem here is that a lot of operating systems will, some will do this, some may not do this, you don't actually have to do this. And some of them rate limit how much they respond back. So this is why when you do this, this could be a very slow scan because you're sending, you can only scan 80 ports every four seconds. So it's a slow type of scan. And that's kind of by the nature of UDP, right? There is no set up, no connection, there's nothing. It's just you send a packet somewhere and maybe you get a response back, maybe not. The other interesting thing that I actually have a story from days ago when I was doing some PEN tests. So you can see here by default Nmap does 1,445 ports. And so here it's saying that it saw these ports around. Why is it doing 65, why is it telling me it tested 65,000 ports? Maybe it's not looking for transient ports. Yeah, maybe it's not looking for transient ports. So essentially it's prioritizing what ports to look for based on what are more likely UDP ports to be open. So you have to add an extra flag to get it to scan for all the ports. So on this network that we were on, they were shocked to learn that one of their computers had the, I believe it's the IPMI, which is like a remote management soft link. I think it was remote, yeah, remote management for servers so that if your server is down, there's actually a second processor there that you can get into to reboot it. This interface had a default username password. And the problem was that they had internal scans that were running every night, but they didn't have the option to scan every single port. So they were only scanning these basic ports that were missing this feature. It was actually really fun. I think I maybe mentioned this before. It was their credit card processing server. So I wanted to try to get access onto that server to try to steal the credit card. But then we told them what we found and what we could possibly do though. Don't absolutely do not do that. We believe you. It's a good time. And so we see the packets that are getting sent. So here we can see one and two, 168.1 out of 100 is sending all these packets to 1.10. So can we mask our IP address in this case? Can we spoof? Or when I say masking, can we spoof and just make these packets come from any IP address? We should be able to. Because UDP doesn't have any handshake, right? True. Yeah. We should be able to. But what are we trying to get back? How do we know if this port is open or closed? We need the ICMP port closed message, which will come to us on the IP address, exactly. So here we can see we're looking at ports 138, 134, 137. It's going to send all these. And so we get back here, port 134 unreachable, 140 unreachable, 131, 132, 135. So we get back all these packets. And from this, basically, you can figure out all the ports that are closed and the ones that are not closed are likely open. So UDP is very, very simple. So it's basically 100% datagram. Just here's some data. Throw in another server. It is still used in a lot of applications that don't need all of the nice features that TCP adds. So TCP adds a whole lot of features that we actually want from a communication protocol. It's where the idea is, so rather than just here, send one packet of data to a remote host, and then maybe they'll get that data and send you a response back, here what we're going to do is actually establish a connection between two hosts on the network. So now, and we're actually going to now guarantee no loss. So both sides will know that each side has seen a certain, up to a certain amount of the transaction, of the communication, that there was no transmission errors and that the packets are received in order. What this means with UDP, if you send five packets from host A to host B, there's no guarantee that they arrive in the order that you sent them in. So you have to add other mechanisms on top of that. So TCP gives you that by default. So if you're using TCP, you get all these great features. And it also uses this idea of this port abstraction. So the key concept in TCP networks is the idea of a virtual circuit or it's often also called a socket when you're talking about client or server-side programming. The idea is you know that host A and host B are communicating and you'll know that because they're communicating on a circuit which is the source IP, the destination IP, the source port and the destination port. So that tuple defines a virtual circuit. And another nice thing about TCP is it's full duplex. So either side, once a communication is established, either side can send data. So there are more headers and more headers that are actually important in the TCP level. So we have just like UDP, source ports and destination ports. They're the same size. It makes sense. You don't want these two terminals to be crazy different. Underneath that we have a 32-bit sequence number and an acknowledgement number which we'll talk about how these are used later. Header length, reserve, some flags which are important. The window which we're not going to talk about but when you get into it it's an interesting mechanism of how you can not overload a client or a server. So check some options, padding and then the data. And again, just like before, our TCP data is going to have a TCP header which makes up the IP data which before that has an IP header which is then at each stage of the multi-stage hop is going to go into an Ethernet frame with its own Ethernet frame header. So okay, we're going to skip that, sequence acknowledgments, great, great, great. Setup, recording's going, everything's good. Okay, so here in this example the client sends a packet to the server. We're connecting on port 22, creates a random source port and then has the SYN flag set. Sends 6574 and then the server sends back 6575 as the act with a new sequence number of 7611 and the server responds with, yeah, so the sequence number that the client sends back is 6575 and the acknowledgement of that 7612. So the server sequence number plus one with an acknowledgement flag. So this is the three way handshake. So what this fun about it means is every time your computer or any computer that you're using wants to make a TCP connection to a remote system you have to have three, it's going to take at least three times the time it takes for a packet to go one way, right, because you have to have this three way handshake to set up this connection. Once you have this, cool, so we can look at this in TCP dump. So we can see these two hosts on the network. You can see actually the ARC traffic between them, which is something we looked at before. So we can see a sin flag here, sin act flag, and then the final act here. So now that we've established the connection. So now when you... And so the idea is every time you send a packet, maybe with data, maybe not, you tell the other side in the acknowledgement section the last byte offset that you saw. So starting at... So it's all going to be on offsets based on that initial sequence and acknowledgement number. So you'll say, hey, I know what you've sent up to byte 10, and by the way, I'm sending you in this packet 20 bytes. And we're going to skip the transmission window, but so here's how it works. It's fairly simple. So the idea here is... Yeah, okay, so here's a 25 byte packet, and I'm saying that... Yeah, so these... So I've sent previously 6575, I'm currently sending you 25 bytes, and the last I saw of your data was 7612. So when the server gets this packet, they can send back an acknowledgement packet with let's say 30 bytes. So the server will send back 30 bytes and say, okay, I acknowledge, I've seen 6575, I've seen up to those extra bytes. And my sequence number is 7612. So that this way, once I can tell if any data was dropped, because let's say the sequence number here was something greater than 7612, let's say it was, I don't know, 7700 or something. Maybe I sent a lot of data and that data got lost. This is my way of saying, no, no, I sent you up to this, and the other side replies and says, no, no, I've only seen up to 7612. So they'll know to actually resend that data if that data gets dropped. But in the normal case, that doesn't happen. And let's say the client doesn't have any data to send, but the client still has to acknowledge to the server that he got that data, otherwise the server won't know that the client received it. Because the IDs, you always have to sync communications so you know that the other side actually saw the data that he sent. So what's going to happen here? So the client will send a zero length, so no data packet to say, hey, I acknowledge I've seen up till 7642. 30 bytes? The 30 bytes came from the TCP data that the server wanted to send to the client. Okay, so it's just an energy. Yeah, so it can send up to zero to whatever the size of the TCP packet is. So if the server doesn't have the actual data, does that mean it's sufficient for a time now if it has to send these apps at least? Yes, exactly. So if the server doesn't have any data to send, it should reply back with a zero byte acknowledgement packet, just like the client did in this case. And yeah, there are mechanisms where the either side will time out, it'll resend the data packet, and then there's a whole mechanism of how it determines when to time out and then at some point that's the same, okay, this connection's dead, like maybe that machine just got unplugged or turned off, right? But in the general case, kind of this is what happens, yeah? I was just thinking like, if you think it creates more sense to just maintain a synchronizing data and not on both the sites, because the server don't need to... It's a full duplex connection. So both sides send data, right? So you think about HTTP, the client makes an HTTP request and then gets a response back. Other protocols are more back and forth, so they're sending both forward and backward. So with a global sequence number, you have to somehow establish and communicate which bytes are which. But neither party knows in advance who's going to talk and who's going to send bytes. So the way to think about how this works, right, is you wrote your program in C, the web server in C. So when you tell the operating system, hey, I want to send these bytes to the client on this socket, right? So when you did the listen system call, right, that's listening for any new incoming connections. And then when you get it and you want to send anything out on that socket, you tell the operating system, hey, send this. But the operating system has to ensure that the other side knows exactly what data that you sent. Just like the server that's connecting to you, because you were actually writing a server, I guess you were writing a server to the client. They are doing similar things. They're making a system call to their operating system. So the operating system has, okay, the program, the user-staged program wants to send all this data, right? And I've sent this much. And so I know that the other side has acknowledged up to here. So that way this data could be lost. I can't get rid of it. This other data I can get rid of. I know that's been sent. And so it has to keep track of all these things to know when it should resend it. Because sometimes packets get lost, sometimes anything happens. But it knows that all this data got sent. And that's why I believe these send... I mean, I don't know if this is 100% right, but I believe this, was it the send system call? Returns how many bytes it actually sent. And that's part of that. So you should actually, as a user-based program, retry sending until you've actually sent it all. So this doesn't necessarily ensure in-order operation or just in terms of... It does in the sense that the sequence number says essentially this is like byte 6575 and the length and this many offsets. So that's what specifies it in the string. So if they come out of order, the operating system would put that data there. And then it may put it there. It may throw it away. But it would acknowledge up until all of the continuous bytes that it sends. So even if it did some chunk, it would say, oh, I've only seen up until here, though. That's what it would acknowledge back. And then they would end up resending that and missing data. And then they'd put that there and say, oh, great, now I've seen up to here. There's some more hands. Anything else? Okay. Do these sequence numbers simply keep increasing? Yes. So that's it. You can think of it as a... That's what I'm looking for. So it won't overflow at some point, but it's fine. It just wraps around. So that can become a point of expectation by trying to over-flow a certain limit. I didn't think about it some more. I don't think that's ever practically a problem because it's a 32 bit number. So you need to send a lot of bytes to cause that to happen. Yeah. The server looks like they're going to know that the gamut of data they want to send is completely missing. Where is the end point for the data? Say it again. So we have a sequence, right? It shows the number of the bytes already transmitted. Yes. We don't know where is the end point of the data. This is a stream-based communication. So there is no end necessarily. The two sides can keep containing information. So how is the server going to know when it needs to respond to the end request? That's at the application level to the side. So that's why, for instance, for the HTTP web server, right? So how does the client know, or how does the server... How do I leave it for? How does the client know when the HTTP headers end and the body begins, right? It knows because there's an empty... Yeah, CRLF, right? So it's all application-specific. And for HTTP, how does it know what length the body is? Well, the content length header specifies the length of the body. So that's in a higher-level protocol. Yeah. Sorry, just a second. But you know that anything you actually read was actually sent by that other side. And so as part of the protocol... So this is why you have to... These protocols are usually based on parsing something. So HTTP, you read a header until a CRLF. Those type of things, yeah. Yeah, even before the freeway handshake, if you're already IP or half-to-grid, then you're basically acting as a server here, right? Is that it again? Even here, you never know if you're talking to a server or not, right? We'll talk about that in a second. I want to get into what it is first, so that we're all very clear on that. Then we can talk about that. Great. So we can look at kind of an example conversation here. The P, the push flag, I honestly don't know this. It gets set, and it means like, hey, there's stuff here, so push this up to user space. I believe as soon as possible. I think that's what that means. I don't actually know if it's respected by all operating systems, or when they actually do respect that. I think that would be interesting. And you can kind of see here one side sending data to the other. And then so this is kind of the... There's three phases to the life cycle here. You either have never spoke... I mean, you don't have a current connection, so you're going to make a connection, TZP connection. You do a three-way handshake, send, send, act, act. You're exchanging data, or you want to stop talking. You want to essentially hang up. And so shutdown is pretty easy. So you just send a... One side can send a packet to the other by sending a packet with a thin live set, FIA. And then the other side would acknowledge with an act flag, and then that means that A will no longer send. So you can actually remember it's a two-way communication. So when one side wants to end and says, hey, I'm not going to send any more data, then it will end, and they won't send any more data. And then when B sends a thin packet, the whole thing shutdown, the whole thing is closed. And so this is pretty simple. One side says, hey, I want to stop talking. The other side says, great, I acknowledge that you want to stop talking. And by the way, here's 30 bytes, and then maybe now I'm finally done. Here's my thin packet. I think it's technically a lie that it's not going to send... I guess it's not going to send any more data, but it does send another packet to acknowledge that I'm sending anything from the other side. And then it shut down. So this is actually pretty simple. All right, so now we want to play fun games, right? Now we want to go into, so these are the basics of how TCP works. What we want to think about is how it does... So just like UDP, we want to be able to scan ports. So how can we do a TCP port scan? So we want to determine the list of TCP services. That's right. So if you're on a unit machine, slash EDC, slash services, if you look at that file, it has the mappings from port name to service name, which is useful to use. So what would be an easy way to do this? Send the C flag, the other thing will send the C plus act flag, then reset the connection. Well, that's not the simplest. So the simplest would be... So I guess we can go over connect. But the idea would be just called connect. Try to create a three-way handshake to every single port on the server that you're interested in. So the idea here is if the handshake succeeds, then you know that there exists a service available on that port. The great thing here is when you're running this, you don't need to be rude. Any application can do a three-way handshake because that's what the operating system provides. The disadvantage is it's very noisy, right? You're sending out, for every port you're trying to connect to, you're actually making a three-way handshake. And the other thing to think about is on the other side, right? So there's a user space program, right? The web server or whatever that's actually listening on that port. And so for the operating system, as soon as you complete the three-way handshake, that's what it tells your user space program, hey, you've got a new connection. So that server may start logging things about what IKEA addresses, connections coming from, and all of these things. So this is also what we mean by noisy. Not only noisy by the network, but noisy in the sense that the user space program is knowing what we're doing. And so we can see an example of this. It's very easy to do with NMAP. And you can do while this is a very open server. So another way to do it, and all is thinking about, remember, all we want is that one bit of information of is there something listening on that port, right? So what was your idea that you had? Send a sync flag. The other end will send sync plus acknowledgement. Then you know it's up and running and you can close the connection. Exactly. So we can, it's also called syn scanning or half open scanning. So the idea is we leave the connections half open. Then we're complete the three-way handshake. So we send a sync packet to every single port. We see if the service is not running on that port, then what should happen? Yeah, it'll ignore it. We'll not get a sync back. But if there is an application listening on that port on the remote system, we get a sync packet back. And then we can either send a reset. So it depends on, reset RST is another one of these flags. It is basically one side or the other. So you've got to think of like TCPIP is this whole, sorry, I'm talking about TCP. So TCP is this whole state machine about how things have to go. And then if somebody sends you something you're not expecting, you go, hey, what the heck are you talking about? Like reset this connection. You clearly don't know what you're doing. And so sometimes, so if you send a sync packet to something that is not listening, you may get a reset packet, or you may get nothing. It kind of just depends completely on what the TCPIP is stacked in the operating system of the computer that you're talking to does. And then the attacker can either just leave that syn act, like never reply to that syn act, and then eventually the operating system will time that out, or it can send a reset back to the server to tell it to reset that. So the idea is the nice thing here is, so now how many packets are you sending? Yeah, you just send one packet per port that you're interested in, right? Rather than before you have to use two packets, well, one packet for all the ports you're interested in, and then for the ones that were open you send another syn act back, or an act packet back. And the other nice thing is you're not only using less packets, but the application never knows that this, because this connection never finished and never was established, right? So the application can never send data here. So you can run this, and usually so with all these types of things you have to then now have raw access to a socket to be able to create raw packets because you're trying to send a syn, like it doesn't make sense for the operating system to give you the abstraction to send just a syn packet, right? Because the operating system, you as a user space application you should just say, hey, establish a connection to this IP address on this port, right? And it handles all of that. But if you want to play games like this you need to have essentially root level access to a socket or to the network to be able to create these packets. So you can easily do this and you can see that it will send a bunch of syn packets, it will get reset packets back, it will get one syn app packet back on port 80, and then it will send a reset packet onto that port 80, so that connection is never established. I really like this. I like talking about these kind of things. It seems like a very simple, you know, you just scan for things that are open, but there's all kinds of subtleties because really all you're trying to get is this one bit of information of is there something running on this port. And so you can get this through other types or interesting types of side channels. That's totally okay too. So TZB Fin scanning, so the idea is, yes, please. So when you don't make the complete connection it doesn't make it to the application level or something, and why can't it get locked? It usually doesn't get locked, yes. Like by default. Because the application itself, so you think of like the web server doesn't know there's an incoming connection because there is not an incoming connection. But the operating system you could think of could lock this kind of stuff, but usually not, yeah. So I don't know, it's like something weird with a network, but if you were writing an intrusion detection system and you wanted to look for this stuff you very well could. It's not impossible. What's the what? The use of recent pagans when something really messes up. It's your way to tell somebody to go away. So let's say, because you need some way to tell the other side or when you receive it to know hey I should stop talking to this person. Let's say somehow, I don't know, somebody just started sending you acknowledgement packets like you were already established in a communication. Like you need some way to tell them to stop doing that because maybe they got their IP address, I don't know, but something weird happened and they think they're communicating with you and sending you data, but you want them to stop. You would send them a reset packet and then that would tell their side like oh something's really weird here, let's kill this connection. Or if you ever get somehow desynced like where you think you're in the SINAC through a handshake and they think they're in the actual data communication you would tell them like hey go away let's just start from the beginning. So that's why you need something there to kind of establish that. So what I really like about this so there's all types of ways interesting, clever ways to get that one bit of information of is this service open or not, or is there an application listening here. So fin scanning is one of these interesting things where it's, so what happens if you just send a fin packet on a port that you've never talked to before. So you don't have the connection established with them, you just send a fin packet to a port. No other fields are sent. Yeah, no other fields, so it's like you're jumping to the part of the communication where you want to terminate the connection. So sequence number zero Let's say a random sequence number, a random acknowledgement number. Do you see such an error reply? An error reply? Yeah, I mean so what's interesting is there's actually a difference depending on if an application is listening or not. So if the port is closed the operating system sends a reset packet but if the port is open then the fin packet is ignored and there's a timeout which is super interesting. So this is like looking through and reading the source code of the TCPIP SAC in an operating system or doing black box testing to try to figure out deviations in operating system behavior. Then you can actually infer which case is it. And the interesting thing about this is that in Windows the reset packet is always sent. So this idea of essentially you can think about it as the TCPIP SACs are essentially implementations of a protocol. So you all tried to implement an RSE protocol with the web servers. It's not easy always to do that to do it 100% to send. And you even saw a lot of you that normal web browsers are actually much more lenient than the specification. And yet we're checking pretty strictly to the specification. So all it takes is and sometimes specifications are ambiguous. They don't actually say exactly what should happen in every situation. I don't think the spec says if somebody sends you a fin packet on a port and you've never talked to them before or what should you do. Because there's kind of an infinite number of possibilities of what should you do. Another interesting type of scanning technique is what they call it the Christmas tree of the Christmas scan where you set both the fin, the push, the urgent flag you set like every single flag and for whatever reason the operating system does something different if a port's open or closed. A null scan is no flag set at all. So it happens if you get a packet with a null no flag set. So if that implementation changes and the response changes depending on if an application is listening on that port then you can extract that information. So you can do fin scanning which is pretty interesting. So it's basically a similar type of thing. But in all of these cases could we ever spoof our IP address in all these port scanning cases? We need the response, right? We want the responses to come back to us. Absolutely. And so this is kind of bad because we're telling the other side what IP address we're scanning them from, right? So if they are looking for crazy packets that are getting sent or weird TZP behavior then maybe they might discover our IP address. So there's some other clever techniques of ways you can actually port scan a computer one machine using another's machine. So we're going to get one way of doing this. If you spoof an IP address but you have rooted all the traffic to you, it doesn't really matter when you have it. Correct. But for the normal case the only way to do that is to be on the network of the computer you're spoofing from or to be on the victim's network. So the key idea here behind idle scanning is we're going to basically set up another computer to scan for us. And we're going to use kind of a side channel here that's going to tell us some interesting information. So what was that? No. Even cooler. So the first idea is we're going to find some victim host that's going to actually perform the scan for us. As we'll see this victim host, there'll be some necessary credentials here is ideally going to be a low traffic victim. And we're going to send packets to this victim as if they're coming from the remote host. So we have our the problem is the names. So we have our relay who is going to be a machine that does not send a lot of traffic and we're going to essentially get them to scan another machine for us. So we're going to send a packet to the relay from so we need to send a packet from the attacker and we're going to get basically basic idea. Does that make any sense? Yeah, that makes sense. It's because we skipped fragmentation and so we didn't really talk about the IP, the datagram ID of the IP. Okay. So the idea is we are going to use the side channels. A lot of operating systems will use the datagram so the IP layer will identify our field that's essentially auto incrementing based on the number of packets that it sends. That's an IP header? Yes, that's an IP header. Yeah, that's what I was super confused on. I thought it was IP. IP sequence number that's the idea is we first want to get from the victim or from the relay we want to get back what's the current IP datagram IP. So we'll get back it'll be something we will then send a connection to the victim so send a SIN packet from R so from the from the relay to the victim on let's say port 80. So two possibilities here, right? So if our victim is listening on that port then what happens? Yeah, if it's listening then it's SIN act back to the victim back to our relay from the victim and then what's the relay going to do here? Send a reset and be like stop talking to me I didn't talk to you. So then we can actually then after that because we've chosen a relay that doesn't have a lot of traffic or almost zero traffic we can then get the IP diagram number and see how many packets the system had sent and if it sent one packet then we know that the victim sent that packet sorry I went the wrong direction whereas in the other case if we send a packet to a port that is closed or let's say port 80 is closed on the victim the victim will then set a reset packet back to the relay which the relay will then ignore and not respond to and now then we test it and we determine that the that the datagram number only increased by one because the one we just saw instead of by two so we're essentially using that the fact that the datagram IDs increment based on the number of packets that are sent in order to use that in my channel to say did the victim send the packet back to my SIN or my SIN Act flag and the super cool part is when you look at the victim the problem is that the victim like from the victim's perspective the victim doesn't know our IP address at all because we've only sent them packets from the relay so now we get to use that behavior there's all kinds of cool I mean this is just one example of this there's a lot of different ways you can use one machine to do things like this on your behalf so for instance if you ever I mean it kind of depends but a lot of applications there'll be some kind of web application where you can put in a link and it will go fetch that link you can put in different IP addresses like even internal to that machine you can put in different IP addresses and then change the port number on the link and the software will usually give you a different error message depending on whether the port was closed or the host was not found so you can use this to scan for hosts in their network and then to port scan those machines to figure out what we're running internally you can do the same thing with FTP because when you do data transfers over FTP you tell the server what to connect to and so to give you a different error message whether the port is open or closed you can use an FTP server to port scan another system so this type of idea comes up in a lot of different places of basically leveraging the fact that you can get one system to port scan another system for you yes can you say that again why was datagramID useful? was what? so the datagramID is used as essentially a side channel to figure out how many packets has the relay sent so you know when I send this packet here if the port is open the relay will have sent a packet if the port is closed the relay will have not sent a packet therefore I can use that as long as I can get that datagramID I can use that as a test to see is the port on the victim open or not so there's other things we want to do so yes you don't have to have any direct control you can use a relay that has almost zero traffic or you have to do several of these tests and do some statistical tests to see if the port is likely open or closed so you need to do some testing because as far as the problem is you don't know if it's running on the relay if it's sending packets or getting packets that's going to change things but you don't need any direct control so we're still back in our situation we now know we're given an IP address or an IP address range we can figure out what hosts are inside the IP address range for each of those hosts we can scan both their UDP and TCP ports to see what services they're running but one thing that also might be interesting is what kind of operating system are they running is it a Linux machine is it a Windows machine would you be interested to learn if it's a Windows XP machine versus a Windows 10 server whatever Windows 10 server it is that would be very useful to know especially if you're talking about here's an entire network versus machines they have a hundred machines up do you want to spend your time trying to break into the Windows 10 machines or do you want to spend your time on the Windows XP machines you would definitely want to start there or on like even on Linux you want to look for older versions and the really cool thing is that you can do this 100% remotely so this is the concept of operating system fingerprinting so this goes back to that idea that I mentioned earlier where every operating system has its own distinct TCP IP stack and so how it's going to react to different packets compared to other not only operating systems operating systems generally but different versions of different operating systems can tell you what version that operating system is so you can see what happens when somebody sends you a thin packet and you keep talking to it or I mean all kinds of stuff what happens if you use undefined flags in the TCP header does the so there's people who've created this like cases of like you think you're like a decision tree like if I send this thing then it's this class of things and then from there other tests will subdivide that until I know what operating system it is you know any kind of weird are there any biases in how the sequence numbers are selected what about the initial we've been talking about TCP Windows size but there could be some side channels there or when does it use ICMP error messages we already saw that when Windows differs from most UNIX implementations where Windows by default will not respond with an ICMP port close message for UDP what's the error rate all kinds of stuff and the other super cool thing is this going to be done completely passively so there's tools that just by analyzing the traffic that's going on so not actually sending any packets can determine what are the likely operating systems of those hosts there's also a NMAP has a I think it's the dash probably capital O or something I don't know if you check the map page but NMAP has an option to try to determine what operating system the host is running we haven't seen it with a grain of salt especially now we have like iPhones and Android devices sometimes get weird responses but oftentimes they'll we got so close we're going to finish this out next time how do we know what the OS is just by the packet you can tell based on some of these passives so you can't tell by the responses but you can tell based on you may not always be able to check and say like hey I'm 60% certain it's window because the way it's responding is truly TZP because that's a chance to pass on the packet