Ce que Bad Guys 2 m'a appris sur l'asymétrie de l'information et le Application Security Problème que personne ne veut nommer

01 Ils étaient étudiants de votre travail

Il y a une réplique dans Bad Guys 2 qui devrait glacer le sang de tous les professionnels de la sécurité. Lorsque les Bad Girls – Kitty Kat, Pigtail Petrova et Doom – se révèlent pour la première fois, elles n'arrivent pas en fanfaronnant, armées d'une puissance de feu supérieure ou d'une technologie plus avancée. Elles se présentent comme des admiratrices. Des fans. « Étudiantes de leur travail », comme le dit le film. Elles ont étudié les Bad Guys si minutieusement qu'elles peuvent reproduire leurs signatures, anticiper leurs mouvements et exploiter leurs relations. Lorsque les Bad Guys comprennent enfin ce qui se passe, la partie est déjà perdue. L'asymétrie d'information était totale avant même la scène d'ouverture.

Les attaquants avaient déjà étudié votre travail. Ils avaient votre fichier binaire. Aucune trace de cette reconnaissance n'apparaît dans vos journaux.

Il ne s'agit pas d'une mise en scène cinématographique astucieuse. Il s'agit de la description de toutes les failles de sécurité graves survenues dans les applications au cours de la dernière décennie.

Les attaquants avaient déjà étudié votre travail. Ils avaient votre binaire. Ils l'ont exécuté hors ligne, à l'aide de désassembleurs et de débogueurs, à leur guise, sans contrainte de temps ni système d'alerte. Ils connaissaient vos clés cryptographiques, votre logique d'authentification, vos modèles d'appels d'API, votre stratégie d'obfuscation – si vous en aviez une. Ils connaissaient votre application mieux que la plupart de vos propres développeurs. Et aucune trace de cette reconnaissance n'est apparue dans vos journaux.

La question n'est pas de savoir si cela arrive à votre application. C'est le cas. La question est de savoir ce qu'ils trouvent lorsqu'ils examinent votre demande.

02 L'asymétrie d'information est le véritable problème

L'asymétrie d'information est un concept utilisé par les économistes pour décrire les situations où l'une des parties à une transaction possède beaucoup plus d'informations que l'autre. George Akerlof a reçu le prix Nobel d'économie en 2001 pour ses travaux sur la façon dont l'asymétrie d'information perturbe les marchés. Son exemple le plus célèbre est celui du marché de l'occasion, où les vendeurs connaissent l'état réel du véhicule, contrairement aux acheteurs, ce qui conduit à un marché saturé de véhicules défectueux. La partie qui dispose de plus d'informations l'emporte systématiquement, non pas parce qu'elle est plus intelligente, mais parce qu'elle possède des informations que l'autre partie ignore.

En matière de sécurité applicative, l'asymétrie est entièrement du côté de l'attaquant dès le déploiement. L'attaquant obtient le fichier binaire. Ce fichier contient votre logique, vos clés, vos secrets et vos hypothèses de confiance. L'attaquant peut l'examiner sans aucune restriction. Vous, le développeur, ne pouvez pas voir ce que l'attaquant fait de votre application une fois qu'elle a quitté votre environnement. Vous avez accès aux journaux. L'attaquant, lui, a une visibilité équivalente au code source sur tout ce que vous avez déployé.

Il ne s'agit pas d'une hypothèse. Les décompilateurs et désassembleurs modernes ont démocratisé la rétro-ingénierie à un point qui aurait semblé inconcevable il y a vingt ans. Un analyste compétent, disposant d'outils gratuits, peut analyser une application mobile, supprimer sa couche d'obfuscation en un après-midi, extraire les clés codées en dur en quelques heures et cartographier l'intégralité de son interface de communication avec le serveur en un ou deux jours. Ces outils sont performants, leur documentation est exhaustive et les communautés qui les utilisent sont actives.

