Mobile Security threats: a trip

[Today’s smartphones are the new personal computers. The issue of security is becoming difficult to manage for those who, until recently, was accustomed to use his phone to do just one thing: calls.

Today’s smartphones allow you as well to access your bank account and are increasingly the container of all your personal data.

To approach the topic, Meedabyte has therefore thought to host a professional: Cristofaro Mune, an independent security researcher, who, coming back from Confidence 2010, gave us a symbolic journey through the major threats identified so far]

First, thanks to  Meedabyte for inviting me to share a few thoughts on mobile security threats as a guest poster.

Just got back from CONFidence 2010 where I presented my talk on the security of embedded devices, but where I also had the opportunity to attend interesting talks on mobile security here and here.

Travels often leave much room for ideas and considerations, so, on my way back, I caught myself thinking about how much the mobile devices and security threats have evolved in the last few years.

Some years ago…

Not so many years ago, most of the phones were nothing more than embedded devices equipped with closed, real-time operating system and monolithic firmware images.

Users were not able to introduce new software components, and, typical threats were about insecurities in communication protocols or flaws at the operating system level, but no functionalities could be easily added and no new attack vectors could be introduced.

Things began to change when systems started opening to let third parties to develop contents and the post launch installation of applications went possible. The new and expanded capabilities gave rise to new markets: applications, ringtones, backgrounds could then be purchased and installed.

Users got the control of software components that could be added to their mobile phones and multiple viruses and malware strains provided to remind that the user itself was one of the weakest links in the chain.

Many (possibly all?) mobile malware and viruses did not spread through software vulnerabilities, but, instead, relied on the user himself: they needed to be explicitly installed before having their malicious payload activated.

So, malware writers started targeting “human vulnerabilities“: Cabir worm happily spread by being installed by its own victims, even if its installation process warned users three times (see video below)

At the end of the day, differently from what expected by multiple parties, mobile viruses and malware never reached the numbers and pervasiveness of their PC counterparts.

Mobile phones weren’t PC at that time and they lacked features and capabilities interesting enough for users to interact with them frequently, for longer times and in complex ways.

Evolving times

Then the last wave came and we are still in the middle of it: Smartphones, mobile devices providing rich user experience, always-connected, always-on and, mostly important, open; allowing a merge between real lives and online identities, online services and personal information in just one portable device.

Evolving towards complex yet secure systems is a long and possibly painful road, as our desktop systems have shown us during the last two or three decades: the same seems to apply to their mobile counterparts.

One of the first vulnerabilities showing how things were rapidly changing was the one that affected jailbroken iPhones, where you could easily connect to with easy default credentials.

SSH on a mobile phone was pretty uncommon for those days, in facts, SSH daemon was not available on stock iPhones, but got installed during jailbreak process.

A root system account is also present on the iPhone, as in all UNIX-derived operating systems, but, unfortunately, the root password is very weak (“alpine”).

This allowed anyone to break into a jailbroken iPhone that had not its root password changed, just by performing a network scan, while connected to a Wi-Fi hotspot, or against a mobile operator IP address range.

In summary, a smartphone with new shiny PC-like capabilities, with an advanced operating system and great connectivity, could be easily hacked with a technique that was commonly used against poorly secured systems connected online, but, up to that time, was unheard of against mobile phones.

So, the mobile phones started being similar to PCs, but it seemed evident that, at least in this case, the security level had just not kept up with the technological evolution pace.

The experience coming from the PCs had not been really useful for avoiding such a vulnerability, even if the concept of having robust passwords is one of the oldest in the security field.

One could argue that that root password was never meant to be exposed or, even less, used for remote connectivity, but some more defensive design could have suggested, at least, a more resistant password.

That’s the way it goes: security must be thought from its roots all the way up, and the weakest link determines the robustness of the whole system.

This weakness concurred in making the first iPhone worm (Ikee) possible, that targeted jailbroken phones and was caught spreading in Nov. 2009 .

It can be interesting quoting here a forum user that has been identified as the likely author of the Ikee iPhone worm, that commented on the motivations for writing such a worm :

