Anàlisi de seguretat d'aplicacions Android

T reba ll F i de G rau

Anàlisi de seguretat d’aplicacions Android

Pedro Galindo Morey

Tutor

María Francisca Hinarejos Campos

Escola Politècnica Superior

Universitat de les Illes Balears

S ^UMARI

Sumari i

Agraïments iii

Resum v

Glossari vii

1 Introducció al projecte 1

1.1 Contextualització . . . 2

1.2 Objectius . . . 7

1.3 Estructura de la memòria . . . 7

2 Tecnologies necessàries 9 2.1 Google Play . . . 9

2.1.1 Android . . . 9

2.1.2 Com s’organitza la informació . . . 11

2.1.3 Gestió de seguretat a la plataforma . . . 13

2.2 Tecnologies a utilitzar . . . 14

2.2.1 API . . . 14

2.2.2 Python . . . 14

2.2.3 Scripting (bash) . . . 15

2.2.4 Java . . . 15

2.2.5 Docker . . . 15

2.3 Escenari del projecte . . . 16

2.4 Elecció del mètode d’accés . . . 17

2.4.1 Informació necessària . . . 17

2.4.2 Elecció del mètode d’accés . . . 18

2.5 El mètode seleccionat:Google Play UnOfficial Python API . . . 21

2.6 Dispensador detokens . . . 27

2.6.1 Anàlisi del problema . . . 27

2.6.2 Anàlisi del projectetoken dispenser . . . 27

2.6.3 Funcionament d’aquest projecte . . . 28

3 Desenvolupament del projecte 31 3.1 Sistema d’extracció (Crawler) . . . 32

3.1.1 Extracció des d’arxiu local.csv . . . 33

3.1.2 Extracció des deGoogle Play Store . . . 34

3.1.3 Emmagatzemament de la informació . . . 38

3.2 Tractament de la informació . . . 40

3.2.1 Tractament de les dades . . . 40

3.2.2 Tractament de certificats . . . 42

3.3 Càlcul de probabilitats . . . 44

3.3.1 Format d’entrada . . . 45

3.3.2 CàlculTrust . . . 48

3.3.3 CàlculPKI . . . 50

3.3.4 Càlcul probabilitat total . . . 55

3.3.5 Càlcul probabilitat de risc . . . 55

3.3.6 Format de sortida . . . 55

3.3.7 Utilitats a tenir en compte . . . 59

4 Resultats 63 4.1 Scriptsque formen el projecte . . . 63

4.2 Execució del projecte . . . 65

4.3 Interpretació dels resultats . . . 73

4.3.1 Probabilitat total . . . 73

4.3.2 Impacte . . . 74

5 Conclusions i treball futur 77 5.1 Conclusions . . . 77

5.2 Treball futur . . . 78

Índex de figures 81

Índex de taules 83

Bibliografia 85

A ^GRAÏMENTS

En un procés tan llarg i sacrificat com és la carrera d’un alumne és imprescindible agrair a tota aquella persona que hagui intervingut positivament en el seu compliment.

Voldria començar agraint a tots els professors, sense excepció, encara que de manera especial a la meva tutoraXisca Hinarejos, per donar-me l’oportunitat de realitzar aquest treball i per tot l’esforç dedicat a facilitar el desenvolupament de totes les fases del projecte.

No voldria oblidar-me d’agrair als meus pares tot l’esforç i confiança que m’han demos- trat durant aquest llarg recorregut.

Tampoc voldria oblidar-me de la meva parella i la meva família que en moltes ocasions m’han donat l’empenta que necessitava.

Una vegada dit això, tan sols voldria expressar el meu agraïment a tota aquella persona que presenti interès amb llegir aquest document, i desitjar que aquest satisfaci les seves expectatives.

R ^ESUM

Un treball de fi de grau és molt més que un projecte en el qual reflectir els coneixements apresos durant la carrera, és un punt i a part en la vida d’un estudiant, i per suposat un punt i començament a la seva vida laboral. Durant a l’elaboració d’aquests tipus de projecte s’aprèn des de la part tècnica fins a la capacitat de síntesi i redacció de l’alumne, és per tant, un treball que permet reflectir moltes de les qualitats entrenades durant la carreta. Aquest pas representa la darrera petjada de l’alumne dins el seu recorregut en el grau, i es pretén dur a terme un projecte que sens dubte l’acompanyarà durant tota la seva vida.

Concretament, en aquest document es pretén realitzar una anàlisi de seguretat d’apli- cacionsAndroid, per a aconseguir això s’han realitzat diferents mòduls amb funciona- ments diferents (encara que relacionats entre ells) que permeten dur a terme una tasca concreta, tal com podria ser el mòdul d’extracció de la informació deGoogle Playque permet extreure la informació relativa a les aplicacions del mercat deGoogle Play. Així, es pot afirmar que el resultat d’aquest treball serà una estructura modular i reutilitzable que podrà ser emprada per a realitzar funcions específiques. De fet, encara que aquest projecte s’hagi basat en l’anàlisi d’aplicacionsAndroiden el mercat deGoogle Playmò- duls com el de càlcul de probabilitats podran ser utilitzats per a l’anàlisi d’altres mercats com per exempleAppStore. Per tant, l’objectiu d’aquest projecte és el de desenvolupar una plataforma que pugui ser utilitzada per al modelatge i avaluació d’equacions del càlcul de risc d’aplicacions mòbils, que en aquest cas seran desenvolupades per altres persones.

G ^LOSSARI

APP Aplicació, programa que s’instal·la en un dispositiu (normalment mòbil) i que permet realitzar diverses funcions.

Android Sistema operatiu que s’empra en dispositius mòbils.

Malware Malicious Software, es tracta d’un tipus de programa que presenta la funció de danyar un sistema o provocar un mal funcionament.

Spyware Softwarela funció del qual és recopilar informació d’un determinat dispositiu per posteriorment enviar-lo a una entitat externa sense el consentiment del propietari.

MongoDB És un tipus de base de dades orientada a documents, és a dir, guarda les dades en documents i no en registres.

Troià Es tracta d’un programa que es presenta a l’usuari com un programa inofensiu i que a l’executar-se proporciona a l’atacant accés remot al dispositiu infectat.

Smartphone Telèfon amb pantalla tàctil que permet a l’usuari connectar-se a Internet i realitzar diferents funcions a través d’aplicacions.

CSV Es tracta d’un tipus de document amb format simple que permet representar valors en format de taula on les columnes es separen per comes ’,’ (encara que es pot configurar) i les files per bots de línia.

Certificat digital És l’únic mitjà a través del qual es pot garantir tant tècnica com legalment la identitat d’una persona i/o entitat a Internet.

CRL Certificate Revocation List, conté els números de sèrie dels certificats digitals que han estat revocats.

OCSP Online Certificate Status Protocol, es tracta d’un mètode que permet comprovar l’estat d’un certificat X509 en línia utilitzant altres mètodes diferents dels CRL.

API Application Programint Interfaceconjunt de subrutines, programes i funcions que ofereix una biblioteca per ser utilitzat per un altre software com a capa d’abstracció.

Script Petit programa que permet dur a terme petites tasques, normalment amb l’ob- jectiu d’automatitzar un procés.

Crawler Aranyaweb, es tracta d’un petit programa que s’encarrega de recórrer l’entre- matwebde forma automàtica i sistemàtica cercant determinats patrons definits en la seva creació.

Maquina virtual Es tracta d’un programa que simula el funcionament d’un ordinador i pot executar programes com si fos una màquina real.

Docker Es tracta d’un projecte que permet crear contenidors que presenten el funcio- nament d’una màquina virtual lleugera.

Token Cadena de caràcters que en un determinat llenguatge de programació pot presentar un significat coherent.

C

1

I NTRODUCCIÓ AL PROJECTE

En aquest capítol es descriurà la situació actual dels dispositius mòbils, relacionant això amb l’àmbit de la seguretat en aplicacionsAndroid, a més a més també s’hi descriuran els objectius proposats en la realització d’aquest projecte. Finalment es conclourà amb una breu explicació del contingut de cada una de les seccions que formen part d’aquesta memòria.

1.1 Contextualització

