Figura 2.1 Modelul inelului [5] 12 Figura 2.2 Arhitectura sistemului de operare Android [8] 14 Figura 2.3 Accesul la date sensibile prin intermediul… [308741]

CUPRINS

TABELĂ DE FIGURI

Figura 2.1 Modelul inelului [5] 12

Figura 2.2 Arhitectura sistemului de operare Android [8] 14

Figura 2.3 [anonimizat] [7] 17

Figura Figura 2.4 prezintă modelul de securitate iOS care reprezintă o privire de ansamblu asupra elementelor ce țin de securitatea fluxului de lucru dintre componentele iOS enumerate în prealabil. 19

Figura 2.5 Diagrama modelului de securitate iOS [9] 19

Figura 2.6 Structura unui pachet .ipa [27] 26

Figura 3.1 Geografia amenințărilor mobile în funcție de numărul de utilizatori atacați, 2017 [24] 35

Figura 3.2 Execuție reală și execuție nelegitimă [17] 36

Figura 3.3 Raportul Nokia pe 2017 privind distribuția malware pe diverse sisteme de operare 37

Figura 3.4 Informații despre cele trei versiuni de AceDeceiver din App Sotre 39

Figura 3.5 Interfața utilizator pentru utilizatorii din afara Chinei 39

În figura Figura 3.5 este prezentat ecranul principal al aplicației pentru utilizatorii din afara Chinei. Când o [anonimizat]-ul tool.verify.i4.cn/toolCheck/xhtml care reprezintă serverul de comandă și control pentru AceDeceiver. Dacă acest URL returnează 0, pe ecranul victimei va apărea o interfață de tip AppStore creată de atacator. [anonimizat]-ul returnează altceva decât 0, utilizatorului îi este afișat ecranul prezentat în Figura 3.6 [23] 39

Figura 4.1 Procesul de detecție malware utilizând machine learning în modul supravegheat [26] 48

Figura 5.1 Exemplu de rezultat pe care otool îl oferă la verificarea arhitecturii unui binar. 49

Figura 5.2 Exemplu de rezultat pe care îl oferă otool în cazul verificării cu rezultat pozitiv dacă acesta este criptat. 50

Figura 5.3 Verificarea prezenței flagului PIE în binar 50

Figura 5.4 Exemplu de afișare a aplicațiilor folosind Clutch 2.0 51

Figura 5.5 Listare director curent și conținut dispozitiv iOS [28] 53

Figura 5.6 Meniu general PassionFruit [29] 54

Figura 5.7 Meniul MobSF 56

Figura 5.8 Meniu principal cu rezultatele unei scanări cu MobSF 56

Figura 5.9 Reprezentarea schematică a procesului de analiză statică MobSF [30] 57

Figura 5.10 Emulator MobSF pentru analiza dinamică 59

Figura 5.11 Meniu MobSF Dynamic Analyzer 59

Figura 5.12 Meniu principal cu rezultatele unei scanări dinamice cu MobSF 60

Figura 5.13 Opțiunea HTTPS afișează 60

Figura 5.14 Apelurile funcțiilor librăriilor folosite de aplicație 61

Figura 5.15 Execuție MobSF din mediul virtual python 63

Figura 5.16 Analiza statică a aplicației DIVA folosind MobSF 63

Figura 5.17 [anonimizat] 64

Figura 5.18 [anonimizat] 64

Figura 5.19 [anonimizat] 64

Figura 5.20 [anonimizat] 65

Figura 5.21 [anonimizat] 65

Figura 5.22 [anonimizat] 66

Figura 5.23 Analiză dinamică MobSF 66

Figura 5.24 [anonimizat] 67

Figura 5.25 Analiza dinamică MobSF meniu raport 67

Figura 5.26 Analiza dinamică MobSF 68

Figura 5.27 Lista cu instrumentele Santoku_0.5 70

Figura 5.28 Ecran principal Santoku_0.5 71

Figura 5.29 Instalare pachete necesare virtualizării 71

Figura 5.30 Creare dispozitiv virtual AVD Manager 72

Figura 5.31 Instalare AFLogical pe dispozitiv folosind adb 72

Figura 5.32 Aplicație AFLogical. Selectarea datelor de extras și mesajul reuzltat în urma extragerii acestora. 73

Figura 5.33 Date extrase cu AFLogical 74

Figura 5.34 Informații conținute de fișierul SMS.xml extras cu AFLogical 74

Figura 5.35 Conținut AndroidManifest.xml 75

Figura 5.36 Afișare resurse rezultate din apk cu ajutorul apktool 76

Figura 5.37 Raport generat de apkstats.py 76

Figura 5.38 Rezultat instrument dex2jar 77

Figura 5.39 Localizare JD-GUI pe Santoku 77

Figura 5.40 Rezultate JD-Gui 78

Figura 5.41 Meniu Luyten afișând clasa principală 79

Figura 5.42 Pornire dispozitiv și instalare apk cu succes 80

Figura 5.43 Încărcare tcpdump pe emulator 80

Figura 5.44 Pornire captură tcpdump 80

Figura 5.45 Android Tamer – fereastra principală 83

Figura 5.46 AndroidTamer – MobSF 84

Figura 5.47 Analiza AndroidTamer4 – diva-beta.apk 85

Figura 5.48 Lansare în execuție diva-beta.apk pe terminalul fizic 85

Figura 5.49 Obținerea fișierului java folosind Dex2Jar 86

Figura 5.50 AndroidTamer4 – Provocarea 1 86

Figura 5.51Androidtamer4 – Introducere date 87

Figura 5.52AndroidTamer4 – Provocarea 2 87

Figura 5.53 AndroidTamer4 – Vulnerabilitate cauzată de date sensibile hardcodate 87

Figura 5.54 AndroidTamer – codul metodei savedCredentials 87

Figura 5.55 AndroidTamer4 – Provocarea 3 88

Figura 5.56 AndroidTamer4 – vulnerabilitate SharedPreferences 88

Figura 5.57 AndroidTamer4 – Provocare 4 și codul utilizat de metoda ce salvează datele 89

Figura 5.58 AndroidTamer4 -rezultatele găsite în baza de date a aplicației cu datele introduse la provocarea 4 89

Figura 5.59 AndroidTamer4 – metoda a treia de salvare a datelor 90

Figura 5.60 AndroidTamer4 – Provocarea 5 – vulnerabilitate în stocarea datelor sensibile 90

Figura 5.61 AndroidTamer4 – Provocare 6 și codul utilizat de metoda ce salvează datele 91

Figura 5.62 Verificare fișier informații sensibile 91

Figura 5.63 AndroidTamer4 – probleme de validare a datelor de intrare 93

Figura 5.64 AndroidTamer4 – Provocare 8 și codul utilizat de metoda ce validează URL-ul de intrare 93

Figura 5.65 AndroidTamer4 – Probleme în controlul accesului partea întâi 94

Figura 5.66 AndroidTamer4 – Pornire activitate din linie de comandă 95

Figura 5.67 AndroidTamer4 – Probleme în controlul accesului – partea a doua 95

Figura 5.68 AndroidTamer4 – execuție manuală TVEETER API ATIVITY 96

Figura 5.69 Codul sursă pentru APICreds2Activity.java 96

Figura 5.70 AndroidTamer4 – probleme în controlul accesului – partea a treia 97

Figura 5.71 AndroidTamer4 – provocarea 11, aflarea locației furnizorului de conținut 97

Figura 5.72 Androidtamer4 – interogarea de conținut folosind adb shell 98

Figura 5.73 AndroidTamer4 – probleme de hardcodare partea a doua 98

Figura 5.74 Clasa DivaJni 98

Figura 5.75 AndroidTamer4 – acces primit provocare 12 99

Figura 5.76 AndroidTamer4 – probleme în controlul accesului – partea a doua. 99

Figura 5.77 AndroidTamer4 – rezultate adb logcat pentru provocarea 13 99

Introducere

Viața umană actuală a devenit influențată din aproape toate punctele de vedere de progresul tehnologic care a fost inițial adoptat, iar acum este deja integrat în activitățile noastre zilnice. Un domeniu revoluționat prin tehnologizare îl reprezintă comunicațiile ce au reușit să apropie virtual persoane aflate la distante foarte mari. Extinderea internetului și vitezei acestuia în conjuncție cu dispozitivele moderne inteligente de dimensiuni mici, telefoane inteligente și tablete, au ajuns ca la acest moment să pună lumea la dispoziție prin simpla atingere cu un deget.

Dispozitivele mobile sunt foarte fiabile și evoluate, atât din punct de vedere hardware, cât și din punct de vedere software, devenind un microcomputer portabil cu putere de procesare importantă, spațiu de stocare ridicat și suportă aplicații diverse. Acest lucru ne creionează că nu mai trebuie să trecem cu vederea elementele de securitate și că informațiile și aplicațiile ce ajung la un momentdat pe dispozitive trebuie verificate și stabilit, în prealabil, dacă pot sau nu aduce un rău ascuns odată cu ele. În 2014 numărul de dispozitive mobile active din lume a depășit numărul de locuitori ai planetei [1]. Prin această forță de procesare mobilă, utilizatorii reușesc să rezolve munci de birou, tranzacții bancare, utilizeze aplicații media pentru înregistrări audio sau video, jocuri și multe altele. Această multitudine de servicii și gama largă de opțiuni multimedia care accesează, stochează, procesează, trimit și primesc date personale ale utilizatorului care, daca ar fi compromise, ar putea să afecteze financiar, social și psihologic utilizatorul.

Dispozitivele mobile sunt definite de prezenta prestabilită a unui sistem de operare. Sistemele de operare sunt de tipul proprietate a vânzătorului, sau open-source. În 2017 piața de telefoane inteligente a fost dominată de sistemele de operare Android cu 85.9% dintre dispozitivele noi achiziționate și iOS cu 14% [2].

La finalul anului 2017, numărul de aplicații descărcate din Google Play a depășit 19 miliarde, depășind App Store cu 145% , iar doar în ultimele 3 luni ale lui 2017 din Google Play s-au realizat 27 de milioane de noi descărcări [3].

Aceste date foarte relevante arată disponibilitatea pe piață a 99.9% dintre dispozitive cu cele două sisteme de operare. Totodată, statisticile prezintă și un număr impresionant de descărcări ale aplicațiilor pentru sistemele de operare respective ceea ce conduce la subiectul lucrării în care este cuprinsă analiza asupra acestora, prin comparație, din punct de vedere arhitectural. Lucrarea pornește de la descrierea nivelului de securitate dat de arhitectura sistemelor de operare respective și aprofundează analiza aplicațiilor conținute pe acestea utilizând componente open-source pentru a determina nivelul de securitate oferit de ele.

Scopul lucrării

Obiectivele acestei lucrări sunt direcționate către sistemele de operare Android și iOS, cu precădere asupra celui dintâi menționat. Scopul lucrării este de cercetare a acestor sisteme de operare pentru dispozitivele mobile, înțelegerea fluxului de lucru al unei aplicații aparținând sistemelor respective și, prin examinarea practică a mai multor instrumente de analiză a aplicațiilor, realizarea unei platforme integrate folosind aceste instrumente. Prin această platformă se dorește centralizarea unui set cât mai complex și folositor de unelte pentru a realiza analiza aplicațiilor suspecte a fi malițioase.

Rezultatul lucrării va reprezenta, practic, detalierea părților sensibile ale oricărei aplicații date și direcțiile care trebuie urmărite pentru a detecta dacă aceasta este sau nu malițioasă. Prin direcțiile urmărite se explică ce trebuie analizat, cum trebuie analizat și cum se detectează anomaliile prin expunerea unei succesiuni de utilizare a diverselor instrumente.

Aceste lucruri sunt relevate prin exemplificarea unor studii de caz folosind uneltele open-source documentate, precizând, detaliat, procesul de analiză și concluziile la care se ajunge.

Securitatea arhitecturilor iOS și Android

Securitatea sistemelor de operare

Fiecare calculator modern, de la servere de rețea, stații de lucru tip desktop, până la laptop-uri și dispozitive mici mobile, conține o bucată de software, denumit kernel, ce se execută la nivelul imediat superior hardware care are rolul de a aloca resurse sistemului de operare (de exemplu: CPU, memorie, accesul la drivere, porturi de comunicare, etc.) care supervizează execuția tuturor aplicațiilor de pe sistem.

Prin obținerea controlului asupra sistemelor de procesare, virușii, troienii, bug-urile de soft și software-ul malițios împreună cu oameni care doresc să facă rau, pot crea prejudicii majore distrugând infrastructuri, folosind modalitatea de procesare bancară online pentru a fura bani, sau roboți pentru a ataca oameni. Societatea actuală este din ce în ce maid dependentă de calculatoare pentru a realiza sarcinile de zi cu zi. Prin urmare, un sistem de operare sigur este foarte important.

Datorită rolului pe care îl are un sistem de operare pe orice, securitatea acestuia va avea un impact fundamental asupra securității de ansamblu a sistemului, incluzând securitatea aplicațiilor prezente pe sistemul de operare respectiv. Orice element vulnerabil prezent în sistemul de operare va reprezenta, cu siguranță, un pericol expus asupra fiecărei aplicații ce rulează pe sistemul respectiv. Lipsa unui control adecvat și o izolare a execuției aplicațiilor într-un sistem de operare ar putea duce la un atac ce s-ar putea extinde de la o aplicație la alta.

Prin creșterea continuă a comerțului electronic bazat pe internet, securitatea aplicațiilor reprezintă un scop al milioanelor de vânzători și cumpărători ce își pun la dispoziție publicului afacerea folosind acest serviciu electronic. Eforturile de a obține securitatea completă a acestor sisteme sunt bazate în mod eronat pe faptul că acest lucru s-ar putea obține chiar și cu mecanismele de securitate curente prezente pe sistemele de operare moderne. Realitatea este că aplicațiile securizate au nevoie de sisteme de operare securizate care ar trebui să prezinte elemente de securitate aplicate și prin verificări controlate la nivel de kernel. [4]

Sistemul de operare împreună cu celelalte componente software trebuie să fie modulare. Fiecare modul poate executa o anumită funcție și poate accepta parametrii. Spre exemplu, un browser web folosește redare HTML pentru afișarea unei pagini. La rândul ei, redare HTML folosește un interpretator jpg pentru a afișa imaginile jpg. Un program de e-mail ar putea utiliza același program de redare jpg. Acest set de funcții ajută dezvoltatorii, făcând scrierea programelor mai ușoară prin posibilitatea de a nu scrie aceeași funcție, deja existentă, de mai multe ori. Modularitatea este esențială pentru staiblitate și securitatea internă a programelor complexe prin simplu fapt că prin nefuncționarea unui modul ar trebui să afecteze doar acea funcție a programului ce accesează modulul respectiv, iar celelalte componente ale aplicației rămânând funcționale sau să facă programul nesigur în mod indirect. Atunci când codul unei funcții este încărcat în memorie, pot fi realizate simultan mai multe execuții ale acesteia. Funcțiile rămân în memorie până ce memoria (RAM) devine foarte încărcată, iar în acel moment funcțiile sunt eliberate din memorie sau mutat în zona de swap.
Fiecare proces conține un set de drepturi și priorități. Aceste priorități determină ce tipuri de resurse poate accesa precum ce dispozitive, fișiere și cu ce nivel de permisiuni poate accesa procesul respectiv. Spre exemplu, un process ar putea avea doar dreptul de a modifica o anumită zonă a ecranului de afișare, sau ar putea fi restrâns față de accesul unui anumit fișier, având drepturi doar de citire. În mod ideal, fiecare proces trebuie să primească doar drepturile ce îi pot îndeplini funcțiile pe care procesul respectiv trebuie să le îndeplinească. Prioritățile reprezintă specificații pentru resursele limitate precum cantitatea de memorie, timpul de procesare, lățimea de bandă sau spațiul pe disc. Prioritățile sunt determinate de importanța fiecărui proces. Multitasking-ul asigură faptul că fiecare proces primește cantitatea de resurse necesară pentru a-și îndeplini sarcina. Cu cât un proces primește mai multe resurse, prioritatea acestuia scade, iar cu cât acesta este limitat în timp la resurse, prioritatea lui crește, astfel un proces defectuos nu ar putea să ocupe excesiv resurse importante.

Concepte de proiectare a unui sistem securizat

Stratificarea

Prin stratificare (layering) se separă funcționalitățile harware și software în nivele modulare. Complexitatea unei cereri de a citi un sector de pe un disc este concentrată într-un singur nivel (nivelul hardware). Alt nivel (spre exemplu cel aplicație) nu este afectat în mod direct de o modificare a celuilalt.

O listă generică de nivele ale unei astfel de arhitecturi de securitate este următoarea:

Hardware

Kernel și drivere

Sistem de operare

Aplicații

Abstractizarea

Abstractizarea ascunde detalii inutile față de utilizator. Complexitatea reprezintă un inamic al securității pentru că cu cât un proces este mai complex, cu atât acesta devine mai nesigur. Calculatoarele sunt un set de procese complexe, iar abstractizarea oferă o modalitate de a administra această complexitate.

Domenii de securitate

Un domeniu de securitate reprezintă o listă de obiecte pe care utilizatorul le poate accesa. Practic, domeniile sunt grupuri de utilizatori și obiecte ce dețin același nivel de securitate. Modul kernel reprezintă nivelul nivelul cu acces la cel mai jos nivel al memoriei, CPU-ului, disk-ului, etc. Acesta este cel mai de încredere și puternic element al unui sistem. Modul utilizator reprezintă nivelul la care conturile de utilizator și procesele acestora se desfășoară. Cele două domenii sunt separate și o eroare de securitate ce ar putea apărea în modul utilizator nu ar trebui să afecteze kernelul.

Modelul inelului (The Ring Model)

Modelul inelului reprezintă o formă de stratificare hardware ce separă și protejează domeniile (precum modul kernel și cel utilizator) între ele.

Arhitectura de tip inel este următoarea:

