Session Hijacking With Android Devices

Information Security and Cryptography
University of Trier
Bachelor Thesis
Session Hijacking on Android Devices
Andreas Koch
August 2011
by
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
Erkrung zur Bachelorarbeit

Hiermit erklre ich, dass ich diese Bachelorarbeit selbststndig 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 Prfungsamt in gleicher oder vergleichbarer Form vorgelegt. Sie wurde bisher nicht verentlicht.
Datum
Unterschrift
Contents
1 Introduction 2 Wireless Networking
2.1 2.2 Wireless LAN How it works . . . . . . . . . . . . . . . . . . . . . . . . IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 2.2.2 Transport standards . . . . . . . . . . . . . . . . . . . . . . . . . Security standards . . . . . . . . . . . . . . . . . . . . . . . . . .
1 3
3 4 5 5
3 Internet protocols
3.1 3.2 3.3 3.4 3.5 TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SSL/TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.1 3.5.2 3.5.3 3.6 3.6.1 3.6.2 3.6.3 3.6.4 Web sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Why session identiers should be kept private . . . . . . . . . . . Why most session identiers are not secure . . . . . . . . . . . . . HTTP Response 'Set-Cookie' . . . . . . . . . . . . . . . . . . . HTTP Request 'Cookie' . . . . . . . . . . . . . . . . . . . . . . Session cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . Shared authentication . . . . . . . . . . . . . . . . . . . . . . . .
7
7 8 9 10 11 11 12 12 13 14 15 16 17
Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Android
4.1 4.2 4.3 Android general application structure . . . . . . . . . . . . . . . . . . . . Dalvik virtual machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . Android security model . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
18 20 20
5 Preparing the attack

5.1 5.2 5.3 5.4 Understanding session hijacking . . . . . . . . . . . . . . . . . . . . . . . How to identify a web sites session cookies? . . . . . . . . . . . . . . . . Capturing the session identier . . . . . . . . . . . . . . . . . . . . . . . Setting session ID for own requests . . . . . . . . . . . . . . . . . . . . .
22
22 25 26 27
6 Technical basics
6.1 6.2 Building native programs for Android devices . . . . . . . . . . . . . . . Requirements on Android devices . . . . . . . . . . . . . . . . . . . . . . 6.2.1 6.2.2 6.2.3 6.2.4 6.2.5 Hardware / Firmware . . . . . . . . . . . . . . . . . . . . . . . . . Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . libpcap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Android ROM / Kernel version of the device . . . . . . . . . . . . Superuser access . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
28 29 29 29 30 30 30
7 Implementing DroidSheep
7.1 Features of the program . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1.1 7.1.2 7.1.3 7.1.4 7.2 7.2.1 7.2.2 7.3 7.3.1 7.3.2 7.3.3 7.3.4 7.3.5 7.3.6 7.3.7 User interface: Listening screen . . . . . . . . . . . . . . . . . . . Web screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Background mode . . . . . . . . . . . . . . . . . . . . . . . . . . . Extensible cookie list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . native C part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Java part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Android CookieManager . . . . . . . . . . . . . . . . . . . . . . . Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . auth.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Identication logic . . . . . . . . . . . . . . . . . . . . . . . . . . AndroidManifest . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
32 32 33 33 33 33 33 36 36 36 37 38 38 40 42 43
Structure
The Java application in detail . . . . . . . . . . . . . . . . . . . . . . . .
8 Limitations and future work

