La septième mouture d’Android, nommée « Nougat », estampillée « API level 24 », et publiée en août 2016, a introduit des changements importants en matière de sécurité des flux de communication SSL/TLS et plus particulièrement autour de l’épinglement de certificat (certificate-pinning en anglais).
Pour rappel, l’épinglement de certificat est une mesure de sécurisation visant à limiter l’impact de la compromission d’une Autorité de Certification (AC) en définissant précisément côté client quel certificat, ou quelle chaine de certification, est attendu (https://www.riskinsight-wavestone.com/2013/04/epinglez-vos-certificats).
Ce qui change pour les développeurs
De manière simple, jusqu’à présent toute application Android faisait aveuglément confiance aux certificats présents dans les deux magasins disponibles sur un terminal, à savoir la base « système », provenant du projet AOSP https://android.googlesource.com/platform/system/ca-certificates/, et la base « utilisateur », contenant des certificats personnalisés, modifiable par un utilisateur du terminal.
Un développeur devait ainsi appliquer une section de code spécifique dans son application pour effectuer un épinglement : sans expérience dans ce domaine, un développement spécifique pouvait s’avérer être totalement ineffectif (https://www.synopsys.com/blogs/software-security/ineffective-certificate-pinning-implementations/). Nous conseillons d’ailleurs aux développeurs de se baser sur les exemples fournis par l’OWASP s’ils souhaitent mettre en œuvre une telle mesure (https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning).
Désormais, une application compilée avec à minima Android 7 comme version cible ne fera plus confiance par défaut au magasin « utilisateur » et devra explicitement définir les AC reconnues comme valides selon plusieurs possibilités :
- Pour les phases de débogage uniquement : l’application doit dans ce cas être compilée avec l’instruction « debuggable=true» dans le Manifest
- Par domaine
- Pour une liste de domaine
- Pour tous les domaines sauf exception
L’exemple suivant, tiré de ce blog post (https://android-developers.googleblog.com/2016/07/changes-to-trusted-certificate.html), illustre comment déclarer un AC valide pour le domaine « internal.example.com» :
Ce qui change pour les auditeurs/pentesters
Historiquement toute personne souhaitant analyser/auditer les flux Web d’une application et qui n’était pas en mesure de compiler l’application cible devait :
- Utiliser un proxy Web, par exemple Burp Suite
- Ajouter l’AC de ce proxy dans le magasin « utilisateur » pour pouvoir intercepter les flux chiffrés SSL/TLS
- Désactiver la fonction d’épinglement de certificat au sein de l’application, notamment en patchant et recompilant l’application (https://medium.com/@felipecsl/bypassing-certificate-pinning-on-android-for-fun-and-profit-1b0d14beab2b)
- Rediriger les flux du terminal vers le proxy, par exemple via les paramètres de connectivité Wi-Fi
L’étape 2 étant désormais ineffective à partir d’Android 7, plusieurs possibilités s’offrent à un auditeur :
- La plus simple : continuer à utiliser l’ancienne méthode, en utilisant un terminal disposant d’Android 6, à la condition que l’application mobile cible autorise cette version
- Celle un peu complexe : ajouter l’AC du proxy Web dans le magasin de certificat « système » : cette méthode est explicitée ici (https://nvisium.com/blog/2017/07/12/advantages-and-disadvantages-of-android-n-network-security-configuration/) et là (https://blog.jeroenhd.nl/article/android-7-nougat-and-certificate-authorities) et consiste à modifier le fichier contenu dans « /system/etc/security/cacerts/ » de la partition système. Le prérequis notable étant de disposer des droits root sur le terminal cible pour pouvoir remonter la partition en lecture et écriture.
- Celle encore plus complexe mais la plus avancée techniquement : utiliser le framework d’instrumentation dynamique « Frida » (https://www.frida.re/) avec un script générique de désactivation de l’épinglement (https://techblog.mediaservice.net/2017/07/universal-android-ssl-pinning-bypass-with-frida/).
Un exemple détaillé d’application de cette méthode est disponible ici (https://blog.it-securityguard.com/the-stony-path-of-android-%F0%9F%A4%96-bug-bounty-bypassing-certificate-pinning/)
En complexifiant la procédure d’interception des flux par des auditeurs bien intentionnés, ces modifications dans la gestion des certificats introduites à partir d’Android 7 permettent également de complexifier les possibilités d’interception par des personnes mal intentionnées tout en facilitant le travail des développeurs, dans l’objectif global de renforcer la confiance au sein de la plateforme mobile la plus utilisée au monde (https://www.idc.com/promo/smartphone-market-share/os).