Les méchantes n'avaient pas besoin d'être plus intelligentes que les méchants. Il leur suffisait d'en savoir plus sur eux que les méchants n'en avaient sur elles. Dans le film, cette asymétrie se construisait par une observation et des recherches approfondies. En matière de sécurité des applications, l'attaquant crée cette asymétrie dès le téléchargement de votre application depuis la boutique d'applications.

03 Le problème de la Patte Pourpre : Quand le secret sort de la boîte

Le moment le plus instructif de Bad Guys 2 n'est pas le braquage. Ce sont les images.

La gouverneure Diane Foxington possède une identité secrète : la Patte Pourpre, son ancien alter ego criminel. Ce secret est jalousement gardé depuis des années. Il est le fondement de son autorité publique, de sa légitimité politique et de sa relation avec Wolf. C’est, à tous égards, une clé de chiffrement — une information cachée dont dépend tout un système de confiance.

Kitty Kat possède les images. Elle s'en sert pour faire chanter les méchants et les contraindre à collaborer à son braquage. Au moment crucial, alors que Wolf croit avoir récupéré la clé USB contenant les images, Kitty les met en ligne malgré tout. L'identité secrète de Diane est révélée au monde entier. Le chantage s'évapore, mais tout ce que le secret protégeait s'effondre avec lui. La crédibilité de la gouverneure, sa relation, sa carrière politique – tout ce qui dépendait du maintien de ce secret – s'écroule simultanément.

C’est précisément ce qui se produit lorsque des clés cryptographiques sont extraites d’une application.

La clé, c'est le secret. Le secret est le fondement du système de confiance. Une fois extrait – une fois que l'attaquant s'en empare – votre réaction est inutile. L'exposition est asymétrique et irréversible. Vous pouvez changer la clé, corriger l'application, révoquer le certificat. L'attaquant a déjà ce qu'il lui fallait.

L'erreur de Wolf a été de croire que posséder la clé USB lui permettait de contrôler le secret. Or, le secret était déjà divulgué. Dans le développement d'applications mobiles et web, cette erreur est structurelle. Les clés intégrées aux fichiers binaires ne sont pas des secrets. Ce sont des informations publiques différées. Ce délai correspond au temps nécessaire à un analyste compétent pour les consulter.

04 L'illusion de la clé USB

Il existe un problème récurrent en matière de sécurité applicative : la confusion entre le conteneur et le secret. Les entreprises considèrent que la sécurité des clés dépend de celle de leur lieu de stockage. Module de sécurité matériel ? Sécurisé. Coffre-fort de clés chiffré ? Sécurisé. Clé codée en dur dans le binaire de l’application mobile ? Certes, nous avons utilisé un outil d’obfuscation tiers, alors…

Wolf pensait que la clé USB contenait les images. Kitty en avait déjà fait des copies et le téléchargement était en cours avant même qu'elle ne lui remette quoi que ce soit. L'objet physique n'était qu'un accessoire, un leurre, quelque chose à remettre à Wolf pour qu'il cesse de chercher les images, qui se trouvaient alors sur une infrastructure à laquelle il n'avait aucun accès.

L'obfuscation, c'est la clé USB. Ce n'est pas l'enregistrement vidéo.

Voilà ce que l'industrie ne cesse d'apprendre et d'oublier. L'obfuscation complique la rétro-ingénierie et en augmente le coût. Pour certains modèles de menaces, cette augmentation des coûts constitue une mesure défensive pertinente. Mais pour tout attaquant suffisamment motivé – un État, une organisation criminelle financière, un concurrent disposant de moyens importants – l'obfuscation n'est qu'un gain de temps, et non une défense. La clé réside toujours dans le code binaire. Un analyste compétent la trouvera. Cela lui prendra peut-être trois jours au lieu de trois heures, mais le résultat sera le même.

La cryptographie classique repose sur le principe que les algorithmes sont publics et les clés secrètes. L'édifice théorique du chiffrement moderne tout entier n'est valable que tant que cette hypothèse l'est. Dans un environnement où l'application s'exécute sur du matériel contrôlé par l'attaquant — chaque appareil mobile, chaque terminal IoT, chaque application cliente —, cette hypothèse n'est plus valable. La clé se trouve quelque part dans le code binaire.