“Why?: Boredom, because i found it so stupid the fact that on my initial scan of my 3G optus range i found 27 hosts running SSH daemons, i could access 26 of them with root:alpine. Doesn’t anyone RTFM anymore?”

Another interesting example, suggesting that the evolution of mobile devices may be not easy from a security perspective, is the method used for the first Android “jailbreak” (RC29 version and lower.

Basically, everything typed on the keyboard was going to be executed in an hidden shell with root privileges!

Again, a shell on a mobile phone was quite a new concept, and surely, not to be expected from a typical mobile phone, but it is something really familiar to technical users in the desktop world.

But a root shell, running under your fingertips, that executed each sent SMS at the highest privileges, is nothing that any security conscious user would have ever wanted on its mobile phone.

The concept of having processes running at the lowest privilege possible is well known in PC operating systems, and well rooted also in Android, but this knowledge, again,  didn’t help in preventing one of the weirdest bug in mobile security history.

Application Markets

With the birth of the Application Store phenomenon, thousands of cool applications, that the geek inside all of us (in different size tho :)) wants to try and install, have been developed.

Malicious application have already been spotted on the Android market: the first known example deleted the content of installed SD card.

But one in particular hit the news some months ago, involving a banking application, that appeared to be more interested in decreasing your bank account rather than helping you in managing it.

This episode fueled many discussions over the Android Market security model, based on permissions accepted by users at installation time, and its effectiveness in coping with possible malware taking advantage of the quite spread “First click, then think” users attitude.

Apple might have also its own problems in successfully recognizing malicious applications during its review process, as recently discussed by a security researcher at BlackHat security conference.

But, any review process that is not very clearly detailed may also arise doubts over its transparency , fairness and legitimacy of its results, and Apple received also its own share of issues and criticisms on the matter.

The entire process can become frustrating for developers that, as a consequence, might be interested in fueling alternative, more open markets, pushing more users towards the “jailbreak” option (necessary because only application signed by Apple can be normally installed on the iPhone).

Without any review process and security measures in place, an open, uncontrolled market may be a very interesting target for malware writers.

This is even more true when users transitioned to the open market from a strictly controlled one, where they felt safe: they might possibly not change their attitude toward application download into  safer ones, more appropriate for the new environment, and malware could get much easier on board.

Two more things things should be kept in mind when speaking about mobile applications and possible measures to improve security:

  • Performing a serious security review of an application requires a significant amount of specialized skills, efforts and time, and this may not scale well, or scale at all, for large markets.
  • On the other hand, final users may not be able to spot anything wrong on their own, if the malware is carefully crafted: checking what a mobile application is really doing under the hood can be not so easy even for experienced users.

Stay connected!

Another relevant change experienced in last few years in the mobile landscape has been the skyrocketing amount of data exchanged through packet-oriented connections.

Wi-Fi and 3G brought, literally, the whole Internet within reach of your fingers on the touch screen of new shiny smartphones.

We are seeing a tighter integration between phones and online services, and Manufacturers are experimenting with new solution and ideas.

But, as often, new solutions bring unexpected side effects: the recent vulnerability disclosed on Palm WebOS can be a good example for clarifying the concept and going further into our exploration.

In WebOS everything is an HTML file, so when you are reading an incoming SMS, what you are actually doing is parsing a web page.

This can be an interesting architectural choice, but if not very carefully designed, it could bring a plethora of web attacks to be applicable to your mobile phone interface.

Have a look at this video to get convinced, where receiving an SMS can have not so nice consequences:

It is fair to say that these vulnerability have been all patched in recent WebOS releases, but this example should be able to convey the idea.

But even more typical solutions and software can have hard times in keeping the user safe from attacks: just think of the browser, your key to the Internet doors.

This year, at the CanSecWest Pwn2Own hacking contest, two security researcher demonstrated an attack that exploited a previously unknown vulnerability in Safari, the iPhone browser.

But not only the attack vector (the browser) was interesting , the attack payload was probably the most remarkable aspect of the whole attack: the two researchers were able to remotely extract the whole SMS database, including the deleted ones.