8.1 8.2 8.3 Network association required . . . . . . . . . . . . . . . . . . . . . . . . . Root access and warranty void . . . . . . . . . . . . . . . . . . . . . . . . WPA and WPA2 encrypted networks . . . . . . . . . . . . . . . . . . . .
45
45 45 46
9 Preventing the attack 10 Conclusion
51 53
1 INTRODUCTION
1 Introduction
Maybe you know Bob. Bob is a well known person and Bob loves coee. Every morning, he takes his laptop and visits one the famous green coee bars, has a 'grande vanilla latte' and writes messages to his Facebook friends. For doing that, Bob uses the coee bars' WiFi because it's free and fast. One morning, Bob is just writing a message to his girlfriend, Eve enters the coee 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 getting 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 trac 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 oering 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 oer 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 application 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 WIRELESS NETWORKING
2 Wireless Networking
In general, wireless LAN (Local Area Network) means any kind of standardized technology, which enables communication of two or more devices without any wired connection [29]. Most of the wireless technologies use electromagnetical waves within specied frequency bands. There are lots of regulatory authorities for usage of radio (e.g. The "`Federal Communications Commission"' in the U.S., the "`European Conference for Posts and Telecommunications"' in Europe and some more around the world), which means selection 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 dierent 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 benet of humanity'. [31] Since the year 1980 the IEEE develops a well known group of standards 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 inherently 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 oer 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
(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 dierent (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 specied 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 ecient modulation and radio techniques, with the main focus being on increasing connection payload. [29]
2.2 IEEE 802.11
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 dier in the radio frequencies they use, modulation techniques, operating distances and bandwidth. Standard 802.11a 802.11b 802.11g 802.11n frequency band 5 GHz 2.4 GHz 2.4 GHz 2.4 GHz & 5 GHz data rate (theo.) 54 MBit/s 11 MBit/s 54 MBit/s 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 dened a security technique called Wired 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 insucient 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
unnished draft for wireless LAN security IEEE 802.11i in 2003. IEEE 802.11i was nished and ratied 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 dierent kinds of WEP, which use dierent key sizes
64 bits (40 bits for the key, 24 bits for initialization vectors) 128 bits (104 bits for the key, 24 bits for initialization vectors)
2.2 IEEE 802.11
256 bits (232 bits for the key, 24 bits for initialization vectors) As WEP uses the PSK together with each packets initialization vector for encryption / 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 trac has been captured).
WPA / WPA2: While the standardization process of IEEE 802.11i was ongoing, many manufacturers implemented a subset of the unnished draft of WPA in their hardware. The dierence between WPA and WPA2 is mainly the used cipher. While WPA uses TKIP, WPA2 uses AES for encrypting the trac. WPA/WPA2 both oer two possible authentications: Pre-shared key PSK or Extensible Authentication 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 device (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 handshakes, this makes monitoring their trac signicantly harder. Many rmwares or drivers of wireless network interfaces do not oer 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 modied or special hardware 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 dierence between Ethernet and IEEE 802.11 wireless networks. For most Internet services, there is one main 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].
The Hypertext Transfer Protocol
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 oers a reliable process-to-process communication stream.
Transmission Control Protocol TCP is the primary protocol on the transport layer and
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 dierence, which one is being used in the network. TCP now is based on IP, which means it uses the packets and addressing IP oers, but extends it for a process identier and enables a reliable stream via IP packets. For doing that, TCP on the one hand uses ports for process identication on a system and on the other hand does some basic three-way-handshake to open a connection (IP is stateless and does not oer 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]
3.2 SSL/TLS
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. cessor
Secure Socket Layer SSL are are two more protocols, based on TCP connections,
Transport Layer Security TLS and its prede-
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 certicate to the client 3. The client authenticates the certicate against a list of trusted certicate authorities or asks the user to validate and accepting the certicate. 4. If the certicate is accepted, the client extracts the public key kpub from the certicate 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 certicates, which have been signed by a trusted certication 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 signicantly. 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
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:

GET / HTTP/ 1 . 1 \ r \n Host : www. g o o g l e . de \ r \n User Agent : M o z i l l a / 5 . 0 ( Windows NT 6 . 1 ; WOW64; rv : 6 . 0 ) Gecko /20100101 F i r e f o x / 6 . 0 \ r \n Accept : t e x t / html , a p p l i c a t i o n / xhtml+xml , a p p l i c a t i o n /xml ; q = 0 . 9 , / ; q =0.8\ r \n Accept Language : engb , en ; q =0.5\ r \n Accept Encoding : g z i p , d e f l a t e \ r \n DNT: 1\ r \n Connection : keep a l i v e \ r \n Cookie : PREF ID=38b2axxxxc90xxxb ; U=f d a f 9 c x x x x 5 a x x b 5 ; FF=0; TM=130xxxx977 ; LM=130xxxx846 ; S=qSZQvAxxxxhTMmVK ; . . . \ r \n
! " # $ % & ' ! "
3.4 HTTPS
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.

HTTP/ 1 . 1 200 OK\ r \n Set Cookie : SID=DQAAAO4AAAA8gJWYASs6dSrbmzMVH XAv [ . . . . ] ; e x p i r e s=Sun , 17 Jan 2038 1 9 : 1 4 : 0 7 GMT; path =/; domain =. g o o g l e . com Content Type : t e x t / j a v a s c r i p t ; c h a r s e t=UTF8\ r \n Date : Wed, 13 J u l 2011 1 3 : 4 7 : 0 2 GMT\ r \n E x p i r e s : Wed, 13 J u l 2011 1 3 : 4 7 : 0 2 GMT\ r \n CacheC o n t r o l : p r i v a t e , must r e v a l i d a t e , maxage=0\ r \n Last M o d i f i e d : Wed, 13 J u l 2011 1 3 : 4 7 : 0 2 GMT\ r \n ETag : 8437283537401365564\ r \n Content Encoding : g z i p \ r \n S e r v e r : i g f e \ r \n Content Length : 678\ r \n XXSS P r o t e c t i o n : 1 ; mode=b l o c k \ r \n \ r \n Content encoded e n t i t y body ( g z i p ) : 678 b y t e s > 1118 b y t e s
! " # $ % & ' ! " # $
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 oers, an extended protocol to ensure privacy for HTTP requests and responses has been developed. IETF introduced
Over TLS in [28], which is mostly called HTTP Secure HTTPS. It is very similar to the
with the main dierence being in the underlying transport layer. While HTTP typically
HTTP
HTTP protocol and basically uses the same packets for HTTP GET and POST messages, uses a simple TCP connection, HTTPS uses a TLS or SSL connection for transporting the 10
3.5 Sessions
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 oer 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 identier 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 identier, which the client should add to all future HTTP requests. After the client sends his credentials together with this identier in a new HTTP request, the server approves them and stores the successful login for the identier. If the client 11
3.5 Sessions
now requests some data, which require authentication, the server can check the identier, provided with the HTTP-GET and send the data in case the identier is already approved.
3.5.2 Why session identiers should be kept private

Sessions over HTTP are quite simple client and server know some identier 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 identier, will be identied as the original user. If somebody can nd out this identier, 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 identier 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 misconguration 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 identiers. 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 identiers 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 identier 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 identier from the HTTP packets even in wireless networks, because the identier 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 identiers are not secure

Securing the session identier 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 oer encrypted communication using TLS. Although the importance of keeping the session identier private is obvious, many web services do not oer encrypted connections. Denitely, there is extra work to do for both parties when using SSL. IBM demonstrated: 12
3.6 Cookies
Performance tests have revealed that using SSL between the agent and the runtime server, for example, increases network trac three-fold, and can reduce 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 computer'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 signicantly 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 oers 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 communication, 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 and
Cookie.
Set-Cookie
13
3.6 Cookies
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 dene scope, expiration date of the cookie, security and some more. Table 1 shows some examples for additional cookie information.
14
3.6 Cookies
eld name Expires Max-Age Domain
function indicates the date and time of the cookies lifetimes end. The client is not supposed to keep or send the cookie after its expiration. indicates the maximum lifetime of the cookie in milliseconds. After the lifetime expired, the client is not supposed to keep the cookie. species the hosts to which the cookie will be sent. Providing example.com will include the cookie within every request to *.example.com/* whereas providing www.example.com only includes the cookie within requests to any document within this structure (www.example.com but not www1.example.com) each cookies scope is limited to a specic path structure. By default this is the directory of the provided domain uri. Providing "/" will include the cookie within any request that matches the domain. By addine a folder structure the cookie will only be included if domain and path match. limits the scope of the cookie to secure connections only, usually indicated by usage of HTTPS. This cookie will only be sent over secured connections! Session cookies (cookies, which contain a session identier) can be secured from theft by this ag.
Path
Secure
Table 1: Additional cookie information [extract, for full reference see [23]]
! " # $ % & ' ! " #
HTTP/ 1 . 1 200 OK CacheC o n t r o l : p r i v a t e , nocache , no s t o r e , must r e v a l i d a t e E x p i r e s : Sat , 01 Jan 2000 0 0 : 0 0 : 0 0 GMT Pragma : noc a c h e Set Cookie : d a t r=fjc8TssmQYbEFTY_PavqVVS ; e x p i r e s=Sun , 04Aug 2013 1 8 : 3 3 : 3 4 GMT; path =/; domain =. f a c e b o o k . com ; h t t p o n l y Set Cookie : l s d=JGIgH ; path =/; domain =. f a c e b o o k . com Content Encoding : g z i p Content Type : t e x t / html ; c h a r s e t=u t f 8 XFBS e r v e r : 1 0 . 5 2 . 1 6 3 . 6 5 XC n e c t i o n : c l o s e T r a n s f e r Encoding : chunked Date : Fri , 05 Aug 2011 1 8 : 3 3 : 3 4 GMT
Figure 4: Example HTTP Response using Set-Cookie
3.6.2 HTTP Request 'Cookie'

After the server assigned the cookies via the HTTP response and stored them within its private database, the client is expected to send the cookies according to their focus 15
3.6 Cookies
restrictions with each HTTP GET request. As most of the cookie ags are scope information, 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 ';'.
! " # $ % & ' ! " #
GET /home . php HTTP/ 1 . 1 Host : www. f a c e b o o k . com User Agent : M o z i l l a / 5 . 0 ( Windows NT 6 . 1 ; WOW64; rv : 6 . 0 ) Gecko /20100101 F i r e f o x / 6 . 0 Accept : t e x t / html , a p p l i c a t i o n / xhtml+xml , a p p l i c a t i o n /xml ; q = 0 . 9 , / ; q =0.8 Accept Language : engb , en ; q =0.5 Accept Encoding : g z i p , d e f l a t e DNT: 1 Connection : keep a l i v e R e f e r e r : h t t p : / /www. f a c e b o o k . com/ Cookie : d a t r=EAkSTuHSFExUaKxElyefcqv0 ; l u=ggKOcxwJRySq72wsl_1wLkcA ; l o c a l e=en_US ; a c t =1311666765645%2F1 ; L=2; c_user =100002346916409; s c t =1311666779; W=1311666779; xs=1%3A 9 6 5 e d 9 5 8 s s e c d 2 b 6 1 9 5 8 0 e b 0 1 e 1 2 c f f b
Figure 5: Example HTTP Request using Cookie
3.6.3 Session cookies

Session cookies are just normal cookies, the only dierence being that they contain the session identier. Once the login procedure has been completed, the server sends the session identier he generated using a Set-Cookie header eld. The client is expected to send this identier 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 identier might be used within more than one web site. Some web services uses the same session identiers 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 identier to use any of the web services sites only by stealing this single set of cookies.
16
3.6 Cookies
3.6.4 Shared authentication

In order to make Internet authentication more comfortable, some big web services oer 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 oers 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
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 identier, stored in the session cookies, the only dierence 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 web site itself.
Open Au-
all accounts sharing their authentication with A and even the original
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 operating 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 oers 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, directory 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 development kit, which oers a lot of dierent 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 dierences: As Android oers most of the user interface components, user interfaces needn't be created by hand, but can be dened 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 special 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: Dening an AndroidManifest.xml le. The AndroidManifest contains an application denition 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 eciency 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 denes 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 application, 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 introduced '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 application 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 trac 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 conguration: There is only one client within the wireless network who is the only one that sends and receives packets.
Figure 7: Ideal conguration 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 identier by just listening to the network. This conguration 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
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 conguration 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 dierent. 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
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 eort to extract the session identier from the plaintext HTTP packets (e.g. Figure 10), meaning the attacker does not have any problems in nding out the session token.
GET / s o m e s i t e HTTP/ 1 . 1 \ r \n Host : www. example . com\ r \n Accept : t e x t / html , a p p l i c a t i o n / xhtml+xml , a p p l i c a t i o n /xml ; q = 0 . 9 , / ; q =0.8\ r \n 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 identier, 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 identier, 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?
Figure 11: Using captured session identier in a wireless network [author's illustration] to the attacker. DroidSheep now does this automatically. It uses promiscous mode on the Android
! " #
GET / s e c u r e s i t e HTTP/ 1 . 1 \ r \n Host : www. example . com\ r \n Accept : t e x t / html , a p p l i c a t i o n / xhtml+xml , a p p l i c a t i o n /xml ; q = 0 . 9 , / ; q =0.8\ r \n 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 identiers. Once it found one, it allows the user to use this session identier 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 identier
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 identied. 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 identied and can be used to capture sessions.
This is an example of cookie-names DroidSheep actually uses to identify sessions: amazon.de facebook.com ickr.com twitter.com linkedin.com yahoo.com live.com google.de 1 4 1 2 2 2 1 4 x-acbde c_user, datr, lu, xs cookie_session auth_token, _twitter_sess bcookie, leo_auth_token T, Y RPSTAuth SID, NID, HSID, PREF
5.3 Capturing the session identier

For performing the attack, there are two steps to do: Capturing the session identiers 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
packet, DroidSheep has to read it and look for the Cookie header eld. If the packet has one, it can extract all session identiers 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 instruction 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 dicult. 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.

Since Android OS runs on many dierent 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 dierent 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 denitely know what hardware and software specications a device has. This leads to some requirements, which most devices will apply with, because Android default conguration does. Nevertheless, there might be some Android congurations which dier 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 trac 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 trac, 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 TECHNICAL BASICS
6.2.3 libpcap
In general, it would be possible to access the kernel directly, requesting the packets for usage within a native application. But in order to simplify the program and to gain maximum compatibility according to drivers and kernel versions, DroidSheep will use a library called
libpcap. This library contains an API for accessing the kernel's network
capabilities and oers some simplications to the network packets layout analysis. libpcap is part of the Android standard conguration 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 oers a lot of compile-time settings, which means the kernels behavior can be dierent depending on the installation [24]. For being compatible with a certain device, DroidSheep requires the kernel to pass the network packets using the libpcap-library to its native application. Most kernels will do this, but it might be possible that one does not. In this case, DroidSheep will not run on that device unless it gets a kernel update which enables support to libpcap.
6.2.5 Superuser access

A last requirement for using DroidSheep on a device is superuser access. Linux has a very strict permission policy which restricts the usage of administrative functions. Most administrative tasks require
superuser access to the system. The superuser (or root )
does have all privileges within a Linux (and Android) system and has the possibility to do everything on the system [22]. Normally, all applications run only with limited user privileges. This means, it can only access les whose security settings allow the user to read/write them. On Android devices, by default each program is executed with a separate user. This leads to a very granular control of every application's permissions and makes all applications run in sandboxes. Sandbox in this case means that an application will never be able to interfere with another application, neither by changing the other's persistent data, nor by changing its processes or threads. On end-user Android devices, there is no intended possibility to gain root privileges for any application. However, on account of the fact, that many people demand root privileges on their device, there have been many exploits of security vulnerabilities to 30
6 TECHNICAL BASICS
gain root access. Nowadays, nearly all versions of Android can be
rooted using simple
and quite easy manuals that can be found on the Internet. As rooting a device mostly leads to loosing the devices warranty, the user should know what he does. Accessing the network interface can have impact on all applications running on the devices. Logically this results in the requirement of superuser privileges for accessing the network device via libpcap and therefore superuser access is also required for using DroidSheep.
31
7 IMPLEMENTING DROIDSHEEP
7 Implementing DroidSheep
After having discussed the basics in the previous chapters, this section gives the reader some more information about how DroidSheep was implemented. Although the following chapter deals with the implementation of DroidSheep, there is really source code in this section. The aim is rather to give an overview about the application structure and the major tasks to do. This thesis does not provide information about compiling the program to an application 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 listening for sessions. This is the main Screen for controlling DroidSheep. Any captured session will be listed here together 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.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 hardcoded information about sessions within DroidSheep. DroidSheep is able to listen to all session-types parallel.
7.2 Structure
The program is basically divided into two main parts. As the Android Java Apps cannot access resources outside their virtual machine, there is a Java part and a native C part.
7.2.1 native C part

In the native part of the application, there is all the logic for capturing network packets. The native process, once started, listens to all incoming network packets and reads their data. If the program discovers the string 'Cookies', like it is used in HTTP Requests
33
7.2 Structure
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: function name pcap_lookupdev pcap_lookupnet pcap_open_live pcap_compile pcap_setlter pcap_setdirection pcap_loop pcap_freecode pcap_close description lookup function for default network interface on the device determines network address and subnetmask of the device starts live listening to packets received by the device compiles a lter expression to a pcap lter applies the compiled lter to the actual capture constrains the capture direction (inbound, outbound, both) starts an endless loop listening for packets and calling callback method for each packet captured disallocates the memory for the compiled lter closes the capture session
libpcap, a network access library provided by the kernel and by de-
fault included in any Android distribution. DroidSheep uses these functions provided by
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 oers 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 eciency the native application will always run faster than the interpreted Java application. As there might be lots of packets in a busy network, this tries to avoid cpu overload. For more information about the native C part, see commented source code (le 'droid-
34
7.2 Structure
interaction libpcap [ libpcap ]
DroidSheep Java app 1: shell command DroidSheep Binary 2: pcap_lookupdev
libpcap
Linux Kernel
3: pcap_lookupnet
4: pcap_open_live
5: pcap_compile
6: pcap_setfilter
7: pcap_setdirection
8: pcap_loop 9: add callback
loop [listening] 11: got packets
10: check for packets 12: packets available callback 13: print_cookies 14: cookies via STDOUT
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.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, identies 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 congures Android's internal cookie manager, which allows the usage of Androids internal browser without changing outgoing packet's contents manually.

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 identication logic, which checks all known authentication denitions 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 congures 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 component 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 oers a special interface for cookie handling: The class
CookieManager.
CookieManager manages and synchronizes the cookies over the dierent 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 opening 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 application into dierent 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 Android application. It is pretty simple and only contains some TextViews and one button. The main component is the session list. For the session list, a new component was created, called SessionListView. This new component is necessary for the lists custom layout, containing the hijacked web sites logo and the item name. Furthermore by tapping an item, a dialog pops up which allows the user to
session list session element session element
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 available and the session is interoperable between mobile and main web site)
Status indicator
Start/Stop Button
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

package droidsheep [
droidsheep ]
ListenActivity
#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
...
WifiChangeChecker
<<constructor>>+WifiChangeChecker( handler : Handler ) +onReceive( context : Context, intent : Intent ) : void
Handler
+handleMessage( msg : Message )
<<use>>
SetupHelper
+checkPrerequisites( c : Context ) : void
-sessionListView SessionListView
...
<<constructor>>+SessionListView( context : Context ) <<constructor>>+SessionListView( c : Context, attrset : AttributeSet ) +refresh() : void
HijackActivity
#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
...
+adapter AuthListAdapter
<<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
CookieWrapper
<<constructor>>+CookieWrapper( cookie : Cookie, url : String ) ~cookieList +getCookie() : Cookie 0..* +getUrl() : String
~singleton ListenThread
+running : boolean = false <<constructor>>-ListenThread( c : Context, handler : Handler ) +getInstance( c : Context, handler : Handler ) : ListenThread +cleanUp() : void +reset() : void +run() : void -startProcess() : void
-authList 0..*
-authToHijack Auth
+authList 0..*
<<use>>
<<constructor>>+Auth( cookieList : ArrayList<CookieWrapper>, url : String, mobileUrl : String ) +getId() : String +getCookies() : ArrayList<CookieWrapper> +getName() : String +getUrl() : String +getMobileUrl() : String
...
SystemHelper <<use>>
+execSUCommand( command : String ) : void +getBinaryPath( c : Context ) : String
AuthHelper
+init( c : Context ) : void -readConfig( c : Context ) : void +match( line : String ) : Auth
~authDefList 0..* AuthDefinition

<<constructor>>+AuthDefinition( cookieNames : ArrayList<String>, url : String, mobileurl : String, domain : String, name : String ) +getAuthFromCookieString( cookieListString : String ) : Auth
Figure 14: Class diagram for DroidSheeps Java application
39
commands. It also has a list of all authentication denitions in order to check a cookie string to match any Authentication.
AuthDenition contains the cookie and URL information of one single web service. It denes the names of the cookies within a authentication. The information for all AuthDenitions are located in the auth.xml resource le and will be loaded dynamically at each application startup. AuthHelper will load the AuthDenitions from the resource le at startup and contains the identication 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 contains the victim's cookies. WiChangeChecker 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 conguration le for supported web service conguration. This usage of XML for conguration makes it very easy to extend DroidSheep. The source code itself does not depend on the used web service. 40

interaction session capturing[ session capturing ]
: ListenActivity
: ListenThread
: AuthHelper
: AuthDefinition
1: startProcess()
droidsheep [native]
2: shell command
loop [] 3: cookie string via STDOUT
4: match(line=cookiestring) loop [] 5: getAuthFromCookieString(cookieListString=string):""
6: match 7: authList.add(Auth)
8: cleanUp()
9: shell command
Figure 15: Sequence diagram - capturing sessions DroidSheep has a generic object for a cookie set used by a single web service called AuthDenition. Once it is started, it reads the XML and creates an AuthDenition object for each denition within the XML. After all denitions have been loaded, the AuthHelper checks the denitions 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 AuthDenition 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 oer 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.
! " # $ % & ' !
<?xml v e r s i o n ="1.0" e n c o d i n g="u t f 8"?> <a u t h d e f i n i t i o n s > <auth> <name>f a c e b o o k </name> <domain>f a c e b o o k . com</domain> h t t p : / /www. f a c e b o o k . com <m o b i l e u r l >h t t p : / /m. f a c e b o o k . com</m o b i l e u r l > <cookiename>c_user </cookiename> <cookiename>datr </cookiename> <cookiename>lu </cookiename> <cookiename>xs </cookiename> </auth> </ a u t h d e f i n i t i o n s >
Figure 16: Example entry in auth.xml
7.3.6 Identication logic

In this rst implementation, we use a very simple approach to determine the session's origin: An AuthDenition 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 denition whether all required cookies are included in the cookie string. If this test is successful, the casted string matches the denition. 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 ecient, because there is just a simple text-matching for each denition, 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 AuthDefinition, 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 denes several things like the program's entry point, its available activities and some layout or style information. It also denes the required permissions that are necessary in order to run the Android application. Figure 17 shows DroidSheeps 'AndroidManifest.xml'.
DroidSheep denes 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 denes 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 specic 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

! " # $ % & ' ! " # $ % & ' ! " # $ % & ' ! ! ! !! !" !# !$ !%
<?xml v e r s i o n ="1.0" e n c o d i n g="u t f 8"?> <m a n i f e s t xmlns : a n d r o i d="h t t p : / / schemas . a n d r o i d . com/ apk / r e s / a n d r o i d " package="de . t r i e r . i n f s e c . koch . d r o i d s h e e p " a n d r o i d : v e r s i o n C o d e ="1" a n d r o i d : versionName ="1.0"> <a p p l i c a t i o n a n d r o i d : i c o n="@drawable / d r o i d s h e e p _ s q u a r e " a n d r o i d : l a b e l ="@ s t r i n g /app_name"> <a c t i v i t y a n d r o i d : s c r e e n O r i e n t a t i o n =" p o r t r a i t " a n d r o i d : name="de . t r i e r . i n f s e c . koch . droidsheep . a c t i v i t i e s . ListenActivity " a n d r o i d : launchMode=" s i n g l e I n s t a n c e " a n d r o i d : l a b e l ="@ s t r i n g /app_name" a n d r o i d : theme="@android : s t y l e /Theme . NoTitleBar"> <a c t i o n a n d r o i d : name="a n d r o i d . i n t e n t . a c t i o n .MAIN" /> <c a t e g o r y a n d r o i d : name="a n d r o i d . i n t e n t . c a t e g o r y .LAUNCHER" /> </ a c t i v i t y > <a c t i v i t y a n d r o i d : l a b e l ="@ s t r i n g /app_name" a n d r o i d : s c r e e n O r i e n t a t i o n =" p o r t r a i t " a n d r o i d : name="de . t r i e r . i n f s e c . koch . d r o i d s h e e p . a c t i v i t i e s . H i j a c k A c t i v i t y "> <a c t i o n a n d r o i d : name="a n d r o i d . i n t e n t . a c t i o n .VIEW" /> <c a t e g o r y a n d r o i d : name="a n d r o i d . i n t e n t . c a t e g o r y .DEFAULT" /> </ a c t i v i t y > </ a p p l i c a t i o n > </m a n i f e s t >
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 identication, 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 eciency. 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 'iwcong' and 'ifcong' 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. Without 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 oers 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 networks. 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 dierent 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 identies 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 identies 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 trac, he can do some ARP spoong. 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 trac. 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 conguration 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 trac 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 trac will be redirected to the attacking device instead of being directed 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 trac. This might lead to problems and slow connections for the whole network. By actively changing the network's conguration, the network connections can become instable when attacking the network. In case of high CPU-load of the attacking 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 identier. In order to answere this question, we should rst clarify the real problem: The session identier 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 specic party the communication 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 identier can be captured without any problem. When using HTTPS this is completely dierent. 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 identiers. Though, usage of HTTPS has some disadvantages: Because of the SSL/TLS handshakes, there is a signicantly 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 dierences between TCP and SSL/TLS connection establishment 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 eort necessary to decrypt and encrypt the payload[20].
! " # $ % & ' ! " # $
# S t a r t TCP Handshake 0 0 : 0 0 : 0 0 . 0 0 0 0 0 0 IP snack . home . 4 0 8 5 5 > c s h . r i t . edu . h t t p s : F l a g s [ S ] 0 0 : 0 0 : 0 0 . 1 1 4 2 9 8 IP c s h . r i t . edu . h t t p s > snack . home . 4 0 8 5 5 : F l a g s [ S . ] 0 0 : 0 0 : 0 0 . 1 1 4 3 4 1 IP snack . home . 4 0 8 5 5 > c s h . r i t . edu . h t t p s : F l a g s [ . ] # TCP Handshake c o m p l e t e . # S t a r t SSL Handshake . 0 0 : 0 0 : 0 0 . 1 1 4 7 6 9 IP snack . home . 4 0 8 5 5 > c s h . r i t . edu . h t t p s : 0 0 : 0 0 : 0 0 . 2 2 6 4 5 6 IP c s h . r i t . edu . h t t p s > snack . home . 4 0 8 5 5 : 0 0 : 0 0 : 0 0 . 2 6 1 9 4 5 IP c s h . r i t . edu . h t t p s > snack . home . 4 0 8 5 5 : 0 0 : 0 0 : 0 0 . 2 6 1 9 6 0 IP c s h . r i t . edu . h t t p s > snack . home . 4 0 8 5 5 : 0 0 : 0 0 : 0 0 . 2 6 1 9 8 5 IP snack . home . 4 0 8 5 5 > c s h . r i t . edu . h t t p s : 0 0 : 0 0 : 0 0 . 2 6 1 9 9 8 IP snack . home . 4 0 8 5 5 > c s h . r i t . edu . h t t p s : 0 0 : 0 0 : 0 0 . 2 7 3 2 8 4 IP snack . home . 4 0 8 5 5 > c s h . r i t . edu . h t t p s : 0 0 : 0 0 : 0 0 . 3 9 8 4 7 3 IP c s h . r i t . edu . h t t p s > snack . home . 4 0 8 5 5 : 0 0 : 0 0 : 0 0 . 4 3 6 3 7 2 IP snack . home . 4 0 8 5 5 > c s h . r i t . edu . h t t p s : Flags Flags Flags Flags Flags Flags Flags Flags Flags [P . ] [.] [.] [P . ] [.] [.] [P . ] [P . ] [.]
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 definition 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 massive, 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 oer 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
http://www.zdnet.com/blog/burnette/ patrick-brady-dissects-android/584. [Online; accessed 17-August-2011].

Burnette.
[2] Symantec
http://www.verisign.com/ssl/ ssl-information-center/how-ssl-security-works/. [Online; accessed 17August-2011].

Corporation.
[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]. http://www.javaworld.com/javaworld/ jw-09-1996/jw-09-bytecodes.html. [Online; accessed 17-August-2011].
line; accessed 17-August-2011].
[6] Bill Venners from JavaWorld.com.
[7] Facebook Inc. https://developers.facebook.com/docs/authentication/. [On-
[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. [Online; 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]. http://developer.android.com/guide/topics/security/ security.html. [Online; accessed 17-August-2011].
Inc.
[12] Google
[13] Google
http://developer.android.com/guide/topics/security/ security.html. [Online; accessed 17-August-2011].

Inc.
55
REFERENCES
REFERENCES
[14] Google Inc. http://source.android.com/. [Online; accessed 17-August-2011]. [15] Google Inc. http://source.android.com/source/initializing.html. [Online; accessed 17-August-2011]. [16] Google Inc. http://source.android.com/source/downloading.html. [Online; accessed 17-August-2011]. [17] Google Inc. http://source.android.com/source/building.html. [Online; accessed 17-August-2011]. [18] Google Inc.
http://developer.android.com/guide/developing/building/ index.html. [Online; accessed 17-August-2011]. US/HTML/tlminmst45.htm. [Online; accessed 17-August-2011].
[19] IBM Inc. http://publib.boulder.ibm.com/tividd/td/ITLM/SC32-1431-01/en_
[20] Chinmoy
http://techie-buzz.com/tech-news/ google-switch-ssl-cost.html. [Online; accessed 17-August-2011].

Kanjilal.
[21] Andreas Koch. https://code.google.com/p/droidsheep/. [Online; accessed 17August-2011]. [22] Michael Koer.
Linux - Installation, Konguration, 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].

lan medium access control (mac) and physical layer (phy) specications, june 2007.
[26] The Institute of Electrical and Inc." Electronics Engineers. Ieee 802.11-2007, wireless
http://standards.ieee.org/getieee802/download/802.11-2007.pdf, 2007.
[27] Bartosz Ponurkiewicz. August-2011]. 56
http://faceniff.ponury.net/.
[Online; accessed 17-
REFERENCES
REFERENCES
[28] E. Rescorla. Request for comments 2818 - http over tls. http://www.ietf.org/
rfc/rfc2818.txt, 2000. [Online; accessed 17-August-2011].

[29] A. Sikora. 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://
Wireless LAN. net.com networking & communications. Addison-Wesley,
www.ieee.org/documents/ieee_annual_report_10_complete.pdf, 2011. [Online; accessed 17-August-2011].

[32] Adam Stubbleeld, 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

Session Hijacking With Android Devices

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Session Hijacking With Android Devices

Uploaded by

Copyright:

Available Formats

Information Security and Cryptography

Supervisor: Prof. Dr. Ralf Kuesters

Reviewer: Prof. Dr. Peter Sturm

Erkrung zur Bachelorarbeit

5 Preparing the attack

The Java application in detail . . . . . . . . . . . . . . . . . . . . . . . .

8 Limitations and future work

9 Preventing the attack 10 Conclusion

of Electrical and Electronic Engineers Inc.), which consists of more

802. IEEE 802 contains amongst others important

2.1 Wireless LAN  How it works

2.2 IEEE 802.11

2.2 IEEE 802.11

2.2 IEEE 802.11

2.2.1 Transport standards

2.2.2 Security standards

WiFi Protected Access WPA was introduced as a subset of the

2.2 IEEE 802.11

The Hypertext Transfer Protocol

Transport Layer Security TLS and its prede-

Figure 2: Establishment of an SSL/TLS connection [2]

! " # $ % & '    ! "

! " # $ % & '    ! " # $

web sessions. (Web)sessions are realized using

3.5.1 Web sessions

3.5.2 Why session identiers should be kept private

3.5.3 Why most session identiers are not secure

Figure 3: Usage of cookies within HTTP communication [author's illustration]

3.6.1 HTTP Response  'Set-Cookie'

Figure 4: Example HTTP Response using Set-Cookie

3.6.2 HTTP Request  'Cookie'

Figure 5: Example HTTP Request using Cookie

3.6.3 Session cookies

3.6.4 Shared authentication

4.1 Android general application structure

4.1 Android general application structure

4.2 Dalvik virtual machine

4.2 Dalvik virtual machine

Dalvik Virtual Machine. A Dalvik VM is a register-based virtual machine

4.3 Android security model

superuser privileges, this security system

wraps each application in its own sandbox. 20

4.3 Android security model

5 PREPARING THE ATTACK

5 Preparing the attack

5.1 Understanding session hijacking

5.1 Understanding session hijacking

5 PREPARING THE ATTACK

5.1 Understanding session hijacking

5 PREPARING THE ATTACK

5.2 How to identify a web sites session cookies?

5 PREPARING THE ATTACK

5.2 How to identify a web sites session cookies?

5.3 Capturing the session identier

5 PREPARING THE ATTACK

5.3 Capturing the session identier

Cookie header eld. So now, if the Linux kernel receives a

5.4 Setting session ID for own requests

5 PREPARING THE ATTACK

5.4 Setting session ID for own requests

6.1 Building native programs for Android devices

libc. Libc actually contains about 200 widely

6.2 Requirements on Android devices

2.1 Wireless LAN How it works

! " # $ % & ' ! "

! " # $ % & ' ! " # $

3.5.2 Why session identiers should be kept private

3.5.3 Why most session identiers are not secure

3.6.1 HTTP Response 'Set-Cookie'

3.6.2 HTTP Request 'Cookie'

5.3 Capturing the session identier

5.3 Capturing the session identier

Cookie header eld. So now, if the Linux kernel receives a

7.3.6 Identication logic

(a) Example network conguration showing each clients ARP table

Linux - Installation, Konguration, Anwendung (6. Au.). Linux