Avec le temps et les outils nécessaires, on peut la trouver. La seule architecture cryptographique qui résiste à l'extraction de clé est celle où cette extraction ne donne rien d'utile.

05 Susan n'a jamais été Susan : La menace interne comme canal d'extraction d'informations

La petite amie de Snake, « Susan », est Doom. Elle n'a pas l'air d'une menace. Elle a l'air d'une relation. Snake, de plus en plus absent des opérations des Bad Guys, passe du temps avec quelqu'un qui a su se créer l'accès dont elle a besoin. Elle n'a pas besoin de franchir le périmètre. Elle est à l'intérieur. Snake la laisse entrer.

L'influence interne est l'un des vecteurs d'attaque les plus efficaces, tant au cinéma que dans la réalité. Les Bad Girls n'avaient pas besoin de compromettre les Bad Guys par une attaque extérieure. Il leur fallait un maillon de confiance au sein de leur réseau, et Snake le leur a fourni sans même s'en rendre compte.

En matière de sécurité applicative, cela se répercute directement sur la chaîne d'approvisionnement. Le vecteur d'attaque le plus dangereux pour une application sécurisée n'est pas l'application elle-même, mais ce à quoi elle fait confiance : les SDK tiers, les dépendances open source, les services API, les outils d'analyse. En principe, chaque bibliothèque externe initialisée par votre application à l'exécution a le même accès à l'état d'exécution de votre application que votre propre code. Si cette bibliothèque est compromise, ou si elle était malveillante dès le départ, la relation de confiance que vous avez établie au sein de votre code devient caduque.

Le Brèche de sécurité chez SolarWinds en 2020 L'exemple classique au niveau de l'infrastructure est celui d'une compromission d'un système de compilation ayant permis la diffusion de mises à jour malveillantes via des canaux de confiance à des milliers d'organisations. Mais ce schéma se reproduit couramment dans les applications mobiles. Un kit de développement logiciel (SDK) mobile d'un fournisseur légitime est acquis. Le nouveau propriétaire déploie une mise à jour intégrant un mécanisme d'exfiltration de données. Toutes les applications ayant téléchargé ce SDK exécutent désormais automatiquement du code qui viole tous les principes de confiance sur lesquels il reposait. Le périmètre de sécurité n'a jamais été franchi. C'est la relation de confiance qui a été l'attaque.

Susan n'a jamais été Susan. Votre kit de développement logiciel analytique n'est peut-être pas celui que vous utilisez habituellement.

06 Pigtail connaît vos signatures

Pigtail Petrova, l'ingénieure au caractère bien trempé parmi les Bad Girls, est le personnage le plus intéressant du film sur le plan technique. C'est elle qui a piégé les Bad Guys. Elle n'a pas utilisé la force brute, mais la technique de la contrefaçon. Elle a étudié leurs méthodes – leurs signatures, leurs approches, leurs tics – avec une telle minutie qu'elle pouvait reproduire des crimes en tous points identiques aux leurs. Les Bad Guys ont été accusés de braquages ​​qu'ils n'avaient pas commis, car Pigtail était capable d'imiter leur comportement à la perfection.

Il s'agit de rétro-ingénierie appliquée à la veille concurrentielle. C'est également la technique employée par les cybercriminels financiers les plus sophistiqués pour cibler les systèmes d'authentification des applications.

Lorsqu'un attaquant procède à une rétro-ingénierie complète d'une application bancaire mobile, il ne se contente pas de trouver les clés d'activation. Il découvre également le comportement de l'application. Il comprend la séquence d'appels API qui constitue une session légitime, le protocole de défi-réponse utilisé par l'application pour prouver son authenticité auprès du serveur, ainsi que les données de télémétrie envoyées par l'application, les en-têtes inclus et les schémas temporels caractéristiques d'une utilisation normale. Grâce à ces informations, il peut créer un émulateur : un client synthétique qui imite le comportement de l'application avec une précision suffisante pour passer la validation côté serveur.

