Denial of Service Attack on Mobile Phones using Java Mobile
Transcription
Denial of Service Attack on Mobile Phones using Java Mobile
Denial of Service Attack on Mobile Phones using Java Mobile Bluetooth API Joyce E. Avestro and Ben-Hur C. Viray MS Computer Science Students Department of Computer Science College of Engineering University of the Philippines Diliman, Quezon City Abstract—Bluetooth is deployed in millions of devices nowadays and is one of the popular protocols for wireless connectivity. Its specification offers security, ease of use and interoperability among a variety of wireless de- vices. However, there are some security flaws discovered and reported. Is it really secure or not? This paper looks into these vulnerabilities and exposes a denial-of-service attack using Java Mobile Bluetooth API. Index Terms—Java Mobile, Mobile Security, Phone Vulnerabilities, Mobile Computing cating with one slave illustrates the former, while a master communicating with several slaves illustrates the latter. There are several issues in the emergence of Bluetooth: (1) security, (2) cost, (3) manufacturer support, and (4) interference with other wireless technologies that use 2.4GHz spectrum, such as 802.11b/g. This paper discusses the first issue. A. History I. Introduction B LUETOOTH is a wireless technology that lets devices - such as computers, phones, personal digital assistants, cameras and printers - perform short-range communication without the need for cables. It enables creation of Personal Area Networks (PAN) of at most 8 devices, which is also known as a piconet. To establish a PAN, a device discovers other devices in range of at most 10 or 100 meters, depending on the Bluetooth capability of the device. If another Bluetooth device is within the range, it responds to the query by providing a list of services it is equipped with. In this process, a master-slave relationship is established. The inquiring device is the master while the responding device is the slave. A Bluetooth device can be part of several piconets. In which case, it could be both a master and a slave but it is allowed to be a master in only one. If piconets are interconnected, they form a scatternet. Communication in Bluetooth can be point-topoint or point-to-multipoint. A master communiMs. Avestro is a faculty member and a Master of Science in Computer Science student of the Department of Computer Science, University of the Philippines, Diliman Quezon City. She specializes in Mobile Computing and Information Systems. Phone: +632 925 2366, e-mail: joyce@up.edu.ph Mr. Viray is a Master of Science in Computer Science student at the University of the Philippines specializing in Information Systems. Phone: + 63 9178153969, e-mail: bcviray@up.edu.ph c 2006 IEEE 1-4224-0220-4/06/$20.00 1 Bluetooth was conceived in 1994 by Telefonaktiebolaget LM Ericsson based in Stockholm, Sweden. The name Bluetooth was influenced by two people: (1) King Harald Blatland (Blatland translates to Bluetooth in English) who was a Viking King of Denmark in 10th century; and (2) Hedy Lamarr, an actress who helped George Antheil discover frequency hopping, the technology used by Bluetooth in data transmission. In frequency hopping, frequencies hop on various channels, making them harder to intercept. In 1998, the Bluetooth Special Interest Group (SIG) was formed by Ericsson, IBM, Intel, Toshiba and Nokia to develop a standard for the technology, which was later joined by thousands more companies. B. Bluetooth Protocol Stack and Profiles The protocol stack of bluetooth consists of seven (7) layers, each corresponding to a layer in the Open Systems Interconnection (OSI) Reference Model[2]. This is illustrated in Fig. 1. At the bottom of the stack is the Bluetooth Radio Layer. It transmits and receives radio signals. The Baseband Layer provides settings to enable sending and receiving of radio signals. Another core protocol, the Link Manager, sets up and configures communication link between Bluetooth devices. It also performs security functions such as authentication. Host Controller In- terface (HCI) bridges the host computer with lower level protocols. Logical Link Control and Adaptation Layer Protocol (L2CAP) provides data services to upper-layer protocols while RFComm emulates the signal by which serial ports receive and process data. OBEX (object exchange) defines data objects and a communication protocol for data exchange between two devices. Service Discovery Protocol (SDP) provides a way to determine what Bluetooth services are available. The last layer consists of various existing protocols. Fig. 2. Bluetooth Profiles and their Interdependence C. Bluetooth Security Model Bluetooth specification covers security. However, it is only for device authentication and is entirely optional! The technology’s security specification covers link security, encryption, authentication, key generation management and random number generation. Bluetooth provides three trust levels: (1) Trusted Device Level, (2) Untrusted Device Level and (3) Unknown Device Level. In Trusted Device Level, fixed relationship between two devices is established and they have unrestricted access to all services. In Untrusted Device Level, its either two devices do not have fixed relationship or have fixed relationship but not trusted. If the level is untrusted, there is restriction on accessing services. To establish trust, Bluetooth uses symmetric key cryptography - both for the initialization key and the link key. To authenticate devices, a 128-bit initialization key is used. It is generated from the device PIN number, the claimant’s Bluetooth device address (unique 48-bit numbers assigned by manufacturer), and a random number shared by the claimant and the verifier. To establish trust, a semipermanent link key is used for authentication as well as for generation of encryption keys. To establish fixed relationship, the verifier sends a random number to the claimant and the verifier encrypts it using the secret link key then sends back to the verifier. The verifier then encrypts the same number and compare it to the claimant’s. They are authenticated when the results match. Fig. 1. Bluetooth Protocol Stack In order to specify the usage of Bluetooth technology, profiles were defined. Profiles may reuse or reference parts of another profile and they can also share security and procedures. The profiles, and their interdependence, are illustrated in Fig. 2. All profiles are built on top of Generic Access Profile, which provides the developer the technical guidelines for all the other profiles. 2 Generic Access Profile defines three security modes. Security mode 1 has no security enforcement - all services are available to other devices. Security mode 2 implements service-level security initiates security when two devices establish communication. In this mode, different security settings in applications running at the same time can be imposed. Security mode 3 enforces device-level security, i.e., security for every low-level communication. Authorization and authentication of a device might be required by some services. In this mode, trusted devices are given automatic access while untrusted devices need authorization. To manage the varying levels and modes of security, Bluetooth uses a security manager. D.3 BlueSnarf Bluesnarfing involves illegal access to someone’s data without alerting the owner. Since the attacker can read and/or copy data, the invasion of privacy is an issue. This is a result of a flaw in the OBEX protocol - instead of PUSHing objects, GET is performed even without authentication. D.4 BlueBug Bluesnarfing inspired the creation of a better attack, Bluebugging. This attack can mean full access to premium services on a victim’s Bluetooth-enabled device. An attacker can alter and/or destroy a certain amount of data, which can render the device unusable. D. Bluetooth Attacks D.5 BlueSniper In Bluetooth, there is a tradeoff between security and user convenience. Since manufacturers consider the latter as top priority, the former is affected. Hence, most systems affected are vulnerable to attacks. The following are the common attacks faced by Bluetooth devices. Bluebugging is not limited to the given range of 100 meters. Alteration of a Bluetooth dongle can make the range of connectivity larger. Making the antenna of a Bluetooth dongle larger enhances the distance it can reach. This is known as a BlueSniper. D.6 Wardrive D.1 BlueSniff Wardriving is not limited to wireless local area networks. It could also be done in Bluetooth. In wardriving, a user can estimate the location of a Bluetooth device that has its discover mode on. The tracking is done using the MAC address of the device. Devices with Bluetooth capability not enabled should not be discovered. However, they can be discovered by brute forcing their MAC addresses. These addresses are permanent so the eavesdropper is guaranteed that the device’s address will not change. During the pairing process of a Bluetooth activity, eavesdroppers can use packet sniffers to get the PINs. Another thing, most users have weak PINs so it is easy for the eavesdroppers to sniff them. The generation of the initialize key algorithm is purely based on this PIN, so it may be a problem because the pairing process happens only once between two devices most of the time. D.7 BlueSmack This Denial of Service attack can make Bluetoothenabled devices unusable. It uses a buffer overflow scheme at the L2CAP layer to exploit the resources of the target. The attacker only needs to overload the buffer beyond its limit of 65535 bytes. II. Related Work D.2 BlueJack Several papers were written about Bluetooth vulnerabilities and attacks. To prove their claims, these authors made experiments and/or applications for “educational” purposes. Bluejacking is done by passing anonymous messages. It is done by sending phonebook entries without notifying the receiver of the existence of a successful connection. The name in the phonebook entry is required, and since it can be up to 248 characters, a long unsolicited message can be sent. Although this practice is almost harmless, it can lead to serious attacks such as bluesnarfing or bluebugging (to be discussed later) if the user initiates a pairing process. Also, it can drain batteries as well. A. RedFang Redfang is an attack that uses brute-force approach in sniffing devices even when Bluetooth are in non-discoverable mode. It was released by @stake Inc. in 2003[13] and a bluesniffing tool was released by Shmoo[3] as a front-end for RedFang. 3 B. Man-in-the-Middle Having a weak PIN can mean trouble for some users. Vainio[9] presented a man-in-the-middle attack in his paper. The attack was about false authentication. He also mentioned that once the Bluetooth address is known, it is easy to monitor the victim’s device. C. Mobiluck Mobiluck is a Symbian snarfing application written in C++. It discovers devices within range and sends messages via Bluetooth through phonebook entries without the need for pairing. Fig. 3 to Fig. 5 shows the actual testing of the application using Nokia 3230 and Sony Ericsson T610, as well as on an Apple Powerbook. Fig. 4. Phone Mobiluck Snarfing Attack: Attacking a Bluetooth screenshots of the attack. However, since no Nokia 6310 at the time of testing was available, we have not tested it successfully on actual device. E. Weapons A long distance attack was performed in August 2004[8], inspired by Wi-Fi toys[11]. They used off-the-shelf hardware as suggested by Bluedriving.com[12]. Other sites include step-by-step instructions for building a BlueSniper rifle[6], which is just a Bluetooth dongle with larger antenna installed. III. Research Motivation Some papers [10] claim that the Bluetooth Specification itself is relatively secure, the security problems are primarily related to device manufacturers and application developers. Fig. 3. Mobiluck Snarfing Attack: Discovering Bluetooth Devices Bluetooth snarfing needs phonebook access to be able to attack. And since Java Mobile does not allow access to phonebook for security reasons, it is not possible with low to mid-end Java mobile phones. It is, however, possible to be done using C++ just like what this work has done. D. Blooover Blooover is a J2ME MIDP 2.0 phone auditing tool written by Trifinite for BlueBugging[1]. It is named after Bluetooth and Hoover, where it is compared to a vacuum cleaner that sucks items. It claims to read and write phonebooks and SMS messages, as well as take calls. The attack was successful on Nokia 6310i and some Sony Ericsson models. Fig. 6 shows actual Fig. 5. Mobiluck Snarfing Attack: Attacking a Notebook Computer 4 IV. Experiment and Results A J2ME MIDlet, which uses OBEX push, was created to show the denial of service attack in mobile phones.The attack will work only if either the two devices have already been paired or the authentication of the target device is not enabled. The experiment used two devices that had been paired. The attack makes the device memory overflow. The effect - the device restarts and becomes unusable for a certain amount of time. In the MIDlet, a byte array of random values is sent to the victim device. Since it cannot handle the amount of data received, it ends up rebooting. The following is a code snippet of the MIDlet: String url = r.getConnectionURL( ServiceRecord.NOAUTHENTICATE_NOENCRYPT, false ); // Get the channel ID of the OBEX service int channel = findChannelId( r ); String url2 = "btspp://" +remote.getBluetoothAddress() +":"+channel +";master=false;encrypt=false;" +"authenticate=false"; try { // Obtain connection and stream to // this service StreamConnection con = (StreamConnection) Connector.open( url2 ); DataOutputStream out = con.openDataOutputStream(); Fig. 6. Blooover Attack On a separate note, there are some studies that take a look into vulnerabilities in J2ME. And since security issues were considered in the design of MIDP - using sandbox model, for example - it is considered secure. However, several other APIs have been considered to allow creation of applications that exploit security vulnerabilities, like Java Specification Request 82 (JSR-082), the Bluetooth Specification. Although most of the vulnerabilities were exploited using C++ (since it allows phonebook access - which is necessary in spreading worms, for example), it is also possible to write programs in J2ME that exploit these vulnerabilities as well. This paper shows one possible attack on mobile phones using the J2ME Bluetooth API. // Long random byte values byte[] dataN = {1,2,3,4,5,6,7, 8,9,9,0,1,2,3,45,67,98, 90,32,123, ....}; // Write data into serial stream for(int i=0; i<50; i++){ out.write( dataN ); out.flush(); } } The attack, however, was successful in only one of three devices experimented on. The device used to attack was a Nokia 3230 and the target was a Sony 5 Fig. 7. DoS Bluetooth Attack: The Bluetooth MIDlet Fig. 9. DoS Bluetooth Attack: Attempting Connection to Bluetooth Device Fig. 8. DoS Bluetooth Attack: Bluetooth Devices Discovered Fig. 10. DoS Bluetooth Attack: T610 Restarting Ericsson T610. It wasn’t able to attack Nokia 3650 and Sony Ericsson K700i successfully. Fig. 7 to Fig. 12 show the attack. Fig. 8 shows the discovery of Bluetooth devices. Fig. 9 illustrates the connection attempt to victim device while Fig. 10 and Fig. 11 display the device restarting. Finally, Fig. 12 shows both Turn On Bluetooth and Turn Off Bluetooth are enabled - when in normal operation’s case, only one of the two is enabled. The Bluetooth API is designed to be secure, it is the hardware manufacturers and firmware developers that make devices unsecure. To protect existing devices from attacks, it is recommended to have the devices’ firmware upgraded whenever it becomes available. Also, turning off Bluetooth whenever not in use or in a public place - such as malls - is highly advisable. Acknowledgment V. Conclusion and Recommendation The authors would like to thank Dr. Susan Pancho-Festin, their adviser in Computer Security, for motivating them to write this paper. Dr. Pancho-Festin obtained her Ph.D. at University of Cambridge and specializes on Computer Security and Security Protocols. She is also a graduate of Royal Holloway, University of London with the degree of MSc in Information Security. There are a lot of initiatives in the development of the technology. More and more devices support it, and more applications use it. Being a relatively new technology, it is not surprising that a lot of vulnerabilities have been found. This paper showed that it is possible to attack a mobile phone by buffer overflow. Although Java Mobile is designed to be more secure than its Standard Edition counterpart, it still can be used to exploit vulnerabilities in the Bluetooth API. However, since it does not allow access to phonebook, the attacks that can be done is limited. References [1] A. Laurie, M. Holtmann and M. Herfurt, “Hacking Bluetooth enabled mobile phones and beyond - Full Disclosure”, 27 December 2004, http://trifinite.org/Downloads/21c3 Bluetooth Hacking .pdf 6 [13] O. Whitehouse, “War Nibbling: Bluetooth Insecurity”, October 2003, http://www.atstake.com/research/reports/acrobat/ atstake war nibbling.pdf Fig. 11. DoS Bluetooth Attack: T610 Restarted Fig. 12. DoS Bluetooth Attack: Both Turn ON Bluetooth and Turn OFF Bluetooth are Enabled [2] Apple Computer, Inc., “Working with Bluetooth Devices”, 29 June 2004, http://developer.apple.com/documentation/Device Drivers/Conceptual/Bluetooth/Bluetooth.pdf [3] B. Potter and B. Caswell, “Bluesniff - The Next Wardriving Frontier”, 13 January 2003, http://www.shmoo.com/˜gdead/dc-11-brucepotter.ppt [4] Benhui.net - Source for J2ME Bluetooth Mobile 3D MIDP 2.0, http://www.benhui.net [5] Bluetooth.org - The Official Bluetooth Membership Site, http://www.bluetooth.org [6] H. Cheung, “How To: Building a BlueSniper Rifle Part 1”, 08 March 2005, http://www.tomsnetworking.com/Sectionsarticle106.php [7] H.M. Deitel, P.J. Deitel, T.R. Nieto, and K. Steinbuhler, “Wireless Internet and Mobile Business: How to Program”, 2001 [8] J. Hering, “Bluetooth Attack!”, 16 September 2004, http://www.g4tv.com/screensavers/features/48021/ Bluetooth Attack.html [9] J.T. Vainio, “Bluetooth Security”, 25 May 2000, http://www.niksula.cs.hut.fi/˜jiitv/bluesec.html [10] M. Bialoglowy, “Bluetooth Security Review”, 25 April 2005, http://www.securityfocus.com/infocus/1830 [11] M. Outmesguine, “New World Record for Bluetooth Link!”, 30 July 2004, http://www.wifi-toys.com/wifi.php?a=articles&id=21 [12] “Modifications to USB Linksys Class 1 Bluetooth Adapter”, http://www.bluedriving.com/linksysmod.htm 7
Similar documents
Bluetooth Hacking revisited
The reason for using the output of and not directly choosing a random number as the key*, is to avoid possible problems with degraded randomness due to a poor implementation of the random number ge...
More information