 I could get everything set up because a lot of questions on a lot of questions on assignment to the reflector. So I wanted to talk about that. Let's see if it works. Another reflector. Man. There we go. Got it. I think it's going to be really bad drawing, but. Fairly good. Okay. So here's our switch. Right? We have the network. All supports. Okay. So we have. These are cords. I don't know if you know what that says. This is D. We'll call it the attacker. We'll call it A. So this is the attacker. Right? You have our computer. We'll call it B. It doesn't matter what it is. B is running the reflector. So this is where your program is running, right? So reflector is running. Where's the victim computer or the reflector computer? They don't exist. They're not real. They're not plugged into anything. Right? But in a program, you have a victim IP and a reflector IP. Now, I'm slightly confusing. I can bring it out and that's all. The program is called reflector. You have reflector IP and reflector IP. They also have ethernet addresses. So when an attacker wants to send a packet to the victim IP, what's the first thing it has to do? Yeah. It has to say, okay, who has this ethernet address? It's going to send an ethernet request. So how does it know that there exists an IP on that network? An ARP reply. An ARP reply. Right? All it's looking for is an ARP reply. So it sends a packet out. The ARP request can go to every single device that's on the local network. It's going to be a sent to this network where your reflector will be this thing and it will say, oh, this is an ARP request for the victim IP. Right? I should reply to that so they can go out and talk to me. Right? So from the attacker's perspective, all they know is that, okay, great. They're on a piece on the victim ethernet. Right? Does the attacker know that it's on the same port as this V? No. The attacker has no way of knowing, right? The switch is dealing with all of that. On the outside, you don't see any of that. So then the attacker sends, we looked at ICMP echo request messages. So it sends an ICMP echo request message to the victim. What happens next? Can I just see a request to the attacker? Yes. So the victim, your program gets that. See that it's for the victim IP. It takes the body of that message, changes it so that it's from the reflector to the attacker and sends that out. And then what happens? Yeah, the attacker says, oh, somebody's trying to ping me. The reflector IP. Great. I should respond to them. What does that have to do first? Probably has to do an ARP request, right? So it's going to do an ARP request for the reflector IP. It'll be a response back from your program. Right? And then it's going to send its ICMP echo reply back to where? The reflector. The reflector, which is going to go where? Back to the attacker. Back to being into your machine where your program is listening, when it sees this packet, what should it do? Send it back to the attacker as if it came from the victim. So in essence, this is the reply to that first packet that it sent. So where does ping actually come from? Or the echo ICMP reply come from? The attacker, right? So the attacker is getting back whatever the reflector sends to it. So in this way, anything that the attacker sends to the victim will actually be sent to themselves, and the results will be sent back to them. So we want to keep these two IPs separate so we have different victims and attackers. A, because they look really weird if the victim is just, like, every time you send a packet, they just send it back right back. And also when you reply, how would you know that it's a reply and not a new packet that you should respond to? Right? So that's why you need to separate this reflection from the representation. Questions on that? We start playing around with it, and we're having some trouble with the layers. So we can do a normal send to the victim. And it receives it and we'll send, we'll go to send something back, but our reflector, like when our reflector reflects that, it's requiring that we send a sent piece or a letter to, instead of a send, a normal send. Could you figure that out? It stands up and you've got to figure it out. It's also not a great document, but, you know, you got it. There we go. What's that? Can the map that is for both victim maybe and reflector maybe the same? What do you think? Probably it could be. Yeah, I don't see any reason why they cannot and don't have to be, but you don't have to worry about that. Just take the parameters and use them, right? Don't try to do anything to them. Just a general question, like a computer receives a packet, would it be standard for it to just cache the address in the IP parent so that it doesn't have to make an ARC request at a future date? I don't know. The question is, if a computer receives the packet, for instance, when a reflector just sends a packet to the attacker, does that, will the attacker always have to make an ARC request? I don't know. Is it also going to hash it? Because the IP could be a non-local IP, right? So it doesn't need to store that, but maybe it does keep track. That would be interesting. Doesn't that mean you could also bring in the protocol? The protocol you should ask if you don't know, right? Just assume that you know based on packets that you get. Yeah. So here we are simulating the reflector, but in actual case, we use reflector. So first case, any packet to victim machine? How does reflector know that the attacker has already sent a packet to the victim machine? Well, reflector has a machine. How many machines are there here? There are only two. Two. reflector has to be on the victim machine. Well, no virtual machines. There's only two machines here. A and B. I think it is virtual machine. It's virtual and confusing term, because it's virtual machines, right? There is no physical machine that is connected to the network that has the IP of the victim and either has the victim. You are essentially telling, how does any, so if any of these computers want to talk to you about a local network, how do they know that the other one exists? They send an ARP request and if they get an ARP reply back, they assume that that IP address exists. There's nothing. So that's all of your leveraging here. Because the attacker doesn't know you're just on this port, right? Remember what we said, the switch is keeping track of MAC addresses it sees on this port. So as soon as it sees an ARP reply of, oh, this MAC address is on this port, it'll keep that mapping there. It'll make sure that packet that gets sent with that ethernet address of the victim or the reflector gets sent to the meeting. So I'm a little confused, we're sending it, we're being the attacker, we're sending packets and then we're trying to listen. You're not meeting the attacker. You're writing this program. So we don't make anything that sends packets to try to attack and like sniff on the network. So you're just reflecting. So we don't have to do the attacker part of anything. Correct. You don't need to do that to test, right? That's all set. But we can both test it. But it's not part of your program. So we have to build it if we want to test our program. Build it. You can just try hanging. You can try art. You should TCP dump everything to see exactly what's happening. You need two computers or a virtual machine. Yes. I did it with two computers. That was kind of an easy way. I'm sure you knew a virtual machine, but I just need the exact... I don't know yet the exact configuration about to do this. But yes. It should be possible. Does our network in our case have to be able to do this? Do you have any trouble with the packets from the other back addresses? Yes. You're interfacing with each other so you get all the packets. But the scampi does that for you. As long as you're out of this room sitting out over here on that. You may have heard this. As I said, my client was not free. So it wasn't... For whatever reason, I didn't debug you very much. So my wireless on this wasn't sending out, I think, correctly. I couldn't debug it more than I just plugged in directly and it worked out. In that case, we might find the 5.0 or the... Yeah. So I have to change the interface and then send it out. That's why that's part of the argument. Attacker, we should be in the same network. Yes. We need to be on the same subnet. The attacker could be Windows, though, right? Yeah. You could be anything about it. It doesn't work on Windows. This is a network might be something special. Yes. You said... You said run it on Windows 1404. Does that matter? Wait. So when you're developing a yes, it needs to run on Windows 1404. If it doesn't run, it's the same as if you try to develop it on Windows. But I'm not saying it's... I can't guarantee it's going to be the same rate. That's why I can't say yes. If you want to make your own risk, you can develop on there if I have it. It does not work. Okay. On the no attack, which was what? Put in an ARP request, and you get, like, replies. And then you send those replies directly to the one that you want to do this outcome. Yes. So, except for ARP replies. So you're sending out ICMD echo requests to a broadcast address which means that that goes to so that they will all respond to what you're trying to take off the internet. And this gives you leverage in order to stay on that site. So we were looking at... The reason we looked at smurf attacks is because we looked at different ICMP messages. And remember, ICMP messages are at the IP layer. So we haven't moved up at all there. IP debugging messages. So you get an destination and a reachable message to state when a gateway says, hey, sorry, I can't access the router. There's lots of subtexts of this. There's never been a reachable host or a reachable protocol or reachable fragmentation needed, but don't fragment it to the set which we saw so the gateway couldn't fragment the packet. The destination host was unknown. We don't know who we were trying to send it to you. Or even the destination network was unknown. I don't even know how to get to that network. There's a huge list of them. So there used to be... So... You used to be able to try to cut notes off from the network by spoofing these messages. So you would spoof a message that says, hey, sorry, your packets can't get out of the network. And then the computer just kind of gives up and doesn't ever reply or try for a while to access the network. So yeah, you basically spoof a destination and a reachable address and then you would basically trick the machine into thinking that it can't access that. This one's super interesting. So ICMP time exceeded. So this is one of those... So what do we look back time here? Are there any times and time stamps in the packets? Yeah, the number of pops, right? There's no time stamps. We look at the headers of every single frame from Ethernet to IP to ICMP. There's no time stamps in there. So the time exceeded here is the TTL. So the time to live value is an IP packet. And so two things, either the TTL becomes zero, in which case this timeout will be zero, or if a fragmented diagram timed out. So we missed one of the fragments and we couldn't get one of the fragments. And ICMP time exceeded message looks like this. Basically what we've been looking at. And this gives us a super interesting networking tool that is very handy that you can use. So the idea is we used to be able to, and we kind of saw this, there's options in the IP header to say, hey, use this specific route when you're routing this packet. Or there was the logging of the route. So basically say, hey, every gateway along the way put a little time stamp telling me about yourself who you are along the way and see what route my packets took. All those got removed. And so now kind of the network after your hop is essentially a black box. But that's where TraceRoute comes in. So TraceRoute is a very cool idea of how we can actually try to map the network from us to wherever our packets are going to go. And it uses these ICMP time time exceeded. So the idea is you send out a packet with an ICMP of a packet with a time to level one. So then what will happen when that gets to the gateway? The TTLB 0, it will drop it and then it will send an ICMP what were you saying? The ICMP time exceeded message back and that will tell you and that has a source IP and it will tell you who actually that came from and then you send out another packet with a TTLB too so it will go to the gateway and then it will go one more hop die. It will send you back an ICMP message. So you have to know who that is and you can keep doing that by incrementing the TTLB out of your desk. Ah, you don't. You have no guarantee. You just know that at that point well, you don't even 100% know if things could happen or rather you or sometimes as we'll get an example in a second they don't even, sometimes they'll routers won't send a response back so it will just get dropped. So yeah, the networks are constantly changing. You know, it's pretty things I would say but yeah, you know, there's no guarantee that even when you trace out from one IP to another that even when you try to go backwards it's going to be the same. So the routes may be symmetrical. Trace route, very cool series of IP diagrams and so you need to specify the destination IP that you're trying to trace a route to. You can basically try to reconstruct this route. It's super useful. Like this is actually very cool. If you don't want to know like how many hops away are you from Netflix or Google or Facebook or you know, anything this is actually a very cool way to do that. So yeah, here's another example. This one has more names. So this one has more like router names depending on how you get to do this. I believe it's trace route, right? I'll try to find it. I think somebody uses this to do a trace route into their network where it starts printing out the text of Star Wars movie in all of those names here. I can't remember how to find it. So let me find it. It's a very cool useful way of using ICMP as it is. So moving on up. So we finally finished the IP layer. Now we're going to talk about what types of packets is that IP layer actually sending. So we saw ICMP is one type but that's really kind of an IP level thing. Now we want to think about at a higher level what are applications actually trying to send. So the first and there's two protocols we're going to talk about. They have a name that we're getting once that we send TCP and UDP. UDP is what we're going to look at first because it's a little bit simpler and similarly we're going to look at this and how we're going to tax that are related here. So the IP protocol sits on top of the UDP protocol sorry sits on top of IP and tries to provide connectionless unreliable best effort diagram delivery service where you do not get no delivery, no integrity no non-duplication, no ordering and no bandwidth is guaranteed. So what all these things mean? So what does connectionless mean? What was that? No handshake. Why do you have handshake? My question. Connection, right? So you can just send a UDP packet and you want it to already have a relationship established which would another way to figure out the connection. So unreliable? We send it, do we know if the other side got it? No way, no idea if the other side got it. Best effort means that kind of the same thing. It's just going to try and it doesn't get there and it doesn't get there, sorry. And the worst part is your application doesn't know what to get there. Datagram, so that just kind of means I think that is in terms of packets. So we're sending some data in a little chunk. So we send some data in some chunk and hopefully the other side gets it maybe they get it, maybe they don't will never know. At least UDP doesn't provide that we know. So it doesn't guarantee delivery, it doesn't guarantee integrity which means that our packet could be tampered with along the way. What about non-duplication? Non-duplication. Say again? No. This packet is not reductated again. Could be, okay. So one thing to be, we don't recent admit the packet twice. Well we may not, there's no guarantee maybe we send it twice. The other way to think about that is what if the packet somehow gets duplicated in the network somewhere? There's no guarantee when it comes, so when the person receives it we send it for three packets or five packets even though we only send one packet. So that's what that means. Ordering, so we can send one packet and then half a second is kind of a long time. But then right afterwards send the second packet and there's no guarantee that it will arrive in that order on the other side. Ordering and bandwidth. So there's no guarantee about having a bandwidth for these things or anything like that. So UDP kind of sounds like that's why we say this. It's super simple. Yeah. Is this broken? I mean it shouldn't but that's the thing is UDP does not provide the guarantees against that. That's the key thing. If you, so. And so what does UDP offer on top of IP? Why create a new protocol? Why not just use IP? So when we talked about kind of delivering and routing of packets in the IP network, what do we say the IP address was like? An address, a physical address. Right? So a physical address would be I don't know, I don't know any of the dorm rooms here. I assume there's like dorm rooms on campus that have an address. So if you wanted to talk to somebody who lived in that dorm room could you just use the address? What else do you need? You can either name or, we don't want to use names, we want to use dorm numbers, right? So we wanted to say what exact room number are they in? And so that's what UDP provides on top of IP is it provides an here set of dorm numbers or apartment numbers. We're thinking about court numbers, so that's what we use. So the idea is to allow send different messages to one IP address but be addressed to different services that are listening there. And so UDP is used a lot is for reasons because it doesn't provide any guarantees. It can often be faster or less overhead. So it's used in multimedia often or voice communication because there you only care if your bag gets duplicated or transmitted twice or comes out of order or whatever. Or if you lost a baggage, you don't care about it because it won't be sending. And there's a lot of services that are based on so the big one that's based on UDP is DNS. So DNS is domain name resolution. So translating the domain names that we typed in so like a trace route or a browser into IP addresses. So different applications can have different ports that they're using, right? Okay. And two can use the same port that then it's like they could like some sort of benefit indication. No. So two can't use the same ports? Correct. So yeah, one application that's a big application because the process that's running on the server, it can open up as many ports, you know, it can try to open up as many ports as it wants. But once it's listening on one port, another application can't try to listen on that port while that program is running. So it tells the operating system, hey, I'm listening for any UDP traffic on port, I forgot to be in that port, whatever, port 1000. And the OS will say, great, any packets that come in for port 1000 are directed toward to you. And that's how it gets done. Unlike TCP and our snippers, when they're listening to the physical interface, they see all the traffic. But normal applications especially if you don't want them to run as root, don't need that privilege. And so they get this UDP port of traction. And on the flip side when we want to send out a UDP packet, you say hey, I want to send a packet to this IP address on this port, and here it might have it. And the OS will worry about sending it out. So a UDP message is composed of the source port, the destination port, what do we need so we clearly need a destination port, I need a source port. Yeah, how to send it back, right, we need we're going to send them something, we need to know who can they talk, who can they reply to to send this response back, right. Especially something like DNS, and we say hey who has the IP address google.com you want to get a reply back that says hey google.com is at this IP address. Based on this, how many ports do we have? Sixty. Yeah, two to the sixteenth, right. Anyways, yes, about 65,000, that's the power of two that's around there for source and destination. We have a message length, so a header that says hey this is the size of the UDP packet, we have a checksum, or the checksum provides some guarantees that the header was not modified, and then we have the data. So actually even simpler than IP, right, IP had more headers in it, it had all kinds of flags and fancy stuff. So IP is super simple on top of that. Just say this is the port I'm trying to talk to here's the port that I'm coming from and here's the length of the message that I sent you. So how does on the receiving node get a UDP packet, so it uses the UDP port, but how does it know who to send it back to? IP, remember we have nesting malls, right, so we're going to have the outer most layer, we have the Ethernet frame, which will occur on our local network, inside that we'll have the IP frame, or the IP header with the IP data and the first part of the IP data is this UDP header, and so by looking at all that, that's how we know who to reply to. So, let's correct me exactly what I was going to say. So we have our header inside the data part of an IP packet, right, so this is when we looked at IP headers, then a whole section of data, well, the very first part of that data will be the UDP header. So how does the OS go against this packet, know that it's UDP, so a protocol field in IP, yeah, there was a protocol field in IP that's specified and says, hey it's either an ICMP message, it's a UDP message, or it's a TZP message, and inside there remember, so for each hop, which of these changes, yes, a frame header, right, every hop, new frame headers, right, but the IP header and everything else stays the same. Cool, so UDP actually pretty simple, so if it's based on IP, what kind of a tax can we have on UDP? What was that? I don't follow, I think you're on the right track though. The link player and the actually still affected. Yeah, so what kind of a tax can we do on the IP header? We can spoof, we can try spoofing a UDP packet, as if it came from someone else, right, and because it's connectionless, all we need to do is just inject this packet with a different source IP and source form destination, destination form whatever we want. So we can actually do UDP spoofing, right, and we can do this again, either if we're on the network, the local network in which case it can become a little remotely because nothing checks that we're actually spoofing the source IP address in any package that we send. So we have a trusted client, we have a server, we have an attacker who's, let's say, somewhere in the middle, doesn't really matter, they're not necessarily in the middle of their connection. They can send a spoof UDP request to the server and the client will get a UDP reply back. So this is fundamentally what we can do. So depending on what we have in here. So there's a variant on the SMIRF attacks that I believe it was what's the networking, the network time protocol, which is what all of your servers and laptops, well at least Linux uses to synchronize time. So there's a vulnerability in there that allows an attacker with a tiny packet request to achieve I think it was like a 100x response back. And so what attackers did was they would spoof the source IP the IP they wanted to take down they would send spoof NTP requests to that domain, to these servers, they would all respond with these huge responses back to the target and eventually taking them offline. So this was a really big deal and it was really bad because the people who were running these NTP servers they're not really vulnerable right they're allowing attacks on other infrastructure and so actually the big problem in the community to clean up and fix all these servers I don't even think they're still all fixed but I think their number is much, much smaller now so that the attack is not really feasible. So yeah it's kind of interesting right because the attacker can send something and you can get a reply even though you never asked for it right cool. Now if we are in the middle right or if we can see well let's talk about this actually so the client can send a request to the server so if we can see this request what can we do yeah maybe we can respond back beforehand but why do we have to see the request what was that yes we don't know what port the client is listening on and waiting for that reply right because the client in their message chose a destination port well pick the destination port because they wanted to talk to that application on the server and the source port they usually will randomly generate from all the ports that are not being used so there you have a 2 to the 16th you have 65,000 possibilities that the attacker could try to reply on if you try to do all of that it's highly unlikely that you're going to win the race back from the server but if you capture that packet now you can reply now how can you capture this packet sniffing sniffing if you want to hug or anywhere in the middle of these hops what else man in the middle so that would be well what kind of man in the middle of that using what yes so if we we're in the same which network do we have to be in the client's network or the server's network either we can get either one as long as we see this packet we can respond so one thing we can do is if we're inside the local network and use these two machines and we're going to route all of the traffic from the client to its gateway through the attacker and then we'll be able to see all these packets and then when this UDP request comes in we can just respond quickly hopefully faster than a server can respond and so then we can get a spoofed UDP reply back and the goal is to beat that UDP reply so you do terrify based on what you just learned so what critical critical network functionality uses UDP video streaming video streaming is not critical yeah DNS right when you type in google.com into your browser do you want to go to Google's site or do you want to go to my site you want to go to Google's site and you want to be assured that you're actually in Google's site and so this is part of the reason why now we'll get into later HGVS and all that other stuff that we've built on top of basic HGV and all those things but even if this is why being on an unencrypted wireless network is very bad because people with the right equipment can see all the packets that are being sent and so if they can see all the packets that are being sent that means they can see any DNS requests that you're making and so they can send a different response Jane Winterton who's in the GSI of the old screen initiative had a great article where she likened it to using an unencrypted Wi-Fi as like going into a public bathroom with avi shoes it's something that should be gross that we think is business so public toilet with avi shoes on and yet security hygiene speaking using a public Wi-Fi is basically the same the same thing but we just don't equate that in our minds but now you know the technical reasons about why is because anybody on that network can be messing with your DNS traffic look at it, what does it say? it's about the wireless so if the wireless has a lock next to it so if you have to give a password for a wireless you're fine it's when you get signed into a network and you get no password and you're just connected to that Wi-Fi that means every single machine that's connected to that Wi-Fi can see your traffic the application asks for a request they got a reply from who it was thinking about and so it just keeps it not listening so the protocol is hey who has the IP address at Google.com and the server will say hey this IP address has Google.com so I made the request, I get my reply good, everybody's fine above the HTTP above TCP so it uses TCP which we'll talk about in a second and it does encryption on top of that so yeah that's why these things were created back when people we really didn't think about all of these problems and how networks can go bad and how you can easily sniff or spoof networks or even back in the age when things were all wired and we had switches it'd be like oh you know you could never get these packets or sniff well you can art poison you can't do that now we've moved to the days where everybody's talking to the same wireless access point with no encryption so yeah so we've had to build so it's very difficult at this point to change the raw TCP UDP and IP layers so now we're building on top of that in essence to fix and patch all of their problems yes look at all the replies you get and try to make it a qualitative determination how do you know that you're right I think the first one wins every time yeah so you have to make your application smarter and maybe that maybe the request that you get back was a duplicated packet or maybe something else went wrong there's a lot of weirdness that can happen in the network but yes it's not done the first reply wins that could be something that you're talking about an intrusion detection system somebody's whether you then essentially it's a DNS poison so they do look for these kinds of things but no applications don't so now we're the attacker if we want to find out a local network what are the IP addresses what do we do that are computers that are active on a local network we can ping them all what's that going to do you might get a reply back from them if you were trying to ping Microsoft.com it does not work but you drop all your packets isn't there like that broadcast like 255 what could we do you could send the ICMP yes but they're not worth applying the ICMP messages ICMP after every request but it doesn't drop it I don't really look for every not working getting the IP addresses on a local network and sending the ICMP request to the broadcast right but you could broadcast all of them but they can choose whether to respond or not so they can just say not applying what's the other way how do you know if an IP address exists on a network not there yet I'm talking about previous stuff not new stuff yeah ARC request you can just send out a bunch of ARC requests for every single IP on your network right for all the hundred or ten that you don't know what you can do you can just send those out and for them to be on the network they have to respond to any ARC request and so using this you can get a list of all the ARC oh that's the other thing I should write it there's a cool tool called ARC ping which is like ping but uses ARC so you can ARC ping a certain IP address which could be very handy and I'll re-sign it and you can choose to ARC ping you can try ARC ping everything to see what posts are up so that can tell us whether an IP address exists on our local network on the remote network yeah we may have to try using ICMP echo request try a ping an IP ping so now we're trying to maybe learn more about a computer right so we know it's IP address we know it exists but we want to know what servers are running on that machine why might we want to know that right so maybe there's a vulnerability in that service right the only way we can try to influence a computer or another network is to try to get it to interpret our data in the wrong way or try to crash it or do something that way but we need to be able to send data to it and so we need to know what services does this computer offer and so to do that we need a way to do what's called port scanning we have 65,000 ports how can we know which ports actually have servers listening on them so what do we do you can send a UDP request to all the ports what will that tell you use end map end map I'm teaching you how to build end map you don't know what it's actually doing so you can send UDP request to packets to every single port what's the pro and non if you get a reply back what do you know yeah you know that there's something listening on that port if you don't get a reply back what do you know something on a venture yeah no one's listening on the port or someone's using it intentionally not to listen to you that type of request yes this is the problem right there's some specific protocol so like DNS is listening the data of a DNS packet better look like a DNS request if it doesn't the DNS server is likely to just ignore it right so yes if you send a bunch of UDP packets you may be able to get a reply back but you may not know if you don't get a reply back that doesn't mean that nothing's listening there exactly so this is the problem it doesn't give us enough information you can try actually as we mentioned there's actually a lot of ICMP error messages so some systems will actually send a port unreachable message so if you try to send a UDP packet to a port that's not listening it will tell you hey there's nobody listening at your port and here you do have to do a negative confirmation right so in this if you know that it does this then if you don't receive this message then you know that something is listening on that port maybe you didn't speak the right turn of the call but at least now you know that something is listening on that port unfortunately well unfortunately depending on how you look at it from the attacker's perspective unfortunately a lot of IP sacks limit the number of error the error message rate that can be sent and so you can't just send 65,000 UDP packets at this host you have to space it out so you stay within just ready to make sure you're constantly getting error messages and so yes you can use MNAP to do this so MNAP the dash s with capital U often says do a UDP port scan it will start up it will say hey all the interesting ports on here my default I think it only scans it doesn't scan all 65,000 it will scan the lower about 1400 I think I think it has a list of ports that it thinks are interesting and that's what it chooses there are command line options for MNAP for you to choose exactly what kind of scanning it does so I'll tell you port 137 of UDP is open which usually is the net bias NS service so can you take that for a fact no you don't know right when you don't know 100% you just know that there is a certain that yes there is something listening on this port but we don't know exactly you know it could be this it could be something else so yeah it will tell us everything that's on there so how I just kind of tried to tend to your expectations with this service component but I didn't get this information like a registry of which service would choose ports yeah so part of the problem is right so if you want to talk to a DNS server that's on a specific IP address what other information do you need to know what a port right and so at some point I guess probably hopefully it was very early they realized hey if DNS is running on different ports on different servers that's going to make it a nightmare to switch between different DNS servers right you got to switch servers also know what IP address and what port of every single server that's running and so they standardized a number of services and said okay port 22 is for SSH and port whatever this is 137 for UDP is NetBIOS can somebody look up DNS it's really annoying 53 that's right so port 53 on UDP is DNS probably also a tcd2 you can run a tcd5 but I'm not going to go really anyways so that's how those are there they're reliable-ish when you see something that's on a non-standard port that's when things get weird because you don't know what to say so if we look and we capture using tcd5 this traffic right this is another really, really good thing to do and this takes you beyond the level of somebody who can run NMAT to somebody who knows exactly how it's working and what it's doing is use tcd5 to capture the traffic to see what is this tool actually doing so if we look at this we can see that from our machine from source port 41481 to 192.810 which is our target port 138 UDP size 0 tdL46 and ID so we're sending 138, 134, 137 140, 131, 132 and so we get back port 134 unreachable so it tells us when we scratch that off and out of it we get back 140 unreachable 131, 132, 135, 139 and so we use this to scratch everything that we test off until we see that the ones that we didn't get these ICMP error messages back from were were 137 and 138 questions about UDP UDP is actually pretty straightforward introduces ports has the same problems as IK but has kind of cool scanning characteristics of how we can write scans to the outside so do we have any questions on UDP since the port for standard services are constant it will be easy for an actor to use UDP yes what makes it hard is well here it's all the same for example the source port is what makes it hard and I believe after review DNS I think there's a request number even if the DNS requested itself so it says hey I want to request by the way and I requested whatever some random nonce so it's increasing the space besides just a receiving port number I believe but it's not but still if somebody listens to that packet and sees that packet they can reply back there's nothing that stops them if they can see the whole packet and this is the whole problem because you're not establishing a connection with that server you're just sending something back and waiting for a reply can you choose not to reply the port that you configured can you choose not to reply who the one who has been requested can they choose not to reply like DNS server any port so an application you can configure your server however you want so you can tell your DNS server hey only serve requests from new IP addresses so you can ignore requests from other people but when you send a request you're waiting for a reply it's unreachable yeah if it's unreachable what are you saying if you didn't send these unreachable messages you'd just be passenger yeah so that would be a way to increase the stealthiness of your system would be to disable these port unreachable methods I believe in that case since the UDP ports are known what services they are I would try sending a DNS request and seeing what I got back or try sending a net bios or whatever that one was that's what I got back so yeah it would it would make the attackers job more difficult but I don't think it doesn't make it impossible on to the main show so TCP is the king or queen because I'm pretty sure protocols don't have genders of the internet so TCP moves essentially everything pretty much everything unlike UDP it is connection oriented which means we're setting up and establishing a connection with the other IP address it's a reliable which means that there's no loss no deduplication no transition errors and as the correct ordering and it's a string delivery service what does that mean yeah so it's continuous so you send a UDP packet with some data they get your packet with data they look at it reply with a packet of data and that comes back with TCP once the TCP connection is open can I set up your series I don't want to try to do it probably you might so TCP once the TCP connection is established the application can send whatever and however much it wants it can send an A, B, C, D, E, F, G whatever longer than the size of the packet and it's TCP's responsibility to make sure that the other side receives it in exactly that same order right so the idea is you always get A before B and you always get B before C and C before D and so on and the other thing is I'll know exactly where the other side is so TCP just like UDP has a port abstraction so this is really good it allows us the same size of ports so this is key so how many people have done TCP before so the rest of you need to pay attention TCP is complicated but in order to provide all of these features these are absolutely necessary so first key concept with TCP is what makes up a circuit so how do I know I'm talking right so this connection oriented nature of TCP what defines this connection so it's source IP source port, destination IP destination port so that's what I'm trying to talk to google.com I will create a TCP packet well we'll see exactly how that works but I will talk to Google's IP so that's the source IP, destination IP Google's source port will be port 80 that's the standard HTTP port so that's defined in those standards and my source port will be just like UDP, some random port that nobody's listening on on my computer and that defines a connection now there is a connection between our two computers and we'll see how this circuit is created and how it's destroyed the circuits allow for too many communications so I can talk to the other side and the other side can talk to me and they both provide all the same reliability there so IP port are commonly called sockets and the two streams are usually called socket here but I don't know anything like that so you can think of when you're listening on a socket means you're listening on an IP address to a specific port and when you get a connection now you have a socket to that other computer so you can talk to them which should be handy for your back door cluster so if we look at a team so remember, even though two so this is where you can see they're saying at a high level our application sees TCP as send this data hey what data did I receive send this data, it doesn't have to think in terms of data grains and sizes IP is what? IP which has packets and sizes and so we need to look at how essentially TCP achieves this abstraction by looking at the headers on the TCP packet so just like UDP, source port destination port the next one is a 32 bit sequence number which is used to keep track of the conversation we'll see the exact details of how this is used and acknowledge the number which allows how the other side is able to tell us hey I've seen it all the way up until E of your message the length of the headers are reserve bytes a bunch of flags and a window so we'll get into the window in a bit check some and an urgent pointer which says this packet is really important options so there's a section for all the options any padding is added up as often so it's a 32 bit and finally the data that's being sent in this BZD packet important things source port, destination port sequence number, acknowledgement number those are kind of the core parts here and so just like UDP it always helps to think that we have these nested null situations TCP packet with the TCP header nested inside the data segment of an IP packet which is nested inside the frame of an usually an Ethernet frame okay so I think it's in the wrong order okay we'll go over it at a very high level of these different things the sequence numbers and all these fields and then we're going to look at it in detail so the sequence number identifies where in the byte string the payload of this packet should start so for instance if the sequence number is 13 423 means the payload of this packet contains the data from 13 423 to whatever the size of that okay so there's what's that I think there'll be any options each blend is a header light so there's an extra header in the options okay we'll look at that okay so the acknowledgement so the sequence says hey here's where this data should go the acknowledgement says hey I've read up to this many bytes and I'm expecting this byte from the sequences that you have sent so the acknowledgement number specifies the next byte that the other side is receiving so if I've sent you a sequence number 1000 through 1010 your acknowledgement number would be 1011 because that's the next byte you're expecting from me so if we have 16754 that means I've read all the way up to 16753 that you sent and I expect the next byte to be 16754 so these are going to be super important because these are how each side keeps track of where each other is and what they've sent so this will handle retransmission, deduplication flow control, all kinds of cool stuff so now the TCP window is used to provide flow control so part of the problem with UDP is you can just send a bunch of UDP packets at another machine and it basically has to accept those with TCP now from the applications perspective I can just send like a gig of traffic on a TCP socket the problem is what's the problem there what if I'm talking to a phone does a phone have a gig of memory to receive all that modern phones yes I don't know if you want your OS season on your gig of memory so the idea is this window allows the receiver to say hey only send me this many bytes like a hundred bytes or a thousand bytes that's the only amount of data all accept and this way we can incorporate older devices and you can talk between any kind of number of devices this is our way of saying hey we're only going to take a segment if we've seen if the sequence number is between the last act that we send you and the act number plus the window size so it's in this way of saying hey this is how many bytes I can actually receive and the receiver can actually change the window size as the conversation continues depending on their capabilities so it's kind of a cool way of like built in don't overload me kind of things and once again you know we're security people so we have to look at this and say well nobody's enforcing this like this is a request from the client that says hey don't send me anything larger than an act number plus window but it's nothing stopping the receiver from doing that except being a good member of the protocol what if you spooked the receiver and you said oh send me a ton of stuff we'll look at that we'll look at that the tzp flags so the tzp flags unlike the other ones which we kind of lost over are very important to understand so the flags we have are sin flag which requests well it's using the connection it's interesting organization which is called a sin packet we have an act flag which states that the acknowledgement number field is valid so you don't always have to send a valid acknowledgement over a field but if you have an act that tells you that it's valid we have a thin flag which says I'm not going to shut down this string I'm not going to send you any more data a reset flag which states that we need to actually we should tear down this virtual circuit and create a new one because something went horribly wrong urgent states are the urgent pointers valid and push requests like hey this is data that you want between acts of the application as soon as possible again I've seen this a lot in traffic I actually don't know I don't know if it's actually used it's kind of interesting maybe it is because when you look at all of your UTCP on the linear web traffic all the browsers are saying yeah I got to push this but I don't know how much that's actually used I don't know if you guys hear 50 or 55 I'm looking at you because you don't know what I trust I'm trusting that alright so I will briefly go over this because I have to go over it twice okay so when we want to set up a virtual circuit just like a UDP we need to know what source IP and source port right we need to talk to a certain IP address on a certain port so to do that there's some server listening so the client is always the one initiating the request right that's how we think about it client and server so this is where we get to the three way handshake so the first part of the handshake is the client sends a SIN packet with a SIN flag set and a random sequence number to the server the server so let's call it SC the server answers with a packet that has both the SIN and the ACT flag set so it goes SIN, SIN ACT and so remember the other side is the two way conversation so the other side has its own sequence number so we'll have a sequence number it will randomly generate from the server SS then as the acknowledgement number so have to prove that it got that message by original SIN yeah it should send back as an ACT but what should it put as the value of the acknowledgement number field so one thing that could be you would first think about is yeah you use the sequence number SC right because that's what you got it's actually the sequence number that the client sends plus one Y because you're expecting that next byte what else how many of you are familiar with endian this so there's little endian big endian right so it's for an 8 for a whatever 4 byte number which number is the most significant byte or the least significant byte so on different operating systems different CPUs they're different the network order is actually different than most operating systems so if you can take the number that I gave you on the network add one to it and send it back to me that means we're both speaking the same endianness on the network so it's also a built in check on the network to make sure we were both talking the same thing because if you just took that value and just put it right back to me there's no telling me that you actually interpreted that number I said then finally the client then finishes the handshake and says yes I got you I'm going to send you an act with a sequence number of SC plus 1 and acknowledge the number of SS plus 1 so does this anything backwards now we have a full handshake so what I want you to think about is what does this give you that UDP does not give you especially in regards to some of the spoofing vulnerabilities that we talked about and I did that being vulnerabilities so think about that we're going to go back and we're going to review this