SecurityInsider
Le blog des experts sécurité Wavestone

Ce qui a changé pour l’épinglement de certificat à partir d’Android 7 Nougat



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 :
  1. Utiliser un proxy Web, par exemple Burp Suite 
  2. Ajouter l’AC de ce proxy dans le magasin « utilisateur » pour pouvoir intercepter les flux chiffrés SSL/TLS
  3. 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)
  4. 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 :

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).

Aucun commentaire:

Enregistrer un commentaire