Inelul 0: Kernel

Inelul 1: Componente OS care nu aparțin de Inelul 0

Inelul 2: Drivere

Inel 3: Aplicații utilizator

Figura . Modelul inelului [5]

Procesele comunică în interiorul inelului prin apeluri de sistem, care permit proceselor să comunice cu kernelul și, astfel, oferă un canal de comunicare între inele. De exemplu: un utilizator folosește un procesor word în inelul 3 și salvează fișierul respectiv, în acel moment se realizează un apel sistem către inelul 0, care cere kernelului să îi permită salvarea fișierului.Kernelul realizează procesul cerut și raportează că fișierul a fost salvat. Apelurile sistem sunt încete (comparând realizarea proceselor folosind un singur inel), însă acest model oferă securitate și abstractizare. [6]

Securitatea Android

Descriere

Android este proiectat să fie sursă-deschisă (open-source). Aplicațiile Android utilizează hardware și software avansat, precum și date locale și deservite, prin intermediul platformei pentru a oferi inovație și valoare clienților. Pentru realizarea acestor lucruri, platforma oferă un mediu al aplicațiilor care protejează confidențialitatea, integritatea și disponibilitatea utilizatorilor, datelor, aplicațiilor, dispozitivului și rețelei.

Pentru a securiza o platformă deschisă este nevoie de o arhitectură bazată pe securitate și implementarea de programe de securitate serioase. Android a fost proiectat folosind modelul de stratificare care este destul de flexibil pentru a putea suporta o platformă de tip sursă-deschisă și, în același timp, de a-i putea proteja pe utilizatori.

Android este proiectat pentru dezvoltatori. Controalele de securitate au rolul de a reduce din greutatea pusă pe umerii dezvoltatorilor. Echipa de securitate Android verifică potențialele vulnerabilități ale aplicațiilor și sugerează modalități de a le repara. Pentru dispozitivele ce au instalat Google Play, Play Services oferă actualizări de securitate pentru biblioteci importante, precum OpenSSL, care este utilizat pentru a securiza comunicațiile. Android a creat și un instrument de testare SSL, denumit nogotofail, care ajută dezvoltatorii să găsească eventuale riscuri de securitate pe platforma pe care creează.

Android este proiectat pentru utilizatori. Acestora le este arătat în mod direct ce permisiuni cere fiecare aplicație și au controlul asupra fiecărei permisiuni.

Arhitectura sistemului Android

Arhitectura sistemului de operare Android are următoarea structura din Figura 2..

Figura . Arhitectura sistemului de operare Android [8]

Application Framework este utilizat de dezvoltatorii de aplicații. Dezvoltatorii hardware trebuie să fie atenți la API-urile dezvoltatorilor software pentru că multe dintre ele accesează interfețele HAL și pot oferi informații importante despre implementarea driverelor.
Mecanismul de comunicare între procese Binder permite frameworkului aplicație să apeleze funcții și servicii ale sistemului de operare Android. La nivelul frameworkului aplicație, comunicația cu celelalte elemente este ascunsă față de dezvoltator.

Serviciile de sistem sunt modulare și sunt accesibile nivelului frameworkului de aplicație prin intermediul API-urilor care realizează apeluri sistem pentru a accesa nivelul hardware necesar. Android permite două grupuri de servicii: servicii sistem (precum Window manager sau Notification Manager) și media (servicii ce permit redarea și înregistrarea media).

Nivelul de abstractizare hardware (HAL) definește o interfață standard pentru dezvoltatorii de hardware pentru ca sistemul Android să fie agnostic în nivelul de jos al implementării driverelor. Folosind HAL permite implementarea de funcționalități fără a afecta sau modifica nivelele superioare din sistem. Implementările HAL sunt împachetate în module și încărcate de către Android atunci când sunt necesare.

Kernel

Nucleul sistemului de operare Android se bazează pe kernelul Linux. Principalele elemente de securitate pe care le oferă acesta sistemului Android sunt:

un model de permisiuni bazat pe dorința utilizatorului

izolarea proceselor

mecanism extensibil de securizare IPC

abilitatea de a renunța la părți care sunt potențial nesigure ale kernelului

Un aspect important al securității kernelului Linux este de a izola resursele între ele.

Sandboxing-ul aplicațiilor

sistemul de operare Android alocă un ID unic pentru fiecare aplicație și o rulează într-un proces separat. Acest aspect este diferit față de alte sisteme de operare (incluzând Linux-ul configurat tradițional) în care mai multe aplicații rulează cu aceleași permisiuni utilizator.

Acest aspect asigură existența la nivelul kernelului a unui sandbox al aplicațiilor.

În mod implicit, aplicațiile nu pot interacționa între ele și au acces limitat la sistemul de operare.

Pentru că izolarea de tip sandbox se realizează în kernel, securitatea modelului se extinde la codul nativ și aplicațiile sistemului de operare. Astfel, întregul software ce se află deasupra kernelului, precum bibliotecile de sistem, aplicațiile native rulează în sandbox.

Permisiunile sistemului de fișiere. Într-un mediu de tip UNIX, acestea asigură faptul că un utilizator nu poate citi sau modifica fișierele altui utilizator. În Android acest lucru se aplică și la aplicații care rulează ca fiind pornite de un utilizator propriu, iar acestea pot accesa fișierele altor aplicații dacă dezvoltatorul specifică explicit acest lucru.

SELinux. Android utilizează Security-Enhanced Linux pentru a aplica politicile de control acces și a stabili controlul obligatoriu al accesului asupra proceselor.

Verificarea la pornire. Începând cu Android 6.0 această verificare a fost implementată și garantează integritatea softwareului pe dispozitiv pornind de la nivelul de încredere al hardwareului până la partițiile de sistem. În timpul pornirii, fiecare nivel verifică integritatea și autenticitatea următorului nivel prin funcții criptografice înainte de a-l executa. De la Android 7.0, s-a introdus verificarea strictă a pornirii și dispozitivele compromise nu pot porni.

Criptografie. Android conține un set de API-uri criptografice pentru utilizarea în aplicații.

Rootarea dispozitivelor. Android nu îngrădește utilizatorii sau aplicațiile cu permisiuni de root în a modifica sistemul de operare, kernelul sau alte aplicații. Acest lucru este important pentru dezvoltatori pentru a putea avea accesul de a analiza diverse versiuni ale sistemului de operare, pentr a realiza operațiunea de debugging asupra aplicațiilor și componentelor de sistem și a avea accesul la caracteristici care nu sunt conținute în aplicații de API-urile Android.

Criptarea sistemului de fișiere. Android 3.0 permite criptarea întregului sistem de fișiere utilizator. Android 5.0 permite criptarea completă a discului bazându-se pe credențialele utilizatorului. Android 7.0 permite criptarea bazată pe fișier, ceea ce înseamnă că se pot cripta fișiere cu diverse chei și decriptate independent.

Securitatea aplicațiilor

Structura unei Aplicații

Componentele principale ale unei aplicații Android sunt:

Activități. O activitate reprezintă, în principal, codul ce este folosit pentru realizarea unei sarcini căreia utilizatorului îi este afișată la un momentdat. În mod normal, o activitate afișează pe ecran o interfață pentru utilizator, dar acest lucru nu este obligatoriu. Există activități care nu afișează nimic pe ecran.

Servicii. Un serviciu reprezintă o bucată de cod care rulează în fundal. Acesta poate funcționa într-un proces propriu sau într-un alt proces al aplicației.

Receptoarele de transmisie (broadcast receiver). Suntun receptor de transmisie reprezintă un obiect care este instanțiat atunci când un mecanism de tip comunicație inter procese (denumit Intent) este emis de sistemul de operare sau de altă aplicație.

Pe lângă mecanismele tip UNIX pentru comunicația inter procese (socketuri, semnale), Android oferă și Binder (mecanism de apel al unei proceduri folosit la apelurile în interiorul sau în afara procesului) , Servicii, Intents (obiect tip mesaj ce reprezintă o intenție de a face ceva) și ContentProviders (acces la un depozit al datelor expuse de alte aplicații de pe dispozitiv).

Accesul la informațiile utilizator se realizează printr-un set de API-uri protejate oferite de Android. Aplicațiile care aleg să își distribuie informațiile pot folosi verificările de sistem Android pentru a proteja datele de alte aplicații (Figura 2.).

Figura . Accesul la date sensibile prin intermediul API-urilor protejate [7]

Android include o serie de Autorități de Certificare instalate în sistem, care sunt de încredere pentru întreg sistemul. Pentru a adăuga o nouă Autoritate de Certificare publică în Android, aceasta trebuie să treacă printr-un proces de includere al Mozilla CA și să facă o cerere directă către Android.

Semnarea aplicațiilor. Prin semnarea codului, dezvoltatorii pot identifica autorul aplicației. Orice aplicație care este încărcată în Google Play trebuie să fie semnată de dezvoltator. În Google Play semnarea aplicațiilor întărește încrederea dintre Google și dezvoltator.

Atunci când o aplicație (fișier APK) e instalată pe un dispozitiv Android, Package Manger verifică dacă aceasta a fost semnată în mod corespunzător cu certificatul prezent pe fișierul APK.

Structura unui pachet Android

Un pachet Android reprezintă un fișier .apk ce care conține o serie de fișiere și directoare. Conținutul standard al unui pachet este format din:

AndroidManifest.xml. Acesta reprezintă un fișier de control care spune sistemului ce să facă cu toate componentele aplicației (activități, servicii, receptoare de transmisie și furnizorii de conținut). Tot aici sunt specificate și permisiunile de care are nevoie aplicația.

classes.dex. Fișier care reprezintă clasele compilate în formatul dex care este necesar pentru interpretarea în Dalvik Virtual Machine și de către Android Runtime.

resources.arsc. Fișier ce conține resurse precompilate precum binare XML.

META-INF. Director care conține la rândul său fișiere importante.

MANIFEST.MF. Fișier specific aplicațiilor Java.

CERT.RSA. Certificatul aplicației.

CERT.SF. Lista de resurse și hash-uri SHA-1 ce corespund liniilor din fișierul MANIFEST.MF

lib. Director ce conține cod compilat specific pentru diverse procesoare.

res. Director ce conține resursele necompilate în fișierul resources.arsc.

assets. Director ce conține obiecte nece

Securitatea iOS

Descriere

Apple a creat platforma iOS în jurul unui nucleu de securitate. Acesta cuprinde caracteristici inovative care întăresc securitatea mobilă și protejează sistemul în mod implicit. Fiecare dispozitiv iOS combină soluții software, hardware și servicii întru a lucra împreună într-un mediu securizat la capacitate maximă și într-un mod transparent față de utilizator.

Figura Figura 2.4 prezintă modelul de securitate iOS care reprezintă o privire de ansamblu asupra elementelor ce țin de securitatea fluxului de lucru dintre componentele iOS enumerate în prealabil.

Arhtiectura sistemului iOS

Securitatea sistemului este proiectată pentru a susșine prin software și hardware securitatea tuturor componentelor oricărui dispozitiv iOS. Prin integrarea hardware, software și a serviciilor în dispozitivele iOS se asigură că fiecare componentă este de încredere și este validat sistemul ca un întreg [10].

Componente:

Secure boot chain (lanț de securitate la pornire)

Fiecare pas de pornire a sistemului conține componente care sunt semnate cu funcții criptografice de către Apple pentru a asigura integritatea și a permite continuarea în siguranță a procesului doar după ce pașii din lanț sunt validați.

Când un dispozitiv iOS este pornit, procesorul de aplicații execută imediat cod din memoria read-only (Boot ROM). Acest cod inflexibil, cunoscut drept rădăcina de încredere hardware este generat la fabricarea cipului și e implicit de încredere. Cheia publică Apple Root CA este conținută în codul Boot ROM și verifică dacă bootloader-ul iBoot este semnat de Apple înainte de a fi încărcat. După finalizarea rulării iBoot, este verificat și pornit kernelul iOS. Pentru dispozitivele cu Security Enclave, coprocesorul acesteia utilizează o componentă de securitate în pornire care se asigură că software-ul separat este semnat de Apple.

Autorizarea Software-ului Sistemului

Procesul descris în primul pas ne asigură că doar cod semnat de Apple poate fi instalat pe un dispozitiv. Într-un scenariu în care un dispozitiv este atacat, iar atacatorul dorește să instaleze un sistem de oeprare mai vechi asupra căruia ar putea să exploateze breșele de securitate generate de neactualizarea software-ului, Apple se protejează folosind un proces denumit System Software Authorization (Autorizarea Software-ului Sistemului). La momentul actualizării iOS, serverul Apple de autorizare a instalării trimite o listă de măsurători pentru fiecare parte a conținutului ce urmează a fi instalat(de exemplu: iBoot, kernel sau imaginea sistemului de operare), un nonce și identificatorul unic al dispozitivului (ECID). Serverul verifică lista de măsurători pentru a determina dacă instalarea este permisă, iar dacă aceasta este validă, se adaugă ECID-ul la măsurători și se semnează rezultatul. Serverul trimite datele semnate către dispozitiv care începe procesul de instalare a actualizărilor.

Secure Enclave

Secure Enclave este un coprocesor care are rolul de a cripta memoria și conține un generator generateor de numere aleatoare la nivel hardware. Acest coprocesor cuprinde toate operațiile critpgrafice pentru protecția datelor, administrarea cheilor și menține integritatea acestora și dacă există compromiteri la nivelul de kernel.

Comunicația dintre coprocesorul Secure Enclave și procesorul aplicație este izolată la nivel de întrerupere de tip mailbox și este realizată prin buffere ce partajează memoria.

Secure Enclave utilizează o versiune de L4 microkernel personalizată de Apple. Aceasta este semnată de Apple și verificată în lanțul securizat de pornire a dispozitivului iOS. În momentul pornirii dispozitivului este creată o cheie efemeră ce are derivă din UID-ul dispozitivului. Aceasta este folosită pentru a cripta porțiunea din Secure Enclave din spațiul de memorie al dispozitivului.

Touch ID

Touch ID reprezintă un identificator pe bază de atingere. Acesta este un sistem de autentificare la dispozitiv printr-un senzor de atingere ce face accesul sigur, rapid și ușor. Această tehnologie citește amprenta utilizatorului și învață din caracteristicile ei în timp pentru o acuratețe mai bună.

Face ID

Face ID reprezintă un identificator ce scanează fața utilizatorului. Acesta oferă o autentificare securizată prin sistemul TrueDepth Camera ce folosește tehnologii avnasate pentru analiza avansată a geometriei feței. Sistemul analizează direcția în care utilizatorul privește, iar apoi, prin intermediul rețelelor neuronale, determină potrivirea sau nu a feței și existența atacurilor de tip spoofing.

Pentru utilizarea Touch ID sau Face ID este necesară setarea unei parole necesară pentru a debloca dispozitivul. Atunci când Touch ID sau Face ID detectează o potrivire cu succes, deispozitivul se deblochează fără a mai fi necesară introducerea unei parole. Cele două metode nu înlocuiesc existența parolei.

Parola este necesară în următoarele situații:

la pornirea dispozitivului

dispozitivul nu a fost deblocat de mai mult de 48 de ore

parola nu a fost utilizată pentru deblocare în ultimele 156 de ore

dispozitivul a primit comanda de blocare de la distanță

după 5 încercări de potrivire nereușite

după inițierea comenzilor de oprire sau a unui mesaj de urgență

Criptarea și protecția datelor

Lanțul de securitate la pornire, semnarea codului și securitatea la pornirea proceselor asigură faptul că doar cod de încredere pentru Apple poate rula pe dispozitiv. iOS conține criptări adiționale și proprietăți specifice protecției datelor utilizatorului chiar și în cazuri în care diverse părți ale infrastructurii de securitate au fost compromise.

Securitatea Hardware

Fiecare dispozitiv iOS conține un motor de criptate AES-256 construit în DMA ce se află între memoria flash și memoria principală a sistemului ce mărește eficiența în criptarea fișierelor.

Identificatorul utilizator (UID) și identificatorul grup (GID) ale dispozitivului sunt salvate în procesorul aplicație și Secure Enclave la momentul fabricării. Niciun software nu poate să le citească în mod direct, ci doar să vadă rezultatul operațiilor de criptare sau decriptare ce se realizează prin intermediul cheilor UID sau GID.

Pe lângă UID (User ID) și GID (Group ID), toate celelalte chei criptografice sunt create de generatorul de numere aleatoare (RNG) folosind algoritmul bazat pe CTR_DRBG. Entropia sistemului este generată de variațiile de timp ale pornirii acestuia și, adițional, de timpii de întrerupere după ce dispozitivul a pornit. Cheile generate în interiorul Secure Enclave folosesc un sistem propriu hardware de generare a numerelor aleatoare ce se bazează pe oscilațiile procesării post CTR_DBRG.

Pentru a realiza ștergerea cheilor în mod securizat, dispozitivele iOS includ o caracteristică dedicată ștergerii datelor denumită Effaceable Storage. Această tehnologie acecsează și șterge în mod direct blocuri de memorie la nivelul cel mai de jos.

Protecția datelor

Pe lângă criptarea hardware atașată dispozitivelor iOS, Apple folosește și tehnlogoia Data Protection pentru a adăuga încă un nivel de protecție a memoriei flash de pe dispozitive. Data Protection asigură un nivel ridicat de criptare pentru datele utilizator și permite dispozitivului să răspundă evenimentelor comune precum apelurile telefonice. Aplicațiilor native pentru mesaje, mail, calendar, fotografii etc. li se aplică în mod automat această protecție.

Protecția datelor este implementată prin construierea și administrarea unei ierarhii a cheilor și se bazează pe tehnologiile de criptare hardware ale fiecărui dispozitiv iOS. Protecția datelor e controlată la nivel de fișier prin atribuirea acestora unei clase, iar accesarea lor este determinată doar dacă cheia respectivei clase a fost deblocată.

Parole

