Anàlisi de seguretat d'aplicacions Android

Texto completo

(1)Treball Fi de Grau. 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 Palma, 6 de setembre de 2017.

(2)

(3) S UMARI. Sumari. i. Agraïments. iii. Resum. v. Glossari. vii. 1. Introducció al projecte 1.1 Contextualització . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Objectius . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Estructura de la memòria . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 2. Tecnologies necessàries 2.1 Google Play . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Android . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Com s’organitza la informació . . . . . . . . . . . . 2.1.3 Gestió de seguretat a la plataforma . . . . . . . . . 2.2 Tecnologies a utilitzar . . . . . . . . . . . . . . . . . . . . . . 2.2.1 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Python . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Scripting (bash) . . . . . . . . . . . . . . . . . . . . . 2.2.4 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.5 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Escenari del projecte . . . . . . . . . . . . . . . . . . . . . . 2.4 Elecció del mètode d’accés . . . . . . . . . . . . . . . . . . . 2.4.1 Informació necessària . . . . . . . . . . . . . . . . . 2.4.2 Elecció del mètode d’accés . . . . . . . . . . . . . . 2.5 El mètode seleccionat: Google Play UnOfficial Python API 2.6 Dispensador de tokens . . . . . . . . . . . . . . . . . . . . . 2.6.1 Anàlisi del problema . . . . . . . . . . . . . . . . . . 2.6.2 Anàlisi del projecte token dispenser . . . . . . . . . 2.6.3 Funcionament d’aquest projecte . . . . . . . . . .. 3. 1 2 7 7. . . . . . . . . . . . . . . . . . . .. 9 9 9 11 13 14 14 14 15 15 15 16 17 17 18 21 27 27 27 28. Desenvolupament del projecte 3.1 Sistema d’extracció (Crawler) . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Extracció des d’arxiu local .csv . . . . . . . . . . . . . . . . . . . .. 31 32 33. i. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . ..

(4) ii. SUMARI . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. . . . . . . . . . . . . .. 34 38 40 40 42 44 45 48 50 55 55 55 59. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 63 63 65 73 73 74. Conclusions i treball futur 5.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Treball futur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 77 77 78. 3.2. 3.3. 4. 5. 3.1.2 Extracció des de Google Play Store . . 3.1.3 Emmagatzemament de la informació Tractament de la informació . . . . . . . . . . 3.2.1 Tractament de les dades . . . . . . . . 3.2.2 Tractament de certificats . . . . . . . Càlcul de probabilitats . . . . . . . . . . . . . 3.3.1 Format d’entrada . . . . . . . . . . . . 3.3.2 Càlcul Trust . . . . . . . . . . . . . . . 3.3.3 Càlcul PKI . . . . . . . . . . . . . . . . 3.3.4 Càlcul probabilitat total . . . . . . . . 3.3.5 Càlcul probabilitat de risc . . . . . . . 3.3.6 Format de sortida . . . . . . . . . . . 3.3.7 Utilitats a tenir en compte . . . . . .. Resultats 4.1 Scripts que formen el projecte 4.2 Execució del projecte . . . . . 4.3 Interpretació dels resultats . 4.3.1 Probabilitat total . . . 4.3.2 Impacte . . . . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. Índex de figures. 81. Índex de taules. 83. Bibliografia. 85.

(5) 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 tutora Xisca 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 demostrat 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.. iii.

(6)

(7) 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’aplicacions Android, per a aconseguir això s’han realitzat diferents mòduls amb funcionaments 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ó de Google Play que permet extreure la informació relativa a les aplicacions del mercat de Google 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’aplicacions Android en el mercat de Google Play mòduls com el de càlcul de probabilitats podran ser utilitzats per a l’anàlisi d’altres mercats com per exemple AppStore. 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.. v.

(8)

(9) 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 Software la 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 Interface conjunt 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’objectiu d’automatitzar un procés. vii.

(10) viii. GLOSSARI. Crawler Aranya web, es tracta d’un petit programa que s’encarrega de recórrer l’entremat web de 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 funcionament d’una màquina virtual lleugera. Token Cadena de caràcters que en un determinat llenguatge de programació pot presentar un significat coherent..

(11) CAPÍTOL. 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 aplicacions Android, 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.

(12) 1. I NTRODUCCIÓ AL PROJECTE. 1.1 Contextualització L’inici d’aquest segle XXI 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 Intelligence conclueixen 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ó de Statista que 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 la GSMA 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:. 2.