L’inici d’aquest segleXXI ha vengut de la mà amb l’anomenada era digital i és que durant el darrer lustre s’han realitzat molts dels majors avanços en l’àmbit digital. De fet, i malgrat que a finals del segle passat ja es comença a parlar de dispositius mòbils, no ha estat fins ben entrat aquest segle quan es produí el seu assentament i posterior massificació. De fet molts dels estudis realitzats recentment com els duit a terme per l’organitzacióGSMA Intelligenceconclueixen que el nombre de dispositius mòbils i per tant el nombre de connexions mòbils, creixen cada dia a un nivell gairebé exponencial.

De fet, això es pot verificar a la figura 1.1 de la publicació deStatistaque pode s’observa tot seguit:

Figura 1.1: Creixement nombre de connexions mòbils [1]

A més a més, a una publicació de laGSMA Intelligence, al Gener de l’any 2016 es va determinar que el nombre de connexions realitzades des de dispositius mòbils gairebé superava al nombre de persones, és més, si s’observa les zones on el nivell de recursos és major (per exemple Europa) la probabilitat supera clarament al 100%, el que implica que el nombre de connexions supera clarament al nombre de persones. De fet, a dia d’avui en un món plenament comunicat això resulta més que evident, ja que resulta quasi impossible imaginar un món sense dispositius mòbils. A continuació, a la figura 1.2 es pot veure aquest factor:

1.1. Contextualització

Figura 1.2: Nombre de connexions mòbils/població [2]

Deixant a part el nombre de dispositius, l’increment en el nombre de connexions mòbils es troba directament relacionat amb les millores realitzades en els anomenats smartphones. Aquests han deixat enrere el concepte de dispositiu mòbil que tan sols realitzava funcions simples de trucada, per passar a ser l’origen principal de les con- nexions. Avui en dia des del dispositiu mòbil es pot dur a terme qualsevol tipus de funció, des de trucar fins a realitzar una transacció monetària. Tot seguit a la figura 1.3 es confirma com efectivament el nombre dispositius mòbils ha deixat enrere fins i tot al nombre d’ordinadors:

Figura 1.3: Evolució del creixement tant de dispositius mòbils com d’ordinadors [3]

Tal com es pot observar a la figura 1.3 (importada deComscorea l’any 2014) el nom- bre d’usuaris dels dispositius mòbils va superar (per primer cop) al nombre d’usuaris d’ordinador.

Tot això és degut, entre altres coses, al desenvolupament en paral·lel de les anomenades aplicacions mòbils (app). Unaappconsisteix en una aplicació informàtica dissenyada per ser executada en els dispositius mòbils, aquesta permet a l’usuari realitzar una funció específica i de qualsevol tipus. De fet, no s’entén la definició desmartphone sense l’existència d’aplicacions amb les qual l’usuari podrà gestionar qualsevol de les funcionalitats del seu dispositiu. A la figura 1.4 es mostra un gràfic, més que interessant, en relació a la importància, a dia d’avui, de les aplicacions mòbils:

Figura 1.4: Temps de consum aplicacióAndroid[4]

A la figura 1.4 presa de l’article detechcrunchque al mateix temps pren aquesta fi- gura de l’empresa d’anàlisiAppannie[5], es pot observar una dada més que interessant i és que aproximadament cada persona passa de mitja un mes de cada any (un 8,33%

del temps) utilitzant una aplicació. Aquest fet descriu a la perfecció el tipus de societat actual.

Com no podria ser d’altra manera, tota part positiva, que en aquest cas és el desenvo- lupament tecnològic, ve de la mà amb altres conseqüències negatives, que en aquest cas fan referencia a totes aquelles aplicacions que pretenen fer un ús fraudulent de les seves funcions damunt l’usuari final. Des de la plataformaSymantec[6] s’ha identificat més d’1 milió d’aplicacions mòbils infectades ambmalware, a més de moltes altres amb funcions també perjudicials per als usuaris tals comspyware, aparició abundant de publicitat, etcètera. Des d’un informe publicat per l’empresaNokiaassegura que la quantitat d’infeccions s’ha incrementat considerablement a l’any 2016, especialment els dispositiusAndroid. A la figura 1.5 es troben alguns percentatges interessants.

1.1. Contextualització

Figura 1.5: Infeccions a dispositius Android 2016 [7]

Nokia NES (NetGuard Endpoint Security)s’encarrega d’analitzar patrons de tràfic dels proveïdors de serveis amb l’objectiu de cercar infeccions demalware, de fet en aquest mateix informe [7] s’hi reflexa que del 85% d’aplicacions infectades el 81% cor- responia a dispositiusAndroidmentre que tan sols el 4% pertanyia a dispositiusiOS.

Un altre aspecte interessant que reflecteix aquest article és que en el mes d’Octubre de l’any 2016 l’augment de la taxa d’infecció va arribar al 1.35% dels dispositius.

Abans d’acabar aquest apartat convé tenir present un dels punts més controvertits de lesapp’s Android, aquest punt no és d’altre que els permisos. Aquests consisteixen en unes determinades accions/controls que sol·licita una aplicació per tal de ser ins- tal·lada en un dispositiu, per exemple, una aplicació de missatgeria pot demanar accés a la teva llista de contactes. L’exemple anterior no pareix un problema, ja que resulta raonable aquest tipus de permís per aquest tipus d’aplicació. El problema recau en què algunes aplicacions demanden (a vegades) uns permisos que no concorden amb la seva teòrica tasca. A continuació a la figura 1.6 es pot veure un exemple d’aplicació que requereix els permisos adequats (el jocClash Royale) i un altre que sol·licita un gran nombre de permisos innecessaris (Linterna):

Figura 1.6: Exemples de sol·licitud de permisos

A la figura 1.6, tan sols s’han vist alguns dels permisos d’aquestes aplicacions, a continuació a la taula 1.1 es podran veure tots els permisos d’ambdues aplicacions:

Comparació permisos

Tipus de permís Clash Royale Linterna

Comprar SI NO

Fotos/Multimèdia/Arxius SI SI

Emmagatzemament SI SI

Wi-Fi SI SI

Rebre dades d’internet SI SI

Connectar a xarxesWi-Fi SI SI

Accés a xarxa SI SI

Control de vibració SI SI

Impedir mode suspens SI SI

Càmera NO SI

Iddel dispositiu i dades de trucada NO SI

Accés administrador de trucades NO SI

Actualitzar estadístiques NO SI

Modificar estadístiques NO SI

Executar al inici NO SI

Tancar altres aplicacions NO SI

Modificar ajustaments del sistema NO SI

Control barra d’estat NO SI

Vincular amb dispositiusbluetooth NO SI

Telèfon (trucar, redirigir) NO SI

Ubicació NO SI

Contactes NO SI

Taula 1.1: El perill dels permisos

A la taula 1.1, s’ha pogut veure de manera clara que l’aplicació llanterna sol·licita permisos totalment desproporcionats a les seves funcionalitats, tals com podrien ser el permís d’ubicació, l’accés a les funcionalitats de telèfon, o l’accés a l’iddel dispositiu, i tants d’altres que’a priori’no pareixen necessàries per a la finalitat d’aquesta aplicació.

Per aquest motiu, aquesta aplicació és potencialment perillosa per tot usuari que la instal·li al seu dispositiu. A més, el fet que més crida l’atenció és que la valoració d’a- questa llanterna és d’un 4.5 (dins l’escala 0-5) amb un nombre de 5.000.000 - 10.000.000 descàrregues, és a dir, un gran nombre de persones pensa que aquesta aplicació és recomanable, aquest fet diu molt del desconeixement de la població sobre les amenaces que pot suposar una aplicació mòbil.

1.2. Objectius

1.2 Objectius

Per a la realització de qualsevol tipus de projecte és imprescindible definir quines són les finalitats per a dur-ho a terme, ja que el fet de no tenir una clara visió del que es vol aconseguir pot afectar el seu desenvolupament. L’objectiu principal d’aquest projecte és la de desenvolupar una plataforma capaç d’extreure, analitzar i tractar, el major nombre d’informació d’aplicacions mòbils a partir d’unes equacions de càlcul de risc desenvolupades en altres projectes. Seguidament podem veure alguns objectius més específics:

• Anàlisi dels diferents mètodes d’accés a l’API de Google Play.Per tal d’aconseguir- ho s’haurà de definir quina informació és la que es vol analitzar, per posterior- ment, realitzar una cerca i posterior anàlisi dels diferents mètodes d’accés a l’API deGoogle, per finalment decidir quin és el mètode d’accés seleccionat.

