\section{Applicazioni} \subsection{Problematiche} La disponibilità di
numerosi giochi e applicazioni e la facilità di accesso ad essi è uno dei
principali campi di battaglia tra i principali operatori del settore e
costituisce uno dei servizi più pubblicizzati e richiesti dal mercato. Non
stupisce quindi che l'installazione e l'esecuzione di applicazioni
costituisca in varie forme una importante superficie di attacco per i
sistemi di comunicazione mobile.

I problemi relativi alla sicurezza derivanti dall'installazione di
applicazioni si possono genericamente suddividere in tre categorie:
malware, problemi derivanti da bug ed errori di programmazione e problemi
derivanti da applicazioni che diffondono involontariamente informazioni
potenzialmente riservate per una progettazione poco attenta ai problemi di
sicurezza.

\subsubsection{Malware} Applicazioni di tipo malware minacciano con dolo di
mettere a repentaglio la sicurezza del sistema in vari modi, attaccando la
confidenzialità e l'integrità delle comunicazioni o delle informazioni
presenti nel dispositivo o la disponibilità di particolari servizi o
dell'intera dispositivo con il suo blocco. Dato l'utilizzo di servizi a
costo tipici della telefonia e le prospettive di espansione di servizi per
il ``\emph{mobile payment}'' un attacco eseguito con successo può avere
anche immediate ripercussioni economiche.  Infine un terminale compromesso
può essere usato come testa di ponte per la compromissione di altri
dispositivi, attraverso la rete o meccanismi di sincronizzazione anche con
altre classi di dispositivi o reti di comunicazione.\\

Le seguenti categorie di attacchi malware possono essere 
identificate:\cite{o2007attack}
\begin{description}
  \item[Spoofing.] Il programma malware fornisce false informazioni all'utente
per spingerlo a scelte e decisioni che incidono sulla sicurezza del
dispositivo.  
  \item[Intercettamento o accesso ai dati.] Il programma malware riesce ad
intercettare ed accedere ai dati presenti nel dispositivo.
  \item[Data Theft.] Il programma riesce a raccogliere e far filtrare
esternamente al dispositivo i dati raccolti.
  \item[Backdoor.] Il programma offre funzionalità che permettono ad un
attaccante di ottenere accesso al dispositivo in un secondo momento.
  \item[Abuso dei servizi.] Il programma riesce a compiere azioni che
comportano un costo finanziario per l'utente.
  \item[Disponibilità.] La disponibilità o l'integrità del dispositivo o dei
dati che risiedono nel dispositivo viene compromessa.
  \item[Accesso alla rete.] Il programma usa il dispositivo per comunicazioni
di rete non autorizzate.
  \item[\emph{Wormable}.] Il programma riesce a replicarsi semi-autonomamente
su altri dispositivi.
\end{description}

Fino a questo momento gli attacchi a smartphone e dispositivi simili sono
stati limitati a confronto con quelli relativi ad altri dispositivi
consumer come desktop e portatili. Risorse hardware limitate sono state un
limite sia per l'attacco che per la difesa, in particolare il modello d'uso
di botnet per spam, denial of service a scopo di estorsione, furto di dati
e phishing sembra di scarsa appetibilità data la necessità di avere linee
dati veloci e stabili e adeguate risorse hardware, anche se la rete
telefonica cellulare sembra essere particolarmente vulnerabile ad attacchi
DDOS.\cite{oberheide2010mobile,Traynor:2009:CBM:1653662.1653690} Data
l'appetibilità di questi dispositivi per attacchi mirati e furto di
personalità e l'esplosione che il mercato sta avendo ci si aspetta comunque
inevitabilmente un aumento nel numero e nella gravità di attacchi a queste
piattaforme.

