La récente histoire de porte dérobée dans la bibliothèque NPM la plus populaire a amené beaucoup de gens à penser à quel point nous faisons confiance au code tiers et à quelle hardiesse nous l'utilisons dans nos projets (remplaçant ainsi potentiellement les utilisateurs de nos produits).
Mais même des mois avant le «coup de tonnerre»,
Felix Kraus (connu des développeurs mobiles comme le créateur de Fastlane) a parlé lors de notre conférence Mobius 2018 Piter de la même chose: la confiance des développeurs mobiles envers les SDK tiers. Si nous téléchargeons le SDK populaire d'une entreprise bien connue, tout va bien, ou est-ce que quelque chose ne va pas aussi? Où est le vecteur d'attaque et à quoi faut-il penser à cet égard?
Et maintenant, nous avons transcrit et traduit son rapport - donc sous la coupe, vous pouvez au moins regarder la vidéo originale, au moins lire la version texte en russe. Étant donné que Kraus est engagé dans le développement iOS, tous les exemples proviennent également d'iOS, mais les développeurs Android peuvent ignorer des exemples spécifiques et y penser également.
Sécurité du SDK
Après avoir vu quels SDK sont les plus populaires dans le développement iOS aujourd'hui, j'ai décidé d'étudier leur vulnérabilité aux attaques réseau les plus courantes. Pas moins de 31% d'entre eux se sont avérés être des victimes potentielles d'attaques man-in-the-middle simples, ce qui signifie que le pirate injecte son code malveillant dans le SDK.
Mais en général, vaut-il la peine d'avoir peur? Que peut-il faire de pire avec votre SDK? Est-ce si grave? Vous devez comprendre que le SDK inclus dans le bundle de votre application s'exécute dans sa portée, c'est-à-dire que le SDK a accès à tout ce sur quoi votre application fonctionne. Si l'utilisateur autorise l'application à accéder aux données de géolocalisation ou, par exemple, aux photos, ces données deviennent également disponibles pour le SDK (aucune autorisation supplémentaire n'est requise). Autres données accessibles depuis le SDK: données chiffrées iCloud, jetons API et, en outre, toutes les vues UIKit contenant de nombreuses informations différentes. Si un pirate intercepte un SDK qui a accès à ce type de données, les conséquences, comme vous le savez, peuvent être assez graves. Dans le même temps, tous les utilisateurs de l'application seront affectés en même temps.
Comment cela peut-il arriver exactement? Prenons un peu de recul et parlons des choses de base du réseau et de leurs abus.
Réseau
Je vous préviens que mes explications ne seront pas exactes et détaillées à 100%. Mon objectif est de transmettre l'essence, donc je vais tout présenter sous une forme quelque peu simplifiée. Si vous êtes intéressé par les détails, je vous recommande de consulter mon blog ou d'explorer le sujet vous-même.
Comme vous vous en souvenez, la principale différence entre le protocole HTTPS et le protocole HTTP est le chiffrement des données lors de la transmission. L'absence de cryptage dans HTTP, dans l'ensemble, signifie que tout hôte situé à l'intérieur du réseau, s'il le souhaite, peut librement écouter et modifier tous les paquets transmis à travers celui-ci; en même temps, il n'est pas possible de vérifier si l'intégrité du colis a été violée. Tout cela est vrai pour les réseaux Wi-Fi publics et les réseaux Ethernet locaux protégés par mot de passe.
Lors de l'utilisation de HTTPS, les hôtes du réseau peuvent également écouter les paquets transmis, mais ils n'ont pas la possibilité de les ouvrir - seules les métadonnées des paquets sont visibles, en particulier, les adresses des hôtes d'envoi et de réception. De plus, HTTPS fournit une vérification: après avoir reçu le colis, vous pouvez vérifier s'il a subi des modifications pendant le voyage.
Auparavant, tout fonctionnait comme suit. Lorsque vous avez entré «google.com» dans la barre d'adresse sans spécifier de protocole, par défaut, le navigateur a envoyé votre demande via HTTP. Mais comme le serveur Google préfère communiquer via HTTPS, en réponse à cela, vous avez reçu un nouveau lien (redirection) avec le préfixe "https: //". Voici un écran de Charles Proxy (un outil de surveillance du trafic HTTP / HTTPS) qui le démontre:
Cependant, le nouveau lien lui-même a été envoyé via le protocole HTTP. Il est facile de comprendre ce qui peut mal se passer ici: la demande et la réponse sont transmises via HTTP, ce qui signifie que vous pouvez, par exemple, intercepter le paquet de réponse et y remplacer l'URL de localisation par «http: //». Ce type d'attaque simple est appelé une bande SSL. À ce jour, les navigateurs ont déjà appris à fonctionner de manière légèrement différente. Mais comprendre ce qu'est une bande SSL nous est plus utile.
Parfois, vous vous souvenez du modèle de réseau OSI. Je l'ai perçue comme quelque chose d'insupportablement ennuyeux. Mais plus tard, il a découvert que, curieusement, le modèle OSI n'existe pas comme ça et peut même être utile.
Nous ne l'examinerons pas en détail. La chose principale à comprendre: tout se compose de plusieurs couches qui sont responsables de différentes choses et en même temps sont en interaction constante les unes avec les autres.
L'une des couches tente de déterminer quelle adresse MAC correspond à une adresse IP spécifique. Pour ce faire, une demande de diffusion spéciale est effectuée, le premier appareil répondu est enregistré, puis des paquets lui sont envoyés.
Le problème est que le pirate peut répondre plus rapidement à la demande: "oui, envoyez-moi tous les paquets." Ceci est appelé usurpation ARP ou empoisonnement du cache ARP. Dans ce cas, le schéma de votre interaction avec Internet se transforme en ceci:
Tous les paquets transitent désormais par l'appareil du pirate et si le trafic n'est pas chiffré, il pourra lire et écrire. Dans le cas de HTTPS, il y a moins de possibilité, mais vous pouvez suivre les hôtes auxquels vous accédez.
Fait intéressant, en fait, les mêmes pouvoirs ont des fournisseurs Internet et VPN. Ils sont des intermédiaires dans votre interaction avec Internet et constituent de la même manière une menace potentielle d'usurpation ARP.
Il n'y a rien de nouveau dans l'approche de l'homme au milieu elle-même. Mais comment tout cela s'applique-t-il exactement aux SDK mobiles?
Spécificités mobiles
CocoaPods est un outil de gestion des dépendances standard utilisé dans le développement iOS. L'utilisation de CocoaPods pour le code open source est considérée comme pratiquement sûre - elle est généralement hébergée sur GitHub, généralement accessible via HTTPS ou SSH. Cependant, j'ai réussi à trouver une vulnérabilité basée sur l'utilisation de liens HTTP.
Le fait est que CocoaPods permet d'installer le SDK avec du code source fermé, et il suffit de spécifier l'URL. Il n'y a aucune vérification que le trafic sera chiffré, et de nombreux SDK proposent une adresse HTTP.
À cet égard, j'ai envoyé plusieurs demandes d'extraction aux développeurs de CocoaPods, et bientôt ils ont terminé l'achèvement. Désormais, les nouvelles versions de CocoaPods vérifient le lien spécifié par l'utilisateur et s'il n'est pas chiffré, ils affichent un avertissement. Donc, mon conseil est: mettez toujours à jour les versions de CocoaPods et n'ignorez pas les avertissements.
Il est encore plus intéressant de voir comment se passe l'installation des SDK non sensoriels non issus de CocoaPods. Prenons, par exemple, la plateforme Localytics.
La page docs.localytics.com n'est pas chiffrée. Il semblerait que dans ce cas, cela puisse être négligé, car il ne s'agit que de documentation. Mais notez que la page, entre autres, contient un lien pour télécharger les binaires. Le lien peut être crypté, mais cela ne garantit aucune sécurité: puisque la page elle-même sera transmise via HTTP, elle peut être interceptée et le lien peut être remplacé par un lien non crypté. Les développeurs Localytics ont été informés de cette vulnérabilité et elle a déjà été corrigée.
Vous pouvez faire autrement: ne changez pas le lien en HTTP, mais laissez HTTPS, mais remplacez l'adresse elle-même. Découvrir cela sera très difficile. Regardez ces deux liens:
L'un d'eux m'appartient. Lequel est de vrais développeurs, et lequel ne l'est pas? Essayez de comprendre.
Contrôle d'entraînement
J'ai alors décidé de tester mes hypothèses en essayant en réalité de remplacer le contenu du SDK à l'aide d'une attaque MITM. Il s'est avéré que ce n'est pas si difficile. Pour construire et exploiter mon circuit, il ne m'a fallu que quelques heures pour mettre en place les outils publics les plus simples.
J'ai confié l'interception du Raspberry Pi habituel. Inclus dans le réseau local, il pouvait y écouter le trafic. Dans les paquets interceptés, il devait, tout d'abord, remplacer tous les liens HTTPS par des liens HTTP, puis remplacer tous les fichiers .zip Localytics iOS par le fichier hack.zip. Tout cela s'est avéré simple et a fonctionné avec fracas.
Le fichier trollface.jpg est apparu dans l'archive résultante et la ligne «Modified by KrauseFx» est apparue dans le fichier Info.plist. Combien était nécessaire pour une telle attaque? Deux conditions seulement:
- Ils ont réussi à accéder à votre réseau (rappelez-vous que pour les fournisseurs Internet et VPN, ce n'est pas du tout une question). À combien de chaînes de cafés et d'hôtels sommes-nous connectés?
- Le téléchargement initié n'est pas chiffré.
Vous dites: "mais je regarde simplement l'icône Sécurisé dans le navigateur, ce qui signifie que je vais bien." Et si vous êtes sur Amazon, alors tout devrait bien se passer, non?
Je suggère de considérer le site Amazon. L'AWS Mobile SDK est leur SDK personnel, qu'ils fournissent aux développeurs pour interagir avec le service.
L'icône «sécurisée», un site bien connu, ne semble rien présager. Mais hélas - seulement à première vue. Le lien pour télécharger le SDK est indiqué sans aucun préfixe (ni https: // ni http: //). Et en même temps, cela devrait amener l'utilisateur vers un autre hôte. Par conséquent, le navigateur passera de HTTPS à HTTP. Comme vous pouvez le voir, ici le téléchargement du SDK n'est pas crypté! Pour le moment, la vulnérabilité a déjà été corrigée par les développeurs d'Amazon, mais elle avait vraiment sa place.
Je dois dire que le développement de navigateurs modernes se fait également non sans attention aux problèmes de sécurité. Par exemple, si vous chargez une page en utilisant HTTPS, et qu'une image est spécifiée via un lien HTTP, alors Google Chrome vous informera du soi-disant «contenu mixte». Mais une telle mesure de sécurité n'est pas prévue pour les téléchargements: les navigateurs ne suivent pas quel protocole est déclenché pour le lien de téléchargement indiqué sur la page. Par conséquent, dans le cadre de ce projet, j'ai écrit aux développeurs de navigateurs pour leur demander de suivre le contenu mixte et d'en informer les utilisateurs.
Vol de données Apple ID
Voyons maintenant un autre problème. Les utilisateurs d'iPhone doivent être familiarisés avec cette fenêtre pop-up régulière:
À gauche, vous voyez la version originale d'iOS, à droite - ma copie. À propos de la façon dont il est facile de simuler une fenêtre similaire, j'ai
écrit sur mon blog il y a quelques mois. Il a fallu 20 minutes pour recréer la vue.
L'iPhone demande souvent des données d'authentification iCloud, et pour l'utilisateur, la raison de la demande n'est généralement pas claire. Les utilisateurs y sont tellement habitués qu'ils saisissent automatiquement le mot de passe. La question de savoir qui demande le mot de passe - le système d'exploitation ou l'application - ne vient tout simplement pas à l'esprit.
Si vous pensez qu'il est difficile d'obtenir l'adresse e-mail à laquelle l'identifiant Apple est attaché, vous exagérez: cela peut être fait à la fois via le carnet de contacts et via les conteneurs iCloud (si vous avez accès à l'application iCloud, que vous pouvez découvrir sur de UserDefaults de cette application). Et l'option la plus simple est de demander à l'utilisateur de saisir personnellement son email: en théorie, cela ne devrait même pas le surprendre, car dans iOS il y a vraiment une sorte de fenêtre demandant non seulement un mot de passe, mais aussi un email.
J'ai pensé: "Et si je prends ce code du formulaire de demande que j'ai et, avec l'aide de la substitution SDK, je pénètre dans de nombreuses applications différentes pour voler tous les mots de passe iCloud avec eux?" Quelle est la difficulté de cette tâche?
Supposons que nous ayons un Mac complètement propre, sans VPN ni proxy installé, mais sur le même réseau, nous avons notre Raspberry Pi. Sur Mac dans Xcode, nous avons un projet de projet iOS ouvert contenant un minimum absolu de code - un affichage cartographique simple de la zone et rien de plus.
Ouvrez maintenant le navigateur, accédez à Amazon Web Services. Recherchez la page AWS Mobile SDK et suivez le lien de téléchargement. Décompressez le binaire téléchargé et faites glisser tous les frameworks dans notre projet dans Xcode. Ensuite, nous importons les bibliothèques. Nous ne sommes même pas obligés d'appeler un code - il suffit qu'il soit téléchargé. Je note que pendant tout le processus, Xcode n'a donné aucun avertissement.
Que se passe-t-il lors de la recompilation de l'application? La même copie de la fenêtre apparaît à l'écran, m'invitant à me connecter à l'iTunes Store. J'entre le mot de passe, la fenêtre disparaît. En même temps, en regardant le journal des applications, je vois comment le mot de passe que j'ai entré y est instantanément affiché - l'interception des données de l'identifiant Apple est terminée. Il serait facile d'envoyer ces données quelque part au serveur.
Ici, vous pouvez dire: «Eh bien, pendant le développement, je remarquerais immédiatement ce formulaire de saisie et je comprendrais que quelque chose ne va pas.» Mais si vous avez un public de millions d'utilisateurs, vous ne pouvez le faire ramper qu'une fois par mille et passer inaperçu lors des tests.
Et encore une fois, combien nous a-t-il fallu pour mener l'attaque? Il fallait que notre ordinateur soit sur le réseau (et le Raspberry Pi suffisait). HTTP ou HTTPs - dans ce cas, cela n'avait pas d'importance, le chiffrement ne sauverait pas la situation. Tous les outils logiciels que j'ai utilisés - les plus simples, ont été retirés par le public. En même temps, je suis un développeur ordinaire, sans grande connaissance et expérience des hacks.
Reprise de gestion
L'exemple précédent a introduit du code malveillant dans l'application iOS. Mais que faire si nous pouvions contrôler l'ordinateur du développeur en général? La capacité à exécuter du code sur votre appareil, comme vous le savez, donne au pirate un pouvoir énorme. Il pourra activer l'accès à distance via SSH, installer un enregistreur de frappe, etc. Il pourra vous observer à tout moment, enregistrer vos actions, utiliser le système de fichiers. Il pourra également installer de nouveaux certificats SSL et les utiliser pour intercepter toutes les demandes que vous faites au réseau. En un mot, quelqu'un a la possibilité d'exécuter du code sur votre ordinateur - et vous êtes complètement compromis.
Je me suis dit "quel SDK iOS puis-je utiliser pour cela?" Il existe un service qui fournit au SDK la commande curl et un lien HTTP avec une sortie redirigée vers la commande sh. Autrement dit, votre terminal téléchargera et exécutera le script shell.
En soi, cette méthode d'installation vous met déjà en danger, ne le faites pas. Mais dans ce cas, le protocole HTTP a également été utilisé. Que faire alors?
Supposons que vous soyez un utilisateur. Vous accédez à la page de documentation officielle. Faites attention au fait que la page est cryptée avec le protocole HTTPS - super! Vous copiez la commande, l'exécutez à la maison. La commande est exécutée en quelques secondes. Que s'est-il passé pendant cette période?
Et pendant ce temps, un simple mécanisme d'attaque impliquant mon Raspberry Pi a réussi à fonctionner. Le script shell updateSDK chargé par l'utilisateur contenait une petite touche de mon propre code. Et maintenant, je suis autorisé à accéder à votre ordinateur à distance via SSH, et vous avez également un enregistreur de frappe installé.
Sur la gauche, vous voyez «votre» terminal, et sur la droite est mon Raspberry Pi, qui montre déjà en temps réel tout ce que vous entrez sur le clavier. Après avoir commencé avec Raspberry Pi SSH, je me connecte en utilisant le login et le mot de passe que vous venez d'enregistrer à l'aide du keylogger, et de cette manière j'obtiens un accès complet pour contrôler votre Mac et son système de fichiers. Et aussi, probablement, votre entreprise employeur a accès à beaucoup.
En conclusion
Quelle est la probabilité que cela vous arrive? Après tout, les développeurs essaient toujours d'utiliser le Wi-Fi sécurisé, achetez un VPN.
Personnellement, j'ai aussi pensé que j'étais prudent jusqu'au jour où j'ai ouvert les paramètres de mon Mac et découvert dans l'histoire de plus de 200 connexions à des réseaux Wi-Fi non sécurisés. Chacune de ces connexions est une menace potentielle. Et même en utilisant un réseau de confiance, vous ne pouvez pas être sûr à 100% de votre sécurité, car vous ne pouvez pas savoir si l'un des appareils de ce réseau a été compromis (comme nous venons de le voir).
Les attaques sur des réseaux Wi-Fi non sécurisés sont très courantes. Ils sont faciles à tenir dans des lieux publics, tels que des hôtels, des cafés, des aéroports et, en passant, des conférences :) Imaginez un orateur parler d'une sorte de SDK, et, comme d'habitude, une partie du public essaie de l'installer en parallèle en se connectant au Wi-Fi distribué ici . Et comme je l'ai dit, il est très facile d'abuser de vos droits à un fournisseur de réseau.
De la même manière avec un VPN - vous vous livrez simplement au fournisseur. Et à qui faire confiance - le fournisseur VPN ou votre réseau local et ses utilisateurs? Pas clair.
En novembre 2017, j'ai mené mes recherches et analysé la présence des vulnérabilités répertoriées dans les 41 SDK les plus populaires pour iOS (sans compter les SDK de Google et Facebook, ils sont tous protégés).
Comme vous pouvez le voir, 31,7% des SDK n'ont pas réussi les tests. J'ai réussi à informer presque tous les fournisseurs sur les problèmes existants. De celui que j'ai reçu une réponse littéralement tout de suite, le problème a été résolu en trois jours. Cinq équipes ont également réagi, mais ont passé un peu plus de temps sur la révision - environ un mois. Seven n'a pas pris la peine de répondre à mon rapport et n'a rien corrigé à ce jour. Permettez-moi de vous rappeler qu'il ne s'agit pas de projets peu connus. SDK , SDK iOS-, , , iPhone.
, , — . , . . -, , , . , , , , , .
man-in-the-middle, . , SDK. , , SDK, , (, , , ).
, . , GDPR. SDK , — , . . , — . Merci de votre attention.
, : Mobius 22-23 , , .