• Desenvolupar un sistema d’extracció i emmagatzemament de la informació.

En aquest bloc es durà a terme una explicació de l’estructura que presenta aquest sistema, i també de la manera en què s’ha aconseguit la implementació de les funcionalitats necessàries per assolir l’objectiu proposat. Es donarà particular importància al format amb el qual s’ha d’emmagatzemar la informació per sim- plificar les tasques de processament del següent bloc.

• Desenvolupar un sistema lògic d’interpretació de la informació tractada.Aquest sistema ha de ser capaç de realitzar el càlcul de risc de cada aplicació. En aquest bloc, es definiran tant les estructures utilitzades per poder tractar la informació d’entrada i sortida, com les passes que s’han seguit per realitzar el càlcul de la probabilitat de risc.

• Analitzar i interpretar els resultats obtinguts. Una vegada obtingut el resultat per mitjà d’un fitxer que conté tota la informació sobre el càlcul de probabilitats, es realitza una anàlisi, on s’explicarà amb profunditat quins han estat els factors que han provocat aquest resultat.

1.3 Estructura de la memòria

Per mitjà d’aquesta secció, es pretén facilitar la comprensió del present document, procurant que els lectors no perdin el fil conductor de les explicacions realitzades al llarg del projecte. Aquest document es troba estructurat en 5 capítols:

Capítol 1. Introducció al projecte

En aquest capítol es pretén introduir al lector sobre la situació actual de les aplicacions mòbils, així com explicar els objectius proposats durant el projecte. Finalment s’expli- carà com s’ha estructurat aquesta memòria.

Capítol 2. Tecnologies necessàries.

En aquest capítol es descriurà el mercat d’aplicacions mòbils utilitzat per realitzar l’anàlisi, les tecnologies utilitzades per a dur a terme el projecte i s’explicaran les carac- terístiques del mètode d’accés a l’APIdeGoogleseleccionat.

Capítol 3. Desenvolupament del projecte.

En aquest capítol es detallaran cada una de les fases realitzades per extreure tota la informació necessària per a dur a terme les posteriors fases del projecte. A més a més s’explicarà el funcionament del sistema lògic de càlcul de probabilitat de risc.

Capítol 4. Resultats.

En aquest capítol es realitza el flux recomanat d’execució i s’explicaran el resultats obtinguts.

Capítol 5. Conclusions i treball futur.

En aquest capítol s’hi reflectiran cada una de les conclusions derivades de la realització del project, així com una planificació de les tasques que es podrien dur a terme una vegada acabat el projecte.

C

2

T ECNOLOGIES NECESSÀRIES

En aquest capítol s’hi defineixen i expliquen tots els elements que formen part d’aquest projecte, cada un d’aquests són independents però juguen un paper fonamental a l’hora d’aconseguir els objectius proposats. Aquest capítol comença explicant el funciona- ment de la plataforma utilitzada per a l’accés a la informació de les aplicacions (Google Play) i seguidament s’explica el funcionament de totes les tecnologies que apareixen en el projecte. A més a més s’hi defineix l’escenari general del projecte, així com l’anàlisi dels diferents mètodes d’accés a l’APIdeGoogle Play, juntament amb l’explicació del mètode seleccionat. Finalment es conclou aquest capítol amb l’explicació del projecte seleccionat per tal d’obtenirtokensd’autenticació vàlids per a l’accés a l’APIdeGoogle Play.

2.1 Google Play

La plataforma sobre la que es realitza l’estudi és el resultat de la fusió (el Març del 2012) de l’anomenatAndroidMarketambGoogle Music, donant pas al conegut ara com a Google Play.Google Play Storeés una plataforma de distribució digital d’aplicacions mòbils per a dispositius del sistema operatiuAndroid. Per mitjà d’aquesta plataforma els usuaris poden trobar gairebé qualsevol tipus d’aplicació i a més a més altres serveis integrats com els deGoogle Play Books, Google Play Games, Google Play Music, Google Play Movies & TV, oferint als usuaris una elevada qualitat de servei.

2.1.1 Android

Tal com s’ha comentat al començament d’aquest capítol 2.1,Google Playdistribueix aplicacions del sistema operatiuAndroid, el qual es troba basat amb el nucli d’un altre sistema operatiu com ésLinux. Aquestes aplicacions es troben programades a través del llenguatge de programació Java, encara que els desenvolupadors utilitzenAndroid SDK toolsper tal de compilar les aplicacions en un fitxer .apk(Android Package) on s’emmagatzemarà tot el contingut de l’aplicació. De fet és per mitjà d’aquest arxiu que

es poden instal·lar les aplicacions als dispositius mòbils. A continuació, a la figura 2.1, s’hi defineix el contingut d’aquest directori:

Figura 2.1: Contingut APK

• (AndroidManifest.xml): tota aplicació ha de presentar aquest arxiu ja que en aquest s’hi descriuen moltes de les característiques de la aplicació, tals com el seu identificador o els permisos que requereix. A continuació es pot veure i analitzar el seu contingut:

<manifest xmlns:android=" h t t p : //schemas . android .com/apk/ res / android "

package="com. example .nomID">

< !−−permisos−−>

<uses−permission android:name=" android . permission .READ_CONTACTS" />

<appl ica tion

android:allowBackup=" true "

android:icon="@mipmap/iconoAPP"

<!−−S’ hi d e f i n e i x e l s l a y e r s de l ’APP−−>

< a c t i v i t y

android:name=" . nomLayerMain"

a n d r o i d : l a b e l =" @string /app_name"

android:screenOrientation=" p o r t r a i t ">

<intent−f i l t e r > < !−−Main−−>

<action android:name=" android . i n t e n t . action .MAIN" />

</ intent−f i l t e r >

</ a c t i v i t y >

< a c t i v i t y

android:name=" . nomLayer"

a n d r o i d : l a b e l =" @string / t i t l e _ a c t i v i t y _ n o m L a y e r ">

</ a c t i v i t y >

<meta−data

android:name="com. google . android . gms . version "

android:value=" @integer / google_play_services_version " />

</ appl ication >

</ manifest>

Com s’ha pogut comprovar, en aquest document s’hi defineix l’identificador únic de l’aplicació (en aquest cascom.example.nomID), els permisos (per exemple:

android.permission.READ_CONTACTSper a accedir als contactes) i finalment cada un delslayers(lesactivity, per exemplenomLayerMain) que formen les pantalles l’aplicació.

2.1. Google Play

• Recursos d’aplicació(assets): directori que conté recursos d’aplicació que poden ser recuperats per l’AssetManager(aquest permet accedir alrawdels recursos de l’aplicació).

• Classes compilades (classes.dex): s’hi troben les classes compilades en el format dex.

• Llibreries (lib): en aquest directori es troba el codi de software compilat, per exemple en aquest directori trobam el.jardelmainde l’aplicació.

• Informaciómetadata (META-INF): directori on es guarda la informació relativa als certificats i al manifest de l’aplicació.

• Recursos no compilats (res): presenta tots els recursos (sense compilar) de l’apli- cació. Un exemple clar són les imatges que s’utilitzen a l’aplicació.

• Recursos compilats (resources.arsc): arxiu que conté els recursos (de la carpeta res) pre-compilats.

2.1.2 Com s’organitza la informació

Com s’ha comentat a l’apartat 2.1.1 tota aplicació presentarà un identificador únic (i no modificable una vegada publicada) que permetrà a la plataforma organitzar totes les aplicacions de la millor manera possible segons els seus criteris. Malgrat queGoogle Playpermet realitzar tant cerques per identificador com per paraules clau, la seva informació es troba organitzada en categories i, fins i tot, subcategories. Totes aquestes categories (a dia d’avui) es veuen reflectides a la taula 2.1:

Categories

Android Wear Art i Disseny Automoció Bellesa

Biblioteques idemos Casa Menjar i beure Còmics

Compres Comunicació Deports Educació

Empresa Entrades i events Entreteniment Estil de vida

Finances Fotografia Eines Llibres

Mapes i navegació Medicina Música Noticies i revistes

Personalització Productivitat Reproductors i editors Salut i benestar

Ser pares Social Jocs Família

Taula 2.1: Categories aGooglePlay

A la taula 2.1, s’ha pogut observar com existeixen 32 categories diferents on agrupar les aplicacions, tot i això, sense tenir en compte les subcategories que presenten algu- nes de les categories, tals com joc o família.