Setând o parolă unui dispozitiv, utilizatorul activează automat sistemul de protecție a datelor. Pentru deblocarea dispozitivelor, o parolă oferă entropie pentru diverse chei de criptare ceea ce înseamnă că pentru a accesa anumite date ce referă la clase de protecție specifice, utilizatorul trebuie să introducă parola.

Pentru a descuraja atacurile de tip brute-force, Apple aplică o serie de întârzieri de timp pentru încercările succesive eșuate de a introduce parola. Dacă opțiunea Erase Data este activă, atunci dispozitivul își va șterge automat toate datele din memorie după 10 încercări consecutive eșuate de a introduce parola.

Lanțul de chei folosit în protecția datelor

Lanțul de chei (keychain) al iOS este implementat printr-o bază de date SQLite salvată într-un fișier sistem. Există doar o bază de date, iar daemon-ul securityd asigură ce elemente ale lanțului de chei este necesar fiecărui proces. Pentru a nu limita accesul la un singur process, grupurile de acces permit lanțului de chei să partajeze elementele între aplicații.

Securitatea aplicațiilor

iOS oferă nivele de protecție pentru a asigura faptul că aplicațiile sunt semnate, verificate și că sunt rulate într-un mediu de tip sandbox pentru protejarea datelor utilizatorului [11].

Coul unei aplicații native este salvat sub forma unui fișier binar executabil, care este apoi criptat. Decriptarea acestuia este realizată doar în momentul în care fișierul executabil este încărcat de către procesor în zona de memorie alocată aleator (random access memory) și întregul proces de decriptare are loc la nivelul hardware. Acesta este și unul din motivele pentru care analiza aplicațiilor iOS este foarte dificilă din cauza necesității decriptării în modul offline. Singura modalitate de a decripta datele binarelor criptate este folosind un dispozitiv cu jailbreak și o serie de instrumente care interceptează informații despre binar de la momentul lansării în execuție până la rularea efectivă.

Structura unei aplicații

Fișierele .ipa sunt arhive sau pachete care sunt de obicei criptate folosind sistemul Apple FairPlay DRM. Pachetul unei aplicații stochează toate obiectele necesare acesteia.

Structura generică a unei aplicații Apple:

fișierul Info.plist. Fișierul cu lista informațiilor despre proprietăți este un fișier strcturat care conține informații de configurare pentru aplicație. Sistemul folosește acest fișier pentru a identifica informații relevante despre aplicație și despre fișierele necesare acesteia.

Executabilul. Fiecare aplicație trebuie să conțină un fișier executabil. Fișierul conține punctul de început al aplicației și codul care de legătură static al acesteia.

Resurse. Resursele sunt fișiere de date care se află în vecinătatea fișierului executabil al aplicației. Resursele constau în imagini, iconițe, sunete, fișiere mib, fișiere cu string-uri, fișiere de configurare. Fișierele de resurse pot fi configurate în funcție de limbă sau regiune sau nespecificat.

Alte fișiere suportate. Chiar dacă pot fi incluse resurse de date personalizate într-un pachet de aplicație iOS, nu pot fi incluse framework-uri sau plugin-uri personalizate.

Structura unui pachet iOS

MyApp.app

MyApp

MyAppIcon.png

MySearchIcon.png

Info.plist

Default.png

MainWindow.nib

Settings.bundle

MySettingsIcon.png

iTunesArtwork

en.lproj

MyImage.png

fr.lproj

MyImage.png

Aceste componente reprezintă fișiere cu următoarele roluri:

MyApp este fișierul executabil ce conține codul aplicației. Numele acestui fișier este același cu numele aplicației, fără extensia .app

Iconițele aplicației sunt fișierele MyAppIcon.png, MySearchIcon.png, și MySettingsIcon.png

Info.plist conține detalii de configurare ale aplicației, precum ID-ul pachetului, versiunea și numele.

Default.png este imaginea de execuție

MainWindow.nib este fișierul nib principal ce conține obiectele interfeței ce trebuie încărcate la momentul lansării în execuție.

Settings.bundle reprezintă un set special de preferințe care pot fi adăugate folosind setările aplicației.

Fișierele de resurse personalizate fără localizare se află în directorul principal, iar cele localizate sunt conținute în sub-directoarele denumite în funcție de limbă.

Un pachet .ipa conține:

/Payload/ – toate datele aplicației

/Payload/Application.app – componentele aplicației descrise mai sus

/iTunesArtwork – imaginea PNG cu iconița aplicașiei ce apare în magazinul App Store

/iTunesMetadata.plist – conține diverse informații, de la numele dezvoltatorului, ID-ul acestuia, ID-ul pachetului, informații despre drepturile de autor, gen, numele aplicației, data publicării, data cumpărării. etc.

Figura . Structura unui pachet .ipa [27]

Conținutul fișierului Info.plist:

NSMainNibFile este un string ce identifiă numele principalului fișier nib al aplicației.

UIStatusBarStyle – un strnig care identifică stilul barei de descriere la lansarea aplicașiei

UIStatusBarHidden – valoare booleană care determină dacă bara de descriere să fie sau nu afișată la lansarea aplicației

UIINterfaceOrientation – un string care identifică orientarea interfaței utilizator

UIPrerenderedIcon – valoare booleană care indică dacă icoana aplicației conține efecte

UIRequiresPersistentWiFi – valoare booleană care informează sistemul dacă aplicașia folosește rețeaua Wi-Fi pentru comunicare

UILaunchImageFile – un string care conține numele fișierului utilizat de aplicație pentru identificarea imaginii de lansare. Dacă nu este specificată, denumirea este Default.

Un element important ce aparține aplicațiilor Apple este că atunci când un utilizator descarcă o aplicație, aceasta conține header-ul criptat cu cheia publică autilizatorului. Așadar, doar cheia privată ce o deține acesta poate să decripteze header-ul prezent în aplicație. În acest sens, dacă o aplicație este copiată de un alt utilizator și instalată pe un alt dispozitiv la lansarea în execuție a acesteia va rezulta o eroare de execuție pentru că nu va putea fi decriptat header-ul. Totuși, pașii menționați sunt greu de atins pentru că verificările Apple nu permit instalarea unei astfel de aplicații ce ar putea proveni dintr-o altă sursă decât App Store, precum copierea de la un alt utilizator.

Semnarea codului aplicațiilor

Odată ce kernelul iOS pornește, acesta controlează ce procese utilizator și aplicații pot să ruleze. Pentru a asigura că toate aplicațiile provin dintr-o sursă sigură și validată, iOS necesită ca orice cod executabil să fie semnat în prealabil folosind certificate emise de Apple. Obligativitatea semnării codului extinde conceptul de lanț de încredere al aplicațiilor iOS și previne încărcarea codului nesemnat de către aplicații de tip third-party.

Pentru a dezvolta și instala aplicații pe dispozitivele iOS, dezvoltatorii trebuie să se înregistreze la apple și să intre în programul Apple Developer program care verifică identitatea acestuia, ca individ sau firmă, înainte de a-i emite un certificat. Acest certificat permite dezvoltatorilor să semneze aplicații și să le trimită către App Store pentru a le distribui. Acestea sunt apoi verificate de către Apple pentru a se asigura că nu sunt malițioase și nu conțin bug-uri sau alte probleme. Pentru a proteja sistemul și celelalte aplicații împotriva încărcării de cod tip third-party în spațiul lor de adresă, sistemul execută o validare a semnării codului pentru toate bibliotecile incluse în aplicație la momentul rulării.

Apple a dezvoltat un program pentru a permite anumitor întreprinderi să-și dezvolte aplicații pe care să le utilizeze doar în interiorul acestora. Pentru aceste cazuri, Apple oferă organizațiilor posibilitatea de a se înrola în programul Apple edeveloper Enterprise Program (ADEP). Prin acceptul acestor instituții în program, acestea pot să se înregistreze pentru a obține un profil de aprovizionare (Provisioning Profile) ce este necesar fiecărui membru al organizației pentru a instala respectivele aplicații pe dispozitivul propriu.

Spre deosebire de celelalte platforme mobile, iOS nu permite utilizatorilor să instaleze aplicații posibil malițioase nesemnate de pe website-uri sau să ruleze cod nevalidat.

Securitatea la momentul execuției procesului

Odată ce o aplicație este verificată și acceptată ca fiind o sursă validă, iOS aplică măsuri de securitate ce au rolul de a preveni aplicația în a compromite alte aplicații.

Toate aplicațiile funcționează într-un mediu de tip sandbox pentru a restricționa accesul acestora la fișierele altor aplicații ceea ce oprește aplicațiile în a lua sau modifica informațiile la care nu au acces.

Fișierele de sistem și resursele sunt și acestea protejate față de aplicațiile utilizator. Întreaga partiție a sistemului de operare este montată doar cu privilegiul de citire. Acesul aplicațiilor third-party la informațiile utilizator și la componente precum iCloud este controlat folosind drepturi declarate. Aceste drepturi sunt reprezentate în formatul de perechi cheie-valoare care sunt semnate într-o aplicație și permite autentificarea peste restricțiile de la execuție, la fel ca un identificator de utilizator într-un mediu UNIX. Din moment ce aceste drepturi sunt semnate digital, ele nu pot fi modificate. Acestea sunt folosite în principal de aplicațiile sistem și procesele demon pentru a realiza anumite operații care, în mod normal, ar necesita privilegii de tip root. Acest aspect reduce în mod considerabil escaladarea de privilegii pe care o poate realiza o aplicație sistem compromisă sau un proces demon.

iOS utilizează ASLR (address space layout randomization) care protejează sistemul de exploatări ce țin de bug-uri de memorie. Aplicațiile integrate în iOS folosesc ASLR în mod implicit și se asigură că toate regiunile de memorie sunt determinate în mod aleator la momentul execuției.

iOS Software Developer Kit (SDK) oferă o suită completă de API-uri care permite dezvoltatorilor să adopte mecanisemele de protecție a datelor (Data Protection) și să asigure un nivel mare de protecție în aplicații. Protecția datelor este disponibilă pentru fișiere și API-uri de baze de date, incluzând NSFileManager, CoreData, NSDate și SQLite.

Extensii

iOS permite aplicațiilor să ofere diverse funcționalități altor aplicații prin intermediul extensiilor. Extensile reprezintă fișiere executabile binare semnate ce sunt comprimate împreună cu aplicația. Sistemul detectează în mod automat extensiile la momentul instării și le face disponibile pentru alte aplicații folosind un sistem de potrivire.

Zona de sistem care suportă extensiile este denumită extension point. Fiecare extensie oferă API-uri și impune politici pentru zonă. Sistemul determină ce extensii sunt necesare folosind sistemul de potrivire.

Extensiile sunt executate în propriul lor spațiu de adresă. Legătura dintre extensii și aplicația care le-a activat folosește comunicația inter-procese mediată de framework-ul sistem.

Tastaturile personalizate sunt un tip special de extensie din moment ce acestea sunt activate pentru întreg sistemul. Odată ce e activată, o extensia unei tastaturi este utilizată pentru orice câmp de text de intrare, mai puțin pentru căsuțele de tip text securizat (secure text view) care forțează accesul la tastatura nativă iOS.

Grupuri de aplicații

Aplicațiile și extensiile ce aparțin de contul unui dezvoltator pot să împartă informații atunci când sunt configurate să aparțină de același grup. Acest lucru se poate face de către dezvoltator în meniul Apple Developer.

Transport Layer Security (TLS)

iOS suportă Transport Layer Security (TLS) și Datagram Transport Layer Security (DTLS)

Conexiuni private virtuale

Conexiunile private virtuale (VPN) necesită setări minime de configurare pentru a funcționa pe dispozitivele iOS.

iOS suportă:

VPN On Demand pentru rețelele care necesită autentificare bazată pe certificat.

Per App VPN pentru a facilita conexiunile VPN dintre aplicații și domenii specifice.

Always-on VPN ce oferă organizațiilor controlul complet asupra traficului dispozitivelor prin tunelarea completă a traficului IP înapoi la organizație. În acest fel organizația poate monitoriza traficul către și de la dispozitivele aferente, poate securiza datele din interiorul rețelei și restricționa accesul dispozitivelor la internet.

Malware pe dispozitive mobile

Un malware reprezintă o bucată de cod malițios. Acesta este un software care este dezvoltat cu scopul de a face rău prin îngreunarea operațiilor de sistem, conferirea pentru atacator a accesului la informații confidențiale și sensibile, precum și conferirea abilității de a spiona deținătorul dispozitivului.

Tipuri de malware

Malware-ul desinat dispozitivelor mobile atinge cu pași repezi volumul și complexitatea celui de pe calculatoarele personale. Companiile de securitate observă tot mai multe tipuri de malware care activează pentru a profita de anumite vulnerabilități specifice.

Printre cele mai populare tipuri de malware se pot enumera:

Malware Bancar. Acesta este reprezentat de troieni cu scopul de a se infiltra în dispozitive și de a lansa procese ce colectează credențiale bancare ce sunt apoi trimise către un server de comandă și control (C&C).

Madware și Spyware. Madware este un neologism de la adware-ul prezent pentru calculatoare. Acesta reprezintă un script sau program instalat pe dispozitiv, în principal fără acordul posesorului, care colectează datele personale cu scopul de a oferi reclame. Un madware se instalează de obicei împreună cu un spyware. Spyware-ul colectează date bazate pe traficul de internet și detalii din dispozitiv (precum contactele salvate) pe care le transmite unei a treia părți.

Viruși și Troieni. Un virus sau troian reprezintă un malware care se instalează pe dispozitiv ca un atașat la o aplicație legitimă. Acesta au rolul de a iniția diverse mesaje SMS premium. În 2015 a fost detectat un troian care era instalat sub forma pachetului 888.apk și care avea scopul de a citii și intercepta textul din mesajele SMS și de a căuta după informații bancare, precum cuvinte cheie: ”Pay”, ”Check”, ”Bank”, ”Balance” sau ”Validare”. Pe lângă aceste lucruri, respectivul troian putea să intercepteze apelurile telefonice și să trimită către atacator detalii despre apelant. În 2012 a fost descoperită o versiune a jocului Angry Birds Space care nu reprezenta niciun comportament suspicios. Totuși, aceasta se folosea de vulnerabilitatea denumită GingerBreak care remonta sistemul cu permisiuni de citire și scriere, instala binarele de superutilizator și aplicația superUser.apk în sistem. Astfel dispozitivul deschidea un backdoor pentru atacatori și se alinia la o rețea de botnets.

Ransomware mobil. Scopul ransomware este de a cripta date importante pentru utilizator, precum documente, fotografii și videoclipuri. Atacatorul realizează aceste criptări comunicând permanent cu serveruld e comandă și control cu care se realizează schimbul de chei de criptare. În final i se cere utilizatorului victimă, printr-un mesaj afișat pe ecran în care i se aduce la cunoștință faptul că datele i-au fost criptate și că trebuie să plătească o recompensă, de obicei în monedă virtuală, pentru a putea să-și recupereze datele. Prin plata respectivă, atacatorul îi oferă victimei instrucțiunile și cheile necesare pentru a putea să-și decripteze fișierele blocate. Android.Simplocker a fost primul ransomware Android, detectat în 2013.

MMS Malware. Prin MMS malware se dorește exploatarea vulnerabilităților de interpretare a datelor media. Un exemplu în acest caz este bug-ul Stagefright ce a afectat o serie de sisteme de operare Android, pornind de la versiunea 2.2 (”Froyo”). Numele vulnerabilității este dat de o librărie afectată de aceasta, care, printre alte lucruri este utilizată pentru despachetarea mesajelor MMS. Vectorul de atac exploata o anumită vulnerabilitate de tip integer overflow prezentă în librăria sistem denumită Stagefright care era o componentă complexă dezvoltată în C++ și care avea rolul în interpretarea diverselor formate multimedia precum fișiere mp4. Prin exploatarea acestui bug i se permitea atacatorului să execute operații arbitrare pe dispozitivul victimei prin escaladarea de privilegii.

Descărcări nelegitime. Reprezintă malware instalat fără ca utilizatorul să-și ofere consimțământul sau să fie păcălit să-l ofere. Acesta poate să se realizeze prin vizitarea unui site malițios sau deschiderea unui mail.

Exploatări ale browser-ului. Prin exploatearea browserului atacatorul ține cont de vulnerabilitățile acestuia.

Aplicații de phishing. Acestea au rolul de arăta ca niște aplicații legitime cunoscute care cer introducerea de informații sensibile pe care le trimit către atacator. Cu cât este mai mic ecranul dispozitivului infectat, cu atât este mai greu de detectat faptul că aplicațiea nu este cea care se crede a fi. [21]

Evoluția malware pe platformele mobile

În 2004, cercetătorii în domeniul securității au creat copii ale primului virus mobil, Cabir, virus tip worm care creat pentru a infecta sistemul de operare Symbian 60.

Scris de către membrii grupului internațional de dezvoltatori de viruși, 29A, acesta a reprezentat un model, o demonstrație. Cabir a fost scris în C++ folosind Symbian și SDK-ul nativ pentru Nokia.

În mod ingenios, acesta folosea un vector de atac comun cu aproape toate smartphone-urile Symbian. Prin transferul bluetooth, acesta apărea ca un fișier cu extensia .SIS ce părea instalat în directorul de aplicații al telefonului.

Virusul nu a fost unul destinat în a genera pagube, ci scopul lui era de a afișa mesajul ‘Caribe’ pe ecranul dispozitivului infectat de fiecare dată când acesat este pornit. Caribe nici măcar nu a fost pus în spațiul public.

Totuși, acesta a reprezentat punctul de pornire pentru mulți alți hackeri care nu aveau intenții bune, iar în momentul în care l-au descoperit au reușit să creeze propriile variante. La mijlocul anului 2005 Cabir reprezenta fundația unor întregi familii de viruși, incluzând Pbstealer, un troian care căuta informații în contactele din telefon și trimitea aceste date prin bluetooth către primul dispozitiv care apărea în raza de tarnsfer.