Le serveur reçoit des requêtes qui semblent provenir d'une application légitime. Elles sont impossibles à distinguer des requêtes légitimes par analyse forensique, car l'attaquant a reconstitué et reproduit la signature de la requête légitime. La fraude reste invisible jusqu'à ce que son mode opératoire soit détectable ; à ce moment-là, l'attaquant a déjà effectué des milliers de transactions.

07 MacGuffinite et le vrai but

Les réalisateurs ont provoqué un véritable fou rire en baptisant leur MacGuffin « MacGuffinite » – un métal rare capable d'attirer l'or magnétiquement. La blague est une référence à Hitchcock : un MacGuffin est ce que l'intrigue exige que tout le monde désire, indépendamment de sa véritable importance. La MacGuffinite n'est que le prétexte. Le véritable objectif est d'extraire tout l'or mondial de la Station spatiale multinationale. Ce braquage élaboré n'est que l'infrastructure nécessaire à ce but ultime, qui se situe à une toute autre échelle.

Les équipes de sécurité sont entraînées à défendre le MacGuffinite. L'attaquant, lui, veut autre chose.

Lorsqu'un attaquant procède à la rétro-ingénierie de votre application mobile, son objectif principal est bien sûr d'obtenir les clés cryptographiques. Mais ces clés ne sont souvent qu'un prétexte. En réalité, l'attaquant peut chercher à générer des jetons d'authentification valides à grande échelle, lui permettant ainsi de prendre le contrôle de millions de comptes utilisateurs. Il peut également vouloir intercepter et modifier des données financières en transit sans déclencher l'épinglage de certificat. Enfin, il peut chercher à cloner l'identité de l'application pour accéder directement aux services backend, en contournant tous les contrôles mis en place par l'application au niveau client.

Le vol clé, c'est celui de la montre connectée lors du mariage. Efficace, chirurgical, quasiment invisible. Le plus intéressant, c'est ce qui se passe ensuite.

08 Le périmètre a toujours été une proposition, pas un mur

L'industrie de la sécurité a consacré près de vingt ans à la mise en place de périmètres de sécurité : pare-feu, systèmes de détection d'intrusion, segmentation du réseau, architecture zéro confiance. Le principe sous-jacent : empêcher les cybercriminels d'entrer, faire confiance au réseau interne et défendre la frontière entre les deux.

Ce modèle était pertinent lorsque l'application était hébergée sur votre matériel, dans votre centre de données, derrière votre pare-feu. Il a commencé à montrer ses limites lorsque l'application a été migrée vers le cloud. Il est devenu totalement inopérant lorsque l'application a été transférée sur le smartphone de l'utilisateur.

Une application mobile est déployée sur un matériel contrôlé par l'attaquant. Un dispositif IoT est déployé sur un matériel que l'attaquant peut physiquement posséder. Une application web est chargée dans un navigateur que l'attaquant peut inspecter. Dans aucun de ces environnements, le modèle de périmètre n'est valable. L'application n'est pas à l'intérieur du périmètre. Elle est à l'extérieur du périmètre, exécutée dans un environnement hostile, dès son déploiement.

Voici le problème architectural que la sécurité périmétrique ne peut résoudre. Vous pouvez avoir un environnement serveur impeccable : aucune vulnérabilité dans l’infrastructure, une segmentation réseau parfaite, des contrôles d’accès irréprochables sur chaque service backend. Et puis, votre application mobile est livrée avec une clé de service codée en dur et un système d’obfuscation qu’un analyste junior, un week-end de libre, peut déjouer. L’attaquant n’atteint pas votre serveur. Il atteint votre application, qui communique directement avec votre serveur.

09 La géométrie de la surface d'attaque a changé