A més a més de tot això,Google Playtambé proporciona molta més informació a nivell d’aplicació. Aquesta informació es pot veure tot seguit a la figura 2.2.

Figura 2.2: Informació que ofereixGoogle Playsobre l’aplicació (Temple Run)

Tot seguit, en el següent enumerat s’hi pot veure tota aquesta informació:

• (1) Nom visible de l’aplicació.

• (2) Categories a la qual pertany.

2.1. Google Play

• (3) Valoració i nombre d’usuaris.

• (4) Descripció.

• (5) Comentaris de l’aplicació.

• (6) Altre informació addicional. Com per exemple : – (6.1) Darrera actualització.

– (6.2) Nombre de descàrregues.

– (6.3) Versió.

– (6.4) Permisos.

– (6.5) Desenvolupador.

2.1.3 Gestió de seguretat a la plataforma

Com tota plataforma, la seguretat deGoogle Playha canviat durant el temps. En els seus inicis cada aplicació era analitzada detingudament abans de ser publicada per un grup d’experts. De fet el dia 2 de Febrer de 2012 en un escrit realitzat perHiroshi Lockheimer [8] es va presentar una nova capa de seguretat que va prendre el nom deGoogle Bouncer;

Una eina permet automatitzar el procés de cerca d’aplicacions ambmalwaredins el mercat. El problema principal d’aquesta eina és que el procés es realitza sempre a les aplicacions ja publicades. Així i tot, l’aparició d’aquesta eina va reduir en un 40%

l’existència de aplicacions potencialment perilloses. El seu funcionament és el següent:

1. Una vegada carregada l’aplicació comença el procés d’anàlisi amb la cerca de malware(conegut),spywareitroyans.

2. També es realitza una cerca en funció de comportaments que puguin ser malici- osos.

3. Compara l’aplicació amb altres prèviament analitzades per tal de cercar patrons de conducta similars.

4. S’analitzen totes les aplicacions del núvol de Google i es simula la forma en què s’executarà dins un dispositiu.

5. Finalment, també s’analitzen les comptes dels desenvolupadors per evitar que desenvolupadors maliciosos o reincidents es registrin.

A més a més d’aquest servei de prevenció demalware, en aquest mateix article s’indica que després de sofrir els efectes delmalwaresobre els primers dispositius connectats a la xarxa, els dissenyadorsAndroidvaren crear tres característiques de seguretat noves:

• Sandbox: aquesta tècnica consisteix amb una paret virtual que permet aïllar el contingut de l’aplicació, de la informació del dispositiu. D’aquesta manera si es descarrega una aplicació maliciosa, aquesta no podrà accedir a les dades del teu telèfon, per exemple a la ubicació.

• Permisos: per mitjà d’aquest sistema es pretén que l’usuari prengui consciència sobre els possibles usos que demanda una determinada aplicació i en conse- qüència decidir si la vol (o no) instal·lar.

• L’eliminació demalware: segons aquest document,Androides troba dissenyat per evitar que elmalwaremodifiqui la plataforma, per tant aquest una vegada descobert podrà ser eliminat de manera remota de la plataforma.

Així i tot, els problemes de seguretat en aplicacionsAndroidno han desaparegut, i a dia d’avui, tal com s’ha comentat al punt 1.1, els problemes de seguretat segueixen sent un apartat important per a guanyar la confiança del consumidor en un mercat tan ampli com és el de les aplicacions mòbils.

2.2 Tecnologies a utilitzar

En aquest apartat es realitza una breu explicació de tots els aspectes relacionats amb les tecnologies utilitzades durant aquest projecte.

2.2.1 API

Una interfície de programació d’aplicacions (API - Application Programming Interfa- ce) [9] és un conjunt de mètodes o funcions que pot oferir un sistema per mitjà de biblioteques. Amb la finalitat de poder ser utilitzades per a un altre software. L’objectiu principal d’aquesta tecnologia és la de beneficiar als programadors permetent que, in- dependentment de la tecnologia que utilitzin, puguin accedir a qualsevol dels recursos de la biblioteca de forma senzilla i intuïtiva. A més a més, com que tota la informació s’estructura de forma ordenada i independent de la tecnologia que la consumeix, el manteniment és molt més sostenible.

Una de les companyies que presenta un volum més elevat deAPI’s ésGoogle, de fet en aquest projecte es farà servir de manera directa l’APId’accés aGoogle Play[10] amb l’objectiu d’accedir la informació d’aplicacions mòbils i emmagatzemar tota aquella informació necessària per al dur a terme el projecte.

2.2.2 Python

Es tracta d’un llenguatge de programació dissenyat originalment perGuido van Possum l’any 1991, encara que el seu desenvolupament se li atribueix a la fundacióPython Software Foundation[11]. Aquest tipus de llenguatge és capaç de suportar diversos paradigmes de programació, incloent-hi programació orientada a objectes, imperativa (basada en computadors) i també funcional (basada en fonaments matemàtics). El seu codi va ser dissenyat amb l’objectiu de ser llegit amb facilitat, per aquesta raó es substitueixen molts dels operadors bàsics tals com!, || o &&per altres més llegibles com not, or i and.

En aquest projecte, tan sols ha estat necessari interpretar aquest llenguatge, com que el mètode d’accés seleccionat per accedir a l’APIdeGoogle Play Storeestà programat ambPython.

2.2. Tecnologies a utilitzar 2.2.3 Scripting (bash)

Es tracta d’un llenguatge de programació basat amb petits fragments de codi que permeten automatitzar qualsevol tipus d’acció. De fet aquesta és la raó principal de la seva existència. És complicat atribuir la creació d’aquest llenguatge a una determinada persona, ja que realment es podria ferscriptingper mitjà de molts de llenguatges [12].

Per aquest projecte, s’ha utilitzat aquest sistema per tal de crear una eina autònoma i automàtica que per mitjà de línia de comandes pugui accedir, de manera massiva, a tota la informació necessària, i al mateix temps emmagatzemar-la de manera ordenada al seu directori corresponent.

2.2.4 Java

Es tracta d’un llenguatge de programació desenvolupat perJames Gosling de Sun Mi- crosystems[13] l’any 1995. L’èxit principal d’aquest llenguatge va ser la d’acabar amb l’estil d’aplicació que hi havia fins a aquell moment, permetent als programadors la pos- sibilitat d’escriure tan sols una vegada la seva aplicació, i poder ser executat a qualsevol sistema operatiu sense necessitat de compilar-la un altre cop. Precisament per aquest motiu, Java és a dia d’avui un dels llenguatges més populars i per tant més utilitzats, sobretot per a aplicacions que segueixen l’arquitectura client-servidor.

Per aquest projecte, s’ha utilitzat per a programar el mòdul de càlcul de probabilitats de risc, i a més a més al ser un projecte que fa ús de la tècnica descripting, el fet que aquest software sigui executable a nivell de línia de comandes ha facilitat el desenvolupament.

A més a més, en el moment del desenvolupament de la partJavade càlcul de pro- babilitat s’han necessitat les següents llibreries auxiliars:

• JavaCsv: aquesta llibreria [14] permet manejar de manera senzilla tot tipus de document.csv. L’ús de les seves classes permet llegir la informació d’entrada i finalment generar un nou document.csvde sortida com a resultat del projecte.

• IAIK: aquesta llibreria [15] permet poder tractar tant els certificats de les aplicaci- ons com tota la informació que contenen i per tant per al càlcul de la probabilitat dePKI.

2.2.5 Docker

Es tracta d’un projecte de codi obert [16] que permet automatitzar el desplegament d’aplicacions dins contenidors de software, ja que aquest proporciona una capa addici- onal d’abstracció i automatització de virtualització a nivell de sistema operatiuLinux.

Aquests contenidors en fan ús de les característiques d’aïllament delkernelde Linux (cgroupsinamespaces) per tal de permetre que diversos contenidors s’executin dins una mateixa instància deLinux. D’aquesta manera, s’evita la sobrecàrrega d’iniciar i mantenir màquines virtuals. Aquest software ha estat utilitzat en aquest projecte per tal de crear un sistema dispensador detokens, és a dir, amb l’objectiu de crear un servei web que generitokensnous i vàlids per accedir a l’APIdeGoogle Play.

2.3 Escenari del projecte

