This repository has been archived by the owner on Jul 27, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathtesi.tex
2213 lines (1914 loc) · 170 KB
/
tesi.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
\documentclass[12pt,a4paper,oneside]{article}
\usepackage[left=3.5cm,top=3cm,right=2.5cm,bottom=3.5cm]{geometry}
\usepackage[english,italian]{babel}
\usepackage[usenames,dvipsnames,svgnames,table]{xcolor}
\usepackage{colortbl}
\usepackage{setspace}
\setstretch{1.35}
\usepackage{mathtools}
\usepackage[overload]{empheq}
\usepackage{amssymb}
\usepackage[bottom,marginal]{footmisc}
\setlength{\footnotemargin}{1.525em}
\usepackage[hidelinks]{hyperref}
\hypersetup{linktoc=all}
\usepackage{footnotebackref}
\usepackage{tablefootnote}
\usepackage[english,italian,nameinlink,capitalize]{cleveref}
\crefname{algocf}{algoritmo}{algoritmi}
\usepackage{graphicx}
\usepackage{tikz}
\usetikzlibrary{shapes,arrows,positioning}
\usepackage{pgfplots}
\pgfplotsset{compat=newest}
\usepackage{multirow}
\usepackage{array}
\usepackage{longtable}
\usepackage{calc}
\usepackage[hypcap=true,labelformat=simple]{subcaption}
\renewcommand\thesubfigure{(\alph{subfigure})}
\usepackage[algoruled,nofillcomment,vlined]{algorithm2e}
\usepackage{fancyhdr}
\pagestyle{fancy}
\fancyhf{}
\renewcommand{\headrulewidth}{0pt}
\fancyfoot[R]{\thepage}
\usepackage[nopostdot,nonumberlist]{glossaries}
\makeglossaries
\bibliographystyle{IEEEtran}
\author{Georgiu Gabriel Claudiu}
\title{RiskInDroid: analisi del rischio di applicazioni Android}
\newacronym{API}{API}{Application Programming Interface}
\newacronym{CVE}{CVE}{Common Vulnerabilities and Exposures}
\newacronym{CVSS}{CVSS}{Common Vulnerability Scoring System}
\newacronym{IDE}{IDE}{Integrated Development Environment}
\newacronym{IPC}{IPC}{Inter Process Communication}
\newacronym{NVD}{NVD}{National Vulnerability Database}
\newacronym{SVM}{SVM}{Support Vector Machines}
\newacronym{URL}{URL}{Uniform Resource Locator}
\begin{document}
\selectlanguage{italian}
\pagenumbering{Roman}
\thispagestyle{empty}
\begin{spacing}{1.3}
\begin{center}
\noindent\makebox[\textwidth][c]{\Large\bf UNIVERSITÀ DEGLI STUDI DI GENOVA}
\noindent\makebox[\textwidth][c]{\large\bf Facoltà di Ingegneria}
\begin{figure}[!htb]
\centering
\includegraphics[height=30mm]{resources/logo.png}
\end{figure}
\begin{minipage}[!htb]{\textwidth}
\begin{singlespace}
\begin{center}
{\itshape Corso di Laurea Magistrale in Ingegneria Informatica}
\end{center}
\end{singlespace}
\end{minipage}
\noindent\hrulefill\\
\vfill
\noindent\makebox[\textwidth][c]{
\begin{minipage}[!htb]{.9\textwidth}
\begin{center}
{\LARGE\scshape RiskInDroid: analisi del rischio di applicazioni Android}
\end{center}
\end{minipage}}
\end{center}
\vfill
\noindent\begin{minipage}[t]{\textwidth-5.9cm}
\textit{Relatore:}
\begin{singlespace}
\textbf{Prof. Alessio MERLO}\\
\end{singlespace}
\end{minipage}%
\noindent\begin{minipage}[t]{5.8cm}
\textit{Candidato:}
\begin{singlespace}
\textbf{Gabriel Claudiu GEORGIU}\\
Matricola n. 3618343
\end{singlespace}
\end{minipage}%
\vspace{2cm}
\begin{center}
\noindent\hrulefill\\
\noindent\makebox[\textwidth][c]{Anno Accademico $2015 - 2016$}
\end{center}
\end{spacing}
\newpage
\selectlanguage{italian}
\begin{spacing}{1.6}
\setglossarystyle{altlist}
\printglossary[type=\acronymtype,title={Simboli e abbreviazioni}]
\end{spacing}
\newpage
\tableofcontents
\newpage
\listoffigures
\newpage
\listoftables
\newpage
\pagenumbering{arabic}
\section{Introduzione}\label{sec:Introduzione}
Con quasi $300$ milioni di smartphone venduti solamente nel secondo trimestre del $2016$ \cite{GARTNER}, Android risulta essere il sistema operativo per dispositivi mobili più diffuso al mondo e, di conseguenza, anche un bersaglio appetibile per gli autori di \textit{malware}, i quali possono sfruttare la sua popolarità per mettere in pericolo la privacy di milioni di utenti. È pertanto necessario prestare particolare attenzione agli aspetti di sicurezza legati alla piattaforma Android.
Con lo scopo di rendere l'utenza più consapevole del rischio in cui si incorre installando determinate applicazioni, questa tesi si prefigge l'obiettivo di proporre un metodo per l'analisi quantitativa del rischio delle app Android, volto a ricavare un punteggio numerico corretto ed affidabile che indichi quanto una certa app possa essere rischiosa. Dopo aver valutato due metodologie che si sono rivelate inadatte per una affidabile valutazione del rischio, viene ideato e proposto un nuovo metodo, denominato RiskInDroid, che si basa su tecniche di \textit{machine learning} per costruire un modello di rischio partendo da un ampio campione statistico raccolto specificatamente per questo lavoro di laurea, costituito da $116~541$ applicazioni benigne e $6~707$ \textit{malware}. Il funzionamento di RiskInDroid si fonda su un'analisi estensiva dei permessi delle applicazioni Android, e non soltanto sui permessi dichiarati (come nella maggior parte degli altri lavori scientifici), ma anche su quelli realmente utilizzati, richiesti ma non usati e infine utilizzati senza essere stati prima dichiarati.
Sebbene la letteratura scientifica che tratta argomenti riguardanti la sicurezza di Android sia molto vasta, finora si è focalizzata maggiormente sulla classificazione binaria di \textit{malware} e non sono presenti molti lavori incentrati sulla creazione di un indice di rischio quantitativo. Le metodologie basate sulla classificazione binaria hanno il limite intrinseco di non poter fornire alcun valore quantitativo riferito alla pericolosità di un'app; per quanto riguarda invece le tecniche già proposte per la valutazione del rischio, alcune non sono applicabili in generale perché necessitano di conoscere la categoria di appartenenza dell'applicazione \cite{ROTARU,CATEGORICAL_RISK}, mentre in altri casi i valori di rischio non sono facilmente confrontabili perché non è stato fissato un intervallo limitato entro cui far variare tali valori \cite{WANG_QUANTITATIVE}. RiskInDroid, il metodo proposto in questa tesi, prende spunto dalle metodologie basate sulla classificazione binaria di \textit{malware}, integrando però le intuizioni più interessanti presenti nelle pubblicazioni riguardanti l'analisi di rischio delle applicazioni. In questo modo si ottiene un approccio applicabile in maniera generale e un indice di rischio facilmente interpretabile e confrontabile con gli indici di rischio di altre app, superando dunque le limitazioni dei metodi proposti finora.
Per quanto riguarda la realizzazione pratica di RiskInDroid, si è deciso di impiegare il linguaggio di programmazione Python, scelta dettata soprattutto dalla volontà di utilizzare la libreria \mbox{\textit{scikit-learn}}~\cite{SCIKIT}, che implementa le tecniche di \textit{machine learning} necessarie al funzionamento di RiskInDroid. Una volta completato lo sviluppo e dopo aver valutato empiricamente l'efficacia del metodo, RiskInDroid è stato integrato come componente di Approver \cite{APPROVER}, un \textit{tool} professionale per l'analisi completa delle applicazioni mobili sviluppato da Talos S.r.l.s (\url{http://www.talos-security.com/}) in collaborazione con il Computer Security Lab del dipartimento DIBRIS dell'Università di Genova.
\subsection{Organizzazione della tesi}
La tesi è organizzata secondo l'ordine cronologico di svolgimento: si inizia con una presentazione complessiva del lavoro che si intende compiere, si prosegue illustrando metodologie e strumenti impiegati per concludere infine con l'analisi e il commento dei risultati ottenuti, indicandone eventuali sviluppi futuri.
La \hyperref[sec:Introduzione]{Sezione introduttiva} offre una panoramica generale sugli argomenti trattati in questa tesi ed espone gli obiettivi prefissati.
La \cref{sec:Android} presenta in maniera sintetica l'architettura del sistema operativo Android, con particolare attenzione al meccanismo di sicurezza basato sull'utilizzo di permessi e menzionando i principali canali di distribuzione delle app.
La \cref{sec:Stato_arte} mostra i risultati più importanti ottenuti finora dalla comunità scientifica nell'ambito della classificazione binaria di \textit{malware} e dell'analisi quantitativa del rischio delle applicazioni Android. Viene inoltre brevemente descritta la libreria di Python che implementa le tecniche di \textit{machine learning} adoperate nel corso della tesi.
Nella \cref{sec:Metodologia} viene esposta nel dettaglio la metodologia adottata in questo elaborato di laurea: inizialmente viene proposto un approccio per l'analisi del rischio delle applicazioni basato sull'elenco \acrshort{CVE}, che si rivela tuttavia poco funzionale; si valutano pertanto due ulteriori metodi, il secondo dei quali, denominato RiskInDroid, ha un carattere innovativo e risulta efficace nell'utilizzo pratico.
La \cref{sec:Risultati} riporta i risultati ottenuti sperimentalmente applicando il metodo RiskInDroid su un campione statistico costituito da oltre $100~000$ applicazioni Android. Le app valutate con un indice di rischio elevato vengono successivamente analizzate con una suite di antivirus online per determinarne la reale pericolosità.
Nella \hyperref[sec:Conclusioni]{Sezione conclusiva} vengono fatte alcune considerazioni sui risultati ottenuti durante lo svolgimento della tesi, illustrando infine alcuni spunti per proseguire ulteriormente il lavoro iniziato in questo elaborato di laurea.
\newpage
\section{Ecosistema Android}\label{sec:Android}
Android è un sistema operativo per dispositivi mobili \textit{open source} basato su \textit{kernel} Linux, sviluppato da Google e dall'Open Handset Alliance. È composto da un'architettura a più livelli di astrazione\footnote{\url{http://developer.android.com/guide/platform/index.html}}, come visibile in \cref{fig:android_stack}.
\begin{figure}[!htb]
\centering
\includegraphics[height=16cm]{resources/images/android_stack.png}
\caption{Architettura a livelli della piattaforma Android}\label{fig:android_stack}
\end{figure}
\noindent In cima allo \textit{stack} dell'architettura di Android si trovano le \textbf{applicazioni di sistema} che offrono le funzionalità di base (gestione email, calendario ecc.). Al livello appena inferiore è presente il \textbf{Java \acrshort{API} framework}, che fornisce un set di componenti modulari riutilizzabili per lo sviluppo di nuove applicazioni in linguaggio Java, come ad esempio funzioni per accedere alle risorse o per mostrare notifiche nella barra di stato dell'app. Il sistema Android rende inoltre disponibile l'accesso a \textbf{librerie native} scritte in \mbox{C/C++} tramite l'impiego di Android NDK (\textit{Native Development Kit}), nel caso si vogliano ottenere prestazioni più elevate nelle operazioni che coinvolgono l'impiego di grafica $2$D e $3$D. L'\textbf{Android Runtime} è il livello dove vengono eseguite più istanze di macchine virtuali (una per ogni applicazione) ottimizzate per avere un basso consumo di risorse. In particolare, ogni macchina virtuale esegue il \texttt{DEX} \textit{bytecode} generato a partire dall'app scritta in Java. L'\textbf{Hardware Abstraction Layer} è formato da un insieme di librerie che rende possibile l'utilizzo delle risorse hardware da parte del livello superiore (Java \acrshort{API} framework). Alla base di tutta l'architettura è presente il \textbf{Kernel Linux}, che astrae l'hardware del dispositivo e fornisce funzionalità elementari, ad esempio per la gestione dei processi, della memoria o dell'\textit{\gls{IPC}}.
Il sistema operativo Android assegna ad ogni applicazione un Linux \texttt{user ID} univoco in fase di installazione della stessa. In combinazione al fatto che ogni app viene eseguita in una propria istanza di macchina virtuale, ciò contribuisce alla creazione di una \textit{sandbox} che garantisce l'isolamento di ogni applicazione installata rispetto alle altre e rispetto al sistema operativo. Android implementa dunque il principio del minimo privilegio\footnote{\url{http://developer.android.com/guide/components/fundamentals.html}}, pertanto ogni app che voglia accedere a risorse protette del dispositivo (fotocamera, memoria esterna ecc.) oppure a dati di altre applicazioni deve richiedere esplicitamente l'autorizzazione all'utente. Questo meccanismo di autorizzazione viene garantito in Android tramite l'utilizzo di permessi. Nelle versioni di Android precedenti alla $6.0$, i permessi sono richiesti in fase di installazione dell'app e l'utente deve accettarli tutti affinché l'installazione venga completata; nelle versioni successive i permessi sono invece gestiti dinamicamente (ovvero sono richiesti quando vengono utilizzati)\footnote{\url{http://developer.android.com/training/permissions/requesting.html}}.
\subsection{Sistema dei permessi in Android}
Il sistema dei permessi è uno dei principali meccanismi di sicurezza su cui si basa Android. Ogni app viene infatti eseguita in un processo isolato ed è grazie ai permessi che le vengono concessi che può accedere a specifiche risorse del sistema. I permessi sono dichiarati nel file \texttt{AndroidManifest.xml}, che contiene anche altre informazioni fondamentali riguardanti l'applicazione come il ad esempio il suo nome, le versioni di Android compatibili e tutti i componenti presenti nell'app. Al momento della stesura della tesi, il sistema operativo Android mette a disposizione più di $130$ permessi\footnote{\url{http://developer.android.com/reference/android/Manifest.permission.html}}; gli sviluppatori possono tuttavia definire nuovi permessi (ad esempio per esporre in maniera controllata funzionalità delle proprie app verso l'esterno) o richiedere permessi specifici dichiarati da altre applicazioni. I permessi inclusi nel sistema Android sono classificati in $4$ categorie\footnote{\url{http://developer.android.com/guide/topics/manifest/permission-element.html}} in base al loro rischio potenziale:
\begin{enumerate}
\item[1)]\texttt{normal}: tipologia di permesso utilizzata di default che viene concessa all'applicazione direttamente dal sistema senza notificare l'utente. Si tratta di permessi per accedere a risorse a basso rischio;
\item[2)]\texttt{dangerous}: categoria di permessi più rischiosi del normale, generalmente non necessari per le applicazioni, ma richiesti per accedere ai dati privati e all'hardware del dispositivo (ad esempio, per leggere i contatti o per effettuare chiamate). Tali permessi possono essere concessi solamente tramite la conferma esplicita dell'utente;
\item[3)]\texttt{signature}: questi permessi possono essere concessi solamente ad applicazioni firmate con lo stesso certificato di quelle che hanno dichiarato i permessi e, in caso la firma coincida, sono concessi senza bisogno di notificare l'utente;
\item[4)]\texttt{signatureOrSystem}: tipologia di permesso speciale garantita in modo automatico alle applicazioni incluse nell'immagine di sistema Android.
\end{enumerate}
\subsection{\textit{Application Store}}
Il successo e la diffusione di un sistema operativo sono fortemente influenzati dalla quantità di programmi e/o applicazioni disponibili. Rispetto alla concorrenza, Android è avvantaggiato dal fatto di essere \textit{open source} e perché, modificando una semplice impostazione, permette di installare app da fonti non ufficiali. Per questo motivo, oltre al Google Play Store, sono presenti svariati \textit{application store} alternativi da dove è possibile scaricare ed installare app per il proprio dispositivo mobile, come ad esempio Aptoide e Uptodown. In questa tesi vengono dunque presi in considerazione sia canali di distribuzione ufficiali (ad esempio Google Play Store, Samsung Store ecc.) sia fonti non ufficiali (come siti web, \textit{market} non ufficiali ecc.) per disporre di un campione statistico sufficientemente ampio per una valutazione affidabile dell'approccio proposto in questa tesi per l'analisi del rischio di app Android.
\newpage
\section{Stato dell'arte}\label{sec:Stato_arte}
Al giorno d'oggi Android è un sistema operativo installato sull'$86.2\%$ dei dispositivi mobili \cite{GARTNER}, con centinaia di migliaia di applicazioni disponibili (e non sempre provenienti da fonti ufficiali), pertanto il problema della sicurezza su questa piattaforma è molto attuale. Negli ultimi anni la comunità scientifica, e non solo, ha proposto diverse metodologie allo scopo di individuare le caratteristiche ed i comportamenti che contraddistinguono i \textit{malware} (app malevole) dalle app benigne. In particolare, esistono due approcci generali per il rilevamento di applicazioni malevole: analisi statica e dinamica. Le tecniche basate sull'analisi statica consistono nell'esaminare il codice sorgente decompilato, senza eseguire l'applicazione; in questo modo è possibile estrarre informazioni per individuare, ad esempio, i permessi, i \textit{broadcast receiver} oppure la presenza di stringhe sospette. Nel caso di analisi dinamica, l'app viene invece eseguita in un ambiente di test controllato per monitorarne il comportamento, ed è possibile ottenere dati riguardanti il traffico di rete generato o le risorse di sistema utilizzate. Generalmente, entrambi i tipi di analisi prevedono la creazione di un modello di classificazione a partire dalle informazioni osservate, in modo da riuscire a distinguere le applicazioni benigne da quelle maligne in base alle loro caratteristiche, codificate come \textit{feature}.
In questo elaborato di laurea ci si concentra solamente sui metodi di analisi statica, in particolare su quelli basati sui permessi relativi alle app Android, senza indagare su metodologie che ricorrono all'analisi dinamica (ad esempio \cite{CROWDROID}): come dimostra infatti la letteratura scientifica (\cref{sec:classificazione_binaria,sec:risk_analysis}), impiegando metodologie incentrate sull'analisi statica si ottengono spesso buoni risultati e non è necessario investire risorse in dispositivi mobili e/o emulatori (indispensabili per l'analisi dinamica). Nello specifico, si è partiti esaminando i lavori presenti nella letteratura scientifica riguardanti la classificazione binaria di \textit{malware} e quelli relativi alla creazione di un punteggio di rischio per le applicazioni Android. Dopodiché, dall'analisi dello stato dell'arte di queste due branche di ricerca è stato proposto un approccio nuovo (RiskInDroid) per la generazione di un indice di rischio per app Android.
\subsection{Classificazione binaria di \textit{malware}}\label{sec:classificazione_binaria}
Le pubblicazioni scientifiche che trattano il problema della classificazione binaria di \textit{malware} in ambito Android sono numerose. Vengono analizzate di seguito solo quelle più rilevanti e promettenti ai fini dell'obiettivo di questa tesi.
\newline
Uno dei primi lavori proposti allo scopo di individuare i \textit{malware} in maniera semplice ed efficiente è Kirin \cite{KIRIN}. Si tratta di un elenco di regole di sicurezza che descrivono pattern considerati pericolosi a partire dalle informazioni reperibili nel file \texttt{AndroidManifest.xml} delle app Android. Ad esempio, è considerata pericolosa un'app che richieda contemporaneamente i permessi \texttt{RECEIVE\_SMS} e \texttt{WRITE\_SMS}. Questa tecnica viene valutata su un totale di $311$ applicazioni popolari scaricate dal Google Play Store nel $2009$, individuando $10$ app che violano la tutte le regole predefinite, di cui $5$ risultano effettivamente sospette anche dopo un'analisi manuale più approfondita.
\newline
Gli autori di \cite{PERMISSION_FEATURES} suggeriscono una metodologia basata sul \textit{machine learning} per riconoscere i \textit{malware}, utilizzando come algoritmi \textit{k-means} e gli alberi decisionali. Da ogni applicazione analizzata viene estratto un vettore di \textit{feature} formato da $0$ e $1$, riguardante soprattutto i permessi richiesti dall'app, dove $1$ indica la richiesta dello specifico permesso e $0$ l'assenza; questo modo di costruire le \textit{feature} viene adottato anche in RiskInDroid. Il metodo sviluppato in \cite{PERMISSION_FEATURES} viene validato con un \textit{dataset} di $500$ applicazioni ottenendo buoni risultati.
\newline
In \cite{PUMA} viene presentato un lavoro simile a \cite{PERMISSION_FEATURES}, in quanto si utilizzano tecniche di \textit{machine learning} su insiemi di \textit{feature} estratte dal file \texttt{AndroidManifest.xml} delle applicazioni Android (in particolare i permessi dichiarati). Con a disposizione un \textit{dataset} composto da $249$ \textit{malware} e $357$ app benigne, in \cite{PUMA} si valutano le prestazioni di diversi classificatori nell'individuare le app malevole, fra cui alberi decisionali, \textit{Random Forest} e \textit{Naive Bayes}.
\newline
Gli autori di \cite{TWO_LAYER} sviluppano una metodologia basata non solo sui permessi dichiarati dalle app Android, ma anche su quelli effettivamente utilizzati. Inoltre, per la creazione dei vettori di \textit{feature}, non vengono considerati solamente i singoli permessi, ma anche le coppie di permessi (sia dichiarati sia realmente utilizzati). La tecnica proposta è articolata in due fasi sequenziali in cui si controllano inizialmente i permessi richiesti e poi le coppie di permessi effettivamente utilizzati. Empiricamente si ottengono ottimi risultati, impiegando come classificatore gli alberi decisionali e conducendo i test su un insieme di $20~548$ applicazioni benigne e $1~136$ \textit{malware}.
\newline
In \cite{DREBIN_DATASET} viene proposto DREBIN, un metodo efficiente per il riconoscimento di \textit{malware} tramite analisi statica. A partire dal file \texttt{AndroidManifest.xml} e dal codice decompilato delle app, vengono estratti insiemi di \textit{feature} sottoposti ad un classificatore formato da \textit{Support Vector Machines} (\acrshort{SVM}). Questo metodo viene testato su un insieme di $123~453$ applicazioni benigne e $5~560$ \textit{malware}, ottenendo risultati che indicano un'accuratezza del $94\%$, con solo l'$1\%$ di falsi positivi. Questa metodologia può essere impiegata anche direttamente sui dispositivi mobili, con tempi di esecuzione nell'ordine di alcuni secondi. Per ogni app esaminata, DREBIN fornisce inoltre una descrizione delle \textit{feature} sospette individuate. La collezione di \textit{malware} utilizzata in \cite{DREBIN_DATASET} viene resa disponibile come DREBIN \textit{dataset} e viene impiegata anche per le prove empiriche utilizzate per la validazione sperimentale di RiskInDroid.
\subsection{Analisi del rischio}\label{sec:risk_analysis}
La letteratura scientifica riguardante l'analisi del rischio delle applicazioni Android contiene un numero inferiore di pubblicazioni rispetto a quella relativa alla classificazione binaria di \textit{malware}; pertanto, nel seguito di questa sezione sono presentati i principali lavori scientifici che prevedono metodi quantitativi per la valutazione del rischio delle app Android.
\newline
In \cite{ROTARU} è descritto un metodo per rilevare segnali di rischio per le applicazioni in base a quanto raramente vengono richiesti permessi (o coppie di permessi) critici, dove con permesso critico si intende un permesso con un impatto significativo per la sicurezza e/o per la privacy dell'utente. In particolare, se un'app richiede un permesso che è poco presente nelle altre app della stessa categoria, tale app è considerata rischiosa. Sempre in \cite{ROTARU} viene indicato come ottenere alcune funzioni per il calcolo del rischio delle applicazioni Android, basandosi su modelli probabilistici bayesiani; tuttavia, per poter applicare questi metodi, è necessario conoscere anche la categoria di appartenenza dell'app (informazione reperibile nello \textit{store} da cui viene scaricata l'app, come ad esempio Giochi, Musica, Produttività ecc.). Vengono inoltre menzionate $3$ proprietà interessanti che dovrebbe avere ogni funzione per la generazione di un punteggio di rischio:
\begin{enumerate}
\item[1)]\textbf{monotonicità}, rimuovendo un permesso richiesto da un'applicazione, il valore di rischio della stessa dovrebbe diminuire;
\item[2)]\textbf{coerenza}, le app maligne dovrebbero avere un indice di rischio alto;
\item[3)]\textbf{facilità di comprensione}, in modo che il valore di rischio di un'applicazione sia facilmente interpretabile e confrontabile con altre applicazioni.
\end{enumerate}
Le prove empiriche in \cite{ROTARU} sono eseguite su un \textit{dataset} composto da due insiemi di applicazioni benigne costituiti rispettivamente da $71~331$ e $136~534$ campioni, raccolti nel $2011$ e nel $2012$, e da una collezione di $808$ \textit{malware}.
\newline
In \cite{CATEGORICAL_RISK} viene suggerito un approccio per calcolare il rischio delle app Android basandosi sulla loro categoria di appartenenza. Nello specifico, una volta creati i vettori di \textit{feature} a partire dai permessi richiesti dalle applicazioni, per ogni categoria si determinano quali e quanti sono i permessi più richiesti dalle app benigne presenti in quella categoria, individuando in tal modo i pattern di permessi per ogni categoria. A questo punto è possibile calcolare un indice di rischio per una nuova applicazione andando a misurare quanto i permessi richiesti dall'app si discostano dai pattern rilevati in precedenza. Nonostante i buoni risultati ottenuti empiricamente su un \textit{dataset} formato da $7~737$ app benigne e $1~260$ \textit{malware}, il limite maggiore di questo metodo consiste nella necessità di conoscere la categoria di appartenenza delle applicazioni, informazione non sempre disponibile o affidabile.
\newline
In \cite{MULTILAYER_RISK} viene descritto un \textit{framework} di valutazione del rischio per le applicazioni composto di $3$ livelli interdipendenti: analisi statica, analisi dinamica e analisi comportamentale. Ogni livello si occupa di aspetti specifici dell'applicazione ed è il \textit{framework} proposto a combinare i risultati ricavati dai singoli moduli in modo da ottenere il rischio associato all'applicazione, il quale è composto da informazioni dettagliate come un punteggio di rischio numerico e una lista di fattori determinanti che rendono l'app rischiosa. Il \textit{framework} presentato è descritto nel dettaglio ma solamente in maniera teorica, in quanto in \cite{MULTILAYER_RISK} non vengono riportate prove empiriche a sostegno della metodologia proposta.
\newline
Gli autori di \cite{WANG_QUANTITATIVE} realizzano DroidRisk, un metodo quantitativo per il calcolo di un indice di rischio per le applicazioni Android. Disponendo di una collezione formata da $27~274$ app benigne e $1~260$ app maligne, in \cite{WANG_QUANTITATIVE} vengono presentate alcune statistiche relative ai permessi delle applicazioni nel \textit{dataset} e successivamente viene descritta una formula probabilistica, costituita dal prodotto fra la probabilità di richiesta e fra l'impatto di ogni permesso (inteso come il danno potenziale che si può causare utilizzando tale permesso). Questo metodo viene approfondito più nel dettaglio nella \cref{sec:probabilistic_method} di questa tesi.
\subsection{Libreria \mbox{\textit{scikit-learn}}}
\mbox{\textit{Scikit-learn}}~\cite{SCIKIT} (\url{http://scikit-learn.org/}) è una libreria \textit{open source} sviluppata in linguaggio Python che contiene le implementazioni dei principali algoritmi di \textit{machine learning} per la risoluzione di problemi di classificazione, regressione e \textit{clustering}. Lo scopo di questa libreria non è concentrarsi sul numero di funzionalità offerte, ma di fornire algoritmi implementati allo stato dell'arte, con particolare attenzione alla qualità del codice sorgente sviluppato. In \cite{SCIKIT_API} si può trovare una descrizione più approfondita della struttura interna della libreria; qui di seguito ci si limita a discutere le motivazioni che rendono \mbox{\textit{scikit-learn}} adatta per l'obiettivo di questa tesi.
Il motivo principale per la scelta di impiegare \mbox{\textit{scikit-learn}} è la presenza della funzione \texttt{predict\_proba} nella maggior parte dei classificatori resi disponibili dalla libreria. Si tratta di una funzione che, invece di restituire solamente il nome della classe predetta, indica in output la probabilità con cui ogni classe viene predetta dai metodi di classificazione. Per alcuni classificatori, come \textit{Naive Bayes}, ottenere le probabilità di ogni classe è immediato perché sono i classificatori stessi ad essere probabilistici; in altri casi è invece possibile ricavare le probabilità delle classi predette utilizzando le tecniche descritte in \cite{GET_PROBABILITIES}, come viene fatto ad esempio per le \textit{Support Vector Machines}.
\mbox{\textit{Scikit-learn}} è dunque una libreria potente e versatile, ma anche relativamente semplice da utilizzare per gli utenti meno esperti. Presenta tuttavia dei limiti per quanto riguarda l'esecuzione parallela di codice che sfrutti la presenza di più processori di calcolo; inoltre non è stata ancora realizzata una soluzione stabile e duratura per il salvataggio in maniera persistente dei modelli di classificazione, una volta eseguito il \textit{training} (operazione che può rivelarsi costosa in termini di tempo).
\newpage
\section{Metodologia}\label{sec:Metodologia}
Per l'implementazione dei metodi proposti in questo elaborato di laurea vengono utilizzati principalmente due strumenti di sviluppo. Inizialmente, per il lavoro di tesi viene impiegato l'\gls{IDE} IntelliJ IDEA $2016$\footnote{\hspace{.175em}\url{http://www.jetbrains.com/idea/}} e il linguaggio di programmazione Java, con cui viene scritto il codice relativo alla \cref{sec:cve}. Successivamente, per poter far uso della libreria di \textit{machine learning} chiamata \mbox{\textit{scikit-learn}}, si passa al linguaggio Python, adoperando come \textit{editor} Visual Studio Code\footnote{\hspace{.175em}\url{http://code.visualstudio.com}}. Trattandosi di strumenti multi-piattaforma, durante lo svolgimento della tesi vengono utilizzati sia il sistema operativo Windows~$10$ sia Ubuntu~$16.04$ (eseguito in una macchina virtuale).
\subsection{Raccolta delle applicazioni}\label{sec:dataset}
Per la valutazione della qualità dei metodi proposti e delle relative implementazioni, è prima di tutto necessario costruire una base di dati che contenga un buon numero di campioni da analizzare.
\begin{table}[!htb]
\renewcommand{\arraystretch}{1.3}
\centering
\begin{tabular}{|>{\centering\arraybackslash}m{.4\textwidth}||>{\centering\arraybackslash}m{.4\textwidth}|}
\hline
Fonte & Numero di applicazioni\\
\hline\hline
Raccolta \textit{malware} & $\hspace{1em}6~707$\\\hline
Google Play Store\tablefootnote{\url{http://play.google.com/store/apps}} & $101~730$\\\hline
Aptoide\tablefootnote{\url{http://www.aptoide.com/page/apps}} & $\hspace{1em}7~609$\\\hline
Uptodown\tablefootnote{\url{http://en.uptodown.com/android}} & $\hspace{1em}7~202$\\\hline\hline
Totale & $123~248$\\\hline
\end{tabular}
\caption{Composizione del \textit{dataset} di applicazioni}
\label{tab:APK_dataset}
\end{table}
\noindent Nella \cref{tab:APK_dataset} è visibile l'origine delle applicazioni prese in esame durante questo elaborato di laurea. L'insieme di \textit{malware} è costituito principalmente dal DREBIN \textit{dataset}~\cite{DREBIN_DATASET} ($5~560$ campioni), con l'aggiunta di ulteriori elementi ottenuti da risorse liberamente accessibili online \cite{CONTAGIO_DATASET, HUSTED_DATASET, BHATIA_DATASET}. I campioni restanti vengono invece scaricati dai relativi \textit{app store} mediante un \textit{crawler} creato ad hoc; dato che il Google Play Store è il canale ufficiale per ottenere applicazioni per dispositivi Android, queste vengono considerate (solo inizialmente) non malevole\footnote{La collezione di applicazioni provenienti dal Google Play Store viene analizzata nella \cref{sec:Risultati} per determinare se contiene o meno campioni appartenenti alla categoria \textit{malware}\vspace{1ex}}. A causa della natura eterogenea delle fonti, ad ogni app viene associato un codice univoco di $32$ cifre esadecimali, chiamato \textit{hash MD5}, per evitare di avere duplicati.
Prendere in considerazione una quantità elevata di dati da analizzare (come fatto per il \textit{dataset} di questa tesi) è importante perché permette di ottenere risultati che valgono in generale e non solo in casi specifici, con il vantaggio di avere una maggiore disponibilità di elementi su cui testare gli algoritmi proposti. Tuttavia, a causa del numero relativamente basso di \textit{malware} nel \textit{dataset}, per condurre prove empiriche, vengono estratti in modo pseudo-casuale $3$ insiemi distinti dalle applicazioni scaricate dal Google Play Store che abbiano la stessa dimensione della raccolta di \textit{malware}, impiegando la funzione \texttt{random.sample}\footnote{\url{http://docs.python.org/3/library/random.html\#random.sample}} presente in Python e fissando il parametro \texttt{random.seed} in modo da avere sempre risultati riproducibili. Pertanto, ognuno dei $3$ set ricavati è formato per metà dalla collezione di applicazioni maligne e per l'altra metà da un insieme di app benigne provenienti dal Google Play Store; in questo modo ogni set creato contiene al suo interno un numero bilanciato di \textit{malware} e di applicazioni non malevole.
\subsection{\textit{\acrlong{CVE}}}\label{sec:cve}
Un primo tentativo di creare un punteggio di rischio è stato fatto utilizzando il \textit{\gls{CVE}}, un database liberamente consultabile online all'indirizzo web \url{http://cve.mitre.org/} contenente informazioni di dominio pubblico su falle di sicurezza e vulnerabilità note relative ai sistemi informatici. In particolare, per gli scopi di questo elaborato, si era interessati esclusivamente alle \textit{entry} collegate all'ecosistema Android. A ogni voce inserita nel \gls{CVE} è assegnato un codice in formato \texttt{CVE-[anno]-[numero progressivo]} (ad esempio \texttt{CVE-$2016$-$3897$}) che identifica in modo univoco una vulnerabilità. Tramite questo codice è possibile reperire ulteriori informazioni dal \textit{\gls{NVD}}, sito gestito dal governo degli Stati Uniti\footnote{\url{http://nvd.nist.gov/}}. Nello specifico, si possono ottenere dettagli tecnici come la classe a cui appartiene la vulnerabilità, le configurazioni di software esposte al rischio, le competenze necessarie per sfruttare la falla e soprattutto un punteggio numerico fra $0.0$ e $10.0$ che ne indica la gravità, chiamato \textit{\gls{CVSS}}\footnote{\url{http://www.first.org/cvss}}.
Al momento della stesura della tesi, consultando il \gls{CVE} si possono trovare circa $2~500$ voci relative ad Android. Una prima strada esplorata per l'ottenimento di un indice di rischio per le applicazioni è quindi la seguente: per ogni app analizzata, si scorre l'elenco delle vulnerabilità del \gls{CVE} collegate ad Android, controllando di volta in volta se la descrizione della falla di sicurezza è in qualche modo riconducibile all'applicazione in esame o a un suo componente. Se si riescono a trovare una o più vulnerabilità, queste vengono assegnate all'app e, grazie al loro identificativo univoco, è possibile estrarne il punteggio \gls{CVSS} da cui ottenere infine l'indice di rischio desiderato. La fase cruciale e più difficile di questo metodo è riuscire a fare il \textit{mapping} fra la descrizione in linguaggio naturale della vulnerabilità e l'applicazione stessa o un suo componente.
Analizzando più nel dettaglio l'elenco \gls{CVE} inerente ad Android, si possono individuare più categorie di vulnerabilità:
\begin{enumerate}
\item[a)]Problemi relativi alla verifica dei certificati SSL X.$509$. Si tratta di vulnerabilità che affliggono versioni specifiche di determinate applicazioni e costituiscono circa il $56\%$ della lista \gls{CVE} considerata. Questo gruppo di problemi non può essere utilizzato per la creazione di un indice di rischio generale perché è riferito a versioni specifiche di app, che con buona probabilità avranno già corretto il baco nella \textit{release} immediatamente successiva;
\item[b)]Vulnerabilità inerenti soltanto determinate applicazioni, quindi non utilizzabili per la costruzione di un punteggio di rischio generale. Ad esempio, sommando i problemi relativi ad Adobe Flash Player, Mozilla Firefox e Google Chrome, si ottiene circa l'$11\%$ del totale considerato;
\item[c)]Problemi con le librerie native sviluppate in \mbox{C/C++}. Quasi l'$8\%$ delle vulnerabilità nell'elenco \gls{CVE} considerato contiene riferimenti a file \texttt{.c} e/o \texttt{.cpp}. Tuttavia, una volta che il codice nativo dell'applicazione viene compilato, non è più possibile risalire ai nomi dei sorgenti, quindi non si può realizzare un indice di rischio che tenga conto di queste informazioni;
\item[d)]Vulnerabilità relative a componenti del sistema operativo Android sviluppati con Java. In questo caso, nella descrizione delle voci nell'elenco \gls{CVE} considerato si fa riferimento a file \texttt{.java}, indicandone eventualmente il percorso completo (ad esempio \path{internal/telephony/SMSDispatcher.java}). Utilizzando uno strumento come Apktool~\cite{APKTOOL}, è possibile decompilare il \textit{Dalvik bytecode} dell'applicazione in un linguaggio intermedio, chiamato Smali~\cite{SMALI}, che ha il vantaggio di mantenere intatti i nomi delle classi Java. Per esempio, decompilando un'app che richiede l'uso di \path{internal/telephony/SMSDispatcher.java}, internamente al codice Smali si ritroverebbe la stringa \path{Linternal/telephony/SMSDispatcher.java;}\footnote{\url{http://github.com/JesusFreke/smali/wiki/TypesMethodsAndFields}}. In questo caso è dunque possibile stabilire una corrispondenza fra le applicazioni nel \textit{dataset} e le vulnerabilità presenti nel \gls{CVE}.
\end{enumerate}
\noindent Per la creazione di un indice di rischio a partire dalla lista \gls{CVE} relativa ad Android si impiega dunque la categoria di vulnerabilità vista al punto d) dell'elenco precedente, utilizzando il procedimento illustrato nella \cref{fig:apktool}. Nella prima fase si sceglie l'applicazione che si vuole analizzare e la si decompila con Apktool,
\begin{figure}[!htb]
\centering
\begin{tikzpicture}[x=.09\textwidth,y=-.1\textwidth]
\node[below] at (1.4,-.15) {\includegraphics[height=25mm]{resources/images/apk_icon.png}};
\node[below,align=center] at (1.4,1.75) {\small \textit{Applicazione}\\ \textit{Android}};
\draw[->,thick] (2.25,.75) -- (3.5,.75);
\fill[orange,opacity=.3] (3.75,0.0) rectangle (6.75,1.5);
\node[align=center] at (5.25,.75) {\Large APKTOOL\\ (decompilazione)};
\draw[thick,line cap=rect,orange] (3.75,0.0) rectangle (6.75,1.5);
\draw[->,thick] (7.0,.75) -- (8.25,.75);
\node[below right] at (8.5,-.45) {\includegraphics[height=25mm]{resources/images/smali_icon.png}};
\node[below right] at (9.0,-.15) {\includegraphics[height=25mm]{resources/images/smali_icon.png}};
\node[below right] at (9.5,.15) {\includegraphics[height=25mm]{resources/images/smali_icon.png}};
\fill[blue, opacity=.25] (3.75,2.25) rectangle (6.75,2.75);
\node at (5.25,2.5) {\small\textit{\gls{CVE}}};
\draw[thick,line cap=rect] (3.75,2.25) rectangle (6.75,3.75);
\draw[thick,line cap=rect] (3.75,2.75) -- (6.75,2.75);
\draw[xstep=5\textwidth,ystep=.025\textwidth,gray,very thin] (3.75,2.75) grid (6.75,3.75);
\node[below,align=center] at (5.25,3.8) {\small\textit{Vulnerabilità relative}\\ \textit{ad Android}};
\draw[->,ultra thick] (9.5,2.25) -- (9.5,2.75);
\draw[->,ultra thick] (9.5,3.25) -- (9.5,4.0);
\draw[->,ultra thick] (7.0,3.0) -- (9.25,3.0);
\draw[black,ultra thick,fill=white] (9.5,3.0) circle (.25);
\fill[olive,opacity=.3] (8.0,4.25) rectangle (10.9,4.75);
\draw[thick,line cap=rect] (8.0,4.25) rectangle (10.9,5.25);;
\draw[thick,line cap=rect] (8.0,4.75) -- (10.9,4.75);
\draw[xstep=5\textwidth,ystep=.025\textwidth,gray,very thin] (8.0,4.75) grid (10.9,5.25);
\node[below,align=center] at (9.45,5.3) {\small\textit{Vulnerabilità \gls{CVE}}\\ \textit{dell'applicazione}};
\end{tikzpicture}
\caption{Identificazione delle vulnerabilità utilizzando Apktool}\label{fig:apktool}
\end{figure}
generando in questo modo una cartella al cui interno si trovano anche i file \texttt{.smali}. Il secondo passo consiste nell'individuare all'interno del \gls{CVE} soltanto quelle vulnerabilità nella cui descrizione è presente almeno un nome di file \texttt{.java}. Al momento della stesura della tesi, risultano $43$ elementi che soddisfano questo criterio. A questo punto, per ogni nome di file \texttt{.java} individuato, si controlla se tale nome è presente (sotto forma di stringa) nel codice Smali generato da Apktool (impiegando, ad esempio, il \textit{tool} da linea di comando \texttt{grep}). In caso di esito positivo, l'app in esame risulta soggetta alla vulnerabilità e si può procedere al calcolo di un indice di rischio adoperando il punteggio \gls{CVSS} reperibile nel \gls{NVD}, tramite l'identificativo univoco che caratterizza la vulnerabilità. Esiste tuttavia la possibilità, seppur non considerata in questa tesi, che il codice sorgente dell'applicazione risulti ``offuscato'' e in tal caso non è garantito il funzionamento del metodo proposto. Il termine ``offuscato'' si usa per indicare codice sorgente sintatticamente corretto che però è scritto in maniera volutamente contorta e apparentemente incomprensibile, in modo da rendere il più difficile possibile la comprensione anche da parte dell'utente l'utente più esperto. L'\cref{alg:vulnerability_check} descrive più nel dettaglio la procedura utilizzata per il calcolo di un punteggio di rischio a partire dalla lista \gls{CVE} con le voci relative ad Android.
\begin{algorithm}[!htb]
\caption{Calcolo di un indice di rischio a partire dalla lista \gls{CVE}}
\label{alg:vulnerability_check}
\SetKwData{rischio}{rischio}
\SetKwData{app}{applicazione}
\SetKwData{vulnerability}{vulnerabilità}
\SetKwData{vulnList}{listaVulnerabilità}
\SetKwData{CVE}{listaCVE}
\SetKwData{smali}{smali}
\SetKwData{fileJava}{fileJava}
\SetKwData{nomeFile}{nomeFile}
\SetKwData{tmpScore}{tmpScore}
\SetKwFunction{aggiungi}{aggiungi}
\SetKwFunction{decompilaApk}{decompilaApk}
\SetKwFunction{ottieniNomiFileJava}{ottieniNomiFileJava}
\SetKwFunction{scoreCVSS}{scoreCVSS}
\SetKwInOut{Input}{Input}\SetKwInOut{Output}{Output}
\BlankLine
\Input{Applicazione da analizzare, lista vulnerabilità \gls{CVE}}
\Output{Indice di rischio per l'applicazione}
\BlankLine
$\smali = \decompilaApk{\app}$\;
\ForEach{\vulnerability in \CVE}
{
$\fileJava = \ottieniNomiFileJava{\vulnerability}$\;
\ForEach{\nomeFile in \fileJava}
{
\If{\smali contains \nomeFile}
{
\app.\vulnList.\aggiungi{\vulnerability}\;
\KwSty{continue}
}
}
}
\BlankLine
$\rischio = 0$\;
\BlankLine
\ForEach{\vulnerability in \app.\vulnList}
{
\tcc{Viene scelto il massimo indice di rischio trovato}
\tmpScore = \scoreCVSS{\vulnerability}\;
\If{$\tmpScore > \rischio$}
{
$\rischio = \tmpScore$\;
}
}
\BlankLine
\Return \rischio\;
\end{algorithm}
\noindent L'approccio appena proposto si rivela tuttavia poco efficace nell'uso pratico, a causa della scarsità di risultati ottenuti. Valutando infatti empiricamente questo metodo su un campione di circa $1~500$ applicazioni del \textit{dataset}, si riesce ad individuare un totale di solamente $3$ vulnerabilità, quindi non si ritiene necessario procedere con l'analisi di ulteriori app. Il fatto di trovare così poche vulnerabilità può anche essere un risultato ragionevole se le applicazioni sono progettate bene e/o non utilizzano componenti di Android afflitti da problematiche di sicurezza; tuttavia l'esiguo numero di riscontri non è sufficiente per permettere di calcolare un punteggio di rischio riferibile in modo generale a tutte le applicazioni, in quanto seguendo questo approccio si avrebbe un indice di rischio nullo per la quasi totalità delle app prese in esame.
\newline
Data la scarsa efficacia di questo primo metodo proposto, si prendono in considerazione due ulteriori criteri per raggiungere lo stesso scopo di costruire un punteggio di rischio, questa volta però concentrandosi sull'\textbf{analisi dei permessi delle applicazioni}:
\begin{itemize}
\item\textbf{metodo probabilistico} (\cref{sec:probabilistic_method}): si basa direttamente sulla probabilità di richiesta e/o utilizzo di determinati permessi da parte di \textit{malware} e applicazioni benigne, similmente a quanto descritto in \cite{WANG_QUANTITATIVE};
\item\textbf{metodo basato sul \textit{machine learning}} (\cref{sec:machine_learn_method}): coinvolge l'utilizzo di tecniche di \textit{machine learning} per estrarre un indice di rischio a partire dall'analisi dei permessi di \textit{malware} e applicazioni benigne. Metodologie simili (come ad esempio \cite{DREBIN_DATASET}) sono già presenti in letteratura, però riguardano una classificazione binaria tra \textit{malware} e non \textit{malware}, senza fornire esplicitamente un punteggio di rischio per ogni applicazione esaminata. Questo nuovo metodo proposto nella tesi viene chiamato RiskInDroid.
\end{itemize}
\subsection{Statistiche relative ai permessi}\label{sec:statistiche_permessi}
Prima di procedere illustrando le metodologie basate sull'analisi dei permessi, è opportuno soffermarsi ad esaminare alcune statistiche ad essi relative. In particolare, la motivazione per indagare ulteriormente su questo aspetto delle app nasce dall'osservazione delle differenze che ci sono fra permessi relativi ad applicazioni benigne e quelli collegati ai \textit{malware}.
\begin{figure}[!htb]
\centering
\begin{tikzpicture}[x=.09\textwidth,y=-.1\textwidth]
\node[below] at (1.4,-.15) {\includegraphics[height=25mm]{resources/images/apk_icon.png}};
\node[below,align=center] at (1.4,1.75) {\small \textit{Applicazione}\\ \textit{Android}};
\node[above] at (2.825,.75) {\small Analisi};
\draw[->,thick] (2.25,.75) -- (3.5,.75);
\fill[orange,opacity=.3] (3.75,0.0) rectangle (6.75,1.5);
\node[align=center] at (5.25,.75) {\Large APPROVER\\ \textit{Permission Checker}};
\draw[thick,line cap=rect,orange] (3.75,0.0) rectangle (6.75,1.5);
\node[above] at (7.625,.75) {\small Risultato};
\draw[->,thick] (7.0,.75) -- (8.25,.75);
\fill[olive,opacity=.3] (8.5,-.25) rectangle (11.1,.25);
\node at (9.8,0.0) {\small\textit{Permessi}};
\draw[thick,line cap=rect] (8.5,-.25) rectangle (11.1,1.8);;
\draw[thick,line cap=rect] (8.5,.25) -- (11.1,.25);
\node at (9.8,.5) {\small dichiarati: \{\dots\}};
\node[align=center] at (9.8,1.0) {\small dichiarati\_e\_usati:\\ \{\dots\}};
\node at (9.8,1.5) {\small \vdots};
\node[below] at (9.8,1.85) {\small\textit{File JSON}};
\end{tikzpicture}
\caption{Modulo di Approver per l'estrazione dei permessi da un file \texttt{.apk}}\label{fig:permission_checker}
\end{figure}
\noindent Per ottenere i permessi delle applicazioni presenti nel \textit{dataset} viene impiegato il modulo \textit{Permission Checker} di Approver~\cite{APPROVER}. Come visibile nella \cref{fig:permission_checker}, si tratta di un componente che prende in ingresso file di tipo \texttt{.apk} e restituisce in output una lista di permessi (in formato \texttt{JSON}) relativi all'app analizzata.
Nello specifico, il risultato ottenuto dal modulo raggruppa i permessi in $4$ diverse categorie:
\begin{enumerate}
\item[1)]\textbf{Dichiarati}: permessi richiesti esplicitamente nel file \texttt{AndroidManifest.xml} presente in ogni applicazione per Android. Questa lista è relativamente facile da ricavare anche con altri \textit{tool}, come ad esempio Androguard~\cite{ANDROGUARD};
\item[2)]\textbf{Dichiarati e utilizzati}: permessi richiesti nel file \texttt{AndroidManifest.xml} che vengono realmente usati dall'applicazione. Per decidere se un permesso è utilizzato o meno, Approver analizza staticamente il \textit{Dalvik bytecode} del file \texttt{classes.dex} contenuto nell'app e determina se vengono invocati metodi che hanno bisogno di permessi per essere eseguiti. Questa lista comprende dunque solo i permessi per cui c'è un riscontro all'interno del \textit{bytecode};
\item[3)]\textbf{Dichiarati ma non utilizzati}: permessi richiesti soltanto all'interno del file \texttt{AndroidManifest.xml} e per cui non c'è alcun riscontro dentro il \textit{bytecode} dell'applicazione;
\item[4)]\textbf{Non dichiarati ma utilizzati}: permessi necessari per l'invocazione di metodi all'interno del \textit{bytecode} ma che non sono presenti nel file \texttt{AndroidManifest.xml}.
\end{enumerate}
Esaminando la \cref{fig:p_dichiarati}, si può constatare la differente distribuzione dei permessi dichiarati fra le diverse categorie del \textit{dataset} considerato. È interessante notare come, nel caso dei \textit{malware}, tutti i $15$ permessi della \cref{fig:p_dichiarati:malware} siano richiesti da almeno un quarto delle applicazioni malevole, mentre tale numero scende a $6$ considerando solo i campioni del Google Play Store (\cref{fig:p_dichiarati:goodware}). Si può quindi dedurre che, statisticamente parlando, i \textit{malware} necessitano mediamente di più permessi rispetto al resto delle app. Inoltre, sempre in \cref{fig:p_dichiarati}, si può osservare come le applicazioni provenienti da \textit{store} non ufficiali (\cref{fig:p_dichiarati:aptoide,fig:p_dichiarati:uptodown}) abbiano statistiche che si trovano a metà strada tra \textit{malware} e app benigne, e questo vale non solo per i permessi dichiarati, ma anche per le altre categorie di permessi, i cui grafici sono mostrati nelle \cref{fig:p_dichiarati_usati,fig:p_dichiarati_non_usati,fig:p_non_dichiarati_usati}.
\begin{figure}[!htb]
\centering
\begin{subfigure}[t]{.49\textwidth}
\begin{tikzpicture}[scale=.75]
\begin{axis}[
width=.9\textwidth,
height=1.3\textwidth,
xmajorgrids,
grid style={dashed,gray!30},
xbar,
y dir=reverse,
xtick={0,25,...,100},
ytick=data,
xmin=0,
xmax=100,
y tick label style={align=right,font=\footnotesize\ttfamily},
enlarge y limits=0.05,
tick pos=left,
symbolic y coords={INTERNET,READ\_PHONE\_STATE,ACCESS\_NETWORK\_STATE,WRITE\_EXTERNAL\_STORAGE,SEND\_SMS,ACCESS\_WIFI\_STATE,RECEIVE\_BOOT\_COMPLETED,ACCESS\_COARSE\_LOCATION,RECEIVE\_SMS,WAKE\_LOCK,READ\_SMS,VIBRATE,ACCESS\_FINE\_LOCATION,CHANGE\_WIFI\_STATE,READ\_CONTACTS,}
]
\addplot[red!40!black,fill=red!70!white] coordinates {
(96.66,INTERNET)
(90.04,READ\_PHONE\_STATE)
(70.84,ACCESS\_NETWORK\_STATE)
(69.79,WRITE\_EXTERNAL\_STORAGE)
(50.45,SEND\_SMS)
(48.61,ACCESS\_WIFI\_STATE)
(46.31,RECEIVE\_BOOT\_COMPLETED)
(38.03,ACCESS\_COARSE\_LOCATION)
(37.93,RECEIVE\_SMS)
(36.99,WAKE\_LOCK)
(36.72,READ\_SMS)
(36.57,VIBRATE)
(36.29,ACCESS\_FINE\_LOCATION)
(25.96,CHANGE\_WIFI\_STATE)
(24.66,READ\_CONTACTS)
};
\end{axis}
\end{tikzpicture}
\captionsetup{justification=centering}
\caption{Percentuale \textit{malware}}\label{fig:p_dichiarati:malware}
\end{subfigure}%
\hfill
\begin{subfigure}[t]{.49\textwidth}
\begin{tikzpicture}[scale=.75]
\begin{axis}[
width=.9\textwidth,
height=1.3\textwidth,
xmajorgrids,
grid style={dashed,gray!30},
xbar,
y dir=reverse,
xtick={0,25,...,100},
ytick=data,
xmin=0,
xmax=100,
y tick label style={align=right,font=\footnotesize\ttfamily},
enlarge y limits=0.05,
tick pos=left,
symbolic y coords={INTERNET,ACCESS\_NETWORK\_STATE,WRITE\_EXTERNAL\_STORAGE,ACCESS\_WIFI\_STATE,WAKE\_LOCK,READ\_PHONE\_STATE,VIBRATE,GET\_ACCOUNTS,ACCESS\_COARSE\_LOCATION,READ\_EXTERNAL\_STORAGE,ACCESS\_FINE\_LOCATION,RECEIVE\_BOOT\_COMPLETED,CAMERA,GET\_TASKS,READ\_CONTACTS,}
]
\addplot[green!40!black,fill=green!70!white] coordinates {
(94.93,INTERNET)
(89.73,ACCESS\_NETWORK\_STATE)
(58.06,WRITE\_EXTERNAL\_STORAGE)
(36.22,ACCESS\_WIFI\_STATE)
(34.89,WAKE\_LOCK)
(30.55,READ\_PHONE\_STATE)
(24.01,VIBRATE)
(19.67,GET\_ACCOUNTS)
(18.16,ACCESS\_COARSE\_LOCATION)
(17.63,READ\_EXTERNAL\_STORAGE)
(17.11,ACCESS\_FINE\_LOCATION)
(15.06,RECEIVE\_BOOT\_COMPLETED)
(10.90,CAMERA)
(7.92,GET\_TASKS)
(6.14,READ\_CONTACTS)
};
\end{axis}
\end{tikzpicture}
\captionsetup{justification=centering}
\caption{Percentuale app Google Play}\label{fig:p_dichiarati:goodware}
\end{subfigure}%
\vspace{.05\textwidth}
\begin{subfigure}[t]{.49\textwidth}
\begin{tikzpicture}[scale=.75]
\begin{axis}[
width=.9\textwidth,
height=1.3\textwidth,
xmajorgrids,
grid style={dashed,gray!30},
xbar,
y dir=reverse,
xtick={0,25,...,100},
ytick=data,
xmin=0,
xmax=100,
y tick label style={align=right,font=\footnotesize\ttfamily},
enlarge y limits=0.05,
tick pos=left,
symbolic y coords={INTERNET,ACCESS\_NETWORK\_STATE,WRITE\_EXTERNAL\_STORAGE,WAKE\_LOCK,ACCESS\_WIFI\_STATE,READ\_PHONE\_STATE,VIBRATE,RECEIVE\_BOOT\_COMPLETED,READ\_EXTERNAL\_STORAGE,GET\_ACCOUNTS,ACCESS\_COARSE\_LOCATION,ACCESS\_FINE\_LOCATION,GET\_TASKS,CAMERA,READ\_CONTACTS,}
]
\addplot[orange!40!black,fill=orange!70!white] coordinates {
(88.84,INTERNET)
(85.30,ACCESS\_NETWORK\_STATE)
(69.72,WRITE\_EXTERNAL\_STORAGE)
(52.02,WAKE\_LOCK)
(45.77,ACCESS\_WIFI\_STATE)
(38.64,READ\_PHONE\_STATE)
(38.10,VIBRATE)
(30.29,RECEIVE\_BOOT\_COMPLETED)
(29.59,READ\_EXTERNAL\_STORAGE)
(29.55,GET\_ACCOUNTS)
(23.37,ACCESS\_COARSE\_LOCATION)
(21.66,ACCESS\_FINE\_LOCATION)
(16.28,GET\_TASKS)
(15.73,CAMERA)
(14.97,READ\_CONTACTS)
};
\end{axis}
\end{tikzpicture}
\captionsetup{justification=centering}
\caption{Percentuale app Aptoide}\label{fig:p_dichiarati:aptoide}
\end{subfigure}%
\hfill
\begin{subfigure}[t]{.49\textwidth}
\begin{tikzpicture}[scale=.75]
\begin{axis}[
width=.9\textwidth,
height=1.3\textwidth,
xmajorgrids,
grid style={dashed,gray!30},
xbar,
y dir=reverse,
xtick={0,25,...,100},
ytick=data,
xmin=0,
xmax=100,
y tick label style={align=right,font=\footnotesize\ttfamily},
enlarge y limits=0.05,
tick pos=left,
symbolic y coords={INTERNET,ACCESS\_NETWORK\_STATE,WRITE\_EXTERNAL\_STORAGE,WAKE\_LOCK,ACCESS\_WIFI\_STATE,READ\_PHONE\_STATE,VIBRATE,GET\_ACCOUNTS,READ\_EXTERNAL\_STORAGE,ACCESS\_COARSE\_LOCATION,RECEIVE\_BOOT\_COMPLETED,ACCESS\_FINE\_LOCATION,CAMERA,GET\_TASKS,READ\_CONTACTS,}
]
\addplot[orange!40!black,fill=orange!70!white] coordinates {
(94.60,INTERNET)
(90.82,ACCESS\_NETWORK\_STATE)
(71.75,WRITE\_EXTERNAL\_STORAGE)
(51.37,WAKE\_LOCK)
(48.01,ACCESS\_WIFI\_STATE)
(43.54,READ\_PHONE\_STATE)
(36.38,VIBRATE)
(31.02,GET\_ACCOUNTS)
(25.04,READ\_EXTERNAL\_STORAGE)
(23.24,ACCESS\_COARSE\_LOCATION)
(22.19,RECEIVE\_BOOT\_COMPLETED)
(20.95,ACCESS\_FINE\_LOCATION)
(14.27,CAMERA)
(14.02,GET\_TASKS)
(11.44,READ\_CONTACTS)
};
\end{axis}
\end{tikzpicture}
\captionsetup{justification=centering}
\caption{Percentuale app Uptodown}\label{fig:p_dichiarati:uptodown}
\end{subfigure}%
\vspace{.01\textwidth}
\caption{I $15$ permessi più \textbf{dichiarati} dalle applicazioni nel \textit{dataset}}\label{fig:p_dichiarati}
\end{figure}
Ciò potrebbe suggerire che le app di \textit{store} alternativi siano in media meno sicure di quelle provenienti dal Google Play Store, il ché è sensato se si pensa ai maggiori controlli a cui dovrebbero essere sottoposte le applicazioni pubblicate nel Google Play Store.
Non tutti i permessi consentono però di fare una distinzione tra app benigne e maligne. \texttt{INTERNET}, ad esempio, è il permesso più dichiarato (\cref{fig:p_dichiarati}) in tutte le categorie del \textit{dataset} considerato ed è anche quello più utilizzato realmente dalle app (\cref{fig:p_dichiarati_usati}), quindi è impossibile valutare il rischio di un'applicazione considerando solamente questo parametro. Attualmente la maggioranza delle app necessita di una connessione ad Internet:
\begin{figure}[!htb]
\centering
\begin{subfigure}[t]{.49\textwidth}
\begin{tikzpicture}[scale=.75]
\begin{axis}[
width=.9\textwidth,
height=1.3\textwidth,
xmajorgrids,
grid style={dashed,gray!30},
xbar,
y dir=reverse,
xtick={0,25,...,100},
ytick=data,
xmin=0,
xmax=100,
y tick label style={align=right,font=\footnotesize\ttfamily},
enlarge y limits=0.05,
tick pos=left,
symbolic y coords={INTERNET,READ\_PHONE\_STATE,ACCESS\_NETWORK\_STATE,ACCESS\_WIFI\_STATE,ACCESS\_COARSE\_LOCATION,ACCESS\_FINE\_LOCATION,VIBRATE,GET\_TASKS,CHANGE\_WIFI\_STATE,WAKE\_LOCK,WRITE\_EXTERNAL\_STORAGE,RESTART\_PACKAGES,SET\_WALLPAPER,CHANGE\_NETWORK\_STATE,CAMERA,}
]
\addplot[red!40!black,fill=red!70!white] coordinates {
(76.67,INTERNET)
(75.65,READ\_PHONE\_STATE)
(59.43,ACCESS\_NETWORK\_STATE)
(36.84,ACCESS\_WIFI\_STATE)
(33.88,ACCESS\_COARSE\_LOCATION)
(32.06,ACCESS\_FINE\_LOCATION)
(29.77,VIBRATE)
(18.61,GET\_TASKS)
(13.78,CHANGE\_WIFI\_STATE)
(9.86,WAKE\_LOCK)
(8.92,WRITE\_EXTERNAL\_STORAGE)
(6.13,RESTART\_PACKAGES)
(4.70,SET\_WALLPAPER)
(3.04,CHANGE\_NETWORK\_STATE)
(2.77,CAMERA)
};
\end{axis}
\end{tikzpicture}
\captionsetup{justification=centering}
\caption{Percentuale \textit{malware}}
\end{subfigure}%
\hfill
\begin{subfigure}[t]{.49\textwidth}
\begin{tikzpicture}[scale=.75]
\begin{axis}[
width=.9\textwidth,
height=1.3\textwidth,
xmajorgrids,
grid style={dashed,gray!30},
xbar,
y dir=reverse,
xtick={0,25,...,100},
ytick=data,
xmin=0,
xmax=100,
y tick label style={align=right,font=\footnotesize\ttfamily},
enlarge y limits=0.05,
tick pos=left,
symbolic y coords={INTERNET,ACCESS\_NETWORK\_STATE,WAKE\_LOCK,WRITE\_EXTERNAL\_STORAGE,ACCESS\_WIFI\_STATE,VIBRATE,READ\_PHONE\_STATE,ACCESS\_COARSE\_LOCATION,ACCESS\_FINE\_LOCATION,CAMERA,GET\_TASKS,RECORD\_AUDIO,SET\_WALLPAPER,CHANGE\_WIFI\_STATE,WRITE\_SETTINGS,}
]
\addplot[green!40!black,fill=green!70!white] coordinates {
(91.83,INTERNET)
(87.62,ACCESS\_NETWORK\_STATE)
(32.00,WAKE\_LOCK)
(30.06,WRITE\_EXTERNAL\_STORAGE)
(24.60,ACCESS\_WIFI\_STATE)
(23.42,VIBRATE)
(21.85,READ\_PHONE\_STATE)
(14.46,ACCESS\_COARSE\_LOCATION)
(13.67,ACCESS\_FINE\_LOCATION)
(6.28,CAMERA)
(5.56,GET\_TASKS)
(3.12,RECORD\_AUDIO)
(3.04,SET\_WALLPAPER)
(2.11,CHANGE\_WIFI\_STATE)
(1.76,WRITE\_SETTINGS)
};
\end{axis}
\end{tikzpicture}
\captionsetup{justification=centering}
\caption{Percentuale app Google Play}
\end{subfigure}%
\vspace{.05\textwidth}
\begin{subfigure}[t]{.49\textwidth}
\begin{tikzpicture}[scale=.75]
\begin{axis}[
width=.9\textwidth,
height=1.3\textwidth,
xmajorgrids,
grid style={dashed,gray!30},
xbar,
y dir=reverse,
xtick={0,25,...,100},
ytick=data,
xmin=0,
xmax=100,
y tick label style={align=right,font=\footnotesize\ttfamily},
enlarge y limits=0.05,
tick pos=left,
symbolic y coords={INTERNET,ACCESS\_NETWORK\_STATE,WAKE\_LOCK,ACCESS\_WIFI\_STATE,VIBRATE,WRITE\_EXTERNAL\_STORAGE,READ\_PHONE\_STATE,ACCESS\_COARSE\_LOCATION,ACCESS\_FINE\_LOCATION,GET\_TASKS,CHANGE\_WIFI\_STATE,CAMERA,BLUETOOTH,BLUETOOTH\_ADMIN,GET\_ACCOUNTS,}
]
\addplot[orange!40!black,fill=orange!70!white] coordinates {
(84.45,INTERNET)
(81.67,ACCESS\_NETWORK\_STATE)
(44.86,WAKE\_LOCK)
(36.82,ACCESS\_WIFI\_STATE)
(36.81,VIBRATE)
(34.52,WRITE\_EXTERNAL\_STORAGE)
(32.11,READ\_PHONE\_STATE)
(19.66,ACCESS\_COARSE\_LOCATION)
(18.01,ACCESS\_FINE\_LOCATION)
(13.73,GET\_TASKS)
(9.55,CHANGE\_WIFI\_STATE)
(8.64,CAMERA)
(7.67,BLUETOOTH)
(4.55,BLUETOOTH\_ADMIN)
(4.52,GET\_ACCOUNTS)
};
\end{axis}
\end{tikzpicture}
\captionsetup{justification=centering}
\caption{Percentuale app Aptoide}
\end{subfigure}%
\hfill
\begin{subfigure}[t]{.49\textwidth}
\begin{tikzpicture}[scale=.75]
\begin{axis}[
width=.9\textwidth,
height=1.3\textwidth,
xmajorgrids,
grid style={dashed,gray!30},
xbar,
y dir=reverse,
xtick={0,25,...,100},
ytick=data,
xmin=0,
xmax=100,
y tick label style={align=right,font=\footnotesize\ttfamily},
enlarge y limits=0.05,
tick pos=left,
symbolic y coords={INTERNET,ACCESS\_NETWORK\_STATE,WAKE\_LOCK,ACCESS\_WIFI\_STATE,READ\_PHONE\_STATE,VIBRATE,WRITE\_EXTERNAL\_STORAGE,ACCESS\_COARSE\_LOCATION,ACCESS\_FINE\_LOCATION,GET\_TASKS,CAMERA,CHANGE\_WIFI\_STATE,BLUETOOTH,RECORD\_AUDIO,GET\_ACCOUNTS,}
]
\addplot[orange!40!black,fill=orange!70!white] coordinates {
(91.17,INTERNET)
(87.97,ACCESS\_NETWORK\_STATE)
(46.54,WAKE\_LOCK)
(39.42,ACCESS\_WIFI\_STATE)
(35.72,READ\_PHONE\_STATE)
(35.30,VIBRATE)
(32.52,WRITE\_EXTERNAL\_STORAGE)
(20.06,ACCESS\_COARSE\_LOCATION)
(18.13,ACCESS\_FINE\_LOCATION)
(11.27,GET\_TASKS)
(8.52,CAMERA)
(6.39,CHANGE\_WIFI\_STATE)
(5.70,BLUETOOTH)
(4.39,RECORD\_AUDIO)
(3.52,GET\_ACCOUNTS)
};
\end{axis}
\end{tikzpicture}
\captionsetup{justification=centering}
\caption{Percentuale app Uptodown}
\end{subfigure}%
\vspace{.01\textwidth}
\captionsetup{justification=centering}
\caption{I $15$ permessi più \textbf{dichiarati e anche utilizzati} dalle applicazioni nel \textit{dataset}}\label{fig:p_dichiarati_usati}
\end{figure}
applicazioni come quelle di messaggistica istantanea o relative ai \textit{social network} devono accedere alla rete per poter funzionare, ma è sufficiente pensare a giochi per dispositivi mobili che richiedono Internet solo per stilare le classifiche dei punteggi migliori o per mostrare annunci pubblicitari all'utente. Come conseguenza, i permessi riguardanti l'accesso alla rete come \texttt{ACCESS\_NETWORK\_STATE} o \texttt{ACCESS\_WIFI\_STATE} sono anch'essi molto diffusi.
\begin{figure}[!htb]
\centering
\begin{subfigure}[t]{.49\textwidth}
\begin{tikzpicture}[scale=.75]
\begin{axis}[
width=.9\textwidth,
height=1.3\textwidth,
xmajorgrids,
grid style={dashed,gray!30},
xbar,
y dir=reverse,
xtick={0,15,30,45,60},
ytick=data,
xmin=0,
xmax=60,
y tick label style={align=right,font=\footnotesize\ttfamily},
enlarge y limits=0.05,
tick pos=left,
symbolic y coords={WRITE\_EXTERNAL\_STORAGE,SEND\_SMS,RECEIVE\_BOOT\_COMPLETED,RECEIVE\_SMS,READ\_SMS,WAKE\_LOCK,READ\_CONTACTS,INSTALL\_SHORTCUT,INTERNET,READ\_LOGS,SYSTEM\_ALERT\_WINDOW,CALL\_PHONE,READ\_PHONE\_STATE,INSTALL\_PACKAGES,UNINSTALL\_SHORTCUT,}
]
\addplot[red!40!black,fill=red!70!white] coordinates {
(60.00,WRITE\_EXTERNAL\_STORAGE)
(50.45,SEND\_SMS)
(46.31,RECEIVE\_BOOT\_COMPLETED)
(37.93,RECEIVE\_SMS)
(36.72,READ\_SMS)
(27.14,WAKE\_LOCK)
(24.63,READ\_CONTACTS)
(22.28,INSTALL\_SHORTCUT)
(19.99,INTERNET)
(18.35,READ\_LOGS)
(16.13,SYSTEM\_ALERT\_WINDOW)
(14.85,CALL\_PHONE)
(14.39,READ\_PHONE\_STATE)
(13.08,INSTALL\_PACKAGES)
(12.57,UNINSTALL\_SHORTCUT)
};
\end{axis}
\end{tikzpicture}
\captionsetup{justification=centering}
\caption{Percentuale \textit{malware}}\label{fig:p_dichiarati_non_usati:malware}
\end{subfigure}%
\hfill
\begin{subfigure}[t]{.49\textwidth}
\begin{tikzpicture}[scale=.75]
\begin{axis}[
width=.9\textwidth,
height=1.3\textwidth,
xmajorgrids,
grid style={dashed,gray!30},
xbar,
y dir=reverse,
xtick={0,15,30,45,60},
ytick=data,
xmin=0,
xmax=60,
y tick label style={align=right,font=\footnotesize\ttfamily},
enlarge y limits=0.05,
tick pos=left,
symbolic y coords={WRITE\_EXTERNAL\_STORAGE,GET\_ACCOUNTS,READ\_EXTERNAL\_STORAGE,RECEIVE\_BOOT\_COMPLETED,ACCESS\_WIFI\_STATE,READ\_PHONE\_STATE,SYSTEM\_ALERT\_WINDOW,READ\_CONTACTS,CAMERA,CALL\_PHONE,ACCESS\_COARSE\_LOCATION,ACCESS\_FINE\_LOCATION,INTERNET,WRITE\_SETTINGS,INSTALL\_SHORTCUT,}
]
\addplot[green!40!black,fill=green!70!white] coordinates {
(28.01,WRITE\_EXTERNAL\_STORAGE)
(18.67,GET\_ACCOUNTS)
(17.63,READ\_EXTERNAL\_STORAGE)
(15.06,RECEIVE\_BOOT\_COMPLETED)
(11.62,ACCESS\_WIFI\_STATE)
(8.70,READ\_PHONE\_STATE)
(6.09,SYSTEM\_ALERT\_WINDOW)
(6.06,READ\_CONTACTS)
(4.62,CAMERA)
(4.27,CALL\_PHONE)
(3.70,ACCESS\_COARSE\_LOCATION)
(3.44,ACCESS\_FINE\_LOCATION)
(3.12,INTERNET)
(3.03,WRITE\_SETTINGS)
(2.89,INSTALL\_SHORTCUT)
};
\end{axis}
\end{tikzpicture}
\captionsetup{justification=centering}
\caption{Percentuale app Google Play}
\end{subfigure}%
\vspace{.05\textwidth}
\begin{subfigure}[t]{.49\textwidth}
\begin{tikzpicture}[scale=.75]
\begin{axis}[
width=.9\textwidth,
height=1.3\textwidth,
xmajorgrids,
grid style={dashed,gray!30},
xbar,
y dir=reverse,
xtick={0,15,30,45,60},
ytick=data,
xmin=0,
xmax=60,
y tick label style={align=right,font=\footnotesize\ttfamily},
enlarge y limits=0.05,
tick pos=left,
symbolic y coords={WRITE\_EXTERNAL\_STORAGE,RECEIVE\_BOOT\_COMPLETED,READ\_EXTERNAL\_STORAGE,GET\_ACCOUNTS,READ\_CONTACTS,SYSTEM\_ALERT\_WINDOW,WRITE\_SETTINGS,ACCESS\_WIFI\_STATE,INSTALL\_SHORTCUT,CALL\_PHONE,WAKE\_LOCK,CAMERA,CHANGE\_NETWORK\_STATE,READ\_SMS,READ\_PHONE\_STATE,}
]
\addplot[orange!40!black,fill=orange!70!white] coordinates {
(35.20,WRITE\_EXTERNAL\_STORAGE)
(30.29,RECEIVE\_BOOT\_COMPLETED)
(29.59,READ\_EXTERNAL\_STORAGE)
(25.03,GET\_ACCOUNTS)
(14.45,READ\_CONTACTS)
(14.04,SYSTEM\_ALERT\_WINDOW)
(12.79,WRITE\_SETTINGS)
(8.95,ACCESS\_WIFI\_STATE)
(8.60,INSTALL\_SHORTCUT)
(7.59,CALL\_PHONE)
(7.15,WAKE\_LOCK)
(7.09,CAMERA)
(6.60,CHANGE\_NETWORK\_STATE)
(6.57,READ\_SMS)
(6.53,READ\_PHONE\_STATE)
};
\end{axis}
\end{tikzpicture}
\captionsetup{justification=centering}
\caption{Percentuale app Aptoide}
\end{subfigure}%
\hfill
\begin{subfigure}[t]{.49\textwidth}
\begin{tikzpicture}[scale=.75]
\begin{axis}[
width=.9\textwidth,
height=1.3\textwidth,
xmajorgrids,
grid style={dashed,gray!30},
xbar,
y dir=reverse,
xtick={0,15,30,45,60},
ytick=data,
xmin=0,
xmax=60,
y tick label style={align=right,font=\footnotesize\ttfamily},
enlarge y limits=0.05,
tick pos=left,
symbolic y coords={WRITE\_EXTERNAL\_STORAGE,GET\_ACCOUNTS,READ\_EXTERNAL\_STORAGE,RECEIVE\_BOOT\_COMPLETED,READ\_CONTACTS,SYSTEM\_ALERT\_WINDOW,ACCESS\_WIFI\_STATE,READ\_PHONE\_STATE,WRITE\_SETTINGS,INSTALL\_SHORTCUT,CAMERA,RECORD\_AUDIO,CALL\_PHONE,RECEIVE\_SMS,WAKE\_LOCK,}
]
\addplot[orange!40!black,fill=orange!70!white] coordinates {
(39.23,WRITE\_EXTERNAL\_STORAGE)
(27.49,GET\_ACCOUNTS)
(25.04,READ\_EXTERNAL\_STORAGE)
(22.19,RECEIVE\_BOOT\_COMPLETED)
(11.24,READ\_CONTACTS)
(9.92,SYSTEM\_ALERT\_WINDOW)
(8.59,ACCESS\_WIFI\_STATE)
(7.82,READ\_PHONE\_STATE)
(7.76,WRITE\_SETTINGS)
(7.65,INSTALL\_SHORTCUT)
(5.75,CAMERA)
(5.74,RECORD\_AUDIO)
(5.56,CALL\_PHONE)
(4.98,RECEIVE\_SMS)
(4.84,WAKE\_LOCK)
};
\end{axis}
\end{tikzpicture}
\captionsetup{justification=centering}
\caption{Percentuale app Uptodown}
\end{subfigure}%