1.1 Motivation and Contribution
1.1.6 Rogue Dynamic Host Control Protocol (DHCP) Attack
As seen earlier, a client performs a four-way handshake in order to authenticate and as- sociate with the AP. Following the successful four-way handshake, the client solicits the AP for its IP configuration. Most wireless APs do provide an interface for a Dynamic Host Configuration Protocol (DHCP) service. The DHCP service provides a pool of IP addresses that can be allocated when a client requests for an IP address. The primary function of a DHCP server is to allocate IP address and other vital information like subnet mask, default gateway, DNS address to the clients requesting it. The client does a four-way handshake with the DHCP server in order to obtain its IP configuration. On open Wi-Fi networks the information exchange between the client and the DHCP server is done in plain text making it susceptible to spoofing. It is also possible for a Wi-Fi network to have multiple DHCP servers. Multiple DHCP servers are usually deployed for fault tolerance and management of IP addresses in case one of the DHCP server fails.
The DHCP does not have any means to authenticate the frame exchange between the client and the DHCP server. As a result, it is possible for an attacker to set up a rogue DHCP server by spoofing the IP and MAC address of the genuine DHCP server and send fictitious IP address, DNS and gateway address (or a combination of these) to the client(s) requesting DHCP services. If a client receives multiple DHCPOFFER(s) from different DHCP server(s) (one from the genuine and other from the rogue DHCP server) it is free to choose the offer of its choice. If the client accepts the IP configuration from the rogue DHCP server then
it may lead to serious security concerns. By supplying wrong default gateway and DNS server address an attacker setting up the rogue DHCP server can re-direct client’s traffic via its terminal thereby sniffing client’s information, re-directing clients to phishing websites, install malware into the client’s machine etc. Thus, a rogue DHCP server is a serious threat to a Wi-Fi network.
Various approaches have been suggested in the literature to detect or prevent the rogue DHCP server attack. In DHCP snooping feature [81], an administrator can configure in- dividual switch ports to be trusted or not trusted. Only trusted ports are allowed to serve DHCPOFFER and ‘DHCP Acknowledgment’ (DHCPACK) frames. If a non trusted port is gen- erating DHCPOFFER or DHCPACK frame, it is blocked at the switch level itself. The clients in Wi-Fi networks are connected over the air to the AP and not via switches. So, DHCP snooping technique might not work in the case of Wi-Fi networks. Some security experts postulate for network wide scanning for studying the IP-MAC mappings of all the clients in the network. As the IP address of the genuine DHCP server(s) is known beforehand, those IP addresses providing DHCP service but not in the white-list of genuine DHCP server(s) list can be marked as rogue [82]. However network wide scanning leads to generation of too much traffic and white-list based methods can be defeated by spoofing the IP and MAC address of the genuine DHCP server.
As DHCP lacks authentication mechanism, the RFC 3118 [83] provided the authentica- tion option with an aim to resolve the security related issues associated with DHCP. The authors in [84] suggest the use of RSA signatures for authentication purposes. Although RSA provides a significant level of security, it is computationally expensive which may fur- ther lead to faster draining of the batteries of hand-held Wi-Fi devices like smart-phones, laptops, PDAs etc. The major issue in the adoption of the authentication option in Wi-Fi network is because of handling of key management for the large number of clients [85]. Xu et al. [86], Glazer et al. [87], Demerjian et al. [88] propose various methods that make use of digital certificates for both entity authentication as well as message authentication and is based on RFC 3118. The usage of digital certificate provides sufficient authentication and protects against the rogue DHCP server attacks. However, the usage of digital signa- ture brings in issues like certificate management, revocation, overhead between client and DHCP server, trust issues etc.
Graaf et al. [89] in their patent describe a method that makes use of special Authentica- tion, Authorization and Accounting (AAA) server that achieves authentication using shared secret between client and AAA server. Similar to this method, the authors in [90] make use of Kerberos V for mutual authentication of the DHCP server and the client, and for the DHCP message authentication. The main disadvantage of these schemes is the additional
communication overhead between the Kerberos, AAA server and the DHCP server. Also, The sequence of frame exchange in the four-way handshake remains the same under nor- mal and rogue DHCP server conditions. Somers et al. [91] describe a method where in they calculate trustworthiness scores based on the DHCP offers received from the DHCP server(s) present in the network. However, the method is prone to large number of false positives because of its scoring methodology. From the various methods discussed above, it can be concluded that rogue DHCP server cannot be effectively detected by simply ob- serving the frame exchange between the client and the DHCP server. A rogue DHCP server does not bring about a significant change in the network traffic. As a result, generation of signature or statistics from this four way frame exchange is difficult and may result in high amounts of false positives [92]. In brief, the drawbacks of the existing schemes to detect or prevent the rogue DHCP server attack are: 1) Require Digital Certificates. 2) Use of specialized servers like AAA, Kerberos. 3) Requires extensive key management strategies.
Rogue DHCP attack is similar to an evil twin attack and clearly lacks signature or anomaly.
However, in all the DES frameworks discussed till now, we have assumed that the diag- noser/IDS always receives frames from the genuine client as well as the attacker reliably under normal, attack and probing conditions. However, many times the IDS fails to capture few frame(s) because of frame losses, capturing errors etc., leading to inconsistent mea- surement. The DES based fault detection framework handles measurement inconsistency rather strictly. DES framework assumes measurement inconsistent transitions as perma- nently unmeasurable and never uses them for fault diagnosis. These inconsistent transitions are inherently measurable, so considering them as permanently unmeasurable may lead to weak diagnosis.
In order to overcome this problem, we propose a Measurement Inconsistent Discrete Event System (MIDES) framework which does not assume measurement inconsistent tran- sitions as permanently unmeasurable; albeit if a transition is measured then it is used for fault diagnosis and if the same transition leads to measurement inconsistency the possible system state(s) are predicted using an estimator diagnoser. We have used the MIDES based Intrusion Detection System (IDS) for rogue DHCP server attack detection. The steps to model is same as those of the previous DES frameworks i.e., to construct the normal and fault model followed by diagnoser construction. The MIDES diagnoser proceeds in exactly the same manner as the previously discussed DES frameworks (simple (untimed) DES, I2- DES, RTDES) unless a measurement inconsistency occurs. If a measurement inconsistency occurs (because of frame loss), the estimator diagnoser predicts the possible system states and continues fault diagnosis. The contributions of the scheme are enumerated below:
1. We propose a modified DES based FDD scheme called Measurement Inconsistency
DES (MIDES), which is capable of diagnosing the faults even when measurement in- consistency occurs. In contrast to traditional DES, the MIDES scheme handles the measurement inconsistency in a flexible manner, instead of assuming them as perma- nently unmeasurable. To handle the state explosion problem, the MIDES framework is augmented with model variables.
2. We develop an MIDES based IDS in order to detect rogue DHCP server in Wi-Fi net- works and demonstrate its efficacy. The IDS designed using MIDES based framework does not require change in protocol, generates minimal extra traffic overhead and does not require patching in individual hosts.