En aquest projecte, es durà a terme una anàlisi de seguretat d’aplicacions mòbils, més concretament d’aplicacionsAndroidper mitjà del mercat que ofereixGoogle: Google Play. Amb la finalitat d’aconseguir aquesta anàlisi, s’hauran de desenvolupar un conjunt de blocs, on cada un d’ells dependrà de l’anterior per aconseguir l’objectiu proposat, així i tot, cada bloc podrà funcionar de manera independent, de tal forma que cada un serà funcional per si mateix. Concretament aquest projecte es pot dividir en els següents 3 blocs:

• Extracció de la informació:en aquest bloc es pretén definir quina informació s’ha d’obtenir, quina és la millor manera d’aconseguir-la i, posteriorment, l’ex- tracció per mitjà d’un procés descriptingbasat en el concepte decrawler. És a dir, una vegada definida la informació que es necessiti per a realitzar l’anàlisi, es decidirà el mètode d’accés aGooglei serà utilitzat per a realitzar l’extracció de la informació.

• Tractament de la informació:l’objectiu d’aquest bloc és la de realitzar les ope- racions necessàries a les dades (informació) descarregades, amb l’objectiu de guardar tota la informació necessària de manera ordenada i amb el format cor- recte, de tal manera que el pròxim bloc tan sols hagi de processar-la. Per tant, per mitjà d’aquest bloc, s’aplicaran les funcions necessàries a la informació per tal que aquesta pugui ser traspassada al següent bloc de forma ordenada.

• Càlcul de probabilitats:finalment, aquest bloc pren la informació del bloc ante- rior i a partir d’aquesta realitza el procés lògic de càlcul de probabilitat de risc. A més a més, aquest bloc també realitza altres funcions, com la del càlcul d’altres probabilitats (com la probabilitat detrusto la probabilitat dePKI), o el control d’errors en temps d’execució.

A la figura 2.3 es pot veure cada un d’aquests blocs:

Figura 2.3: Escenari general del projecte

2.4. Elecció del mètode d’accés

La figura 2.3 mostra l’escenari (a escala general) del nostre sistema. Tal com es pot observar, a partir del mòdul d’extracció aconseguim tota la informació desitjada, per posteriorment tractar-la en el mòdul de tractament de les dades, d’aquesta for- ma l’entrada al sistema de càlcul de probabilitats és controlada i es podrà facilitar el processament dels càlculs.

2.4 Elecció del mètode d’accés

Un dels punts més complicats i més importants d’aquest projecte és l’elecció d’un mètode d’accés aGoogle Play. Aquest és un procés complex, ja que s’ha de realitzar una recerca orientada cap als nostres objectius. És precisament per aquest motiu, que convé tenir clar quina és la informació que es necessita per a realitzar l’anàlisi.

2.4.1 Informació necessària

Tal com s’ha pogut veure al punt 2.1.2, de tota la informació que proporcionaGoogle Play(com s’ha vist a la figura 2.2), a continuació es descriuen els elements necessaris per a poder realitzar el nostre estudi:

• Identificador d’aplicació:com tot identificador, es tracta d’un codi únic que per- met identificar l’aplicació dins totes les disponibles aGoogle Play. En el nostre cas, serà necessari per a realitzar l’extracció de la informació per cada aplicació.

• Nombre de descàrregues:valor que indica el nombre de vegades que els usuaris han instal·lat l’aplicació al seu dispositiu. Aquest sol ser un nombre que oscil·la entre dos valors aproximats (exemple figura 2.2, 6.2).

• Valoracions:llindar de 0 a 5 que reflecteix les opinions d’un grup determinat d’usuaris que ha fet efectiu el seu dret a valorar l’aplicació. En el nostre cas, serà un factor a tenir en compte a l’hora de calcular la probabilitat detrusto confiança.

• Comentaris:fragments de text en el qual els usuaris poden reflectir els seus pensaments i/o experiències sobre l’aplicació.

• Permisos:conjunt de concessions sobre el teu dispositiu mòbil, que atribueixes a l’aplicació una vegada acceptes les seves condicions d’ús.

• Creador:persona o organisme a la que se li atribueix la llicència d’aquesta aplica- ció. En el nostre cas, ens interessarà saber si aquest és considerat de confiança o no.

• Accés a l’apk: és el paquet utilitzat pel sistema operatiuAndroidper tal de distri- buir i instal·lar les seves distribucions. En el nostre cas, aquest element serà el més important, ja que a partir del’apkes podran extreure els certificats de cada aplicació i calcular la probabilitat dePKIsegons el seu contingut.

2.4.2 Elecció del mètode d’accés

Una vegada sabuda quina és la informació que es vol extreure deGoogle Play, tan sols s’haurà de seleccionar el mètode d’accés (a la sevaAPI) més convenient. Per aquest projecte, s’han estudiat els següents mètodes d’accés a l’APIdeGoogle Play:

APPMONSTA

Aquest sistema d’extracció és el desenvolupat de l’empresaAppMonsta[17] des de l’any 2011. Aquest mètode d’accés presenta diferents tipus de subscripcions segons les necessitats de l’usuari entre les quals destaca la gratuïta, encara que tan sols permet 100 peticions per dia en cada una de les seves cridades. El funcionament d’aquesta eina és molt simple. Abans de començar, s’ha de realitzar un registre que com a resultat s’obté una clau d’accés a l’APIi, amb aquesta i el mateix terminal de l’ordinador, ja pots dur a terme les proves que es necessitin. A la taula 2.2, es pot veure les possibilitats que ofereix aquest mètode d’accés aGoogle Play:

APPMONSTA

Criteris a complir Ho permet?

Identificadors SI

Nombre de descàrregues SI

Valoracions SI

Comentaris SI

Permisos SI

Creador SI

Accés a l’apk NO

Taula 2.2: APPMONSTA

Tal com es pot observar a la taula 2.2, aquest sistema d’extracció no permet l’accés al’apkde les aplicacions (les versions de pagament tampoc). Per aquest motiu s’ha descartat aquest sistema.

APPMONSTA - A tenir en compte Criteri addicional Ho permet?

Gratuït SI - limitat

Facilitat d’ús SI

Codi accessible NO

Taula 2.3: Informació addicional - APPMONSTA

Encara que no compleix amb un dels criteris de selecció també es varen valorar altres factors (veure taula 2.3) per tal de dur a terme una cerca més completa.

Cal destacar que aquest va ser un clar exemple de l’error que és precipitar-se a l’hora de realitzar una elecció d’aquest estil, ja que en un primer moment, aquesta va ser l’elecció. L’error fou donar per suposat que un mètode d’accés a l’APIdeGoogle Play hauria de tenir com a mínim accés al.apk.

2.4. Elecció del mètode d’accés

CRAWLER UC3M

Aquesta eina és el resultat delTFGdeJaime Esquivias Sauras[18], un alumne de la Universitat Carlos III de Madrid. En aquest projecte, es va desenvolupar unCrawler que permetia agafar tota la informació relativa a diferents mercats(Google Play, App Store, Windows Phone)i emmagatzemar-la a una base de dadesMongoDBno relacional.

A la taula 2.4 es pot veure les característiques d’aquest mètode d’accés.

UC3M

Criteris a complir Ho permet?

Identificadors SI

Nombre de descàrregues SI

Valoracions SI

Comentaris SI

Permisos SI

Creador SI

Accés a l’apk SI

Taula 2.4: UC3M

Tal com s’ha pogut comprovar a la taula 2.4, aquest mètode d’accés compleix amb tots els requeriments necessaris, per tant podria ser el sistema d’extracció elegit. Així i tot, a la taula 2.5 s’analitzen algunes característiques més:

UC3M - A tenir en compte

Criteri addicional Ho permet?

Gratuït SI

Facilitat d’ús NO

Codi accessible SI

Taula 2.5: Informació addicional - UC3M

El fet que l’usuari final hagués de realitzar un procés d’instal·lació en local i confi- guració de la base de dades,MongoDB, és un fet que fa que començar a utilitzar aquest mètode d’accés no sigui ràpid ni senzill. Des del meu punt de vista, el mètode d’accés hauria de ser més intuïtiu i menys laboriós.

Google Play Crawler (nviennot/playdrone)

Aquest projecte elaborat per tres investigadors de la Universitat de Columbia a Nova York, també consistia en elaborar unCrawlerper recopilar tota la informació sobre Google Play[19]. A la taula 2.6 es pot veure les característiques d’aquest mètode d’accés.

Crawler (nviennot/playdrone)

