XMCO a pu assister à l’édition 2019 de l’Insomni’hack qui s’est tenue au centre Palexpo de Genève le 21 et 22 mars dernier (et également jusqu’au 23 mars au petit matin pour les plus courageux).
L’évènement proposait une variété d’activités permettant aux professionnels autant qu’aux passionnés de sécurité informatique d’y trouver leur compte. Ainsi, en plus des conférences variées qui s’étalaient sur 2 ou 3 pistes techniques ou business, 2 compétitions se sont tenues en parallèle les soirs. Un CTF de type Jeopardy classique rassemblant de très grosses équipes de CTF (p4, Dragon Sector, ou encore LC↯BC) s’est déroulé du vendredi soir au samedi matin. Un challenge original « Boss of the SOC » pour les habitués des analyses d’incident a également eu lieu le jeudi après-midi en même temps que les conférences.
En attendant le prochain numéro de notre ActuSécu, nous vous proposons de revenir sur quelques conférences qui nous ont marquées. Les supports de présentation utilisés lors des conférences sont présents à l’adresse suivante via les retweet des conférenciers :
Growing Hypervisor 0day with Hyperseed – Daniel King, Shawn Denbow, Microsoft
SLIDES
Dans cette première présentation, Shawn Denbow revient sur une expérience interne de fuzzing menée sur l’hyperviseur de Microsoft, Hyper-V, et sur les résultats de celle-ci. La conférence est assez pointue et détaille le fonctionnement d’Hyper-V dans ses grandes lignes, avant d’expliquer les points d’entrée que l’équipe a utilisés pour le fuzzing.
Shawn commence par mettre en évidence la criticité des vulnérabilités susceptibles d’impacter les systèmes liés à la virtualisation en explicitant des récompenses de Bug Bounty : jusqu’à 250 000$ pour une compromission kernel vers hyperviseur, 150 000$ pour une compromission de l’hôte en mode utilisateur seulement, et 25 000$ pour une fuite d’information.
Il explique également pourquoi s’être attaché à l’étude du mécanisme des Hypercalls dans Hyper-V, qui sont une pierre angulaire d’Hyper-V. Les Hypercalls sont en effet accessibles depuis les noyaux supportant ce type de communication (les noyaux Windows et Linux le supportant). Ils sont bien documentés, et ils permettent de manipuler une grande variété de formats d’entrée et de sortie.
En plus de ces caractéristiques adaptées pour le fuzzing, les Hypercalls permettent à des systèmes virtualisés de communiquer avec des hyperviseurs ou d’autres systèmes virtualisés à des niveaux plus élevés (dans le cadre de la virtualisation imbriquée permise par Hyper-V). Il est donc théoriquement possible de trouver des vulnérabilités sur ce mécanisme permettant de compromettre l’hyperviseur au niveau 0 (et donc de compromettre l’intégralité des systèmes virtualisés sous-jacents).
La complexité technique de l’exposé augmente alors avec l’introduction du modèle de sécurité d’Hyper-V avec le concept de niveau de confiance. Heureusement, des schémas très clairs accompagnent l’exposé. 2 niveaux de confiance sont présents pour chaque niveau d’abstraction supplémentaire ajouté. Le premier est un mode privilégié (VTL1 – secure mode) qui contrôle les ressources allouées au deuxième mode (les systèmes du niveau de confiance inférieur VTL0 ou normal mode).
Après avoir détaillé ces bases d’Hyper-V, Shawn entre alors dans le vif du sujet avec une description du mécanisme des Hypercalls. Ils fournissent une interface des systèmes virtualisés avec l’interface Hyper-V et permettent une communication entre systèmes à des niveaux différents de virtualisation et de protection.
Les Hypercalls doivent être invoqués depuis le noyau (ring 0) et via les instructions processeur adaptées : vmcall pour Intel VMX et vmmcall pour ADM SVM.
Des conditions spécifiques et complexes doivent également être remplies pour que les appels au mécanisme soient réussis. Elles sont décrites dans le support de présentation pour les plus motivés.
Shawn explicite alors la méthodologie de fuzzing employée par la suite. Notamment, toutes les configurations de fuzzing entre les différents niveaux de virtualisation et privilèges (par exemple : analyse des résultats depuis une partition userland de niveau 2 vers le noyau, vers l’hyperviseur de niveau 1, vers l’hyperviseur de niveau 0 et vers une partition de niveau L1).
La technique de fuzzing employée est une technique qualifiée de “format-aware”, c’est à dire qu’elle tente d’inférer des formats d’entrée à partir des exceptions récoltées au fur et à mesure du déroulement du fuzzing. Les mutations appliquées sur les données sont des mutations classiques dans ce cadre (mutation aléatoire, sliding, bitflip, masque, …).
Après avoir montré quelques bouts de code C++ et l’architecture du programme résultant hyperseed.exe (couplé avec le driver noyau hyperseed.sys), le conférencier termine avec des statistiques sur l’ensemble de l’opération. Au total, 16 vulnérabilités ont été trouvées, dont 8 élévations de privilèges ou exécutions de code, et 8 dénis de service. Parmi celles-ci, 2 sont qualifiées pour le Bug Bounty Hyper-V, pour une valeur théorique de 215 000$. La CVE CVE-2018-8439, une élévation de privilège depuis un invité L1 vers un hôte VTL0, en constitue une grosse partie (valeur théorique de 200 000$).
The Evolution of Cloud Threats – Paolo Passeri, Netskope
SLIDES
Venu pour représenter Netskope, l’un des sponsors de cette édition de la conférence, Paolo Passeri a présenté une conférence au sujet de l’évolution des menaces liées au cloud computing.
Le conférencier a commencé par constater que les entreprises se tournent de plus en plus vers des solutions de cloud computing comme le PaaS (Platform as a Service) ou l’IaaS (Infrastructure as a Service). Ces solutions leur permettent de ne pas avoir à gérer l’aspect physique des serveurs. Il peut être avantageux financièrement selon les besoins de l’entreprise.
Paolo Passeri a ensuite expliqué que les pirates suivent la même tendance et utilisent de plus en plus de services de cloud computing pour mener à bien leurs attaques. Le conférencier a présenté plusieurs pratiques de pirates exploitant les services de cloud computing.
Ces derniers ont par exemple de plus en plus tendance à héberger leurs serveurs de contrôle ou à stocker leurs outils sur des serveurs loués chez des fournisseurs de cloud connus. Ces fournisseurs hébergeant de nombreuses applications légitimes, une certaine confiance est accordée au trafic à destination des plages d’adresses leur appartenant.
Le conférencier a par la suite donné des exemples d’attaques dites « hybrides ». Ces attaques mêlent des vecteurs d’infection classiques, comme le phishing, avec l’utilisation de ressources dans le cloud.
Parmi les risques induits par la généralisation des solutions de cloud computing, on relève la facilité de conduire certaines attaques de phishing. Paolo Passeri a donné l’exemple d’une attaque de phishing ciblant les utilisateurs d’Office 365 : la page de phishing était hébergée sur Microsoft Azure. Les cibles de cette attaque se retrouvaient donc face à une mire d’authentification pour Office 365, hébergée sur un site dont le certificat SSL appartenait à Microsoft.
Le cloud computing ne révolutionne pas tous les concepts de l’informatique, mais son adoption massive par les entreprises attire de plus en plus l’attention des potentiels attaquants.
Building a flexible hypervisor-level debugger – Mathieu Tarral, F-Secure
SLIDES
Cette seconde conférence présente un outil, (py)vmidbg, permettant le débogage au niveau hyperviseur. Mathieu Tarral, chercheur chez F-Secure, avait précédemment présenté un outil similaire r2vmi à la hack.lu 2018. Cet outil s’interfaçait spécifiquement avec radare2, et a été étendu pour s’interfacer avec tous les frameworks de reverse-engineering pouvant agir en tant que frontend GDB (incluant GDB, radare2, IDA, Visual Studio).
Mathieu commence par revenir sur les limites des débogueurs en espace utilisateur et en espace noyau. Il insiste notamment sur le fait que le débogage d’applications modifie l’exécution normale du programme analysé (observer effect) et est susceptible d’être complexifié par divers mécanismes de défense (Windows PatchGuard, Protected Media Path, Windows 10 Virtual Secure Mode, …). De plus, le debug de certaines fonctions bas niveau interagissant avec la pile réseau par exemple est susceptible de créer des boucles infinies au niveau de l’agent de debug (dans le cas d’un agent de debug communiquant à la fonction déboguée via TCP), et finalement certains OS manquent de fonctionnalités permettant le débogage (par exemple des OS spécifiques comme unikernel).
Après avoir listé les outils existants et leurs limites, le conférencier explicite les briques qu’il a rassemblées pour la création d’un débogueur au niveau hyperviseur agnostique : le frontend GDB permet l’interface avec des outils de reverse engineering et la bibliothèque libvmi qui abstrait les fonctionnalités des hyperviseurs Xen et KVM.
Le fait de se placer au niveau -1 permet une analyse complète du niveau 0, c’est à dire du système d’exploitation, en restant hors de portée des mécanismes de protection mis en place par l’application déboguée. Dans plusieurs contextes, cela peut se révéler utile, voire nécessaire: analyse de malware, fuzzing ou encore débogage des fonctionnalités sécurisées du noyau de Windows 10.
Le créateur des outils pyvmidbg et KVM-VMI effectue ensuite une démonstration montrant comment une automatisation du débogage peut être mise en place via des scripts Python utilisant l’outil.
Enfin, il aborde dans le reste de la conférence les différents types de points d’arrêts (breakpoints) qui peuvent être placés par l’”hyper”débogueur. Les “hyper”breakpoints correspondants aux brakpoints “classiquement” rencontrés lors de session de débogage présentent tous certaines limitations intrinsèques. C’est pourquoi Mathieu termine l’exposé en détaillant un mécanisme complexe palliant l’ensemble des inconvénients simultanément : les “Advanced SoftHyperBreakpoint” avant de lancer un appel aux contributions en évoquant les points clés du projet ainsi qu’une potentielle réécriture en RUST.
Let’s hack the IoT Hub with Pwnhub dudes: IoT Hub Exploitation and countermeasure – Jisub Kim, Kanghyun Choi
Dans cette conférence, les 2 coréens de l’équipe de CTF $swag reviennent sur leurs expériences sur divers objets connectés et notamment sur des produits commerciaux de type « IoT Hub » permettant de connecter un ensemble d’appareils.
Ils montrent brièvement les parts de marchés de l’IoT en augmentation afin de justifier leur recherche.
Ils commencent en évoquant les difficultés qui sont susceptibles d’apparaître à la première étape de toute analyse d’un composant IoT : la récupération du firmware. Dans le cas de l’objet qu’ils décrivent, impossible de récupérer l’image depuis le site du fabricant. Impossible également d’obtenir l’image via l’interception d’une mise à jour de l’appareil, ni même via le port série COM qui n’est plus accessible. Dessouder la flash n’est pas une option dans la mesure où il faut disposer d’appareils coûteux et sophistiqués pour poursuivre l’analyse.
Finalement, ils constatent que le système de boot utilisé est un système très commun dans l’IoT. Il s’agit d’U-boot. Ils découvrent que ce dernier, lorsqu’une erreur survient lors du boot, provoque l’apparition d’une CLI permettant l’interaction avec l’appareil et la récupération du firmware (CVE-2018-19916).
Ils expliquent alors leur démarche d’établissement d’un modèle de menace sur l’IoT selon 3 axes. Ainsi, ils détaillent les différentes vulnérabilités envisageables selon les critères du déni de service, de la fuite d’information et de la prise de contrôle.
Avant de plonger dans le grand bain de la 0-day, ils fournissent des exemples d’exploitation de 1-day. Notamment, ils évoquent le fait que beaucoup de CVE proviennent de l’absence de vérification des tailles des chaînes (aboutissant à des buffer overflows ou corruptions de mémoire variées), de l’absence de mécanisme anti-rejeu mais également de l’utilisation de communications insécurisées permettant l’interception par un attaquant. Ils prennent l’exemple d’une corruption de la mémoire dans le produit commercial « SmartThings hub » et celui d’une attaque par rejeu dans le produit « Insteon hub ».
Pour finir, ils se basent sur les éléments déjà remontés en 1-day pour trouver une 0-day dans un produit commercial en exploitant un buffer overflow dans un parseur de cookie au sein du serveur web du produit.
Ils encouragent le public à participer à des programmes de bug bounty ou des CTF.
These are the Droids you are looking for : practical security research on Android – Elena Kovakina, Google
La conférencière Elena Kovakina de chez Google a animé une conférence au sujet d’Android. Elle a d’abord abordé quelques généralités à propos du système d’exploitation, puis a détaillé le contenu des rapports de bugs dans lesquels se trouvent de nombreuses informations pertinentes dans le cadre d’un audit ou d’une enquête forensique.
La chercheuse a introduit sa conférence en rappelant qu’Android est basé sur le noyau Linux et utilise un système de fichier similaire. Elle a ensuite détaillé les différents types d’applications que l’on peut retrouver sur un appareil Android:
- les applications système
- les applications utilisateur
- les applications super-utilisateur.
Les applications système sont préinstallées sur les appareils et ne peuvent pas être désinstallées par l’utilisateur. Elles disposent d’un important niveau de privilèges.
Les applications utilisateur peuvent être préinstallées sur l’appareil, mais les utilisateurs ont la possibilité de les désinstaller ainsi que d’en installer de nouvelles depuis des plateformes de téléchargement. Elena Kovakina n’a pas manqué de rappeler qu’il est prudent de n’installer d’applications que depuis la plateforme officielle de Google, le Google Play Store. Ces applications n’ont aucun privilège par défaut et peuvent demander d’utiliser certaines fonctionnalités de l’API Android. C’est l’utilisateur qui choisit quelles permissions il souhaite accorder à telle ou telle application.
Les applications super-utilisateur ont les mêmes caractéristiques que les applications utilisateur, à la différence qu’elles nécessitent l’accès au compte super-utilisateur (root) pour fonctionner. Le compte root est par défaut désactivé et inutilisable pour des raisons de sécurité sur la plupart des appareils Android. Les applications super-utilisateur permettent d’accéder à des fonctionnalités avancées, comme faire des sauvegardes de certains fichiers du système, mais elles exposent l’utilisateur à de nouveaux risques.
La conférencière a ensuite décrit les efforts de Google pour endiguer les malwares sur son système d’exploitation mobile. La firme de Mountain View a en effet intégré un outil d’analyse de malware à sa plateforme de téléchargement il y a quelques années. Nommé Google Play Protect, cet outil se charge de scanner les applications téléchargées sur l’appareil afin de détecter d’éventuels comportements suspects. Il est en mesure de bloquer l’installation d’applications malveillantes, de les désinstaller si elles ont échappé au premier scan ainsi que de les bloquer si la désinstallation est impossible.
Concernant l’accès au compte root, Elena Kovakina ne bannit pas totalement cette pratique. Elle la considère acceptable si l’accès est obtenu en installant un système personnalisé au sein duquel le compte root est proprement intégré. La chercheuse s’oppose par contre à l’accès au compte root par des exploits, ces derniers laissant des portes ouvertes pour les attaquants qui peuvent à leur tour utiliser l’exploit pour obtenir l’accès super-utilisateur.
La deuxième partie de la conférence traitait des rapports de bugs générés par Android lors du plantage d’une application. Ces fichiers peuvent également être générés à n’importe quel moment depuis les options de développement du système.
La chercheuse a précisé la nature d’Android ne permet pas d’accéder à ces fichiers sans le consentement de son propriétaire. Il est en effet nécessaire d’avoir un accès à l’appareil déverrouillé pour récupérer ces fichiers.
La conférencière a mis un échantillon de rapport de bug Android à disposition de l’audience afin d’organiser un petit challenge forensique. Elle s’en est servi pour lister les différents types d’informations disponibles dans ces rapports:
- historique de localisation
- paramètres du système
- synchronisations et connexions
- données des applications
- alertes du système
- fichiers de journalisation
- fichiers d’erreurs
- etc.
La chercheuse a su montrer efficacement au travers de petits scénarios qu’il est possible d’extraire beaucoup de données pertinentes des rapports de bugs d’Android.
Turning your BMC into a revolving door: the HPE iLO case – Alexandre Gazet, Fabien Perigaud, Joffrey Czarny
SLIDES
Dans cette dense conférence, Fabien Perigaud et Alexandre Gazet reviennent sur leur périple au travers du BMC (Baseboard Management Controller) HP iLO. Ils expliquent notamment les étapes et les vulnérabilités qu’ils ont trouvées sur les versions 4 et 5 d’iLO et comment une porte dérobée persistante peut être installée sur des systèmes vulnérables.
Alexandre commence par une description de ces systèmes singuliers néanmoins fréquemment présents dans de grosses infrastructures. La puce iLO est en effet présente sur une majorité de serveurs HP depuis plus de 10 ans. Il s’agit d’un système autonome comprenant un processeur ARM, une mémoire flash NAND et une RAM. Ce système est lancé au démarrage du serveur, et met en place un secure boot depuis la version 5.
En 2016, peu de vulnérabilités ayant un impact significatif sur ce composant sont exploitables. C’est une motivation des travaux de recherche de l’équipe. Ces travaux conséquents (plus de 200 jours), leur ont permis de bien comprendre le fonctionnement interne du système et de développer une panoplie d’exploits et d’outils spécifiques pour l’extraction d’informations, l’analyse des systèmes ou l’implant de porte dérobée.
Ils ont donné lieu à une première série de conférences sur le cas iLO4 en 2018.
Fabien revient alors sur la démarche et les vulnérabilités identifiées sur cette version plus ancienne. Il décrit l’analyse du firmware extrait depuis le site HP et sur l’analyse de ses composants : bootloader, kernel, image userland, …. Cela donne lieu à l’écriture de loaders spécifiques pour IDA Pro. Une fois les formats bien reconnus et compris, les services et processus (appelés task) lancés peuvent être analysés de manière plus détaillée. 49 tâches utilisateurs s’exécutent simultanément sur un iLO4. Parmi elles, on retrouve notamment un serveur web et un serveur SSH.
Un buffer overflow basique de CVSS 9.8 impacte le serveur web (CVE-2017-12542). Grâce à cette vulnérabilité, un attaquant non authentifié est capable de compromettre la puce iLO pour s’en servir de pivot. En analysant la communication entre l’hôte et la puce iLO, les trois auteurs se sont aperçus que le noyau du système hôte était représenté dans une tâche utilisateur sur le système iLO. Cela impliquant une lecture et écriture directe dans la mémoire noyau de l’hôte, Fabien effectue une démonstration dans laquelle la mémoire noyau du système hôte est réécrite afin d’engendrer l’apparition d’un Shell accessible en TCP avec des droits root.
Il conclut cette partie avec une autre vulnérabilité du même type (CVE-2018-7105) découverte plus récemment par une personne de l’ANSSI et concernant la tâche SSH. Cette vulnérabilité n’est toutefois pas aussi facilement exploitable car elle nécessite la possession d’un compte administrateur sur le système.
La partie suivante de la conférence s’attache à l’élaboration d’une porte dérobée persistante une fois la puce iLO compromise. Il s’avère qu’un mécanisme de vérification de l’intégrité du noyau du système d’exploitation sur la puce est présent. Toutefois, des commandes sur la puce peuvent être exécutées pour écrire directement dans la mémoire flash SPI, réécrivant ainsi le bootloader en supprimant le code se chargeant de la vérification de l’intégrité du noyau pour pouvoir remplacer le noyau du système par un noyau ne vérifiant pas l’intégrité des tâches utilisateur lancées ultérieurement. Ainsi, il devient possible d’ajouter une tâche « porte dérobée » dont l’intégrité ne sera pas vérifiée par le noyau modifié (dont l’intégrité ne sera elle-même pas vérifiée par le bootloader modifié).
Les conférenciers s’amusent finalement à évoquer des cas d’utilisation de la porte dérobée ajoutée (modification du système hôte, utilisation de NotPetya …) et indiquent que tous leurs outils sont disponibles sur le dépôt Github ilo4_toolbox.
Après avoir détaillé des scénarios de compromission en provenance des tâches de la puce iLO, les auteurs s’attachent aux possibilités de compromission depuis le système hôte. Ils montrent que de nombreuses commandes sont accessibles via la tâche CHIF sur l’iLO depuis le système hôte, et que des commandes dangereuses permettent de mettre à jour le système avec un nouveau firmware ou de lire le mot de passe administrateur. Les mêmes vérifications d’intégrité que précédemment décrites sont effectuées au travers d’un module (fum) lors d’une mise à jour. Malheureusement, une nouvelle vulnérabilité de type buffer overflow est présente dans ce module et permet de contourner les vérifications afin d’installer une mise à jour malveillante (CVE-2018-7078, corrigée en mai et juin 2018 sur iLO4 et 5) depuis le système hôte.
Le cas iLO5 est ensuite abordé, notamment son système de secure boot qui est expliqué de manière approfondie. En détaillant à nouveau l’organisation de la chaîne de démarrage et le firmware utilisé, mais également les algorithmes de signature utilisés, les conférenciers montrent qu’une erreur logique aboutit à l’acceptation d’une signature fausse (CVE-2018-7113 corrigée en octobre 2018 sur iLO5). Ils expliquent les difficultés qu’ils ont rencontrées avant d’obtenir un exploit fonctionnel, et notamment l’obligation de mettre les mains dans le cambouis, ou plutôt dans le debug électronique.
Ils concluent avec un résumé des différentes vulnérabilités trouvées au cours de leur long périple.
On the Security of Dockless Bike Sharing Services – Antoine Neuenschwander
SLIDES
Venu pour remplacer une conférence annulée sur les ransomwares aux sources ouvertes, Antoine Neuenschwander a animé une conférence sur la sécurité des vélos en libre service disponibles en Suisse.
Le chercheur a analysé les installations de plusieurs fournisseurs afin de chercher des vulnérabilités dans leurs produits, notamment Smide, oBike et Publibike. Tous ces services reposaient sur l’installation d’une application mobile afin d’acheter des crédits et de réserver les appareils.
Le premier fournisseur étudié par Antoine Neuenschwander, Smide, propose des vélos électriques haut de gamme (~5800 €) à un prix élevé (~0,22 € par minute). En plus d’être de bonne facture, tous les vélos de la flotte sont équipés d’un GPS et d’une connectivité GSM. Cela permet aux vélos de communiquer leurs positions au backend de Smide qu’ils soient utilisés ou non.
Lorsqu’un utilisateur désire utiliser un vélo Smide, il peut utiliser l’application mobile pour localiser les vélos vacants les plus proches de lui. Pour cela, une requête est envoyée vers le backend de Smide. Ce dernier renvoie un document JSON contenant la liste des vélos disponibles à proximité.
Une fois authentifié avec un identifiant et un mot de passe, l’utilisateur obtient un token nécessaire à la réservation d’un vélo. Pour ce faire, une requête contenant l’id de l’utilisateur ainsi que celui du vélo concerné est envoyée au backend. Si la réservation est possible, le backend renvoie un numéro de réservation et les détails de cette dernière.
Le chercheur a rapidement remarqué que les numéros de réservations étaient simplement incrémentés d’une réservation à une autre. Cette information lui a permis de deviner les numéros de réservation et ainsi de lister les vélos en cours d’utilisation.
Le conférencier a ensuite démontré qu’il était simple d’usurper le jeton d’authentification d’un autre utilisateur et d’agir sur sa réservation, en bloquant par exemple le vélo de la victime.
Le conférencier s’est ensuite penché sur la société oBike basée à Singapour. Cette dernière proposait ses services dans 24 pays avant de déclarer faillite en Allemagne et de réduire sa présence en Europe. Les vélos de cette marque sont de faible qualité, ne disposent que d’une connectivité Bluetooth pour communiquer avec le téléphone de l’utilisateur.
Afin de garder une trace des positions des vélos, l’application envoie la dernière position du téléphone de l’utilisateur au backend d’oBike lors de la fin d’une réservation.
Dès lors qu’un utilisateur est authentifié, il est en mesure de mettre à jour la position de n’importe quel vélo dont il connaît l’identifiant. Ces identifiants étant récupérables par une requête permettant de lister les vélos à proximité, un attaquant pourrait par exemple décider de renseigner des localisations erronées pour tous les vélos de la flotte. Le conférencier a « avoué » sur un ton humoristique avoir été tenté de faire apparaître tous les vélos au fond du lac Léman.
Les vélos de la flotte suisse de oBike ayant été retirés de la circulation, le chercheur a contacté la société chargée de les retirer pour récupérer quelques-uns des cadenas utilisés pour verrouiller les vélos.
Il a ainsi pu utiliser des techniques de rétro ingénierie pour décoder les communications entre le cadenas, le téléphone et le backend d’oBike. Il a remarqué que le cadenas émettait un challenge à résoudre pour être déverrouillé. À force de redémarrer le circuit du cadenas à chaque essai, le chercheur a remarqué que le challenge était lié au temps depuis la mise sous tension du système. Cela lui a permis de résoudre le challenge et d’obtenir le déverrouillage du cadenas sans dépendre du backend d’oBike.
Le conférencier a pu en faire la démonstration en direct sur l’un des cadenas récupérés sur d’anciens vélos oBike.
Pour conclure, Antoine Neuenschwander a émis quelques recommandations que les fournisseurs de service de véhicules en libre service devraient suivre pour améliorer la sécurité de leurs produits, notamment de soumettre leurs systèmes à des audits pour se débarrasser de vulnérabilités facilement évitables. De plus, tous les appareils en libre service embarquant des composants logiciels devraient pouvoir être mis à jour.
Betrayed by the Android User Interface: Why a trusted UI matters – Yanick Fratantonio
SLIDES
Le chercheur spécialisé dans la sécurité des appareils mobiles Yanick Fratantonio a présenté une conférence sur les vulnérabilités de l’interface utilisateur d’Android. Cette dernière est selon lui mal comprise et peu sécurisée.
Il a tout d’abord émis quelques rappels concernant le système d’exploitation de Google:
- les utilisateurs peuvent installer des applications tierces
- ces applications sont toutes isolées les unes des autres
- les fonctionnalités de ces applications sont encadrées par le système de permissions d’Android
Yanick Fratantonio a ensuite rappelé que contrairement aux systèmes d’exploitation classiques, être en mesure d’exécuter du code arbitraire sur un appareil sous Android ne compromet pas l’appareil dans sa totalité. Cela en raison du compartimentage des applications, chacune utilisant un utilisateur dédié pour s’exécuter.
D’après le chercheur, les attaques exploitant l’interface utilisateur du système d’exploitation sont en mesure de contourner la majorité des mécanismes de sécurité opérants à plus bas niveau.
Suite à cette introduction, le chercheur a donné sa définition d’une attaque sur l’interface utilisateur: toute attaque impliquant l’interface utilisateur dans le but de tromper ce dernier.
Contrairement aux attaques de phishing face auxquelles un utilisateur averti peut vérifier que le domaine du site visité est cohérent, une attaque bien menée sur l’interface utilisateur d’Android est imperceptible. Selon le chercheur, même un expert sachant que l’appareil est activement attaqué serait incapable de discerner avec certitude les activités illégitimes.
Yanick sépare les attaques sur l’interface utilisateur en deux catégories:
- les attaques de clickjacking
- les attaques de phishing
Les attaques qualifiables de clickjacking profitent de la permission « draw on top » qui permet à une application de dessiner du contenu arbitraire au-dessus de ce qui est actuellement affiché à l’écran. Cette permission, automatiquement attribuée lors de l’installation d’une application depuis le Google Play Store, est par exemple utilisée par Facebook Messenger pour afficher les bulles de conversations, quelle que soit l’application en cours d’utilisation.
Les fenêtres créées grâce à cette permission sont de taille, transparence et position variables. Elles peuvent être créées en mode cliquable auquel cas elles récupèrent l’événement de l’écran tactile, ou en mode « passthrough » auquel cas l’événement du clic sur l’écran tactile est transmis à l’application sous la fenêtre.
L’attaque de clickjacking la plus simple consiste à masquer un dialogue de confirmation ou de demande de permissions avec une fenêtre quelconque dessinée en mode passtrough. L’attaquant tentera alors d’amener l’utilisateur à cliquer là où il souhaite en affichant par exemple un faux bouton dans la fenêtre malveillante.
Pour les attaques nécessitant plus d’un clic, comme par exemple activer le débogage par USB ou l’autorisation d’installer des applications depuis des sources inconnues, il est possible d’intégrer plusieurs étapes à l’attaque. Cependant, pour que le clic soit reçu par l’application cachée derrière la fenêtre malveillante, il faut que cette dernière soit en mode passtrough, dans lequel elle ne reçoit pas les coordonnées du clic.
Il est alors difficile pour l’attaquant de déterminer si l’utilisateur a bien cliqué au bon endroit. Il est possible de contourner ce problème en couvrant l’écran de fenêtres cliquables, sauf là où la victime est supposée cliquer. Si cette surface restante est recouverte d’une fenêtre passthrough, l’attaquant saura que la victime a cliqué au bon endroit lorsqu’il reçoit l’événement d’un clic sans coordonnées.
Le conférencier a par la suite détaillé plusieurs variantes de cette attaque permettant de contourner les protections intégrées par Google au fil des années.
Les attaques de phishing sont également simplifiées par la permission « draw on top ». Rien n’empêche un attaquant de détecter l’ouverture d’une application, et d’afficher une copie malveillante de la mire d’authentification par-dessus la fenêtre légitime. L’opération sera transparente pour l’utilisateur qui aura juste l’impression d’avoir été déconnecté de sa session.
Dans une autre mesure, les gestionnaires de mots de passe pour Android sont sensibles aux attaques sur l’interface utilisateur. Ces derniers se basent souvent sur le nom du package d’une application pour déterminer si un mot de passe doit être autorempli lors du lancement de l’application. Les noms de package sous Android n’étant pas réglementés, il serait trivial pour un attaquant d’usurper le nom d’un service légitime pour obtenir les identifiants liés à ce compte dans le gestionnaire de mots de passe.
Le chercheur a conclu sa conférence avec un regard sur le futur de la sécurité des interfaces utilisateur. Selon lui, il s’agit d’un problème ouvert à la recherche. Il reste difficile pour un utilisateur de savoir avec certitude qu’il interagit avec l’application avec laquelle il souhaite interagir, ou pour une application de savoir que l’utilisateur a cliqué sur tel ou tel bouton en toute connaissance de cause.
L’arrivée de la prochaine version d’Android devrait d’après Yanick Fratantonio apporter des nouveautés intéressantes en concernant la confiance que l’on peut céder à son interface utilisateur.
[line]
Nous vous donnons rendez-vous dans le prochain numéro de l’ActuSécu pour un résumé complet et détaillé de cette édition !
Résumé co-écrit par Théo Lionti et Julien Schoumacher