Services financiers. Santé. Industrie de la défense. Télécommunications. Tous les secteurs qui ont numérisé leurs opérations en contact avec la clientèle au cours de la dernière décennie ont, sans le savoir, déplacé leur surface d'attaque du centre de données vers le terminal. Les données sensibles, la logique d'authentification, les opérations cryptographiques : tout cela s'exécute désormais, au moins en partie, sur du matériel que l'organisation ne possède ni ne contrôle.

Les implications pour la cryptographie sont spécifiques et sous-estimées. La cryptographie classique — les chiffrements AES-256, les signatures RSA, les échanges TLS — est prouvée sûre sous l'hypothèse que la clé est secrète. Cette hypothèse n'est pas mathématique, mais physique. Les fondements mathématiques du chiffrement moderne sont solides. Le problème réside dans cette hypothèse.

Lorsqu'une application effectue des opérations cryptographiques sur un appareil contrôlé par un attaquant, ce dernier peut observer la mémoire de l'application au moment du chargement de la clé, de l'exécution de l'opération et de la production du résultat. Une catégorie d'attaques, appelées attaques par canaux auxiliaires, exploite précisément cette vulnérabilité : la consommation d'énergie, les émissions électromagnétiques, les variations de synchronisation et les schémas d'accès au cache permettent tous de divulguer des informations sur la clé utilisée. Dans une attaque en boîte blanche, l'attaquant va plus loin, considérant l'application elle-même comme une boîte ouverte à l'analyse, et extrayant la clé directement du code compilé.

L'AES-256 reste l'AES-256. Mais lorsque la clé est accessible, le chiffrement n'est aussi fort que le secret de la clé — et le secret de la clé est nul, ou presque.

10. Le renforcement binaire n'est pas de l'obfuscation. La cryptographie en boîte blanche n'est pas du chiffrement.

C’est là que le débat sur la sécurité doit gagner en précision, car la confusion de ces concepts coûte cher aux organisations et les expose à des risques réels.

L'obfuscation transforme le code pour le rendre plus difficile à lire. Elle renomme les variables, aplatit le flux de contrôle, insère du code superflu, chiffre les chaînes de caractères. Un analyste persévérant finira par la déjouer. L'obfuscation, c'est du temps perdu. C'est comme une clé USB.

Le renforcement binaire est différent. Il intègre à l'application elle-même des mécanismes de défense qui rendent toute falsification détectable ou impossible. Des techniques anti-débogage détectent l'exécution de l'application sous un débogueur et modifient son comportement. Des contrôles d'intégrité vérifient le code de l'application à l'exécution et refusent son exécution en cas de modifications. Des contrôles anti-falsification détectent si l'application s'exécute dans un environnement émulé. Des vérifications environnementales identifient les conditions d'accès root ou de jailbreak révélatrices d'un dispositif malveillant. Le renforcement binaire ne se contente pas de ralentir l'analyste ; il modifie l'économie des attaques en rendant les méthodes de rétro-ingénierie les plus courantes peu fiables.

La cryptographie en boîte blanche résout directement le problème de l'exposition des clés. En cryptographie en boîte noire classique, la clé est une entrée distincte pour l'opération cryptographique. En cryptographie en boîte blanche, la clé est mathématiquement intégrée à l'implémentation elle-même, grâce à une série de transformations mathématiques qui la rendent irrécupérable, même si un attaquant a un accès complet au code et à la mémoire et peut observer chaque calcul intermédiaire. L'opération cryptographique produit toujours des résultats corrects. La clé ne peut être extraite de l'implémentation. Il n'y a pas de clé USB à fournir.

Il ne s'agit pas d'améliorations incrémentales du périmètre. Il s'agit d'un principe architectural différent : au lieu d'essayer d'empêcher les attaquants d'accéder à votre application, vous construisez une application qui reste sécurisée même lorsque les attaquants y ont un accès complet.

11. Renseignements sur les menaces liés aux applications : savoir quand les personnes malveillantes sont déjà à l’intérieur.