Criteris a complir Ho permet?

Identificadors SI

Nombre de descàrregues SI

Valoracions SI

Comentaris SI

Permisos SI

Creador SI

Accés a l’apk SI

Taula 2.6: Crawler (nviennot/playdrone)

Tal com es pot veure a la taula 2.6, pareix un mètode més que acceptable, ja que compleix totes les necessitats del nostre sistema, així i tot tampoc es va escollir aquest sistema per les raons reflectides a la taula 2.7:

Crawler (nviennot/playdrone) - A tenir en compte Criteri addicional Ho permet?

Gratuït SI però confús

Facilitat d’ús NO

Codi accessible SI

Taula 2.7: Informació addicional - Crawler (nviennot/playdrone)

A la taula 2.7, s’han pogut veure les següents peculiaritats d’aquest sistema d’ex- tracció:

• Gratuït: segons indicava la seva documentació es necessitava crear una compta d’una manera peculiar ja que requeria la realització d’un pagament.

• Facilitat: la seva documentació no acabava de deixar clar el seu funcionament o fins i tot la forma amb la que s’haurien de realitzar les peticions.

Google Play UnOfficial Python API

Finalment, es va estudiar el mètode d’accés no oficial a l’APIdeGoogle Playcreat per l’usuari deGitHub egirault[20]. Aquest permet l’accés a tota la informació necessària per al nostre projecte i a més a més el seu codi és accessible i modificable.

2.5. El mètode seleccionat:Google Play UnOfficial Python API

UnOfficial Python API

Criteris a complir Ho permet?

Identificadors SI

Nombre de descàrregues SI

Valoracions SI

Comentaris SI

Permisos SI

Creador SI

Accés a l’apk SI

Taula 2.8:UnOfficial Python API

Com s’ha pogut comprovar a la taula 2.8, aquest mètode d’accés també permet totes les opcions requerides pel nostre sistema. Per tant, a continuació es mostren més factors a tenir en compte.

UnOfficial Python API - A tenir en compte Criteri addicional Ho permet?

Gratuït SI

Facilitat d’ús SI

Codi accessible SI

Taula 2.9: Informació addicional -UnOfficial Python API

A la taula 2.9, s’ha pogut comprovar com aquest mètode d’accés compleix tots els requeriments del nostre sistema. Per tant aquest ha estat el mètode d’accés a l’APIde Googleseleccionat.

2.5 El mètode seleccionat: Google Play UnOfficial Python API

Google Play UnOfficial Python APIés el mètode seleccionat per tal de poder dur a terme els accessos a l’APIdeGoogle Play, l’origen d’aquest projecte resideix en la publicació del projecte per part de l’usuariegirault, el 8 de Desembre de 2012, a la plataforma de desenvolupamentGithub. La tecnologia amb la qual s’ha programat aquest projecte ésPythoni, el fet que el codi sigui accessible, fa que es pugui adaptar a les necessitats de cada usuari. Aquest projecte consta d’un arxiuPythonper a cada una de les seves cridades, encara que totes hereten d’una classe principalgoogleplay.py. A continuació s’explicarà el contingut de cada una de les classes d’aquest projecte:

• Classe preparar (setup.py): permet preparar el projecte en la seva instal·lació.

• Classe principal (googleplay.py): és la classe principal del projecte i conté totes les funcions necessàries per a realitzar l’accés a l’APIdeGoogle, tant les necessàries per a realitzar l’autenticació com la definició de cada una de les cridades a l’API.

• Classe utilitats (helpers.py): on es recullen una sèrie de mètodes necessaris per a realitzar un conjunt d’utilitats tals com imprimir sortides, calcular volums d’informació, etcètera.

• Classe configuració (config.py): en aquesta classe es recullen les credencials dels usuaris, així com un mètode simple per tal d’obtenir eltokend’autenticació de Google Play.

• Classe descarrega (download.py): permet descarregar els.apkde cada aplicació per mitjà del seu identificador.

• Classe permisos (permissions.py): permet descarregar tots els permisos de cada aplicació per mitjà del seu identificador.

• Classe categories (categories.py): s’utilitza amb l’objectiu d’extreure totes les categories d’aplicacions que existeixen aGoogle Play.

• Classe cerca (search.py): permet treure la informació sobre una determinada aplicació o grup d’aplicacions (per categoria).

• Classe llistat (list.py): permet obtenir un conjunt d’aplicacions segons la seva categoria i segons el seu paper en el mercat (gratuïtes, més venudes, etc). En aquest projecte no s’ha utilitzat.

• Classe detalls (details.py): permet obtenir els detalls d’una determinada aplicació, tals com descripcions, imatges, versió, etc. En aquest projecte no s’ha utilitzat.

• Classe comentaris (reviews.py): permet obtenir els comentaris que s’han realit- zat d’una determinada aplicació (amb un límit de 500 comentaris). En aquest projecte no s’ha utilitzat.

• ClasseshellApi(apishell.py): aquest mètode d’accés també permet executar una shellinteractiva per a realitzar les cridades. No s’ha utilitzat durant aquest projec- te.

Una vegada analitzades cada una de les funcionalitats que permet aquest projecte, s’explicarà el procés de realització per tal de poder començar a utilitzar qualsevol de les seves cridades:

1. La primera passa a realitzar consisteix en instal·lar un nou entorn virtual (vir- tualenv). Aquest aspecte és optatiu, però és recomanable pel fet que així no es comprometen les versions de paquets o llibreries d’altres projectesPython. L’ús d’un entorn virtual permet a l’usuari executar un projecte amb unes versions totalment diferents de les que es tenen instal·lades fora d’aquest entorn. Per mitjà d’aquest procés es pretén resoldre els problemes d’incompatibilitat entre versions de diferents projectes.

2.5. El mètode seleccionat:Google Play UnOfficial Python API

Figura 2.4:Pythona l’entorn virtual

A la figura 2.4 s’ha pogut comprovar com dins el nou entorn virtual existeix una carpeta amb totes les llibreries afegides al nou entornpython, a més a més d’incloure els paquetspythoninstal·lats en el mateix dispositiu.

2. Modificar l’arxiu de configuració (config.py) amb l’objectiu de poder autenticar- se correctament ambGoogle. Per tal d’aconseguir-ho, s’han de seguir les següents passes:

• En el cas que l’usuari que vulgui utilitzar aquest mètode d’accés no tengui un compteGooglehaurà de crear un nou compte, d’aquesta manera podrà seguir utilitzant l’eina.

• Necessitat d’introduir unes credencials deGoogleemplenant els següents camps:

– LANG: on es pot seleccionar el mercat en el qual es vol realitzar les consultes.

– ANDROID_ID: correspon a l’identificador únic d’un dispositiuAndroid vinculat amb un determinat correu electrònic. Per tal d’aconseguir aquest identificador, existeix una aplicació anomenadaDevice IDque permet visualitzar-la directament en el dispositiu.

– GOOGLE_LOGIN: correspon a un correu electrònic vàlid i prèviament registrat a un compteGoogle.

– GOOGLE_PASSWORD: correspon a la teva clau secreta vinculada amb el correu electrònic anterior.

– AUTH_TOKEN: com s’ha comentat anteriorment per tal d’autenticar-se ambGoogleés necessari l’ús detokensd’autenticació.

LANG = "en_US" # can be en_US , fr_FR , . . . ANDROID_ID = "XXXXXXXXXXXXX"

GOOGLE_LOGIN = " user@gmail .com"

GOOGLE_PASSWORD = "password"

AUTH_TOKEN = " tokenAuth " # " yyyyyyyyy "

• Aquest mètode d’accés permet definir un separador amb l’objectiu d’a- conseguir una sortida de la informació més ordenada. Per mitjà de l’ús

d’aquest separador al punt es podrà tractar la informació com si es tractés d’un document.csv. En el nostre cas s’ha triat (’;’).

SEPARATOR = " ; " #per separar

Un exemple clar de la importància de definir el separador es pot veure a la figura 2.8 o 2.7. En aquest cas, es pot veure que el separador dels camps és el

’;’ comentat anteriorment. D’aquesta forma, el tipus de document utilitzat per emmagatzemar la informació (.csv), podrà donar format a la sortida.