(13) 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 connexions. 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 de Comscore a l’any 2014) el nombre d’usuaris dels dispositius mòbils va superar (per primer cop) al nombre d’usuaris d’ordinador. 3.

(14) 1. I NTRODUCCIÓ AL PROJECTE Tot això és degut, entre altres coses, al desenvolupament en paral·lel de les anomenades aplicacions mòbils (app). Una app consisteix 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ó de smartphone 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 de techcrunch que al mateix temps pren aquesta figura de l’empresa d’anàlisi Appannie [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 desenvolupament 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 plataforma Symantec [6] s’ha identificat més d’1 milió d’aplicacions mòbils infectades amb malware, a més de moltes altres amb funcions també perjudicials per als usuaris tals com spyware, aparició abundant de publicitat, etcètera. Des d’un informe publicat per l’empresa Nokia assegura que la quantitat d’infeccions s’ha incrementat considerablement a l’any 2016, especialment els dispositius Android. A la figura 1.5 es troben alguns percentatges interessants. 4.

(15) 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 de malware, de fet en aquest mateix informe [7] s’hi reflexa que del 85% d’aplicacions infectades el 81% corresponia a dispositius Android mentre que tan sols el 4% pertanyia a dispositius iOS. 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 les app’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 instal·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 joc Clash Royale) i un altre que sol·licita un gran nombre de permisos innecessaris (Linterna):. Figura 1.6: Exemples de sol·licitud de permisos. 5.

(16) 1. I NTRODUCCIÓ AL PROJECTE 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 Fotos/Multimèdia/Arxius Emmagatzemament Wi-Fi Rebre dades d’internet Connectar a xarxes Wi-Fi Accés a xarxa Control de vibració Impedir mode suspens Càmera Id del dispositiu i dades de trucada Accés administrador de trucades Actualitzar estadístiques Modificar estadístiques Executar al inici Tancar altres aplicacions Modificar ajustaments del sistema Control barra d’estat Vincular amb dispositius bluetooth Telèfon (trucar, redirigir) Ubicació Contactes. SI SI SI SI SI SI SI SI SI NO NO NO NO NO NO NO NO NO NO NO NO NO. NO SI SI SI SI SI SI SI SI SI SI SI SI SI SI SI SI SI SI SI SI 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’id del 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’aquesta 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.. 6.

(17) 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’aconseguirho s’haurà de definir quina informació és la que es vol analitzar, per posteriorment, realitzar una cerca i posterior anàlisi dels diferents mètodes d’accés a l’API de Google, 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 simplificar 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’explicarà 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 característiques del mètode d’accés a l’API de Google seleccionat. 7.

(18) 1. I NTRODUCCIÓ AL PROJECTE. 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.. 8.

(19) CAPÍTOL. 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 funcionament 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’API de Google Play, juntament amb l’explicació del mètode seleccionat. Finalment es conclou aquest capítol amb l’explicació del projecte seleccionat per tal d’obtenir tokens d’autenticació vàlids per a l’accés a l’API de Google 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’anomenat AndroidMarket amb Google 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 operatiu Android. 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 de Google 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 Play distribueix aplicacions del sistema operatiu Android, el qual es troba basat amb el nucli d’un altre sistema operatiu com és Linux. Aquestes aplicacions es troben programades a través del llenguatge de programació Java, encara que els desenvolupadors utilitzen Android SDK tools per 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 9.

(20) 2. T ECNOLOGIES NECESSÀRIES 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" /> <application 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−−> <activity android:name=" . nomLayerMain" and r o i d: l ab 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 > <activity android:name=" . nomLayer" and r o i d: l ab 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 " /> </ application> </ manifest>. Com s’ha pogut comprovar, en aquest document s’hi defineix l’identificador únic de l’aplicació (en aquest cas com.example.nomID), els permisos (per exemple: android.permission.READ_CONTACTS per a accedir als contactes) i finalment cada un dels layers (les activity, per exemple nomLayerMain) que formen les pantalles l’aplicació. 10.

