 So, welcome everybody to session 1 of day 6, there are two talks today in the morning, the first is by me and the second is on database security by professor Sudarshan that is the talk that begins at 11.30. So, let us now talk about protocol vulnerabilities. So, this is hardcore network security and we also have two demos associated with this presentation. The first is on Nmap and the second is on Nessus. So, we need to understand what are the vulnerabilities in different networking protocols. So, this is a little different from the vulnerabilities in the protocols we had discussed earlier. So, if you recall we had various security protocols. So, another word for security protocols are cryptographic protocols things like SSL, IPsec, Kerberos, Needham Schroeder, the various authentication protocols for wireless communications in cell phones and wireless LANs etcetera. So, those were really cryptographic protocols and there were various vulnerabilities in those protocols such as the replay attack or the parallel session attack or the man in the middle attack and so on and so forth. Today's session is a little bit different it is on regular protocols that you are very well familiar with TCP, IP, ARP, DNS etcetera etcetera. So, almost all of these protocols has some vulnerability or the other it does not appear to be a vulnerability, but if you look close and hard you will find it and the goal is to try and see how we can exploit it and later on in tomorrow's session how we can defend against some of those attacks. So, let us get back to the slides. So, this is an important saying over here once we know our weaknesses they cease to do us any harm. So, we should know the vulnerabilities in these networking protocols both in the design of the protocol as well as in the implementation of the protocol. So, let us look at some of these vulnerabilities. As I mentioned there are vulnerabilities almost across the spectrum the 7 layer stack starting from ethernet 802.11 and ARP, IP and ICMP, TCP, UDP, DNS etcetera etcetera. One point is the vulnerability may be in the protocol itself it may be in the implementation of the protocol. So, the software that implements the protocol might for example, have a buffer overflow vulnerability. One of the most well known such attacks is the denial of service attack and there are various manifestations of it. One set of denial of service attacks is due to certain attributes of various protocols and another application based denial of service attacks. So, here we are going to focus on protocol based denial of service attacks and various protocols might actually be the cause of this. For one thing the TCP protocol may be exploited to create what is called a sin flooding attack or you might have exploitation of the UDP protocol for UDP based denial of service or even an ICMP based denial of service. So, we will look briefly at some of these. So, first a sin flood an attacker sends thousands of TCP packets to the victim with a sin flood a sin flag set. So, the intention appears to be to establish a connection. So, to establish a connection as we all know in TCP because TCP is connection oriented there is a three way handshake. So, the first packet is a packet with a sin flag set, the second packet is from the recipient to the initiator with the sin and act flag set and the third packet is just with the act flag set. So, an attacker sends thousands of TCP packets to the victim with a sin flag set. The victim innocently thinks that these are legitimate requests for TCP connection establishment that is to say the first message in the TCP three way handshake. Now, in response to each message the victim reserves buffer space eventually the victim's communication link and or memory are exhausted or perhaps even the computational capability. So, the victim are seriously crippled because of the flood of sin packets. So, to review this is the three way handshake the initiator and the responder. The first packet is the sin is with the sin flag set there are six TCP flags sin fin reset etcetera. The first one has the sin flag set and it has some value in the sequence number field some random value it is supposed to be random random value set in this set in the sequence field. So, let us say that value is x what is the responder do he sends a response message with the sin flag set and the act flag set. He acknowledges the receipt of this packet by setting the acknowledgement field. So, there is an acknowledgement flag and there is an acknowledgement field. So, that acknowledgement field is set to be x plus 1. So, x plus 1 is over here and then he also randomly sends one value y. So, both these values x and y are random and the actual random number generator is decided by the operating system. So, this is an operating system a dependent implementation issue what are those random values x and y. And then the initiator response with the third message saying I have received your acknowledgement and now let us start to talk let us start to send and exchange data. So, it sends the third message now only with the act flag set the first one was only the sin flag set the second one was both sin and act flag set. And the third one is only the act flag set and the value in the acknowledgement field will be y plus 1. So, I have received your message with sequence number y and now I am acknowledging it and saying that I am ready to receive y plus 1. So, this is a very standard three way handshake which most of you are familiar with in a computer networks course. Now, let us see what opportunities exist for attacking or exploiting some of these. So, one possibility is the attacker sits down over here the victim is over here there is a single attacker single victim he sends one sin packet. So, these are called sin packets the first packet in the three way handshake he sends one sin packet he keeps bombarding the victim with sin packet after sin packet. And the victim does not know what is going on he thinks these are legitimate requests for connection and to each one he responds with a sin plus act flag set. Now, the only thing is not to be discovered what he does is he spoof the source IP address. So, instead of his own IP address he put some other fraudulent IP address and as a result these packets go off in a different direction the packets the second packet in the three way handshake for each of these request packets the response packet does not go back to him, but goes back to the supposed source of this packet with the somebody else all together. So, it goes in a different direction he does not really receive it and he does it. So, that he is not able to be detected. So, one feature of the sin flood attacks and indeed dose attacks in general is you are trying to hide the identity of the sender by spoofing the source IP address. So, besides exploiting TCP you can also exploit UDP and attacker sends a large number of UDP packets to non-listening ports on the victim. So, the goal is to slow down the victim. So, what you do is you try to waste his time doing what send him UDP packets to non-listening ports. So, what does he do this causes the victim to respond with an ICMP message stating host unreachable for each of those packets each of those UDP packets that it receives it responds with an ICMP host unreachable message and that of course, wastes CPU time. So, that is about UDP and then we can also exploit ICMP through a well known attack called the smurf attack. An attacker sends a very large number of ICMP echo request messages to the victim's network. Now, what is interesting about this is that the destination IP address of all these packets is the special broadcast address. So, he sends just one packet the attacker sends just one packet with the destination IP address as the special broadcast address. So, this packet receives is received by all of them because it is broadcast everybody on this network and he spoofed the source address he makes it appear that the victim has sent this when actually he is sending it. So, the source IP address is the address of the victim. So, what happens is everybody thinks the victim is saying echo request and everybody responds to this victim and as a result the victim has to process each of those packets the victim is slowed down. So, this causes the victim to be inundated with echo reply messages from each host on the network. So, this is another example of a denial of service attack where it is not very serious perhaps, but at least you slow down the victim because of receiving so many packets being able being and the necessity of processing all these packets and then responding to them. Now, let us make a denial of service attack a little bit more sophisticated using what is called a distributed denial of service attack. So, what exactly happens in this case there is the attacker as you can see out here and he actually compromises several hosts as you can see. So, all these hosts are compromised you compromise them with some kind of a malware attack for example, so that you basically make them all obey you you you sort of transmit the malicious payload on each of these hosts. And then each of these hosts does a similar kind of thing he compromises a whole bunch of what are called zombies. So, once again he sends the infection transmits the infection like it is done in the case of code read for example, through a standard payload and each of these is infected and is commanded basically to do what he wants. And what is the command the command is to attack one of these victims. So, now this has a multiplicative effect because this attacker he is the master behind all this the brain behind all this he is actually recruited thousands perhaps of zombies directly or indirectly he is recruited all these guys to bombard the victim. So, this is this has the feature of being distributed. So, distributed denial of service attack. So, some features of DOS and DDoS. So, sin flooding it is an example of a DOS attack caused by a vulnerability in the TCP possible abuse of the 3 TCP 3 way handshake. So, some features of these attacks very often you will find that the source IP address almost always the source IP address is typically spoofed. There are multiple attack sources especially in the case of a distributed denial of service attack. So, multiple attack sources the victim reserves buffer space for each connection request. So, you have to reserve some amount of memory to accept packets from the source and it might lead to memory and bandwidth exhaustion, but also computational power might be consumed unnecessarily. So, there is a possibility of memory exhaustion of bandwidth saturation of computational degradation in processing because you are spending so much time in processing those fake requests. So, these are some of the features of DOS and distributed DOS. Now, we would like to come up with a simple model to see how serious this problem is. So, that we can take remedial measures via some sort of an intrusion detection system. So, we look at these various parameters to model the effect of this attack. So, one is the communication bandwidth of the victims link. So, let L be the communication bandwidth of the victims link. Let B be the maximum number of buffers reserved for TCP connections and let T be the maximum amount of time that the buffer can be reserved for a half open TCP connection. So, we actually describe what these things mean the maximum amount of time to be reserved for a half open TCP connection. And some more parameters these are attack related parameters R is the aggregate rate at which the victim receives sin attack packets from the various sources and P is the sin attack packet size in bits. Now, the question is what harm can this cause and we can be quantified through a very simple model. So, we can use more complicated models, but I am trying to come up with a very simple model to find out when memory can be exhausted or when the link can get saturated. So, what are the conditions for each of those? So, for that purpose let us write down some of the this notation from the two slides and then we will try to write down two equations which can capture memory exhaustion and bandwidth saturation. So, these are some of the parameters we are trying to model the effect of DDoS on the victim. So, once again L is the communication bandwidth in bits per second B is the maximum number of buffers utilized by TCP. So, do not forget that TCP is implemented as part of the operating system T is the maximum amount of time a buffer may be reserved for a half open TCP connection. So, let us try to clarify what this thing means in a second R is the aggregate rate at which the victim receives sin attack packets from not just one zombie, but from all the all the zombies that are attacking it and P is the sin attack packet size. So, let me clarify what is meant by the maximum amount of time that a buffer may be reserved for a half open TCP connection. So, the attacker sends the sin packet the victim responds with the sin plus act. So, this is the attacker this is the victim now this victim is waiting for the third packet of the handshake. So, it hopes to get it sometime by say this point in time. So, this is the time line it hopes to get it by sometime over here it waits it waits it waits patiently does not get it what does it do it times out and resends the sin packet sin plus act packet. So, this is resending it. So, resending the second packet in the three way handshake and it waits again patiently to receive this thing waits and waits does not receive it again it waits for some more amount of time before it resends. Now, this amount of time that you wait before resending and the number of resends both of these are operating system dependent. So, these depend on the implementation of the OS. So, all of this time before it just simply gives up. So, it will resend may be three times and then it will give up. So, all of this time between receiving the first sin packet and waiting and waiting and waiting until you give up this is the time that we refer to as t in this. So, now with this notation we would like to find out two things what is the expression what is the condition for bandwidth saturation or link saturation and then what is the condition for memory exhaustion. So, first link saturation. So, that should be pretty straight forward it is related to which of the three things it is related to the rate of attack packets it is related to the packet size and it is related to the link bandwidth. So, the rate of packets multiplied by the packet size is greater than what the communication link can hold then the link saturates. So, rate of packets multiplied by packet size and bits if that is greater than or equal to the link bandwidth then of course, the link can no longer hold anything and basically they can be no communication supported anymore and that is exactly what the attacker would like for the link to saturate. So, that is the condition for link saturation let me write it down again clearly r times p greater than l the link bandwidth what about memory exhaustion. So, this should be somehow related to the rate of packets that time t that we just described and the number of buffers that the operating system reserves for TCP. So, the rate of packets multiplied by the amount of time that is that the packet that a buffer can be held if this product is greater than or equal to the number of buffers then memory is exhausted. So, now we have no more memory to support TCP and either the operating system tries to get some more memory or there is a great slow down in the receipt of packets. So, either of these cases seems to satisfy the attacker. So, he is hoping that the bandwidth the link might saturate he is hoping that memory will be exhausted and of course, the third thing is computation. The victim is spending a lot of time in processing these useless packets and the CPU will slow down greatly. So, all of these are the effects of a DDoS attack and we will see later on tomorrow how we can do two things number one is how can we detect this and how can we try to prevent it. So, these are not foolproof methods, but at least we can try and once again the distinction between detection and prevention. So, before I continue there is one little thing I would like to say and that is how did we get this particular thing. This is an example of what is called little's law in networking and it is a very useful law that is used again and again in different contexts. So, I will just briefly illustrate this thing. So, in a typical network you might have. So, think of this is one of the switches you have got several buffers in these switches. So, think of a router or a switch over here. So, these are different input buffers. So, packets are coming in and packets are going out you might have input switching you might have output switching you can have shared memory switches and all kinds of different switch designs and then this is connected to some other switch here etcetera. Now, the neat thing about little's law is you can draw a boundary anywhere. So, you can draw a boundary around one switch you can draw a boundary around a single buffer you can draw a boundary across multiple switches and in either case ask yourself the question what is the average number of packets. So, suppose I draw a boundary across these switches ask yourself the question what is the average number of packets in this subsystem what is the average number of packets inside the subsystem and that is related to the arrival rate into the subsystem let us call that lambda. So, the arrival is from various sources if you consider the boundary like this. So, look at all these fluxes the rates into the system from different directions these inputs. So, this rate we are talking about and multiplied by the average time that a packet spends inside the subsystem. So, the average rate of packets into the system multiplied by the average time it spends into the system is equal to the average number of packets inside the system if in any point in time I just look and ask how many packets are there. So, there are two packets in this buffer there is one in this there are three in this and so on and so forth and I look at there is one that is getting ready to go out and so on I just look at the average number in the system at any point in time. So, I do this experiment again and again and again I look at the average number I look at the average aggregate rate into the system from all these different sources and an average time that a packet spends in the system then I have a very interesting relationship between these three things that the average number in the system is equal to the average rate into the system multiplied by the average time each of those elements of packets spends in the system and this is independent of the statistics of the arrival rate the arrival rate could be points on it could be anything else and still this relationship holds. So, this is the relationship I have used in deriving the little expression for memory exhaustion. So, once again link saturation when the rate of attack packets multiplied by the packet size is greater than the capacity of the link l and memory exhaustion when the rate of attack packets multiplied by the time for reserving the half open connection I explain what is that capital time it includes everything from the receipt of the first sin packet to the time when the victim gives up after having resend the message several times he gives up he is not received the third message of the handshake he keeps trying again and again until that time we refer to that as t that interval is referred to as t. So, r times t is greater than or equal to the number of buffers reserved for the TCP protocol. So, now that we have talked about the attack and the effect of the attack just a little bit about actually we will talk about this in great detail tomorrow during the session on IDS, but what are the possible mechanisms what can you do to handle a DOS and DDoS. So, you could have prevention mechanisms detection you can do neither and just respond to the attack. So, you are not proactive over here, but you are reactive you respond to the attack and then you let the attack happen let the effects of the attack happen and then say I am going to figure out who was responsible for the attack get to that person and possibly throw him in jail. So, you want to trace back find out who is responsible who is behind this attack. So, we look at different strategies for prevention detection response and trace back. So, we look at that in the context of IDS tomorrow we continue with the different kinds of network security protocols that could be attack we have looked at ICMP, UDP, TCP and now ARP. So, the next thing is ARP spoofing. So, you might have seen this some of you might have actually experimented with certain tools to do ARP spoofing one of the well known tools is cane enable for example. So, the first thing about this aspects of this attack it exploits certain features in the address resolution protocol it results it could result an ARP cash poisoning and in MIM attacks. So, that stands for man in the middle attacks session hijacking and so on. So, these could be very dangerous attacks where an adversary on the local area network that you belong to is actually trying to hack in and look at all the messages that you are sending may be even change them in a standard man in the middle attack. So, what is this most of you have already seen it. So, we just recap very briefly what is ARP it is used to resolve an IP address to a MAC address. So, we had just briefly talked about DNS where you resolve a domain name to an IP address. Now, you go one step further and you resolve an IP address to a MAC address. So, I have the IP address of a certain party and I am trying to find out what is that person's MAC address. If a station A needs to send a packet to B it is not sufficient that A knows B's IP address A should also know B's MAC address. For this purpose what is typically done as part of the ARP protocol is ARP broadcasts on the local area network and ARP query containing B's IP address. A station that has or knows B's MAC address responds directly to A. So, the first thing is a broadcast and then it is the direct communication to A whoever is knows the answer to that will respond to A. Now, the only thing is there will be multiple guys who know the answer to that question what is B's IP address and multiple guys might respond and then again it depends on how this ARP is implemented ARP might just look at the first response and neglect all the other responses. So, the IP address MAC address translations are cached. So, I often need to talk to somebody and I need to two different people actually and I have the IP addresses and I want to know the MAC addresses where do I look. So, typically I look into a fast memory and as everybody knows fast memories are called caches. So, I look into the specific ARP cache to quickly obtain the parties MAC address. So, these translations are typically cached ARP cache entries have a lifetime because they might change you might change the IP address views DHCP and so on. So, the IP address could change and as a result ARP cache entries should have a finite lifetime stations periodically send out ARP requests to update their cache entries. So, what is the current MAC address of somebody and so on any node X may send an unsolicited reply. So, these caches need to be updated now some guys might try to be extra helpful and what they might do is for example, node X may send an unsolicited reply to a node A regarding the MAC address of an arbitrary node B. So, I never asked you what is B's MAC address still X will send to A a message saying that B's MAC address is so and so. These are called unsolicited replies I never asked you for B's address, but you simply send it to me. So, this feature ARP referred to as Grotutus ARP is a serious vulnerability. So, there are actually two different things over here number one is when A requested for B's MAC address as I said before many guys might respond to A saying this is B's MAC address. In particular the attacker might also respond and he might try to be very fast. So, B itself might respond. So, once again the question is A is asking what is B's MAC address and there could be several guys who are responding one of the guys responding could be B, but you could have responses from others as well. So, what might happen is A might just take the first response and ignore all the other responses. In particular X may also respond and X may respond fast. So, this is not unsolicited this was solicited A actually asked what is B's address MAC address and every many guys responded including X and X happens to be the first. So, X's response will actually be cached the other situation is where it is unsolicited. Nobody asked for B's MAC address, but the attacker X actually sends a message to A saying that B's MAC address is so and so once again the MAC address is a 48 bit string as you all know. So, now let us see how this particular feature gratuitous replies and unsolicited replies might actually be exploited to launch some kind of a man in the middle attack. So, I will just show in a picture. So, here you have a LAN and you have three entities of relevance there is an A guy a B guy. So, these are innocent victims sort of and then there is an attacker X. So, how does this attack actually proceed. So, the first thing is a gratuitous or unsolicited response from X. So, message number one a gratuitous response from X unsolicited saying that B's MAC address is little x. So, to clarify this notation the IP address of this guy is capital A and the MAC address is little a. The IP address of this entity is capital X and the MAC address is little x and the IP address of this entity is capital B and his MAC address is little b. So, the attack starts with an unsolicited response from X saying that even though A never asked for it he sends it unsolicited response saying that B's MAC address is his own MAC address just imagine. So, this is a lie that B's MAC address B's MAC address is actually this thing little b where he says it is little x and he very humbly and meekly accepts this and he updates his ARP cash. Now, the second message he does the same thing to the other victim B. He says that A's MAC address he is telling B that A's MAC address is little x. So, once again B updates its ARP cash. Now, a few minutes later they want to communicate with each other who wants to communicate with whom A wants to communicate with B and B wants to communicate with A and in general they would get the messages directly through the LAN. A would talk to B and B would talk to A without any interference from the attacker, but because their caches have been spoofed what happens is when A is trying to contact B this is the message it sends to B this is the data part this hashed thing over here is the data part and this is the header and as you can see the source IP address is A. So, A is sending the message and he wants to talk to B that is B's IP address and he wants to know what is a B's MAC address and because his cash has been poisoned thanks to this message he puts B's MAC address as x and as a result the LAN will actually the LAN switch or the LAN hub will actually route this thing to x. So, x receives this message what does he do he can read this he can change it etcetera assuming it is not encrypted he can read it change it etcetera. So, that is message number 3 which is intercepted in a sense by x a man in the middle thing and then message 3 prime. So, he receives it reads it possibly modify something over there and then does a little bit of work he changes something in those fields. Now, he changes the MAC address back to little B so that we can receive it the original packet had little x he has changed it to little b and. So, the LAN routes it to B. So, B has seen the message for the message from A as pass through x and possibly been modified by x and exactly the same thing for response from B. So, he sends a message with the source equal to B that is himself and the destination equal to A that is this guy and the MAC address equal to x because his cash is also been poisoned. So, the MAC address is little x that is intercepted by this guy it is actually routed through him he reads all this stuff possibly modifies it changes the MAC address back to little a and then ships it out. So, you can see this is a standard man in the middle attack cause due to some problem with the ARP protocol the ARP cash has been poisoned and as you can see the vulnerability is also that you have messages that are not authenticated over here. So, that is one of the vulnerabilities you have these gratuitous unsolicited messages floating around. So, what could be the possible solutions one thing is this allow gratuitous ARP responses another thing is. So, one of the features that caused all this in the first place were these unsolicited responses and so on that is not the end of the story though that is only one scenario the other thing is allow only authenticated ARP replies. So, this might require support of PKI or some kind of Kerberos system then do not allow caches to change value of course, that is not very practical use ARP caches that are static which ignore updates sent by random machines. And then finally, there are switches built today that can handle this problem intelligent switches which learn which MAC addresses and IP addresses are mapped to which switch port. So, you find some strange thing coming in from a certain port I never see this port containing MAC address little b, but today I find it I get suspicious or I do not find little x today I find little x as the MAC address I get suspicious and I handle that packet I probably destroy that packet. So, use intelligent switches which learn which MAC address MACs maps to which port and which IP address maps to which port. Also monitor IP address MAC address pairings and ethernet frames and an ARP replies and check for any inconsistency with what has been learned by the switch. So, for example, I might get suspicious if I see a mapping like this destination IP address b and MAC destination equal to little x I have been I have been used to thinking of little b of capital B and little b over here suddenly I find b and x I get suspicious and I try to handle it by probably destroying the packet of something. So, these are some of the possible solutions you can ask yourself what are the pros and cons of these different solutions how easy is it to be to implement it how effective is the solution etcetera how cost effective is it and so on. There are also attacks on DNS they follow along exactly the same lines just like you have an ARP cache you also have a DNS cache and the cache can be poisoned due to unsolicited responses and so on and so forth. So, I will skip these you can just read them there are any questions do get back to us. There is also solution to this DNS set that is implemented on many different routers and many different systems which use DNS. So, those that is one possible solution to DNS cache poisoning and all the DNS attacks and then finally, before we start with the demos I will just mention briefly about vulnerabilities in LANs. LANs are probably the easiest thing to exploit and the reason for that is there are very standard protocols it is a common access medium. There are standard protocols that depend on the good behavior of all the entities on that LAN if some of them decide to misbehave the entire operation of the LAN can get crippled. So, an ethernet and 802.11 LANs for example, there are very well defined rules governing when a node should talk how long he should talk for how many nodes should handle how nodes should handle collisions etcetera etcetera. You very well know in CSMA CD for example, if there is a collision or even an 802.11 when there is a collision what exactly should I do should I back off for how long should I back off etcetera etcetera. The smooth functioning of these networks depends on the stations on the LAN strictly obeying the MAC rules otherwise in the worst possible case you could have one particular guy who jams the entire network. So, nobody else can talk nobody else can understand what is happening on the network. So, such problems are serious problems if some of these guys misbehave. So, there could be several attacks due to vulnerabilities in the MAC protocol which can be exploited by these bad guys. There are rules governing when a node may transmit after sensing a collision or rules related to inter frame spacing for example, in the case of 802.11 if these rules are violated stations on the LAN or the wireless LAN will see garbled messages. Frames may also be spoofed. So, there are several attacks there are several tools that do this you can ask your students to look at those tools and implement it if you have got a wireless LAN on your campus. Frames may be spoofed leading for example, to premature disconnection of a communicating party of two communicating parties. For example, a party has set up a connection with access point and suddenly that connection can be terminated because of an illegal the authentication frame or disassociation frame which has been spoofed by the attacker. There are several such attacks which are mentioned in section 17.4 of the text. So, with that brief introduction to various vulnerabilities in normal protocol these are not cryptographic protocol just your normal protocol and how these could be exploited. We will now turn to two particular demos one is on N map. So, the basic goal over here is to find out. So, this is in preparation for an attack what should I do I should try to find out on this particular network which are the hosts that exist which hosts are alive and once I found that out which ports are open on those hosts and then once I found out which ports are open whether they can be attacked whether any vulnerabilities behind the application or the service on that particular port. So, there is a sequence of these demos which we will do partly in the we will actually do in the lectures and the those demos will also be repeated in the lab. So, those demos are a full sequence of them today we will do Nessus and N map and tomorrow we will continue with Metasploit and Snot and the same thing will also be done in the lab tomorrow Thursday during the lab session.