3. Aquest mètode d’accés no presenta una funció que retorni els identificadors de totes les aplicacions, ja que aquest mètode d’accés retorna els identificadors segons la categoria seleccionada a la petició (el que en principi no pareix un problema). Però s’ha pogut comprovar que la resposta mai és de més de 200 identificadors, essent insuficient per a realitzar una anàlisi complet. Per aquest motiu, es va tractar de modificar l’arxiuhelpers.py, on si defineix la longitud de la resposta. Tot i així, tampoc s’ha pogut obtenir una resposta de més de 200-300 identificadors, provocant la recerca d’una alternativa que ha consistit amb l’ús d’un arxiu.csv. Aquest document ha estat recogit de la investigació realitzada pels creadors deMAETROID[21] i conté tots els identificadors de les aplicacions.

Una vegada realitzats els punts comentats, ja es podrà començar a utilitzar el mètode d’accés. Realitzar alguna de les seves cridades és simple, ja que tan sols s’hi ha de definir la cridada i el format de la petició a realitzar. El format que presenten aquestes trucades segueix el següent patró:

python c l a s s e . py es .id. apk

//on es .id. apk representa l ’ i d e n t i f i c a d o r de l ’ a p l i c a c i ó A continuació es mostren alguns exemples de les cridades més utilitzades:

• Descarregar aplicacions: aquest mètode d’accés permet realitzar descarregues d’aplicacions a partir del identificador d’aplicació. A la figura 2.5 es pot veure un exemple.

Figura 2.5: Exemple descarregar aplicació

A la figura 2.5, s’ha aconseguit extreure el.apka partir de l’identificador de l’apli- cació. Aquest.apkes generà al directori on s’hagui executat la comanda.

• Descarregar permisos: aquest mètode d’accés permet realitzar descarregues de permisos a partir del identificador d’aplicació. A la figura 2.6 es pot veure un exemple.

2.5. El mètode seleccionat:Google Play UnOfficial Python API

Figura 2.6: Exemple extracció de permisos

A la figura 2.6, s’han aconseguit extreure tots els permisos a partir de l’identifica- dor de l’aplicació. El resultat de l’execució en aquest cas tan sols es mostra per terminal, encara que modificant la comanda de la següent forma:

python permissions . py es . id . apk > t e s t. t x t // es pot guardar e l r e s u l t a t en un document .

• Cercar per identificador: aquest mètode d’accés permet realitzar la cerca de les característiques d’una determinada aplicació. A la figura 2.7 es pot veure un exemple.

Figura 2.7: Exemple cerca per identificador

A la figura 2.7, s’han aconseguit extreure totes les característiques d’una determi- nada aplicació i similars. En el cas que tan sols es vulgui obtenir les característi- ques de l’aplicació sol·licitada, serà necessari indicar la longitud de la resposta (offset) de la següent forma:

python search . py es . id . apk 1

• Llistar aplicacions: aquest mètode d’accés permet llistar les diferents classifi- cacions a partir d’una determinada categoria. A la figura 2.8 es pot veure un exemple.

Figura 2.8: Exemple llistar subcategories

A la figura 2.8, es pot veure com es permet llistar a partir d’una determinada categoria extreure els seus diferents tipus de classificació.

• Obtenir els detalls d’una aplicació: aquest mètode d’accés permet extreure in- formació els detalls d’una determinada aplicació. A la figura 2.9 es pot veure un exemple.

Figura 2.9: Exemple extreure detalls d’aplicacions

A la figura 2.9, s’obtenen els detalls d’una determinada aplicació, en aquest cas el resultat s’obté en formatjson.

• Obtenir els comentaris d’una aplicació: aquest mètode d’accés permet extreure els comentaris d’una determinada aplicació. A la figura 2.10 es pot veure un exemple.

Figura 2.10: Exemple extracció de comentaris

A la figura 2.10, s’obtenen tots els comentaris d’una determinada aplicació, en aquest cas el resultat s’obté en formatjson.

2.6. Dispensador detokens

Tal com s’ha pogut observar a les dos darrers figures (2.9 i 2.10) per a l’extracció de detalls i comentaris, el format de sortida és diferent (és en format json). Aquestes dues classes es varen agafar d’un altra branca del projecte (la realitzada per l’usuari paolocalciati[22]). Això és degut al fet que el projecte principal no permetia accedir a aquesta informació, i malgrat que en aquest projecte no s’ha arribat a utilitzar, aquestes dues funcionalitats podran ser útils en un treball futur.

2.6 Dispensador de tokens

Tal com s’ha explicat a l’apartat 2.5, eltoken és un dels elements necessaris per a l’autenticació ambGoogle. Per aquest motiu, va ser imprescindible l’ús d’un projecte secundari, per tal de poder autenticar les peticionsGoogle, i així aconseguir que les respostes d’autenticació deGoogleno fossin errònies. En aquesta secció es descriurà aquest projecte.

2.6.1 Anàlisi del problema

Durant el procés de realització de les primeres proves amb el mètode d’accés selecci- onat, es va poder comprovar que amb la configuració per defecte (tal com s’ha vist a l’apartat 2.5), quan el campAUTH_TOKENs’inicialitza anullel 50% de les peticions fallaven per l’error: ’BadAuthentication’, a la figura 2.11 es pot veure un exemple:

Figura 2.11: Exemple extracció de comentaris

Tal i com s’ha pogut comprovar a la figura 2.11, aquest error és provocat per una mala autenticació ambGoogle. Aquest problema provoca haver de repetir la mateixa petició diverses vegades amb l’objectiu d’obtenir el resultat satisfactori (com s’ha vist a la figura 2.8).

És precisament per aquest motiu que es va decidir cercar un mètode alternatiu per tal d’obtenirtokensd’autenticació d’accés aGoogle Play, i d’aquesta manera acabar amb els problemes d’autenticació i els consegüents problemes de realització de més cridades de les necessàries per obtenir la resposta correcta.

2.6.2 Anàlisi del projectetoken dispenser

Per tal de resoldre l’inconvenient explicat a l’apartat 2.6.1, el projecte seleccionat és eldockerdel dispensador detokensde l’usuariNoMore201[23]. Aquest es bassa en el projecte de l’usuariyeriomin[24]. Aquest projecte permet generartokensd’autenticació

deGoogle Play de manera simple i amb la possibilitat de fer-ho de dues maneres diferents segons les necessitats de l’usuari. Aquestes dues possibilitats es poden explicar de la següent manera:

• Per mitjà d’una base de dadesMONGODB: per mitjà d’aquest mètode d’accés es permet obtenirtokenssegons si un determinat usuari presenta una entrada amb el seu nom creada a la base de dades. És a dir, tan sols podran obtenirtokens d’autenticació aquells usuaris registrats a la base de dades. Aquest mètode pareix idoni per aquells sistemes que pretenen tenir un volum elevat d’usuaris.

• Per mitjà d’un fitxer configurable: aquest mètode és molt més simple i tan sols requereix de l’actualització de l’arxiu de configuració per part de l’usuari amb les seves credencials. S’ha elegit aquesta funció pel fet que resulta suficient per a l’abast d’aquest projecte.

Cal tenir en compte que aquest mètode d’accés alstokensdeGoogle Playés un projecte totalment nou i pot experimentar canvis.

2.6.3 Funcionament d’aquest projecte

En aquest apartat es descriu el procés a seguir per tal d’executar aquest projecte i començar a rebretokensd’autenticació. Per tal d’engegar el dispensador detokens, s’han de seguir les següents passes:

1. Per tal d’utilitzar el softwaredocker, s’haurà d’instal·lar prèviament.

2. Accedir al directori d’aquest projectedocker-tocken-dispenserper mitjà de la comandacddel teu terminal.

3. Accedir al subdirectoribackend-plaintext.

4. Veure l’estat delsdockerdel teu sistema per mitjà de la següent comanda:docker info. O si vols veure l’estat dels processosdockerexecutats en el teu sistema:

docker ps.

Figura 2.12:docker stopped

5. Compilar la imatge deldockerper mitjà de la següent comanda:

sudo docker build −t tokendispenser .

6. Crear un nou container amb el nom detokendispenseral port 8080.

sudo docker run −d −−name tokendispenser −p 8080:8080 tokendispenser

2.6. Dispensador detokens

7. En aquest punt eldockerhauria d’estar engegat i per tant el dispensador detokens en execució.

Figura 2.13:docker running

8. Així i tot, si es vol comprovar com efectivament el dispensador detokenscrea noustokens, es pot accedir a la següent direcció:

