Session hijacking with android devices

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.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)


5



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


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


�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


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.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.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


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


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


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


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.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


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


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


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


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.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


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


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


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


(c) Clients have updated their ARP tables with the wrong entry

(d) All network tra�c gets redirected through the attackers computer

49


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

http://www.zdnet.com/blog/burnette/patrick-brady-dissects-android/584

http://www.zdnet.com/blog/burnette/patrick-brady-dissects-android/584

http://www.verisign.com/ssl/ssl-information-center/how-ssl-security-works/

http://www.verisign.com/ssl/ssl-information-center/how-ssl-security-works/

http://www.dalvikvm.com/

http://www.ietf.org/rfc/rfc2616.txt

http://www.mozilla.org/projects/security/certs/included/

http://www.mozilla.org/projects/security/certs/included/

http://www.javaworld.com/javaworld/jw-09-1996/jw-09-bytecodes.html

http://www.javaworld.com/javaworld/jw-09-1996/jw-09-bytecodes.html

https://developers.facebook.com/docs/authentication/

http://www.gnu.org/licenses/gpl.html

https://code.google.com/apis/gdata/articles/oauth.html

http://developer.android.com/guide/basics/what-is-android.html

http://developer.android.com/guide/basics/what-is-android.html

http://developer.android.com/guide/topics/fundamentals/activities.html

http://developer.android.com/guide/topics/fundamentals/activities.html

http://developer.android.com/guide/topics/security/security.html





[14] Google Inc. http://source.android.com/. [Online; accessed 17-August-2011].

[15] Google Inc. http://source.android.com/source/initializing.html. [Online;


[16] Google Inc. http://source.android.com/source/downloading.html. [Online;


[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

http://source.android.com/

http://source.android.com/source/initializing.html

http://source.android.com/source/downloading.html

http://source.android.com/source/building.html

http://developer.android.com/guide/developing/building/index.html

http://developer.android.com/guide/developing/building/index.html

http://publib.boulder.ibm.com/tividd/td/ITLM/SC32-1431-01/en_US/HTML/tlminmst45.htm

http://publib.boulder.ibm.com/tividd/td/ITLM/SC32-1431-01/en_US/HTML/tlminmst45.htm

http://techie-buzz.com/tech-news/google-switch-ssl-cost.html

http://techie-buzz.com/tech-news/google-switch-ssl-cost.html

https://code.google.com/p/droidsheep/


http://www.theregister.co.uk/2003/02/21/crypto_attack_against_ssl_outlined/

http://www.theregister.co.uk/2003/02/21/crypto_attack_against_ssl_outlined/

http://standards.ieee.org/getieee802/download/802.11-2007.pdf

http://faceniff.ponury.net/


[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;


[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



http://www.semicomplete.com/blog/geekery/ssl-latency.html

http://www.ieee.org/documents/ieee_annual_report_10_complete.pdf

http://www.ieee.org/documents/ieee_annual_report_10_complete.pdf


Session hijacking with android devices

Documents

Transcript of Session hijacking with android devices