And this just by making the victim iPhone visit a malicious web page. Pretty scary!

Please, fasten your seatbelt…

Scenarios associated to these (and many others) vulnerabilities can be even more worrying if we think that our personal information, identities, and, lately, also money are at stake.

It’s probably time to think about how to improve the overall security level of mobile ecosystems; sound security reviews and accurate security testing processes should walk their way into the mobile world, similarly to what has already happened in other environments.

But, the road to securing the mobile experience is long and tough: think that there are mobile phones sold today, that do not even have an easy update process clearly accessible to user.


The landing plane interrupted my train of thoughts, bringing me safely on the earth and then, slowly, came to a stop.

I switched on my smartphone as everybody, familiar splash screens and incoming SMS sounds started popping all over the place.

I wondered how many of us were aware of the threats connected to those simple gestures; threats that did not even exist just few years ago and still unfamiliar to many of us.

[Cristofaro Mune is an independent security researcher currently focusing, mainly, on Mobile and Embedded security. In the past he has been Security Research Lead for Mobile Security Lab, discovering, with his team, vulnerabilities in mobile devices, applications and services. Some of his works have been presented at past
important security conferences.  In his experience there are security assessments of IT networks, devices and services for major companies. His main interests are exploitation of embedded architectures, reverse
engineering and he loves everything that is “food for (security) thought” ]

Tweet thisTweet this

read the rest of this entry for the italian translation.

Mobile Security: un viaggio nei rischi

Innanzitutto un grazie a Meedabyte per avermi invitato, come guest poster, a condividere alcune riflessioni sui rischi di sicurezza connessi al mondo mobile.

Sono appena rientrato dalla security conference CONFidence 2010 , dove, oltre a presentare il mio talk sulla sicurezza dei dispositivi embedded, ho avuto l’opportunità di apprezzare alcuni interventi sulla mobile security (qui e qui).

I viaggi lasciano spesso del tempo per metabolizzare idee e concetti, così, durante il viaggio di ritorno mi sono trovato a riflettere su quanto, negli ultimi anni, si fossero evoluti sia i dispositivi mobili che i rischi di sicurezza ad essi collegati.

Alcuni anni fa…

Non molti anni fa, la maggior parte dei telefoni cellulari non erano niente di più che dispositivi embedded, dotati di sistemi operativi real-time, closed, che utilizzavano immagini firmware monolitiche.

Gli utenti non erano in grado di introdurre componenti software aggiuntive ed i tipici rischi erano collegati a problemi di sicurezza nei protocolli di comunicazione o al livello del sistema operativo, tuttavia, non essendo possibile aggiungere facilmente nuove funzionalità, nessun ulteriore  vettore di attacco poteva essere introdotto oltre a quelli già esistenti.

Le cose iniziarono a cambiare quando I sistemi operativi iniziarono ad “aprirsi”, offrendo la possibilità a terze parti di sviluppare contenuti e l’installazione “post-launch” delle applicazioni divenne possibile.

Le nuove e migliorate possibilità crearono anche nuovi mercati: divenne infatti possibile acquistare, e quindi installare, applicazioni, suonerie e sfondi.

L’utente aveva il controllo delle componenti software che potevano essere aggiunte al proprio “handset”, mentre molteplici famiglie di virus e malware provvedevano a ricordarci che l’utente stesso era uno degli anelli più deboli della catena.

Molti (se non tutti) malware e virus per dispositivi mobili non si diffondevano grazie a vulnerabilità del software, ma, invece, si affidavano all’utente stesso: infatti questi dovevano essere installati manualmente (dall’utente) affinché potessero svolgere le funzioni malevole previste dal loro codice.

Quindi gli sviluppatori di malware e virus iniziarono a prendere di mira le “vulnerabilità umane”: Cabir, ad esempio, si diffondeva con facilità, sebbene il suo processo d’installazione prevedesse addirittura 3 avvisi di sicurezza, che l’utente doveva accettare esplicitamente (vedi video):

