 All right, good afternoon, everyone. Come on in at 6. Let's get started. Sorry. I don't know. Sorry about that. There's a truck trying to turn a little bit over here. I think so. We were there at 5. Quite humorous and delay this slightly. OK. So we are the best. OK. We are getting started right where we left off on Wednesday. So we were just, we've covered essentially all the networking up until TCP. So we did IP, we did Ethernet, IP, UDP, and now TCP. So it's actually some interesting stuff in here that will hopefully clarify some things. Some people have questions in office hours today about what happened or why when I sent data over a TCP connection, how come I didn't see that in the packets that we're getting sent with my reflector? And so this will help answer some of those questions. So at a very high level, we talked about TCP. So what is TCP guaranteed for us? Reliability. Reliability. What's that? Integrity. Integrity. It's going to go in the order? In order. So our packets will be delivered in the order that we sent. What's the other big difference from UDP? Oh, connection, yeah. So we have a connection and stream oriented, right? So we can just send data. We don't have to think about just sending individual packets. We're sending a bunch of data. So the idea is to recap. I think this is right where we left off. So we have a surfer is listening on a specific port, right? And just like in any kind of networking, in order to connect to that service, you need to know what is the IP address of that machine and what is the port of that machine. And then you can connect to it. So then the client initiates a connection. So to do that, the client sends a SIN packet with a random initial sequence number, SC. Then when the surfer gets that, if the server is listening, it answers with a SIN ACT packet, which has the server's random sequence number, SS, and SC plus one as the acknowledgement number of this packet. Remember, this is a way for the server to say, yes, I hear you. This is the next packet I am expecting from you. Finally, if everything goes good and the client wants to set everything up, the client sends a packet back with the ACT flight set, the acknowledgement number of the server's sequence number plus one, and with their sequence number of SC plus one. So now we've actually established a three-way handshake between these two nodes. So what do we, at this point now, data can flow. So the question is, well, what do we choose as an initial sequence number? Yeah. Why? Why do we want to choose a random one? Well, let's think about this. So the standard group ECB says that we should increment a sequence number every four microseconds. And other systems have done other things. So we'll look at this and we'll kind of just leave this here. And think about, OK, well, why does it matter so much what this initial sequence number is? And we'll see how this thing play out in practice. So this is the famous TCP through a handshake. There's another thing to learn deep inside of your bones so that if you ever get asked this by somebody, you know exactly what they're talking about with a TCP handshake. So first, the client sends a packet to the server. So the destination port sends the TCP headers of this packet. So the destination port is port 22 with port 22. SSH. So this looks like the start of an SSH connection. So the server is trying to SSH into the client. What's this number? ID? The source port. So this is the source port. Why is the source port important? Yeah, the server has to reply. We need IP address and port number. So this tells the server how to reply back. So essentially the client determines a random port on their machine that is free and not being used by anyone. And so they say, OK, I'm going to use this port to get the reply from the server. So I'm sending the port 22. The reply port is 1397. I've chosen a random sequence number of whatever 6574 and the send flag is set. So the send flag is 1. So the server gets this. What does it want to do? So it's going to reply. What is it going to do? What's the destination port of that packet? 1397. 1397 is going to be the destination. The source is going to be what? 22. 22. Exactly. What's the acknowledgement number? 1. 6575. So it will be the sequence number sent from the client incremented by 1. And the sequence number that the server sends will be some random number. And the send flag will be set and the act flag will be set. So send, send, act. So we have the sequence number 7611. Yeah, we're good. And then the client responds with source port 1397 destination port 22, sequence number of 6575 and act of 7612 with the act flag set. So now once the server receives this packet, now both sides know that they can send information to each other and everything will go fine. Questions on the clear-way handshake? So if we look at this and we TCP note this conversation and sniff all the packets that are getting sent, the first thing we have is an ARC request. What's an ARC request? I feel like you know it a lot better now, or maybe you know it a week. So .20, which was the client, let's say, says, hey, who has .10? It replies, hey, who has .20, tell .10, hey, .20 is at this ethernet address. And then we can see a, now this is a slightly different SSH connection from 1026 to 22. And here you have the SIN, so the SIN flag is set. It has a random sequence number here of 10, 15, 0, 4, 3. We get a reply back with the SIN flag also set and the ACK flag set. So the ACK is this number incremented by 1. The SIN is some random sequence number. And then finally the client responds and acknowledges. So this dot means there is no SIN flag set. So the acknowledgment flag is set with this one, 4, 0, 5. 6, 5, 7, 7, 9, 4, 4. So now that we've established this connection, now we actually want to send the data. And remember this is, so this is a little bit tricky, right? Because we have to, unlike beauty TV, we need to send packets without thinking, right? Here we actually need to make sure we're sending packets in the right order, or that when a packet has been lost, we transmit it, and the other side can ask us for packets. So we need to look at how exactly this happens. So the idea is every time one side receives data from the other, they send an acknowledgment back to the other side with the next sequence number that they're expecting, right? So when a packet comes in, it's going to have a sequence number. The packet carries whatever, 20 bytes, 100 bytes, some amount of bytes. And then the side will respond with an act packet that says the sequence number plus the size of the packet, which is, let's say, 101. So it'll say, that's the next byte I'm expecting. So, transmission window. So this is how it acknowledges when it's being sent. So it just sends an empty packet with no bytes as an acknowledgment packet. The other thing I have to point out is how much data is in the size of these packets. These are TCP packets. These are the headers. What about the body of the data of the packet? Nothing. Doesn't make sense to send anything, right? We have to name a satellite so we can properly talk to each other. So why send any data, right? So that's another thing. These packets are sending no data, but they are sending basically a TCP line, or a TCP header. Okay. So we can look at what happens with some kind of data exchange here. So we can have the client send to the server. So this is an act packet that says, hey, continuing off of where we were. This is sequence 6575 and acknowledgment. I'm expecting 7612. That's where I'm expecting it from. And oh, and if I'm sending 25 bytes, that means what should the server acknowledge? It means 6575, which is 6601. It means acknowledge the next byte. So we got those 25 bytes, and we're expecting the next byte. So it shouldn't... Okay. The sequence number here is 7612. Is this right? Yeah. Okay. It's only sequence number increased by the number of turning to the bytes. Okay. Yeah. So it turned into 25, so we say, okay, yes. And then we're sending 30 bytes. So when they reply back, it'll be 30 bytes above 7612, right? So that would be 7642 with another act. And then finally, we'll have to acknowledge that packet being sent. So this is important because data can be sent while also acknowledging packets. And we also don't have to send these bytes when we acknowledge packets. We're going to send an act back to acknowledge the traffic. Looking at this in TCP, I'm not going to go through this, but you can see... So I remember we said, what's the P flag for? It's a push. It says, hey, this is data for the application. Right? So you say, we have some pushes, we're sending data to the application, and then we have an act here for 1015047. That says, hey, I've read up until there. We push some more data. We acknowledge more things. And you step through this, you should be able to follow the exact sequence of our acknowledgments. So that's that exchange, right? And so the idea is, because both sides are acknowledging how much data they've seen, they now know, okay, if one side can tell if the other side has dropped a packet, because let's say they've sent a thousand bytes and the acknowledgments are only for the first, let's say, 100 bytes and after a certain time the other side will retransmit the rest of those bytes to try to make it to the other side. So in that way you can guarantee that both sides know exactly how many bytes, not only they've sent, but how many bytes the other side has received and actually gotten. Right? And that's how you get reliability here. So you have to add in a lot of extra features on top of it here. Shutdowns. And now we want to stop talking. We've initiated a connection. We want to stop talking. Either side remembers the two-way conversations of all sides can send data. So either side can decide to terminate its side by sending a packet with the thin flag set. So this is thin and don't send any packets. The other packet, except for one more, the other side acknowledges that packet and says, yeah, okay, I got it. I'm not going to talk to you anymore. And from that point on A will not send big data to B. It will, but it can still accept data, right? So it's a two-way street. And then when B shuts down each street by sending a thin packet and everything's done. So this is pretty simple. One side says, hey, I won't stop talking. The other side says great, I acknowledge that. And by the way, here's some data that I'm going to send to you. And the other side will acknowledge that. Oh, and then this side can then say, okay, I'm going to send you a thin packet. So now we're actually stopped. Communication done, TCD connection closed. And then this will side by way of acknowledge that. And after this point, after this point, if the client makes a new connection to a server, that would be a brand new TCD connection. Questions on shutdown? How would the diagram change if the server closes a connection unexpectedly? In what way? Like, maybe someone went in there and said, shut down or restart. So a couple different things. So A, if the server just goes down, the client will keep trying to send packets and say, hey, where are you? It'll realize that it's not getting any acknowledgments for anything that it's sending. And so it will time out at a certain point and just say, okay, this connection is dead. The other thing that can happen is, let's say, the application that was running and talking just gets killed without any cleanup. At that point, I believe there's a reset flag, an RST flag, which the client would send a packet to the server and the server would say, there's nobody here to listen to this. It would send a reset packet which says, hey, something went horribly wrong, which is what happened. So you have to restart this connection. So the client would probably try to initiate the connection and then the server would not send a SINAC back because there's no server listening there. It kind of depends exactly on the mode of failure of what happens. But yeah, they will stop talking. Eventually, they'll stop talking. Any other questions? Yeah? Here, after this one. So you send one fin and then one acknowledgement. Or you send a fin, the other side will acknowledge that. And then they'll send a fin. You'll acknowledge that and that's it. There's the S. When you go through the DNS, like the QDP, what we're trying to find, where the server is located, that all happens before this, right? Yes, you can get the IP address as a number. So these are just the PCP headers of the packet, right? But enclosing that is IP headers. And enclosing that are internet frames for each step of the hop. So yes, to get even the IP address of the server that you want to talk to, you have to do a DNS query to resolve that domain name to an IP address before you even start the disconnection. So that's why your DNS server has to be an IP address. It can't be a DNS address because you've never finished resolving, right? And you can look at this. I actually highly recommend you do this. Hopefully, are you doing this for your project? For part two, very handy to use WireChart on both machines, your attacker machine and the machine you're running to reflect it off. But even it's just fun to pull it open and see kind of what's going on in the traffic. Okay, so just like UDP, right? So with UDP, we had a way to maybe try to tell which servers, which ports were open on a given machine, right? So we have an IP address. We want to know what network services are running there because maybe we can attempt to try to explain that, right? We want to know, is this machine, is it running SSH? Is it running a printing service? Maybe it's a printer. Is it running any kind of other services that could be interesting? And so how can we try to determine UDP ports being open? Yeah, so you send a package to all the port numbers and what were you hoping for back? Yes, the ICMP port not available error. So with TCP, we actually have a lot of different ways to try to port stand. For UDP, it's kind of the only one way. For TCP, we can do a couple of different things. And we really want to do this in order to determine which TCP services are running on that host, right? Remember, as attackers, the more information we have, the better. So if we can know exactly what services are running on that machine, that'll be really good for us. So, like we said for UDP, the services that are running on each port are statically, usually statically determined, although that's not always 100% of the case. You can check out the file ETC services on any UDX distribution. It will tell you all the things there. So the basic TCP port scanning is super easy. You just take that IP address, you try, it's called connect scanning. So you just try to do a handshake to every single port on that server. And if you get what, what are you successful? Yeah, so if you complete that three-way handshake, you know you're good and you can talk to that server, right? So you just try to open a TCP connection of all the ports on the victim host. And this is really, well, one of the ways that why this is really good. So hey, so if you know that a handshake was successful, then you, that port is open. So what are the benefits here? You can send malicious data, not just pass it to the server. But we don't want to send anything malicious yet. We just want to see who's there. It doesn't really look malicious if you're just sending a couple of renowned things. It's just a connection. So if, well, if you spread it out enough, then yeah, maybe it's not that noticeable because you're actually trying a real connection, right? You're not sending any weird packets there. You're just trying to connect like a normal person. The fact that you're trying to connect to port one is maybe a little. How does your browser connect to websites? HTTP using what? TCP. TCP, right? You're doing part three. Do you run your browsers as root or as an administrator? No, so essentially they're doing this connect, right? So do you have to be root to run a connect? Oh, you can be any user, right? You're just making a normal connection to the server. So one of the main benefits here is you don't need to be root. So if you don't spread this out over time, what would be some of the downsides of that? Network traffic. Yeah, how many? It's like two. Times two or three, depending. Yeah, that's a lot of traffic, right? We may be sending a ton of traffic to this machine, so we're not being very stealthy. So the way to be stealthy, you either send less or you spread out the amount you're sending over time, right? Those are kind of the main techniques. So connect scan is super easy. You can use NMAP to do this. This is running a group that you don't need to. This is actually another good way to test a reflector. If you try using NMAP to scan the victim IP, it should have the exact same results as if you scan the attacker's IP. Although the tricky thing there is if you're running it from, if you're trying to scan the same machine, some ports may be open and listening only for local hosts. So they would be accessible from the victim's machine but not from this reflector. Anyways, this should still work. It's kind of the important thing. You should see the relevant stuff. So here, this machine has a lot of different ports open. FTP, SSH, the Echo service, which I'm going to be running more. Login shell, it's running an X11 server, which is not very, probably not very safe. And you can run this, and it runs actually pretty quickly. So, maybe another way that we can try port scanning without doing the SIN-SINAC act. What do we need from our technique? Let's think a little bit of meta. What do we need from a port scanning technique? What's our goal? A multiple services running on a specific port. Find out if a port is, there's a service running on that port, right? We don't ever know that actually this service is running yet. Maybe more digging, but we just want to know if the service is running on this port. Just thinking about high level, right? So that's what we want to know. So what must our technique be able to do? What was that? Get a replacement. I can't see who's talking. Get a replacement. Yeah, so we want to, well, maybe get a reply or maybe not, right? So in the case of UDP, we wanted an ICMP message, but we need a way for what we send, we get a response back if it's open or not, right? And that's what we want to know. So what would be some ways maybe that we could do that based on what we've seen so far? Use UDP, ICMP, and see which is open and then do TCP on the ones that are open. Hmm, that's what you're saying. So scan UDP, usually they won't be on the same ports. So you'd have to scan it all again anyway. But it could give you a good starting point. Maybe, I don't know, DNS has a mode where you can run it in TCP or UDP, although it's also all UDP. I don't know if it's the same port. I assume that attention is already open. See what they say. So yeah, you could maybe just try to, so thinking about the different protocols, right, and thinking about, okay, what happens if I do something weird, right? Does the other side change its behavior based on whether that port is open or not? Yeah, that's actually, I think, similar to one technique. We'll look at it. So the three-way handshake requires us to send how many packets. The trick question requires us to send how many packets? Two. Two, right, and we get one back. Do we need to send all three, do we need to send all two? Yeah, just send the first one. See if we get a SIN act back and then don't reply. Don't keep that connection open. So it's called SIN scanning, or it's also half-open scanning. So it's a very simple idea. We send a SIN packet. If the ports open, the server will send what back? And SIN act, if it's not open, it will usually send a reset packet. Usually, not always. So instead of sending the final act, we can send while we either do nothing or we can send a reset packet. There's various, so if we send a reset packet, we're actually getting a lot of network stealthiness. But, so when we do a full three-way handshake connection to a port, who finds out about that? So who's handling the handshake? The client's what? The client's operating system is handling this handshake. Then when it finishes that handshake, then what happens? Who gets notified? The application that's listening. You're writing a web server in C. You call listen on a socket and you get notified whenever a new connection happens. And that is after the three-way handshake. So the one downside of doing just connect scanning is the applications know that somebody tried to connect to them. So the benefit here is we never made that three-way handshake. So the connection is never open and fully open and this is usually not logged by the operating system or the application itself. So there's no record on that system that we ever made these connections. Is that if you send the RST or if you don't send the RST? I think both ways. Sending the RST would definitely say something went wrong and they'll both stop sending stuff. Not sending anything at some point, it will time out and it will not. Although that also looks like another attack that we'll talk about later, a DOS attack. So we may not want to do that. Could you add any security measures to the kernel to log? Yes, you definitely could. But it requires changing things and adding things. So you do that and then I find out about it and so I'll come up with a different way that you're not logging or not scanning or I'll use one of these other techniques. Just to clarify, the reset packet, that won't cause the server to somehow start trying to do the handshake itself. No, no, no. Reset means the protocol messed up or something weird happened. So it's like the client's responsibility to try and do a handshake again. Yes, if the client wanted to talk again you would have to redo that, exactly. And that would be, I think, either way. Otherwise you can do a lot of weird stuff if you can force the server to make connections. Cool, so you can use this. There's another option in AdMath. Remember we're teaching about build tools, not use them. So using them is fun to learn how they work. So you pass this option. This has to be done as root. Why? Just like you're doing in Scapi, you have to have physical access to send out arbitrary packets. By doing that you're essentially bypassing the kernel's TCP stack and saying I want to do this on my own and send out my own packets. So you run this here and it will say on this machine that port 80 was open. And if you look at the TCP you'll see a bunch of SIN packets to port 78, 78, 78, I don't know why it's 78 twice, but maybe it does that. 81, 82, 80, 79 and we will get a reset packet from port 78. So that's from the server, right? So saying hey, there's nobody on this port. On port 81 we'll also get that until we get to port 80 where we get a SIN act packet back. But at this point we then will reply with our phone reset packet to say don't actually fully establish this packet. There's other things so just like we said earlier what if we send different things? So what if we just send a FIN packet to a certain port if we've never talked to that port or know how to connect and establish? So just send it with a FIN mark packet. So again this depends on differences in the actual implementation. And fairly certain there's nothing in the specification that says if you get a FIN packet do this and you're not receiving anything and so it's up to the implementations of the site and how they actually implement these things. So in most of these if the port's closed you get a reset packet from the kernel. If the port's open then the FIN packet is completely ignored. And so by using this behavior from the outside you can make a much stealthier scan of the system. Because how many packets are you sending out for each port? One. Just one. And you're in this case you're going to reset back for all the ports that are not open. So what's the downside of using a technique like this? There's no difference between a port and a port that's not being used at all. A port that's not being used at all? What's that? If they don't send the RST packet back. Yes, so one thing could be maybe they're dropping these reset packets. Maybe there's a firewall in the way that's dropping it which would make every packet look open. So if you can get a response back and you can see two different responses then you'll know for certain which way it is. Getting a packet back is kind of not an easy signal to go off of. If you keep getting tagged out you want to seem like you're trying to do a deep data scan. Like if all the ports are open and then you keep getting tagged off because they're all open and then it makes it seem like you're actually trying to deny sales. But it's a timeout on our side basically. So the scanner the port scanner is going to send fin packets and for each packet it sends and says okay wait two seconds or whatever the tools can figure it out. If I don't get a response by then then I assume it's open. The problem is that assuming anything could have happened. Maybe the packet just got dropped on the floor. Different kernels could have different responses to the packet. Is this the behavior of every single kernel? Maybe it's different on the iPhone because it's on a Linux system. And that actually is part of the problem. So on Windows a reset packet is always sent back. No matter if it's open or not. And so if you try to use this on a machine that you don't know the operating system of you may get inconsistent results. But you may know the operating system. How many know? Operating system fingerprinting or whatever? So I talked about NMAP has a way of operating system fingerprinting. You can do that. You may just know. So if you look in HTTP headers that are being sent back oftentimes they'll say what operating system is running. So they'll say the exact PHP version sometimes and operating system that's running. So you can use that information in ways like this to improve your attack. Or you may just know there are certain companies that all their servers run Windows and so you may know through another way. So you can do all kinds of weird there's all kinds of techniques there's what they call the Christmas tree scanning which is you turn on like all the flags so you turn on fin push urgent and that causes different behaviors and responses to be honest I don't know exactly what the various responses but it's a similar idea right that's more responsive based on what's open or not. Similarly to the Christmas tree there's like all the lights on on the packet the opposite of that would be what? All the lights off. Turn all the flags to null. No flags set. So that's an old packet. So you can do all of these again with Wiresharp. So Wiresharp will do all of these. So you can do fin scanning of the system and you can look at it and it just sends a bunch of fin packets and we get back for 79, 82, 81, 78 but we do not get a fin packet back for 80 which means that that port is open on this machine. So what are the problems with all of these techniques or port scanning techniques in general? In consistency is part of it. You're actively sending packets on the network? We are actively sending packets on the network with what source IP? Can we spoof the source IP? Yeah if we spoof the source IP we won't get the packets back to us. Fundamentally. So this is an important thing to think about if in TCP or any kind of thing on IP as we talked about if we ever want to get a response back we have to send it with our source IP address. So the key problem is if the defenders are watching their network they'll see port scans coming from us from our IP address. Could you just combine that with sniffing and send fake source IPs and then listen for who's sending stuff back to that? So who could you what IPs could you spoof in that case? Could you spoof an arbitrary IP address? Yeah, so you can only spoof somebody who's on your subnet and to do that you would have to maybe implement ARP if you're doing. But the downside there is they'd still know what autonomous system you're coming from IP address wouldn't still have all that information about your subnet in it as well and especially on networks like this where we have most people are behind NATs. So our IP address we have inside here in ASU is an internal IP address. You can't access that IP address from outside. So in that case you're not really gaining much except maybe pretending to be somebody else on the network. But yes, you could do that but how much that gets you that's part of it. You can't just choose an any arbitrary address. So there's an incredibly cool technique that we're going to look at that actually allows us to use a third-party machine to port scan another our victim that we want to get, which is really cool. Could you use the DNS service? Could you maybe use the DNS service? To do what? Port scan? Well, maybe. I don't know. We'll see. So this is called idle scanning because you need this cohort server that you're going to actually trick to scan needs to not have a lot of traffic and we'll see why. The idea is that we're going to find some relay or that we're, sorry, we're going to relay our scan through a victim. So we're going to try to port scan one machine and relay our traffic through this victim and they're going to scan on behalf of us but we'll still be able to see the results of that scan. So the idea is, so what do we have to do if we want to send back it? At a high level, if we want it to not come from our source IP, what do we need? Yeah, so we need brute access to the physical device. What do we need to have the source IPV? Something on our system or on the victim's? We'll see in a second. Yeah. Yeah, so we need, so essentially it can't be our IP, that's the whole point, right? It can't be our IP address. We need to be somebody else's IP address. And so that's, you know, at a high level, we want to spoof our IP address, that's what we're going to have to do. So what we're going to do is we will send out a packet on the network to the target. So this is the machine that we are trying to scan. We're going to send out a packet to the target with the source IP of the victim. So you're the target, you get this packet. So what happens then? Yeah, so assuming it's a SIM packet, right? We didn't specify exactly what kind of packet. So it depends, right? So depending on what type of scanning if we send a SIM packet it will send a SIM packet, SINAC packet back to the victim. If we send a a FIM packet or a reset packet, like we saw then depending on the operating system it may send a reset packet back to the victim or it may not, right? Depending. The target gets this, it looks like it comes from the victim so the target will then reply to the victim. So if the target replied with a SINAC as we just said so we send a SIN packet if the target replies with a SINAC which means it's an open port then the victim will send out a reset packet. What happens if the port is closed? What will the attacker send? What will the victim send? The target. Sorry, there's three machines here I know I've changed the terminology, I'm confused too. So the target, we're targeting trying to scan this machine. So we send a SIN packet to a port there with the source IP of the victim. The port is not open, what does it send? A reset, so let's go with reset. So it sends a reset packet back to the victim and what does the victim do whenever he sees a reset packet? Ignores it, right? Just drops it, doesn't do anything with it. So here we have two different behaviors right? So in one case, if the port is open then we know that the victim sent out a packet. If the port is closed then we know that the victim did not send out a packet and it turns out with just that one bit of information that's enough for us to understand and do a port scan here. So the idea is the attacker before we do this we're first going to try to probe the victim which is where we're saying all these source IPs come from and we try to say what was the IP diagram ID of that packet that we first got. Then we do this then we try to ping it again and see what's the IP diagram ID. In most OSes there's a potentially increasing number. So we know that if this doesn't get incremented then the port is closed if it does get incremented then the port is open. So basically it boils down to it's going to baseline to try to find out the initial IP sequence number. So in our relay we have our victim, we have our attacker right? We first send out a packet to the relay that says hey whatever it doesn't matter what type of packet we send as long as we get a response back. We get a response back that will have an ID in the IP field which will be whatever 11, 1, 2, 3, 4. Then in the next step we want to now do our port scan so now we send our spoofed packet to the target from the victim's IP and the key thing is remember we can always do this on the network but we can't always get the reply so I'll do a reset packet to port 80 or no no a SIN packet so I got the wrong thing so port 80 is open they'll send the SIN back to the relay the relay says what are you doing I'm not talking to you go away it will send a reset packet back the key is here this ID is 1235 this packet I just sent and so we send another packet to the relay saying whatever we get a reset packet back with 1236 so now we know that that packet was open that that one sent it out so why is this called an idle scanning packet because you're hoping that the relay doesn't have any traffic that's in chromium any other traffic to this relay or the victim oh it's called relay if there's any other traffic to this relay it's going to mess up our count right and we're not going to get the right count is that okay in the back and we've got to think about the other case so that's the case that the port is open and if the port is closed we'll send a SIN packet we'll get a reset packet the relay won't send anything back and we'll get 1135 to see that it didn't get incremented and so this would tell us that that port is closed so we can do this for every single port on the system right and so all the packets that the victim sees who do they come from the relayer it's pretty cool right this actually works yeah how often would the system be idle though it seems like everyone's always sending connections everyone's always sending connections so another way to think about it is you know you don't if it's completely silent then you can always do this on a percent right but if let's say you can identify you can choose on any server that looks right there's web servers that look like that so you figure out one then even if there's a little bit of traffic in the background if you do this enough times you can kind of average out the results right so you can use statistics to kind of alleviate the noise and there's some things where and you have clear indicators if the ID increased by more than two then you know something happened and you should retest so it should be increased to either one or two anything more is garbage you should ignore so maybe you could use those as part of statistics if the background noise was consistent so you can send if there's some background noise you can just send a bunch of synth packets a bunch of greater numbers to the victim just so then you'll see that the relays number is going to increase greatly versus only increase the number that would be a good way to do it send them a bunch you'd have to change each packet and have to have different source ports but that shouldn't be a problem send a thousand packets and see if the number and you could also pull do this connection to the relay to see how this IPID changes over time so you could get an idea of the baseline and then do this so maybe you could do this with even more non-idle servers that would be interesting but if you're sending a thousand packets just to check one port is open that would be a little much even if the relay is active does any server keep sending reset packets often unless there's abnormal traffic into will it be sending relay to a reset packet? no it will only send a reset packet it responds to something it wasn't expecting so it can come down oh but no it's any packet so this is the IP header so any packet that gets sent it's part of the fragmentation IP packets have the IP datagram ID so that's the one so any packets that gets sent will alter this value yes what if the relay keeps track of packets that it's not sending anything but it's sending a response for the server what if it's keeping track of sending a packet with the unless they're doing anything special which if you're choosing a non-important server they're probably not going to be right so yeah if you're looking at the traffic anybody on the relays network would be like what the heck is going on why are we getting all these packets from this victim and so yeah that would be super weird but most people don't look like how often have you looked inside your network at home to see what weird traffic is making sense like never and unfortunately the exact companies and organizations would be better but often times they are not yes, different so the main purpose of this is to you're trying to get all the suspicion over but you're trying to find weak spots in the relay or rather trying to get information about which ports are open in the relay on the victim you're trying to figure out which ports are open on the victim the packet to the victim spoofed as if it's coming from the relay so this way from the victim's perspective all the packets they see coming in are from the relay and all the packets they send out are from the relay so literally they have no idea of what IP address you actually are which is pretty cool the public network does not have any relay or compromise the idea if you're using a public network of a public network so if you're using a public network like a public hotspot or something yeah, you're so hypothetically speaking if you want to cover your tracks like that you know the if it's like think about what they could be doing so they could be the public wireless network you're on including logs of what Ethernet address is at using the network and what IP address it has and so then when the public Wi-Fi gets upset because the victim goes, hey your port scanning us they could actually look at that time frame find that IP address that was making those requests and figure it out that way again that would only give you Ethernet address right and so yeah you'd have to have other information and track it back to you but can you change or spoof your MAC address you should all nod your head you're doing that for your project too but you also got to be worried whenever you're connected to a computer how much information when you're connecting to a network how much information you're leaking it could be leaking like folders or anything you'll be advertising your computer's name which may not be a random name it's probably something you gave it all that kind of stuff even I think Dropbox has this land sharing feature so Dropbox is probably sending out packets to see who else is on there a lot of stuff they can send out idle scanning okay so just like we talked about I guess I went a little bit early so I actually saw some of these port scanning techniques are based on the fact that operating systems deal with packets that are unexpected in different ways based on the port is open or closed OS fingerprinting is the idea that different TCPIP implementations will deal with unexpected packets in different ways and it's actually kind of a crazy idea when you think about it right we're just two computers connected to the network and yet by sending you special packets and seeing how you respond I can know exactly what operating system you're on it's pretty cool so some of the things like what happens when they send a thin TCP packet what happens if you have special flags that you put or that you set the bits on the undefined flags in some TCPIP stacks those are reflected back at you for whatever weird reason programming weirdness weird combinations of flags like a push and a spin and a reset and a thin Christmas tree attack sometimes the selection of the initial sequence numbers can actually tell you what operating system it is if it's somehow predictable the selection of the TCP window size says only send me at most this much data I can't handle more than this so different operating systems have different defaults for that when does it send ICMP messages does it send is there I think we saw earlier with UDP scanning that on windows it'll send a maximum of 5 ICMP port not found messages in a second or something like that so you have to make sure you're not scanning faster than that so that would be a way to tell if you're scanning a windows machine versus a Linux machine because you can send out a bunch of these packets and if they're only replying a certain amount in a certain time limit you can attack that when they reply with an ICMP message sometimes they'll include part of that packet that was invalid in their response so how much do they send what TCP options do they do do they include certain flags that are optional or not include certain flags so it was very cool and the crazy thing about this it seems kind of it's I like to think of this kind of like languages right it's like they're all speaking the language of TCP, IP, UDP but they all have different dialects right so by probing their dialects you can try to figure out who exactly is speaking and the really interesting thing about this so it kind of makes sense like if I send you packets I can figure out but there's also passive ways of doing this so there's a program called POF which will passively listen to the network traffic that's being sent and you can actually try to infer what operating systems the hosts are running there's also an active way of doing this in NMAP so you can use NMAP to actively scan machines which is pretty cool it's fun to do you can like play with these things and try to figure out what kind of devices are running what else would be cool would be to use TCP for a wire shark and look at the packets that NMAP is sending when it does these scans that would also be really interesting okay we'll talk about handshakes we'll talk about the sending data now we can talk about so we talked about port scanning so now we'll talk about our favorite networking topic and attack we'll talk about every level which is what spoofing spoof packets so as a TCP layer we want to be able to do what and we want to basically create a TCP connection with another system while changing the source IP and make it think like it came from a different server so we want to establish impersonate another host and it was first described this is kind of a looking back at some of the history we talked about RTM, the guy who wrote the Morris Worm wrote kind of on a separate thing not a way into the Morris Worm to talk about how to do this and that you could impersonate and do TCP spoofing and it would be kind of mythic in the facts against the SCSC so let's look at it so what are we trying to do we're trying to exploit trust in the system so the idea is the server we're trying to attack doesn't trust me but it trusts some other host so I want to make a connection to the server and it came from that host so node A trusts node B but we're node C and we want to impersonate node B when we make a connection to node A so how are we going to do this what makes this, is this easy we've done this with UDV we've filled this with every level is it easy? why or why not yes it comes down to the 3-way handshake the 3-way handshake is really what makes TCP incredibly difficult to spoof can we spoof the source IP of the initial SIN packet yeah but then what happens to that SIN act it goes to whoever we spoofed right so but then there's two things here one that server may respond with a reset so that may kill our connection and what is this server expecting back the correctly implemented server side sequence number in an act packet right so we have SIN act it's expecting that act packet back so the core problem the crux of what TCP spoofing comes down to is that we don't see that SIN act packet so we have to either guess what that sequence number was or somehow get that packet the same network as all these systems the same local network yeah we can sniff everything we talked about all kinds of ways that we can sniff traffic so there has to become more of an easy easy fairly easy what do we have to worry about though we always have to worry about these the person responding faster than we do what was that yeah what if that other person responds faster than us so one way we can deal with that is we need to somehow kill that machine in whatever way hypothetically we need to flood in with traffic crash it turn it off we just want to make sure that machine doesn't respond we don't have to do this but well we need that reset packet to not be sent that's the key problem here to somehow do this then we send a ttd send segment so we spoof the IP address of the trusted host A replies to the SINAC packet but it ignores the packet because it's either dead or it's too busy so if we're on the same network we know how to do this we know that we can we can see that packet we can sniff that packet on our local network if we want to hub it's trivial we can do some art poisoning but if we can't right then because we do not need that response back so if we can't we need to send an act back with the server side sequence number plus one so we either need to see that packet we either need to get that packet or we need to somehow guess the correct sequence number so this is why this sequence number is the crux of security for ttd so if you just used an incrementing sequence number right that's trivially guessable right and I don't need to get lucky once I don't need to send one packet with that correct sequence number in that acknowledgement so this is how it would look so we are C we are the attacker we will do some kind of denial of service attack take out this trusted host B then we'll send to A a packet spoofing the source IP of B to that with our own sequence number here excuse me with our own sequence number A will respond to B with the sequence number and this is the one we are trying to guess and then finally we have to respond with this 54003 right and that can tell us what it is so this is why as we said this is why we are talking about choosing the right sequence number so just incrementing the sequence number every couple of microseconds is not enough yes it will still send to B it will still send to B it will send well it depends on what it is sending so if you think about SSH which is how we give a remotely controlled server what are we sending to the server after we've logged in and what do we get back the output but I don't need the output I'll just add my IP as a trusted host to your system and then I'll stop doing all this and then I'll engage into it normally and then add myself as just a user we can log in and I'll log in as that user and then I'll probe that system see if there's any way I can have to lay my privileges out so it depends on exactly what but yeah fundamentally you will never get a reply from that server back you can still always send data to the server right but you won't know what it is sending and you may have to do some weird bits could you just sniff to get the data that they were sending if you can sniff it if you guessed it then you're not on the network been here what if they were flying you don't know the technology the knowledge remember to send back to them but they just not send it to college yeah you wouldn't have to send any acknowledgement because they would just think that all of the packets they sent you got lost but they would think that all the packets that were coming in were fine they're getting packets from you but they can't send any back to you you can always send out packets and start randomly incrementing that sequence number yeah yeah I definitely heard you up to like 5.20 or good and then it would send you a little bit more but yeah yeah up to 100 we're definitely good just keep doing whatever I'm telling you but it all depends on the specific but yeah so the fundamentals are you will not receive those across how do you know that you guessed properly you got it that's a good question how would you know so hopefully you can get it where you only need one packet and send it like your exploit packet which would add you to the system and then you can test that afterwards but yeah you need some way to test right because how would you know if that once you send a successful packet they'll be fine with it right you send SIN, SINAC, AC and now you can both send each other data if they send you data or something it's going to be and you're never getting it so this is why it comes down to choosing the right sequence number so there's an RFC that defines ways to improve sequence number generation and says hey we should really you know use something better here unfortunately a lot of implementations didn't do that and there was a great paper an early paper called Strangetractors in TCPIP sequence number analysis where this person graphed the sequence numbers that they were receiving from various OSs so you can see things like this this is like Windows 2000 XP kind of has this AZ cloud I'd say it's like decent you know decently random especially when you compare it to something like Windows 95 or 98 and the other thing is right you get a lot of guesses because you only need one packet that gets that correct and you have a lot of requests back to try these kinds of things Linux was pretty good you can see it's spread out FreeBSD and you know the history of FreeBSD so FreeBSD is the distro that like does that open in BSD? what does the security want? FreeBSD right? yes FreeBSD is there are all things about security so they do code reviews all the time with the code and the kernel and they're constantly removing stuff that they don't like it's very interesting I think I tried to experiment with it once but I couldn't like get stuff running but a lot of actually network gain equipment is usually based off of the BSD family of operating systems I think part of that has to do with the license so BSD is anyone can use it even commercially whereas Linux with a GNU license you can have it open as much as you can so that's why this is so Cisco and you know the name of Cisco's operating system on my switches iOS with a capital I so they have incredibly simple and easy to guess sequence numbers and think about your switch having this is incredibly bad because why? because someone couldn't personate your switch well the switch would be easy to make and usually on a switch you have maybe like a trusted IP who could access the management interface of your switch now if you have an easily guessable sequence number somebody could easily try to guess that and understand that but they eventually fix it and now you're like very distributed Mac OSX was pretty good and he had what's the X and Y here? it's the delta between the packets so it kind of it's actually three dimensional it's like X, Y and Z I can't remember all the differences but the more spread out it is the more difference there is between different sequence numbers so they just tried a bunch on this got a bunch of sequence numbers and plotted the differences there and so HP's system is a lot of easily recognizable but unfortunately they claim they fix it and they do not do a really great job let's see this one's probably going to work I don't know if you guys see those dots there's like big dots on the screen so yeah this is not a good sequence so spoofing spoofing is we want to come from a new source another type of attack that I don't think we've talked about yet is we may want to hijack a TCP connection so in this sense hijacking instead of starting a new connection or a new conversation I want to inject data into an already established TCP string if I'm looking at this I'll see if I can do this I like continuing to where Devin's going to take too long so we'll stop here we're actually almost at the end of our game and then we go on to how about three questions for two minutes assign it to one question another one so hold everyone else up