(21) 2.1. Google Play • Recursos d’aplicació (assets): directori que conté recursos d’aplicació que poden ser recuperats per l’AssetManager (aquest permet accedir al raw dels 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 .jar del main de 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’aplicació. 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 que Google Play permet 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 Biblioteques i demos Compres Empresa Finances Mapes i navegació Personalització Ser pares. Art i Disseny Casa Comunicació Entrades i events Fotografia Medicina Productivitat Social. Automoció Menjar i beure Deports Entreteniment Eines Música Reproductors i editors Jocs. Bellesa Còmics Educació Estil de vida Llibres Noticies i revistes Salut i benestar Família. Taula 2.1: Categories a GooglePlay. 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 algunes de les categories, tals com joc o família. A més a més de tot això, Google Play també proporciona molta més informació a nivell d’aplicació. Aquesta informació es pot veure tot seguit a la figura 2.2. 11.

(22) 2. T ECNOLOGIES NECESSÀRIES. Figura 2.2: Informació que ofereix Google Play sobre 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. 12.

(23) 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 de Google Play ha 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 per Hiroshi Lockheimer [8] es va presentar una nova capa de seguretat que va prendre el nom de Google Bouncer; Una eina permet automatitzar el procés de cerca d’aplicacions amb malware dins 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), spyware i troyans. 2. També es realitza una cerca en funció de comportaments que puguin ser maliciosos. 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ó de malware, en aquest mateix article s’indica que després de sofrir els efectes del malware sobre els primers dispositius connectats a la xarxa, els dissenyadors Android varen 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ó. 13.