Alla fine, a differenza di quanto atteso da molti, i malware e virus per dispositivi mobili non hanno mai raggiunto il numero e la pervasività dei virus esistenti per PC.

A quel tempo infatti, i dispositivi mobili infatti non erano affatto dei PC: non ne avevano le potenzialità e mancavano le attrattive sufficienti a far sì che gli utenti interagissero con essi frequentemente, più a lungo ed in modalità complesse.


Infine arrivò l’ultima evoluzione, che stiamo ancora vivendo oggi: gli smartphone, in grado di assicurare una “user experience” coinvolgente, sempre connessi, sempre disponibili e, soprattutto, “open”; che permettono di immergere le nostre identità online nella vita di tutti i giorni, unendo servizi online ed informazioni personali in unico dispositivo portatile.

La strada che porta all’evoluzione verso sistemi complessi ma sicuri è spesso lunga e difficile, così come si è appunto dimostrata essere per i desktop PC negli ultime due o tre decenni: lo stesso sembra essere valido anche per i dispositivi mobili in generale, e per gli smartphones in particolare.

Una delle prime vulnerabilità che mostrava come come le cose stessero cambiando rapidamente era quella che interessava gli iPhone sottoposti alla procedura di “jailbreak”, a cui era possibile connettersi utilizzando delle semplici credenziali di default.

Effettuare una connessione SSH con un telefono era una cosa ancora decisamente poco comune, infatti, il demone SSH non era disponibile sugli iPhone originali messi in commercio, ma veniva installato come parte della procedura di “jailbreak”.

Un account di root è disponibile sull’iPhone, così come tutti i sistemi operativi derivati da UNIX, ma, sfortunatamente, dotato di una password molto debole (“alpine”).

Questo permetteva a chiunque di “bucare” un iPhone in cui non fosse stata modificata la password di root, semplicemente effettuando un scansione di rete mentre si era connessioni ad un hotspot Wi-Fi oppure rivolta verso lo spazio d’indirizzamento IP di un operatore mobile.

In sostanza, uno smartphone con la potenza di un PC, dotato di un sistema operativo avanzato e grande possibilità di connettività, poteva essere attaccato con una tecnica comunemente utilizzata con sistemi connessi in rete e dotati un basso grado di sicurezza, ma che, fino a quel momento, non era mai stata utilizzata per un “telefono”.

Quindi i telefoni iniziano ad apparire simili ai PC ma, almeno in questo caso particolare, apparve evidente come il livello di sicurezza non fosse riuscito a tenere il passo dell’evoluzione tecnologica del sistema.

Infatti l’esperienza acquisita con i PC non era stata particolarmente utile ad evitare la vulnerabilità, sebbene il concetto dell’uso di password robuste sia uno dei più antichi nel campo della sicurezza informatica.

Si potrebbe argomentare che la password di root non era stata pensata per essere distribuita o, men che meno, utilizzata per connettività remota, ma un design più “difensivo” avrebbe potuto suggerire, perlomeno,  una password più resistente.

Purtroppo, la sicurezza di un sistema va progettata dalle basi fino agli ultimi dettagli ed è sempre il punto più debole a determinarne la robustezza.

Questa vulnerabilità ha, inoltre, permesso la creazione del primo “worm” per iPhone (Ikee), rilevato per la prima volta nel Novembre 2009 .

E’ interessante citare qui un utente di un forum che è stato indicato come il probabile autore del worm Ikee, a proposito delle motivazioni che lo hanno spinto a scrivere il worm (in inglese):

“Why?: Boredom, because i found it so stupid the fact that on my initial scan of my 3G optus range i found 27 hosts running SSH daemons, i could access 26 of them with root:alpine. Doesn’t anyone RTFM anymore?”

Un altro esempio interessante, che suggerisce come l’evoluzione degli smartphone possa risultare accidentata da un punto di vista di sicurezza, è il metodo utilizzato per il primo “jailbreak” di Android (versione RC29 e precedenti) .

In pratica, qualunque contenuto digitato veniva eseguito in una shell nascosta con privilegi di root!

