University of TrierInformation Security and Cryptography
Bachelor Thesis
Session Hijacking on Android Devices
by
Andreas Koch
August 2011
University of Trier
Prof. Dr. Ralf Kuesters
Chair of Information Security and Cryptography
Building H/Campus II
D-54286 Trier
Bachelor Thesis
Session Hijacking on Android Devices
Andreas Koch
Matriculation Number: 949190
August 2011
Supervisor: Prof. Dr. Ralf Kuesters Reviewer: Prof. Dr. Peter Sturm
Erkärung zur Bachelorarbeit
Hiermit erkläre ich, dass ich diese Bachelorarbeit selbstständig verfasst und keine anderen
als die angegebenen Quellen und Hilfsmittel benutzt habe und die aus fremden Quellen
direkt oder indirekt übernommenen Gedanken als solche kenntlich gemacht habe.
Die Arbeit habe ich bisher keinem anderen Prüfungsamt in gleicher oder vergleichbarer
Form vorgelegt. Sie wurde bisher nicht verö�entlicht.
��������� ���������
Datum Unterschrift
Contents
1 Introduction 1
2 Wireless Networking 3
2.1 Wireless LAN � How it works . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1 Transport standards . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2 Security standards . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Internet protocols 7
3.1 TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 SSL/TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4 HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.5 Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5.1 Web sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5.2 Why session identi�ers should be kept private . . . . . . . . . . . 12
3.5.3 Why most session identi�ers are not secure . . . . . . . . . . . . . 12
3.6 Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.6.1 HTTP Response � 'Set-Cookie' . . . . . . . . . . . . . . . . . . . 14
3.6.2 HTTP Request � 'Cookie' . . . . . . . . . . . . . . . . . . . . . . 15
3.6.3 Session cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6.4 Shared authentication . . . . . . . . . . . . . . . . . . . . . . . . 17
4 Android 18
4.1 Android general application structure . . . . . . . . . . . . . . . . . . . . 18
4.2 Dalvik virtual machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3 Android security model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5 Preparing the attack 22
5.1 Understanding session hijacking . . . . . . . . . . . . . . . . . . . . . . . 22
5.2 How to identify a web sites session cookies? . . . . . . . . . . . . . . . . 25
5.3 Capturing the session identi�er . . . . . . . . . . . . . . . . . . . . . . . 26
5.4 Setting session ID for own requests . . . . . . . . . . . . . . . . . . . . . 27
6 Technical basics 28
6.1 Building native programs for Android devices . . . . . . . . . . . . . . . 28
6.2 Requirements on Android devices . . . . . . . . . . . . . . . . . . . . . . 29
6.2.1 Hardware / Firmware . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.2.2 Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.2.3 libpcap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.2.4 Android ROM / Kernel version of the device . . . . . . . . . . . . 30
6.2.5 Superuser access . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7 Implementing DroidSheep 32
7.1 Features of the program . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.1.1 User interface: Listening screen . . . . . . . . . . . . . . . . . . . 32
7.1.2 Web screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.1.3 Background mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.1.4 Extensible cookie list . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.2 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.2.1 native C part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.2.2 Java part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.3 The Java application in detail . . . . . . . . . . . . . . . . . . . . . . . . 36
7.3.1 Android CookieManager . . . . . . . . . . . . . . . . . . . . . . . 36
7.3.2 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.3.3 Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.3.4 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.3.5 auth.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.3.6 Identi�cation logic . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.3.7 AndroidManifest . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
8 Limitations and future work 45
8.1 Network association required . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.2 Root access and warranty void . . . . . . . . . . . . . . . . . . . . . . . . 45
8.3 WPA and WPA2 encrypted networks . . . . . . . . . . . . . . . . . . . . 46
9 Preventing the attack 51
10 Conclusion 53
1 INTRODUCTION
1 Introduction
Maybe you know Bob. Bob is a well known person and Bob loves co�ee. Every morning,
he takes his laptop and visits one the famous green co�ee bars, has a 'grande vanilla latte'
and writes messages to his Facebook friends. For doing that, Bob uses the co�ee bars'
WiFi because it's free and fast. One morning, Bob is just writing a message to his girl-
friend, Eve enters the co�ee bar. Eve has an Android phone and Eve uses DroidSheep.
After ordering a 'venti caramel macchiato', Eve sits down, takes her phone and starts
browsing Facebook. Using Bobs identity. She can watch his friends, read his messages,
write messages, write wall posts, remove friends, delete Bobs account. Without ever get-
ting in touch with Bob.
This short story introduces what this work is about: 'simple session hijacking', 'stealing
someones digital identity' or however you'd like to call it. Facebook is only one of the
most recent and most prominent examples where an attack like this is possible.
In October 2010, Eric Butler published an extension for the popular browser Firefox
called '�resheep'. Firesheep allowed the user, who is connected to a wireless network, to
listen to the networks tra�c and to identify open sessions within this network.
Firesheep then captured open sessions on the network and showed them to the user. With
just a single click, the user could take over the session and surf the web site using the
victims identity.
So even if the attack that �resheep performed was not new or very complicated, it was
the �rst time that this attack could be performed that easily and by anybody without
any network knowledge or special hardware.
After a lot of ethic discussion regarding �resheep, people realized that there is a big
lack of security in wireless networks and web services. This resulted in some of the big web
sites accepting the demand for security and o�ering encrypted connections for logging in.
Nevertheless, many provider for web services did not realize that there is a demand for
security and still do not o�er any encrypted communication.
This is one of the reasons for this work. This work describes the basic knowledge
for the development of DroidSheep, an application with similar features compared to
�resheep, but developed for Android powered, mobile devices. This opens a completely
new �eld of application for this attack, as most Android phones contain wireless chips
but are much more �exible than a laptop and can perform an attack in fact 'in passing'.
DroidSheep is not intended to harm any person. Instead it should rather remind
1
1 INTRODUCTION
people to think about their privacy. If they learn how easily their identities can be stolen,
they might avoid risks like public networks. This also might make the web services rethink
their strategies, because people might demand security and force the providers to enable
this security.
After reading this thesis, the reader should have knowledge about how the attack
works, including some required network basics, Android system architecture and appli-
cation development. He also learns how the attack itself is performed and what steps
are necessary to implement it automated in an Android application. Afterwards, the
limitations of the implementation and possible ways to prevent that attack are outlined.
2
2 WIRELESS NETWORKING
2 Wireless Networking
In general, wireless LAN (Local Area Network) means any kind of standardized technol-
ogy, which enables communication of two or more devices without any wired connection
[29]. Most of the wireless technologies use electromagnetical waves within speci�ed fre-
quency bands. There are lots of regulatory authorities for usage of radio (e.g. The "`Fed-
eral Communications Commission"' in the U.S., the "`European Conference for Posts and
Telecommunications"' in Europe and some more around the world), which means selec-
tion of frequency bands for wireless networking technologies is very restricted and often
linked to registration and usage fees. In order to make wireless LAN publicly available
and devices of di�erent manufacturers interoperable, standards for wireless technologies
have been developed by independent groups or producer associations. One of these groups
is the IEEE (Institute of Electrical and Electronic Engineers Inc.), which consists of more
than 400,000 members around the globe and is one of the most important 'professional
association dedicated to advancing technological innovation and excellence for the bene�t
of humanity'. [31] Since the year 1980 the IEEE develops a well known group of stan-
dards for local networks, called IEEE 802. IEEE 802 contains amongst others important
standardizations for 'Ethernet' (IEEE 802.3), 'Bluetooth' (IEEE 802.15.1), 'Broadband
Wireless Access' ('WiMAX', IEEE 802.16) and 'Wireless LAN' ('Wi-Fi', IEEE 802.11).
2.1 Wireless LAN � How it works
Wireless LAN uses electromagnetic waves for communication and therefore it is inher-
ently a broadcast medium. Radio waves are not targeted, which means they dispread
uncontrolled over the air and can be received or monitored by any person or device within
the wireless devices operational range.
Wireless networks usually o�er two network modes: infrastructure mode and ad-hoc
mode [29]. Infrastructure usually implies the usage of an access point, which cares about
authentication and key negotiations. Most wireless networks use this infrastructure mode,
whereat in most small wireless networks the access point additionally features router and
Internet gateway capabilities. As mentioned before, wireless networks physically can only
send broadcast messages. Within a usual, wired (switched) network (�g. 1(a)), there is
one switch that has a wired connection to each client computer. If a client sends a data
frame, he puts some electric tension on the wire and thus carries his data to the switch.
As this wire only connects the switch and the client, any other device within this network
can only receive this data frame in case the switch actively forwards it to the device.
3
2.2 IEEE 802.11 2 WIRELESS NETWORKING
(a) Way of a network packet in a switched network (b) Way of a network packet in a wireless network
Figure 1: Transport of packets within IEEE 802 [author's illustration]
Within wireless networks, this is completely di�erent (�g 1(b)). As there are no lines, the
client has to use the air for sending his data frame using electromagnetic waves. By the
waves, dispreading basically in a circular way, the way of his data frame is uncontrolled.
Any device, which is inside the range of the electromagnetic waves, can receive the data
frame.
2.2 IEEE 802.11
In the year 1997 the IEEE's Standards Association published the standard IEEE 802.11
after seven years of preparation and approval. IEEE 802.11 was the �rst non-proprietary
standard for wireless local area networking, its current version is IEEE 802.11-2007 [26].
The initial standard already speci�ed communications using the 2.4 GHz and the 5 GHz
radio band, whereas the 2.4 GHz was much more attractive as it is worldwide and license
free usable. Compared to 5 GHz it has a better operating distance as it is not resorbed
as much as the 5 GHz band. During the last years, some new and improved amendments
have been added. They describe more e�cient modulation and radio techniques, with
the main focus being on increasing connection payload. [29]
4
2.2 IEEE 802.11 2 WIRELESS NETWORKING
2.2.1 Transport standards
The most widely used standards for transport within IEEE 802.11 are IEEE 802.11a/b/g
and the most recent 802.11n. They mainly di�er in the radio frequencies they use, mod-
ulation techniques, operating distances and bandwidth.
Standard frequency band data rate (theo.)
802.11a 5 GHz 54 MBit/s
802.11b 2.4 GHz 11 MBit/s
802.11g 2.4 GHz 54 MBit/s
802.11n 2.4 GHz & 5 GHz 54 - 600 MBit/s
2.2.2 Security standards
Because of the usage of a broadcast medium, there is a high demand for strong security
properties when using wireless networks. Without encryption applied, everybody can
monitor the wireless LAN's data without authentication. To avoid this, IEEE 802.11
initially de�ned a security technique calledWired Equivalent Privacy WEP. In 2001 WEP
was proved to be insecure by exploitation of a weakness in its RC4 key scheduling. As
this attack is very easy and inexpensive, WEP became insu�cient for securing wireless
networks[32]. As a reaction of WEPs vulnerability, IEEE started research for a new
security solution and WiFi Protected Access WPA was introduced as a subset of the
un�nished draft for wireless LAN security IEEE 802.11i in 2003. IEEE 802.11i was
�nished and rati�ed in 2004 and is known as WPA2.
Today, wireless LANs use one of these security standards:
• Open: All data is sent unencrypted in plaintext. Any device in range of the
network can read the packets. If it is not associated to the network most devices
discard the packets automatically unless they are running in monitor mode which
prevents discard of any data.
• WEP: It uses a pre-shared key (PSK) and RC4 stream cipher for encrypting all
communication in the network. There are three di�erent kinds of WEP, which use
di�erent key sizes
64 bits (40 bits for the key, 24 bits for initialization vectors)
128 bits (104 bits for the key, 24 bits for initialization vectors)
5
2.2 IEEE 802.11 2 WIRELESS NETWORKING
256 bits (232 bits for the key, 24 bits for initialization vectors)
As WEP uses the PSK together with each packets initialization vector for encryp-
tion / decryption of the message, all clients within the network will be able (and
need to) decrypt every single packet. As the entire network packet is encrypted
payload, the network adapter has to decrypt it before checking the recipient of the
packet. This leads to the fact, that every single client will receive and decrypt all
the packets within the network. Devices, which are not associated to the network
will need to monitor the packets and know the PSK in order to decrypt the packets.
(Based on the attack [32] it is easily possible to retrieve the key when enough tra�c
has been captured).
• WPA / WPA2: While the standardization process of IEEE 802.11i was ongo-
ing, many manufacturers implemented a subset of the un�nished draft of WPA in
their hardware. The di�erence between WPA and WPA2 is mainly the used cipher.
While WPA uses TKIP, WPA2 uses AES for encrypting the tra�c. WPA/WPA2
both o�er two possible authentications: Pre-shared key PSK or Extensible Authen-
tication Protocol EAP. While EAP uses some authentication infrastructure and
might need additional hardware (e.g. RADIUS server), PSK is mainly used for
small wireless networks. In contrast to WEP, WPA does not use the PSK directly
for encrypting/decrypting network packets. Instead, it derives pairwise keys for
each wireless device within the network using some four-way-handshakes between
the wireless device and the access point. This usage of pairwise keys means, that
a single device typically can only decrypt (and read) the packets sent to this de-
vice (and encrypted with its personal pairwise key). Although it is possible to gain
knowledge of the other devices pairwise keys by monitoring their key exchange hand-
shakes, this makes monitoring their tra�c signi�cantly harder. Many �rmwares or
drivers of wireless network interfaces do not o�er access to these packets, as they
handle this low-level protocol and do not pass them to the operating systems. This
means, for monitoring the packets, the driver needs to be modi�ed or special hard-
ware has to be used. Devices that are associated to a WPA-encrypted network
can only read packets by monitoring the other devices' pairwise keys and have to
decrypt them manually. Devices which are not associated to the network will �rst
have to gain access to the network by performing a dictionary or brute-force attack
to break the network's PSK. Only associated they can monitor any handshakes or
packets.
6
3 INTERNET PROTOCOLS
3 Internet protocols
One of the main (and most popular) applications of wireless networks is gaining access
to the Internet. Once a device is connected to the wireless LAN, applications can use
this connection just like an Ethernet connection by sending and receiving packets via the
operating systems TCP/IP stack. On the 'application layer' (see OSI model [34]), there
is no di�erence between Ethernet and IEEE 802.11 wireless networks.
For most Internet services, there is one main protocol: The Hypertext Transfer Protocol
HTTP. It is located at the OSI layers 5-7 and has been developed and published by the
World Wide Web Consortium W3C and the Internet Engineering Task Force IETF as
a de-facto standard in RFC-2616 [4]. The security enabled HTTPS protocol has been
published later in RFC-2818 [28].
3.1 TCP/IP
TCP/IP is basically a protocol family for network communication consisting of many
protocols, with two being considered most important: While the Internet protocol IP
is the primary protocol for all host-to-host communication on the network layer, the
Transmission Control Protocol TCP is the primary protocol on the transport layer and
o�ers a reliable process-to-process communication stream.
Addressing within IP is done using IP-addresses and the communication itself is stateless.
An IP packet is generated and sent via the network without any link to other IP packets.
As IP is located on the OSI network layer, it can use either Ethernet or wireless networks
� both only work on the physical and data-link layers, so it does not make any di�erence,
which one is being used in the network.
TCP now is based on IP, which means it uses the packets and addressing IP o�ers, but
extends it for a process identi�er and enables a reliable stream via IP packets. For doing
that, TCP on the one hand uses ports for process identi�cation on a system and on the
other hand does some basic three-way-handshake to open a connection (IP is stateless and
does not o�er connections). Once established, it ensures the correct ordering of received
data and checks the integrity of the payloads by generating and checking checksums. For
more detailed information on TCP/IP see [34, chapter 6.5]
7
3.2 SSL/TLS 3 INTERNET PROTOCOLS
3.2 SSL/TLS
As neither IP nor TCP are encrypted or secured in any way, there are lots of possible
attacks on the protocols. Within a network it is very simple to inject packets to a TCP
connection or even change its contents. Transport Layer Security TLS and its prede-
cessor Secure Socket Layer SSL are are two more protocols, based on TCP connections,
that realize secured and encrypted connectivity. The most recent version 1.2 of TLS was
introduced in 2008 by the IETF [33].
TLS and SSL both use a handshake to setup a secured stream, and the handshake
basically does the following steps (some variations possible, depending on the actual
algorithm and protocol implementation used):
1. The client asks the server for a secured session
2. The server sends his digital certi�cate to the client
3. The client authenticates the certi�cate against a list of trusted certi�cate authorities
or asks the user to validate and accepting the certi�cate.
4. If the certi�cate is accepted, the client extracts the public key kpub from the certi�-
cate and generates a random symmetric key ksym.
Then he generates m = enc(ksym, kpub) and sends m to the server.
5. The server uses his secure key kpriv and computes ksym = dec(m, kpriv).
6. Both can now exchange data encrypted by the symmetric key ksym.
By the usage of digital certi�cates, which have been signed by a trusted certi�cation
authority (such as DigiCert, VeriSign and others [5]) the server's authenticity can be
validated by the user.[2]
Though SSL/TLS depending on the actual implementation and used version might not
be perfectly secure or even if there are attacks on these standards, usage of these secured
connections increases the complexity and costs of an attack signi�cantly. Often used
attacks are Man-in-the-middle attacks, which represent a special problem, because they
refer to the user as the weakest part of the protocol. So for this thesis, we assume
SSL/TLS to be secure because it is actually not possible to break it within a short period
of time.[25]
8
3.3 HTTP 3 INTERNET PROTOCOLS
Figure 2: Establishment of an SSL/TLS connection [2]
3.3 HTTP
`The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed,
collaborative, hypermedia information systems' [4].
HTTP is text-based packets and stateless. Usually, HTTP is used to communicate in
a client/server architecture. The client sends his request using an HTTP-GET packet,
which is then transported to the server using the TCP/IP protocol family. The main
application for HTTP is the Internet. First, a webclient generates a request as for data
in an HTTP packet like this:
1 GET / HTTP/1.1\ r \n
2 Host : www. goog l e . de\ r \n
3 User−Agent : Moz i l l a /5 .0 (Windows NT 6 . 1 ; WOW64; rv : 6 . 0 )
4 Gecko/20100101
5 Fi r e f ox /6 .0\ r \n
6 Accept : t ex t /html , app l i c a t i on /xhtml+xml ,
7 app l i c a t i on /xml ; q=0.9 ,∗/∗ ; q=0.8\ r \n8 Accept−Language : en−gb , en ; q=0.5\ r \n9 Accept−Encoding : gzip , d e f l a t e \ r \n
10 DNT: 1\ r \n
11 Connection : keep−a l i v e \ r \n
12 Cookie :PREF−ID=38b2axxxxc90xxxb ;13 U=fdaf9cxxxx5axxb5 ; FF=0; TM=130xxxx977 ;
14 LM=130xxxx846 ; S=qSZQvAxxxxhTMmVK; . . . \ r \n
9
3.4 HTTPS 3 INTERNET PROTOCOLS
Then he establishes a TCP connection and sends the packet as a data stream using the
connection to the server. Once a request has been received, the server loads the requested
data (or generates it) and sends it in an HTTP response packet back to the client, again
using a TCP connection.
1 HTTP/1 .1 200 OK\ r \n
2 Set−Cookie : SID=DQAAAO4AAAA8gJWYASs6dSrbmzMVH−XAv [ . . . . ] ;3 exp i r e s=Sun , 17−Jan−2038 19 : 14 : 07 GMT;
4 path=/; domain=. goog l e . com
5 Content−Type : t ex t / j a v a s c r i p t ; cha r s e t=UTF−8\r \n6 Date : Wed, 13 Jul 2011 13 : 47 : 02 GMT\ r \n
7 Expires : Wed, 13 Jul 2011 13 : 47 : 02 GMT\ r \n
8 Cache−Control : p r ivate , must−r e va l i da t e , max−age=0\r \n9 Last−Modif ied : Wed, 13 Jul 2011 13 : 47 : 02 GMT\ r \n
10 ETag : 8437283537401365564\ r \n
11 Content−Encoding : gz ip \ r \n
12 Server : i g f e \ r \n
13 Content−Length : 678\ r \n
14 X−XSS−Protec t i on : 1 ; mode=block \ r \n
15 \ r \n
16 Content−encoded en t i t y body ( gz ip ) : 678 bytes −> 1118 bytes
Especially in case of the Internet, a packet can pass lots of switches, routers or gateways,
meaning the correct ordering of the packets cannot be ensured.
These properties lead to the following problem: As HTTP is stateless, there is no reliable
stream and thereby no possibility for continuous user authentication. A server cannot
determine, if a packet was really sent by the client stated in the packet's header or by
anyone else stating a fake sender.
3.4 HTTPS
Because of the weak security properties that HTTP o�ers, an extended protocol to ensure
privacy for HTTP requests and responses has been developed. IETF introduced HTTP
Over TLS in [28], which is mostly called HTTP Secure HTTPS. It is very similar to the
HTTP protocol and basically uses the same packets for HTTP GET and POST messages,
with the main di�erence being in the underlying transport layer. While HTTP typically
uses a simple TCP connection, HTTPS uses a TLS or SSL connection for transporting the
10
3.5 Sessions 3 INTERNET PROTOCOLS
HTTP packets. This enforces the privacy of the packets and also prevents any attacker
from injecting data to the connection.
3.5 Sessions
There is one problem with these standards and protocols: HTTP does not provide any
state or reliability � but today's web services need exactly this: Users do not want to
reenter all their information for each visit of a web service. Most web services therefore
o�er some kind of state, they allow the user to register once and re-login using some
credentials the user gets from the service (or may choose by himself). The user also
expects services to store information, for example a shopping cart or a favourite song
list. The question now is: How can a web service provide stateful information, using
a stateless protocol and supporting more than one user? The answer to this question
is: They use some kind of workaround � web sessions. (Web)sessions are realized using
the application level HTTP-protocol. A session mainly is an exchange of information
between a server and a client, within a limited amount of time, more exactly between the
session's initialization and its termination. Within an open session, the web server has
the possibility to map a HTTP request to an open web session and hereby to a user.
3.5.1 Web sessions
Sessions in HTTP are relatively easy to understand: HTTP uses client requests (e.g.
sent by the browser on the user's computer) to ask the server for some data, e.g. for a
web site the user wants to access. In addition to the plain HTTP-GET he adds some
static identi�er to all his requests allowing the server to recognize the user and identify his
HTTP requests. The server responds by sending the data to the client. Using modern web
technologies, the server does not just send an HTML �le from its disk, but generates one
using its (PHP-, Java-, Groovy-, Ruby-, ..., scripts) and mostly some kind of user data.
Maybe the server also needs to check the user's authorization to access the requested
data or needs to select the appropriate dataset for this special user from its database.
Implementing sessions using HTTP then means that the server has some public data, for
example some kind of login page. Any client can request this data (e.g. the login site)
and the server responds by sending it. Together with his HTTP response, the server tells
the client a private identi�er, which the client should add to all future HTTP requests.
After the client sends his credentials together with this identi�er in a new HTTP request,
the server approves them and stores the successful login for the identi�er. If the client
11
3.5 Sessions 3 INTERNET PROTOCOLS
now requests some data, which require authentication, the server can check the identi�er,
provided with the HTTP-GET and send the data in case the identi�er is already approved.
3.5.2 Why session identi�ers should be kept private
Sessions over HTTP are quite simple � client and server know some identi�er that the
server can associate to the user, the client sends this id with every request.
But there is one main weakness in this approach: The one, who knows and uses the
identi�er, will be identi�ed as the original user. If somebody can �nd out this identi�er,
he might request information that he is not authorized to access and there is no possibility
for the server to determine the real origin of the request.
As these sessions are normally used within the Internet, the HTTP request containing the
identi�er might be sent via many parties. The user does not know the way a packet takes
and he does not know who might have access to the packets. This means, the user can
never trust the network and a miscon�guration or infection of a single router or even the
usage of a network hub can enable access to packets and thereby to other user's session
identi�ers.
Applied to wireless networks, this means, that the broadcast property of wireless networks
will allow every single device within the operational range of the wireless access point to
read these packets and steal the session identi�ers of associated users.
The reader might now ask for protection against this - there are many applications that
would have a negative impact on the user if it was that easy to steal the session identi�er
� for example banking and mail. The answer is encryption. It is easily possible to enable
SSL or TLS encrypted connections between the server and the client. Once encryption
is enabled, an attacker will not be able to read the session identi�er from the HTTP
packets even in wireless networks, because the identi�er is sent encrypted and can only
be decrypted by the web server (according to our SSL/TLS security assumptions).
3.5.3 Why most session identi�ers are not secure
Securing the session identi�er is very important and nevertheless quite simple by using
encrypted communication. So what is the problem? The problem is that many web
servers do not o�er encrypted communication using TLS. Although the importance of
keeping the session identi�er private is obvious, many web services do not o�er encrypted
connections. De�nitely, there is extra work to do for both parties when using SSL.
IBM demonstrated:
12
3.6 Cookies 3 INTERNET PROTOCOLS
Performance tests have revealed that using SSL between the agent and the
runtime server, for example, increases network tra�c three-fold, and can re-
duce the speed of response of the runtime server to agent requests by from
two to ten times, depending largely on the agent platform. This extra work at
the runtime server is actually done by the Web server, but its use of the com-
puter's resources can also have an impact on other activities that the runtime
server is performing. [19]
But on the other hand, Google revealed that doing some major improvements to
the open source SSL libraries, they could implement SSL for all their services without
adding new hardware or increasing the CPU-load of their machines. They also revealed
that using caching and resuming open sessions, there is only a slightly higher latency in
connection establishment, as only the initial handshake for SSL takes signi�cantly more
time [20].
Consequentially, reason for these poor security properties seems to be the web services'
laziness or dread to implement secure connections to their sites. Facebook for example
implemented secure connections some time ago, but users still have to explicitly activate
it.
This lack of security is a big disadvantage for the users. Even if a user would like to use
encrypted communication, he can only use it if the server o�ers it. If this is not the case,
there is no chance for the user to enable SSL/TLS for his connection.
3.6 Cookies
For implementing sessions to store state information within stateless HTTP communi-
cation, cookies have been introduced. Cookies are an extension for the HTTP protocol
and allow additional state information within HTTP packets. The cookie standard has
been published in [23]. In general, cookies are name-value pairs exchanged by HTTP
server and client using an additional HTTP header �eld. Cookies can be assigned from a
web server to a webclient using HTTP response messages and stored by the client, who
sends them within the header of all future requests. A cookie can contain any kind of
string information. Figure 3 demonstrates the HTTP communication using Set-Cookie
and Cookie.
13
3.6 Cookies 3 INTERNET PROTOCOLS
Figure 3: Usage of cookies within HTTP communication [author's illustration]
3.6.1 HTTP Response � 'Set-Cookie'
After the server received an HTTP GET request he will answer the request with an HTTP
response. This response can contain an additional header �eld called 'Set-Cookie:'. It
is followed by several name-value-pairs � the cookies. Figure 4 shows an example of an
HTTP response containing the 'Set-Cookie' �eld.
A cookies name and value is delimited by '=' and multiple cookies are separated by
';'. Cookies can also have additional information to de�ne scope, expiration date of the
cookie, security and some more. Table 1 shows some examples for additional cookie
information.
14
3.6 Cookies 3 INTERNET PROTOCOLS
�eld name functionExpires indicates the date and time of the cookies lifetimes end. The client
is not supposed to keep or send the cookie after its expiration.Max-Age indicates the maximum lifetime of the cookie in milliseconds. After
the lifetime expired, the client is not supposed to keep the cookie.Domain speci�es the hosts to which the cookie will be sent. Providing ex-
ample.com will include the cookie within every request to *.ex-ample.com/* whereas providing www.example.com only includesthe cookie within requests to any document within this structure(www.example.com but not www1.example.com)
Path each cookies scope is limited to a speci�c path structure. By defaultthis is the directory of the provided domain uri. Providing "/" willinclude the cookie within any request that matches the domain. Byaddine a folder structure the cookie will only be included if domainand path match.
Secure limits the scope of the cookie to secure connections only, usuallyindicated by usage of HTTPS. This cookie will only be sent over se-cured connections! Session cookies (cookies, which contain a sessionidenti�er) can be secured from theft by this �ag.
Table 1: Additional cookie information [extract, for full reference see [23]]
1 HTTP/1 .1 200 OK2 Cache−Control : p r ivate , no−cache , no−s to re , must−r e v a l i d a t e3 Expires : Sat , 01 Jan 2000 00 : 00 : 00 GMT4 Pragma : no−cache5 Set−Cookie : datr=fjc8TssmQYbEFTY_PavqVVS ;6 exp i r e s=Sun , 04−Aug−2013 18 : 33 : 34 GMT;7 path=/; domain=. facebook . com ; httponly8 Set−Cookie : l s d=JGIgH ; path=/;9 domain=. facebook . com
10 Content−Encoding : gz ip11 Content−Type : t ex t /html ; cha r s e t=utf−812 X−FB−Server : 1 0 . 5 2 . 1 63 . 6 513 X−Cnection : c l o s e14 Transfer−Encoding : chunked15 Date : Fri , 05 Aug 2011 18 : 33 : 34 GMT
Figure 4: Example HTTP Response using Set-Cookie
3.6.2 HTTP Request � 'Cookie'
After the server assigned the cookies via the HTTP response and stored them within
its private database, the client is expected to send the cookies according to their focus
15
3.6 Cookies 3 INTERNET PROTOCOLS
restrictions with each HTTP GET request. As most of the cookie �ags are scope infor-
mation, the client only sends the indicator for the cookie header 'Cookie:' followed by
all cookies whose scope matches the requested address. Figure 5 shows an example of an
HTTP response containing the 'Cookie' �eld.
Each name-value pair is delimited using '=', the set of cookies is separated using ';'.
1 GET /home . php HTTP/1 .12 Host : www. facebook . com3 User−Agent : Moz i l l a /5 .0 (Windows NT 6 . 1 ; WOW64; rv : 6 . 0 )4 Gecko/20100101 F i r e f ox /6 .05 Accept : t ex t /html , app l i c a t i on /xhtml+xml ,6 app l i c a t i on /xml ; q=0.9 ,∗/∗ ; q=0.87 Accept−Language : en−gb , en ; q=0.58 Accept−Encoding : gzip , d e f l a t e9 DNT: 1
10 Connection : keep−a l i v e11 Refe r e r : http ://www. facebook . com/12 Cookie : datr=EAkSTuHSFExUaKxElyefcqv0 ; lu=ggKOcxwJRySq72wsl_1wLkcA ;13 l o c a l e=en_US ; act=1311666765645%2F1 ; L=2;14 c_user=100002346916409; s c t =1311666779;15 W=1311666779; xs=1%3A965ed958ssecd2b619580eb01e12cf fb
Figure 5: Example HTTP Request using Cookie
3.6.3 Session cookies
Session cookies are just normal cookies, the only di�erence being that they contain the
session identi�er. Once the login procedure has been completed, the server sends the
session identi�er he generated using a Set-Cookie header �eld. The client is expected
to send this identi�er with each new request, so the server will grant him access to
information that might be unavailable for the public. A web site might require more
than one session cookie and one single session identi�er might be used within more than
one web site. Some web services uses the same session identi�ers for their rich-client web
site and for their mobile-device web site. This allows a user who logged in with his mobile
device on the rich-client site to access their mobile device site without having to re-login.
This also allows a potential thief of this session identi�er to use any of the web services
sites only by stealing this single set of cookies.
16
3.6 Cookies 3 INTERNET PROTOCOLS
3.6.4 Shared authentication
In order to make Internet authentication more comfortable, some big web services o�er
user authentication for web services using their platform. Shared authentication means,
that one web service can check whether the user is correctly authenticated to another
web service instead of handling credentials by itself.
Imagine Alice is a user of the famous web service A and Alice wants to use web service
B. B o�ers authentication using A's accounts. So Alice logs into her A account and grants
B some rights to access her state information within B's session. Once she enters B, B
will invisibly redirect her to some special site of A, which checks her A-session cookie.
If this check is successful, meaning her A session cookie is correct and valid, A will tell
B that Alice is successfully authenticated and Alice will be able to use her account in B
without any credentials.
There is a special standard for this kind of shared authentication, called Open Au-
thentication OAuth. OAuth is an open standard for shared authentication and is widely
used by many big web services, for example www.facebook.com [7], www.google.com [9]
and many others. The basis for this open authentication is in fact the session identi�er,
stored in the session cookies, the only di�erence is, that web service B does not need to
check the credentials itself, but ensures the credentials have already been checked by A.
This also means: If anyone can steal the session cookie from A, any check using A for
shared authentication will succeed, which in fact means, stealing one cookie will grant the
attacker access to all accounts sharing their authentication with A and even the original
web site itself.
17
4 ANDROID
4 Android
DroidSheep is built for Android powered devices, so this section should give a short
introduction about what Android is and what Android applications look like.
'Basically, Android is a software stack for mobile devices that includes an op-
erating system, middleware and key applications. The Android SDK provides
the tools and APIs necessary to begin developing applications on the Android
platform using the Java programming language.'[10]
Android o�ers runtime and SDK for application development on mobile devices, such
as phones and tablet computers.
It is based on a Linux operating system using a Linux-kernel, meaning commands, direc-
tory structure and many other things are very similar to standard Linux systems.
Android Applications are written in Java programming language and get compiled
to 'byte code'. Applications can be run within a 'Dalvik Virtual Machine'[3], which
interprets the 'byte code' on the device [6].
Figure 6 shows the general Android system architecture. DroidSheep is divided into
two parts. One part needs direct access to the system resources, such as the Linux
kernel, and is therefore located in the Android runtime itself. The runtime is a plain
Linux system, so this means this program part is not interpreted by the virtual machine
but has to be compiled for the devices ARM platform and runs as a system process. The
second part is a normal Android Java application and runs within the application layer.
4.1 Android general application structure
Most Android applications are based on the Android SDK. The Android SDK is a de-
velopment kit, which o�ers a lot of di�erent tools, a compiler and libraries for creating
Android applications. Generally, an Android application is just a plain Java program
using the well-known class and package structure Java uses.
There are only a few di�erences: As Android o�ers most of the user interface compo-
nents, user interfaces needn't be created by hand, but can be de�ned using an XML layout
descriptor. This �le is then used to generate the whole user interface of the application.
An Android application is divided into 'Activities'. Normally, each activity has a spe-
cial mission and controls the user interface and program logic for this special application.
For further information see [11]
18
4.1 Android general application structure 4 ANDROID
Figure 6: Android system architecture [10]
In order to run the application on an Android device, there is a second thing to
do: De�ning an AndroidManifest.xml �le. The AndroidManifest contains an application
de�nition telling the Android operating system, what the entry point of the program is
and which permissions it requires.
For installing an application on a device, it gets compiled to bytecode using the .dex
format (Dalvik Executable). Those dex �les are zipped together with resources and
AndroidManifest to an .apk �le (Android Package) and can be installed on an Android
device. For security reasons, most devices require the packages to be digitally signed and
will warn the user in case this package has not been downloaded from a trusted or known
source (such as the Google Android Market).
19
4.2 Dalvik virtual machine 4 ANDROID
4.2 Dalvik virtual machine
Similar to desktop Java applications, Android uses a virtual machine for interpreting the
bytecode and thereby running the applications. They do not simply use some Linux Java
VM, but use a Dalvik Virtual Machine. A Dalvik VM is a register-based virtual machine
which is designed and optimized for very low memory consumption and e�ciency when
running on mobile devices. [3]
In order to avoid security issues, each start of an Android application starts a separate
VM running only this single application.
4.3 Android security model
Android de�nes a very strict security model. Basically it uses an extended Linux security
model.[12] 'A central design point of the Android security architecture is that no applica-
tion, by default, has permission to perform any operations that would adversely impact
other applications, the operating system, or the user.' [13]
• In order to access any user data or communication functionalities, android intro-
duced 'permissions'. An application can request permissions by including a special
tag uses-permission in its AndroidManifest.xml. If an application requests special
permissions (e.g. for accessing the internet, contacts and other personal data), the
user will be prompted at installation time and only if he grants the permissions,
the application will be installed.
• Each Android application is started within a separate process. This means, there
is a separate Dalvik Virtual Machine only for this single application. By doing
this, Android prevents any kind of access to another applications' thread state or
memory within the VM.
• For each Android application, the Android OS creates a separate user. The appli-
cation then is started with the privileges of this single user, which also means, an
application can never access an other applications data or threads.
Depending on the permissions that have been requested in the AndroidManifest.xml,
the Android OS grants privileges to the user. This gives the system the possibility,
to control access to system resources for single applications.
Since normally no application runs using superuser privileges, this security system
wraps each application in its own sandbox.
20
4.3 Android security model 4 ANDROID
In general, it is possible for any application to run native processes. A process can be
started using Linux shell commands which will be executed by the Android operating
system. Any native process invoked by an application will run using the applications'
user id and privileges leading to the same restricted permissions the original Android
program has.
21
5 PREPARING THE ATTACK
5 Preparing the attack
Next, let us look at DroidSheep's attack in detail. DroidSheep listens to the associated
wireless network's tra�c and uses captured cookies for hijacking the associated sessions.
5.1 Understanding session hijacking
The previous sections introduced the basic network protocols and technologies. Figure 7
shows the ideal con�guration: There is only one client within the wireless network who
is the only one that sends and receives packets.
Figure 7: Ideal con�guration of a wireless network [author's illustration]
An HTTP request he sends will be received by the wireless access point and, using
TCP/IP routing, the packet will be forwarded to the web server. If the wireless network
is security enabled (using e.g. WPA-2 and a strong key), an attacker is not able to read
any HTTP packet and therefore cannot steal the user's session identi�er by just listening
to the network.
This con�guration is very unlikely, as a wireless network is often used to share an
Internet connection. Multiple clients are connected to the network and exchange packets
22
5.1 Understanding session hijacking 5 PREPARING THE ATTACK
with the access point. Remembering the broadcast property of wireless networks, every
client inside the network is able to read any packet, even if it is not addressed to his
network address. But without having promiscous mode enabled, a normal client device
Figure 8: Normal con�guration of a wireless network [author's illustration]
within this network will receive a packet, look at the recipient address and dismiss the
packet in case it is not him, just like shown in Figure 8.
This assumes some trust to the wireless network the user is connected to. In case of
a home network, the user might assume to have trustworthy clients in the network, as
the user normally knows the clients personally and might actually be able to control the
network and its users.
In case of a public (or unsecured personal) network, this is very di�erent. A user within
the network cannot trust any other user � he might not have any kind of knowledge about
the network or its members. If he nevertheless uses the wireless network, there might be
an attacker and the user does not have any control about his packets' way and about
who can receive them. In this case an attacker can, instead of dismissing the packets,
read the users data and reuse the information contained in the packets, demonstrated in
Figure 9.
23
5.1 Understanding session hijacking 5 PREPARING THE ATTACK
Figure 9: Capturing session cookies in a wireless network [author's illustration]
Because he does not know anything about the network and about who can read his
packets, a user cannot determine if somebody reads his data. Once the data is read, there
is no technical e�ort to extract the session identi�er from the plaintext HTTP packets
(e.g. Figure 10), meaning the attacker does not have any problems in �nding out the
session token.
1 GET / somes i t e HTTP/1.1\ r \n2 Host : www. example . com\ r \n3 Accept : t ex t /html , app l i c a t i on /xhtml+xml ,4 app l i c a t i on /xml ; q=0.9 ,∗/∗ ; q=0.8\ r \n5 Cookie : SESSION_ID=1234567890;\ r \n
Figure 10: Example of a captured HTTP request for extracting session id
If an attacker can acquire the session identi�er, he can easily reuse it. By generating
his own HTTP packets requesting the desired data (e.g. Figure 12), he can just insert
the victim's session identi�er, demonstrated in Figure 11. The server cannot distinguish
between the real attacker's packets and the victim's ones and will send the desired data
24
5.2 How to identify a web sites session cookies? 5 PREPARING THE ATTACK
Figure 11: Using captured session identi�er in a wireless network [author's illustration]
to the attacker.
DroidSheep now does this automatically. It uses promiscous mode on the Android
1 GET / s e c u r e s i t e HTTP/1.1\ r \n2 Host : www. example . com\ r \n3 Accept : t ex t /html , app l i c a t i on /xhtml+xml ,4 app l i c a t i on /xml ; q=0.9 ,∗/∗ ; q=0.8\ r \n5 Cookie : SESSION_ID=1234567890;\ r \n
Figure 12: Example of a generated HTTP request containing stolen session id
device and captures all users packets. Then it reads the HTTP requests and searches for
session identi�ers. Once it found one, it allows the user to use this session identi�er for
his requests and thereby hijack the victims account.
5.2 How to identify a web sites session cookies?
Basically, we could simply capture ALL cookies and reuse them for our requests. But
DroidSheep only wants to capture packets, containing a valid set of cookies to ensure
25
5.3 Capturing the session identi�er 5 PREPARING THE ATTACK
each entry in its session list can be used to hijack an account.
Therefore, there is only one preceding step to do: DroidSheep has to know which
combination of cookie-names is used for a certain web site. The simplest way to do that
is to apply a 'trial and error'-method using a computer and a standard web-browser:
• First, remove all cookie data from the browser
• Then create an account on the desired web service and login
• Now open the cookie-window of the browser and have a look at the listed cookies: By
subsequently deleting a single cookie and refreshing the web service in the browser
window, a session cookie can be identi�ed. If the browser is still logged in, it was
no session cookie, otherwise it was one. In this case, re-login and remove all tested
cookies and test the remaining ones. After testing all cookies, a full set (or a single)
of session cookies has been identi�ed and can be used to capture sessions.
This is an example of cookie-names DroidSheep actually uses to identify sessions:
amazon.de 1 x-acbde
facebook.com 4 c_user, datr, lu, xs
�ickr.com 1 cookie_session
twitter.com 2 auth_token, _twitter_sess
linkedin.com 2 bcookie, leo_auth_token
yahoo.com 2 T, Y
live.com 1 RPSTAuth
google.de 4 SID, NID, HSID, PREF
5.3 Capturing the session identi�er
For performing the attack, there are two steps to do: Capturing the session identi�ers
and afterwards use them for own requests.
First, the cookie has to be captured. Therefore, the wireless interface has to be put
into promiscous mode. This usually can be done by telling the driver to do this and use
some special library to tell the Linux kernel to forward all packets to the application.
Once this is done, the library receives some memory pointer to each network packet and
can read its content. Because of HTTPs statelessness, the cookies are sent with every
single HTTP request in the Cookie header �eld. So now, if the Linux kernel receives a
26
5.4 Setting session ID for own requests 5 PREPARING THE ATTACK
packet, DroidSheep has to read it and look for the Cookie header �eld. If the packet
has one, it can extract all session identi�ers it �nds. The Cookie standard [23] says, the
cookies have to be separated using the ';' char, its name and content by '='. This means,
DroidSheep can easily parse the cookie line by line and check if the cookie is one of the
session cookie names it knows.
5.4 Setting session ID for own requests
After capturing one or more session tokens, these tokens can be used to send HTTP
requests to the server. If the required tokens are provided within the HTTP headers cookie
�eld, the server will accept them and respond to the attacker's request with potentially
private or sensitive information. The attacker will be able to send requests, until the user
logs out and the session tokens will be invalidated on the server.
27
6 TECHNICAL BASICS
6 Technical basics
In this section, the technical requirements and basics for implementing the attack on
Android devices are covered.
6.1 Building native programs for Android devices
Basically, Android devices use the ARM-architecture, as its processors use a reduced in-
struction set and can hereby decrease their complexity and power consumption. Android
itself is based on Linux and uses a normal Linux kernel (e.g. Android version 2.3 uses
Kernel version 2.6.35.7). This means, an android device will be able to run any Linux
application natively, which is correctly compiled for ARM architecture to binary code.
In order to compile any Linux application, there are necessary libraries which contain
some basic funtions that are used by most Linux programs, containing for example basic
IO functionalities, kernel access and lots of other things. Not every developer should be
enforced to implement basic IO functionality himself � this would make development of
even small programs rather di�cult. This leads to default libraries for Linux, which are
used to compile any application.
One of the main libraries for Linux is libc. Libc actually contains about 200 widely
used functions which are implemented according to the respective operating system. As
Android is not a standard Linux distribution, but optimized for mobile devices, it uses a
special libc called Bionic. Bionic has been developed for Android by Google Inc. based
on libc [1]. Bionic is only half as large as libc and optimized to be very fast on limited
CPU power. Thinking about compiling native applications for Android, this means, the
compiler on the development machine has to use Bionic instead of libc for compiling the
sources to an executable. To make this easy, Google provides an Android compilation
toolchain together with a complete build environment, which can be used to compile
Android itself and any other application for Android ARM devices [14]
To use the Android build environment on an 32-bits Linux machine, the following
steps are necessary:
• installation of all required Linux packages (e.g. Java JDK, Git, GCC and others),
as described in [15]
• download of the Android source as described in [16]
28
6.2 Requirements on Android devices 6 TECHNICAL BASICS
• execution of a complete Android build using the just installed packages, explained
in [17]
Once these steps are done, the build environment is ready to compile any application for
Android devices on ARM architecture, using Bionic library.
6.2 Requirements on Android devices
Since Android OS runs on many di�erent devices, there are some requirements to run
DroidSheep. DroidSheep will use the Linux kernel to capture network packets. The
problem with the usage of the kernel is, that there are di�erent barriers between a native
application and the network device. As one of Androids main advantages is being open
source, every manufacturer of Android devices can build a custom distribution for his
devices. This means that no one can de�nitely know what hardware and software spec-
i�cations a device has. This leads to some requirements, which most devices will apply
with, because Android default con�guration does. Nevertheless, there might be some
Android con�gurations which di�er from this standard.
6.2.1 Hardware / Firmware
Primarily the devices need in any case a wireless network interface to capture packets
with. Most of the Android devices do have such an interface, but there is one requirement
to this interface: It has to support promiscuous mode. Promiscuous mode means that the
network adapter does forward all received tra�c to the operating system. Unfortunately,
there are a few wireless interfaces that do not support the promiscuous mode, which
means the adapter receives packets from other devices within the network, but the device
(or its �rmware) does not hand over these packets to the kernel. These interfaces will
not be compatible to DroidSheep, as they will only be able to read their own tra�c, and
thus do not meet the requirements for hijacking sessions.
6.2.2 Driver
The driver is another barrier between network interface and kernel. As the driver usually
applies to the features of the network interface, it should be possible to enable promiscuous
mode via the driver for all interfaces, which support promiscuous mode. Nevertheless it
can happen, that a device's driver does not allow the promiscous mode to be enabled
although the device does support it.
29
6.2 Requirements on Android devices 6 TECHNICAL BASICS
6.2.3 libpcap
In general, it would be possible to access the kernel directly, requesting the packets for
usage within a native application. But in order to simplify the program and to gain
maximum compatibility according to drivers and kernel versions, DroidSheep will use
a library called libpcap. This library contains an API for accessing the kernel's network
capabilities and o�ers some simpli�cations to the network packets layout analysis. libpcap
is part of the Android standard con�guration � thus it is most likely available on all
Android devices.
6.2.4 Android ROM / Kernel version of the device
The last step between network interface and application is the kernel. It o�ers a lot of
compile-time settings, which means the kernels behavior can be di�erent depending on
the installation [24]. For being compatible with a certain device, DroidSheep requires
the kernel to pass the network packets using the libpcap-library to its native application.
Most kernels will do this, but it might be possible that one does not. In this case,
DroidSheep will not run on that device unless it gets a kernel update which enables
support to libpcap.
6.2.5 Superuser access
A last requirement for using DroidSheep on a device is superuser access. Linux has a
very strict permission policy which restricts the usage of administrative functions. Most
administrative tasks require superuser access to the system. The superuser (or root)
does have all privileges within a Linux (and Android) system and has the possibility to
do everything on the system [22].
Normally, all applications run only with limited user privileges. This means, it can
only access �les whose security settings allow the user to read/write them. On Android
devices, by default each program is executed with a separate user. This leads to a very
granular control of every application's permissions and makes all applications run in
sandboxes. Sandbox in this case means that an application will never be able to interfere
with another application, neither by changing the other's persistent data, nor by changing
its processes or threads.
On end-user Android devices, there is no intended possibility to gain root privileges
for any application. However, on account of the fact, that many people demand root
privileges on their device, there have been many exploits of security vulnerabilities to
30
6.2 Requirements on Android devices 6 TECHNICAL BASICS
gain root access. Nowadays, nearly all versions of Android can be rooted using simple
and quite easy manuals that can be found on the Internet. As rooting a device mostly
leads to loosing the devices warranty, the user should know what he does. Accessing the
network interface can have impact on all applications running on the devices. Logically
this results in the requirement of superuser privileges for accessing the network device
via libpcap and therefore superuser access is also required for using DroidSheep.
31
7 IMPLEMENTING DROIDSHEEP
7 Implementing DroidSheep
After having discussed the basics in the previous chapters, this section gives the reader
some more information about how DroidSheep was implemented. Although the following
chapter deals with the implementation of DroidSheep, there is really source code in this
section. The aim is rather to give an overview about the application structure and the
major tasks to do.
This thesis does not provide information about compiling the program to an applica-
tion or packaging it. The reader might consult [18] for detailed information about how
to compile, package and run an Android application.
7.1 Features of the program
DroidSheeps functionality is quite simple. It allows to listen to the network for sessions.
Once it captures all required information for hijacking a session, it will inform the user
graphically by adding the session to a list. Then the user can choose which session
to hijack by simply clicking the list entry and DroidSheep will open a browser activity
containing the victim's account.
7.1.1 User interface: Listening screen
The �rst user interface is a listening screen,
in which the user can start and stop listen-
ing for sessions. This is the main Screen for
controlling DroidSheep.
Any captured session will be listed here to-
gether with an icon indicating the web site of
captured session. The user can also change
the network connectivity and change the
wireless network to listen to.
32
7.2 Structure 7 IMPLEMENTING DROIDSHEEP
7.1.2 Web screen
The second screen is a web screen. In this
view, the attacker can use the hijacked web
service using the victims identity.
By tapping a session in the list, the user
opens a context menu where he can choose
what to do. He can open the normal or if
available the mobile version of the web site.
Once selected, the web screen appears, where
he is able to navigate and use the account as
if he were logged in himself.
7.1.3 Background mode
For usability reasons, a user can start DroidSheep and keep it running in the background.
DroidSheep will notify the user by haptic and visual feedback once a new session will be
captured. This allows the attacker to use his device normally while it tries to hijack
sessions.
7.1.4 Extensible cookie list
In order to keep DroidSheep generic, the information about sessions and the corresponding
cookies are stored within an XML-�le, which can easily be extended. There is no hard-
coded information about sessions within DroidSheep. DroidSheep is able to listen to all
session-types parallel.
7.2 Structure
The program is basically divided into two main parts. As the Android Java Apps cannot
access resources outside their virtual machine, there is a Java part and a native C part.
7.2.1 native C part
In the native part of the application, there is all the logic for capturing network packets.
The native process, once started, listens to all incoming network packets and reads their
data. If the program discovers the string 'Cookies', like it is used in HTTP Requests
33
7.2 Structure 7 IMPLEMENTING DROIDSHEEP
for transferring cookie data, the program outputs all data to STDOUT until it reads a
newline '\n' which signalizes the end of the cookie string.
As mentioned earlier, DroidSheep uses its native program to capture packets. This
native program uses libpcap, a network access library provided by the kernel and by de-
fault included in any Android distribution. DroidSheep uses these functions provided by
libpcap:
function name description
pcap_lookupdev lookup function for default network interface on the de-
vice
pcap_lookupnet determines network address and subnetmask of the de-
vice
pcap_open_live starts live listening to packets received by the device
pcap_compile compiles a �lter expression to a pcap �lter
pcap_set�lter applies the compiled �lter to the actual capture
pcap_setdirection constrains the capture direction (inbound, outbound,
both)
pcap_loop starts an endless loop listening for packets and calling
callback method for each packet captured
pcap_freecode disallocates the memory for the compiled �lter
pcap_close closes the capture session
Figure 13 shows the usage of libpcap. The main task of the callback method is �ltering
the packets by looking for string 'Cookies' and only forwarding the plain cookie data to
the Java application.
This manual �ltering in a way seems unnecessary, because libpcap already o�ers
some �ltering by expressions, but these �lters cannot be used, because libpcap works on
the lower OSI-layers, which means it can �lter by TCP/IP rules (IPs, ports, hardware
addresses) but not for information on the application level � where HTTP is located.
Libpcap handles all HTTP information just as a payload to the TCP packets.
Basically, it would not be any problem to do this �ltering in Java by forwarding all
packets data. The only reason is for e�ciency � the native application will always run
faster than the interpreted Java application. As there might be lots of packets in a busy
network, this tries to avoid cpu overload.
For more information about the native C part, see commented source code (�le 'droid-
34
7.2 Structure 7 IMPLEMENTING DROIDSHEEP
interaction libpcap libpcap[ ]
DroidSheep Java app
DroidSheep Binary
Linux Kernellibpcap
[listening]
loop
shell command1:
pcap_lookupdev2:
pcap_lookupnet3:
pcap_open_live4:
pcap_compile5:
pcap_setfilter6:
pcap_setdirection7:
pcap_loop8:
print_cookies13:
cookies via STDOUT14:
packets available12:
add callback9:
check for packets10:
got packets
callback
11:
Figure 13: Sequence diagram - packet capturing using libpcap
sheep.c'), available on CD enclosed to this thesis.
35
7.3 The Java application in detail 7 IMPLEMENTING DROIDSHEEP
7.2.2 Java part
DroidSheep's second part is the main Java App which does most of the work. It handles
the graphical user interface and all user interactions, identi�es the cookie strings, i.e.
especially the mapping from cookie strings to the particular web site.
It also starts, stops and monitors the native application and con�gures Android's internal
cookie manager, which allows the usage of Androids internal browser without changing
outgoing packet's contents manually.
7.3 The Java application in detail
Knowing the native application's responsibilities, i.e. capturing cookies from network
packets and sending them via STDOUT to the Java application, we will take a closer
look at the Java part.
After launching the native process, DroidSheep uses a listening thread in Java to
poll on the native applications STDOUT. If a cookie string is received, the listening
thread passes this string to the identi�cation logic, which checks all known authentication
de�nitions for matching the new cookie string.
If there is a match, it stores the authentication in a list and shows it to the user. When
the user selects an identity from the list, DroidSheep con�gures the cookies and loads the
web site in its webview.
7.3.1 Android CookieManager
For compatibility and usability reasons, DroidSheep does not implement its own browser,
but uses the Android standard web browser component 'WebView'. Doing that, the
application can simply use the UI component that already handles web site loading,
parsing, user interactions, gestures and so on.
Usage of this component is quite simple, the application only needs to tell the com-
ponent which web site to load, so once the cookies have been captured, there is one step
to do before DroidSheep can open the web site:
It �rst has to tell the Android system the cookie values, in order to make Android send
the cookies it captured from the victim's HTTP packets.
Android o�ers a special interface for cookie handling: The class CookieManager.
CookieManager manages and synchronizes the cookies over the di�erent threads using
cookies. So DroidSheeo just has to call the CookieManager and set all the cookie values
36
7.3 The Java application in detail 7 IMPLEMENTING DROIDSHEEP
for the selected identity. In order to avoid collisions, DroidSheep tells the CookieManager
to �rst remove all cookies and afterwards set the cookies it provides.
Tests showed that there should be some time between setting the cookies and open-
ing the web site, in DroidSheep performed by a short 'Thread.sleep()' call, to let the
synchronization �nish before opening the web site.
7.3.2 Activities
Android uses so called 'Activities' for controlling user interfaces and splitting an appli-
cation into di�erent tasks. This should make applications more granular and activities
reusable [11]. DroidSheep uses two main activities, one for each user interface.
• ListenActivity is the applications entry point. The �rst thing to do is to check
the DroidSheep binary. If it is not installed, the binary is copied to the device.
Afterwards, the 'chmod 777' command is executed to ensure the �le has all necessary
Linux permissions for being executed.
When this check is �nished, the Activity shows the listening screen. The user can
now start listening for sessions or open the WiFi menu in order to change the
connected network.
• HijackActivity is started once the user selects a session from the session list
within the ListenActivity. HijackActivity loads the cookies of the selected session
and sets them to the Android CookieManager. Once this is done, it calls a short
Thread.sleep() in order to allow CookieManager to synchronize all Threads, and
shows the webview where the attacker can use the victim's session.
37
7.3 The Java application in detail 7 IMPLEMENTING DROIDSHEEP
7.3.3 Layout
The ListenActivity is the main layout of the An-
droid application. It is pretty simple and only
contains some TextViews and one button. The
main component is the session list. For the ses-
sion list, a new component was created, called
SessionListView. This new component is neces-
sary for the lists custom layout, containing the
hijacked web sites logo and the item name. Fur-
thermore by tapping an item, a dialog pops up
which allows the user to
• remove the entry from the list
• open the hijacked session
• open the hijacked session using the mobile
web site (only if a mobile web site is avail-
able and the session is interoperable be-
tween mobile and main web site)
Status indicator Start/Stop Button
session list
session element
session element
7.3.4 Classes
Source code and code comments are located on the CD (see appendix). This is only a
short overview about the implemented classes without too many technical details.
• ListenActivity is the software's entry point. It is derived from android.app.Activity
and controls the listen screen and user interactions. At the �rst start, this activity
calls SetupHelper to ensure the binary being installed correctly. The ListenActivity
also starts and stops the ListeningThread in order to make the DroidSheep binary
listen for cookies.
• SetupHelper controls the correct installation of the DroidSheep binary. It initially
copies the binary to the device and changed the application �le permissions to
execute the binary (chmod 777).
• ListenThread is a singleton implementation of a Java wrapper for the binary
application. It is used to start and kill the DroidSheep binary by executing shell
38
7.3 The Java application in detail 7 IMPLEMENTING DROIDSHEEP
droidsheep droidsheeppackage [ ]
<<constructor>>+AuthDefinition( cookieNames : ArrayList<String>, url : String, mobileurl : String, domain : String, name : String )+getAuthFromCookieString( cookieListString : String ) : Auth
AuthDefinition
<<constructor>>+Auth( cookieList : ArrayList<CookieWrapper>, url : String, mobileUrl : String )+getId() : String+getCookies() : ArrayList<CookieWrapper>+getName() : String+getUrl() : String+getMobileUrl() : String
...
Auth
#onCreate( savedInstanceState : Bundle ) : void#onStart() : void#onResume() : void#onDestroy() : void+onOptionsItemSelected( item : MenuItem ) : boolean+onContextItemSelected( item : MenuItem ) : boolean+onClick( v : View ) : void+onCreateContextMenu( menu : ContextMenu, v : View, menuInfo : ContextMenuInfo ) : void+onCreateOptionsMenu( menu : Menu ) : boolean+onKeyDown( keyCode : int, event : KeyEvent ) : boolean+click( id : int, mobilePage : boolean ) : void+onItemClick( parent : AdapterView, view : View, position : int, id : long ) : void-showDisclaimer() : void-start() : void-stop() : void-cleanup() : void-refresh() : void-networkSniffable() : boolean-updateNetworkSettings() : void-notifyUser() : void
...
ListenActivity
<<constructor>>+AuthListAdapter( authList : Hashtable<String, Auth>, context : Context )+getCount() : int+getView( position : int, convertView : View, parent : ViewGroup ) : View+getItemId( position : int ) : long+getItem( position : int ) : Auth
AuthListAdapter
...
<<constructor>>+SessionListView( context : Context )<<constructor>>+SessionListView( c : Context, attrset : AttributeSet )+refresh() : void
SessionListView
<<constructor>>+CookieWrapper( cookie : Cookie, url : String )+getCookie() : Cookie+getUrl() : String
CookieWrapper
+running : boolean = false
<<constructor>>-ListenThread( c : Context, handler : Handler )+getInstance( c : Context, handler : Handler ) : ListenThread+cleanUp() : void+reset() : void+run() : void-startProcess() : void
ListenThread
<<constructor>>+WifiChangeChecker( handler : Handler )+onReceive( context : Context, intent : Intent ) : void
WifiChangeChecker
#onCreate( savedInstanceState : Bundle ) : void#onStart() : void#onStop() : void-setupCookies() : void-setupWebView() : void+onKeyDown( keyCode : int, event : KeyEvent ) : boolean+onCreateOptionsMenu( menu : Menu ) : boolean+onOptionsItemSelected( item : MenuItem ) : boolean
...
HijackActivity
+execSUCommand( command : String ) : void+getBinaryPath( c : Context ) : String
SystemHelper
+checkPrerequisites( c : Context ) : void
SetupHelper
+handleMessage( msg : Message )
Handler
+init( c : Context ) : void-readConfig( c : Context ) : void+match( line : String ) : Auth
AuthHelper
+authList 0..*-authToHijack-authList 0..*
<<use>>
~cookieList
0..*
<<use>>
~authDefList 0..*
~singleton
<<use>>
-sessionListView
+adapter
Figure 14: Class diagram for DroidSheeps Java application
39
7.3 The Java application in detail 7 IMPLEMENTING DROIDSHEEP
commands. It also has a list of all authentication de�nitions in order to check a
cookie string to match any Authentication.
• AuthDe�nition contains the cookie and URL information of one single web ser-
vice. It de�nes the names of the cookies within a authentication. The information
for all AuthDe�nitions are located in the auth.xml resource �le and will be loaded
dynamically at each application startup.
• AuthHelper will load the AuthDe�nitions from the resource �le at startup and
contains the identi�cation logic for matching the cookie strings.
• SystemHelper enables easy execution of superuser commands. It also generates
the binary path of the DroidSheep application.
• Auth represents one authentication � which means a full set of session cookies used
for hijacking a web service identity. In addition to the cookies it contains the URLs
for the web service.
• CookieWrapper is a wrapper class for the org.apache.http.cookie.Cookie class,
which also contains the URL for each cookie.
• HijackActivity realizes the session hijacking. It is started by user interaction
in the ListenActivity and gets the desired Auth to hijack as an argument. Once
started, it takes the cookies from the Auth object and sets them to the system's
CookieManager. Afterwards it shows the system's standard WebView which con-
tains the victim's cookies.
• Wi�ChangeChecker is used in order to be informed by the system in case the
WiFi state changes (connection lost, . . . ). In this case, DroidSheep stops listening
and informs the user.
Figure 14 shows the classes in an UML diagram. Figure 15 gives an overview about the
collaboration between classes and binary while capturing sessions.
7.3.5 auth.xml
For best extensibility, DroidSheep uses an XML con�guration �le for supported web
service con�guration. This usage of XML for con�guration makes it very easy to extend
DroidSheep. The source code itself does not depend on the used web service.
40
7.3 The Java application in detail 7 IMPLEMENTING DROIDSHEEP
session capturing session capturinginteraction [ ]
droidsheep [native]
: AuthDefinition : ListenActivity : ListenThread : AuthHelper
[ ]
[ ]
loop
loop
cookie string via STDOUT3:
match6:
startProcess()1:
cleanUp()8:
shell command2:
match(line=cookiestring)4:
shell command9:
getAuthFromCookieString(cookieListString=string):""5:
authList.add(Auth)7:
Figure 15: Sequence diagram - capturing sessions
DroidSheep has a generic object for a cookie set used by a single web service called
AuthDe�nition. Once it is started, it reads the XML and creates an AuthDe�nition
object for each de�nition within the XML. After all de�nitions have been loaded, the
AuthHelper checks the de�nitions for matches, each time a cookie-string has been casted.
Actually the XML is named 'auth.xml' and it is located at the application's resource
folder.
Figure 16 shows an example for the xml structure. An AuthDe�nition has a name, a
domain and a URL. Domain describes the cookie domain, whereas the URL is the real
path to the web application which will be used within the HijackActivity. The mobileurl
is optional, it can be used for web services that o�er an optimized mobile access to their
41
7.3 The Java application in detail 7 IMPLEMENTING DROIDSHEEP
service and hereby use the same session cookies as for their rich client web site. The user
will be able to choose which one he wants to use. The cookie list contains all the names
of the cookies that are necessary for hijacking the session.
1 <?xml ve r s i on ="1.0" encoding="utf−8"?>2 <authde f i n i t i o n s >3 <auth>4 <name>facebook</name>5 <domain>facebook . com</domain>6 <url>http ://www. facebook . com</ur l>7 <mobi leur l>http ://m. facebook . com</mobi leur l>8 <cookiename>c_user</cookiename>9 <cookiename>datr</cookiename>
10 <cookiename>lu</cookiename>11 <cookiename>xs</cookiename>12 </auth>13 </au thde f i n i t i on s >
Figure 16: Example entry in auth.xml
7.3.6 Identi�cation logic
In this �rst implementation, we use a very simple approach to determine the session's
origin: An AuthDe�nition contains the names of all necessary cookies for hijacking a
session. When a cookie string is casted (the string contains all cookies from a single HTTP
request, separated using semicolon), AuthHelper checks for each de�nition whether all
required cookies are included in the cookie string. If this test is successful, the casted
string matches the de�nition.
After a successful match, the cookie string is separated and all required cookies are
extracted and stored within an Auth object.
Every Auth object represents a session, which can be hijacked.
All Auth objects are stored within a global list and can be loaded immediately after
casting or at any later time.
This method is very simple and e�cient, because there is just a simple text-matching
for each de�nition, of which there are actually less than ten. It might produce false
matches, for example if a cookie string contains the names of all cookies of one AuthDef-
inition, it will be interpreted as a match, even if it contains the names as some value.
As the probability that this occurs is relatively low, the problem can be disregarded �
although there is some room for improvement.
42
7.3 The Java application in detail 7 IMPLEMENTING DROIDSHEEP
7.3.7 AndroidManifest
AndroidManifest.xml is a required descriptor for any Android application. It de�nes
several things like the program's entry point, its available activities and some layout or
style information. It also de�nes the required permissions that are necessary in order to
run the Android application. Figure 17 shows DroidSheeps 'AndroidManifest.xml'.
• DroidSheep de�nes some general information like the application name and icon
that will be displayed on the device. This also includes information such as the
package name and the version.
• uses-sdk describes the minimim SDK version to run the application. The SDK
version is directly related to the Android OS-version, which means in this example
SDK version 7 requires Android 2.1 to run the application.
• Each activity tag de�nes an application activity. There are two activities in this
application, the main entry point is the ListenActivity. In order to tell Android
which one to show in the devices application launcher, this activity gets the action
'MAIN' in its intent-�lter, whereas the HijackActivity gets the 'VIEW' action. This
means, it cannot be started directly from Android's application launcher, but only
from the ListenActivity.
• There are also uses-permission tags within the AndroidManifest.xml. Each one
tells the system that DroidSheep requires a speci�c permission to be run, and
Android asks the user to grant these permissions when installing the application.
The �rst one is the INTERNET permission, which allows the application to access
the internet. This is required for accessing the hijacked web services. The second one
is the ACCESS_WIFI_STATE permission. This is necessary to get informed by
the system in case of WiFi state changes. There are no other permissions necessary,
as the binary DroidSheep application will run with superuser permissions, which
automatically grants all available rights to this binary application. The permission
tags are only necessary for the Java application and the permissions it uses.
43
7.3 The Java application in detail 7 IMPLEMENTING DROIDSHEEP
1 <?xml ve r s i on ="1.0" encoding="utf−8"?>2 <mani fe s t3 xmlns : android="http :// schemas . android . com/apk/ r e s / android "4 package="de . t r i e r . i n f s e c . koch . dro idsheep "5 android : vers ionCode="1"6 android : versionName="1.0">7 <app l i c a t i o n8 android : i con="@drawable/ droidsheep_square "9 android : l a b e l="@str ing /app_name">
10 <a c t i v i t y11 android : s c r e enOr i en ta t i on="po r t r a i t "12 android : name="de . t r i e r . i n f s e c . koch .13 dro idsheep . a c t i v i t i e s . L i s t enAc t i v i t y "14 android : launchMode="s i n g l e I n s t a n c e "15 android : l a b e l="@str ing /app_name"16 android : theme="@android : s t y l e /Theme . NoTitleBar">17 <intent− f i l t e r android : l a b e l="@str ing /app_name">18 <act i on android : name="android . i n t en t . a c t i on .MAIN" />19 <category android : name="android . i n t en t . category .LAUNCHER" />20 </intent− f i l t e r >21 </ac t i v i t y >22 <a c t i v i t y23 android : l a b e l="@str ing /app_name"24 android : s c r e enOr i en ta t i on="po r t r a i t "25 android : name="de . t r i e r . i n f s e c . koch .26 dro idsheep . a c t i v i t i e s . H i j a ckAct iv i ty">27 <intent− f i l t e r >28 <act i on android : name="android . i n t en t . a c t i on .VIEW" />29 <category android : name="android . i n t en t . category .DEFAULT" />30 </intent− f i l t e r >31 </ac t i v i t y >32 </app l i c a t i on>33 <uses−permis s ion android : name="android . permis s ion .INTERNET" />34 <uses−permis s ion35 android : name="android . permis s ion .ACCESS_WIFI_STATE" />36 <uses−sdk android : minSdkVersion="7"/>37 </mani fest>
Figure 17: AndroidManifest.xml
44
8 LIMITATIONS AND FUTURE WORK
8 Limitations and future work
This �rst version of DroidSheep still has some limitations. Some of them are based on
technical restrictions, some of them only need implementation and can be realized in
future work. DroidSheep has been published on Google-Code [21] using the open source
licence GNU GPLv3 [8] which allows anybody to change and improve DroidSheep.
There surely are some code improvements to be made, for example the algorithm for
session cookie identi�cation, but this section covers some general limitations based on
technical or physical surroundings.
8.1 Network association required
DroidSheep can only capture sessions within wireless networks it is associated to. This
means, the device has to have access to a wireless network and the access point will have
knowledge about the clients connection.
Furthermore, the DroidSheep device will have to know the credentials for the network.
The reason for that is a technical one: The WiFi-card's drivers normally only forward
packets of the associated network to the kernel, in order to maximize e�ciency. The
kernel will not get any packet of a network he is not connected to and therefore will not
have any CPU load caused by these packets. In fact, there is a way to receive these
packets: The WiFi-cards monitor mode. This mode forwards all packet the card receives
to the kernel and the applications can use them.
But there only is one main problem with monitor mode: Many network adapters do
not support this mode. Therefore, in order to maximize compatibility, DroidSheep does
not try to activate monitor mode. After some further investigation, there might be some
possibility to enable monitor mode, but as the well known Linux applications 'iwcon�g'
and 'ifcon�g' for enabling monitor mode are not enclosed in the standard system, this is
not as easy as on a native Linux distribution as Ubuntu or Debian.
8.2 Root access and warranty void
Because of the Linux security model, DroidSheep requires superuser access to run. With-
out these permissions, there is no access to libpcap possible and so the application cannot
cast any packet from the network. By default no Android device o�ers superuser access,
which means DroidSheep can only run on manipulated devices. Even if manipulation
(rooting) is often very easy and safe, the device's warranty gets lost and any application
45
8.3 WPA and WPA2 encrypted networks 8 LIMITATIONS AND FUTURE WORK
is able to access the system using superuser privileges. This represents a severe security
impact on the system, because an application can potentially access all even secure or
private data. The user has to trust the applications not to exploit their rights and steal
personal information or do some other potentially damaging things on the device.
8.3 WPA and WPA2 encrypted networks
Within the �rst version, DroidSheep does not support WPA or WPA2 encrypted net-
works. WPA and WPA2 use some kind of pairwise keys for communication between
access point and each client. Therefore the device cannot simply read the other device's
packets, as it can do when the network uses WEP encryption or no encryption at all.
In general, it is possible to decrypt the other devices packets within the network, as
every device can read the four-way-handshakes between the access point and the clients
and by doing this read the pairwise keys of the other devices. There basically is a
technical problem when trying this: WPA and WPA2 decryption are done in the WiFi
drivers within the kernel layer (see 6). Any packet that can be decrypted by the driver
will be sent to the kernel � and to DroidSheep � but all the other ones which cannot be
decrypted using the device's own pairwise key, will be dismissed directly inside the driver.
This leads to the fact that DroidSheep cannot access these plain packets which contain
the handshakes of the other devices or the encrypted packets without modifying the
drivers.
Because of the very di�erent devices and drivers, DroidSheep does not try to change or
modify the driver in order to avoid severe system problems and at the same time support
a maximum number of devices.
Within the last weeks, there is an Android application called 'FaceNi�' [27] which
basically does the same like DroidSheep, but also supports WPA and WPA2.
By analyzing how FaceNi� worked, I found out, that it uses ARP-Request-Poisoning.
A short introduction to this attack:
Basically, ARP is a protocol for closing the gap between OSI layer 2 and layer 3. In all
layers above and including the network layer, applications use (logical) IP addresses to
address a packet's receiver.
Below and including layer 2, the data link layer, the physical address is used, called
the MAC address, which is bound to the network interface (hardware).
What ARP does is it identi�es the corresponding MAC address for an IP address. It
therefor sends broadcast messages to all hosts within the network and asks for the mac
46
8.3 WPA and WPA2 encrypted networks 8 LIMITATIONS AND FUTURE WORK
address to tell the desired IP address. A client that receives the request and identi�es
the requested IP address as his one, responds with an ARP response, which contains his
IP address and his MAC address. In order to avoid requesting for each single packet, a
host within the network caches most of the MAC addresses with the corresponding IP
addresses in the so called ARP-Table.
Imagine a network like in Figure 19(a). There are some wireless clients in a network,
together with some wired clients and one accesspoint / Internet gateway. Most home and
small business networks look like that.
If a host within a network wants to receive an other host's tra�c, he can do some ARP
spoo�ng. What happens in case of an attack is that the attacker generates faulty ARP
responses that contain the desired IP address (in this example the one of the internet
gateway) and his own MAC address, like in �gure 19(b).
Once the responses are sent subsequently to every host within the network, the hosts
start updating their ARP tables (�gure 19(c)). Every new packet they send now contains
the attackers MAC address as destination (�gure 19(d)).
This does make sense, as the routing in switched networks is based on OSI layer 2,
which means the switch redirects the packets directly to the host who has the receiver
MAC address without checking the destination IP address.
In our example, the network switch also is a router and Internet gateway. It does not
recognize, that the destination IP-Address is his own address, but forwards the packet to
the attacker, whose MAC address is the receiver of the packet (because the hosts ARP
table is faulty).
This also means, if this is a WPA/WPA2 encrypted wireless network, that the router
decrypts the packets, looks for the destination MAC address and forwards the packet
to the attacker � who does not need to decrypt the packets himself but gets the whole
network tra�c.
Once a packet is received by the attacker, he reads the packet and uses the data he
wants to have. When the packets have been received, the attacker's Linux kernel checks
the IP address of the packet. It recognizes, that the destination IP is not his one (because
his ARP table contains the correct values) and forwards the packet � now with the correct
MAC address as receiver.
47
8.3 WPA and WPA2 encrypted networks 8 LIMITATIONS AND FUTURE WORK
Figure 18: Performing ARP-Request-Poisoning [author's illustration]
(a) Example network con�guration showing each clients ARP table
(b) Attacker sending faulty ARP responses containing the gateway IP and his MAC address
48
8.3 WPA and WPA2 encrypted networks 8 LIMITATIONS AND FUTURE WORK
(c) Clients have updated their ARP tables with the wrong entry
(d) All network tra�c gets redirected through the attackers computer
49
8.3 WPA and WPA2 encrypted networks 8 LIMITATIONS AND FUTURE WORK
But there are some disadvantages of this attack:
• It is an active attack that can be discovered. The ARP caches of all network clients
will be changed, which allows some software or people to discover a running attack
and identify the attacker within the network. The passive attack DroidSheep uses
cannot be attacked, as DroidSheep only uses the data it receives, but does not do
any changes to the network itself.
• All network tra�c will be redirected to the attacking device instead of being di-
rected to the Internet. Because of limited bandwidth and processing power of most
Android devices, there might be bandwidth problems in networks with a lot of
tra�c. This might lead to problems and slow connections for the whole network.
• By actively changing the network's con�guration, the network connections can be-
come instable when attacking the network. In case of high CPU-load of the at-
tacking device, packets can get lost and internet requests or responses can be very
slow or can completely get lost. In case the device leaves the network or is switched
o�, the other devices still have the poisoned ARP-cache and will try to send their
packets to the attacking device. If this is not reachable, their internet connectivity
will get lost until the accesspoint refreshes their ARP cache.
50
9 PREVENTING THE ATTACK
9 Preventing the attack
Finally, The most interesting question is, how to protect against stealing the session
identi�er.
In order to answere this question, we should �rst clarify the real problem:
The session identi�er should not be accessible to anyone except the client and the web
server.
What DroidSheep does is exploiting the broadcast property of wireless networks.
Wireless networks (without WPA/WPA2) do not even require any attack on the network,
because all data is sent 'over the air' to everybody in operational range.
Thus as a �rst step, it would be helpful to secure communication to the gateway
and prevent eavesdropping the connection. This could be done using a private and
protected wireless network, wired clients or even by using a VPN-tunnel to a trusted
server somewhere in the Internet.
But there still is a lack of privacy, because starting at a speci�c party the communi-
cation to the web server again is unprotected. Therefor the real solution for the problem
is a secured connection between both communication parties, meaning the client and the
web server.
The most common and secure way to do this is using the HTTPS protocol. Here
the whole payload of the packet gets encrypted which means that except the routing
information, (so the data below OSI layer 3) no data can be extracted from the network
packets. Only the two partners of the communication � the web server and the client �
can read the HTTP data and therefor the cookies remain secret.
An HTTP packet can be easily read and processed by DroidSheep and any other
application, everything within the packet is plaintext data and the cookies containing the
session identi�er can be captured without any problem.
When using HTTPS this is completely di�erent. The server and client negotiate a
symmetric key for transporting data. Without the knowledge of this key no one can
decrypt the packets and read the identi�ers.
Though, usage of HTTPS has some disadvantages:
Because of the SSL/TLS handshakes, there is a signi�cantly greater latency in establishing
the connection. Once it has been established, browsers normally cache the SSL/TLS
information and allow quick resumption of the session.
Figure 19 shows the di�erences between TCP and SSL/TLS connection establish-
ment and overhead. Whereas the TCP handshake took about 114 ms to establish the
51
9 PREVENTING THE ATTACK
connection, the SSL handshakes took 436 ms - a factor of 3.8 [30].
However, there are several ways to optimize handshakes and caching. Google could
decrease the memory and CPU-time consumption and network overhead of their SSL/TLS
implementation to a minimum and implemented always-encrypted connections to less
than one percent higher CPU load, only two percent higher network overhead and 10KB
of memory per connection. This demonstrates that the cost of SSL/TLS can be heavily
reduced. It also shows that there is not that much more e�ort necessary to decrypt and
encrypt the payload[20].
1 # Star t TCP Handshake2 00 : 00 : 00 . 000000 IP snack . home .40855 > csh . r i t . edu . https : Flags [ S ]3 00 : 00 : 00 . 114298 IP csh . r i t . edu . https > snack . home . 40855 : Flags [ S . ]4 00 : 00 : 00 . 114341 IP snack . home .40855 > csh . r i t . edu . https : Flags [ . ]5 # TCP Handshake complete .6
7 # Star t SSL Handshake .8 00 : 00 : 00 . 114769 IP snack . home .40855 > csh . r i t . edu . https : Flags [P . ]9 00 : 00 : 00 . 226456 IP csh . r i t . edu . https > snack . home . 40855 : Flags [ . ]
10 00 : 00 : 00 . 261945 IP csh . r i t . edu . https > snack . home . 40855 : Flags [ . ]11 00 : 00 : 00 . 261960 IP csh . r i t . edu . https > snack . home . 40855 : Flags [P . ]12 00 : 00 : 00 . 261985 IP snack . home .40855 > csh . r i t . edu . https : Flags [ . ]13 00 : 00 : 00 . 261998 IP snack . home .40855 > csh . r i t . edu . https : Flags [ . ]14 00 : 00 : 00 . 273284 IP snack . home .40855 > csh . r i t . edu . https : Flags [P . ]15 00 : 00 : 00 . 398473 IP csh . r i t . edu . https > snack . home . 40855 : Flags [P . ]16 00 : 00 : 00 . 436372 IP snack . home .40855 > csh . r i t . edu . https : Flags [ . ]
Figure 19: Comparison between TCP and SSL handshakes [30]
52
10 CONCLUSION
10 Conclusion
After reading this thesis, the reader should have a good overview about how easy hijacking
sessions in networks really is.
Wireless networks shout all data 'over the air' to anybody in range and are by def-
inition interceptable, but even wired networks can easily be compromised by doing a
simple ARP-Request-Poisoning attack. The reader also got a deeper insight into how
DroidSheep was implemented, what the structure of the application looks like and what
the tasks of the particular components are.
This thesis also demonstrates, how important secure connections in the Internet are
and that the costs for implementing them are much lower, than the providers of web
services claim. Thus, it is really incomprehensible why there are so many unprotected
web services in the Internet, although the rate of personal user data within the services
increases rapidly. Just because most of the Internet users do not have any technical
knowledge about 'how their Internet works', it should be the providers' duty to make it
at least possible for the users to protect themselves against these attacks.
Social networks, email and many other web services have become so important in our
lives. An attack, that gains unauthorized access to an account can therefor have a mas-
sive, negative impact on family, friendships, job.
In conclusion, it can be said that this thesis and DroidSheep hopefully help to convince
as many web service providers as possible to use or at least o�er encrypted connections
for their services.
. . . and hopefully Bob discovers how to enable HTTPS in Facebook's jungle of settings.
53
10 CONCLUSION
Appendix A: CD
The enclosed CD contains:
• This Bachelor thesis as PDF �le
• DroidSheep Java source code and Android project �les
• DroidSheep C source code and Android.mk �le for compiling
• DroidSheep APK package for installation on Android devices
• Google Android SDK for Windows and Linux
54
REFERENCES REFERENCES
References
[1] Ed Burnette. http://www.zdnet.com/blog/burnette/
patrick-brady-dissects-android/584. [Online; accessed 17-August-2011].
[2] Symantec Corporation. http://www.verisign.com/ssl/
ssl-information-center/how-ssl-security-works/. [Online; accessed 17-
August-2011].
[3] DalvikVM.com. http://www.dalvikvm.com/. [Online; accessed 17-August-2011].
[4] R. Fielding et al. Request for comments 2616 - hypertext transfer protocol � http/1.1.
http://www.ietf.org/rfc/rfc2616.txt, 1999.
[5] Mozilla Foundation. http://www.mozilla.org/projects/security/certs/
included/. [Online; accessed 17-August-2011].
[6] Bill Venners from JavaWorld.com. http://www.javaworld.com/javaworld/
jw-09-1996/jw-09-bytecodes.html. [Online; accessed 17-August-2011].
[7] Facebook Inc. https://developers.facebook.com/docs/authentication/. [On-
line; accessed 17-August-2011].
[8] Free Software Foundation Inc. http://www.gnu.org/licenses/gpl.html. [Online;
accessed 17-August-2011].
[9] Google Inc. https://code.google.com/apis/gdata/articles/oauth.html. [On-
line; accessed 17-August-2011].
[10] Google Inc. http://developer.android.com/guide/basics/what-is-android.
html. [Online; accessed 17-August-2011].
[11] Google Inc. http://developer.android.com/guide/topics/fundamentals/
activities.html. [Online; accessed 17-August-2011].
[12] Google Inc. http://developer.android.com/guide/topics/security/
security.html. [Online; accessed 17-August-2011].
[13] Google Inc. http://developer.android.com/guide/topics/security/
security.html. [Online; accessed 17-August-2011].
55
REFERENCES REFERENCES
[14] Google Inc. http://source.android.com/. [Online; accessed 17-August-2011].
[15] Google Inc. http://source.android.com/source/initializing.html. [Online;
accessed 17-August-2011].
[16] Google Inc. http://source.android.com/source/downloading.html. [Online;
accessed 17-August-2011].
[17] Google Inc. http://source.android.com/source/building.html. [Online; ac-
cessed 17-August-2011].
[18] Google Inc. http://developer.android.com/guide/developing/building/
index.html. [Online; accessed 17-August-2011].
[19] IBM Inc. http://publib.boulder.ibm.com/tividd/td/ITLM/SC32-1431-01/en_
US/HTML/tlminmst45.htm. [Online; accessed 17-August-2011].
[20] Chinmoy Kanjilal. http://techie-buzz.com/tech-news/
google-switch-ssl-cost.html. [Online; accessed 17-August-2011].
[21] Andreas Koch. https://code.google.com/p/droidsheep/. [Online; accessed 17-
August-2011].
[22] Michael Ko�er. Linux - Installation, Kon�guration, Anwendung (6. Au�.). Linux
Specials. Addison-Wesley, 2003.
[23] D. Kristol and L. Montulli. Request for comments 2965 - http state management
mechanism. http://www.ietf.org/rfc/rfc2965.txt, 2000.
[24] Greg Kroah-Hartman. Linux kernel - in a nutshell: a quick desktop reference.
O'Reilly, 2007. [Online; accessed 17-August-2011].
[25] John Leyden. http://www.theregister.co.uk/2003/02/21/crypto_attack_
against_ssl_outlined/. [Online; accessed 17-August-2011].
[26] The Institute of Electrical and Inc." Electronics Engineers. Ieee 802.11-2007, wireless
lan medium access control (mac) and physical layer (phy) speci�cations, june 2007.
http://standards.ieee.org/getieee802/download/802.11-2007.pdf, 2007.
[27] Bartosz Ponurkiewicz. http://faceniff.ponury.net/. [Online; accessed 17-
August-2011].
56
REFERENCES REFERENCES
[28] E. Rescorla. Request for comments 2818 - http over tls. http://www.ietf.org/
rfc/rfc2818.txt, 2000. [Online; accessed 17-August-2011].
[29] A. Sikora. Wireless LAN. net.com networking & communications. Addison-Wesley,
2001.
[30] Jordan Sissel. http://www.semicomplete.com/blog/geekery/ssl-latency.html.
[Online; accessed 17-August-2011].
[31] IEEE Corporate Strategy and Communications. Ieee 2010 annual report. http://
www.ieee.org/documents/ieee_annual_report_10_complete.pdf, 2011. [Online;
accessed 17-August-2011].
[32] Adam Stubble�eld, John Ioannidis, and Aviel D. Rubin. Using the �uhrer, mantin,
and shamir attack to break wep. In NDSS'02, 2002.
[33] E. Rescorla T. Dierks. Request for comments 5246 - the transport layer security (tls)
protocol, version 1.2. http://www.ietf.org/rfc/rfc5246.txt, 2008.
[34] A.S. Tanenbaum. Computer networks. Prentice Hall PTR, 2003.
57