Universidade de Aveiro Departamento deElectr´onica, Telecomunica¸c˜oes e Inform´atica 2019
Jo˜
ao
Grego
o j´uri / the jury
presidente / president Professor Doutor Jo˜ao Paulo Silva Barraca
Professor Auxiliar do Departamento de Electr´onica, Telecomunica¸c˜oes e In-form´atica da Universidade de Aveiro
vogais / examiners committee Professor Doutor Paulo Jorge Salvador Serra Ferreira
Professor Auxiliar do Departamento de Electr´onica, Telecomunica¸c˜oes e In-form´atica da Universidade de Aveiro
Professor Doutor M´ario Jo˜ao Gon¸calves Antunes
agradecimentos / acknowledgements
Quero come¸car por agradecer ao meu orientador, Professor Doutor Paulo Jorge Salvador Serra Ferreira, e co-orientador, Professor Doutor Ant´onio Manuel Duarte Nogueira, por toda a paciˆencia e compreens˜ao ao lidar comigo, apesar de todos os adiamentos e obst´aculos resultantes de ser trabalhador-estudante. Queria tamb´em agradecer `a Universidade de Aveiro, e mais concretamente, ao Chefe de Divis˜ao da ´area de Seguran¸ca, Inform´atica e Comunica¸c˜oes dos servi¸cos de Tecnologias de Informa¸c˜ao e Comunica¸c˜ao da UA, Carlos Manuel Nunes de Almeida Alves da Costa, pela compreens˜ao e flexibilidade que me proporcionou na tarefa dif´ıcil de balancear vida de trabalhador com vida de estudante.
Quero tamb´em agradecer aos meus pais, que n˜ao s´o me proporcionaram a possibilidade de estudar a um n´ıvel superior com todo o conforto, como tiveram que lidar comigo nesta fase stressante, em que a disserta¸c˜ao tanto serviu de desculpa para negligenciar la¸cos familiares. Gostava tamb´em de deixar um grande abra¸co a todos os meus amigos que tanto me ouviram e aconselharam durante esta etapa.
Finalmente, n˜ao podia deixar de emitir um agradecimento especial `a minha namorada e companheira, Ana Catarina Rib˜aes Alves. Sem o apoio dela, tanto a n´ıvel psicol´ogico como log´ıstico, teria sido imposs´ıvel terminar esta disserta¸c˜ao. A sua incansabilidade, carinho e desejo de me ver florescer nas diversas ´areas da vida foram determinantes para fechar este cap´ıtulo. Um grande beijinho e muito obrigado.
palavras-chave dispositivos m´oveis, seguran¸ca, malware, Android, vulnerabilidades, canais de comunica¸c˜ao, seguran¸ca f´ısica
resumo Com o aumento dos utilizadores de dispositivos m´oveis, e o consequente decl´ınio do computador como forma preferencial de aceder `a internet, o n´umero de ataques a telem´oveis subiu consideravelmente. A este facto adiciona-se tamb´em a sua diversidade e complexidade, fazendo com que um telem´ovel moderno tenha v´arios poss´ıveis vetores de ataque. Mas n˜ao s´o as amea¸cas digitais afetam um utilizador destes aparelhos, e podem at´e ser uma mais-valia na dete¸c˜ao e diminui¸c˜ao do impacto de amea¸cas f´ısicas. Este trabalho procura explorar uma forma de limitar as amea¸cas digitais e, simultaneamente, detectar amea¸cas f´ısicas ao ind´ıviduo portador do telem´ovel.
Para al´em da disserta¸c˜ao em si, o trabalho tamb´em culminou numa ap-lica¸c˜ao para Android, cujo c´odigo-fonte foi publicado no GitHub sobre uma licen¸ca de c´odigo livre e aberto.
keywords mobile devices, security, malware, Android, exploits, communication chan-nels, physical security
abstract With the increase of mobile device’s users, and the consequent decline of the computer as the main way of accessing the internet, the number of attacks on mobile devices rose considerably. Furthermore, these devices became more and more diverse and complex, resulting in a modern phone that has several possible attack vectors. But not only digital events threaten the user of these machines, and they can even be a plus in the detection and reduction of the impact of physical dangers. This work explores a way of limiting the effect of digital attacks and, simultaneously, try to detect physical events that may menace the phone’s bearer.
Besides this dissertation, this work also resulted in an application for An-droid, with the source code published in GitHub with a free and open license.
Contents
Contents i
List of Figures iii
List of Tables v
Listings vii
1 Introduction 1
1.1 Objectives . . . 3
1.2 Document structure . . . 3
2 Android systems and users threats 5 2.1 Attack types, motivations and their consequences . . . 5
2.2 Malware (malicious software) . . . 6
2.2.1 Repackaging . . . 6 2.2.2 Update attack . . . 8 2.2.3 Drive-by download . . . 9 2.2.4 Others . . . 9 2.3 Communication-based attacks . . . 10 2.3.1 SMS / MMS . . . 10 2.3.2 GSM . . . 10 2.3.3 Wi-Fi . . . 11 2.3.4 Bluetooth . . . 12 3 Application Framework 15 3.1 Scope . . . 15 3.2 Modules . . . 17 3.2.1 Overview . . . 17 3.2.2 Information gathering . . . 18 3.2.3 Data processing . . . 31 3.3 Development . . . 34
3.3.1 External dependencies and libraries . . . 34
4 Results 39 4.1 WiFi incidents . . . 39 4.2 Fall alerts . . . 40 4.3 Geolocation . . . 45
5 Conclusion and future work 47
List of Figures
3.1 The top menu where the user can change between the 4 activities of the
ap-plication. From left to right: radio, app traffic, sensors, geolocation. . . 18
3.2 A partial view of each of the application’s four activities. . . 18
3.3 The cells table. . . 23
3.4 The WiFi access points table. . . 23
3.5 The Bluetooth devices table. . . 24
3.6 The applications table, with the total traffic throughput that was registered in the last 30 days on the right. . . 25
3.7 The dialog that shows when one of the applications in the list is touched, with the details of the traffic. . . 26
3.8 The sensors activity. . . 27
3.9 The SensorEvent API’s coordinate system. . . 28
3.10 The map activity, with the indication of the current coordinates and accuracy. 29 3.11 The USB Host and Accessory modes schematised. . . 31
3.12 An example of what PermissionHelper could look like on the Nexus 6. . . 35
3.13 An example of osmdroid’s MapView on an Android device. . . 35
3.14 The map of the existing data points (cells, WiFi APs, bluetooth beacons) contained in the Mozilla Location Service. . . 36
3.15 Some of the permissions that Paranoid Android requests at startup. . . 37
3.16 Dialog that is displayed after pressing the middle button, asking the user to authorise the request for permission. . . 38
4.1 Plot of the sum of the acceleration components in the two falls detected when the CA component was accounted for. . . 42
4.2 Plot of the angle variation in the two falls detected when the CA component was accounted for. . . 43
4.3 Plot of the sum of the acceleration components in two of the falls detected, without considering the CA component. . . 44
4.4 Plot of the angle variation in two of the falls detected, without considering the CA component. . . 45
4.5 Geolocation accuracy in Praia da Barra, Aveiro and ´Ilhavo . . . 46
List of Tables
4.1 Results obtained from slightly changing the configuration of hostapd in each iteration. . . 40 4.2 Thresholds considered for the three features. . . 41 4.3 20 iterations of letting the cell phone fall from an altitude of 0.5m, with the
values of the sum of the acceleration components, the angle change, the change in angle and if the fall was detected or not. . . 41 4.4 Results for the same experiment as table 4.3, but this time without accounting
for the CA component. . . 43 4.5 Geolocation accuracy in six different locations. . . 45
Listings
3.1 Registering the custom listener . . . 18
3.2 Inserting base station information into the database. . . 19
3.3 Registering the actions on the IntentFilter, and registering the IntentFilter on the context of the application, along with the WifiInfoReceiver itself. . . 20
3.4 Registering the actions on the IntentFilter, and registering the IntentFilter on the context of the application, along with the BluetoothInfoReceiver itself. . . 20
3.5 Inserting WiFi access point information into the database. . . 20
3.6 Inserting bluetooth device information into the database. . . 21
3.7 Obtaining traffic information using TrafficStats. . . 25
3.8 Obtaining traffic information using NetworkStatsManager, for WiFi only. . . 26
3.9 Registering the custom listener. . . 28
3.10 Updating the sensor that triggered the “onSensorChanged” callback. . . 28
3.11 The retrieval of location information, simplified. . . 29
3.12 Registering the broadcast receiver. . . 30
3.13 The MozillaLocationService interface, using Retrofit’s annotations. . . 32
3.14 The MozillaLocationService interface, using Retrofit’s annotations. . . 32
3.15 Creating the Retrofit instance, and calling the “geolocate” method declared in the previous interface. . . 33
Chapter 1
Introduction
Mobile phones have been increasing in complexity, in an attempt to please users who seek new and exciting functionalities. Most devices can now communicate in a wide array of channels, such as LTE, WiFi, NFC or Bluetooth. This increase in both functionalities and communication channels opens multiple attack vectors that can be exploited to compromise the security of a mobile device. Y. Zhou and X. Jiang [1] claimed that “one third (36.7%) of the collected malware samples leverage root-level exploits to fully compromise the Android security, posing the highest level of threats to users’ security and privacy” and “more than 90% turn the compromised phones into a botnet controlled through network or short messages”.
This problem only got worse since then. Symantec, for instance, states that the number of mobile vulnerabilities has increased every year from 2013 to 2016 [2], and Android continues to be the most targeted mobile platform [3].
Although serious vulnerabilities tend to be patched fast by the kernel developers, Android manufacturers are notoriously slow in propagating these patches to their costumers. Skycure estimates that, among the top 5 US mobile carriers, “71% of mobile devices are running on security patches that are at least 2 months old, leaving millions unnecessarily susceptible to breach” [4].
Another malware that was infamous a few years ago was “NotCompatible”, a “botnet-for-rent” kind of exploit that allows an attacker to use the infected device for purposes such as spam and bruteforce attacks. The most sophisticated variant, “NotCompatible.C”, was so challenging to security enterprises that it became one of the longest running mobile botnets, effectively operating since 2012 to the end of 2014 [5].
Besides mobile phones, other machines and gadgets with connectivity have been gaining popularity. Miscellaneous devices, such as webcams, speakers, home assistants, and even “smart water bottles”, are being pumped out by the industry. Security hasn’t been a primary concern, as companies don’t seem to be motivated to take action in this area unless forced, either by regulation or by consumer demand. The October 2016 cyberattack showed how costly this carelessness can be. The DNS provider, Dyn, suffered a DDoS (distributed denial-of-service) that caused some of the largest Internet platforms, like Twitter and Reddit, to be unavailable to millions of users in Europe and North America [6]. Dyn itself has confirmed that the attack was orchestrated by a Mirai-based botnet of 100,000 malicious endpoints [7]. Mirai works by simply scanning for IoT devices that use the default username / password combinations provided by the manufacturer and installing a bot on those devices. This
CHAPTER 1. INTRODUCTION
creates an army of “smart” CCTV cameras, fridges, and any unsecured device suffering from this problem [8].
Software with malicious intent can be installed through a myriad of ways, either using the victim’s (often unaware) collaboration or not. Software can be installed voluntarily, and around 40.000 malicious software could be found in 2018 on the Play Store [9]. Another possible vector to be exploited is direct access to the device, in which a rogue USB device could be used to install a payload, obtain root access, and even flash a compromised system image [10] [11].
Not all issues that threaten a mobile phone user come from digital menaces, however. Real life agents can be as deleterious to privacy and data confidentiality as digital ones. For instance, theft or misplacement can expose one’s confidential information. And it is even a good idea to take advantage of the fact that a mobile phone is usually almost 100% of the time with it’s owner to assess his physical integrity. Possible applications of this idea would be the detection of traffic accidents, falls of the elderly or those with mobility issues and theft detection and consequent damage control / mitigation.
Khan et al. [12], for instance, present a solution using the accelerometer to detect and react to an accident situation, sending the current position to emergency contacts. As the authors claim, “with real time location tracking for both victim and responder the system will drastically increase the survival rate of an accident victim by providing emergency aid in time”.
As a cell phone is a ever present device, it can also be very useful to detect and provide assistance to people which suffer from limited or impaired mobility, such as the elderly. It is estimated that accidental falls are the leading cause of mortality in elderly individuals, and that lack of assistance within an appropriate time window exacerbates the negative consequences of such a hypothetical fall [13]. As such, it can be promptly suggested that timely assistance, made possible with the help of reliable and accurate fall detection devices, would be a great help in mitigating the number of casualties. A commercial application attempting to provide an answer to such a problem exists, named “AlerteChute” [14].
Theft is also an interesting problem to attack with the usage of an Android mobile device. There are some proposed solutions for this already, like the phone tracking service provided by Google [15], or the one offered by the android-based operating system developed by Xiaomi, MiUI [16]. Others go a bit further, offering features like the ones proposed on this dissertation. Prey [17] is a free and open source mobile application that can be installed on both Android and iOS that offers features like control zone geofencing, remote screen lock and remote data wipe. The same company behind this software shows that, even if theft is not a big concern in one’s area, most of the time individuals just misplace or lose their devices, and that a thief is, unsurprisingly, much more motivated to steal a mobile device than a laptop, for example [18].
No matter if one desires to track incidents at the software / hardware level, watching out for hackers, malware and other kind of digital threats, or if the objective is to be on the lookout for physical, real life threats, either (accidentally) auto-inflicted or provoked by third parties, hopefully the need for robust and exhaustive data collection and analysis has become apparent. With the use of a monitoring system built on multiple sources of data, the detection of anomalies becomes easier, and new services can be developed on its foundations.
CHAPTER 1. INTRODUCTION
The work elaborated in the process of building this dissertation originated, in a very early phase, a paper that was published in the 10th Conference on Telecommunications (Conftele 2015). All the code that was written for the Android application is released as free and open source software, and is published on github. The source code can be obtained in https: //github.com/jpgrego/paranoid-android.
1.1
Objectives
This document aims to propose an integrated monitoring software system for mobile devices that will be able to detect anomalous behaviour at the:
• operating system level; • application level;
• communication channels level; • physical level.
The detectable anomalies should include: • illicit malware and bot actions;
• undeclared application behaviors; • undeclared usage of identity credentials;
• activation and unusual usage of communication channels;
• physical tampering actions (such as the insertion of an unknown, untrusted USB device); • loss or theft of the device.
This system tries to be independent from service providers by centering all information storage and analysis on the mobile device’s hardware. The free and open source nature of this software, allowing its analysis by any interested party, together with the increased control of the data and information by the user, will give any stakeholder greater control of their security without significantly compromising confidential information. For a solution that tries to improve a device’s security and privacy, these precautions seem natural.
1.2
Document structure
This dissertation is currently organized in 5 chapters:
• Chapter 1: the current chapter, containing a brief introduction to the problem and explaining what motivated the development of this solution;
• Chapter 2: a chapter dedicated to the discovery and review of existing solutions to the problem presented in chapter 1, as well as presenting some of the issues in a more detailed way;
CHAPTER 1. INTRODUCTION
• Chapter 3: the chapter dedicated to presenting and analysing the Android application developed in the context of this dissertation;
• Chapter 4: this chapter covers some experiments and results of the app usage, ana-lyzing possible short-comings and drawing conclusion to the effectiveness of some of the features;
Chapter 2
Android systems and users threats
To better guide the practical part of this dissertation, and to better understand what needs to be done, an investigation of the current panorama in the area of mobile and IoT security was developed, delving a bit deeper beyond what was discussed in chapter 1.
Hopefully, with this research, the reader will be properly equiped with the knowledge to understand a little better the complex world of mobile computing and security.
2.1
Attack types, motivations and their consequences
There are three categories in which all attacks generally belong to [19]:
• Confidentiality attacks. These kind of attacks are characterized by exploits in which the objective is to obtain the user’s data and confidential information. Smartphones are, after all, heavily used for data management. This results in these devices containing information like authentication information in various services, credit card numbers, user schedule and calendar, call logs, and others.
• Integrity attacks. Attacks that try to modify an operating system code or data, or acquire privileges and power over a device. This can lead to various consequences, including the same as confidentiality attacks, but also control of the device for use in criminal activities (botnets) and even physical damage (battery exhaustion, abuse of processing power in order to cause overhreating).
• Availability attacks. Denying or limiting access to the device’s capabilities. These can be the traditional protocol-based denial of service attacks, like UDP floods. Battery draining and other physical blocks are a possibility too. Usually, though, smartphones appear to be enlisted as bots in distributed denial of service attacks, rather than be the targets themselves. This can, in any case, depending on the kind of attack, limit the access to the phone, as resource usage could be intense.
There are many different attacks, included in these three categories, that an attacker could carry out. The damage that is inflicted varies, and can range from simple snooping to unintentional calls and message sending to paid services. Even deactivating the phone is possible, by deleting boot scripts, or forced restarts.
CHAPTER 2. ANDROID SYSTEMS AND USERS THREATS
2.2
Malware (malicious software)
When it comes to infecting a victim’s device, some craftiness may be needed. The ob-jective is to penetrate into the device, or gain power over it, preferably without the victim’s knowledge, at least for some time. The way to achieve this can vary. Zhou and Jiang enu-merate three types of methods that an attacker can use to deliver its payload [1]:
• Repackaging. • Update attack. • Drive-by Download. • Others.
The hacker doesn’t necessarily have to pick only one of these methods. In fact, there are variants of the same type of malware that pick a combination of these. By doing that, the possibiliy of a successful implementation of the harmful code into a victim’s device increases.
2.2.1 Repackaging
Repacking seems to be the most popular method of dissemination of malicious payload. In fact, from the 1260 malware sample collection of a study [1], 86% of it, or 1083 samples, used this method, parasitizing apps from various categories, like games and utilities, free or even paid. Malware authors try to be clever, infecting popular apps and piggybacking on their success to reach a broader population of potential victims. Furthermore, they try to disguise the malicious code with innocent sounding class names, appearing to provide useful and benign functionality, like updates, fooling unsuspecting users.
To understand how this repackaging is done, first one must understand how Android developers package and distribute their applications. They do this through a package file format denominated “Android Package Kit” (APK).
Similar to “.deb” packages for GNU/Linux Debian based distributions, or “APPX” for Windows, an APK is a JAR file that contains specific files of the Android platform. The usual combination of files present is:
• META-INF directory. A directory containing metadata of the APK / JAR file. – MANIFEST.MF : The manifest file. Contains information that is to be consumed
by the Java virtual machine upon loading of this package. Information contained here includes the main class that is to be run, author of the package, list of file names and respective SHA1 digest, etc.
– <KeyID>.SF : This is the signature file. It’s similar to the manifest, as it also contains a list of files and a digest for each entry. However, while in the manifest file the SHA digest value for each file is the digest of the binary data in the file, the digests of this file refer to the digest of the correspondent three lines present in the manifest file.
– <KeyID>.RSA: The signature file is signed, and its signature is placed in this file, the signature block file. Additionally, it contains a X.509 certificate or certificate chain that authenticates the public key, written as a PKCS#7 message in DER
CHAPTER 2. ANDROID SYSTEMS AND USERS THREATS
format. Although, in this list, the extension is “RSA”, it can also be “DSA” or “EC”, according to the digest algorithm that was used.
• lib directory. This directory contains the native libraries that run on specific device architectures, if such libraries are necessary for the execution of the application. Possible sub-directories are armeabi, armeabi-v7a, arm64-v7a, x86, x86 64 and mips.
• res. This folder contains all the resources (icons and images) that were not compiled into “resources.arsc”.
• assets. Contains all raw files that are used by the application, such as text files, XML files that are not directly related to Android, and audio files.
• AndroidManifest.xml. In addition to the previously mentioned manifest file, that is shared with JAR type files as well, there’s also this “APK” archive specific manifest. It describes the name of the Java package for the application, components (activities, services, ...), names the classes that implement each of the components, declares per-missions necessary for correct execution of the application, lists libraries that need to be linked against it, mentions the minimum level of the Android API required, etc. This file is usually in binary XML and it’s not human-readable, but it can be easily converted.
• classes.dex. The classes that constitute the application are compiled into this file, in the “dex” file format. It’s processed either by “Dalvik”, a discontinued process virtual machine that was in use until Android 4.4, or “Android Runtime”, that made its official debut in the 5.0 version of the OS.
• resources.arsc. Contains pre-compiled application resources, in binary XML format. Although all Android applications must be cryptographically signed [20], as any app that is not will not be installed by an Android device, it is not required for a keypair to be certified by a Certificate Authority. T. Vidas and N. Christin, in their analysis of 76.480 applications, concluded that more than 99% of them were, indeed, using self-signed certificates [21]. Adding the fact that the only key distribution mechanism is adding the developer’s public key to the application, this means that signatures on Android don’t do much to prove that the signer is who he says he is, only that he signed it. In other words, there’s no foolproof way to ensure that you can trust the developer that made an application, as there’s no guarantee that he’s the same developer that built other apps in which you trust. Unless, of course, the user himself obtains something signed with the same key from that signer through direct, or trusted and verified indirect contact, and compare the key fingerprints. It’s worth noting that this is how Android verifies that the app upgrades come from the same entity as the application to which the upgrades are destined [22] and that, at least, all applications signed with the same key can be removed easily.
One of the most common technique attackers use to compromise a device is to adulterate the “classes.dex” file. With the help of easily obtained, free and open source tools like “apktool” [23], one can easily disassemble an “APK” package and obtain the Java source code from this DEX file, allowing for modification and insertion of malicious code. The process, as described in this article [24], is the following:
CHAPTER 2. ANDROID SYSTEMS AND USERS THREATS
• Step 1: Create the malware. The authors develops a malicious application like any other app, implementing the desired functionality and targeting the desired systems. This app is then built into an “APK” package.
• Step 2: Use the previously mentioned tool, “apktool”, to disassemble the malware and obtain the malicious classes, in opcode format.
• Step 3: Find a legitimate application in which the malicious code is to be injected. Popular applications, as mentioned, are usually targeted in this phase. Proceed in doing the same disassembling as in step 1, and insert the developed classes into appropriate directories. If the app’s necessary permissions change, in order to exploit something or acquire more power, the “AndroidManifest.xml” file is adulterated. This modified application is then re-assembled with the “apktool”, and signed with a key owned by the attacker.
• Step 4: The resulting malware is then distributed, by uploading it into alternative application markets, or by phishing, for example, to trick victims into installing it into their phones.
2.2.2 Update attack
This strategy of malware infection consists in producing a, at first, legitimate application and publish it, either on the official or alternative markets. The malicious code is installed via an update of the application, sometime after the application’s installation. By these means, the applications “flies under the radar”, that is, remains undetected as malware for a time, accumulates installations in user devices, and deploys the malware as soon as programmed, or when the attacker sees fit. The unsuspecting users remain rightly unsuspecting indeed, as even the malware detectors saw nothing wrong when the app was originally deployed.
Tenenboim-Chekina et al. [25] mention four main techniques that can be used to create self-updating applications for Android that download new pieces of software stored remotely. These techniques are as follows:
• Prompt the user to update the app, often offering a complete replacement of the original application.
• Dynamically load compiled Android code using Android’s DexClassLoader [26] class, which allows the loading of “JAR” and “APK” files that contains “classes.dex”. This enables the execution of code that was not a part of the application when it was installed. • Dynamically load a binary shared object file (files with the “.so” extension, native libraries), or an executable file containing native code, to be executed by the Java’s Runtime class.
• Dynamically load a media file, like sound or image, that contains a malicious payload and execute it by exploiting existing vulnerabilities in the system libraries or external applications that handle these file types.
The same authors note that this self-updating mechanism of malware execution cannot be detected by the standard static code analysis techniques, due to the obvious fact that the original version of the application users downloaded is completely benign. Furthermore,
CHAPTER 2. ANDROID SYSTEMS AND USERS THREATS
“detection by dynamic analysis techniques can be simply avoided by using a time delayed or filtered deployment of the malicious payload” [25]. This kind of attack is also difficult to target, as the self updating mechanism is also used with a legitimate and benign goal by several applications.
2.2.3 Drive-by download
Drive-by downloads are an old technique known in the personal computing world since, possibly, the introduction of automatic downloading of “ActiveX” controls, in 1996. In fact, an exploit in 1999 using this mechanism allowed an attacker to delete all files of a computer [27].
The concept of how they work is simple: lure the user into installing something voluntarily, by convincing them that is in their interest to do so. They’re not exploits in themselves, but more alike to social engineering techniques. Usually the infection is carried on by the use of counterfeit executables, ActiveX components and Java applets.
There’s also indirect attack vectors using JavaScript. The victim is tricked into visiting a website that contains malicious JavaScript code, which attempts to exploits vulnerabilities present in the browser or its add-ons. According to Cova et al. [28], three main factors make this technique a viable and popular way to spread malware:
• vulnerabilities in web clients are widespread, and a great percentage of internet users run outdated versions, with many exploits that need to be fixed;
• the exploits and techniques to successfully hack these browsers are well-documented, and this information is easy to access;
• sophisticated tools for automating the whole process of identification and exploiting itself exist and are easily obtainable.
2.2.4 Others
This final group of malware applications represent the ones that do not exactly fit in the previous categories, as per Y. Zhou and X. Jiang analysis. The apps that remain employ the following techniques:
• Applications that are openly announced as malware, and make no attempt to fool the user. They’re intended to be purposefully installed in the device, probably by individuals with physical access to it.
• Applications that pretend they are legit, but perform malicious activities in the back-ground, without the user’s knowledge, like stealing a victim service’s username and password. They do not provide the functionality claimed. These are not considered repackaged applications because they don’t obtain and modify the original application. They simply try to mimic the presentation and user interface of the application they try to masquerade as.
• Applications that are similar to the previous item, but they do provide the advertised functionality. But, additionally, they also perform malicious activity, without the user’s knowledge.
CHAPTER 2. ANDROID SYSTEMS AND USERS THREATS
• Applications that rely on having root privilege and access to operate as intended, and obtain it stealthily. While not necessarily malware per se, the aforementioned authors consider these apps step over a boundary when they try to use known exploits to obtain the needed privilege without informing the device’s user.
2.3
Communication-based attacks
2.3.1 SMS / MMS
This kind of attacks consist in exploiting vulnerabilities in the SMS or MMS system of the phone. The fact that it’s a system that is always on, as long as the phone is operating as such, makes it a highly appealing target. Furthermore, over the years it was expanded to have more features, such as the sharing of ringtones, videos and pictures. Generally, as the number of features increase, so do the potential attack vectors and the number of vulnerabilities.
An attack using MMS could be executed by sending this kind of message to a phone with a virus infected attachment, which uses the infected phone’s address book to send it to other potential victims.
“Stagefright” is a strong example of the potential of this attack vector. This vulnerability, that affected Android’s media playback engine [29], compromised a staggering 95% of all Android devices in 2015 [30]. It was so accessible that an attacker would only need a victim’s phone number. No opening of the message was required, because Android would automatically process it. As soon as the attack was concluded, the attacker would be able to access the camera and microphone of the device, among other things [31].
2.3.2 GSM
Attacks on GSM networks generally consist in breaking the encryption of the network. The early “A5” algorithms, A5/1 and A5/2, suffered from the practice of “security through obscurity” [32], which made it impossible to test just how strong the algorithms really were. Predictably, however, this policy reared it’s problems, and A5/1 was shown to be broken in an average of 6 hours, 12 hours for the worst-case scenario [33]. To make matters worse, A5/1 was the strongest algorithm of the two, as A5/2 was intentionally made weak to pos-sibilitate eavesdropping by governments and law enforcement agencies [34], and was shown to be so vulnerable that a real-time attack was possible and relatively easy to execute with low-powered hardware [35] [36].
Fortunately, a stronger algorithm was introduced with A5/3, also known as KASUMI. It is used in both GSM (2G) and UMTS (3G). However, it didn’t take long for researchers to find vulnerabilities on it too [37]. One attack in specific has a sufficiently low complexity to be launched and concluded in simple hardware, such as a computer equipped with an Intel Core 2 Duo processor. The authors, note, however, that this technique “might not be applicable to the specific way in which KASUMI is used as the A5/3 encryption algorithm in third generation GSM telephony.” [38].
CHAPTER 2. ANDROID SYSTEMS AND USERS THREATS
Even if no attack can be used, or users are using stronger algorithms (because they’re using 4G LTE, for example), a base station has the power to downgrade the communication. For example, a fake base station can be set up in order to fool devices in the area to connect to it instead of other legitimate base stations, force 2G GSM communications, and force the traffic to be unencrypted, that is, the connection is only allowed to use A5/0 algorithm (no encryption) [39]. These devices are commonly known as “IMSI-catchers”.
2.3.3 Wi-Fi
Wi-Fi based attacks are not unique to smartphones only. The now obsolete “WEP” algorithm is known to be insecure, and an attacker can easily insert himself into a network that is protected by it. Furthermore, a rogue AP can be used to take advantage of the fact that most smartphones remember the networks they were connected in the past. As such, the aforementioned AP can be configured with the same parameters of a network the victim uses, and trick it into connecting into the false network. Once an attacker gains access to the same network the smartphone is connected to, spying traffic that is not encrypted is trivial. With the help of tools like “ettercap” and “sslstrip”, even some encrypted traffic is possible to be eavesdropped. Exploits that require both the attacker and the victim to be located on the same network can also be launched, like the one described by CVE-2017-0561 [40], an heap-overflow attack that takes advantage of faulty TDLS (Tunneled Direct Link Setup) implementation in Broadcom’s firmware.
Curiously, there weren’t any major threats related to Wi-Fi vulnerabilities until recently. At least, not in the 802.11i norm directly. Attackers normally exploited weaknesses in other mechanisms, like WPS [41] (“Wi-Fi Protected Setup”) and flaws in the WPA enterprise au-thentication [42]. October 2017 has been a specially interesting month in relation to security of Wi-Fi and Bluetooth networks. There were two important vulnerabilities that became known in that period: “KRACK” and “Broadpwn”.
2.3.3.1 KRACK
“KRACK” is a vulnerability discovered by researchers Mathy Vanhoef and Frank Pies-sens. This vulnerability is, according to the authors, “exceptionally devastating against An-droid 6.0” [43]. It consists in a flaw in the 4-way handshake, the mechanism that provides mutual authentication of the participants and the negotiation of a session key, that makes it susceptible to a key reinstallation attack. In short, it consists in forcing nonce (incremental transmit packet number) resets by retransmitting the message that establishes the session key. As it’s an exploit that affects versions 2.4 and 2.5 of wpa supplicant, the supplicant that is widely used in GNU/Linux distributions, and as Android uses a modified wpa supplicant, Android 6.0 and Android Wear 2.0 are vulnerable to this attack, targetting around 31.2% of Android devices, going by the same researchers. The implications of a successful attack are frame decryption, consequent eavesdropping and hijacking of TCP connections, manipulation of unencrypted HTTP packets and, if WPA-TKIP or GCMP is used, even packet forging. 2.3.3.2 Broadpwn
As mobile devices main operating systems, Android and iOS, become increasingly secure, thanks to major investments by both Google and Apple, attackers will tend to try to find other
CHAPTER 2. ANDROID SYSTEMS AND USERS THREATS
weak links and entry points in the device. One great example of this fact is a vulnerability discovered by researcher Nitay Artenstein denominated “Broadpwn” [44]. This vulnerability, which is so serious that some estimations of affected devices are predicted to be around a billion devices [45], consists in exploiting a buffer overflow that occurs in a method responsible for parsing the WMM (Wireless Multimedia Extensions, a Quality-of-Service extension included in the 802.11 norm) capabilities of an AP. While the advent of ASLR (address space layout randomization) and similar technologies made this kind of exploits much harder to succeed, there are two main reasons that make this attack possible when targeting Broadcom’s chips: there is no ASLR, and the entire memory has read, write and execute permissions. As such, an attacker can make good assumptions about a victim’s address space and memory state. A successful hack allows the perpetrator to execute any code he wishes on Broadcom’s chip and, possibly, achieve privilege escalation in order to execute code on the application processor. To make matters worse, Artenstein successfully made a worm out of this exploit, self-replicating itself to any vulnerable devices in the area. The fact that a lot of mobile phones and other mobile devices use Broadcom chips, the possibility of remote code exploitation and the self-replicating possibility of this attack makes it a very powerful worm, the likes that haven’t been seen for many years now.
2.3.4 Bluetooth
Bluetooth gained a lot of popularity over the years due to the ease of wirelessly connecting several machines, and the comfort that being able to use devices like wireless headsets with a reasonable degree of quality and reliability, specially with the introduction of “A2DP” (Advanced Audio Distribution Profile), provides. However, it is not without its problems, and it is susceptible to denial-of-service and man-in-the-middle attacks, eavesdropping and other vulnerabilities. Fortunately, its security has been improving with each new version, and some dangerous attacks have been nullified. Nevertheless, there’s still a degree of risk and, as such, security must be continually improved to properly address new and currently unknown attacks.
There are three proposed threat categories in which Bluetooth vulnerabilities can fall into [46]: disclosure, integrity, and denial of service. These categories are analogous to the more generic confidentiality, integrity and availability attack types, respectively, mentioned on chapter 2.1.
2.3.4.1 Bluejacking
A usually harmless, albeit annoying, attack, “Bluejacking” consists in sending unwanted and unsolicited messages using Bluetooth. It’s an old attack, as it appeared in 2003, when Bluetooth first started gaining popularity and to be adopted by consumers. As long as something like sharing a contact using Bluetooth is possible, bluejacking is also theoretically possible. However, phones nowadays usually aren’t discoverable by default. As a result, other devices can’t initiate communication as easily, and that makes bluejacking way more challenging. Furthermore, Android doesn’t seem to allow vCard sharing between unpaired devices, and a RFCOMM connection can only be established if the participating devices are paired [47].
CHAPTER 2. ANDROID SYSTEMS AND USERS THREATS
2.3.4.2 Bluesnarfing
“Bluesnarfing” is defined as a unauthorized access to a wireless device’s stored informa-tion using a Bluetooth connecinforma-tion. Such informainforma-tion can range from calendars and contacts lists to private pictures, videos and access credentials to services. While “Bluejacking” was relatively harmless, as it only consisted in the victim’s device receiving unwanted content, this attack actually steals information.
Although it used to be a serious threat [48], there doesn’t seem to be any documented attack on today’s Android or iOS smartphones. Nevertheless, Bluetooth implementation by a phone’s manufacturer can be faulty and vulnerable to it.
A tool that is easily obtainable to launch this attack, and that is even available in penet-ration testing oriented GNU/Linux distributions like Kali Linux, is “bluesnarfer” [49]. 2.3.4.3 Bluebugging
“Bluebugging” is similar to “bluesnarfing”, in the sense that it consists in unauthorized access to a device. However, this attack results in an increased power and access to privileged functions. A successful exploit, in addition to the effects of “bluesnarfing”, allows the attacker to redirect incoming calls, modify existing contacts information and make calls without the phone’s owner realizing it, making it easy to eavesdrop on the device’s surroundings.
However, like “bluesnarfing”, this exploit doesn’t seem to have documented ways to be applied in today’s smartphones.
2.3.4.4 Blueprinting
This attack can be used to find out information about the device itself, like manufacturer, device model and firmware version. This can be useful to “generate statistics about Bluetooth device manufacturers and models” [46], and to attempt to find if there are devices in range that are vulnerable to any kind of exploit, bluetooth-related or otherwise. However, it seems that a prerequisite to actually launch an attack like this is to have, a priori, the “BD ADDR” of the intended target.
A tool that can be used to launch an attack like this is “blueprinting” [50]. 2.3.4.5 Other threats
Even if many security improvements have been made over the successive Bluetooth ver-sions, this doesn’t mean that Bluetooth is no longer vulnerable to attack. In fact, Cope et al. claim that “various attacks can be performed before the pairing process has completed” and that “even after the devices are paired, an adversary can still gain enough information to be able to perform Man in the Middle attacks or to impersonate another device” [51]. That is, it appears that the pairing process is critical in assuring that the communication is secured, and it’s the weak link of the whole link establishment process, due to flaws in the link key establishment protocol [46].
CHAPTER 2. ANDROID SYSTEMS AND USERS THREATS
Some other attacks are possible. To obtain the “BD ADDR” mentioned before, an at-tacker can try to brute force the last 24 bits of it (the first 24 are predetermined, and depend on the manufacturer). Although some authors claim that this is a feasible attack [46], the limited range of Bluetooth piconets, limiting the array of victims available to try and guess their address, and the fact that there are more than 16 million possible combinations, make it seem appropriate only to an obstinate attacker. There are also Bluetooth specific worms, but they only seemed to target phones that had Symbian OS installed.
Some researchers [51], while admitting to difficulties in sniffing and decryption of live data in newer devices, have managed to successfully snoop on a device’s communication, using easily obtained tools (Kismet, Wireshark and Crackle, all possible to obtain in major distribution repositories) and a piece of hardware denominated “Ubertooth One” [52]. The same authors also mention that using multiple “Ubertooth One” devices would be a boon in accomplishing the capture of many more packets by scanning all the frequencies that are possible to be used by Bluetooth, eroding the security benefits of the frequency-hopping effect. Bluetooth is also susceptible to denial of service attacks, as mentioned. They are mostly just annoying, however, and don’t seem to cause serious consequences pertaining personal data leak or manipulation. An attacker can attempt to jam all frequencies Bluetooth users to transmit data, but this kind of attack is easily detected by intrusion detection systems. Some researchers have, however developed a method to more efficiently jam a target beacon, resulting in a harder to detect attack [53].
To try to minimize the aforementioned risks, the following preventive measures and mit-igation techniques ought to be applied:
• turn off Bluetooth capabilities when they are not being used;
• if Bluetooth is being used, but no pairing with new devices is necessary, turn the discovery feature off; although it’s still possible to initiate contact by guessing the “BD ADDR” through brute force, the sheer number of possible combinations makes this approach impractical;
• if the need to pair a new device arises, it should be done in a non-public and secure area, as to avoid eavesdroppers that can obtain the frames associated with pairing and determine the link key [46];
• if a Bluetooth device has been lost, the owner should unpair it from all other devices it paired with, as to avoid that device being used to access the former owner’s piconet; • unknown or unexpected transmissions should always be ignored, as it may be an attacker
attempting to send infected files, or to gain access to the device;
• link encryption for Bluetooth connections should always be used, if possible;
• keeping the phone’s firmware and software updated is a good idea, as existing vulnerab-ilities in the manufacturer’s implementation of the Bluetooth stack are possibly patched in these updates.
Chapter 3
Application Framework
3.1
Scope
Mobile security is complex, and a plataform like Android, whose main strength (be-ing an open platform) is simultaneously its weakness (fragmentation and abandonment by manufacturers on phones deemed too “old”), complicates things even more, as discovered vulnerabilities have no guarantee of being patched [4]. Even if they are, zero day exploits are always a risk, and there is no guarantee of security at any time. To make things worse, the fact that phones have many features and many communication options also open up new and unexpected attack vectors. Attacks that attempt to target and exploit device’s components instead of their operating system or attempting other obvious vectors are becoming more common, like “Broadpwn”, described in section 2.3.3.2.
The solution described in this chapter consists in an Android application, whose objective is to try to mitigate some of the problems described in chapter 2. As such, as discussed, there are two main areas of action in which this application will be focused on:
• software and device systems: these are threats that target the device’s normal operation, such as abnormal network activity from an application, possible rogue access points or unexpected changes to known ones, and physical insertion of unknown USB devices;
• device’s / user’s physical integrity: unexpected events that may befall the user or the device, like a theft attempt, fall, accident or the presence of the device at a location that the user never found himself at before.
The real challenge will be, however, managing the need to be on the lookout and notify the user of events, and at the same time not be too annoying, as constants interference on one’s usual activities can become tiresome and lead the user to not use such a solution. Also, the consequence of reading sensors in too frequent intervals results in excessive drain of the battery. It is important, then, to find the sweet spot between information retrieval and displaying, and user experience.
An important issue, since the beginning of this project, was to ensure that the end-user’s data and privacy is well protected, and not subject to harvesting by an unauthorized third
CHAPTER 3. APPLICATION FRAMEWORK
party, while using this service. As such, to guarantee a degree of trustworthiness, the following conditions have to be met:
1. All data that is collected is stored in local storage. Most cloud storage services offer no guarantee of privacy. While using external storage such as these, strong encryption would be necessary to reasonably expect a good degree of data confidentiality.
2. All source code is to be free and open source, licensed under a free software license, such as the GNU GPL. The fact that all the code used in this application is open and published allows for public scrutinizing to guarantee that there’s no unauthorized use of data. Furthermore, bugs and possible vulnerabilities have a greater chance of being spotted if more people are looking at the source. Depending on security by obscurity is not a good practice. Some security experts go as far as saying that “obscurity is insecurity” and that “smart security engineers open their systems to public scrutiny, because that’s how they improve” [54]. Finally, by handing it to the community, and if the community has any interest in it, continuation of this work is possible and not dependent on any kind of authorization or red tape.
3. Geo-location services provided by Google are to be avoided. While reliable and usually accurate, there’s no guarantee of privacy in ad-sponsored services like these. Even if one assumes Google does no harm, and decides to trust it, another agent can use ads to infer sensitive data, such as a person’s whereabouts. Researchers found that an attacker “can purchase passive ads and use those ads to detect a target visiting a specific location within 10 minutes of their arrival there” [55]. To be fair, Google in specific, according to the same research, seems to try and protect user’s privacy from these kind of incursions. It still seems a good principle to avoid services that depend on advertisement revenue, however.
The application itself is divided in 3 distinct modules:
• Information Gathering: Acquisition of information pertaining to base stations, Wi-Fi access points, sensors installed in the phone, application network activity and geoloca-tion. The app periodically requests this information to Android’s API, and stores it into the local SQLite database. This database is created, in case it doesn’t already exist in the application folder (internal memory), and updates it if any database structure change occurred in a new version.
• Data processing: The processes and decisions made with the data acquired on the first module. That is, with all the data that is acquired, there is now the possibility to act on that data, by taking precautions and reacting when necessary. This treatment of the data allows:
– Access point impersonation detection. As Wi-Fi access points are scanned, the application will analyze the ones currently available, compare them to the ones it has stored in the local database, and alert the user if any change in BSSID has occurred, or if it has the same BSSID but other parameters have changed, and other verifications to try and detect a possible evil twin attack.
– Deciding if a soft locking of the phone should be enabled upon reasonable suspicion that the device is currently located on a place where it has never been before. The
CHAPTER 3. APPLICATION FRAMEWORK
base station, Wi-Fi, Bluetooth and geolocation data aquired in the previous module will assist on this decision.
– Reacting to the detection of an extreme sensorial input, corresponding to, possibly, a forceful grabbing by another individual of the device, a fall, a traffic accident, or other similar events.
– Reacting to abnormal network activity of an application. For example, the sudden download of a great volume of data.
• User interaction and notification: The module responsible for alerting the user to events judged to be problematic or worthy of attention by the previous module. This is mainly done through the use of notifications, some of which ask for input of the user (e.g.: asking the user if a newly detected access point is to be trusted, for instance). Besides notifications, “Paranoid Android” also act in a more forceful way if deemed necessary, such as the soft lock of the phone, and requesting the user to input his screen code (or any other authentication method that was set up, like fingerprint reading). Code was also developed to allow for communication with an external service. The idea was to enable the remote location of the phone, or the calling for help in case of an event that has the possibility of causing harm to the user. The external service itself is deemed out of the scope of this dissertation, however.
As the purpose is to always be on the lookout for dangerous activity and interactions, the application was aptly named “Paranoid Android”.
3.2
Modules
3.2.1 Overview
Before moving on to the description of the features, it’s appropriate to present a quick overview of the application and how to navigate in it.
In the action bar, to the right of the application name, four buttons can be seen. These buttons permit the user to navigate between the four activities. These activities are:
• Radio: All the information that is currently being obtained about cellular base stations, WiFi access points and Bluetooth devices and beacons. There are 3 tables on this activity, related to each of the types mentioned.
• App Traffic: The information pertaining to applications traffic activity. In this activity there’s a list of applications installed in the device, in descending order of network activity (the sum of sent and received bytes using both WiFi and cellular network). • Sensors: A simple activity containing only a table with all sensors detected in the
system. At the application startup, Paranoid Android requests to receive updates from the sensors with a 20 microseconds delay.
• Location: Activity containing a replacement of Android’s MapView, using the afore-mentioned osmdroid library and Mozilla location services. Displays the estimated cur-rent geolocation.
CHAPTER 3. APPLICATION FRAMEWORK
Figure 3.1: The top menu where the user can change between the 4 activities of the applica-tion. From left to right: radio, app traffic, sensors, geolocaapplica-tion.
Figure 3.2: A partial view of each of the application’s four activities.
3.2.2 Information gathering
As the first feature that has been introduced into Paranoid Android, information gathering from a multitude of sources the Android OS provided was deemed crucial, and the basis of many of the other features present in this application. This acquisition of data is what allows the data processing module to do its work, as it provides the raw information it needs to evaluate situations and act on events. That is, it’s possible to determine the usual access points that are used, the base stations that are accessed in a normal day, what kind of Bluetooth communications are to be considered normal, among other information.
3.2.2.1 Cellular / WiFi / Bluetooth
This is the data that pertains to all radio communications going in and out of the device. By radio it is meant to be all cellular network activity, WiFi traffic and Bluetooth commu-nication.
A simple description of the steps involved in the acquisition of base station information could be described as:
1. Upon application start-up, a custom listener, the CellInfoListener class that extends PhoneStateListener [56], is registered using the listen method of TelephonyManager [57]. This allows CellInfoListener to receive “onSignalStrengthsChanged” callback in-vocations, which are fired upon detection of a network signal strength variation.
CHAPTER 3. APPLICATION FRAMEWORK
1 p u b l i c C e l l I n f o L i s t e n e r (f i n a l Context c o n t e x t ) {
2 t e l e p h o n y M a n a g e r = ( TelephonyManager ) c o n t e x t . g e t S y s t e m S e r v i c e (
Context . TELEPHONY SERVICE) ;
3 t e l e p h o n y M a n a g e r . l i s t e n (t h i s , LISTEN SIGNAL STRENGTHS) ; 4 . . .
5 }
6
Listing 3.1: Registering the custom listener
2. When the aforementioned callback is invoked, the table with the base station informa-tion, in “Paranoid Android”’s Radio activity, is updated.
3. The current base station information is persisted in the local SQLite database with a periodicity of 10 seconds, rather than always inserting immediately upon the firing of the callback. 1 p r i v a t e v o i d w r i t e C e l l I n f o T o D B (f i n a l L i s t <C e l l > c e l l L i s t ) { 2 f i n a l C o n t e n t V a l u e s v a l u e s = new C o n t e n t V a l u e s ( ) ; 3 4 f o r ( C e l l c e l l : c e l l L i s t ) { 5 // i f no c e l l ID c o u l d be d e t e r m i n e d , s k i p 6 i f ( c e l l . g e t C i d ( ) == −1) { 7 c o n t i n u e; 8 } 9
10 v a l u e s . put ( D a t a b a s e C o n t r a c t . C e l l E n t r y . CID COLUMN, c e l l . g e t C i d ( ) ) ; 11 v a l u e s . put ( D a t a b a s e C o n t r a c t . C e l l E n t r y .MCC COLUMN, c e l l . getMcc ( ) ) ; 12 . . . 13 14 t r y { 15 db . i n s e r t O r T h r o w ( D a t a b a s e C o n t r a c t . C e l l E n t r y .TABLE NAME, n u l l, 16 v a l u e s ) ; 17 } c a t c h (f i n a l SQLException ex ) { 18 // i f an e x c e p t i o n was thrown , i t ’ s b e c a u s e an e n t r y w i t h t h e 19 // s p e c i f i e d c e l l ID a l r e a d y e x i s t s . r e p l a c e t h e o l d one 20 v a l u e s . remove ( D a t a b a s e C o n t r a c t . C e l l E n t r y . CID COLUMN) ; 21 db . update ( D a t a b a s e C o n t r a c t . C e l l E n t r y .TABLE NAME, v a l u e s , 22 D a t a b a s e C o n t r a c t . C e l l E n t r y . CID COLUMN + ”=?”, 23 new S t r i n g [ ] { S t r i n g . v a l u e O f ( c e l l . g e t C i d ( ) ) } ) ; 24 } 25 26 } 27 } 28
Listing 3.2: Inserting base station information into the database.
For WiFi and Bluetooth data the steps would be:
1. When “Paranoid Android” starts, a custom receiver, WifiInfoReceiver / BluetoothIn-foReceiver, which extends Android’s BroadcastReceiver [58], is registered on the ap-plication’s context. Both specify, with the use of an IntentFilter [59], the events which are relevant to listen for. For the WiFi, SCAN_RESULTS_AVAILABLE_ACTION and NETWORK_STATE_CHANGED_ACTION [60] are the relevant actions, indicating that a scan
CHAPTER 3. APPLICATION FRAMEWORK
has completed and there are results available, and that the state of the WiFi con-nectivity has changed, respectively. In the Bluetooth scenario, ACTION_FOUND [61], ACTION_CONNECTION_STATE_CHANGED and ACTION_DISCOVERY_FINISHED [62], indicat-ing that a new bluetooth device has been found, the Bluetooth connection state has changed and that a scan / discovery has been completed, respectively.
1 p u b l i c W i f i I n f o R e c e i v e r (f i n a l Context c o n t e x t ) { 2
3 . . . 4
5 f i n a l I n t e n t F i l t e r w i f i I n t e n t F i l t e r = new I n t e n t F i l t e r ( ) ;
6 w i f i I n t e n t F i l t e r . a d d A c t i o n ( WifiManager . SCAN RESULTS AVAILABLE ACTION
) ;
7 w i f i I n t e n t F i l t e r . a d d A c t i o n ( WifiManager .NETWORK STATE CHANGED ACTION)
;
8
9 c o n t e x t . r e g i s t e r R e c e i v e r (t h i s , w i f i I n t e n t F i l t e r ) ;
10 }
11
Listing 3.3: Registering the actions on the IntentFilter, and registering the IntentFilter on the context of the application, along with the WifiInfoReceiver itself.
1 p u b l i c B l u e t o o t h I n f o R e c e i v e r (f i n a l Context c o n t e x t ) { 2 i f( b l u e t o o t h A d a p t e r != n u l l) {
3 f i n a l I n t e n t F i l t e r b l u e t o o t h I n t e n t F i l t e r = new I n t e n t F i l t e r ( ) ; 4 b l u e t o o t h I n t e n t F i l t e r . a d d A c t i o n ( B l u e t o o t h D e v i c e . ACTION FOUND) ; 5 b l u e t o o t h I n t e n t F i l t e r . a d d A c t i o n ( B l u e t o o t h A d a p t e r .
ACTION CONNECTION STATE CHANGED) ;
6 b l u e t o o t h I n t e n t F i l t e r . a d d A c t i o n ( B l u e t o o t h A d a p t e r .
ACTION DISCOVERY FINISHED) ;
7 c o n t e x t . r e g i s t e r R e c e i v e r (t h i s , b l u e t o o t h I n t e n t F i l t e r ) ; 8 9 . . . 10 11 } 12 13 } 14
Listing 3.4: Registering the actions on the IntentFilter, and registering the IntentFilter on the context of the application, along with the BluetoothInfoReceiver itself.
2. When there are scan results available, the respective tables are updated and the new data is displayed on the “Radio” activity. When devices are connected, that connection gets highlighted in the aforementioned tables.
3. In a similar fashion as the base station information, the data is inserted into the SQLite database, with a periodicity of 10 seconds.
1 p r i v a t e v o i d writeWifiAPInfoToDB (f i n a l A r r a y L i s t <WifiAP> w i f i A P L i s t ) { 2 f i n a l C o n t e n t V a l u e s v a l u e s = new C o n t e n t V a l u e s ( ) ;
3 4
5 f o r ( WifiAP wifiAP : w i f i A P L i s t ) {
6 v a l u e s . put ( D a t a b a s e C o n t r a c t . WifiAPEntry . BSSID COLUMN, wifiAP .
CHAPTER 3. APPLICATION FRAMEWORK
7 v a l u e s . put ( D a t a b a s e C o n t r a c t . WifiAPEntry . SSID COLUMN, wifiAP .
g e t S s i d ( ) ) ; 8 9 . . . 10 11 // i f an e x c e p t i o n i s thrown an e n t r y w i t h t h e g i v e n BSSID a l r e a d y e x i s t s . 12 // i f t h a t ’ s t h e c a s e , update t h e e x i s t i n g e n t r y 13 t r y {
14 db . i n s e r t O r T h r o w ( D a t a b a s e C o n t r a c t . WifiAPEntry .TABLE NAME, n u l l ,
v a l u e s ) ;
15 } c a t c h (f i n a l SQLException ex ) {
16 v a l u e s . remove ( D a t a b a s e C o n t r a c t . WifiAPEntry . BSSID COLUMN) ; 17 db . update ( D a t a b a s e C o n t r a c t . WifiAPEntry .TABLE NAME, v a l u e s , 18 D a t a b a s e C o n t r a c t . WifiAPEntry . BSSID COLUMN + ”=?”, 19 new S t r i n g [ ] { wifiAP . g e t B s s i d ( ) } ) ;
20 }
21 }
22 }
23
Listing 3.5: Inserting WiFi access point information into the database.
1 p r i v a t e v o i d w r i t e B l u e t o o t h I n f o T o D B (f i n a l A r r a y L i s t <MyBluetoothDevice>
b l u e t o o t h D e v i c e L i s t ) {
2 f i n a l C o n t e n t V a l u e s v a l u e s = new C o n t e n t V a l u e s ( ) ; 3
4 f o r( MyBluetoothDevice b l u e t o o t h D e v i c e : b l u e t o o t h D e v i c e L i s t ) { 5 v a l u e s . put ( D a t a b a s e C o n t r a c t . B l u e t o o t h E n t r y .NAME COLUMN,
b l u e t o o t h D e v i c e . getName ( ) ) ; 6 7 . . . 8 9 // i f an e x c e p t i o n i s thrown an e n t r y w i t h t h e g i v e n a d d r e s s a l r e a d y e x i s t s . 10 // i f t h a t ’ s t h e c a s e , update t h e e x i s t i n g e n t r y 11 t r y { 12 db . i n s e r t O r T h r o w ( D a t a b a s e C o n t r a c t . B l u e t o o t h E n t r y .TABLE NAME, n u l l , v a l u e s ) ; 13 } c a t c h (f i n a l SQLException ex ) {
14 v a l u e s . remove ( D a t a b a s e C o n t r a c t . B l u e t o o t h E n t r y .ADDRESS COLUMN) ; 15 db . update ( D a t a b a s e C o n t r a c t . B l u e t o o t h E n t r y .TABLE NAME, v a l u e s , 16 D a t a b a s e C o n t r a c t . B l u e t o o t h E n t r y .ADDRESS COLUMN + ”=?”, 17 new S t r i n g [ ] { b l u e t o o t h D e v i c e . g e t A d d r e s s ( ) } ) ; 18 } 19 } 20 } 21
Listing 3.6: Inserting bluetooth device information into the database.
The data that pertains to radio communications that is currently collected by Paranoid Android is:
• Currently connected and neighbouring base stations. The currently associated base stations are highlighted with a white background, on the cells list. The data fields obtained for each base station are:
CHAPTER 3. APPLICATION FRAMEWORK
– Mobile Country Code (MCC): a 3-digit code that can be used to pinpoint the country of operation of the base station. The first digit identifies the region (2, in case of Europe, 3 in North America and the Caribbean, etc.), while the remaining two identify the country (68 corresponds to a base station installed in Portugal). As such, a base station that is located in Portugal displays a mobile country code of 268.
– Mobile National Code (MNC): a 2 or 3-digit code, depending on the area where the base station is installed. For instance, a MNC of 01 is not the same of a MNC of 001; each one of them corresponds to different networks. While the MCC identifies the country of operation, this code makes it possible to determine the operator that detains this base station. A combination of both the MCC and the MNC is denominated a Home Network Identity, or HNI for short. So, a MCC of 268 with a MNC of 01 results in a HNI of 26801. Furthermore, if one adds to this the Mobile Subscriber Identification Number (MSIN), a 10-digit unique number that is used to identify a specific mobile phone, the resulting combination is the International Mobile Subscriber Identity (IMSI), that serves as a unique identifier that is associated with all cellular networks.
– Cell ID (CID): this is a unique number that identifies a base station within, at least, of a location area code (LAC), or possibly within an entire GSM network. Valid values for this number can range from 0 to 65535 on the case of GSM and CDMA networks, and from 0 to 268435455 on UMTS and LTE networks.
– Location Area Code (LAC): a location area code is a 16-digit unique number broadcast by a base transceiver station. It corresponds to an area of a set of base stations which were grouped together to maximize signalling efficiency, performing under a single base station controller. This controller is responsible for the alloca-tion of radio channels and the handovers from base staalloca-tion to base staalloca-tion, among other responsibilities.
– Pre-scrambling code (PSC): this number serves as a local cell identifier in UMTS networks, in the sense that it is not repeated across neighboring cells. There can be, however, base stations across the country that share the same PSC. – Signal strength (in dBm): simply the measure of the signal strength in dBm. • The list of detected WiFi access points in the area. The currently connected WiFi
access point, if any, is highlighted in a similar fashion to the currently associated base stations. Access points that are fading, that is, getting out of range because the last scan didn’t detect them, change their font colour to “greyed out”, a darker grey that is usually shown for other access points. After 3 scan results where those access points are not shown, they are considered to be out of range and are removed from the list. The columns presented in the WiFi access points table are:
– Security: this column is represented with a padlock icon, either closed or open, indicating, respectively, if a security protocol is present. On the right side of this icon the information about the security protocol used can be consulted (WEP, WPA, ...), if any.
– Service Set Identifier (SSID): the SSID of the connection is displayed here. Below it the Basic Service Set Identifier (BSSID), a unique 48-bit identifier that
CHAPTER 3. APPLICATION FRAMEWORK
Figure 3.3: The cells table.
follows the MAC address conventions, can be found.
– Channel: the channel where the advertised connection is established. Possible channels are 1 to 14 in the 2.4 GHz bands (used in 802.11b/g/n/ax protocols) and 36 to 169 (with some gaps, and depending on the channel width) in the 5GHz bands (used in 802.11a/h/j/n/ac/ax protocols.
– Signal strength (in dBm): similar to the cells table, it’s the measure of the signal strength expressed in dBm (decibel-milliwatts).
CHAPTER 3. APPLICATION FRAMEWORK
• List of detected bluetooth devices / beacons in the area. The currently associated bluetooth devices get highlighted.
The columns that are presented in the bluetooth devices table are: – Name: the name the device uses to advertise itself.
– Address: a unique 48-bit identifier that follows the MAC address conventions. – Type: what type is this bluetooth device. Possibilities include “Classical” (Basic
Rate / Enhanced Data Rate), “BLE” (Bluetooth Low Energy), “Dual” (supports both previous modes) or “Unknown”, if it wasn’t possible to accurately determine the type.
– Received Signal Strength Indicator: a column for the RSSI, that measures the power level that a client device receives from the emitting device, in dBm. The same as both previous tables.
Figure 3.5: The Bluetooth devices table.
3.2.2.2 Application traffic data
This system is responsible to gather information about the traffic throughput of each application installed in the system. On the “App Traffic” activity, a table is displayed showing all the applications installed on the system that had network activity in the last 30 days. The table is organised in descending order according to the total traffic commu-nicated. The decision to limit the time frame of this information to 30 days was made because these values could easily reach the order of the terabytes if no restriction was put in place. This caused the calculation of the data displayed on this activity to take a long time.
The information that is shown on the table is:
• Icon: Simply the icon of the application. Displayed on the leftmost column.
• Friendly name: The application’s label, or friendly name. Displayed on the middle column.
• Total traffic: The total traffic done by the application in the last 30 days, in megabytes. Shown on the last column.
Clicking on one of the applications of the list display more detailed information about the traffic that was initiated by the clicked application, and information about the application itself.