Di nuovo, una shell su un “telefonino”, un concetto abbastanza nuovo, qualcosa di inatteso per il tipico dispositivo mobile, ma sicuramente familiare per utenti tecnici in ambito desktop.

Ma una shell di root, disponibile sotto le dita, che esegue con il massimo dei privilegi ogni SMS inviato, è una cosa che nessun utente attento alle problematiche di sicurezza avrebbe mai voluto avere sul suo smartphone.

Il concetto di eseguire processi con il livello minimo di privilegi possibile è ben noto nei sistemi operativi per PC, e anche ben radicato in Android, ma questa conoscenza, di nuovo, non è stata d’aiuto nel prevenire uno dei bug più curiosi nella storia della sicurezza dei dispositivi mobili.

Application Markets

Con la nascita del fenomeno degli Application Store, sono state sviluppate migliaia di applicazioni interessanti, che il “geek” presente dentro ciascuno di noi (anche se in misura variabile :)) vorrebbe sperimentare ed installare.

Applicazioni malevole sono già state individuate in passato nell’Android market: il primo esempio conosciuto cancellava il contenuto delle SD card installate.

Ma un caso in particolare, qualche mese fa, ha ricevuto consistente attenzione da parte dei media: un applicazione di banking che sembrava più interessata a diminuire il conto corrente bancario, piuttosto che a fornire un aiuto per la sua gestione.

Questo episodio ha ravvivati molte discussioni relative al modello di sicurezza del modello di sicurezza di Android, basato su autorizzazioni fornite dall’utente al momento dell’installazione, e alla sua efficacia nel contrastare del malware che tragga vantaggio dalla abitudine del “Prima clicca, poi pensa” abbastanza diffusa tra gli utenti.

Anche Apple potrebbe avere qualche difficoltà nel riconoscere con successo applicazioni malevole durante il suo processo di review, almeno stando a quanto indicato recentemente da un security researcher alla conferenza di sicurezza BlackHat.

Ma ogni processo di review le cui regole non siano chiaramente dettagliate può generare dubbi sulla sua trasparenza, equità e legittimità dei risultati, e anche Apple ha ricevuto la sua razione di problemi e critiche  in merito.

L’intero processo di review può divenire un’esperienza frustrante per gli sviluppatori, che come conseguenza, potrebbero essere interessati ad alimentare market alternativi e più aperti, spingendo così un numero maggiore di utenti verso l’opzione del jailbreak (necessaria poiché solo applicazioni firmate da Apple possono essere normalmente installate sugli iPhone).

In assenza di un adeguato processo di review e di misure di sicurezza, un mercato aperto e non controllato, potrebbe essere un ambiente molto interessante per gli sviluppatori di malware,

Questo può risultare ancora più vero nel caso in cui gli utenti migrati nel mercato open provengano da uno strettamente controllato, dove si sentivano sicuri: questi infatti potrebbero non cambiare le loro abitudini di download delle applicazioni, non adottando quindi accorgimenti aggiuntivi e più appropriati per la nuova situazione, e del malware potrebbe più facilmente essere installato e diffondersi.

Due ulteriori fattori andrebbero non trascurati nelle considerazioni relative ad applicazioni mobile e a possibili misure per l’innalzamento del livello di sicurezza:

  • Effettuare una seria analisi di sicurezza di un’applicazione richiede quantità significative di abilità specialistiche, risorse e tempo, e questo può essere una soluzione non facilmente scalabile, o affatto scalabile, per market di grandi dimensioni.
  • D’altra parte, gli utenti finali potrebbero non essere in grado di rilevare anomalie in maniera autonoma, se il malware è stato creato con curo: verificare cosa accade effettivamente a basso livello può non essere affatto semplice anche per utenti esperti.


Un’altra rilevante novità degli ultimi anni nel panorama “mobile” è stata l’eccezionale aumento della quantità di dati scambiati su connessioni a pacchetto.

Il Wi-Fi e le connessioni 3G hanno reso l’intera Internet letteralmente a portata di dito, sui touchscreen di nuovi e lucenti smartphone.