În August 2004 un Troian a fost găsit într-o versiune ilicită a jocului Mosquito destinat platformei Symbian. Această versiune, pe lângă jocul original, mai avea și programul adițional Trojan.Mos. Acest Troja.Mos era responsabil ca de fiecare dată când jocul era accesat, troianul trimitea un SMS premium către un anumit număr de telefon, făcându-l astfel ca fiind primul virus care extrage bani de la victime.

În toamna lui 2004 a apărut Skuller, un malware care exploata o vulnerabilitate din Symbian și care avea scopul înlocuirii iconițelor aplicațiilor cu un craniu și ștergerea fișierelor apicațiilor. Acesta era un troian distribuit prin site-urile web și forumuri cu scopul de a conferi noi teme telefonului prin iconițe și imagini de fundal. Scopul lui Skuller a fost mai mult de a crea haos, dar prin ideea de a face un dispozitiv indisponibil a stat la baza ransomware-ului pe mobil. Acesta a avut un succes foarte mare în special prin faptul că încorpora cod din Cabir și se distribuia și prin Bluetooth.

Așadar, Cabir, Mosquito și Skuller au reprezentat o clasă de viruși care au atacat sistemul de operare Symbian, înlocuind aplicațiile sistem, isntalând aplicații corupte sau maligne sau infectând fișierele utilizator. [15]

În 2005 și-a făcut apariția CommWarrior care a fost un nou worm ce ataca sistemul de operare Symbian. Dar, în timp ce Cabir avea un singur vector de infecție, CommWarrior a fost prima amenințare mobilă ce se putea multiplica prin intermeduil serviciului de mesaje multimedia (MMS). Acesta se putea multiplica și prin bluetooth. Ciclul de infectare multimedia era ca atunci când o victimă primea respectivul worm, acesta alegea aleator un contact căruia îi trimite un mesaj tip MMS ce avea atașat un fișier care părea de încredere din partea persoanei de la care a fost trimis. Atunci când victima deschidea acel fișier, se infecta, iar ciclul continua. Acest lucru l-a făcut să aibă un succes mult mai mare în infectarea dispozitivelor.

În 2006 a apărut RedBrowser care a reprezentat primul malware pentru dispozitivele mobile care era de tipul multi-platformă. Acesta putea să funcționeze pe telefoane pe care rulează Java 2 Mobile Edition (J2ME). La acel moment, J2ME putea să ruleze pe telefoane făcute de Nokia, Motorola, Siemens, Samsung și multe altele. Malware-ul pretindea că este un browser de tip Wireless Application Protocol (WAP) dar, în loc să își realizeze funcționalitățile de browser, acesta trimitea mesaje de pe dispozitivele victimelor. Nu a durat mult și platformele celelalte, precum Windows Mobile au devenit țintele malware.

În 2007 a fost lansat FlexiSpy, primul spyware mobil. Acesta a fost promovat drept un dispozitiv pentru oamenii ca să-și spioneze partenerul. FlexiSpy putea să înregistreze apelurile telefonice, să colecteze mesajele SMS și să le trimită către atacator.

Tot în 2007 a fost lansat și primul dispozitiv iPhone. Odată cu iOS și cu dorința de a instala software nelegitim pe dispozitivele iPhone prin realizarea de jailbreak apăreau și problemele de securitate. Aceste dispozitive cu jailbreak se infectau cu malware-ul Ikee atunci când utilizau protocolul de securizare a traficului de rețea OpenSSH. Malware-ul profita de faptul că oamenii nu își modificau numele de utilizator și parola predefinite și, odată ce erau infectate, atacatorul fura identificatorul Apple al dispozitivului și parola și schimba imaginea de fundal cu cea a cântărețului Rick Astley.

După apariția Android în 2008, atacatorii au început să își direcționeze atenția către acesta.

În 2010 a apărut Zitmo care se baza pe succesul troianului bancar Zeus. Zitmo (Zeus-in-the-Mobile) avea scopul de a fura numerele de autorizație ale tranzacțiilor bancare prin internet. Acesta a fost mai întâi descoperit pe Symbian, iar apoi pw Windows Mobile, Blackberry și într-un final pe Android.

În 2011, amenințarea denumită DroidDream a fost descoperită în interiorul pachetelor a peste 50 de aplicații ce păreau legitime din Android Market (denumirea inițială a Google Play). Aceasta a fost descărcată de mii de ori. Malware-ul fura diverse informații sensibile din interiorul dispozitivelor infectate și putea, în același timp, să instaleze și alte aplicații.

În 2013 a apărut FakeDefender, prima amenințare de tip ransomware mobilă. Acesta viza dispozitive Android cărora le afișa alere false de securitate încercând să forțeze utilizatorii să cumpere o aplicație pentru a le elimina falsele amenințări. FakeDefender schimba, de asemenea, setările sistemului de operare, iar utilizatorilor nu li se mai permitea revenirea la setările din fabrică. Totuși, chiar dacă acest malware reușea să blocheze anumite caracteristici ale dispozitivelor, el nu realiza criptarea fișierelor, aspect care stă la baza ransomware-ului.

În 2014 a fost detectat Simplocker, primul ransomware care cripta fișiere și le decripta în schimbul unei recompense. Simplocker era inițial considerat o aplicație legitimă în varianta falsă a Google Play destinată vorbitorilor de limbă rusă. Malware-ul cripta documente, poze și fișiere video stocate pe memoria externă a dispozitivului. Apoi acesta afișa un mesaj în care informa utilizatorul că dispozitivul a fost blocat din cauza prezenței pornografiei infantile și că singura metodă pentru a îl debloca era de a plăti o taxă. Acest mesaj apărea la momentul în care utilizatorul încerca să acceseze orice aplicație.

În 2015 a apărut YiSpecter, primul malware pentru dispozitivele iOS fără jailbreak. YiSpecter crea un backdoor pe dispozitivele compromise care permiteau atactorilor să instaleze și să dezinstaleze aplicații, descarce fișiere, să afișeze reclame. Această amenințare a vizat în special China și Taiwan și a fost răspândită prin magazine virtuale third-party de aplicații, postări pe forumuri, social media sau prin servicii internet care redirectau utiliaztorii către sursa de descărcare a malware-ului. [16]

Figura . Geografia amenințărilor mobile în funcție de numărul de utilizatori atacați, 2017 [24]

Amenințări recente

Android

Grabos

La finele anului 2017, echipa McAfee de cercetare a securității mobile a descoperit un nou malware tip troian pe Android ce era prezent în 144 de aplicații din Google Play. Aceștia l-au denumit Grabos pentru că era elementul de text prezent în mai multe bucăți din codul sursă. Grabos a reușit să treacă de elementele de securitate google Play pentru că codul injectat este protejat de un obfuscator comercial făcându-l aproape imposibil de analizat.La lansarea în execuție a aplicațiilor infectate, malware-ul verifica dacă dispozitivul este conectat la internet și dacă aplicația este executată pe un dispozitiv legitim sau pe un emulator.

Dacă aplicația se afla online și pe un dispozitiv real atunci se executa un proces ascuns ce funcționa precum un fals File explorer / Music player. În modul legitim, utilizatorul căuta după o anumită melodie pe Youtube pe care o descărca și putea să o asculte în modul offline.

Figura . Execuție reală și execuție nelegitimă [17]

Pe partea nelegitimă aplicația colecta date despre dispozitiv pe care le critpa și le trimitea către un server de comandă și control. Serverul răspundea cu date criptate ce conțineau parametri necesari descărcării de muzică pentru a putea afișa banere publicitare și notificări personalizate pentru a-i cere utilizatorului să evalueze aplicația în Google Play. Totodată aplicația îi propunea utilizatorului să distribuie aplicația pentru a avea acces la viteze mai mari de descărcare.

Pe lângă aceste aspecte de raportare a datelor despre locația și configurația dispozitivului, Grabos verifica și prezența aplicațiilor de social media de pe dispozitiv.

În concluzie, prin afișarea mesajelor de notificare către utilizator, la accesarea lor, utilizatorul era păcălit în a instala noi aplicații. Gabos este un malware care a reușit să depășească elementele de securitate din Google Play și care a dobândit popularitate prin caracteristica de a putea descărca melodii de pe youtube și faptul că, după fiecare descărcare, utilizatorul era rugat să evalueze aplicația pe Google Play, acest lucru aducând instalarea de noi aplicații. [18]

În figura Figura 3.3. se poate observa cum două treimi din prezența malware din 2017 se află pe Android, în timp ce doar 27.96% pe Windows/PCs și mai puțin de 4% pe iOS și alte sisteme de operare. Nokia atribuie acest lucru în raportul de securitate pe 2017 aplicațiilor încărcate din magazinele de aplicații false sau neoficiale. Acestea reprezintă aproximativ 96% dintre aplicațiile descărcate în China.

Android reprezintă principala victimă malware pentru că pe smartphoneuri marea majoritate de amenințări apar prin intermediul aplicațiilor cu troieni. Utilizatorul este păcălit prin phishing, reclame sau inginerie socială în a descărca și instala diverse aplicații. Acest lucru funcționează din cauza faptului că Android permite instalarea aplicațiilor din orice sursă. Cu toate eforturile Google de a face Google Play un loc sigur, utilizatorii continuă să acceseze aplicații din zone nesigure. [19]

iOS

AceDeceiver

Troianul AceDeceiver este un program pentru sistemele Windows care oferă servicii pentru dispozitivele iOS de a reinstala sistemul, realiza jailbreak, backup, administrarea dispozitivului, curățarea sistemului. Acest malware exploatează defectele de proiectare în sistemul Apple cu rol în controlul distribuției ilegale a conținutului cu drepturi de autor din internet, denumit Digital Rights Management (DRM) sau FairPlay. FairPlay este mecanismul de protecție Apple pentru a proteja drepturile de autor a componentelor cumpărate din App Store.

Dispozitivele nu trebuie să aibă jailbreak pentru ca un atac de tip AceDeceiver să aibă succes. Malware-ul folosește o metodă denumită ”FairPlay Man-in-the-Middle (MitM) attack” pentru a instala aplicații malițioase pe dispozitive.

Când o aplicație este instalată pe un dispozitiv iOS, acesta cere un cod de autorizare pentru a dovedi că aplicația a fost cumpărată în mod drept (cerința FairPlay). Acest lucru este realizat de fiecare dată când o aplicație este cumpărată folosind calculatorul utilizatorului și apoi instalată pe dispozitivul mobil printr-o conexiune la calculator.

Într-un atac de tip AceDeceiver, un hacker poate să se poziționeze între utilizatorul care cumpără aplicația respectivă și rețeaua care descarcă aplicația în calculator, reușind să intercepteze codul de autorizație. AceDeceiver poate mai apoi, replicând comportamentul iTunes din calculator, să forțeze dispozitivul iOS în a descărca orice aplicație dorește utilizatorul.

AceDeceiver încerca să descarce trei aplicații malițioase pe dispozitive. Toate trei erau sub forma de aplicații pentru modificarea imaginilor de ecran (tip wallpaper) care au reușit să fie considerate de Apple drept aplicații de încredere. Acestea încercau apoi să se conecteze la un magazin de aplicații secundar și încurajau utilizatorul să își introducă credențialele Apple pentru a accesa mai multe opțiuni.

Acest atac a fost detectat în mai multe versiuni între anii 2015-2016.

Figura . Informații despre cele trei versiuni de AceDeceiver din App Sotre

În mod normal, Apple analizează codul aplicațiilor prealabil includerii acestora în App Store. După ce sunt acceptat, dacă dezvoltatorul dorește să le adauge noi funcționalități, pentru fiecare actualizare în AppStore, Apple verifică din nou codul aplicației. S-a constatat că aceste aplicații au fost permise de Apple și după o serie de actualizări, ceea ce a însemnat că au evitat de mai multe ori sistemul de verificare.

În figura Figura 3.5 este prezentat ecranul principal al aplicației pentru utilizatorii din afara Chinei. Când o astfel de aplicație este lansată în execuție, aceasta accesează URL-ul tool.verify.i4.cn/toolCheck/xhtml care reprezintă serverul de comandă și control pentru AceDeceiver. Dacă acest URL returnează 0, pe ecranul victimei va apărea o interfață de tip AppStore creată de atacator. Dacă în schimb, URL-ul returnează altceva decât 0, utilizatorului îi este afișat ecranul prezentat în Figura 3.6 [23]

Pegasus

Un alt malware foarte important care a atacat iOS este Pegasus care a fost rezultatul a trei vulnerabilități tip 0-day prezente pe iOS care au fost exploatate de atacatori. Acesta este un spyware sofisticat care are ca țintă în mod exlucis dispozitivele iOS.

Vulnerabilitățile de care a profitat acesta au fost:

CVE-2016-4655. Scurgeri de informații din Kernel – O vulnerabilitate bazată pe maparea kernelului care permitea atacatorului să calculeze locația acestuia în memorie.

CVE-2016-4656. Memorie Kernel coruptă din cauza Jailbreak – vulnerabilitate care permite atacatorului să realizeze jailbreak pe dispozitiv fără ca utilizatorul să fie înștiințat și care îi permite acestuia să instaleze apoi diverse software-uri.

CVE-2016-4657. Memorie coruptă în Webkit – vulnerabilitate prezentă în Safari WebKit care permite atacatorului să compromită dispozitivul atunci când utilizatorul accesează un link.

Malware-ul este bănuit a fi dezvoltat de către o organizație Israeliană care a fost cumpărată de o companie cu sediul în Statele Unite ale Americii în 2010. Pegasus a fost creat pentru a urmări disidenții politici, dar și alte ținte de valoare.

Atacul are structura clasică de tip phishing. Victima primește un mesaj ce conține un link. Dacă acesează acel link, aceasta este redirectată către o pagină web care pornește descărcarea spyware-ului. Spyware-ul exploatează vulnerabilitățile iOS și adună informații despre utilizator pe care le trimite înapoi către atacator folosind o conexiune cu un server de comandă și control. Acesta extrage informații importante chiar și din cadrul altor aplicații precum Gmail, Facebook, Skype, WhatsApp, Viber, FaceTime, Calnder, WeChat, Tango și altele. Un alt aspect important al Pegasus este că poate să asculte și pachetele audio și mesajele criptate, prin modulul său de keylogging și capabilităților de acces la informație înainte de criptare pentru datele transmise și după decriptare în cazul datelor recepționate.

Un alt aspect important al Pegasus este că acesta se auto distrugea în cazul în care nu reușea să realizeze o comunicare cu serverul de comandă și control pe o durată mai mare de 60 de zile. [24]

Metode de analiză a aplicațiilor

Analiza statică

Analiza statică reprezintă procesul prin care sunt analizate codul și structura programului pentru a-i determina modul de funcționare. Programul de analizat nu este executat la acest moment. În contrast cu analiza statică, analiza dinamică execută programul în vederea observării elementelor din momentul punerii în funcțiune.

Această metodă reprezintă un bun pas de pornire a unei analize malware, dar are și dezavantajul ce poate apărea din cauza codului obfuscat sau încărcat în mod dinamic. Aceste lucruri făcând-o greu de realizat.

Avantajele unei astfel de analize sunt date de costul procesării, timpul și resursele utilizate care sunt relativ puțin costisitoare.

Există o serie de pași prin care se trece în cazul aplicării unei analize statice:

Scanarea cu un antivirus.

Primul pas și unul foaret important în analiza unui fișier considerat infectat este de a-l executa în mai multe programe antivirus, care s-ar putea să-l fi descoperit deja ca fiind infectat. Trebuie să ținem cont de faptul că programele antivirus nu sunt perfecte. Acestea se bazează în principal pe o bază de date prin intermediul căreia reușesc să identifice bucăți specifice de cod (semnături de fișiere), precum și analiza de comportament (euristici) care identifică fișiere suspecte. O problemă este reprezentată de faptul că dezvoltatorii de malware pot să-și modifice ușor codul, astfel se schimbă semnătura programului și reușesc să nu fie detectați de antiviruși. De altfel, de multe ori malware-ul trece nedetectat de software-ul antivirus pentru că acesta nu este regăsit în baza de date. Euristicile de comportament ce au rezultate destul de bune în cod neidentificat ca fiind malițios, pot fi ocolite de malware nou și unic.

Așadar, pentru că majoritatea antivirușilor diferă în conținutul bazei de date și structurii de analiză euristică, este recomandat sp se realizeze o analiză folosind mai mulți antiviruși.

Există și site-uri web care realizează aceste scanări în cloud, precum VirusTotal care oferă și rapoarte cu detalii importante legate de analiză.

Semnătura malware-ului (hash-ul)

Procedeul de generare a semnăturii este o metodă comună de a identifica malware unic. Soft-ul malițios este trecut printr-un program care produce semnătura unică ce identifică malware-ul. Funcția de hash MD5 (Message-digest Algorithm 5) este cea mai utilizată, împreună cu SHA-1 (Secure Hash Algorithm 1).

Prin generarea semnăturii, aceasta poate fi utilizată ca o etichetă, poate fi distribuită cu alți analiști pentru a-i ajuta la identificarea malware-ului, poate fi căutat în mediul online pentru a verifica dacă acest hash a fost deja identificat.

Utilizarea stringurilor

Un program conșine stringuri dacă afișează mesaje, se conectează la un anumit URL sau copiază un fișier la o locație specifică.

Stringurile oferă într-un mod simplu o privire de ansamblu asupra funcționalităților programului de analizat.

Malware obfuscat sau împachetat.

Cei care scriu codul pentru malware utilizează programe de împachetare sua obfuscare pentru a le face fișierele mai dificil de detectat sau analizat. Programele obfuscate sunt cele ale cărei execuție autorul malwareului încearcă să o ascundă. Programele împachetate sunt un subset al celor obfuscate în care codul malițios este comprimat și nu poate fi analizat. Ambele metode limitează sau îngreunează procesul de analiză statică.

