Hi all,
Mobile Security Lab members Stefano Vetrini and Daniele Linguaglossa have solved all challenges of the last AHE17 for remote users and published the write-ups on https://github.com/mseclab/AHE17.
Let’s take a look and enjoy. 🙂
Hi all,
Roberto Gassirà (@robgas) and Roberto Piccirillo (@robpicone) will speak Saturday 26 November 2016 at Codemotion Milan 2016 with the talk “Increasing Android app security for free“.
The abstract is:
” Secure Development of Android App sometimes requires the use of third party libraries and external frameworks, often expensive or hard to quickly update if vulnerable.The Android SDK and Google Play Services provide security features and services, that allows a developer to take advantage of security enhancements in order to increase the security level of an application.The talk, starting from real common threats, will show how some of these features can be used into the different versions of Android, until the newest Nougat, to mitigate security risks that could afflict a mobile application. ”
See you in Milan. 🙂
Hi all,
the Mobile Security Lab will give the talk “Android Lollipop for enterprise” Friday April 10 2015 @ DroidConIT 2015 with the following abstract:
“With the latest major release of the Android OS, codenamed “Lollipop”, Google is playing its best cards to enter the enterprise market. Android 5.0 Lollipop has introduced new features, security enhancement and upgraded API for device management; it can now be considered a mature operating system to be used in critical environment and a potential major player in the enterprise world. The talk will explore new features such as the “kill switch” factory reset, the smart lock functionality and other innovative security features and improvements. The session will end with a deep technical discussion on the device management extensions offered by Android; it will focus on the new “managed profile” feature for “containerization technology”, based on the integration of Samsung‘s KNOX platform, which offers the ability to run enterprise applications in a secure protected environment and to keep the working and personal spaces independent from each other.”
Technical details and code examples will be demonstrated during the presentation.
See you in Turin ;).
Sabato 16 Novembre 2013 il Mobile Security Lab ha partecipato al primo DevFest Rome 2013 con un talk sul Key Management fornito dalla piattaforma Android a partire dalla versione 4.3. I temi affrontati durante l’intervento sono disponibili qui, inoltre sono disponibili tutti gli esempi mostrati durante la sessione del Codelab. Molto interessante l’intervento tenuto da Alessandro Panconesi, Professore Dipartimento di Informatica dell’Università La Sapienza, sul tema Big Data dal titolo “BIG DATA in a small world”. Un grazie a tutto il gruppo del GDG Roma.
Dopo un lungo silenzio torniamo a pubblicare i risultati del nostro lavoro, che negli ultimi anni si è concentrato soprattutto su Android.
Il prossimo 16 novembre alcuni dei ricercatori del Mobile Security Lab terranno, nell’ambito del GDG DevFest Rome 2013, un CodeLab che tratterà alcuni aspetti relativi alle problematiche di sicurezza riguardanti il “Key Management” per le applicazioni Android.
Nella prima parte dell’intervento verranno introdotte le tematiche inerenti alla conservazione sicura e protetta del materiale crittografico utilizzato da un’applicazione (per il salvataggio cifrato dei dati, autenticazione con il backend, ecc).
Si proseguirà poi con la descrizione di alcune delle tecniche e delle metodologie di Key Management disponibili nelle varie versioni di Android.
Inoltre, si mostrerà come alcuni di questi meccanismi possano essere compromessi su dispositivi “rooted” o vulnerabili e come l’introduzione del nuovo “Android Key Store”, disponibile dalla versione 4.3 del sistema operativo, fornisca una maggiore resistenza a possibili attacchi.
Il CodeLab si svolgerà alternando sessioni teoriche a sessioni pratiche di coding, durante le quali si terrà una dimostrazione reale di come la compromissione del materiale crittografico sia possibile prima dell’introduzione dell’Android Key Store ma non successivamente.
Chi è interessato può iscriversi qui; i requisiti minimi per seguire il CodeLab sono:
Thanks to the DeepSec team, the presentation of mseclab team “Hijacking Mobile Data Connections 2.0: Automated and Improved”, held in November 2009 in Vienna, has been published at vimeo website.
This presentation explains some techniques, effective still today, to hijack device originated Mobile Data Connections, on any phone equipped with OMA client. Furthermore, automated technique is shown to retrieve victim’s IMSI in order to select the right APN Mobile Operator Configuration; how to perform an SSLSTRIP attack has also been demonstrated.
We’ve just come back from HITB held in Amsterdam; we really had a good time there, and we would like to thank the whole staff for all the effort they put on it :-).
During our presentation “Hijacking Mobile Data Connections: State of Art” we discussed some relatively simple methods to extend the scope of the attack to iPhones/iPod/iPad and Android-based devices.
Regarding Apple products we suggested, as a countermeasure, to update the iPhone to iOS 4; we didn’t give any details to back up this, basically because iOS 4 had been released just a few days before and, apart from noticing some changes in the way it handles remote reconfiguration, we didn’t have time to perform full tests and report the results. In order to avoid any possible misinterpretation, we would like to point out a few additional details on this topic.
Apple’s iOS 4 features a new constraint when installing a Configuration Profile: if the user already has a Configuration Profile, previously installed, he can download a new one, but he cannot install it because an Error box like the one below is shown.
The only way around this is to manually remove the old one (if it’s not locked) and then proceed with the installation.
On the other hand, if the user has no installed Profile, he can download and install the new one in the usual way.
This mechanism protect all users that already have an installed profile; sadly, however, it does nothing to address the vulnerability of users that don’t have any installed profile.
Additionally it must be considered that this raises another issue, having to do with how phone backups are managed. When the user backups his handset, configuration profile is stored in the backups itself, and is recovered when he later restores it; this also applies to locked profiles (PayloadRemovalDisallowed=true), that is, profiles that the user cannot modify or remove. In iPhone OS 3.x the user can work around this by installing a new profile and using it instead of the malicious one. In case of iOS 4, on the other hand, this is not possible anymore (for the reason explained above), so the user has no simple way, apart from reflashing the handset (and losing all his backup data) to restore it to a safe condition. The only solution, at this point, relies on the availability of an older backup, performed before the attack was carried out, and thus not including the malicious configuration profile.
Another point that deserves attention, as shown by the screenshots below, is related to the details of the new configuration that the handset shows to the mobile user before he accepts the it.
As opposed to the iPhone OS 3.1 behavior, iOS 4 presents to the user additional information about the Certificate used for signing the mobileconfig file, e.g. “Subject Name”, “Issuer Name”, “Signature Algorithm” (but also other useful information such as the email address which has been used when requesting the certificate itself), before the mobileconfig installation actually takes place.
By analyzing these information, the user should be able to decide if the configuration source is to be trusted or not. While this provides some useful information, it must be noted that only the first few characters of the strings are displayed.
Hence a smart attacker can forge a long enough common name and email address, to hide the suspect part of the strings.
Furthermore, the security flaws disclosed by Cryptopath blog still works, since a signature-only certificate is valid to sign a configuration profile and Safari root CAs list is used to validate the signature.
So, while iOS gives some degree of additional protection to (probably) most users, we must conclude that there is still an open vulnerability windows, that an attacker can exploit to perform the attack.
We are glad to take part, as speakers, to the first European edition of the “Hack In The Box” security conference, to be held from June 29th to July 2nd in Amsterdam – A big thank to all the HITB staff !
We are going to present our talk “Hijacking Mobile Data Connections: State of the Art”, where we’ll show how it’s possible to hijack “iPhone and Android” data connections. Further information are available at HITB web site.
See you in Amsterdam ;).
We’ve just come back from DeepSec, and we’re really glad to have attended the conference.
We’d like to thank Michael and the whole DeepSec staff for supporting us (and for their great tips!).
For everybody wishing to see the presentation, it is available here.
See you at next DeepSec conference ( and have a good Schnitzel 😉 )
SSL is the de-facto standard for securing communications between a user and a server against third parties. If someone is able to intercept, hijack, or have access in any other way to our network traffic, SSL provides an effective line of defense against eavesdropping.
Basically, all the devices have to do is check that the certificate protecting the connection to site “foo” carries a label (the CommonName Field) stating it belongs to site “foo”, and warn the user if it does not, something that is actually more complicated than it seems. At Black Hat USA 09, during the talk “More Tricks for Defeating SSL” given by Moxie Marlinspike, the “Null Prefix” attack was presented; the security researcher leveraged the fact that the string containing the domain name is represented using ASN.1 encoding as:
[domain_name length] domain_name
while many programs (browers, mail clients, and those used internally by CA’s) use the ‘C’ standard (null terminated-string) instead:
domain_name[\0]
So he generated Certificate Requests for domain names containing a null character (\0 or \x00), for example “paypal.com\0.thoughtcrime.org”, and managed to get them signed by an official Certification Authority; several CAs verified that the request came from “thoughtcrime.org”, while the applications thought the certificate belonged to paypal.com.
The researcher discovered that the applications built with Mozilla NSS Library ( Network Security Services that support SSL/TLS standards) are vulnerable to wildcard certificates generated in the same way. From a certificate request for *\0.thoughtcrime.org, it is possible to obtain a certificate valid for every domain!
Another attack variation consists of generating a certificate for “sitekey.ba\0nkofamerica.com”: the sitekey.ba domain is used for requesting validation but the resulting certificate is valid for the domain “sitekey.bankofamerica.com” for SSL implementations that simply strip the “\0” character.
The attack was fundamentally meant for desktop environments; we immediately wondered how it applies to mobile environments; so we’ve spent some time to test the attacks against some mobile devices. We’ve reported the results of our tests in the following table:
Test Results