(24) 2. T ECNOLOGIES NECESSÀRIES • 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 conseqüència decidir si la vol (o no) instal·lar. • L’eliminació de malware: segons aquest document, Android es troba dissenyat per evitar que el malware modifiqui 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 aplicacions Android no 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 Interface) [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, independentment 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 de API’s és Google, de fet en aquest projecte es farà servir de manera directa l’API d’accés a Google 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 per Guido 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’API de Google Play Store està programat amb Python. 14.

(25) 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 fer scripting per 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 per James Gosling de Sun Microsystems [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 possibilitat 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 de scripting, 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 part Java de càlcul de probabilitat 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 .csv de sortida com a resultat del projecte. • IAIK : aquesta llibreria [15] permet poder tractar tant els certificats de les aplicacions com tota la informació que contenen i per tant per al càlcul de la probabilitat de PKI.. 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 addicional d’abstracció i automatització de virtualització a nivell de sistema operatiu Linux. Aquests contenidors en fan ús de les característiques d’aïllament del kernel de Linux (cgroups i namespaces) per tal de permetre que diversos contenidors s’executin dins una mateixa instància de Linux. 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 de tokens, és a dir, amb l’objectiu de crear un servei web que generi tokens nous i vàlids per accedir a l’API de Google Play. 15.

(26) 2. T ECNOLOGIES NECESSÀRIES. 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’aplicacions Android per mitjà del mercat que ofereix Google: 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’extracció per mitjà d’un procés de scripting basat en el concepte de crawler. É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 a Google i serà utilitzat per a realitzar l’extracció de la informació. • Tractament de la informació: l’objectiu d’aquest bloc és la de realitzar les operacions necessàries a les dades (informació) descarregades, amb l’objectiu de guardar tota la informació necessària de manera ordenada i amb el format correcte, 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 anterior 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 de trust o la probabilitat de PKI), 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. 16.

(27) 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 forma 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 a Google 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 proporciona Google 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 permet identificar l’aplicació dins totes les disponibles a Google 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 de trust o 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 aplicació. 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 operatiu Android per tal de distribuir i instal·lar les seves distribucions. En el nostre cas, aquest element serà el més important, ja que a partir de l’apk es podran extreure els certificats de cada aplicació i calcular la probabilitat de PKI segons el seu contingut. 17.

(28) 2. T ECNOLOGIES NECESSÀRIES. 2.4.2 Elecció del mètode d’accés Una vegada sabuda quina és la informació que es vol extreure de Google Play, tan sols s’haurà de seleccionar el mètode d’accés (a la seva API) més convenient. Per aquest projecte, s’han estudiat els següents mètodes d’accés a l’API de Google Play: APPMONSTA Aquest sistema d’extracció és el desenvolupat de l’empresa AppMonsta [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’API i, 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 a Google Play: APPMONSTA Criteris a complir. Ho permet?. Identificadors Nombre de descàrregues Valoracions Comentaris Permisos Creador Accés a l’apk. SI SI SI SI SI SI NO. Taula 2.2: APPMONSTA Tal com es pot observar a la taula 2.2, aquest sistema d’extracció no permet l’accés a l’apk de 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 Facilitat d’ús Codi accessible. SI - limitat SI 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’API de Google Play hauria de tenir com a mínim accés al .apk. 18.

(29) 2.4. Elecció del mètode d’accés. CRAWLER UC3M Aquesta eina és el resultat del TFG de Jaime Esquivias Sauras [18], un alumne de la Universitat Carlos III de Madrid. En aquest projecte, es va desenvolupar un Crawler que permetia agafar tota la informació relativa a diferents mercats (Google Play, App Store, Windows Phone) i emmagatzemar-la a una base de dades MongoDB no 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 Nombre de descàrregues Valoracions Comentaris Permisos Creador Accés a l’apk. SI SI SI SI SI SI 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 Facilitat d’ús Codi accessible. SI NO 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 configuració 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 un Crawler per 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. 19.

(30) 2. T ECNOLOGIES NECESSÀRIES Crawler (nviennot/playdrone) Criteris a complir. Ho permet?. Identificadors Nombre de descàrregues Valoracions Comentaris Permisos Creador Accés a l’apk. SI SI SI SI SI SI 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 Facilitat d’ús Codi accessible. SI però confús NO 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’extracció:. • 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’API de Google Play creat per l’usuari de GitHub 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. 20.

(31) 2.5. El mètode seleccionat: Google Play UnOfficial Python API UnOfficial Python API Criteris a complir. Ho permet?. Identificadors Nombre de descàrregues Valoracions Comentaris Permisos Creador Accés a l’apk. SI SI SI SI SI SI 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 Facilitat d’ús Codi accessible. SI SI 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’API de Google seleccionat.. 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’API de Google Play, l’origen d’aquest projecte resideix en la publicació del projecte per part de l’usuari egirault, el 8 de Desembre de 2012, a la plataforma de desenvolupament Github. La tecnologia amb la qual s’ha programat aquest projecte és Python i, el fet que el codi sigui accessible, fa que es pugui adaptar a les necessitats de cada usuari. Aquest projecte consta d’un arxiu Python per a cada una de les seves cridades, encara que totes hereten d’una classe principal googleplay.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’API de Google, tant les necessàries per a realitzar l’autenticació com la definició de cada una de les cridades a l’API. 21.

(32) 2. T ECNOLOGIES NECESSÀRIES • 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 el token d’autenticació de Google Play. • Classe descarrega (download.py): permet descarregar els .apk de 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 a Google 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 realitzat d’una determinada aplicació (amb un límit de 500 comentaris). En aquest projecte no s’ha utilitzat. • Classe shellApi (apishell.py): aquest mètode d’accés també permet executar una shell interactiva per a realitzar les cridades. No s’ha utilitzat durant aquest projecte. 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 (virtualenv). Aquest aspecte és optatiu, però és recomanable pel fet que així no es comprometen les versions de paquets o llibreries d’altres projectes Python. 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. 22.

(33) 2.5. El mètode seleccionat: Google Play UnOfficial Python API. Figura 2.4: Python a 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 entorn python, a més a més d’incloure els paquets python instal·lats en el mateix dispositiu. 2. Modificar l’arxiu de configuració (config.py) amb l’objectiu de poder autenticarse correctament amb Google. 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 compte Google haurà de crear un nou compte, d’aquesta manera podrà seguir utilitzant l’eina. • Necessitat d’introduir unes credencials de Google emplenant 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 dispositiu Android vinculat amb un determinat correu electrònic. Per tal d’aconseguir aquest identificador, existeix una aplicació anomenada Device ID que permet visualitzar-la directament en el dispositiu. – GOOGLE_LOGIN: correspon a un correu electrònic vàlid i prèviament registrat a un compte Google. – 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 amb Google és necessari l’ús de tokens d’autenticació. LANG ANDROID_ID GOOGLE_LOGIN GOOGLE_PASSWORD AUTH_TOKEN. = = = = =. "en_US" # can be en_US , fr_FR , . . . "XXXXXXXXXXXXX" "user@gmail .com" "password" "tokenAuth" # " yyyyyyyyy ". • Aquest mètode d’accés permet definir un separador amb l’objectiu d’aconseguir una sortida de la informació més ordenada. Per mitjà de l’ús 23.

(34) 2. T ECNOLOGIES NECESSÀRIES 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’arxiu helpers.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 de MAETROID [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 .apk a partir de l’identificador de l’aplicació. Aquest .apk es 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. 24.

(35) 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’identificador 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 determinada aplicació i similars. En el cas que tan sols es vulgui obtenir les característiques 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 classificacions a partir d’una determinada categoria. A la figura 2.8 es pot veure un exemple. 25.

(36) 2. T ECNOLOGIES NECESSÀRIES. 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 informació 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 format json. • 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 format json. 26.

(37) 2.6. Dispensador de tokens 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, el token és un dels elements necessaris per a l’autenticació amb Google. Per aquest motiu, va ser imprescindible l’ús d’un projecte secundari, per tal de poder autenticar les peticions Google, i així aconseguir que les respostes d’autenticació de Google no 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 seleccionat, es va poder comprovar que amb la configuració per defecte (tal com s’ha vist a l’apartat 2.5), quan el camp AUTH_TOKEN s’inicialitza a null el 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ó amb Google. 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’obtenir tokens d’autenticació d’accés a Google 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 projecte token dispenser Per tal de resoldre l’inconvenient explicat a l’apartat 2.6.1, el projecte seleccionat és el docker del dispensador de tokens de l’usuari NoMore201 [23]. Aquest es bassa en el projecte de l’usuari yeriomin [24]. Aquest projecte permet generar tokens d’autenticació 27.

(38) 2. T ECNOLOGIES NECESSÀRIES de Google 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 dades MONGODB: per mitjà d’aquest mètode d’accés es permet obtenir tokens segons si un determinat usuari presenta una entrada amb el seu nom creada a la base de dades. És a dir, tan sols podran obtenir tokens 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 als tokens de Google 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 rebre tokens d’autenticació. Per tal d’engegar el dispensador de tokens, s’han de seguir les següents passes: 1. Per tal d’utilitzar el software docker, s’haurà d’instal·lar prèviament. 2. Accedir al directori d’aquest projecte docker-tocken-dispenser per mitjà de la comanda cd del teu terminal. 3. Accedir al subdirectori backend-plaintext. 4. Veure l’estat dels docker del teu sistema per mitjà de la següent comanda: docker info. O si vols veure l’estat dels processos docker executats en el teu sistema: docker ps.. Figura 2.12: docker stopped. 5. Compilar la imatge del docker per mitjà de la següent comanda: sudo docker build −t tokendispenser . 6. Crear un nou container amb el nom de tokendispenser al port 8080. sudo docker run −d −−name tokendispenser −p 8080:8080 tokendispenser. 28.

(39) 2.6. Dispensador de tokens 7. En aquest punt el docker hauria d’estar engegat i per tant el dispensador de tokens en execució.. Figura 2.13: docker running. 8. Així i tot, si es vol comprovar com efectivament el dispensador de tokens crea nous tokens, es pot accedir a la següent direcció: http : / / server −address : port / token / email /youremail@gmail .com Aquest email haurà de ser el mateix que el definit en el moment de la instal·lació a l’arxiu entrypoint.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üent token: ’5QTdOH..1djA.’. En conclusió, aquest projecte ha suposat una solució simple i ràpida respecte a l’inconvenient amb l’autenticació amb Google Play. Convé recordar que aquest servei s’haurà de llançar cada vegada que se’n vulgui fer ús del projecte d’accés a Google 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. 29.

(40)

(41) CAPÍTOL. 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 aplicacions Android a 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 consisteix en desenvolupar un conjunt de scripts que permetin l’extracció de la informació de Google Play de manera automàtica. • Bloc 2 (Tractament de la informació): aquest bloc consisteix en un conjunt de scripts que 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’aplicacions Android.. 31.

(42) 3. D ESENVOLUPAMENT DEL PROJECTE. 3.1 Sistema d’extracció (Crawler) Tal com ens recordava Imam 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 aplicacions Android. 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 de Google Playstore. • Sistema d’extracció (Crawler): realment la paraula Crawler no seria l’ideal per aquest element, ja que no fa les funcions típiques de crawling com és l’accés directe a recursos de pàgines web. En aquest projecte, es tracta d’un conjunt de scripts que realitzen funcions específiques (com extreure identificadors, característiques, permisos, etc.), per tal d’aconseguir extreure tota la informació necessària per al seu posterior processament. Això ho aconseguirà accedint directament (a través del mètode d’accés seleccionat) o de manera indirecta (a través del fitxer addicional). 32.

(43) 3.1. Sistema d’extracció (Crawler) • Espai d’emmagatzemament: és l’espai o lloc on es guardarà tota aquella informació 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 .csv complementari 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 un script amb el següent funcionament: 1. Accedir a la carpeta que conté aquest arxiu. Per dur a terme aquesta acció s’utilitza la comanda cd. 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 fitxer list_apps.csv: 33.