Programele legitime conțin multe stringuri în majoritatea cazurilor. Malware-ul care este împachetat sau obfuscat conține foarte puține stringuri. Dacă programul de analizat returnează un număr foarte mic de stringuri, atunci sunt șanse foarte mari ca acesta să fie obfuscat sau împachetat.

Bibliotecile și funcțiile importate

O parte importantă de informație pe care o putem afla despre un executabil este dată de import-uri. Acestea reprezintă fucții folosite de către un program care sunt, de fapt, ale altui program. Programatorii utilizează aceste import-uri pentru a nu reimplementa aceeași funcționalitate prezentă în mai multe programe. Codul bibliotecilor utilizate poate fi importat static sau la momentul rulării, în mod dinamic. Importarea statică este cea mai puțin utilizată metodă deoarece atunci când o bibliotecă este importată în mod static, tot codul acesteia este importat în program, iar acesta devine foarte mare. Cel mai des este utilizat modelul de încărcare dinamică, iar în cazul malware-ului obfuscat sau împachetat acesta este ajutat și prin faptul că funcțiile sunt încărcate doar la momentul utilizării și nu atunci când programul își începe execuția.

Analiza dinamică

Analiza dinamică reprezintă orice examinare realizată prin execuția malware-ului. Tehnicile de analiză dinamică reprezintă pasul secundar din procesul de analiză malware. Această analiză dinamică se realizează în mod normal după ce a fost făcută o analiză statică ce nu a dus la un rezultat concret. Acest lucru putându-se întâmpla din cauza codului obfuscat, procedeului de împachetare sau dacă analistul nu atinge niciun rezultat folosind toate tehnicile de analiză statică pe care le are la îndemână.

Analiza dinamică poate implica monitorizarea malware-ului în timpul execuției sau examinarea sistemului după ce procesul acestuia este închis.

Spre deosebire de analiza statică, analiza dinamică permite observarea adevăratei funcționalități a aplicației. Un exemplu ar putea fi dat de faptul că existența unui string în fișierul binar care reprezintă o anumită acțiune a malware-ului nu înseamnă neapărat că acea acțiune va fi executată. Prin analiza dinamică se pot observa diverse detalii specifice funcționalității malware-ului. Spre exemplu, în caul unui keylogger, analiza dinamică poate ajuta la localizarea fișierului de logare din sistem, detectarea înregistrărilor pe care le salvează, determinarea destinației informațiilor salvate și altele. Aceste lucruri sunt foarte greu sau imposibil de detectat folosind doar analiza statică.

Totuși, prin analiza dinamică se poate infecta sistemul computațional și rețeaua în care se află. Tehnicile dinamice prezintă și o serie de limitări pentru că este posibil ca nu toate bucățile de cod să fie executate la acest pas.

Există două metode de analiză dinamică, fiecare conducând la rezultate de o granularitate și calitate diferită:

comparând starea sistemului de operare înainte de execuția malware-ului cu cea de după ce acesta a fost executat. Această metodă analizează doar efectele cumulative ale malware-ului fără a putea observa schimbările dinamice, precum generarea unui fișier în timpul execuției și ștergerea acestuia la înainte de terminarea programului.

monitorizarea acțiunilor pe care le realizează malware-ul în timpul execuției utilizând un instrument de analiză specific, cum ar fi un debugger[25].

Există o serie de proceduri ce se au în vedere în cazul unei analize dinamice:

Monitorizarea apelurilor de funcții

În mod normal o funcție reprezintă o bucată de cod care îndeplinește o anumită cerință. Pentru a monitoriza ce funcții sunt apelate, se interceptează și analizează aceste apeluri. Procesul de itnerceptare a apelurilor de funcții se numește hooking. Funcția de hook este responsabilă pentru punerea în aplicare a funcționalităților necesare analizei precum salvarea invocării acesteia într-un fișier de logare sauprin analiza parametrilor de intrare.

Funcțiile care formează un set de funcționalități comune, precum manipularea de fișiere sau comunicarea în interiorul rețelei, sunt în mod obișnuit grupate într-un așa-numit application programming interface (API).

Software-ul executat pe un sistem este împărțit în: aplicații generale, precum procesoare de word sau manipulatoare de imagine care sunt executate în așa-numitul mod utilizator, iar sistemul de operare este executat în modul kernel. Această separare previne procesele din modul utilizator să interacționeze cu procesele din sistem în mod direct. De exemplu, nu este posibil ca un proces din spațiul utilizator să deschidă sau să creeze un fișier. În schimb, sistemul de operare oferă API predefinit pentru acest lucru, interfața de apeluri sistem. Prin aceste apeluri, un proces din modul utilizator poate cere sistemului de operare să realizeze anumite sarcini pentru el.

Două metode prin care se poate realiza procedeul de hooking este prin tehnicile de debugging sau, în cazul sistemelor de operare pentru calculatoare, prin înlocuirea dinamic shared libraries cu biblioteci personalizate ce conțin funcțiile de hook.

Analiza parametrilor funcțiilor

Spre deosebire de analiza statică a parametrilor funcțiilor în care se încearcă determinarea valorilor posibile în cazul acestora, în analiza dinamică a parametrilor se observă valorile ce sunt prezente în apelul funcțiilor. Prin urmărirea acestor valori se pot corela apeluri ale funcțiilor ce operează asupra aceluiași obiect.

Urmărirea fluxului de informații

Prin acest lucru se are în vedere modul în care programul procesează datele. Prin urmărirea interacțiunii dintre informații, se are în vedere dacă o variabilă de date X este în vreun fel influențată de o altă variabilă Y pentru a determina dacă date de intrare pot produce găuri de securitate.

Tehnicile bazate pe fluxul de informații dinamic au fost utilizate pentru:

aplicații benigne: erori de memorie, command injection, SQL injection, Cross-Site Scripting. etc.

aplicații care nu sunt de încredere: detectarea comportamentului de bot controlat de la distanță, determinarea comportamentului de tip activare de la distanță sau detectarea violării politicilor de securitate interne la momentul execuției.

Analiză bazată pe algoritmi de machine learning

Machine learning: concepte și definiții

”Machine learning is a set of methods that gives computers the ability to learn without being explicitly programmed.” Arthur Samuel.

Cu alte cuvinte, un algoritm de machine learning descoperă, analizează și formalizează principiile care stau la baza datelor pe care le vede. Folosind aceste cunoștințe dobândite, algoritmul poate observa aceste proprietăți asupra altor aplicații pe care nu le-a analizat. Un set de principii matematice formalizate care stau la baza proprietății datelor se numește model.

Învățare nesupravegheată

O abordare a învățării automate este învățarea nesupravegheată. În acest context, ni se oferă doar un set de date fără a utiliza informații care nu sunt clasificate drept benigne sau maligne permițând algoritmului de învățare să funcționeze fără a fi ghidat. Scopul este de a descoperi structura datelor sau legea generării acestora. Un exemplu important este gruparea (sau clustering-ul). Clustering-ul este o sarcină care include divizarea unui set de date în grupuri de obiecte similare.

Învățare supravegheată

Învățarea supravegheată este reprezentată de aplicarea algoritmului asupra unui set de date ce are corelat și răspunsul sau categoria din care face parte fiecare obiect introdus. Scopul este de a pregăti modelul ce va genera răspunsuri cât mai exact pentru obiectele noi introduse.

Învățarea supravegheată constă în două etape:

Formarea și fixarea unui model pentru datele disponibile.

Aplicarea modelului antrenat asupra noilor date pentru a obține predicții.

Aplicabilitatea machine learning în securitatea cibernetică prin învățare supravegheată

Pentru acest lucru este necesar:

un eșantion de obiecte

fiecare obiect este reprezentat de o caracteristică X

fiecare obiect este mapat cu un răspuns corect Y

Această informație de antrenare este utilizată la etapa de antrenare a rețelei, atunci când se caută cel mai bun model care poate produce răspunsul corect Y’ pentru obiectele necunoscute ce au caracteristica X’.

În cazul detecției malware, X poate să reprezinte caracteristicile, conținutului sau comportamentul unui fișier, spre exemplu statistici ale acestuia sau o listă de funcții API utilizate. Y poate să fie ”malware” sau ”benign” sau diverse alte clasificări mai detaliate, de exemplu virus, Troian-Downloader, adware etc.

După ce rețeaua a fost antrenată și s-a fixat un model se trece la etapa a doua în cazul detecției malware denumită etapa de protecție. În această etapă se utilizează modelul predictiv generat în prealabil pentru a putea clasifica noi fișiere de analizat. Aplicând algoritmul de machine learning asupra a noi fișiere împreună cu datele din model ajungem la decizia modelului care clasifică fișierul în malițios sau benign.

Figura . Procesul de detecție malware utilizând machine learning în modul supravegheat [26]

Securitatea fiind un domeniu sensibil, în utilizarea algoritmilor de machine learning pentru detectarea malware sunt necesare respectarea mai multor proprietăți pentru a avea un sistem de încredere.

Sunt necesare foarte multe seturi de date. Pentru că în crearea unu model cel mai important impactul pe care îl au datele introduse, acestea trebuie să fie într-un număr cât mai mare și mai echilibrat, adică proporția de date considerate malițioase trebuie să fie aproape de cea a datelor considerate benigne, pentru a antrena rețeaua către un model cât mai exact.

Modelul antrenat trebuie să fie interpretabil. Acest lucru constă în crearea unui model de tip white-box. În cazul multor modele sunt introduse datele X care pdoduc rezultatul Y trecând printr-o secvență complexă de operații ce greu pot fi interpretate de o persoană. Un model de tip white-box este necesar, spre exemplu, în cazul unui false-positive atunci când se dorește să se înțeleagă care lucru a declanșat acel false-positive în vederea remedierii pe viitor.

Rata detectărilor false (false-positive trebuie să fie foarte scăzută). Detecția de tip false-positive se întâmplă atunci când un algoritm etichetează un fișier benign ca fiind malițios.

Algoritmii trebuie să permită adaptări rapide la noile metode ale dezvoltatorilor de malware.

Instrumente open-source pentru analiza aplicațiilor mobile

Instrumente pentru analiza aplicațiilor iOS

otool

Este un instrument ce afișează conținutul diverselor fișiere obiect sau biblitoeci. Acesta înțelege formatul fișierelor Mach-O și formatele fișierelor universale.

Formatul Mach-O al binarelor conținute de un fișier .ipa este împărțit în 3 componente: header, load commands (comenzile de încărcat) și segmentul de date.

Analiza executabilului:

Determinarea arhitecturii pentru care binarul a fost compilat.

otool -f BINARY

Figura . Exemplu de rezultat pe care otool îl oferă la verificarea arhitecturii unui binar.

Determinarea dacă binarul este criptat.

otool -l BINARY | grep -A 4 LC_ENCRYPTION_INFO

Figura . Exemplu de rezultat pe care îl oferă otool în cazul verificării cu rezultat pozitiv dacă acesta este criptat.

Verificarea prezenței ASLR (address space layout randomization)

Acest lucru se realizează verificând prezența flag-ului PIE (Position Independent executables).

otool -Vh BINARY

Figura . Verificarea prezenței flagului PIE în binar

Verificarea prezenței ARC (Automatic Reference Counting). ARC este o caracteristică a compilatorului care oferă automatizarea managementului memoriei pentru obiectele Object-C.

otool -v -I BINARY | grep release

Verificarea dacă aplicația folosește și alocări dinamice de memorie. Acest aspect ne poate spune dacă aceasta ar putea să aibă probleme în amnagementul memoriei.

otool -v -I BINARY | grep malloc

otool -v -I BINARY | grep free

class-dump-z

Acesta este un utilitar în linie de comandă care permite examinarea segmentelor Object-C din fișierele Mach-O. Acesta generează declarații ale claselor, categoriilor și protocoalelor.

class-dump-z BINARY

În cazul în care binarul este criptat, comanda va încerca să interpreteze rezultatele de afișat, însă va informa utilizatorul că este necesar un fișier necriptat pentru ca informațiile pe care le oferă să fie bune.

Clutch 2.0

Clutch este un instrument de decriptare pentru aplicațiile iOS. Acesta necesită un dispozitiv iOS asupra căruia a fost instalat un jailbreak.

Pentru utilizarea acestui instrument trebuie adăugat depozitul (repozitory) iPhoneCake în Cydia folosind URL-ul http://cydia.iphonecake.com. Odată ce acesta este adăugat, Clutch 2.0 poate fi instalat.

După ce se realizează instalarea instrumentului pe dispozitiv, se realizează o conexiune SSH sau se folosește o aplicație terminal care escaladează privilegiile de root ale dispozitivului.

După conectarea la dispozitiv se folosește comanda:

Clutch2 -i

Aceasta afișează o listă cu toate aplicațiile descărcate din App Store și instalate pe dispozitiv.

Figura . Exemplu de afișare a aplicațiilor folosind Clutch 2.0

Pentru descărcarea binarului necriptat al aplicației WordPress se folosește comanda:

Clutch2 –b org.wordpress

Rezultatul este pus în directorul /var/tmp/clutch. Acesta conține aplicațiile în format decriptat și pot fi copiate din director pentru a fi analizate.

objection

Objection reprezintă un set de instrumente ce ajută la exploatarea sistemului iOS în timpul execuției. Acesta este o soluție dezvoltată de Frida. Frida permite injectarea de fragmente de JavaScript sau propria bibliotecă în aplicații native pe Windows, MacOS, GNU / Linux, iOS, Android și QNX. De asemenea, Frida oferă câteva instrumente simple dezvoltate utilizând API-ului Frida. Acesta este scris în C.

Pornind de la Frida, objection a fost creat pentru a putea evalua aplicațiile mobile și securitatea acestora.

Objection este destinat evaluării atât a aplicațiilor Android cât și iOS și conține actualizări periodice în funcție de scenariile noi de utilizare.

Specificații objection pentru toate platformele:

interacțiunea cu sistemul de fișiere, listarea fișierelor și afișarea conținutului acestora, precum și încărcarea sau descărcarea de fișiere

executarea diverselor sarcini legate de memorie precum listarea modulelor încărcate și exporturilor pe care le realizează acestea

evitarea și simularea unui mediu rootat sau cu jailbreak

listarea claselor încărcate și a metodelor acestora

evitarea diverselor funcționalități SSL.

interacțiunea cu bazele de date SQL

executarea de scripturi Frida personalizate

Specificații objection pentru iOS:

descărcarea lanțului de chei iOS și exportarea într-un fișier

descărcarea datelor din NSUserDefaults și NSHTTPCookieStorage

evitarea diverselor restricții aplicate de TouchID

monitorizare iOS pasteboard (obiect ce reține informațiile cerute de funcționalitățile de copy, cut sau duplicate)

descărcarea și exportarea fișierelor codate .plist într-un format ușor de citit

În figura următoare se poate observa un exemplu de utilizare al objection. Se conectează terminalul la un iPod cu sistemul de operare iOS 10.2.1, se printează directorul curent și conținutul acestuia.

Figura . Listare director curent și conținut dispozitiv iOS [28]

Pentru descărcarea lanțului de chei se folosesc comenzile:

objection explore -q

ios keychain dump –json keychain.json

Pentru conectarea la o bază de date SQLite și interogarea acesteia se pot utiliza următoarele comenzi:

sqlite connect mydb.db

sqlite execute query slect * from mytable

sqlite disconnect