Le problème fondamental des méchants dans le film, c'est leur réactivité. Ils réagissent à des événements imprévus, car ils n'avaient aucune visibilité sur ce qui se tramait contre eux. Ils ignoraient tout des méchantes jusqu'à ce que celles-ci décident de se révéler, au moment et selon leurs propres conditions.

La sécurité des applications a toujours souffert du même problème : l’attaque est découverte a posteriori. Les journaux d’activité sont examinés après la violation. L’analyse forensique permet de reconstituer les actions de l’attaquant. Le laps de temps entre la compromission initiale et la détection – ce que l’industrie appelle le temps de latence – est en moyenne de plusieurs semaines à plusieurs mois. Pendant ce temps, l’attaquant exploite pleinement l’asymétrie d’information à son avantage.

La solution logique consiste à instrumenter la détection plus tôt dans la chaîne d'attaque : avant la fin de l'extraction de la clé, avant l'utilisation du jeton de session falsifié, avant même que le client émulé n'effectue son premier appel frauduleux. Les applications capables d'observer leur environnement d'exécution et de signaler les anomalies (activité de débogage, accès mémoire inhabituels, exécution dans des émulateurs, code altéré exécuté sur des services en production) génèrent des données de télémétrie qui réduisent le temps de présence de l'attaquant.

Lorsque votre application peut indiquer qu'elle est exécutée dans un débogueur, l'analyste qui étudie votre binaire n'est plus invisible. Lorsque votre application signale qu'une version piratée contacte vos serveurs, l'usurpation d'identité par Pigtail ne passe pas inaperçue pendant des mois. L'asymétrie d'information commence à se rompre.

12 La question essentielle à se poser avant d'expédier

Avant chaque mission, Wolf avait un plan. Ce plan reposait sur l'hypothèse d'une asymétrie d'information en faveur des méchants. Ils savaient des choses que la cible ignorait et disposaient de capacités que cette dernière ne pouvait anticiper. Le plan fonctionnait tant que cette asymétrie se maintenait.

Les Bad Girls ont inversé la tendance. Elles ont dressé un portrait plus complet des Bad Guys que ces derniers n'en avaient d'eux-mêmes, du moins sur le plan opérationnel. Le plan a échoué car l'asymétrie d'information sur laquelle il reposait avait déjà été inversée.

Avant de déployer votre prochaine application, une question se pose : l’attaquant qui effectue une ingénierie inverse de votre binaire trouvera-t-il quelque chose d’utile ?

Si la réponse est oui — s'il y a des clés, des signatures d'authentification reproductibles ou une logique qui compromet la confiance lorsqu'elle est exposée — alors votre plan repose sur une asymétrie d'information que l'attaquant finira par exploiter. Il existe, quelque part, des personnes qui étudient vos travaux.

Les méchants finissent par gagner, bien sûr. C'est un film familial. Mais ils gagnent en exploitant l'asymétrie d'information : en déjouant les plans de Kitty, en comprenant son véritable objectif et en agissant grâce à des informations qu'elle ignorait posséder. C'est aussi ainsi que l'on gagne en sécurité applicative. On ne gagne pas en espérant que les pirates informatiques n'étudieront jamais votre travail. Ils l'ont déjà fait. On gagne en s'assurant que ce qu'ils ont étudié ne leur indique pas la marche à suivre.

Digital.ai Protection des applications

Digital.aila plate-forme Cette approche part de la couche binaire. Le renforcement binaire protège l'application contre les méthodes de rétro-ingénierie et de falsification les plus courantes : protection contre le débogage, vérification d'intégrité, détection de l'environnement et autoprotection à l'exécution. La cryptographie en boîte blanche intègre les clés dans les implémentations de manière à rendre leur extraction mathématiquement impossible, et non simplement contraignante. L'intelligence contextuelle de l'application fournit des données télémétriques sur son activité en production : analyse, modification ou usurpation d'identité.

L'objectif n'est pas de ralentir l'analyste, mais de s'assurer que ses découvertes, même avec un accès complet, ne lui confèrent aucun avantage opérationnel. Si la clé USB est vide, Kitty n'a rien à y télécharger.