 Alright. Happy Monday everyone. First things first, to take things off today. Assignment one is on website right now. We'll be at least, there's not any links to it at the moment. I'll add them right after class and put them on there but you can go check it out at this URL. About two weeks on this assignment, slightly less than two weeks because I don't want to do it on Monday and no people will be here for class. Due before midnight, very important, as per the syllabus, every day at this late it will be a 20% reduction. Cool. The first part is incredibly easy. Hopefully you've already done this. Otherwise you're not connected to the class. Sign up for the course management though. Part two is very cool. So part two is you will build a reflector. So the idea is you will build a program that will, you're basically going to be impersonating two different IP addresses with different MAC addresses on your local subnet. So the idea is any packet that is sent to the victim, so there's two IP addresses, victim and reflector. Any IP address that is sent to the victim, what will happen is your program will listen for those, take that packet, take the content of that packet so that came from some source IP address. So your goal is to send it back to that source IP address from the reflector, see what they respond as, and then respond from the other side. So in this way you will, when everything is working, you will be able to SSH to that victim IP address which doesn't exist, and you'll be SSH-ing actually into your own machine. So this is a really fun project and it really gets you to know the details of low level networking stuff that we're talking about now. You'll have to implement ARB in order to do, in order to actually simulate these IP addresses on the network. It is a lot of fun. And you can program this in whatever language you want. I recommend, oh I think you could move the scab if you want to talk to me about that. I highly recommend you use scab and you use Python. That will make this part a lot easier, but you can really do this in whatever language you want. Everything's got to run, so it's going to be from here on out for the rest of the class. Everything has to run on move to 14.0464 bit. So that's going to be the operating system that we'll use from here to the rest of the course. And there'll be a list of, you can see here a list of pre-insult packages. You can upload with your source code a packages file which lists different packages if you want to do, for instance, your, if you want to do this in Haskell for some reason which I wouldn't necessarily recommend, but you know, whatever. You can add the Haskell GAC and GAC diagram packages to your packages file. That way before your code is ran those packages will be installed and available for you. Any questions on this? So there'll be a, you'll need to use a make file. So this is for all the products in this class. You'll need to write a make file. So this is how we're able to do this so that you can write your code in whatever language. You can write in whatever you want as long as there's a make file. That way after we run a make there's an executable called reflector. And that reflector respects this interface. Then we're good. That's why we don't care what language your program is written in. So you can write it in whatever you want. Okay. And there's only here to the last year's TA created or gave me about how to look up make files. Also need a reading. Any questions on this? Have no questions? Yes. This isn't up yet, right? It technically is up. There are no links to it though. But yeah. If you go to this URL that I was trying to utilize there. Can we assume that the... Yes. Yes. So that would be a requirement. You won't need to check that in your code at all. You can just assume. So the interface is... You're given an interface. So physical interface. You're given the victim IP, the victim Ethernet address or reflector IP or reflector Ethernet. So yes, you can assume that those are on your same subnet. You don't have to worry about that. The person running your program has to worry about that. You also don't have to worry about are those IP addresses already taken by somebody else? That's something that your code... The person running your code should do. Will it be automatic test cases where we can upload it and see if it passed all of them? Yes, thoroughly. I have a site up. I need to tweak it a little bit to get everything running. But I will have that out. I'll send out the information Wednesday at the latest. So you can go to there. I don't think any of you is going to finish in two days. But yes, there will be a submission site for all of this. So when you find... This is on this machine. This is a synod of interface zero, VTA zero. Any packets that get sent to the victim IP should get reflected back to that source IP from this reflector IP. And then any replies to those packets get sent back to that source IP address. You're essentially impersonating two different machines. Yes. That's it locally. These are our victim and under... First machines in different organisms. No, no, no. These are our machines. Your program is simulating these machines. There is no victim machine. There is no reflector IP. How would you simulate an IP address on your local network? Virtual machines? What are your programs doing in it? How do you know if an IP address exists on your network? You ping and then what does that do? It what? Get a reply. Before that. You get sent an ARP request. You say I want to talk to this IP address and what did you get back if that machine exists? An ARP reply. It says I am this IP. I am at this physical interface. I am at this physical link address. So the program, you can do that. You can listen to the network traffic, sniff the network, see are there any ARP requests for this 192.168.1.10 If there are, reply that ARP request with this is my ethernet address. Similarly with the reflector. There are no extra virtual machines in here. You are pretending to be two different other IP addresses. Do we have to program programmatically set our interface to misgivous mode? Or do we assume we can do that manually outside? Assume that it is done with whatever permissions are being used in your sniffing program. The interfaces will handle that for you. Wait, let me think about that more. Yeah, you don't have to worry about it in your code. Yeah, it will be fine. And the other thing, the little caveat with this assignment is that your code needs to be run as root in order to get access to raw sockets. So this means the submission system will essentially run your code as root so don't do anything stupid. As many as you want, I think. I never said that policy depending on the submission system load. But it hasn't been a problem really in the past. It's 170 people. It's got a lot. Especially if it's close to the deadline every few minutes. The box is all confused. But we'll see for now. But you shouldn't use this as an opportunity to just make a tiny change, test anything, and then just submit it, right? You should use it to actually develop, develop it, test it, make sure that it's correct and then you're ready to submit. I was going to test it right now. I don't need two virtual machines to test it. Why? So the one virtual machine will be the victim one. No virtual machines. No virtual machines. Your program is pretending to be those IP addresses. Can you explain how do we test it locally? How do you test it locally? Run it? How would you test it? So what's the test base? After never traveling, you're going to do what? What is it trying to do? We have to send out the initial ICM thread or request for the IP address here. Trying to spoof. Yeah, so how could you do that? Ping it. Ping what? Ping the victim IP. You should get a reply. You should get a reply. Only if the machine that you're pinging it from would give a reply. So you can run it locally. You can also test it on a different machine on your network. If you try to pinging that IP address on your local network, the victim IP, you should get a response if your machine gives a response. Could you set it up with multiple network interfaces? You could, your program doesn't need to worry about that. Victimize. I don't know if that's the term I'd use. You're essentially just telling it what interface to listen on, right? So which physical device to list physical port or wifi to listen to, right? And then the question is which IPs is your victim? So which IP when they try to either ping that victim, they'll get pinged. If they try to attack that victim, they'll actually get attacked because they'll actually be attacking themselves. So what's that IP address and then what's that Ethernet address? And the reflector IP and the reflector Ethernet specifies when you're sending those back to whoever pinged you on this victim, who are you sending those from? So yeah, there shouldn't be any other interfaces, just one interface. I mean, I guess you could change it to do that but that would be a little more complicated. Could it be our actual IP address or something you're paying for on that feed? There are a total of three IP addresses in play. So there's, let's say you call the attacker even though they may not be attacking us, call the attacker IP address, there's the victim IP address and the reflector IP address. So packet comes in from the attacker to the victim, right? Your program's listening to that, right? It's having all in the same interface. Your program's listening to that, it sees the packet. It says, okay, to respond to this what I'm going to do is I'm going to send this packet, change the source address to now be the destination address and set the source address to be the reflector IP, send that packet out on the network, that'll go to the attacker's IP, they'll send a response back where? To the reflector IP, right? Because that's who we sent the packet from. Then we take that packet, change, put the source to be the victim IP and send that out back to the attacker. So they'll see that as the response to their initial packet. So three IP addresses. So pretty much we're doing it manually. But we're not. Pretty much. It's man in the middle kind of, but it's coming to you, right? So you're, you're saying instead of actually responding to this packet the way I would, I'm going to respond however the attacker would. So like if they ask you for a webpage, you'll actually ask them for a webpage and you'll return that webpage back. If they ask you to try to SSH in your machine, all those packets will actually be sent back to them. So they'll end up SSHing themselves. If they send you some kind of denial of service traffic or some kind of exploit traffic, right? You don't actually do anything with that, you send that back to them. So they'll think that they're attacking MIT when really they're attacking themselves. Okay. Part three. So part three is pretty fun. This one we're going to go into some low level C network game. So specifically on this because C is such an important part of what we're going to look at in application security. We're going to look at buffer overflows of C programs, all kinds of cool stuff like that. You can be familiar with C code. And the best way to do that is by writing some. So you're going to write a backdoor web server. So the idea is, once you've taken over somebody's machine, you still want access to that machine. And what is the most common type of traffic on the internet? Web traffic. Yeah, web traffic. Almost every organization allows port 80 into their network and they'll allow outgoing connection to port 80. So what we're going to write is a web server that is actually a backdoor. So your goal you're going to be creating in C a minimal HTTP 1.1 server based on the RFC. So again, this is going to help you get good at reading RFCs which are where you go to for the source of all information and knowledge from scratch. So no HTTP libraries, no libraries except for the C standard library. So this is getting back to the original days of writing code. You're going to create a program called Normal Web Server. It's not actually a normal web server. The command line interface is a normal web server and a port. So the idea is your server should listen for incoming connections on that given port and it should respond to almost all requests that we'll see with a valid HTTP 1 response of 404. So pretty much anything that sends it should just say 404 back. And so how do you know how to send a valid HTTP 404 status? Yeah, if you look in the RFC, it's all in there. And it's really important that it's a valid HTTP 1.1 because your back door will be detected otherwise. And your server shouldn't cause the client to hang or it shouldn't otherwise malfunction. So you have to make sure you're actually doing the spec properly of what you send back. You don't want the server to connect to this client who's connecting to you to wait forever. Then they may have something up with your back door functionality. So that's the standard functionality. Almost any URL they ask for or any method should be just a 404 response back. The exception is our back door. So our back door is going to be if they make specifically a get request so only a get request for a URL of some of this kind of form slash exec slash some kind of command then your server shouldn't take command which is everything after that slash and exec all the way to the URL and execute it using the system Linux system call. And the HTTP response must be the standard out of the executed command. You don't know what these things are to open up. The status code should be 200 if you use this successful request. There's no limitations on the characters inside the command. It should capture everything from slash all the way to the end of that URL request. So for some, for instances if you use slash exec slash ls that should return an HTTP response with the body of the output of the ls command. As if you had ran it from wherever directory you ran normal web server that's what the output would be. So remotely you're getting essentially a remote code execution on this machine. By making these HTTP requests we're able to execute arbitrary commands. So remotely we can do arbitrarily complicated commands in here. We can do exec slash ls what's this percent 20? That's space in URL encoded. Dash LA will return an HTTP response with the body of the output of ls space dash LA. So we adjust the same running that ls dash LA in the same directory. So this one is here. There's resources for how to do sockets in C for those that aren't familiar. But this is where you put the knowledge that was already about how networking works to the test and actually doing something that does a network server. There is an extra credit on this that's going to be very hard in terms of gzip encoding so that if the client supports gzip encoding then send the result of the command with gzip encoding. So this is where you put the library in C that's doable. Any questions on this part? You're really saying that we should assume there's no limit on the number of characters in the command including the nexus possibly but you won't have to worry about that. It would be just like as if they're typing in from the command line. No, don't worry about that. It's more about don't try to split on just slashes because you could have ls space slash that would be list out what's in the root directory. You want to actually see that result. You don't want to try to get everything from exactly the first slash. In which directory do we run? Wherever. Wherever it's run. I mean that's... Do you mean like the normal web server? When we test it, yes, when we test it we will run it and do everything all locally to make sure it works. But when you're testing it yeah, you need to... It shouldn't matter where it's located except for the fact that the commands that depend on the directory like ls will list out the current directory. So that will depend on where your server works. What should be the command that you focus on? Whatever directory is run. Web server? Uh... No. No, nothing. Oh yeah, this part here. Are you going to attempt to kill it with the Windows 1? Will I attempt to kill it? Wait, okay. Two things. A. When the server is killed, so control C or significant, the server should release the port and save the terminating. So this is good server programming. This one doesn't need to be run as root. And we'll see listening on ports above 1024 does not require root permission. So this one doesn't necessarily have to run as root. What would be executing the command in root form? No, it should execute it just as whatever user it's running as. So if you run it as root, it will execute. If you did sudo normal server, it will run as root. If you just run normal web server as a different user, it should run it whatever that user. You don't have to do anything special. I mean, yeah, don't do that. It's part of your testing. But yes, that is the functionality built in. Other questions? On to fragmentation. All right, all this is going to go to work. Yeah, okay. I'm trying to set the reason why it's taking so long because I have everything all set up. I just need to create... I want to use HTTPS this time, but it's a little bit tricky because oh, that's okay. I'll talk about that and I'll send it out. So it should be all good, but we'll see. Are you going to have test cases on this instrument that's similar to 340? No. No, you'll have to come up with your own test cases. There will be test cases on the server before... Before I had secret test cases where I wouldn't give you anything. I don't know if I'll do that this time. We'll see. Okay. So what kind of fragmentation are we talking about here? Somebody reminded us from Wednesday which feels like a neon ago. Yeah. Hacket fragmentation. So, packets are being fragmented. Why? Too big for who or what? Ethernet, the link layer. Yes, remember we saw that IP packets could be 65,000 bytes or higher than that. But the link layer Ethernet can only be 1,500 bytes. That's what happens. The idea is we need to break that packet up in the tiny fragments and then send it across. So, this is exactly what happens. So fragmentation could either be performed at the source host, so if the host knows for whatever reason the NTU, the Minimal Transmission Maximum Transmission Unit, if it knows the exact size or the most size that could possibly be sent, it can fragment there. Otherwise, any of the other routers could possibly fragment on any of their hops. And so, if, so there's a flag called Do Not Fragment, so if you're sending a packet and there's a Do Not Fragment flag set, then instead of being fragmented you'll get an ICMP error message back that says, hey, you tried to send this packet, sorry, it was too big for the network. We looked at the IP Datagram and we kind of went over this briefly but some of the things we didn't talk about, so we have the flags, so inside the flags we have bits of don't fragment, so this is what we just talked about, this would tell any router along the way, hey, do not fragment this packet. We have another field for more fragments, we'll talk about in a second. We also have the fragment offset. So if we actually can fragment a packet, this is kind of the process. So first of all, we want to send, so what are we going to be fragmenting in here? So this is the packet. The data, the problem is the data is too large. So then we have to split the data up into NTU chunks. So that's going to give us different chunks of these packets. What do we need from that? Yeah, we need to know at the other end how to put those packets back together again. So we've cut them all up. There's no guarantee that even if we send them out one after another that they'll be received in that order. These are IP packets. There's no guarantee about the delivery of the order or anything. So what I'm receiving in needs to have enough information to be able to place all the packets correctly. What else do we need? Number. We don't even know how many there are. And we need to make sure that all of these headers are exactly the same. We want to make sure that all these packets get to the correct destination. So that's what this process is going to do. So we're going to copy the datagram ID. So this datagram ID in this header is the identifier here. That's the IP identifier. That's going to make copies. So that way, the receiving end also knows that we're from the same packet. If the identifiers are different, that means it's a different packet. Even if they're also fragmented. More fragments fly set. So it's going to be one for all of the fragments except for the last fragment which will be zero. The fragment offset field tells it where in the data this should be offset. So where does this packet go when you're constructing the final packet? So where does this fragment go when you're constructing the final packet? It's a little tricky because it's expressed in 8-byte units. So one would be 8-byte offset, two would be 16-byte offset and so on. The total length field will be changed to each fragment to mask the size of the fragment and now each fragment goes on its way and gets routed and hopped in exactly the same manner as any other IP packet. Now this incurs some risk because any one of these fragments gets lost, the entire packet is gone. There's no checksum, there's no re-delivery, there's nothing. We're just trying to do our best with unreliable link layers to complete the process that we can't do. So we can see here this is a TZP trace, a TZP dump output from 128, 111, 48, 69, 2.70 and we can see that all of these these are all fragmented packets and then at the end we can see with all these packets that it's an ICMP active request so this is a ping request that we're getting here and they can come in kind of any order. So this leads to fun attacks that used to occur because now we're asking the endpoints and maybe even routers in between to do extra work. Now when you get some fragments back the operating system has to correctly reassemble those in all the right places but they don't actually know at the start whether they've gotten every fragment because it actually doesn't send a total number of fragments, what does it send? Yeah, so it uses offset so each fragment will have a different offset and then how do you know when you've got the last fragment? Yeah, zero for the more fragments. That's the only thing, so what happens if you lose that fragment? You'll never know when the end is and you have to time out and eventually throw that packet away because you've never got that final piece. How would the host know if it missed any fragments in between? Let's say it got the final one. Yeah, so it knows exactly. So if it knows the last one and it knows the offset of the last one in the packet then it knows how much data it should have gotten and it can keep track of all the fragments at every place in there and it can see if it's got all the fragments. Does it seem complicated? Yeah, it's complicated, right? It's not straightforward, it's not easy. You have to keep track of all this stuff. This should be a hint if you're ever writing a spec or you're trying to audit a spec or audit even any kind of application. Anything complicated like this, it's like Murphy's Law, Ken and Will Go Wrong and that's exactly what happened. So that's how you get different attacks like in the opinion of Dad. Where essentially what they would do is they would alter the last packet to make the operating system kernel, so it's handled on this IP reassembly, it would cause it to overflow the size of the maximum allowed packets. So it would allocate a buffer to wait for some packets that were coming in for fragmented packets and it would change the size to be really, really large and cause it to overflow that packet or overflow that packet and start overwriting kernel memory. So what would happen, a kernel panic, what happens in a kernel panic? It drops everything, it dies. It's like the Linux equivalent of a blue screen. It just dies, everything dies, you lose all the packets, right? So think about this, so somebody's on the staff, there's just a bug in here. Now what can you do just by sending a few packets? You can take down, well, a network route. I think these were end hosts, so I think these were only, I think it's probably Linux or Unix machines that were affected by this. Oh, maybe Windows too. So if you can't check out the routing infrastructure, what happens? Somebody could take down their ideas. And you can take down the ideas, you can just take down the machines. You can take down computers on the internet with just like two packets, two packets, primary packets and what do we know about IPs? Does IP guarantee where the source IP sent the packet from? No, which means what? Yeah, we can spoof other people's IP addresses when we do this attack, so nobody will know when this attack is coming from. So what this would entail is sending out a bunch of fragmented packets, and it would be such the case that the total reassembled packet from the last one, the 65, 120 plus 398 bytes would be the size of the fragment that was sent and it would be greater 658 or 655, 38, 35 just wasn't enough to cause it to crash into. And so this was an early kind of denial of service attack that caused a lot of havoc and problems on the internet. Just think about it. A few packets, like your computer just shuts down. It's kind of, it seems like, well, it doesn't seem like the equivalent of a bank if you just, like, tapped on the door like the bank would just open up. That'd be like the equivalent here. See, there's people coming to talk to you. You're not even responding to them. Just be somebody just talking to you, and you're like, oh yeah, come in. And you're like, I didn't even say anything. I just stood here. And so this is a kind of a theme that we'll see looking at all of these is a lot of the early bugs were bugs at the kernel layer IP TCP stack. Because if you found one bug in those, you could attack every operating system that was running that operating system, right? And that TCP IP stack. Which was almost all systems. Well, eventually over time the operating systems got better and better and fixed a lot of these bugs. Where now it's very difficult to get these kind of remote, just kill off of a few packets getting sent. So then we'll see where people moved up to. How do you just get access from the kernel projects? How does that give you full access to any computer? This is a little over exaggeration, but you don't actually get access, but you're shutting them down, right? So you're compromising their security by taking away their availability. So then you could call them up and ask for a rain zone. You're like, hey, it really sucks that those computers are getting taken down. You should wire some bitcoins to my bitcoin address. Maybe that'll go away. You know, that could be one way to do it. There's also other types of attacks that are similar to this that allow remote code execution. So you would be able to get onto their machines, but this is an early one that was very annoying. This is the ping of death. Ping of death. So, fragmentation is not just something that is interesting because at least these kind of weird corner cases. They actually have a lot of interesting applicability and kind of give light to some interesting security principles that we can talk about. So one key way that these can be used is essentially, so somebody talked about IDS, so an intrusion detection system, right? So one of the key ideas in security is you're always under attack. I hope you agree with that. As an organization, you're always under attack. And so you want to know when you've actually been compromised. Right? Sometimes just knowing that is difficult and so that is why you run intrusion detection systems, which look at network traffic and try to see if you've been hacked or breached. And so as an attacker, you know that the good guys are using these things. So what you really like to do is try to get around them. So what are some other, so we have IDSs or some other technologies that companies or organizations use to protect themselves and their network. What was that? Firewall. Firewall, what's a firewall? It's just a machine that sits in between usually the outside and the inside network and it has a set of rules that say nobody outside can talk to this specific internal IP address or maybe nobody out can talk to any IP import that people on the outside can talk to is this specific machine port 80. And so firewalls are a really good mechanism to try to restrict what traffic can come in. They can also be used to restrict what traffic goes out but that's a little more difficult. They don't really use so much of that. So, because there's such core security mechanisms if we're able to try to evade them like if we can launch an attack that's great for us as attackers because now we've gotten into the network and the people don't know about it. Similarly with the firewall if we can actually bypass the firewall's policies and access things we shouldn't now we can maybe use that to get a foothold into their systems. So, fragmentation comes in. Why? Why do you think that would be useful for either evasion or something like that? Yeah, maybe if you crash the firewall. If you crash a firewall, what should happen? What should happen? No traffic goes in or out. Yeah, no traffic should go in or out. We call that fail close. That means that if that machine, if the firewall fails you should have no traffic being going through because the firewall is a security mechanism and you don't want anyone to come in or out. What do you think most firewalls do if they crash? Yeah, they fail the other way, they fail open is just allow access to anyone. Why? People like availability. People like availability? Yeah, people want availability, right? Networks are being used to make them money, right? People are accessing their website. Their employees are working all day. Think about take a hundred 200 person organization the firewall goes down. That means nobody can access the internet for a couple of hours. Think about that lost productivity. A lot of organizations would say no, I want to just I want it to keep working. I don't want it to shut everything off. A lot of these things there's probably configuration mode but a lot of them will fail open, unfortunately. You can use a deny service maybe it's a firewall to try to get it to crash. Maybe using the ping of death thing. What else? You gotta think, like IDS is listening to all traffic coming into the organization. So can we like evade it by going around it and going into some other route into the organization? That's a good one. I want to go back to the invasion idea. Can you force your traffic to go another route not through their IDS or firewall? You could tap it. So we're not moving. But can you force your traffic to go another route? Proxy change? Proxy change? Of what though? You're on the outside. You can't touch their network, right? If you touch their network everything becomes a lot easier. But as soon as you're completely on the outside VPN pretend to be on the local network? Depends on the firewall setup but hopefully not. So fundamentally we have to think they control their network right? You have to assume there's some level of competency which is that all incoming traffic is going to go through the IDS or the firewall. So you can't evade it by trying to go some other route because that route doesn't exist. The organization has set it up they just like you at home have an ISP that they're buying their internet from and so they can set it up very easy and physically such that all traffic goes through that firewall and that intrusion detection system. So when you're talking about evasion we can't think like oh we'll somehow just get it around there if we're just on the outside. So then what would that mean? What was that? Impersonating a familiar IP address. We can try impersonating a familiar IP address. Yeah that could work hopefully would not work depending. Yeah we can do that. Yeah we want our IDS listening to everything right so we'll put it right on the edge. Right on the edge yeah. We could fragment the packets in a way such that the IDS would not detect them. Why would it not detect it? It wouldn't notice some malicious pattern. What does the intrusion detection system have to do? Port of the packets. So it has to listen to all the packets coming across. So we're going to make a decision whether a packet is good or bad when it gets everything. Right? So who wrote the IDS? I'll just make something up. It's not a guess what's in my life situation. Is there security? Yeah some security company right let's say they're using I don't know, well BFD is bad. We'll say they're using like Linux or something right whatever whatever they're using networking layer there right and let's say our servers and our systems are Windows. Are those the same IP TZP layers? Are they? They were written by the same people. Linux IP layer is the same as Windows. Should be following the same standard. It should be following the same standard but who is the code written by? Different companies. Different organizations right? There may be different and subtle bugs that can happen in each different operating system and essentially you can exploit those differences in order to cause let's say the IDS to disregard your traffic but that packet actually gets through to the host machine. So for instance what happens if you overlap some of the fragments? What happens? Right? Does... the spec doesn't say anything about that right about what to do but you're an OS writer and maybe you don't it's just a byproduct of how your code's written right? Do you ignore the... so you have a first packet coming in you have a second packet that overlaps do you keep the first packet and then attend whatever was after it do you actually just paste over and now the middle of that packet becomes packet 2 or do you reject this fragment and say no I'm not going to do any overlapping packets right? None of this is correct which means that if the machine I'm targeting and the intrusion detection system diverge they will see two different truths as to what this packet is and so I can use that by hiding my malicious that's kind of what we mean by evasion right? We can make the IDS think that it's saying something different than a host machine is actually seeing and so you can play all kinds of games with this. This will be another thing so for firewalls specifically they are sitting so an intrusion detection system is just listening right? It's sniffing everything that's going on the network a firewall is sitting in between inside and outside it has to decide when to let things go so it gets the first packet of a fragment does it send it on does it wait or how does it decide right? A lot of times they'll use TCP or port information but you can kind of arbitrarily size fragments so you can make a really tiny fragment that only has part of the TCP header and then the firewall has to decide so what if it just hangs on to that packet and waits to try to reassemble it then what would happen? It'd be slow what else? You don't know how it's going to reassemble it it may reassemble it differently what if we send a bunch of different fragmented packets but never send the end packet it's going to just keep on waiting it'll keep on waiting and it'll keep allocating memory waiting and waiting and waiting for these packets and so maybe we can overload the firewall and get it to fail over then just cause it to crash that way so that's what we said so we can send our IP packet it's going to be either a TCP or a UTPacket so if we send only the first few bytes of there that doesn't necessarily give the firewall enough information to make a decision and so it depends on how they've written that we can change different packets to try to get the first one through we can try to do overwriting by what we said of trying overlocking packets what happens when we overlock packets in some cases we may with overwriting be able to change the source and destination packet so now you make a packet comes in and you say yeah this is great send it on and another packet comes in that actually overwrites part of that and changes the destination port that you were talking to so you essentially desync the view of this packet from your security device and the host machine so again we're going to go to IDS IDS for performance reasons just like you said may not reassemble the packet right because then it has to do the same thing and try to keep all of maybe hack open packets or half of the packets open we can maybe build like we said denialist of service impact by trying to force either a firewall or an IDS to allocate more memory than it has by sending a bunch of half finished packets and trying to see where that gets us to force the system to use a large amount of memory so this is kind of a really cool security idea and hack idea that comes up in different contexts is how do you if you have two systems right and they're maybe talking the same protocol but it's not exactly the same code that's running maybe you can exploit differences between the two to cause different behavior you seem to have something in mind in the difference between the two do you know of particular difference between the two and how they analyze the packet? yes they're different so there's actually a tool I think we'll get back to we'll get to it when we kind of finish all the networking stuff but NMAP is a network awesome networking tool it has an option to do OS fingerprinting and so what it'll do there's parts of the spec on TZP UDP TZP IP UDP there's like corner cases that aren't well specified and so each operating system does it differently and so there's a program that's compiled that that will do network tests remotely to try to determine what operating system is running on that computer so yeah there's actually a lot of different some of them are we haven't gotten to TCP but what happens if you send a TCP reset packet to a connection that you haven't even started yet do you do nothing or do you respond and say like go away those are things that aren't specified in the spec but you could do whatever you want same things I don't know there's all kinds of weird differences like what happens if you're talking and then I say I want to stop talking and then I start talking again like what do you do do you kill it do you how do you respond so using that they're able to fingerprint all these tiny differences and they can actually be very accurate ICMP okay so we finally get a look at this ping protocol part that we've been using so the idea basically behind ICMP is okay we're starting to build these complicated networks and with the link layer these are basically machines that are local to us right they're on our local sub network with IP now we're talking to remote machines that are multiple hops away our packets are traversing across networks that we don't control and that are owned and used by who knows what and so ICMP is kind of like the debugging protocol of IP so this allows us to say things like for instance if we set the don't fragment don't fragment it on a packet the if a router needs to fragment that packet it will send us an ICMP message that says hey sorry I couldn't you know your packet was lost because I had it right so in exchange there's control messages error messages they're inside the IP diagram so it's specific flag in the IP header that says this is actually an ICMP message they can be either requests where you're trying to get something from somebody else responses where you're responding to somebody's request or error messages right so this is when a computer can say hey sorry we also saw another one we saw a host down or no route to host so if you actually try this if you take a computer start pinging some remote IP address or I'd like google.com or something and then you go to your let's say your cable mode and just unplug it you should start getting error messages back that say hey you're here and that should go out otherwise you have a magical network B you should get ICMP messages back from your router saying hey there's no route to get the packet out sorry and so it'll actually send you an error message that will include the header and a portion of the payload 8 bytes of the defending IP diagram so that your system can actually try to figure out what packet sent this error message form is pretty simple we have a type a code to check some and the data so pretty easy this is also a good design principle if you're trying to make something that's used for errors or debugging you should make it very simple right you don't want there to be errors in your error what happens if one of these ICMP fails right you should get a spiral of variables okay there are lots of different types of messages these are all old not really used I have never seen any of these before echo request and reply these are kind of the brand and model of what ICMP is used for it's basically used to test connectivity right the idea is you send an ICMP packet to a destination IP and you request and say hey are you alive and then they will listen for that if their computer is configured to respond they will say yes I'm alive and send you an ICMP reply echo reply back and you'll get a packet back this is a super useful if you've ever done an app release we have this crazy issue in our lab where the students will be using our lab network and trying to SSH to our servers and then their connections will just drop and then all of a sudden it seems to be working so I'm going to just script to every I think 10 seconds paying local IPs inside ASU and outside to Google and other things and then I did a graph and you can see like every 30 seconds the network would just drop and then magically go back up 30 minutes oh no not 30 seconds 30 minutes 30 minutes off 30 minutes on 30 minutes off 30 minutes on it was insane and did you figure out the problem? no no what they did is they moved our network because in ASU we're all in all the virtual networks so they moved our network around until it stopped was basically the answer what was my deal though actually it proved that it was a problem time exceeded so that's an important one that's going to come up what happens if that TTL value reaches zero why do we want something to know when that happens yeah so we can do something about it right so maybe we can maybe we can maybe there's a loop somewhere else but hey if nobody knows about it then not good redirect message so you're trying to send traffic to a host that's not actually a gateway if they can't go anywhere else they may actually try to redirect you somewhere else and say hey you should actually talk to this other host instead we set destination on reachable so that's when we can't get our packet there so let's look a little more deeply at the echo request or reply so used by the pain program things awesome the type is going to be either zero or eight where one responds to a request or a reply the code is zero it will have some identifier why is that identifier important what was that yeah so we're going to send we're going to ask you hey are you alive and you're going to say yes I'm alive but how do I know that you actually responded to my specific message right so I'll generate some identifier and that way you'll send that identifier back to me so I'll know you actually got it there there's a sequence number two so you can actually ping and increase a sequence number from zero all the way to how many devices and you can even send data if you send data you're asking the other side to actually send you that data back and so this way you can verify that what you sent on the network is what you actually get back so that the other side read what you sent so you ping super fun so they get nice so this is I'm pinging 129.168.1.1 and I'm from 192.168.1.100 and it's saying ping is automatically putting in some data in there to see what gets back 64 bytes of data so we can see here where are some interesting things that we can see here yeah so we can see so we know if we sent 7 packets we got 7 packets back because of the sequence number this means we did not lose any packets because this is IP we're just trying to send stuff there's no guarantee that we actually never get anything back we also get the time so the time is interesting this is if you're ever trying to debug weird network jitter problems or trying to see how fast your internet is ping can be kind of a useful baseline to try to see how many seconds it's taking what is this time exactly yeah round trip time right this is the time from when you sent it to the other machine they got it and sent it back to you you also have a TTL value which is interesting and it will give you some very basic statistics so you can kind of try to measure the network jitter it's also fun because it led to a lot of attacks which seems silly because this is a very easy protocol you send a request you get a reply right so one thing I don't think I need my how do you break into a bank speech yet how do you break into a bank that you've learned from movies what's the first step the first step is you assemble a team you've always missed that step that's going to montage for them what's the next step so you've got your team you plan what's part of planning getaway vehicle getaway vehicle maps so you try to get maps why do you need maps yeah you want to try to plan a route what else do you do do you just stay in your little like secret layer and plan everything what was that assign activities okay good what does that mean yeah so you're going casing the joint that's like the slime right you go where disguises and you pretend to eat across the street while you observe the bank and you see who's going in and out you're trying to look for when are the security officers get there what time do they get off when do they change shifts and you may do this for several days for maybe weeks even so that you know the habits of the people in the bank oh this guard always goes around the corner for a smoke break at three o'clock and that'll give you an in there right so all these things tie right the importance of reconnaissance right you need to know understand the layout of whatever you're trying to attack or break into right so here we have a mechanism where you can ask any IP address hey are you alive could that be useful for reconnaissance yeah so one of the you know the simplest attacks you know this is called a pain scan or an IP sweep you get it so assuming you're in a local network you don't know anything about it you do know you're on a local network so you know your subnet that means you can iterate over all IP addresses in your subnet and just try pinging every single one and then when you get back will be some legit IP addresses unless they're running a reflector in which case they'll get one more than they think so you just send echo of diagrams to everyone in the host you collect the approaches and try to see who's alive so nmap is a tool that we'll talk about in a good amount this is another tool you have to be careful with um you want to again only run this on your local network with machines that you own because you know you're trying to just trying to ping every machine in the network A that's very noisy and B it's not really a great networking neighbor style thing to do unethical I mean you can have that discussion that's kind of a more difficult question but you're getting to gray territory so you can run this and it would tell you you have to specifically configure how you want it to run and then you want an IP scan nmap is actually an incredibly complicated tool which has lots of different options you can look it all up but yeah you can scan for local IPs on your local network to see who all is there we can also perform a super cool what you used to be able to perform a very cool denial of service attack which also has a really cool name of SMURF so this is one of the first kind of leverage based denial of service attacks so the other one we saw was just exploiting a kernel basically buffer overflow that caused the kernel to crash so they're going to need two packets essentially to take out the computer with the SMURF attack the SMURF attack was different it actually used the concept of leverage for denial of service so first of all what is denial of service more broad than that bringing down the availability of a system you could do it in a lot of different ways you could just cut the cord to the computer that would definitely be a denial of service attack but we want to look at most of the ways it's done now is sending too many packets to one machine to try to get it so that it can't respond to normal requests and taking off the availability that way so I have my machine let's say at home, hypothetically I have this machine at home can I just launch a denial of service attack at google.com do you think they even bother like like they only let you send a certain amount of traffic over an example even just IP, what if I just send like a ton of ICMP can I ping google.com you can do that in your command line you can ping google.com I can ping them a lot and keep pinging them they can take so much, they take so many pings they don't really care that you ping them more so I can go up the bandwidth think about my little ISP that I'm paying for some amount of traffic and think about googles it probably wouldn't even fit in this room if we're doing it by scale of my original one right and so how can I possibly with my machine generate enough packets and enough bandwidth to actually affect that all google.com the short answer is I really can't do that myself because I'm limited to my bandwidth so all the dinosaurs that I'm going to look at need some leverage so basically if I send one packet and google gets one packet that means I have to have more bandwidth than google to take them down that is never going to happen right but if I can cause it to where I send one packet and google gets 10 packets or 20 packets or 100 packets now we're talking and now maybe I have enough leverage and google's a very large target so maybe we narrow it down in scope to a small medium sized business they're a business ISP I don't have much more traffic than them but if I can generate use my traffic to cause 10 times as much traffic come to them now I can actually perform some kind of attack so this is the concept behind the service attract it's all about leverage because the attacker on their own by themselves can't get more bandwidth they have as much bandwidth as they can pay for and then the other side the company can pay for as much bandwidth they have the same way of buying bandwidth so let's look at the smurf attack we'll see how that averages this so there's some subnetwork 192.168.1 168.2 111.10.20 and there's this machine here that we want to take off the network so our goal right now is attackers is to denial of service 128.111.41.10 that's our goal we're attackers here so what we're going to do we're going to leverage two things one, did I talk about broadcast addresses? okay so on your local network so we talked about subnets so if you want to broadcast a packet on this subnet you would send a packet to 168.1.255 so the local area all one that's always the broadcast address of the local network and that means that that packet should get sent to everyone on the network it was useful for all kinds of things and it was fairly standard so it leverages this feature that a packet sent to a broadcast address will get sent to all those addresses and it leverages another very simple feature that we know about from IP packets we're talking about ICMP so this means that what can we make guarantees on the source IP? the attacker can put whatever source address they want to be so think about using our example can I just send a bunch of pings to this guy? I could but I don't get any leverage there for every one packet I send one packet goes to the attacker here to the victim that's not any good but what if I was able to send so let's think about this what would happen if I send an IP packet to the broadcast address of this subnet every single one of these machines and then let's enter a ping packet who are they going to respond to? the source do I want to respond to me? no I want to respond to the victim so I can create packets from spoof the source IP have them pretend to be from this victim send it to this broadcast address on this subnet is every single machine on that network will respond to that that will send out a bunch of packets but maybe that's not enough so here in this little example I've got 1, 2, 3, 4, 5 I've got 1, 2, 3, 4 I've multiplied my packet by 4 my number of packets now I can send one more to 192.168.2.2 by 5 and they'll all send packets back there and the same thing with the other network and there's all send a bunch of packets back there so now I'm using this broadcast ability and the fact that they'll reply back to this source IP to get leverage and to be able to generate so many packets and take this machine off the network how do you prevent that machine from going off the network? with this attack you have to fix this broadcast capability so they change it to where if you're not on the local network you can't broadcast you're external trying to send it to the local network that's server buddy you can't can't you just redirect all that traffic to that server? I mean if you can identify that traffic but you could filter it up top but this was back further before we knew how to do that easily and nicely are these attacks still done? they don't work anymore because they fix this broadcast capability but you can still spoof source IP addresses right? so if you somehow inserted yourself into the local network it's a good question I don't know off the top of my head somebody should look at broadcast in IP to see if it's still done probably so like you could do it from the internet but we don't know if you should do it but you're saying like that could be a problem from broadcast well the other thing is you're limited on your local network to how much bandwidth your local network has so that would be the other thing even if you're able to get all of them to do that the fact is that's not distributed throughout the internet that's the important thing here we have three networks here and they all have different bandwidths so it's going to be added in as long as you saturate that bandwidth you can't send anymore as this happens when you do like a bot on someone's computer sort of they can like ping all the local area networks and they can also do the same attack after that's why I think it probably doesn't work I don't think ICMP or maybe they changed the host so that they won't respond to a broadcast ping that may be the thing they'll only respond to ping's record in their IP address I think that would make more sense if we can hey, hey still going five more minutes if a firewall is to the server and if somehow the firewall can give the maybe the package just a ping then it can avoid this type of attack so this is similar to the other question so if if we put a firewall in front of this and then dropped all ICMP packets then maybe the server stays up but can anybody access us because we still have all of our bandwidth being used by these ping packets so there's different levels of denial of service they're sending so many packets that literally the kernel of the machine cannot keep up with it and starts dropping packets that a router or a switch in here can't handle it and starts dropping packets then there's you're sending so much traffic that your link layer is saturated and your ethernet literally can't send any more packets or there's your ISP can't even send you that many traffic so yeah, you need to get your IP to kind of redirect that your ISP to redirect that traffic to somewhere else not to you so that that way you still get traffic yeah, that's the kind of a key a key problem with these things good question can you explain how like Cloudflare and companies like them might prevent my work with this or just let it just absorb all of it yeah, I know they basically Cloudshare and the other one is Akamai which is like the super paid version of Cloudflare they basically have servers in every single ISP and they will essentially they do it like part of their trick is they don't ever tell you who the real source IP website that you're talking to is so if you try to go to a Cloudflare IP you get IP addresses that are Cloudflare boxes and then when you talk to them you're saying hey I'm trying to get to foobar.com and they'll look in their local cache and say yeah, here it is and so you never actually talk to that foobar.com so with enough of these servers and bandwidth now essentially Cloudflare is growing their pipes so big that no one person can take down just one server object that's at a high level cool, alright, we'll continue