 Alright folks, get started. Nobody did the extra credit. I'm really disappointed. How do you do it? Half more. I can't. We're still within the time frame. Are we? So when will it be allowed to tell us? Next Tuesday? How about that? Maybe Thursday. How about it? It's late. I'll hit this. I mean technically that wasn't it. Half more. No. I said, next Tuesday I'll talk about the hit and tell you what it was. Okay, other things real quickly? So some of you, there's still, I know many people have talked to me about the scholarship for service stuff. The deadline was technically last week. If you get your application in quickly, we can review it quickly. So do it, yes. As quickly as in like the next week? Yeah, like do it. As soon as possible. Yes. Admitting it, I would say, from the ASU side. Yeah, so, you know, we want, you guys are, most of you are prime right at the right level. Because if we can get you right now, we can get like starting. Because the key is to be able to go to the career fair in D.C. in January. So if we can't get you processed by then, you can't go to the career fair. And you can't get an internship for the summer. So it's all about securing that pipeline. So there's definitely still time. Please do it. As soon as possible. Any questions on that? I was going to say, like the letters of recommendation from the faculty. Is that like an important thing that we need to have included? Or can we kind of like, I would submit your application as soon as possible and you can get in any supplemental material that you need that's still coming in as it comes in. Right, so just get in your application and then you can get those things in. No, many. We have four million dollars to give away. So it won't be a lifetime of this grant. Actually, I don't know that that's all your mark for scholarships. I'm sure a decent amount is also pays for your travel and all that stuff and the stipend and everything else involved in there. So yes, we have a number of, it's not going to be just one thing. It'll be as many as we can. Keeping in mind that we have to do this over time, we have to figure out what people, if you're trying to do a four plus one, that's also, you know, we have to think about that in terms of budgeting and making sure that this is the first year of our new grant. So there's a lot of scholarships available, let's say. All right, do it. Make me proud. All right, assignment five is also a way you can make me proud. You like that transition? Okay, cool. So do the 26. This is a combo piece. So the first piece is going to be, the first part is on policy. So you're going to be, I will give, I'll post on Piazza today, a policy on mobile asset management. So the situation is you're the CISO of this organization. Your underling or your direct report, that's probably a better way to say that in terms of underling. Your direct report will, has given you a draft of some management policy for how to manage mobile assets. You're going to write a critique of the draft, identifying what aspects the policy does not cover, what aspects it should cover, and specifically why. You should also include in there justification for why you're focusing on these things and why you feel that there's no more and that the policy is complete. So if you feel there's one big glaring thing that is missing, you add that, justify why that makes a complete policy, you're done. If you have, if you see three or four things, you should justify all of those and explain why that then makes a comprehensive policy. Does that make sense? Fair and reasonable, and we will evaluate it. So just text. So imagine you're writing an email, no text, plain text, email, text file, .txt, text, text, text, ask you text. There's no weird bytes, no crazy bytes, no weird stuff. I've seen no crazy quotes, curvy quote marks, no pictures, diagrams. I guess you can make an ASCII art if you want, but just writing. This is a writing assignment. You'll find, this is actually one of the things I learned at Microsoft is that I spent a good, I don't know, 30 or 40% of my time writing and communicating like emails and meetings that is not coding. There's coding and fixing bugs, but you also need to communicate with people and work together. So that's kind of why this is important. Questions? Yeah. This is kind of stupid, but do you have a preference for how many columns it's going to be plain text file? No, that's a good, I'd say 80 is a good, it's a fine one, but I'm not super strict on that. That's the only answer. Is this our last assignment? No, you'll have one more assignment. Also there's a second part. So the second part is a network security part, so you will design a, so we talked about some of the data bridges and we talked about kind of, in essence when you've exploited a system you need to then somehow get data back out of that system. And so the way you can do that here is you are going to implement a program that will send a message and will encode the message secretly into the IP datagrams that you're sending. So specifically we are going to use the ID field, the identification field to, cool. So every byte of the message will be sent in the IP layer of a packet. So you'll send one packet per byte of the message that you want to send. That's right. It'll be encoded in the high 8 bits, so the uppermost 8 bits of the ID field of the datagram. And the lower 8 bits of the ID field will remain constant to me as part of this message. So you'll choose some random value that will be the ID for that message. And then there'll be another, ah yes, so we'll encode the byte number into the fragment offsets. This will say which byte it is that you're sending. And when there's no more bytes to send the highest bit of the fragment offsets to be set to one and the lower 8 bits of the fragment offsets to be set to the length of the message the total byte sent. So if you follow this protocol implement a command line interface just like you've been doing and just like all the other assignments, you can write this in any language that you want. So basically you'll be able to walk through these examples here of these packets that are getting sent. So this is sending the message test. And so it's encoding the T would be hack 74. The lower bits of this ID field is 41 and this is byte number zero. Bite number one, byte number two, byte number three. And finally the last one to say that there's no more is this message. And then we know the other side knows that they've received all the message you're trying to send and everything is good. So all you're writing for this is the client. Like I said, like all assignments you can write this in any language you want. I highly recommend using Python with this staffee library. You'll find because you have to manipulate these packets and create these packets where you're messing with the ID field which normally the operating system will handle for you. So you can technically do it in whatever language you want. So you can use libnet is another way but it's a highly recommend using staffee. It makes it much more difficult for us to debug and help you if you use something else. You can do it. I have faith in all of your abilities in any program of language you want. 1804, that's the same. I'll also provide you with a server implementation. I'll also provide you with a server implementation so you can test your client. So this way you can have a Python server program running on your machine so you can test that the message is getting there correctly. I think that'll be a lot easier and help everything. Some of the things makefile, readme, secret senders, the name of the executable. I think we've hit all these roadblocks earlier in the semester. So this should be pretty easy. Do you have any questions? So you said we can do it in any language but you recommend Python? Yes. That is definitely the gist of what I said. It's definitely possible to do it in C. I thought it in C. It's just a pain. Or is the SCAPI implementation it's not a ton of lines of code. Yes. Because the library is very good. Can we expect assignment 6 to be released on the 27th? That's a fair... Yes. And it'll be due... So the next assignment will be basically a server or a hacking assignment. There'll be a series of different challenges. You have to exploit a certain number for 100%. There'll be more than that number. And you'll have up until like basically like the last day. So it'll even go after finals. So as soon as you can get it done, that's good. So it'll be available to you up until the final for this class or the last day of the final. I think it's like that 8 because that's what I have planned. Yeah. What kind of exploits will that number take? You will... It'll be all stuff we talked about in class. Okay. Yeah. Is there extra credit? Like if you do more? I don't know yet. TVD. Any other thing on this assignment? So basically we're creating a quiet program? Yes. That will exfiltrate data that you send through the IV field of a header. So basically you can think of it as you're given this protocol of how data transfer should work with these different aspects of this inside here. And you have to implement a program that does that. I'll give you a server program that will be accepting these and we'll print out the message as it receives it. So that should help you a lot in terms of testing. And then just like before that we automated test cases we'll set the submission limit to 20. The start, please don't use them all. I don't know why, I use them every time, but yes. So are we currently taking the computer networks class? Wait, did that help us? I don't know. You tell me afterwards. I guess it depends on what you're doing there. Cool. All right. Good. Did that. Scholarship. Move over to Simon. Cool. Let's rock and roll. All right. So speaking of networking we've been talking about networking and we've been talking about the different layers. So we've been discussing basically so far the physical layer, link layer, IP layer and now we're going to finally get up to the transport layer so we can understand what's happening at that level. And so, yeah, the packets you'll need to send I believe are ICMP packets or UDP packets with the IP layer messed with. So the easiest one to start with is UDP. So UDP stands for User Datagram Protocol. The basic idea is UDP provides nothing on top of IP, which means what? What does IP provide or not provide in terms of guarantees? Yeah. I have no guarantee that any packets are having to order. No guarantee on ordering? What else? Yeah. That it's not that it's even going to get there that it's not going to double? What else? The order of the packets. Yeah. Do we already say like if it gets there at all? Yeah. If it gets there, all these kind of things. So it does nothing. It adds no, none of these reliability features. It provides exactly what IP provides. Connectionless, unreliable, best effort. So delivery, I guess the one thing we didn't talk about was modification. So integrity, non-duplication, ordering a bandwidth not in the RT. The one thing, yes? I was going to say doesn't Discord use this for their voice channels? Yes. I don't know about Discord specifically, but yes, a lot of VoIP happens over UDP for explicitly these reasons because as we'll see, TCP provides a lot of these things, but it has a lot of overhead to do that. And in a real-time communication scenario, you don't care if your packets arrive out of order or something. And, well, we won't look at it here, but in general when you think about networking, you can as an application use UDP and add things to it if that's what you want. But let's say you don't want any of the other features. So you can easily do that. And if you think about it, that's kind of what we're doing in the homework assignment is we have a way of ordering the bytes that we're sending because we're saying which byte it is that we're sending and then we have a final signal which says how many bytes we've sent. So that way the other side knows how many they should have seen. The one thing that UDP provides, and this is something that goes back to when we initially talked about abstraction. So why is a port important? It allows us to block certain ports if we want to kind of limit track. But what does it mean? What does a port abstraction mean? I mean, we can do that, but... It tells you what service on that machine needs that information. Yeah, so it allows multiple different server applications to be listening on different ports on that machine so that way clients can connect to exactly that application. So really going back to where's my thing? Oh, you're going to get this screen. Oh, it's okay. It'll survive. Sorry, it's in presenter mode. It's usually not, but... So this TCPIP layering, right? So in order to know, am I talking to DNS or NFS, both of which use UDP by default? You need some way for one machine to be running both and that's the idea of ports and that's where ports come in. But again, it mainly... This is kind of the only addition that UDP has over IP. So it just has this idea of a port. So you can, like, go back to kind of the house analogy. So the IP address is the physical address of the machine and the port number would be what apartment number are we trying to talk to of that machine. So, yeah. Yeah, so without port abstraction do you get like confusion amongst all the different packets coming in? Confusion without, you said? Yeah. Yeah, without, you'd have no way, you'd only be able to run basically one application on one IP address because there would be no way of knowing who is this message for. Right? Of all the apps that are listening, yeah. Would each app have their own format that gets like filter out which message is for them? Possibly, but you would need a way, like how would you, you need some kind of way of having an application like what order do you pass packets to what applications? I mean, theoretically I guess yes, you could think of some way but then you're going back to this model then you're forcing every single application to have a way of distinguishing different protocols and doing all this kind of stuff which would be a pain. I guess you could do it like you could have kind of like there's magic bytes on files that tell you that it's a PDF or a JPEG or a PNG or whatever in the file format itself you could have that in your NFS packet and then figure out where it goes to based on that but then you're still kind of locked in and you can't I think that would provide a lot of problems. So looking at UDP message so again this is another layer that's going to be on top of IP so and here what fields do we expect based on what we saw about UDP? Port number? Port number what port number just like 50? Just one. One? Port number? Two. Why is two better than one in this case? Two is in the direction two I'm sending it to a certain port from a certain port. Right so just like IP addresses right we have a destination IP address and a source IP address. So similarly in UDP messages we have a source port and a destination port how many port numbers can we have? 32? 2 to the 16 2 to the 16 just like 65,000 something like that cool and we can see here there's 32 bits each port takes up half 16 bits so the source port and the destination port for both 16 bits cool and then we have some header information we have the length of the message a checksum and then the data so there's really and we can even so there's the text description of this is what UDP adds on top of IP we can actually look at just the header itself and say the only thing this is adding so what's inside this data like the IP packet? Yeah the IP packet and what's the start that IP packet going to have? Yeah the header the IP header and then in that data section there'll be the ethernet frame information Oh that was wrong you guys all got that wrong we got wrong yeah Is there an informal standard to how ports are numbered like across different services I know sometimes they're standard but what if like a new video game comes out and they want a separate port for their server do we have this running out? So in general there is there's I don't know if it's I can but there is a list of like defined ports and that doesn't mean that so you can stand up a server and you can put any application listening on any port so you can run a UDP server listening on port 80 it doesn't have to be an HTTP server it's just that's the kind of binding by default that says hey if I want to talk HTTP protocol the server is likely a port 80 but a client so for a client to connect to a server what is the need for UDP of what we just saw so going again to like what things it means yeah the destination port number the destination port number or what else the what? what's in the IP packet? yeah so the destination IP right so we need to know the port IP that we're trying to send to sorry we need to know the port number the destination port number and the destination IP address so and the question is how do we figure that out so the question was about games so you're developing a new thing you control both the client and the server so you can technically make whatever port number you have to deal with a lot of complications and there's on most systems not most systems port numbers less than 1024 are reserved for applications that run as root typically so you can look up the table you can choose an unknown one which would probably be the safe bet you also have to think about if anybody else is blocking your traffic because if you happen to choose a port number of a well-known let's say backdoor then that would be a bad idea your packets are negative but technically there's no reason you can't choose whatever you want especially when you control the client okay so we were wrong so inside the UDP data grant is the actual data of the message and this is where finally we actually get the real data that we're trying to send if we look at the ethernet frame and this makes sense because this ethernet frame is going to change hop to hop as we saw it's going to change with source and destinations for the current hop are put in the ethernet frame the IP header stays the same except for the time to live value is changed what about the UDP header hopefully it stays the same yeah it stays the same if we go back there's nothing in here right there's just source port destination port message length and check zones that's it so that data remains the same so UDP is not complicated so how does the UDP packet get sent you said ports what ports are you talking about UDP port numbers in UDP port yeah so yeah so the actual data that we're trying to send is in the UDP UDP packet yes and then that's embedded in the IP packet then that's embedded in the ethernet frame right exactly so how does that packet travel what's the difference between that and IP isn't it very similar almost the same it isn't the same yeah I would say the only thing that's different is when the packet gets there the operating system sees that it's a UDP packet checks the header and says what port number is this destined for do I have an application that's listening on that port number if so give the packet to that application and then let it do it what happens that application wants to respond it makes its own UDP packet and then that embeds that it sends it to the operating system which embeds it into like an IP packet and what does it even know or how does it respond it needs to it takes the original the packet it got because then it knows the source and it makes the source its destination and it knows itself with port numbers so that's how a UDP machine responds but again there's no so just like before if we think about if A sends a packet if Alice sends a UDP packet to Bob does Alice know that packet ever got there no no does she know that Bob is even alive no so yeah that's what you get UDP cool this mean yeah wait the UDP did not contain the it does it has the source port and the destination port yes why would it be that because if you're making an application what would the application kind of know this and it put that as the destination the answer is it depends so for a protocol like this yes it would depend on the protocol of how do I respond to a message right it could be on a defined port but here we're specifying what the source port is so usually what will happen is let's say for something like DNS DNS is a good example you make a UDP request you choose your operating system will automatically choose a random source port the source UDP port and then it will wait and any packets that come back to that port it gives back to the application so that's how it deals with that but yet it's one of the tricky parts of figuring that out because there is no idea of this connection it's very much packet based you're just sending data so this gives you the ability to respond nothing says you have to respond or that you should respond and thinking about it in terms of attacking right so when we receive a UDP packet what of this packet can we trust the destination port and that's it right the source port can be forged and we talked about already the IP the IP can be the IP source can be forged which leads us to what do we mean that we can trust that the depth I mean the destination port is going to be the port that it arrived at but what do you mean by trusting it because that could be changed so like another we could have been sending this packet so it came to us but we didn't need it or it wasn't meant for us yes so I guess we can trust the fact that this destination port in the same way that we can trust the destination IP and that we're receiving this so it was somebody wanted it to come to us but it doesn't necessarily mean the as we saw it doesn't mean that source IP was the one who sent us that packet similarly here there's nothing that says that the source IP was the person who sent us this packet right they could be spoofed or it could be a man in the middle changing it along the way yeah good question so this means because there's basically no change from IP to UDP this is why UDP is very easy to understand is all of the attacks that we talked about work against UDP that we talked about with IP so what were some of those very broadly spoofing sniffing impersonation yeah so spoofing is trivial it's big I mean not trivial it's basically IP spoofing so let's say that I have this server I can spoof any UDP request to that server and if I wanted to go to the client what do I put in that packet the client source the client source IP and that's it and the source port and then the server gets that if it's responding it will respond back to that client this is actually how a lot of denial of service attacks happen is that like the what's the name of the time system is it NTP NTP network time protocol yes NTP so the NTP the network time protocol name and basically if you sent in a small request it would send a reply back that was 15 times larger so what you do is figure out which of these servers were vulnerable figure out what client you want to take down spoof those requests to each of these servers a large number of them all these NTP servers from around the world will then get UDP packets reply with this 15x reply back to this client and then basically overloading it and sending it too much information and it all comes back to basically IP spoofing because it's trivial to spoof a source IP address does that make sense okay I have a quick question yes are you going to ever show us how to do this let's think about this somewhere to see how this could be done let's think about this what's the difference between doing this and your homework assignment it is the same thing you're creating raw packets where you're choosing the values in each of the protocols so it's just the same as changing source IPs and destination IPs so this is kind of the idea is all of this I mean there's basically no difference I mean once you see how you can forge a raw packet as long as you understand the mechanics of what happens along the way you can do all this stuff so it's also I've created assignments like this for grad classes they can be very delicate because some IPs some ISPs don't like that I mean they're like some won't let you spoof IP addresses and so you have this problem of how can you make sure that everyone can actually do the assignment so it's a big thing but you can you can play around the way to do this is just like throw requests around and spoof them and see what's going on so we can also so here yeah it's okay so how would they even know that the sender spoofed an IP hmm so put yourself in this situation you're an ISP right everyone have internet how can the ISP know whether you're spoofing packets or not yeah when you plug your modem in right it gets in negotiated somehow a IP address from the ISP and so the ISP should know exactly what your IP address is so this is called the egress filtering basically so looking at usually it's outgoing of a network so like ASU by doing egress filtering it would say no like nobody can spoof an IP address that's not on ASU's network a lot of times they don't actually do that because it requires processing power and keeping track of IP addresses and all this stuff so many many ISPs do not do any of that yeah is there any legitimate reason to be sending packets with a spoofed IP? no not that I could think of yeah which is crazy but it's still you can still do this in a lot of ways okay so who so think about this scenario who are we spoofing here what's the trust that we're spoofing here yeah we're spoofing a packet sent from the client to the server right so the server sees a request and thinks that it comes from the client if this is NFS a network file share maybe this is delete a file so now that file is gone what do we need to know in order to spoof this request the source IP of the client we wanted to spoof the server IP address and the destination IP address or the destination port of the server so we need to be on the same local network as this server as long as that packet will get there as long as this IP address is a routable IP address so this means you can do crazy actually I don't know if you can do that that would be interesting spoofing a packet I assume you can spoof an attack a packet from an attacker completely external to a server pretending to be a local address like a 192.168th address I'm not sure if they'll route I'm sure they would actually yeah yes and that's slightly different which is what because you're doing out the application there's no IP changing of the packet but yeah I thought most outbound waiting for property to use the private source packet it definitely it definitely drops packets where they have a private destination IP but I don't know about the source IP that's what I'm I don't know I would be interested to figure that out I think that would be an interesting question cool but what about the reverse can we do the reverse what if we want to spoof the server's reply to the client can we do that so when would we want to do that if it's like a web page request we could spoof like a web page that's being sent back to the client web pages aren't our UDP they're but yes if we could do that I mean the general concept of spoofing a server to a client that's exactly what we want to do what about in UDP what protocols that we talked about they use UDP DNS why is DNS important yeah it maps domain names to IP addresses so if you can convince somebody that google.com is at your IP address they will come to you instead of google.com so if the client is going to make a request to a DNS server and says hey I want the IP address of google.com then what do I need to do as an attacker to spoof that response louder sorry do you know the server's IP and the client's IP you need to know the server's IP and the client's IP so that you can properly craft a packet that is to the client from the server what else do you need the ports which ports the clients so is port so you need so you would I need the server's source port in some sense the server's port so you can set the from port correctly and then you also need so again looking at this UDP request the client is making a UDP request to the server you want to basically be able to respond to this reply so what do you need from that packet what was that we're going to say the way the message is like that it's DNS that's a protocol you can look up the RFC for DNS or create a reply what do you need and what information from there you need to know this is for DNS right sure yes it applies to any UDP packet oh never mind the data involved in the UDP request for the DNS request the data whatever I don't care who they're requesting I still want to spoof the DNS request and say it comes to me I need blood if you could get the UDP request packet what do I need from there IPs well port numbers port numbers why do I need the port numbers so if the client says to from a port to a port you're expecting to reply from the port it sends you yeah it goes back to that communication protocol we talked about the DNS request so the client's going to randomly generate a a port number send it to the server as the source port and is expecting a UDP reply to that to that port so yeah quick question so if the operating system generates a random port and starts listening on that if you intercept that message and you know which port it's listening on can you then use that to like send a script into the clients into the whatever port it's listening on now that's an open port you can't send this all you can send is packets right so you can craft a UDP packet that has the source IP of the server the source port of the server the destination IP of the client and the destination IP a destination port of the client's port that's the response to that and send it if you get there before the server the server will think that that's what your reply is but that's what the server's reply is so thinking about that can we do this remotely will we be able to see so think about this the other way is think about it is doing it blind so can we without seeing this UDP request can we make a reply what was that yeah how many do you have to guess 65,000 65,000 that's actually not that much you've been you're experienced with large numbers and hashing and how many hashes per second and maybe you can do this a few times or if you can force the client to make that DNS request maybe eventually you can get it so it is possible but it's noisy right you have to guess it right better way is to intercept and get a copy of this UDP request how do you get that listening on the gateways between maybe listening on any of the switches in between yeah it's wifi you can just be listening on a public wifi you can listen to all of the unencrypted packets that are being said what else spoof your IP how does that help you get the packet if you would compromise the switch and had your IP address associated with the MAC address of the server on its like ARP cache then when it sends so you're not to compromise the switch but you can use ARP the things we talked about in local network attacks with ARP poisoning then we can intercept a copy of this packet as well right we talked about those so we can think about how they manifest in each of these different contexts so here was if you can do that then all you have to do is spoof the UDP reply with that information and that way if you can do it faster before the reply gets to the client now if you think about it from the client's perspective they have again absolutely no way of knowing that this packet was spoofed it is not originally from the server so does the client discard the actual real UDP reply when it receives it yes because it's not expecting the I guess a high level question is it depends on the protocol or what the application is in terms of DNS you make a request and you expect one reply and then you're done you just discard the next message yeah yeah whoever gets their first definite any other questions now we think at a high level do we break into a remote application or a remote server let's think about it this way do we talk about bringing into a bank so what are the steps you've all watched movies how do you bring into a bank yeah you go to the bank no yes that's one step that's a joke yeah you have to assemble the crew first that's the first step you need a nice montage like you assemble the crew and then what do you do so then you just go right to the bank just storm the bank just storm the bank from there what was it is it louder do you investigate the bank you gotta why do you investigate the bank you gotta scope the joint right you have to like go to a cafe across from the bank and like read a newspaper while you look at like when the guards come there when do they change positions when do they when is the safe open who's the manager right you need to find out as much information as you can about this bank go to city hall get the plans of the bank find out as much information as you can and then you actually try to rob the bank with that plan or I guess then you formulate a plan execute the plan and then it all goes to heck and doesn't go well so the reason what we're talking about this is breaking into a remote system is the same way that first step is you need to understand you need to do and understand what is this system so if we think in terms of some remote machine that we want to exploit what do we want to know about that how can so think of it even conceptually there's some machine somewhere we want to exploit it how first try to find out what protocols it's using why because then you know what you can actually spoof and how to spoof it yeah so think about this so there's some remote system the only way we can possibly influence that system is by somehow getting our data to that system right so we need to know what are the ways that we can get data into that system can't you also think about the other people that are using it and use those people to gain access to the remote server yes but we need to know what's this server doing first maybe there's nothing it all depends just because it's part of an organization it could be nobody uses that server right it could be people focused yeah do you work with services and from there service like versions yeah so we want to know basically we need to do the same thing and perform some kind of reconnaissance to understand what services are listening and running on that remote system right is it an email server is it running an SSH server is it running DNS and so essentially what we want to try to learn is what applications are listening on that system would you agree that that would be useful cool yes so the idea there is called port scanning so we want to scan a remote system and find out what applications are listening on which port and specifically for UDP we want to find out what applications or what services are listening so how can we do that I mean that's just a program yeah you can just send packets using a port and then what and ask it see who the operating system responds whichever one they respond yeah so if you think about it this is all we have to work with right the UDP message so we have the ports the source ports destination ports so if you think about it conceptually we basically want to so there is no protocol to just ask a system what ports are open so we basically group force and send a packet to every port in the system and then we need some way to tell if that port is open or not because let's say we get a response what do we know it's open it's open yeah we definitely know it's open what if we don't get a response if we don't know anything the packet may not have got there but let's say it did get there yeah maybe the application maybe we're not speaking the right protocol to that specific application so there maybe could have been or maybe there's no application there and there's nobody listening on that port right and we'd like to be able to tell those differences apart so this is why the idea of port scan is actually super interesting and it's tied into little details about how operating systems actually operate and what they do if in these different circumstances of is there an application listening on that port versus not so a normal UDP port scan is actually fairly simple you send a zero packet to each port if you get an ICMP so there's an ICMP message which is the what we talked about the basically an IP field of things but you'll get a message that says the port port is unreachable from the operating system and then you can tell right yeah that will tell you that it's closed that will tell you that nothing is listening on that port exactly so what you'll do is you'll send out packets if you get a reply back then you know you're definitely listening if you get this message you know there's definitely not anything listening and if you get nothing back then you're pretty sure there's something listening there maybe you send a few packets to confirm yeah yeah so you are you need to try different methods and different things so you try different techniques of what happens in certain and it's all about again the networking stack of the operating system in certain circumstances yeah so let's say I know that I'm pen testing company X and I know that they have an IP address range that's this whole whatever a slash 24 and so I can send ping packets to every machine on that IP address range to figure out how many IPs there are and then from there I want to understand how many what are running what services and that would give me a nice attack service and I want to go further from there to figure out exactly what version of software are they running on each of those systems are they old versions with no exploits that I can just throw at them the trick here is that it can be very slow because many TCPIP stacks limit the error rate so you can't just send 65,000 packets to them at once so the the Linux limit is 8 messages for every 4 seconds this is why the default kind of UDP scan if you're using something like Nmap which we'll talk about here so these are things you can go home install Nmap run it on I would still I guess we didn't talk about this well we'll talk about that in a second but I'd still run this against systems that you control just because it's nicer so Nmap you need to run as group usually because well sometimes you need to run it as group because it may create packets but basically Nmap the Ancestry Network it's a network mapping tool you can do that ping scan I mentioned to scan a whole IP address range for machines that are active the dash U option is the capital U is the UDP port scan so it would scan this and it would tell you and I think by default the other thing that's important is it's only scanning the top 1,445 ports that are known to be used by UDP it's actually not scanning and trying every 60 every port from 1 to 65,000 and so it will tell you that on this machine there's NetBIOS NS NetBIOS CMG and it took 4 seconds to scan that are the vulnerabilities for each port dependent on the service that they're associated with yes and not only what service but what specific application because the vulnerability is tied to the software so if you found out that it was running a DNS server you need to figure out exactly which version of that DNS server it's running and which is it buying is it some other implementation TCP dump does it do the same thing that NMAP does in this situation so TCP dump is 100% passive in that it just listens and logs packets so you would what I would do is to figure out how NMAP works run TCP dump to see all the packets that NMAP is sending and then get all the NMAP to figure out what it's actually doing so in this case you'd see a bunch of you'd see 1,445 UDP packets and you'd get back basically was it 100 1,443 ICMP port closed messages and you get two that were not and those are the ones that are likely open but you still don't know and you don't even know again the only reason this is saying it's NetBIOS-NS is because port 137 is associated with that service it could be anything running on that port so you need to do more information to figure out what's actually there any questions on this and now we move into TCP so TCP gets a little bit more complicated and finally we get some features from our networking protocols that we would like we get connection oriented which means that we can establish a connection with our remote system we get reliable delivery we get a stream so what's the difference between streams and packets or datagrams I guess is that again streams and order so stream is in order and what else kind of I'd say it's more it's in some sense an abstraction so rather than thinking about it in terms of packets the data that one side sends to another forms a stream of data so we can just send a bunch of information from one side to the other not worrying about how many packets we get sent the operating system can figure that out and on the other side they just read bytes and they can read from the stream of data so you get really nice features that way we also get in terms of our stream it's reliable and when I say reliable does this mean we're guaranteed that the other side will receive our packets no what if some undersea cable gets cut you can't guarantee that the packets are going to get there but you can on the other side saw the data that you wanted to send so that is the part that you can actually guarantee so that's what the when we talk about reliable here we mean that there's no we know that there was no lost packets we know that there was no duplication we know that there were no well transition errors kind of and we know that it's in the correct order and we know when the other side has received all of our information which is important the other thing is the port abstraction so again we have ports in TCP they work exactly the same as in UDP which means they're having 16 bits 16 bits yeah good they'll be popping all these questions on you so the idea is TCP provides us in our applications with this idea of this virtual circuit or virtual communication channel that's identified by four different things and this is kind of forms the base of a lot of TCP communications so it's the because we don't just be able to talk between one IP and another IP why? no we're not worried about forging because well so let's think about this when I talk to another machine what am I talking to yeah so the idea is so we're going to establish this kind of communication channel but how do we define that channel that we're talking on so do we talk just IP to IP? exactly right we could have multiple applications running on one IP address that want to talk to multiple different IP addresses running on the remote system and so we need to establish communication that way this is the whole idea of the port so we abstract it up and we have basically source IP source port destination IP destination port there's a four tuple that defines a communication channel this is incredibly important to kind of underline all of TCP communications other interesting things is this creating this circuit you have two full streams so this means either side can send data to either one at any time and can actually close other things is this idea IP address port number is called a socket so this is when you talk about socket programming this is usually what we're talking about looking at the header in more detail so again just like UDP we have source port and destination port which makes sense because every packet in TCP needs to come from this we also now have this problem where we need to know where we are in this stream because we have a stream of data we're trying to send from one side to the other where in this stream are we so this is TCP is going to introduce some more concepts which we'll talk about exactly how they're used and it's important to talk about and understand how they're used so we can go back to our familiar friends of spoofing and hijacking to see how can we do this in this TCP context so we'll see this but safe to say there's a sequence number which is a how many 32 bits we have an acknowledgment number that's 32 bits we then have some other special things some special flags which we'll see some of them do we have the window number checksum pointers option padding a whole lot of stuff so you can see that TCP is definitely more complicated than UDP just by looking at the headers UDP was just source port destination port basically done here we have a lot more things and so why does this make sense that or does it make sense that TCP has more complicated headers it does make sense why because the reliability you can't get that stuff for free right and the reliability and those guarantees for free you need to add something to it right so this is what's being added to it so question so vice sequence number is that like the order in which that we read it we will find that out in a second I was going to ask what acknowledgment number was yes it's related to the sequence number but it's important to kind of see just the layout and the size so we can conceptualize that on the same machine I guess there's difference they can't be on the same so you cannot that's a good question I would say my intuition is no you can't have both a TCP and a UDP service listening on the same port one port one protocol one this is what I believe to be the case yes I think a similar question is I saw you mentioned that it's TCP ports yes although I guess like convention because we're often talking about TCP so yeah that's a good question I should check that out you may be able to but because the operating system would know which protocol it is and it would know I don't know if it actually does that for you that operating system is the one that responsible routing to the to the application yeah because the application will make a call to the operating system this protocol on this port and give me any packets that are I'm listening for that so you'll see how that's done in the client code you're all right I'll start with all right what was your question for that answer yeah sure I think so okay cool me too okay cool so just like before we have our TCP header with our TCP data that's being sent which is put inside of an IP header and the IP data which is then inside of the Ethernet header with the Ethernet data just like before so all right there's a lot of text here and it's really just they hope we're still recording you know what I'm gonna okay so we go back to our handy-dandy scenario we have Alice who wants to communicate with Bob over TCP so let's say Bob is running an HTTP server port 80 and so what does Alice need to do to like start the what information does she need to start in a connection with Bob destination IP destination port and then source IP and source port Bob IP destination port 80 Alice IP and some source we'll call it we'll fill it yeah all right we'll go 41 41 right okay so this all the information and Alice has all this information she knows Bob's IP if she didn't have an IP she had a domain name and used DNS in order to translate that domain name to an IP address but the end of the day before any packets go out or any TCP packets go out Alice needs to know Bob's IP address she knows it's port 80 because it's talking HTTP and she knows the IP address and some random source port we'll call 41 41 so but we think about it and what we've been thinking about is what does everyone know at this point so does Alice know that Bob is up and exists well no why not it hasn't sent anything nothing hasn't been sent right so we need to do some way in order to initiate a connection to Bob right before we can ever talk to Bob we don't know whether Bob's up we don't really want to send any data we need to kind of communicate in the link or a circuit we need to be able to verify that that other side is up and once the talk to us could be that Bob doesn't want to talk to us and tell us to go away so what Alice will do is we'll send a TCP packet bless you so so source port 41 41 destination port 80 and I'm kind of mixing the headers here but that's okay source IP is Alice IP destination IP is Bob's IP now when Bob gets this how does he know that this message isn't part of the current ongoing communication with Alice because he would recognize her IP address if they've spoken to each other yeah so so we need well so first he would use the IP port right so he'd say am I already well one way could say is am I talking to Alice's IP port 41 41 but another thing is maybe it would be nice to say that this is like an opening like a starting communication message would that be the acknowledgment of the thing from the TCP from the TCP close so this comes into the flags so inside of these flags there are a number of different bits that can be set one of them is the sin bit syn so set that bit to one all the other five bits to zero which essentially will then tell Bob hey I want to initiate a new connection with you so there's another so Bob can get this there's another flag called reset RST or you can send that back to basically say go away don't talk to me that's what my Bob could say but Bob wants to do this communication so sends this to exactly what happens on every hop of the way how this communication gets from Alice to Bob we know that we've looked at that studied that Bob gets it back what is he going to reply would it also be with the sin bit well what about the data here so we have the sin we have ports source destination source IP destination IP what's the source the source port 80 80 in the destination port 41 41 what about the source IP Bob I know I'm running out of space sorry Bob's IP and destination IP Alice's IP Alice's IP so one thing that we need to figure out is Bob will needs to have some way to say this is I'm responding to your request right so it just so happens and you think of there could be any number of bits they don't have to be these but they this is what they are so they'll set two bits the sin and the act flag so Bob will send that back to Alice so how does Alice so what does Alice know when she receives this packet Bob is up the reply was meant for Alice the reply was meant for Alice yeah one thing though that well we how do we know that it was this request what if we just talked to Bob two minutes ago so we had a talk with Bob we closed our communication and then I want to talk to him again how do I know that this packet is a direct response to this packet and not a packet from two minutes ago or five minutes ago it just got lost in the ether and that was found maybe that was through with the like the secrets number so I mean talking about here the information here right is there enough information to tie this request this response to this request not in this right and you think about it just in terms of information right there's nothing in here that says this is a reply to this message so we need some kind of like random number or something that will kind of be able to say hey this is this message and that way if that random number is included in that response it will show me exactly what that response is so this is kind of the basis for the sequence and acknowledgement numbers they're used a little more complicated when they start to talk but at least in terms of setup so Alice will will she generate an acknowledgement number? I think we'll ignore this for now so Alice will generate a random sequence number and send that along and that way when Bob replies he can put in his acknowledgement number yeah this makes sense okay how fancy do you think I can get? not fancy enough okay so I'm just going to add it to the bottom so and so to go more in depth here the reason why this sin flag is set is this sequence number wow that's not true so what Bob will do is he will reply back in his acknowledgement number so there's two numbers here the sequence number and the acknowledgement number Bob will reply back with acknowledging Alice's sequence number plus one why the plus one? seems silly right? all we need to verify is that the response came from that initial request that we made so why the plus one? to keep the communication going back and forth and so I don't know it seems very trivial right? I was going to say like because TCP is supposed to be like a stream instead of like just a series of packets so like I guess the idea would be like this is part of this particular connection like that we've just started rather than potentially like but do you need it? do you need it? because the goal here is to link the request with the response so do you need a plus one here? no right? yeah I was going to say yeah that could go away right? and it's totally fine the same thing still works the reason is actually goes back to if you remember endianness from architecture days what's endianness? it's like yeah so if we think about this 32 bit number it's 32 bits that are broken up into 4 bytes which byte is the most significant byte or the least significant byte? is this the most significant byte these 8 bits? or is this the most significant byte? and different operating systems are different so Intel I believe is little endian I want to say which means that the most significant bit is actually on this side one you consider the lower side but whereas so a lot of systems are little endian where I believe and I maybe no that's not right so whereas this TCP if you look at it it's defined as big endian so the number is big endian so basically this was like a debugging capability that it's trivial to rip this sequence number from the packet that you received and put it in the new packet and just literally copy the bytes that does not mean that you can interpret that number as what it's supposed to be so the idea was they added one here so that way says you know how to do math and you can speak the proper byte ordering here so it's kind of a cool clever almost mini debugging thing in the protocol okay cool so are we good? so now so now Alice knows what we're talking about what does Alice know when she receives this packet like we said the host is alive Bob is alive and what else he's ready to communicate he's ready to communicate and he specifically wants is replying to that message that I sent is that it? are we good to go? we just start chatting? yeah say it again yeah that they're compatible exactly so that Bob can do the sequence number plus one do we actually know we don't really know it's Bob replying to us right definitely not but we know that this is a reply from Bob's IP that includes the right sequence number that we're expecting right so we're thinking about now how the protocol is designed is not thinking about these attacks but we'll talk in a second so are we good to talk? good to go rock and roll? yeah we need to why? because if we could send it and then drop off and then Bob's like okay I'm ready to connect yeah so if we think about this right we always got to consider there's two parties who are trying to communicate here Alice and Bob so we've always been looking at it right now from Alice's perspective what does Alice know and what does she know about Bob but if we look at it from Bob's perspective so Bob receives this first packet which means what to Bob Alice wants to start talking and then Bob sends this message and then what does Bob know? nothing Bob knows nothing right? Bob doesn't know if Alice got the reply or maybe Alice shut off in that time in between right? so a lot of people I don't know they think about like a three part handshake or whatever why you need the three you can reason yourself very clearly into why you need three so so Alice so Alice needs to reply before Bob knows that this is a communication that needs to continue so Alice will create a packet and will be essentially replying to Bob's reply so Alice will reply and she will do source IP 41 41 destination IP port and source IP Alice's IP destination IP Bob's IP cool okay now how does Bob know that this is a legit reply to his message? does he again have the same problem but from the different perspective right? we're looking at Alice Alice didn't know Bob's reply was directly to her message and now we got the problem from Bob's perspective how do I know that Alice is actually replying to the message that I said so we're going to use the same trick it's not anything complicated we just use the same concept so Bob will generate his own sequence number that is unique from Alice and will send it as the sequence number of his packet so he will send sequence number of Bob and how will Alice respond? sequence number of Bob yeah in the acknowledgement so sequence number of Bob plus one we'll find out apparently on Thursday why she will also send the sequence of Alice plus one as her sequence number and so should so now she needs a way of saying that this is a reply to your reply and so she will send back a message with just an act bin set so this is the classic so this would be one thing you should definitely burn into your brain about a TCP connection SIN SINAC AC and now at this point now once Bob so at this point Alice knows that Bob's up and ready to talk once Bob receives this message he knows that Alice is up and ready to talk and now they can both communicate and start communicating so we'll see how these sequence acknowledgment numbers give us the basis so that we can have reliable communication from both sides