\subsubsection{Bug} Bug nelle applicazioni installate possono mettere a
repentaglio la sicurezza del terminale. Un esempio recente è stata la
scoperta di una importante vulnerabilità all'attivazione da parte di Google
di una interfaccia web al Market per l'installazione di applicazioni
Android. {E'} presto emerso un problema di \emph{cross-site scripting} o
\emph{XSS} in cui c'era la possibilità di inserire codice javascript nella
descrizione delle applicazioni in modo da innescare l'installazione via
browser, anche remota, di applicazioni sul terminale Android di utenti
collegati allo store.\cite{xss}

Data la mancanza di una conferma obbligatoria sul terminale alla richiesta
di installazione quest'ultima può essere forzata dall'attaccate con una
semplice procedura POST AJAX all'URI di installazione:

\begin{figure}
\begin{verbatim}
/* silently install malicious app to victim phone */
$.post('/install', {
    id: 'com.attacker.maliciousapp',
    device: initProps['selectedDeviceId'],
    token: initProps['token'],
    xhr: '1' }, function(data) {
});\end{verbatim}
\end{figure}

Come si può vedere in fig.~\vref{xss1} e in fig.~\vref{xss2} per
l'esecuzione dell'attacco è sufficiente poi inserire lo script nella form
di descrizione dell'applicazione del Market.

\begin{figure}
\centering
 \includegraphics[width=.9\textwidth]{pics/xss-listing.png}
 \caption{Cross-site scripting, inserimento dello script
 nella descrizione dell'applicazione}
 \label{xss1}
\end{figure}
\begin{figure}
\centering
 \includegraphics[width=.9\textwidth]{pics/xss-screen}
 \caption{Cross-site scripting, esecuzione}
 \label{xss2}
\end{figure}

\subsubsection{\emph{Leaking} di dati} Un tipo più subdolo di bug è quello
in cui il problema non è di tipo implementativo, ma deriva da una
progettazione non particolarmente attenta alle problematiche di sicurezza.
Sicurezza ed usabilità sono spesso in conflitto, non sempre si riesce a
comunicare in modo adeguato i rischi di sicurezza e privacy all'utente e le
interfacce non sono in molti casi adeguate.\cite{whitten1999johnny} Lo
sviluppo di applicazioni sicure può essere inoltre costoso in termini di
tempo e sforzo e se lo sviluppatore dell'applicazione non presta
particolare attenzione alle regole e best practice dell'ambiente per cui
programma può involontariamente causare problemi e compromettere la
sicurezza del dispositivo e dei dati presenti, ad esempio salvando dati
riservati in aree di memoria condivise con altre applicazioni o
memorizzando dati non più necessari. Un recente problema di questo tipo è
venuto alla luce con la scoperta di un file di log su dispositivi Apple con
sistema iOS versione 4.0 contenente una serie di coordinate geografiche e
timestamp. I dati, in chiaro e derivanti probabilmente tramite
triangolazione con antenne GSM, sono aggiornati con regolarità e
documentano, anche se non sempre con esattezza, la posizione del terminale
anche quando non sono attivi i servizi di localizzazione.

Anche se non pone un immediato problema di sicurezza (il file non è
accessibile da applicazioni di terze parti e i dati non vengono trasferiti)
l'esistenza stessa di questi record espone a gravi problemi di
confidenzialità e crea nuove ed impreviste superfici di attacco. Come
mostrato dal programma iPhone Tracker in fig.~\vref{tracker} si può
comunque accedere ai dati connettendo il terminale a un
computer.\cite{iphonetracker} 

\begin{figure}
\centering
 \includegraphics[width=.9\textwidth]{pics/southofengland}
 \caption{iPhone Tracker mostra i movimenti registrati su iOS 4.0}
 \label{tracker}
\end{figure}

\subsection{Contromisure} Non potendo riporre completa fiducia nelle
applicazioni che gli utenti andranno ad installare numerose misure di
sicurezza sono prese all'insegna di un generale principio di isolamento
delle applicazioni per una difesa in profondità. Alcune misure di
mitigazione dei danni possono inoltre essere intraprese una volta accertata
una violazione della sicurezza.

\subsubsection{Macchine virtuali} L'uso di macchine virtuali oltre a
garantire un certo grado di portabilità si presta facilmente ad essere
sfruttato per la costruzione di sandbox naturali per le applicazioni.  Nei
sistemi Android ad esempio ogni applicazione viene eseguita in una separata
macchina virtuale Java, limitando fortemente possibili canali di
comunicazione tra le applicazioni al di fuori del modello di sicurezza
scelto e rendendo possibili controlli a tempo di esecuzione sull'uso non
autorizzato delle risorse hardware del terminale.

Quando l'uso di macchine virtuali si accompagna ad ambienti di sviluppo
quali Java e .NET si gode inoltre di protezione verso alcune classi tipiche
di bug (es. buffer overflow) che possono influenzare in modo negativo la
sicurezza.

\subsubsection{Permessi} I permessi che regolano l'accesso al file system
nei sistemi operativi multi-utente  possono essere riadattati come misura
di non interferenza e isolamento tra le applicazioni nell'accesso alle
risorse su file. Mentre nei sistemi operativi tradizionali \emph{User Id} e
\emph{Group Id} sono associati agli utenti del sistema nei sistemi mobile
che ne fanno uso vengono generati in modo specifico per ogni applicazione
al momento della sua installazione \cite{android,windowsphonesec}

\subsubsection{Capabilities} Mentre i permessi regolano l'accesso alle
risorse nel file system i meccanismi di capabilities regolano l'accesso da
parte delle applicazioni a specifiche API (Application Programming
Interface) del sistema operativo che permettono alle applicazioni l'uso di
determinati sottosistemi come l'accesso alla rete, la possibilità di
effettuare telefonate o l'accesso ai contatti presenti nel telefono. Le
capabilities necessarie all'applicazione vengono definite da parte dello
sviluppatore e possono essere esplicitate all'utente in fase di
installazione per la sua approvazione
(fig.~\vref{capabilities}).\cite{android,Liu:2009:ETA:1882486.1882493}

Nonostante l'utente finale sia il soggetto che ha potenzialmente le
migliori informazioni per fare una scelta informata numerosi studi hanno
evidenziato difficoltà nella valutazione dei potenziali rischi e
conseguenze.\cite{jedrzejczyk2009know,cranor2005security}

\begin{figure}
\centering
 \includegraphics[width=.9\textwidth]{pics/capabilities}
 \caption{Android, valutazione delle capabilities richieste
 a momento di installazione}
 \label{capabilities}
\end{figure}

\subsubsection{Canali di comunicazione} Per quanto arduo sia valutare ed
implementare meccanismi di sicurezza al livello della singola applicazione
il compito si rivela molto più difficile quando si prende in considerazione
i possibili comportamenti emergenti derivanti dalle interazioni tra diverse
applicazioni. Allo scopo di limitare possibili effetti indesiderati molti
sistemi cercano di limitare i canali di comunicazione tra le applicazioni a
meccanismi ben definiti e controllati dal sistema operativo (come il
richiamo di activities esterne nei sistemi Android) o di eliminarli
tout-court come nel caso di sistemi Windows Phone 7 dove non è previsto a
questo scopo l'uso di aree condivise di memoria (in Windows Phone 7, quando
presenti, le memorie di tipo esterno, come già specificato in
\ref{schedesd}, vengono integrate nel file system interno e legate tramite
crittografia allo specifico dispositivo) e la condivisione di dati viene
implementata solamente tramite l'accesso a servizi
cloud.\cite{windowsphonesd,windowsphonesec}

\subsubsection{Installazione centralizzata} L’origine delle applicazioni
può essere un indicatore sull'affidabilità delle stesse. Store
centralizzati per la ricerca e installazione delle applicazioni sono
presenti in molti sistemi per questo motivo oltre che per scopi commerciali
e di controllo della piattaforma . L'accesso da parte degli sviluppatori
viene controllato con policies diverse da piattaforma a piattaforma,
tipicamente il fornitore del servizio si riserva una valutazione sui
contenuti dell'applicazione oltre che sulla sua legalità, facendosi in
qualche modo garante per le applicazioni distribuite.

In alcuni sistemi (iOS) non è possibile per l'utente finale installare
applicazioni al di fuori dello store centralizzato, nei sistemi come
Android dove invece è possibile per l'utente installare applicazioni anche
da terze parti, vi è una maggiore attenzione all'affidabilità e la
reputazione del singolo sviluppatore.

\subsubsection{Firma digitale} Misure come l'installazione centralizzata e
l'esplicitazione delle capabilities sono di scarso conforto se
l'applicazione può venire modificata da terzi prima della sua installazione
sul dispositivo dell'utente. Molti sistemi richiedo quindi forme di firma
digitale dei pacchetti di installazione a garanzia della loro origine e
della loro integrità durante i processi di distribuzione e installazione.
Alla firma digitale da parte dello sviluppatore viene affiancata una firma
da parte del distributore nei sistemi che prevedono la distribuzione
centralizzata delle applicazioni.

\subsubsection{Analisi remota} Classici meccanismi di difesa tipici dei
personal computer come i programmi antivirus richiedono risorse e potenza
non sempre presenti in misura adeguata nei terminali mobili e un controllo
a real time del dispositivo implica un consumo di batteria che limita
fortemente il loro utilizzo attuale. Si è proposto di spostare la
complessità del riconoscimento di malware dal terminale verso servizi
esterni allo scopo di migliorarne prestazioni e scalabilità.
\cite{oberheide2008virtualized,Portokalidis:2010:PAV:1920261.1920313}

L'uso di macchine virtuali permetterebbe l'esecuzione di un numero molto
elevato di repliche di dispositivi su server consentendo l'uso di tecniche
di individuazione di malware a livello
centralizzato.\cite{oberheide2008cloudav}

\subsubsection{Black list e kill switch} Una volta accertata una violazione
di sicurezza del sistema derivante da applicazioni alcune misure di
sicurezza possono essere usate a posteriori per interrompere la violazione
e limitarne per quanto possibile ulteriori effetti dannosi. Sistemi che
dispongono di un controllo centralizzato delle applicazioni installate
prevedono procedure di ``kill switch'', disinstallazione forzata da remoto
delle applicazioni, con successiva rimozione dallo store delle applicazioni
e riconoscimento futuro tramite una black list di applicazioni dannose
riconosciute.

Procedure di wipe (cancellazione) e brick (disattivazione) remote dei
dispositivi sono supportate in modo ufficiale in ambiente Black Berry per
clienti corporate allo scopo di contrastare perdite di dati dovute a
smarrimento o furto del dispositivo.