http : / / server−address : port / token / email / youremail@gmail .com Aquestemailhaurà de ser el mateix que el definit en el moment de la instal·lació a l’arxiuentrypoint.sh.

Figura 2.14: Servei en funcionament

Tal com s’ha pogut veure a la figura 2.14 el resultat d’això és el següenttoken:

’5QTdOH..1djA.’.

En conclusió, aquest projecte ha suposat una solució simple i ràpida respecte a l’incon- venient amb l’autenticació ambGoogle Play. Convé recordar que aquest servei s’haurà de llançar cada vegada que se’n vulgui fer ús del projecte d’accés aGoogle Play. Per tal d’aconseguir-ho, tan sols és necessari llançar la següent comanda des del directori docker-tocken-dispenser/backend-plaintext:

sudo docker s t a r t tokendispenser

C

3

D ESENVOLUPAMENT DEL PROJECTE

En aquest capítol s’explica de manera detallada el procés realitzat per dur a terme cada una de les parts que formen la plataforma, amb l’objectiu de dur a terme l’anàlisi de seguretat en aplicacionsAndroida partir de les formules de modelatge elaborades a altres projectes. En aquest apartat de la memòria es pretén entrar en detall amb el procediment realitzat per aconseguir el funcionament de cada bloc de la plataforma (introduïts a la figura 2.3). Per tant, en aquest capítol s’explicarà el procediment duit a terme per tal de desenvolupar des del sistema d’extracció, fins al càlcul de probabilitats, passant pel tractament de la informació. A continuació es realitza una breu descripció de cada un dels blocs d’aquesta plataforma:

• Bloc 1 (Sistema d’extracció -Crawler): és el primer bloc de la plataforma i con- sisteix en desenvolupar un conjunt de scriptsque permetin l’extracció de la informació deGoogle Playde manera automàtica.

• Bloc 2 (Tractament de la informació): aquest bloc consisteix en un conjunt de scriptsque permeten modificar la sortida del primer bloc amb l’objectiu de donar un format més fàcilment processable per al càlcul de probabilitats.

• Bloc 3 (Càlcul de probabilitats): finalment aquest bloc permet a partir de la informació se sortida del segon bloc processar tota la informació i realitzar els càlculs necessaris per a l’anàlisi de la seguretat d’aplicacionsAndroid.

3.1 Sistema d’extracció (Crawler)

Tal com ens recordavaImam Ali[25]"Knowledge is power", el coneixement és poder. La informació és la base de tot projecte, i més en aquest cas, on es vol analitzar un aspecte tan ampli com és la seguretat en aplicacionsAndroid.

Una vegada clares les funcionalitats del mètode d’accés elegit i la informació que necessitam, tan sols queda implementar tota la lògica necessària per a dur-ho a terme.

A la figura 3.1 es pot veure l’estructura d’aquest bloc:

Figura 3.1: Procés d’extracció

A la figura 3.1, es reflecteix l’estructura i funcionament d’aquest bloc. A continuació s’explicarà la funció de cada un dels elements que el conformen.

• Usuari: és la persona que decideix quines funcions es volen dur a terme.

• Google Playstore: com s’ha explicat durant tot aquest document,Google Playés el mercat sobre el qual se centra aquesta anàlisi i per tant serà l’origen de la majoria de la informació a analitzar.

• Informaciócsv: és l’origen de part de la informació. S’alimenta de la base de dades deGoogle Playstore.

• Sistema d’extracció (Crawler): realment la paraulaCrawlerno seria l’ideal per aquest element, ja que no fa les funcions típiques decrawling com és l’accés directe a recursos de pàginesweb. En aquest projecte, es tracta d’un conjunt descriptsque realitzen funcions específiques (com extreure identificadors, ca- racterístiques, permisos, etc.), per tal d’aconseguir extreure tota la informació necessària per al seu posterior processament. Això ho aconseguirà accedint direc- tament (a través del mètode d’accés seleccionat) o de manera indirecta (a través del fitxer addicional).

3.1. Sistema d’extracció (Crawler)

• Espai d’emmagatzemament: és l’espai o lloc on es guardarà tota aquella infor- mació que s’extraurà en el sistema. En aquest cas consisteix en un directori amb diferents subdirectoris.

Una vegada vists tots aquests elements, es pot passar a explicar el funcionament dels scripts que permeten extreure tota la informació.

3.1.1 Extracció des d’arxiu local.csv

Com s’ha explicat al punt 2.5, una vegada decidit el mètode d’accés, es va descobrir la limitació que presenta a l’hora d’extreure els identificadors de les aplicacions. A causa d’aquest factor es va decidir utilitzar un fitxer.csvcomplementari per tal d’acabar amb aquesta limitació.

Una vegada solucionat el problema amb els identificadors de les aplicacions, es comen- çarà amb el procés de la seva extracció representat a la figura 3.2.

Figura 3.2: Extracció utilitzant un fitxer .csv

Per tal d’aconseguir realitzar l’extracció de tots els identificadors, a partir del fitxer, es va utilitzar unscriptamb el següent funcionament:

1. Accedir a la carpeta que conté aquest arxiu. Per dur a terme aquesta acció s’utilitza la comandacd.

route=" Laine / l l i s t a A p l i c a c i o n s / l i s t _ a p p s . csv "

cd $route

A la figura 3.3 es pot veure una part del fitxerlist_apps.csv:

Figura 3.3: Fitxer.csvinicial

2. Extreure la primera columna de l’arxiu. Per això s’utilitza la comandaawk.

function t r e u r e I n f o E x c e l {

awk −F " ; " ’ { p r i n t $1 } ’ l i s t _ a p p s . csv > aux . t x t }

3. Eliminar la part identificativa pròpia deGoogle, ja que posteriorment ens causaria problemes a l’hora d’utilitzar els identificadors. Per això s’utilitza la comandased.

function recoirID { #eliminam la part i d e n t i f i c a t i v a de google borrar=" https : / / play . google .com/ s t o r e /apps/ d e t a i l s ? id="

sed ’ s , ’ $borrar ’ , , g ’ "aux . t x t " > info2 . t x t }

El resultat d’aquesta execució, serà un document de text (.txt) amb tots els identificadors línia a línia. A la figura 3.4 es veu una part del seu contingut.

Figura 3.4: Resultat extraccióid’s

3.1.2 Extracció des deGoogle Play Store

El procés anterior és fonamental per tal de poder utilitzar les classes del mètode d’accés, ja que, com s’ha explicat a l’apartat 2.5, totes aquestes necessiten l’identificador de l’aplicació. A més a més, com s’ha vist a la figura 3.4 el procés anterior ha permès guardar de manera ordenada tots els identificadors i per tant facilitar el procés d’automatitzar l’extracció. Per tant, aquest bloc pretén a partir del fitxer d’identificadors (aconseguit al procés anterior) i de les classes que proporciona el mètode d’accés automatitzar el procés d’extracció. A la figura 3.5 es pot veure l’estructura del procés d’extracció des de l’APIdeGoogle Play.

3.1. Sistema d’extracció (Crawler)

Figura 3.5: Extracció des deGoogle Play

Per a dur a terme el procés d’automatització (3.5), s’han creat un conjunt descripts amb funcions diferents segons la informació que es vol extreure. Així i tot, cada un d’aquests comparteixen una mateixa estructura per tal d’aconseguir dur a terme l’ex- tracció:

1. Guardar les rutes necessàries per a l’emmagatzemament i recerca de la informa- ció. Ja que durant tot moment es necessita l’accés a directoris/fitxers de diferents ubicacions serà necessari guardar aquesta informació a diferents variables per tal d’utilitzar-les posteriorment. Per fer això, s’utilitza la comanda ’$pwd’ que permet obtenir la ruta en temps d’execució.

function treureRutes { rutaTFG=$ ( ’pwd’ ) cd apks

v a l i d a r F i t x e r rutaApks=$ ( ’pwd’ ) }

2. Validar l’existència de la carpeta. Ja que l’espai d’emmagatzemament del projecte consisteix en una jerarquia de directoris, serà imprescindible crear noves carpetes.

Aquesta validació es realitza per mitjà de la següent funció que permet determinar si existeix (o no) una determinada carpeta.

function validarCarpeta {

i f [ ! −d carpeta ] ; then # s i no e x i s t i s t e i x . . .

#cream la carpeta on guardarem e l s permisos / apks . . mkdir carpeta

f i }