Stiamo assistendo ad un’integrazione sempre maggiora tra il telefono, inteso come dispositivo, ed i servizi disponibili su Internet, mentre i costruttori continuano a sperimentare nuove idee e soluzioni.

Ma, abbastanza speso, soluzioni innovative possono avere “effetti collaterali” inattesi: la vulnerabilità recentemente pubblicata sul WebOS di Palm, può essere un buon esempio per chiarire il concetto e continuare la nostra esplorazione

In WebOS tutto è un file HTML, quello che accade in realtà per la lettura di un SMS in arrivo è il “parsing” di una pagina web.

Questa può essere una scelta architetturale molto interessante, ma se non progettata molto attentamente, potrebbe portare un’elevata quantità di attacchi tipici delle applicazioni e dei client web, direttamente sugli smartphone.

Il video di seguito può risultare illuminante, dove la ricezione di un SMS può avere conseguenze non tanto piacevoli:

Per correttezza va detto che tutte le vulnerabilità  interessate dal video sono state corrette da Palm nelle recenti release di WebOS, ma questo esempio dovrebbe comunque riuscire a veicolare il concetto di base.

Ma anche software e soluzioni meno atipiche possono avere delle difficoltà nel proteggere gli utenti da attacchi: è sufficiente pensare al browser, la chiave delle porte di Internet.

Durante l’hacking contest Pwn2Own, svoltosi quest’anno durante la security conference CanSecWest 2010, due security researcher hanno dimostrato un attacco he sfruttava una vulnerabilità precedentemente non nota di Safari, il browser dell’iPhone.

Ma non solo il vettore di attacco (il browser) era interessante, infatti il payload utilizzato è stato probabilmente l’aspetto più considerevole di tutto l’attacco: I due researcher sono stati in grado di estrarre da remoto l’intero contenuto del database degli SMS, inclusi quelli cancellati.

E questo solo facendo vistare una pagina web all’iPhone oggetto dell’attacco: decisamente preoccupante!

Allacciare le cinture…

Gli scenari associati a queste (e molte altre) vulnerabilità possono risultare ancora più preoccupanti se riflettiamo sulla posta in gioco: le nostre informazioni personali, le identità e ultimamente, anche i soldi.

E’ probabilmente giunto il momento di pensare a come migliorare il livello di sicurezza complessivo di tutto l’ecosistema “mobile”: solide analisi di sicurezza e processi che prevedano accurati security testing dovrebbero fare ingresso nel mondo mobile, così come accaduto precedentemente in altri ambienti.

Ma la strada per rendere sicura la “mobile experience” è lunga e non semplice: basti pensare che esistono telefoni, venduti ancora oggi, che non hanno un processo di aggiornamento semplice ed immediatamente disponibile all’utente.


L’atterraggio interrompe il corso dei pensieri e mi riporta a terra in maniera sicura; l’aereo lentamente si ferma.

Accendo il mio smartphone, come tutti, mentre tutt’intorno compaiono sfondi familiari su piccoli schermi e si sente il suono di SMS in arrivo.

Penso a quanti di noi siano consapevoli dei rischi collegati a quei semplici gesti: rischi che neanche esistevano ancora pochi anni fa e che risultano ancora poco familiari a molti di noi.

[Cristofaro Mune è un indipendent security researcher focalizzato, principalmente, sulla sicurezza Mobile and Embedded. In passato è stato Lead researcher per  Mobile Security Lab, scoprendo, con la sua squadra, varie vulnerabilità nei dispositivi mobili, applicazioni e servizi. Alcune sue opere sono state presentate in passato in
importanti conferenze di sicurezza. Nella sua esperienza ci sono valutazioni di sicurezza su reti, dispositivi e servizi per le grandi imprese. I suoi interessi principali sono l’exploit di architetture embedded, la reverse
engineering e ama tutto ciò che è “food for (security) thought” ]


About meedabyte

Strategist, Consultant and Collaborative Pathfinder


  1. Pingback: The Evolution of Mobile Threats « Mocana DeviceLine Blog

  2. Thank goodness some bloggers can still write. Thank you for this piece.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: