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: [email protected]
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:
[email protected]
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