Evitarea mecanismului de SSL Pinning (caracteristică a securității aplicațiilor care se asigură că clientul verifică certificatul serverului cu care comunică comparând-ul cu cel deținut în mod sigur: https://possiblemobile.com/2013/03/ssl-pinning-for-increased-app-security/ ) al unei aplicații iOS aflată în execuție:

objection -N explore -q

ios sslpinning disable

PassionFruit

PassionFruit este un instrument destinat analizei aplicațiilor black-box iOS.

Caracteristici:

suportă dispozitive fără jailbreak

afișarea schemelor URL

verificarea semnăturilor

listarea info.plist

realizarea capturilor de ecran

opțiunea checksec pentru a verifica dacă o aplicație este criptată și dacă are activate mecanismele de PIE, ARC sau stack canary.

navigarea în interiorul aplicațiilor pentru previzualizarea directă sau descărcarea imaginilor, vazelor de date SQLite și fișierele plist. Meniul cuprinde și vizualizator pentru hexa, imagini, fișiere plist și pentru citirea bazelor de date SQLite

verificarea framework-urilor pe care le încarcă aplicația țintă și simbolurile exportate de acestea

interceptarea apelurilor, argumentelor și conținutul stivei

listarea claselor aplicațiilor și metodelor acestora

descărcarea KeyChain, BinaryCookies and UserDefaults

Figura . Meniu general PassionFruit [29]

Instrumente pentru analiza aplicațiilor Android

Mobile Security Framework

Mobile Security Framework (MobSF) reprezintă o aplicație/instrument cu capabilități de tip toate într-unul ce ajută la testarea aplicațiilor prin analiza statică și dinamică a aplicațiilor mobile pentru Android/iOS și Windows. MobSF are capabilitatea de a testa dinamic aplicațiile în momentul execuției acestora.

Acesta conține și un REST API ce poate fi utilizat pentru generarea de noi instrumente care să utilizeze modulele prezente în MobSF sau pentru integrarea acestora într-o altă aplicație.

MobSF oferă și posibilitatea de scanare în masă a sample-urilor de aplicații prin scriptul python python mass_static_analysis.py ce primește ca argumente IP-ul serverului pe care este executat instrumentul de analiză și directorul ce conține fișierele. Exemplu:

python mass_static_analysis.py -s 127.0.0.1:8000 -d /home/files/

Pentru analiza statică există posibilitatea utilizării unui container de docker.

În mod implicit MobSF salvează datele într-o bază de date de tip Sqlite3, dar există posibilitatea configurării unei baze de date Postagres.

Instalare

Soluția poate fi descărcată de la adresa Github: https://github.com/MobSF/Mobile-Security-Framework-MobSF.

MobSF este un instrument care poate fi executat pe un sistem Windows, MAC sau Linux și necesită: Python 3.6+; Oracle JDK 1.7+;

După descărcare este necesar să fie urmărite instrucțiunile de instalare de pe pagină.

Prin instalarea tuturor elementelor necesare rulării stabilite în prealabil, se crează mediul python virtual folosind instrumentul python virtualenv și se instalează celelalte biblioteci necesare execuției MobSF. Soluția este încă o versiune Beta și conține diverse probleme nerezolvate ce pot fi expuse pe pagina de github, dezvoltatorii încercând să le rezolve.

Prin execuția scriptului manage.py (python manage.py runserver) în sensul pornirii serverului și accesarea link-ului local pe portul specificat, va apărea următoarea fereastră:

Figura . Meniul MobSF

Meniul prezentat în Figura 5.7 oferă următoarele posibilități:

analiza fișierelor prin încărcarea acestora pe server

căutarea baza de date cu rapoarte ale analizelor vechi folosind un MD5

accesarea listei cu scanările recente

accesarea documentației

Figura . Meniu principal cu rezultatele unei scanări cu MobSF

Meniul principal cu rezultatele unei scanări prezent în Figura 5.8 reprezintă o pagină statică HTML ce conține diverse detalii legate de analiza aplicației în cauză.

Utilizare

Analiza Statică

Figura . Reprezentarea schematică a procesului de analiză statică MobSF [30]

Analizatorul acceptă și analizează cod din fișiere .apk, precum și cod sursă Java. Odată ce fișierele sunt încărcate, analizatorul începe procesul de examinare a fișierelor și a codului.

Conform meniului prezent în stânga imaginii din Figura 5.9 se poate observa opțiunea de a scana dinamic fișierul respectiv și structura rezultatelor din scanarea statică:

Information. Informații generale despre fișier precum nume, dimensiune, hash-uri, denumirea pachetului, versiunea Android pentru care este destinat și componente ale aplicației.

Scan Options. Sunt prezente opțiunile pentru a scana dinamic sau a descărca sau analiza codul Java sau Smali generate din fișier.

Signer Certificate. Detalii despre certificatul digital prezent în aplicație.

Permisiuni. Lista cu permisiuni împreună cu descrierea și importanța fiecăreia în mod ierarhic conform severității acestora.

Binary Anaysis. Reflectă analiza bibliotecilor .so utilizate de aplicația instalată pentru apelarea diverselor funcționalități.

Android API. Structura de pachete utilizate și de funcții java prezente în aplicație.

Browsable Activities. Denumirea activităților detectate în aplicație împreună cu intenturile lor.

Security Analysis.

Manifest Analysis. Probleme de securitate detectate în fișierul de configurare AndroidManifest.xml împreună cu problema, severitatea și descrierea acestora.

Code Analysis. Probleme de securitate detectate în codul aplicației. Este specificată problema, severitatea și fișierul sursă ce conține această problemă.

File Analysis. Probleme de securitate detectate pe diverse fișiere conținute în pachet. Este prezentă și descrierea acestei probleme.

Malware Analysis.

DEX Malware Analysis. Acest instrument folosește APKiD care are rolul de a obține informații despre cum fișierul .apk a fost construit. Acesta identifică informații despre compilatoare, instrumente de împachetare, instrumente de obfuscare și altele.

Virus Total. Instrument online ce se bazează pe o serie de scannere în cloud aflate pe site-ul www.virustotal.com. Pentru obținerea accesului la acesta este necesară creare unui cont și înregistrarea cheii contului în interiorul MobSF. Acesta oferă rapoarte și detalii legate de antivirușii prezenți în cloud-ul VirusTotal.

Domain Malware Check. Verificarea stringurilor tip domenii prezente în aplicații pentru a observa dacă acestea sunt considerate malițioase.

Recoinnaissance

URLs. Extragerea URL-urilor și specificarea fișierelor java din care au fost extrase acestea.

Emails. Detectarea adreselor email prezente în aplicație și fișierul java corespunzător.

Strings.

Components. Structurile componentelor recunoscute în aplicație: activități, servicii, receptoare, furnizori, biblioteci, fișiere.

Download Report. Această opțiune generează un raport PDF al paginii statice HTML cu conținutul analizei statice a fișierului analizat.

Start Dynamic Analysis. Pornește analiza dinamică.

Analiza Dinamică

Analiza dinamică este realizată executând aplicația într-un emulator oferit de MobSF. Informația colectată este examinată în sensul verificării:

dacă aceasta cere accesul la date sensibile

existența diverselor detalii hardcodate

analiza traficului

cereri nesigure prin intermediul internetului

Analiza dinamică folosind Mobile Security Framework presupune configurarea unui dispozitiv virtual oferit de soluția open source MobSF. Pentru testările acestui proiect a fost utilizatăm mașina virtuală Download MobSF Android x86 4.4.2 VM (v0.2).

Configurarea mașinii presupune încărcarea într-un mediu virtual a acesteia. Configurarea rețelei și setarea instrumentului MobSF pentru a utiliza acest emulator în execuția aplicației de analizat.

Figura . Emulator MobSF pentru analiza dinamică

Figura . Meniu MobSF Dynamic Analyzer

Figura . Meniu principal cu rezultatele unei scanări dinamice cu MobSF

Conform meniului prezentat în Figura 5.12 se pot observa rezultatele scanării dinamice:

Figura . Opțiunea HTTPS afișează

Prin activarea opțiunii HTTPS Traffic se descarcă fișierul WebTraffic.txt ce conține toate apelurile și informația transmisă de aplicație pe canalul HTTPS.

Logcat Logs, Droidmon API Monitor Logs, Dumpsys Logs generează fișiere .txt ce conțin afișările din aplicație, erorile declanșate de diverse acțiuni din aplicație împreună cu o serie de detalii legate de ele.

Application Data generează o arhivă ce conține toate librăriile, datele și resursele utilizate de aplicație.

Figura . Apelurile funcțiilor librăriilor folosite de aplicație

API Monitor este repreentarea grafică a diverselor apeluri de librării pe care aplicația le realizează. Acestea sunt sortate după cum se poate observa în Figura 5.14:

File IO – detalii legate de scrierile și citirile din fișiere

Network Calls – detalii despre metodele care apelează funcții din internet

Binder Calls – diverse apeluri dintre activitățile și procesele aplicației sau între aplicație și alte aplicații sau procese prezente pe sistem

Crypto – metode apelate din bibliotecile folosite pentru criptarea datelor

Device Info – detalii cerute de aplicție despre dispozitivul pe care rulează

Base64 – codări și decodări base64

Content – hash-urile utilizate de aplicație

SMS

Device Data

Dex Class Loader – încărcarea claselor din fișiere .jar și .apk

Reflection

System Manager

Process

Exported Activity Tester – activitățile exportate de aplicația analizată

Activity Tester – activitățile detectate în funcționalitățile aplicației

Screenshots – imaginile captate în timpul analizei dinamice

HTTPS Traffic – apelurile https realizate în timpul analizei dinamice

Recoinessance: Clipboard Dump, URLs, Malware Check, Emails – verificarea domeniilor, mailurilor detectate ca fiind utilizate de analiza dinamică a aplicației prin apelurile din momentul execuției acesteia

File Analysis

SQLite Database – bazele de date sql utilizate de aplicație

XML Files – fișierele XML utilizate de aplicație

Other Files – alte fișiere pe care le utilizează aplicația pentru a stoca date

Download / Print – descărcarea raportului dinamic în format PDF

Exemplu analiză .apk

Pentru realizarea analizei am folosit aplicația DIVA (Damn Insecure and Vulnerable App) ce este dezvoltată cu rolul de a fi nesigură.

Pentru început se descarcă aplicația de la adresa http://www.payatu.com/wp-content/uploads/2016/01/diva-beta.tar.gz

Se activează mediul virtual creat la momentul clonării MobSF de pe github.

Se pornește instrumentul MobSF din mediul virtual activat în prealabil.

Figura . Execuție MobSF din mediul virtual python

Se accesează link-ul specificat în Figura 5.15: http://127.0.0.1:8000/

Se încarcă arhiva .apk în meniul accesat la adresa specificată prealabil.

Figura . Analiza statică a aplicației DIVA folosind MobSF

Se analizeză informațiile importante rezultate în urma analizei statice:

Figura . Rezultate analiză statică DIVA – Permisiuni și Biblioteci

Figura . Rezultate analiză statică DIVA – XML Manifest

Figura . Rezultate analiză statică DIVA – Cod

Figura . Rezultate analiză statică DIVA – Cod RAW SQL Query

În figura Figura 5.20, din analiza statică realizată de MobSF se poate observa că fișierele Java decompilate din .apk conțin cod ce poate genera probleme de securitate în întreaga bază de date. Analizând mai departe, manual, fișierele specificate, am ajuns la părțile de cod ce interoghează baza de date și se poate observa cum acestea sunt susceptibile la SQL Injection.

Figura . Rezultate analiză statică DIVA – Virus Total

Prin activarea opțiunii MobSF pentru scanarea aplicației în cloud-ul VirusTotal, în analiza statica se poate observa un raport ce reprezintă rezultatele celor 61 de soluții de scanare în cloud-ul VirusTotal.

Figura . Rezultate analiză statică DIVA – Raport VirusTotal

Continuând pe butonul Full Report reprezentat în figura Figura 5.22 se ajunge la rezultatul din figura Figura 5.23. din care reiese că modulul de scanare WhiteArmor a detectat aplicația ca fiind un PUP (Potentially Unwanted Program).

Se aplică analiza dinamică.

Figura . Analiză dinamică MobSF

În Figura 5.23. se observă cum instrumentul MobSF s-a conectat la emulatorul cu Android oferit împreună cu soluția.

Prin accesarea diverselor activități și opțiunilor de activare activități, creare de screenshot, dezinstalare și instalare de certificat, instrumntul analizează comportamentul acesteia și salvează detaliile.

Prin pornirea activităților, instrumentul iterează colecția de activități ale aplicației și le apelează pentru a observa comportamentul acestora.

Figura . Aplicare analiză dinamică – apelarea unei activități

Modul dinamic permite analiza aplicației în mod manual. Prin accesarea funcționalităților acesteia în mod manual se pot verifica anumite situații dorite în mod explicit.

Figura . Analiza dinamică MobSF meniu raport

În Figura 5.25. se observă opțiunile ce le oferă MobSF la finalizarea analizei dinamice. Se pot descărca diverse loguri, date ale aplicației și trafic de date. Opțiunea CapFuzz aplică fuzzing asupra aplicației.

Figura . Analiza dinamică MobSF

Din analiza dinamică se pot observa:

În Figura 5.26 se observă bazele de date SQLite utilizate de aplicație și încercarea de a utiliza email-ul conectat la dispozitiv.

În ambele tipuri de analiză, statică sau dinamică, instrumentul oferă posibilitatea descărcării în format .PDF a rapoartelor finale.

Concluzii

Mobile Security Framework reprezintă o soluție completă, free și open-source ce poate genera rezultate importante în procesul de analiză a securității aplicațiilor mobile.

Pentru utilizarea în cazul analizei aplicațiilor iOS este necesar un laborator mai complex pentru a ajunge la anumite rezultate, acest lucru datorându-se modelului de securitate, arhitectură, interconectare și tipului de cod sursă a dispozitivelor Apple și a arhivelor ce conțin codul aplicațiilor.

În cazul aplicațiilor Android, laboratorul utilizat conține executabilul MobSF și emulatorul Android 4.4.2. Există o plajă ridicată de aplicații care nu pot fi rulate în mod dinamic și analizate folosind această soluție, însă codul static oferă rezultate bune. În principal, aplicațiile care dau eroare la analiza dinamică nu sunt suportate de specificațiile necesre MobSF pentru rularea acestora.

Mai multe aspecte importante pot fi menționate la acest modul, printre care: încorporarea analizei dîn cloud-ul oferit de VirusTotal și raportul oferit de acesta; analiza traficului, a stringurilor și a URL-urilor; ApkID ce cuprinde un modul de analiză folosind reguli yara predefinite pentru acest tip de aplicații; structurarea informațiilor într-un mod lizibil, posibilitatea exportării raporturilor analizelor statice, cât și dinamice în format PDF.

Santoku_0.5

Santoku_0.5 reprezintă o platformă open-source dedicată analizei aplicațiilor pe dispozitive mobile. Aceasta este o distribuție de Linux ce are integrate un set de tooluri cu rolul de a realiza mobile forensics, analiza și securitatea aplicațiilor mobile. De aici și numele Santoku, care se traduce prin ”cele trei virtuți” sau ”cele trei utilități”.

Așadar, această suită de instrumente se poate împărți în:

Mobile Forensics (instrumente pentru achiziționarea și analiza datelor

Instrumente pentru citirea memoriei disponibile pentru mai multi producători

Instrumente pentru reprezentarea memoriilor NAND, cardurilor media și memoriei RAM.

Versiunile gratuite ale unor instrumente de forensics comerciale

Mai multe scripturi și utilitare create special pentru analiza forensics mobilă

Mobile Malware (instrumente pentru analiza malwareului pe dispozitive mobile)

Emulatoare pentru dispozitivele mobile

Utilitare pentru a simula servicii de rețea pentru analiza dinamică

Instrumente pentru decompilare și dezasamblare

Acces la bazzele de date de malware

Mobile security (evaluarea aplicațiilor mobile)

Instrumente pentru decompilare și dezasamblare

Scripturi pentru a determina probleme comune în aplicațiile mobile

Scripturi pentru automatizarea decriptării binarelor, încărcarea aplicațiilor, analiza detaliilor aplicațiilor și altele.

Figura . Lista cu instrumentele Santoku_0.5

Instalare

Santoku repreintă o distribuție Linux care se poate descărca în format .iso. Această imagine are o dimensiune de aproximativ 2.5 GB și conține toate instrumentele necesare pentru a fi utilizate ulterior instalării în analiza securității aplicațiilor pe dispozitive mobile.

Acesta poate fi descărcat de la adresa http://santoku-linux.com/download/ și instalat ca o distribuție obișnuită de Linux pe 64 biți într-un mediu de virtualizare (recomandat VirtualBox sau VMWare Player).

Pentru această cercetare științifică am folosit mediul VirtualBox pentru instalarea, configurarea și utilizarea mașinii virtuale de Santoku.

Utilizare

Figura . Ecran principal Santoku_0.5

În figura Figura 5.28. se pote observa fereastra principală Santoku_0.5. Pe aceasta este reprezentat modelul după care sunt organizate instrumentele prezente pe mașină și faptul că acestea sunt intuitiv grupate pentru a ajuta analistul în procesul de verificare a unei aplicații.

Setări necesare pentru analiză

Instalare dispozitiv virtual

Pentru realizarea unei analize de securitate este necesară existența unui dispozitiv pentru a putea analiza din punct de vedere dinamic cum reacționează aplicația respectivă. Pentru creare unui dispozitiv virtual în Santoku se accesează instrumentul Android Virtual Device (AVD) Manager.

Figura . Instalare pachete necesare virtualizării

Figura . Creare dispozitiv virtual AVD Manager

Exemplu analiză .apk

Selectare și descărcare aplicație

Pentru această analiză am folosit aplicația Bake A Cake pe care am descărcat-o de la link-ul https://apkpure.com/bake-a-cake-cooking-games/air.com.girlygames.BakeaCake.

Forensics

Utilitarul permite analiza forensic a dispozitivelor hardware reale iOS și Android.

Figura . Instalare AFLogical pe dispozitiv folosind adb

Pentru extragerea datelor dintr-un dispozitiv Android este necesară instalarea aplicației AFLogical.apk prezentă în suita de instrumente a Santoku_0.5. Pentru instalarea acesteia este necesară conctarea dispozitivului Android prin intermediul USB la sistemul de calcul. Folosind opțiunea Devices se selectează conectarea dispozitivului pentru mașina Santoku_0.5. După conectare, se procedează ca în figura Figura 5.31. Se instalează aplicația AFLogical folosind comanda:

adb install AFLogical.apk

După instalarea aplicației pe dispozitiv, este necesară deschiderea acesteia și selectarea datelor de extras conform figurii Figura 5.32.

După selectarea datelor dorite acestea vor fi extrase pe sdcard folosind butonul capture. Pentru extragerea corectă a datelor este necesar ca pe dispozitivul respectiv să existe un sdcard.

Figura . Aplicație AFLogical. Selectarea datelor de extras și mesajul reuzltat în urma extragerii acestora.

Figura . Date extrase cu AFLogical

Figura . Informații conținute de fișierul SMS.xml extras cu AFLogical

Conform figurii Figura 5.34. se poate observa cum AFLogical extrage informațiile din mesajele SMS, atât string-urile transmise, cât și informații de sistem și metadate. Acestea pot fi de folos în cadrul unei investigații țintă a unei persoane.

Analiza statică

Analiza statică necesită decompilarea codului și investigarea codului sursă pentru a ajunge înțelege modul de funcționare al aplicației și pentru a determina dacă există sau nu malware.

Inițial vom decompila fișierul .apk pentru a analiza conținutul AndroidManifest.xml. Fișierul AndroidManifest.xml conține informații despre aplicație referitoare la interacțiunea acesteia cu sistemul de operare Android, pachetul Java utilizat, componentele aplicației, procesele care sunt responsabile cu componentele aplicației, permisiuni, biblioteci pe care aplicația le utilizează și nivelul minim Android API.

apktool

Apktool are rolul de a extrage resursele android din fișierele aplicație. Folosind instrumentul apktool din prezent în Santoku_05 putem genera fișierul AndroidManifest.xml decompilând fișierul aplicație .apk.

apktool d bake_a_cake.apk

Figura . Conținut AndroidManifest.xml

Analizând conținutul AndroidManifest.xml al aplicației se poate constata că nu există nimic suspicios. Permisiunile sunt unele normale pentru o astfel de aplicație și, deci, nu ne duc nici ele către o direcție anume de existență a unei activități malițioase. Acestea fiind pentru accesul internetului și verificarea stării rețelei.

Mai departe, uitându-ne în rezultatul generat de apktool, analizăm conținutul string-urilor din folder-ul destinat resurselor, fișierul strings.xml.

Figura . Afișare resurse rezultate din apk cu ajutorul apktool

Din investigarea string-urilor utilizate în aplicație nu rezultă niciun posibil comportament malițios. Pentru o analiză mai exactă a tuturor stringurilor prezente în aplicație, inclusiv a celor hardcodate, am utilizat scriptul python apkstat.py care analizează conținutul stringurilor dintr-un fișier apk dat. Acesta oferă o categorisire a stringurilor pe domenii de internet găsite, posibile IP-uri, colecția întreagă de stringuri și un fișier report.txt care prezintă un raport general al acestora.

Rezultatul prezintă permisiunile cerute de AndroidManifest.xml, numărul de activități al aplicației, posibile domenii accesate de aceasta.

Din analiză rezultând că domeniile sunt rezultatul accesării serviciilor adobe și API-urilor Google pentru că aceasta necesită anumite servicii legitime preinstalate. Valoarea 1 a IP-urilor posibile este un false-positive făcând referire la o cale locală, nepericuloasă pe care o accesează aplicația.

Se poate observa și că aceasta nu încarcă nicio bibliotecă criptografică.

dex2jar

Dex2jar este un instrument folosit pentru extragerea codului Java compilat.

unzip bake_a_cake.apk

Comanda precedentă dezarhivează pachetul .apk și generează un set de fișiere. La momentul acesta pe noi ne interesează fișierul classes.dex. Acesta este generat din codul Java scris de dezvoltatori. Inițial fișierele .java sunt compilate folosind compilatorul Java javac. Acest pas generează fișierele .class. Aceste fișiere sunt procesate de instrumentul dx care creează fișierul classes.dex ce rulează în Dalvik Virtual Machine (DVM). Fișierul reprezintă un binar compilat deci nu se poate citii ca string. De aceea se utilizează utilitarul dex2jar care convertește fișierul .dex în fișier .jar. Fișierele .jar pot fi decompilate folosind orice decompilator de java, de exemplu JD-GUI.

Figura . Rezultat instrument dex2jar

Figura . Localizare JD-GUI pe Santoku

Figura . Rezultate JD-Gui

Cu toate că decompilarea a avut loc cu succes, afișarea conținutului claselor regăsite nu este suficientă cu utilitarul JD-Gui pentru deobfuscarea clasei principale ce ar trebui să conțină metoda MAIN și vom utiliza Luyten.

Pentru acest lucru, am descărcat fișierul obiect java al programului luyten. Pentru a-l rula am folosit comanda java -jar luyten.jar. Pentru a automatiza lucrurile, am creat un script lângă executabil pe care l-am adăugat în variabila PATH a mașinii virtuale, astfel

Am creat fișierul luyten, lângă luyten.jar având conținutul:

#!/bin/bash

echo ”Starting Luyten…”

java -jar /home/user/Desktop/tools/luyten.jar&

Apoi am adăugat linia următoare în fișierul ~/.bashrc:

export PATH=$PATH:/home/user/Desktop/tools

Figura . Meniu Luyten afișând clasa principală

Exporând AppEntry.class putem observa metoda apelată la crearea primei activități a aplicației. Analizând apelurile din această clasă nu se observă nici o care să ne atragă atenția. Nici celelalte clase și metode nu conțin cod ce ar putea să ne inducă un comportament malițios al aplicației.

Analiza statică a aplicației ne conduce la concluzia că aceasta nu este malițioasă.

Analiza dinamică

Analiza dinamică implică instalarea aplicației țintă pe un terminal virtual pentru a putea observa anumite tipare de funcționare și pentru a monitoriza comportamentul rețelei și analiza traficului acesteia. Analiza dinamică ajută și prin faptul că unele elemente statice pot fi greu de detectat la analiza statică din pricina eventualului cod obfuscat sau a codului nestructurat.

După ce am pornit dispozitivul virtual, am verificat conectivitatea acestuia folosind comanda adb devices care afișează emulatorul și identificatorul acestuia.

Următorul pas a fost de a instala aplicația pe dispozitiv. Acest lucru a fost făcut folosind comanda apk install bake_a_cake.apk.

Figura . Pornire dispozitiv și instalare apk cu succes

Pentru analiza traficului generat de aplicație se utilizează binarul tcpdump care este încărcat și acesta pe emulator.

Figura . Încărcare tcpdump pe emulator

Pentru rularea acestuia i se acordă drepturi de execuție fișierului și se pornește captura.

chmod 755 tcpdump

./tcpdump -v -s 0 -w packets.pcappdump

Figura . Pornire captură tcpdump

Pentru captarea pachetelor am restartat aplicația pentru a observa apelurile de inițializare și am accesat funcționalitățile acesteia. Rezultatul poate fi analizat în mașina locală folosind Wireshark, instrument disponibil în mașina Santoku.

Pentru aducerea fișierului ce conține captura pe mașina locală, folosim comanda:

adb pull /data/local/tmp/packets.tcpdump

Figure 1 Rezultate captură analiză Wireshark

Din analiza capturii wireshark se poate observa că aplicația nu încearcă să se conecteze la nici un eventual server din internet.

Concluzii

Suita de instrumente Santoku reprezintă o mașină virtuală open-source de complexitate deosebită cu un set de instrumente dedicate ce ajută la analiza securității aplicațiilor Android, atât prin metoda analizei statice, cât și dinamice.

Aceasta conține un set complex de unelte ce destinate acțiunilor de tip mobile forensics, mobile malware și mobile security.

Pe site-ul oficial al soluției este sunt prezentate și o listă de exemple de tip ”How To” pentru a explicita utilizarea diverselor instrumente prezente în mașina virtuală Santoku_05. Acest lucru este foarte important și ajută în acomodarea cu soluția.

Pentru acest exercițiu am folosit:

Android SDK Manager pentru crearea unui emulator Android

apktool

dex2jar

JD-Gui

Luyten

tcpdump

Luyten

APKStat

La momentul analizei s-a ajuns la concluzia că aplicația analizată nu este malițioasă.

AndroidTamer4

AndroidTamer4 reprezintă o platformă virtuală destinată analizei securității aplicațiilor Android.

Mediul permite o plajă largă de metode de lucru legate de securitatea Android, printre care se află analiza malware, teste de penetrare și procesul de reverse engineering asupra aplicațiilor.

Instrumentele prezente în AndroidTamer4 sunt grupate după cum urmează, conform site-ului oficial al soluției:

Instrumente personalizate: adb wrapper, apk2java, droer-checks.

Instrumente Google: Android SDK, Android NDK.

Dezvoltare: Android Studio, proguard, visualvm, gradle.

Analiza statică și dinamică: MobSF, findbug, flawfinder.

Reverse Engineering: aapt, pidcat, enjarify, apktool, jd-gui, jad, jadx, smali

Pentestig (teste de penetrare): OWASP ZAP, Burpsuite-free, w3af, nikto, nmap, sslscan, wireshark / tshark, tcpdump, skipfish, wapiti, ratproxy.

Forensic: volatility, autopsy, dc3dd, dcfldd, dff, ext4magic, scalpel, sleuthkit, exif, metcam, exiftags, exifprobe, testdisk, steghide, guymager, rdd, fatcat, foremost, Dezvoltare ROM-uri, fastboot, heimdall, flashrom.

AndroidTamer4 include în colecția de instrumente și Mobile Security Framework.

Instalare

AndroidTamer repreintă o distribuție Linux care se poate descărca în format .iso. Această imagine are o dimensiune de aproximativ 5 GB ce conține o suită de instrumente necesare analizei securității aplicațiilor Android și este preconfigurată pentru a utiliza 1.5 GB de memorie RAM.

AndroidTamer folosește la bază o distribuție de Debian pentru că aceasta conține o serie de scripturi ce simplifică procesul de analiză Android pe care trebuie să îl parcurgă un pentester.

AndroidTamer se instalează descărcând fișierul .ova de pe site-ul https://androidtamer.com/. Imaginea este compatibilă cu VirtualBox și VMware.

Pentru această cercetare științifică am folosit mediul VirtualBox pentru instalarea, configurarea și utilizarea mașinii virtuale de AndroidTamer.

La pornirea mașinii virtuale se folosesc credențialele de utilizator cu numele android și parola tamer.

Utilizare

Figura . Android Tamer – fereastra principală

În figura Figura 5.45 se pote observa fereastra principală AndroidTamer4. Pe aceasta este reprezentat modelul după care sunt organizate instrumentele prezente pe mașină și faptul că acestea sunt intuitiv grupate pentru a ajuta analistul în procesul de verificare a unei aplicații.

Se poate observa în meniul AndroidTamer4 faptul că acesta conține și utilitarul MobSF (Mobile Security Framework) configurat pentru a putea fi executat împreună cu celelalte instrumente.

Figura . AndroidTamer – MobSF

În figura Figura 5.46 este reprezentată soluția MobSF prezentă pe AndroidTamer4. Cele trei opțiuni permit automatizarea proceselor de:

Setare dispozitiv. Prin accesarea opțiunii MobSF Setup Device se procedează ca în cazul descris la crearea emulatorului pentru Mobile Security Framework. La accesarea acestei opțiuni, sunt cerute IP-ul și port-ul setate pentru testare pe emulator. În acest caz am folosit același emulator Android utilizat și pentr MobSF.

Pornire server. Opțiunea MobSf Start Server pornește serverul ce poate fi accesat din browser-ul local pe localhost, portul setat automat fiind 3000.

Accesare interfață utilizator. MobSF Start UI pornește browserul, acesând direct adresa localhost pe port-ul 3000.

Chiar dacă este folosit emulatorul Android configurat în prealabil, la fel ca în cazul MobSF, AndroidTamer4 trebuie executat ca sistem de operare principal pe un sistem de calcul deoarece soluția MobSF nu poate accesa în cadrul analizei dinamice aplicațiile pe un emulator dintr-o altă mașină virtuală.

Celelalte instrumente se pot accesa din linia de comanda a terminalului sau, în cauzul unora, folosind interfața utilizator pusă la dispoziție.

Exemplu analiză .apk

Pentru acest exercițiu am folosit aplicația diva-beta.apk utilizată și în cazul analizei folosind soluția Mobile Security Framework.

Pentru testarea aplicației, având AndroidTamer4 instalat drept mașină virtuală, am folosit dispozitivul personal pentru testare.

Figura . Analiza AndroidTamer4 – diva-beta.apk

Pentru analiza aplicației am conectat dispozitivul xiaomi Redmi note 3 Pro, conform figurii Figura 5.47 la emulator, am verificat faptul că există conexiunea, așa cum se poate observa și în terminalul din partea stângă a imaginii. Apoi am instalat pe terminal aplicația diva-beta.apk, așa cum poate fi observat în terminalul din dreapta-jos a imaginii, folosind comanda:

adb install diva-beta.apk

Aplicația este pregătită.

Primul pas în descoperirea vulnerabilităților unei aplicații este analiza statică ce presupune inversarea aplicației. Aplicația conține un set de provocări ce vor necesita citirea codului inversat. Pentru acest lucru este necesară obținerea fișierelor .java folosind Dex2Jar și JD-GUI pentru citirea acestuia.

În continuare voi ține cont de cele menționate și voi încerca să rezolv provocările aplicației.

Logarea nesigură

Figura . Obținerea fișierului java folosind Dex2Jar

Conform figurii Figura 5.49 se poate observa utilizare scriptului dex2jar pentru obținerea din fișierul .apk a surselor .java.

Prima provocare presupune observarea codului care face logarea aplicației. Acest lucru poate fi observat în figura Figura 5.49 și folosind comanda în AndroidTamer cu dispozitivul fizic conectat la mașina virtuală: adb logcat.

După cum se poate observa în cod, putem determina faptul că codul este vulnerabil din punctul de vedere al logării datelor deoarece în aplicație sunt stocate informațiile legate de datele introduse de la tastatură, în acest caz informații importante despre un card de credit.

Figura . AndroidTamer4 – Provocarea 1

Probleme de hardcodare date sensibile – partea întâi

Pentru această provocare este necesar să verificăm codul aplicației. Putem observa în figura Figura 5.51. faptul că verificarea datelor introduse drept cheie de acces sunt hardocate folosind string-ul ”vendorsecretkey”. Acesta permite accesul și, astfel, provocarea este depășită.

Figura .AndroidTamer4 – Provocarea 2

Figura . AndroidTamer4 – Vulnerabilitate cauzată de date sensibile hardcodate

Stocarea nesigură a datelor – partea întâi.

Folosind JD-GUI, putem observa metoda saveCredentials. Uitându-ne la codul acestei funcții în figura Figura 5.53., putem observa că aplicația folosește opțiunea Android de salvare a datelor în obiectul SharedPreferences.

Figura . AndroidTamer – codul metodei savedCredentials

În cotinuare vom folosi adb shell pentru a parcurge sistemul de fișiere pe dispozitiv. Analizând AndroidManifest.xml putem observa că numele pachetului aplicației este jakhar.aseem.diva.

Așadar, pentru accesarea SharedPreferences, trebuie să citim fișierul jakhar.aseem.diva_preferences.xml prezent în locația /data/data/jakhar.aseem.diva_preferences din dispozitiv.

În figura Figura 5.55 se poate observa cum datele introduse la provocarea 3 sunt salvate în mod clar în fișierul destinat apicației.

Figura . AndroidTamer4 – vulnerabilitate SharedPreferences

4. Stocarea nesigură a datelor – partea a doua

Pentru acest exercițiu vom introduce niște date secrete, la fel ca în exercițiul precedent. Așadar datele introduse vor fi SECRET și SECRET și se dorește analiza locației în care vor fi salvate datele și dacă acestea pot fi recuperate.

Analizând codul ajungem la concluzia că aplicația folosește interogări SQL neprocesate de date.

Figura . AndroidTamer4 -rezultatele găsite în baza de date a aplicației cu datele introduse la provocarea 4

Stocarea nesigură a datelor – partea a treia

Figura . AndroidTamer4 – metoda a treia de salvare a datelor

Analizând codul din figura Figura 5.59 folosind JD-GUI putem observa că aplicația folosește un fișier temporar de salvare a datelor.

Figura . AndroidTamer4 – Provocarea 5 – vulnerabilitate în stocarea datelor sensibile

Stocarea nesigură a datelor – partea a patra

Pentru acest exercițiu urmărim în continuare, folosind JD-GUI, clasa InsecureDataStorage4Activity.class pentru a afla codul sursă reprezentat în dreapta imaginii din Figura 5.61 pentru funcția saveCredențials. Urmărind codul acestei funcții, putem observa cum aplicația stochează informațiile sensibile într-un fișier pe memoria externă a dispozitivului. Fișierul are denumirea hardcodată în metodă uinfo.txt.

Figura . Verificare fișier informații sensibile

Pentru ca acțiunea să aibă loc cu succes, aplicația trebuie să primească permisiunea de a scrie pe memoria externă în prealabilul acestui exercițiu. În figura Figura 5.62 se observă cum aplicația nu poate observa existența fișierului pentru că aplicației nu îi este permis să îl scrie pe memoria externă. Apoi, o problemă secundară ar fi fost faptul că fișierul era scris cu prefixul ”.” care în linux face ca comanda simplă ls să nu poată să îl afișeze decât în mod explicit. În final, s-a ajuns la faptul că fișierul a fost scris și informațiile sensibile aflate.

Probleme de validare pentru datele de intrare – partea întâi.

Ecranul provocării șapte prezintă posibilitatea introducerii unui nume de utilizator drept input în aplicație. Acest lucru ne face să ne gândim la faptul că acel utilizator ar putea fi căutat într-o bază de date și că aceaasta ar putea fi exploatată prin interogări SQL.

Pentru a observa dacă pista aceasta de lucru este una corectă, vom folosi comanda în AndroidTamer4

adb logcat | grep -I sql

și vom monitoriza interogările pe această aplicație.

Pentru testare am introdus ca date de intrare semnele ‘” și am putut observa în logcat următoarea informație:

06-06 13:14:48.025 27194 27194 D Diva-sqli: Error occurred while searching in database: unrecognized token: ""'" (code 1): , while compiling: SELECT * FROM sqliuser WHERE user = ''"'

Acest lucru înseamnă că aplicația este vulnerabilă la SQL Injection și, în continuare, vom încerca tehnicile clasice de injectare de tip always-true.

Conform figurii Figura 5.62. se poate observa că prin introducerea ca date de intrare a formulei 1’ or ‘1’ != ‘2 se ajunge la extragerea unor date neașteptate și foarte importante din aplicație. Acest lucru se datorează neglijenței interogărilor SQL.

Probleme de validare pentru datele de intrare – partea a doua.

Această provocare presupune analiza codului și observarea faptului că aplicația accesează un anume URL introdus de utilizator fără ca acesta să fie validat în vreun fel. Pentru acest lucru am citit metoda descrisă în figura de mai sus folosind JD-GUI și am accesat URL-ul http://www.google.com în prealabil pentru a observa cum funcționează aplicația. Prin intermediul acestei căsuțe de intrare am verificat dacă se poate ca aplicația să aibă acces la alte date de pe dispozitiv. Pentru acest lucru, am utilizat fișierul deja creat pe sdcard în pasii precedenti .uinfo.txt. Se poate observa în figura Figura 5.65 că metoda a citit conținutul fișierului și l-a afișat pe ecran.

Probleme în controlul de acces – partea întâi.

Figura . AndroidTamer4 – Probleme în controlul accesului partea întâi

În figura Figura 5.65 se poate observa cum aplicația afișează anumite credențiale legate de dezvoltator și se cere extragerea acestora în mod analitic direct din aplicație, fără accesarea butonului de afișare.

Pentru acest lucru vom analiza fișierul AndroidManifest.xml.

Folosind apktool, utilitar prezent în AndroidTamer4, putem ajunge la respectivul fișier.

apktool d diva-beta.apk

cat diva-beta/AndroidManifest.xml

<activity android:label=”@string/apic2_label” android:name=”jakhar.aseem.diva.APICreds2Activity”>

<intent-filter>

<action android:name=”jakhar.aseem.diva.action.VIEW_CREDS2″/>

<category android:name=”android.intent.category.DEFAULT”/>

</intent-filter>

</activity>

Se poate observa prin această activitate că este într-un intent de tip protected. Fiind tratat ca un protected deoarece când este utilizat în acest mod, intentul este exportat în mod public . Așadar, activitatea este vulnerabilă, fiind accesibilă de către oricare altă aplicație din exterior.

Figura . AndroidTamer4 – Pornire activitate din linie de comandă

Probleme în controlul accesului – partea a doua.

Figura . AndroidTamer4 – Probleme în controlul accesului – partea a doua

Din nou, accesând butonul VIEW TVEETER API CREDENTIALS vom observa credențialele care apar în imaginea Figura 5.67 în partea dreaptă. Cerința acestei provocări este de a afla acele informații sensibile indirect față de utilizarea acestui buton.

Pentru acest lucru, se analizează din nou AndroidManifest.xml din care se poate extrage codul:

<activity android:label=”@string/apic2_label” android:name=”jakhar.aseem.diva.APICreds2Activity”>

<intent-filter>

<action android:name=”jakhar.aseem.diva.action.VIEW_CREDS2″/>

<category android:name=”android.intent.category.DEFAULT”/>

</intent-filter>

</activity>

Folosind comanda adb shell am start -n jakhar.aseem.diva/.APICreds2Activity -a jakhar.aseem.diva.action.VIEW_CREDS vom ajunge la figura Figura 5.68.

Acest lucru ne conduce la faptul că este un caz special față de cel discutat anterior. Pentru acest lucru vom analiza codul sursă al aplicației.

Analizând codul APICreds2Activity.java cu ajutorul JD-GUI prezent în AndroidTamer4, ajungem la concluzia că este folosită o variabilă booleană înainte de afișarea credențialelor.

Figura . Codul sursă pentru APICreds2Activity.java

Pentru aflarea valorii acestui string se verifică fișierul cu conținutul de string-uri din aplicație. Deoarece aplicația a fost deja dezasamblată folosind apktool, se accesează direct fișierul de string-uri ce se află în locația: /app/src/main/res/values/strings.xml. Înainte de verificarea credențialelor, codul verifică dacă utilizatorul este deja înregistrat sau nu. Acest lucru e face prin variabila booleană chk_pin prezentă în fișierul strings.xml.

Aașadar se va încerca compromiterea acestui pas folosind comanda:

Prin opțiunea –ez se poate executa un intent aplicând valoarea unui string ca input, în acest caz check_pin este executat ca fiind fals

Probleme în controlul accesului – partea a treia.

Figura . AndroidTamer4 – probleme în controlul accesului – partea a treia

Această provocare presupune crearea unui pin de acces la anumite notite private. După ce acesta este creat, utilizatorului îi este permis accesul către notitele respective folosind codul proaspăt introdus.

Scopul este de a accesa notițele respective fără a fi nevoie de introducerea codului PIN de verificare. Analizând AndroidManifest.xml observăm că este înregistrat un furnizor de conținut (content provider) care este exportat în mod explicit.

<provider android:authorities=”jakhar.aseem.diva.provider.notesprovider” android:enabled=”true” android:exported=”true” android:name=”jakhar.aseem.diva.NotesProvider”/>

Furnizorii de conținut sunt reprezentați de adrese URI care încep cu //. Așadar, trebuie aflată calea pentru accesul la aceste notițe.

Pentru acest lucru, parcurgem folderele extrase cu ajutorul apktool din diva-beta.apk.

Figura . AndroidTamer4 – provocarea 11, aflarea locației furnizorului de conținut

Conform figurii Figura 5.71 se poate observa că fișierul conținut este NotesProvider. Pentru aflarea notițelor se utilizează comanda adb shell precum în figura Figura 5.72.

Figura . Androidtamer4 – interogarea de conținut folosind adb shell

Probleme de hardcodare date sensibile – partea a doua

Figura . AndroidTamer4 – probleme de hardcodare partea a doua

Această provocare cere introducerea unui cod de acces în aplicație. Analizând codul din figura Figura 5.73 observăm că djni, care este un obiect de tip DivaJni este utilizat pentru accesul dorit. Așadar, trebuie să analizăm clasa DivaJni pentru a continua investigația.

Clasa DivaJni este încărcată la rândul ei împreună cu aplicația. Bibliotecile care vin împreună cu fișierul .apk sunt încărcate la rândul lor.

Realizând despachetarea aplicației cu ajutorul comenzii

unzip diva-beta.apk

Din despachetarea fișierului .apk se ajunge la următoarea colecție de fișiere și directoare: AndroidManifest.xml, META-INF, classes.dex, diva-beta.apk, lib, res, resources.arsc.

Se parcurge folderul lib în căutarea unei librării care să aibă sens pentru denumirea DivaJni și se ajunge la libdivajni.so.

Pentru analiza acesteia și determinarea unui string de intrare în activitatea pe care dorim să o exploatăm, aplicăm următoarea comandă asupra librăriei:

strings libdivajni.so

Analizând rezultatele, se pot încerca câteva variante pentru accesul dorit și se va ajunge la string-ul olsdfgad;lh ca fiind valoarea dorită a fi inserată în aceasta.

Probleme în controlul accesului – partea a doua.

Printr-o serie de încercări, am ajuns la concluzia că aplicația răspunde cu mesajul Acces Denied în cazul în care string-ul introdus este mai mic decât 20 de caractere. Pentru mai mult de 20 de caractere, aplicația este susceptibilă pentru buffer overflow, afișând mesaj de eroare și închizându-se.

Am încercat să analizez log-urile de sistem pentru a observa cum decurge eroarea provocată de string-ul de mai mult de 20 de A-uri inserat și am putut observa Figura 5.76.

Concluzia care se poate extrage din acest exercițiu este că aplicația permite atacul de tip buffer overflow, fapt datorat neverificării stringului introdus ce creează și eroarea care închide aplicația.

Limitări

Prin utilizarea și analiza acestor intstrumente de analiză am ajuns la o serie de limitări ce trebuie menționate:

analiza aplicațiilor pe dispozitivele emulate durează mai mult și poate fi limitată de resursele fizice de care dispune calculatorul de pe care este realizată

pentru analiza aplicațiilor iOS este necesar un desktop sau laptop pe care rulează sistemul de operare macOS. Nu pot fi analizate aplicațiile iOS pe un sistem Linux sau Windows.

pentru analiza aplicațiilor iOS în mod dinamic este necesar un dispozitiv iPhone, iPad sau iPod

pentru analiza aplicațiilor iOS, dispozitivul fizic existent pe care este necesară execuția acestora necesită, în cele mai multe cazuri, existența unui jailbreak

pentru execuția diverselor comenzi sau instrumente de analiză asupra unor aplicații Android, este necesar ca pe dispozitivul țintă să fie rootat

în cazul dispozitivelor Android, două versiuni foarte asemănătoare ale unui dispozitiv pot da rezultate diferite prin faptul că producătorii și dezvoltatorii au acces direct la cod și există o multitudine de componente hardware diferite

instrumentele de tip open-source nu oferă nicio garanție juridică pentru rezultatele oferite și aceste rezultate trebuie utilizate doar ca un indicator

instrumentele de tip open-source nu oferă întotdeauna rezultate de încredere sau corecte, de aceea este necesară utilizarea acestora cu o anumită precauție

Concluzii

Contribuții

În proiectul ales, Analiza securității aplicațiilor pe dispozitive mobile, am cercetat literatura de specialitate analizând succint cele mai populare modele arhitecturale ale sistemelor de operare din domeniul dispozitivelor mobile, Android și iOS, atât prin lucrările publicate oficial de firmele Apple pentru iOS și Google pentru Android, cât și cercetând materialele publicate și acceptate de IEEE sau cărți de marcă din domeniu precum iOS Application Security – The Definitive guide for Hackers and Developers sau Mobile Device Exploitation Cookbook.

Scopul acestei lucrări a fost de a cerceta securitatea sistemelor de operare pentru dispozitivele mobile, înțelegerea fluxului de lucru al unei aplicații aparținând sistemelor respective și metodele prin care un utilizator, prin intermediul unei aplicații, își poate compromite date sensibile sau ar putea fi afectat în diverse feluri. Totodată, prin examinarea practică a mai multor instrumente de analiză a aplicațiilor s-a înfăptuit realizarea unei platforme integrate folosind aceste soluții.

Conform diverselor statistici și analize avute în vedere și în acest proiect, este foarte clară importanța și necesitatea securității pentru aplicațiile prezente pe dispozitivele mobile. La momentul actual, puterea de calcul a unui telefon inteligent se află la un nivel foarte ridicat și continuă să crească. Prin acțiunile importante pe care le putem exercita folosind diverse aplicații, de la gestiunea afacerilor, diverselor baze de date aflate în cloud, la transferuri bancare și plăți online, se constată, din păcate, că securitatea acestora nu este realizată întocmai cum ar trebui și că zilnic apar noi atacuri și posibilități de exploatare a diverselor aplicații sau vulnerabilități ale sistemelor de operare. Acest lucru este cauzat din neglijența sau nepriceperea programatorilor și dorința de a realiza tot mai multe lucruri funcționale într-un timp cât mai scurt, fără a mai trece codul executabil prin diverse teste de securitate.

Lucrarea a fost structurată în două părți. Prima direcție a fost reprezentată de cercetarea domeniului. Pentru acest lucru a fost realizată analiza securității sistemelor de operare Android și iOS, descrierea părților bune și rele ale arhitecturii acestora, expunerea diferențelor legate de faptul că Android este un sistem de operare de tip open-source, în timp ce iOS este unul de tip black-box și structura și fluxul de instalare și execuție ale aplicațiilor destinate fiecăruia, precum și mecanismele de securitate implementate la nivelul acestora. Tot în direcția de cercetare au fost cercetate tipurile de malware ce pot afecta un dispozitiv mobil, cum a fost realizată trecerea de la malware pe un calculator personal la dispozitive portabile, evoluția și modalitățile prin care acestea ajung să infecteze un utilizator.

Cea de-a doua direcție a reprezentat descoperirea și utilizarea de unelte de tip open-source ce pot ajuta la analiza securității aplicațiilor pe dispozitive mobile. Aceată parte a constat în studierea soluțiilor existente, testarea acestora și concluzionarea printr-o colecție tip laborator virtual care ajută la stabilirea dacă o aplicație mobilă este sau nu sigură, adică dacă este susceptibilă la un atac sau dacă reprezintă în sine un atac.

Pentru acest lucru s-au folosit instrumentele:

Clutch 2.0. Clutch este un instrument de decriptare pentru aplicațiile iOS de pe un dispozitiv.

class-dump-z. Acesta este un utilitar în linie de comandă care permite examinarea segmentelor Object-C din fișierele Mach-O. Acesta generează declarații ale claselor, categoriilor și protocoalelor.

otool. Este un instrument ce afișează conținutul diverselor fișiere obiect sau biblitoeci. Acesta înțelege formatul fișierelor Mach-O și formatele fișierelor universale.

objection. Acesta este un set de instrumente ce ajută la exploatarea sistemului iOS în timpul execuției

PassionFruit. Este un instrument complex destinat analizei automate a aplicațiilor black-box iOS.

Mobile Security Framework. Aceasta reprezintă o soluție complexă de analiză automată a fișierelor .apk ce reprezintă arhivele aplicațiilor Android și fișierelor .ipa ce reprezintă arhivele aplicațiilor iOS.

Santoku_0.5. Acesta reprezintă o platformă open-source dedicată analizei aplicațiilor pe dispozitive mobile. Aceasta este o distribuție de Linux ce are integrate un set de tooluri cu rolul de a realiza operații de forensics pe dispozitivele mobile, cât și analiza și securitatea aplicațiilor mobile.

AndroidTamer4. AndroidTamer reprezintă o platformă virtuală destinată analizei securității aplicațiilor Android. Mediul permite o plajă largă de metode de lucru legate de securitatea Android, printre care se află analiza malware, teste de penetrare și procesul de reverse engineering asupra aplicațiilor.

Totodată, testarea și analiza aplicațiilor a necesitat utilizarea unui hipervizor pentru mașinile virtuale ce conțin instrumentele și pentru emulatoarele pe care s-au realizat testele. Pentru mașinile virtuale de Linux a fost utilizat Oracle VM Virtualbox, un hipervizor gratuit și open-source, iar pentru emulatoarele de Android a fost utilizat Genymotion ce funcționează în strânsă legătură cu Virtualbox. Dispozitivul fizic utilizat în teste este Xiaomi Redmi Note 3 Pro ce folosește Android Oreo.

Direcții viitoare

Lucrarea a avut ca scop cercetarea securității sistemelor de operare mobile și a securității aplicațiilor acestora prin utilizarea diverselor tipuri de instrumente de tip free și open-source existente pe internet.

Pentru îmbunătățirea domeniului securității aplicațiilor mobile sunt necesare:

documentarea continuă în legătură cu aceste sisteme de operare, atât prin actualizări de soft, patchuri de securitate sau adăugarea de noi caracteristici

continuarea procesului de actualizare, salvare și gestionare a cunoștințelor în funcție de amenințările ce apar treptat prin noi breșe de securitate, aplicații malware sau diverse atacuri ce vor fi descoperite

conturarea unui laborator virtual de analiză a securității aplicațiilor mobile care să conțină instrumentele cu randamentul și precizia cele mai bune. În acest sens trebuie urmărite și testate noi unelte și actualizările celor vechi.

dezvoltarea laboraturlui virtual pentru a putea fi posibilă analiza securității aplicațiilor iOS. Pentru acest lucru sunt necesare existența unui instrument de calcul pe care să ruleze macOS și un dispozitiv real pe care să ruleze iOS.

extinderea domeniului de analiză pentru toate sistemele de operare mobile precum Windows Phone sau Blackberry.

cercetarea algoritmilor și soluțiilor existente în domeniul securității mobile, bazate pe inteligență artificială, în vederea includerii acestora într-un flux permanent de analiză de noi aplicații

Bibliografie

[1] ZACHARY DAVIES BOREN, 7 Octombrie 2014,  There are officially more devices than people in this world,   Sursa: https://www.independent.co.uk/life-style/gadgets-and-tech/news/there-are-officially-more-mobile-devices-than-people-in-the-world-9780518.html

[2] Joe Rossignol, 22 Februarie 2018, iPhone and Android Duopoly Nears Peak With Estimated 99.9% Market Share Last Year; Sursa: https://www.idc.com/promo/smartphone-market-share/os

[3] https://www.appannie.com/en/insights/market-data/app-downloads-consumer-spend-q4-2017/

[4] SANS Institute, Ianuarie 2003, Operating System Security and Secure Operating Systems. Sursa: https://www.giac.org/paper/gsec/2776/operating-system-security-secure-operating-systems/104723

[5] Sursa: https://en.wikipedia.org/wiki/Protection_ring#/media/File:Priv_rings.svg

[6] Security Architecture and Design, (2010), Sursa: http://cdn.ttgtmedia.com/searchSecurityChannel/downloads/CISSP+Study+Guide+_Chapt6.pdf

[7] Sursa: https://source.android.com/security/images/permissions_check.png

[8] Sursa: https://source.android.com/devices/images/ape_fwk_all.png

[9] Sursa: https://www.apple.com/business/docs/iOS_Security_Guide.pdf

[10] iOS Security Guide, Ianuarie 2018, iOS Security – iOS 11

[11] David Thiel, 2016, iOS Application Security – The Definitive guide for Hackers and Developers

[12] Sarah Abraham, August 2016, iOS Anathomy

[13] Allister Banks, Charles S. Edge, 2015, Learning iOS Security

[14] Prashant Verma, Akshay Dixit, 2016, Mobile Device Exploitation Cookbook

[15] Trend Micro, Februarie 2012, A brief History of Mobile Malware

[16] John-Paul, Aprilie 2018, Maliciously Mobile: A Brief History of Mobile Malware

[17] Sursa: ” https://securingtomorrow.mcafee.com/wp-content/uploads/2017/11/20171109-Grabos-5.png”

[18] Carlos Castillo, Noiembrie 2017, New Android Malware Found in 144 GooglePlay Apps

[19] McAfee, 2018, McAfee Mobile Threat Report Q1. Sursa: https://www.mcafee.com/us/resources/reports/rp-mobile-threat-report-2018.pdf

[20] Nokia, 2017, Nokia Threat Intelligence Report – 2017

[21] Symantec, 2018, Types of Common Mobile threats and What They Can Do to Your Phone

[22] Kaspersky, 2017, Android Mobile Security Threats

[23] Claud Xiao, Martie 2016, AceDeceiver: First iOS Trojan Exploiting Apple DRM Design Flaws to Infect Any iOS Device

[24] Kaspersky, Aprilie 2017, Pegasus: the ultimate spyware for iOS and Android. Sursa: https://www.kaspersky.com/blog/pegasus-spyware/14604/

[25] Carsten Willems, Thorsten Holz, December 2013, Toward Automated Dynamic Malware Analysis Using CWSandbox

[26] Kaspersky Lab, 2017, Machine Learning for Malware Detection

[27] Sursa: http://oi60.tinypic.com/15q2ici.jpg

[28] Sursa: https://github.com/sensepost/objection/blob/master/images/ios_ls.png

[29] Sursa: https://github.com/chaitin/passionfruit/blob/master/images/metainfo.png

[30] http://2we26u4fam7n16rz3a44uhbe1bq2-wpengine.netdna-ssl.com/wp-content/uploads/040918_1853_AndroidPene14.png

[31] AndroidTamer, Learn Android Security, Sursa: https://androidtamer.com/learn_android_security