 So, welcome to the third session of the third day. This is about network security proper, non-cryptographic protocol vulnerabilities. So, a recurring theme in this workshop is whatever we design, hardware, software, procedures, etcetera, policies, we need to know what are our vulnerabilities. So, once we know our weaknesses, they cease to do us any harm. Protocol vulnerabilities. As mentioned before, in almost any networking protocol you can think of, there are a score of vulnerabilities. For example, Ethernet 802.11, ARP at the lowest, MAC layer and data link layer, IP, ICMP, TCP, UDP, DNS, etcetera. The vulnerability may be in the protocol itself, in the design of the protocol or it may be in the implementation of the protocol. Either way, we need to identify it and see what can be done to get around that vulnerability. If it is in the design, it may not be very easy to solve it, but if it is in the implementation at least, we can handle it. So, one of the most well-known vulnerabilities and which still causes problems 10 years when it, 10 years from the date it actually manifested itself, 10 or 15 years is DOS, Denial of Service. So, the different types of these things, they are protocol based and they are also application based DOS. SIN flooding, UDP based SMERF attacks. So, let us take a look at some of these. The SIN flood. An attacker sends thousands of TCP packets to the victim with a SIN flag set. The victim thinks that these are legitimate requests for TCP connection establishment that is the first message of the three-way handshake. And in response to each message, the victim reserves some amount of buffer space, eventually the victim's communication link and or memory are exhausted. So, here is the picture of the three-way handshake. The SIN flag set in the first packet with the sequence number set to X. In the second packet, the SIN flags and the ACT flags in the TCP header are set to 1. And a random number is chosen for the sequence number in the second message and the acknowledgement number is X plus 1. And then in the third packet, the ACT flag is set and the acknowledgement number is Y plus 1. So, this is the typical three-way handshake. Now, how do we subvert the working of the system? In other words, how do we launch a DOS or a DDoS attack? So, here is the attacker. So, the typical strategy is to send these SIN packets to flood the victim with SIN packets. So, there is the attacker and the victim, flood them with SIN packets. But the interesting thing is that almost typically, he will use spoofed addresses. So, he cannot be traced. And then he will respond to that first SIN packet with an acknowledgment packet. But because the source address has been, the source address in these packets has been spoofed, those acknowledgments will go to some arbitrary location, not back to the source of the attacker. So, eventually in this scheme, either he will run out of space, the amount of buffers that have been reserved for TCP packets, or he will run out of computational power, or he will run out of communication bandwidth, assuming that a sufficient number of these packets hits him. Just like in SIN flooding, you also can subvert UDP. An attacker sends a large number of UDP packets to non-listening ports on the victim. This causes the victim to process each of those packets and respond with an ICMP forced, unreachable message for each packet that it receives. So once again, communication bandwidth, once again, computational power that is uselessly wasted. Another attack, a smurf attack, this time not UDP, but ICMP. An attacker sends a very large number of ICMP echo request messages to the victim's network. So, he cleverly does the following. The destination IP address of these packets is a special broadcast address of the network. While the source IP address is the address of the victim. So, everybody in the network receives these packets and thinks that there's an echo request from the victim. So, what they do is they send an echo response. So, this causes the victim to be inundated with echo reply messages from each host on its network. So, all of a sudden, the victim finds it's receiving many, many packets. It's unable to process them, and it definitely slows it down if not crashing the system to some extent. Now, you can make all of these attacks much worse by the typical DDoS packet. So, we've talked about in the morning some kind of a botnet. So, you can think of this as being, so actually DDoS preceded botnets. You can think of this as being the botnet controller, and these have been the hosts and the zombies, the handlers and the zombies and so on and so forth. So, you can multiply the effect of DDoS by using distributed denial of service. So, as you can well imagine, over each of these zombies is bombarding this guy. You're going to have a sort of pulsed attack or a phased attack, but this guy bombards for some time. Then this guy takes over, and this guy takes over, and so on and so forth, in more or less a random fashion so that you can't catch who's the guy who's actually bombarding him. So, he just bombards a little bit. By the time you've caught him, somebody else has taken over. You catch this guy, somebody else has taken over, and so on and so forth. So, it's very difficult to find out who is the brain behind this attack, or even who are the zombies behind this attack, because they're not flooding all the time. The flooding is distributed amongst many of these zombies. So, sin flooding is an example of DDoS caused by a vulnerability in TCP, the possible abuse of the three-way handshake. Basically, all those three messages are unauthenticated. If I knew exactly who was sending them, I would be more careful, but unfortunately, that's not implemented in the original TCP. So, the attack of floods, the victim with sin requests, the source IP address is typically spoofed. So, these are some of the typical features of a DDoS attack, a simple attack. There are multiple attack sources. The victim reserves buffer space, say about 4K or so, for each request that it receives. Memory and bandwidth exhaustion, also computational resources, could be consumed. So, let us see how severe this problem is, in terms of some simple parameters, L is the communication bandwidth of the victim's link, B is the maximum number of buffers reserved for TCP connections, T is the maximum amount of time that a buffer can be reserved for a half-open TCP connection. So, typically, what will happen, as you know, is that when you receive a request, you will send a response, and if you don't receive the third message, you will keep that connection what's called half-open. And you might resend that first message in the hope that you will get back finally, you will resend the message, the second message, in the hope that you will get the third message back. So, let's go to this picture. So, I'm sitting over here, I'm the victim, I get this request, I send this response, I don't receive anything. So, I think this message has gotten lost along the way. So, I'll resend it, resend it, resend it, and eventually I'll time out completely. So, after I time out, I'll resend it, and after a certain number of retries, I'll completely give up. So, that's the way this thing works. But in the meanwhile, I've reserved buffer space over here, and there are several such requests coming. So, in the end, I might actually exhaust the buffer space. So, once again, the parameters, the communication bandwidth at the victim's link, the maximum number of buffers reserved for TCP connections, the maximum amount of time that a buffer can be reserved for a half-open TCP connection, the aggregate rate at which the victim receives SIN attack packets from various attack sources. And finally, the SIN packet, SIN attack packet size. So, in terms of these, let us see what are the conditions for saturating the communicating link and saturating the memory. So, let's just put down these parameters again. Communication bandwidth and bits per second. So, what's the condition for saturating the communication link? Simple algebraic equation over here. Not enough communication capacity. What's the rest of this? Basic model, R into P. So, the rate of, the aggregate rate of packets coming in and bombarding this victim, multiply by the packet size and bits. And what about memory exhaustion? You can use something called Little's Law, which is very useful in communications and in networking. How many of you have heard of Little's Law? Very, very useful law. Sorry? N equal to lambda T. Yes. So, what is N and what is lambda and so on here? Lambda is the arrival rate. Yes, so, give me this side. N is the, in terms of this thing. I would like to use Little's Law in different contexts. So, let me use it over here. So, let me just tell you this Little's Law because it's been very useful to many people. So, you've got a communication network. You've got various switches over here in the communication network, switches, routers, et cetera. You've got different buffers in these switches. You can throw a boundary anywhere you want. A boundary around the switch, around a single buffer, around the entire subnet, wherever you want. And the rule is very, very good. What it states is that the average time a packet spends over here, multiplied by the aggregate rate is equal to the average fill in the blanks, the average number in the system. So, if you just take the average number of packets inside this thing, you take the average amount of time each packet spends inside this, and you take the arrival rate into this. They are related by this equation. It's a very, very fundamental relationship. And the interesting thing is it doesn't depend on the statistics of the arrival rate. It doesn't say, for example, that arrivals have to be poisson. It can be just anything. This thing will still hold. So, if I use this in this context, then I will get B. So, this is a condition for memory saturation or memory exhaustion. There's not enough memory buffers over there to hold all these incoming requests. This law is known as Little's Law, L-I-T-T-L-E. Little's Law, and you'll see it in most, if you've seen computer networks by Gallagher, for example, it's a rather mathematical textbook. You will see frequent use of this thing in queuing theory and so on and so forth. So then, what are the advances, what are the challenges in handling DOS and DDoS? So, as before, whenever we talk about intrusion detection, some of the fundamental ideas are prevention, detection, response to the attack, and trace back. Who is responsible for starting this attack? So, can DDoS and all its manifestations always be prevented? So, let's talk about some prevention strategies. How can it be detected? What is the response to this attack? And how effective are these responses? And trace back using various strategies like packet marking, packet logging, or some hybrid of the two. Okay, so we'll talk about these handling of DDoS in the next session on IDS and so on. Let's move on to another protocol which can be, and I'm sure many of you are familiar with this, another protocol that can be abused is ARP. So, ARP spoofing, ARP cache poisoning. This exploits certain features in the ARP protocol, address resolution protocol, leads to ARP cache poisoning, and the result is, it could result in an MIM attack, man in the middle attack, session hijacking, et cetera. So, once again, what is the vulnerability? First and foremost, what is ARP in one slide? Used to resolve an IP address to a MAC address. So, every single machine out there in the net will have a cache, ARP cache, that stores these translations, translation from an IP address to a MAC address. If a station A needs to send a packet to B, it is not sufficient that A merely knows the IP address of B. A should also know B's MAC address. For this purpose, if A doesn't know B's MAC address, then A broadcasts an ARP query. Notice the word broadcasts, everybody listens. I say, does anybody know what is A's MAC address? I'm giving you A's IP. What is the corresponding MAC address? A station that has or knows B's MAC address responds directly, not broadcast, but typically responds directly to A. So, that's the way the standard protocol works. If address MAC address translations are cached by each station in its ARP cache. So, IP address, MAC address translations are cached by each station in its ARP cache. ARP cache entries have a lifetime. So, they turn stale after a while. So, stations periodically send out ARP requests to update their cache entries. Any node X may send an unsolicited reply to a node A. So, this is part of the vulnerability. Now, just watch, this is a feature that somebody is going to abuse. Any node X may send an unsolicited reply to a node A regarding the MAC address of an arbitrary node B. This feature of ARP is referred to as gratuitous ARP. Gratuitous means free, basically. Gratuitous ARP is a serious vulnerability. So, anybody can just say, say I am X, I can say that A is MAC address, I can tell B that A is MAC address is this thing. And he's supposed to believe it. So, unauthenticated. So, how do we exploit this feature? So, consider an attacker X with IP address capital X and MAC address little X. X sends an unsolicited ARP response message to A, stating that B's MAC address is little X. So, now you're getting the hang of this attack. So, this is going to poison the ARP cache of A. We call this ARP cache poisoning. X also sends an unsolicited ARP response message to B, stating that A's MAC address is little X. The unsolicited responses of X have created fake entries in the ARP caches of A and B. We say that their caches have been poisoned. So, the best way to understand the attack is through a little picture. So, I marked all the different messages. I've tagged them with times. The first message, the second, and so on. So, the attacker is X. The two victims are A and B. What does this thing achieve? So, the first message, the attacker tells A that B's MAC address is little X. Little X is X's MAC address. Same thing he does to B. He tells B that A's MAC address is little X. Then in the third message now, imagine, so after some time, A wants to communicate with B. So, A trusts X and A sends a packet with the source address himself, A, the destination address B, and the MAC address corresponding to B's IP address has been put as X because he's updated his ARP cache. So, if he sends it this way, then it's delivered to, say the switch, for example, the ethernet switch in the network, will deliver it to X. Then what does X do? X can now inspect the packet if it's not encrypted. He can even modify the content, and then he sends it to B. So, he sends it in message number three prime. The same packet, maybe with some modification, source address is A, destination address is B, and he puts the correct MAC address of B. So, that's message three prime. So, B sees it, and then he responds in message number four. Once again, he wants to send a message to A, so the source address is B, the destination IP address is A, but the MAC address is little X. So, once again, the attacker X is able to intercept that packet, read it, possibly modify it, and then send it to A. So, this is a standard man-in-the-middle attack using ARP spoofing. So, what are the vulnerabilities? What are the defenses? The usual questions. So, possible solutions and defenses to ARP spoofing. Disallow these gratuitous ARP replies. That's one possibility. So, you'll have to modify the protocol for this. Allow only authenticated ARP replies. This may require PKI or Kerberos support. So, once again, you'll have to modify the protocol and add lots of overhead. Use static ARP caches which ignore updates and by random machines. But again, every single entry has a lifetime. So, this is not a very practical alternative. Finally, use intelligent switches. So, this is probably the best bet that we have using intelligent switches, which learn which MAC address and IP address are mapped to which switch port and they monitor IP address. So, if you see something coming from a strange port which you have not seen before, just raise an alert in the IDS. Monitor IP address, MAC address pairings, and ethernet frames, and an ARP replies, and check for any inconsistencies. So, do some kind of learning using AI and check for inconsistency with what has been learned by the switch. So, there are switches that are intelligent and that can help prevent against these ARP spoofing attacks. So, just like you have attacks on ARP, you also have attacks on DNS because that's the same thing. You have mappings between URLs or domain names and IP addresses. Some of the worst kinds of problems can occur with LANs. A LAN assumes what is a MAC, medium access control, that assumes that everybody is going to behave properly. But what if some guys start to misbehave? So, an ethernet and wireless LANs that are well-defined rules governing when a node should talk, how nodes should handle collisions, et cetera, et cetera. Can anyone elaborate upon that in either ethernet or 802.11? What is the right protocol? CSMA CD. So, what happens? Can I just broadcast anytime I want to? What should I do? There is some etiquette, right? What should I do? I listen to the medium. If nobody's sending anything, then I can send. Now, as I send, I continue to listen. I'm talking about CSMA CD. I continue to listen. If I hear any collision, then what do I do? I back off, then I wait a random period, binary, exponential, back off, and so on and so forth. So, all of these things I should follow. If we all follow these rules, then things will be fine. But if one guy even misbehaves, there could be a lot of havoc on the network. So, you can see how this protocol can be terribly subverted with terrible consequences. The smooth functioning of these networks depends on the stations on the land, strictly obeying the MAC rules. So, there are many tools that can actually hack into things like wireless lands and so on. So, there are rules governing when any node may transmit after sensing a collision or rules related in the wireless LAN case, rules related to interframe spacing. If these rules are violated, stations of the land will seek garbled messages and almost nobody will be able to talk. Frames may also be spoofed, leading to, for example, premature disconnection of communicating parties on an 802.11 LAN. I think the frame for that is deauthentication or deassociation. If you just send that frame, then the communication between A and B. You send it to A. A thinks that B doesn't want to continue talking and stops talking. So, there are several examples of this in the book. So, that's the basic part of network security. It's going to be complemented with some of the demos that we have. So, as I said, some of the demos are Nmap, Nessus, and then in the next session, it's going to be Snot. After the next session is over, what we will do is you can come. After the next session is over, what we will do is, it's very important that when you go back to your colleges, if you haven't already started using Snot and Nessus and so on, then you get used to this. So, we will entertain any questions about installing these on your machine and getting it to work. So, there were some suggestions for people in the audience about how best to bundle all these products and download it onto your servers. So, we'll talk about that. And by the time this next 10-day workshop starts, I think most of you over here who are going to host another 50 faculty in your institutes should get ready with having learned this thing and telling them how to install the software. Because a very important part of a security course is actually implementing all these things. There are several attack tools that people have implemented also for ARP spoofing and all, but we're not showing you all of those. We're not asking you to implement any of those for obvious reasons. What you can do is you can just take a small set of three students in your college and ask them to get started on something like this. Those that you trust, because as somebody was mentioning in the audience, ethics is a very important issue. If you have some tools to do ARP spoofing and vulnerability testing and so on and so forth, there's no end to the kind of trouble that you can create. So, don't give it to all of your students. Give it to only selected students that you can trust. And of course, you yourselves get familiar so you can teach the next 50 people who are going to come to your college in July.