Depuis plusieurs années, les incidents de cybersécurité se multiplient au sein de l'écosystème santé en France et à l'international. Malgré les réglementations et les investissements effectués, les systèmes restent vulnérables, la menace s'accélère et les difficultés à maintenir en conditions de sécurité des systèmes parfois anciens, toujours complexes et éminemment sensibles, sont flagrantes.
Akyl s'implique de longue date auprès des acteurs de la santé, assurant tour à tour de l'accompagnement à la remédiation sur incident, de l'audit cybersécurité, de l'accompagnement à la gestion de crise ou encore plus souvent la position de responsable de la gouvernance cybersécurité des établissements.
Cet article plonge au cœur d'un cas concret : comment une rétro‑ingénierie logicielle a permis de défaire un mécanisme de protection en place depuis des années et d'exfiltrer les données de milliers d'individus.
À travers ce retour d'expérience, nous illustrons comment le manque de moyens historique est aujourd'hui à l'origine d'une dette technique, et pourquoi la combinaison de logiciels obsolètes, d’accès mal contrôlés et de pratiques de développement peu matures sur le plan cybersécurité continue de mettre en péril la confidentialité des données de santé.
Avant-propos
L'ensemble des éléments restitués dans cet article sont volontairement anonymisés et rendus indiscernables des organismes, personnes privées ou morales impliquées. L'absence d'illustration explicite ou capture d'écran de l'application auditée dans ce retour d'expérience en est une manifestation directe.
L'article présuppose une connaissance générale des méthodologies d'audit, techniques (décompilation, instrumentation de code source, interception de flux, etc.) et outils employés (FRIDA, JADX, BURP, etc.) pour l'analyse d'applications Android et Web, qui sont utilisés ici pour servir le narratif du retour d'expérience sans être spécifiquement ou pédagogiquement détaillés.
Prise de contexte
Akyl est sollicité pour auditer la sécurité d'une application cœur de métier utilisée par des professionnels de santé. Un incident en cours pointe l'application comme responsable suspectée d'une récente fuite de données.
Akyl est missionné avec une emphase sur la recherche de vulnérabilités associées à un potentiel de rupture du cloisonnement et d'exfiltration de données relatives aux individus, ici les patients des professionnels de santé utilisant l'application.
L'intervention est marquée par la nécessité de rapidement démontrer l'hypothèse et de valider l'origine de l'incident de sorte à engager la responsabilité de l'éditeur de la solution et d'ouvrir les discussions utiles à un correctif.
Choix d'approche
Le cadrage de l'audit permet de convenir d'une approche en méthodologie boîte grise, des comptes d'accès dédiés aux testeurs sont fournis ainsi que les points d'accès de l'application (hyperliens et magasin distribuant l'application mobile Android).
Une rapide reconnaissance des différents canaux d'accès à l'application permet de promptement identifier une dissonance de look & feel. L'application web semblant d'apparence relativement moderne là où l'application mobile est d'apparence plus "rétro". En particulier, l'observation des échanges effectués par les applications permet de pointer l'usage d'API différentes pour l'application Web et Android, tant en matière d'adressage (Fully Qualified Domain Name) que de signature (appellations, chemins des services exposés, schéma des paramètres, etc.). Les modifications effectuées par un canal sont cependant répercutées sur le second, confirmant l'usage d'une base de données unique (ou du moins un ensemble de bases synchronisées).
L'obsolescence étant généralement un indicateur de vulnérabilité potentielle et la durée de l'audit étant un facteur ici d'importance, nous décidons d'orienter nos premiers tests essentiellement sur l'application mobile.
N.B : l'application et son API Web seront bien sûr testées également, quelques jours après l'application mobile, mais ne font pas l'objet du présent article.
Mise en place d'un banc de test
Pour commencer, l'application est déployée dans un environnement de test contrôlé. Une suite d'outillage à l'instar d'un émulateur, d'un décompilateur, d'un instrumentateur de code et d'un proxy d'attaque permettent notamment de réaliser les analyses au sein du banc de test.
Si ce procédé permet de faciliter les analyses techniques, il se confronte aussi souvent à divers mécanismes de détection de bac à sable (protections anti-débogage, anti-émulateur, anti-root, épinglement de certificats, etc.) et à divers autres mécanismes anti-rétro-ingénierie (obfuscation de code source, mécanismes anti-rejeu, etc.) qu'il est courant de devoir déconstruire en premières analyses avant de pouvoir réellement auditer le corps fonctionnel de l'application.
Premières analyses
Dans notre cas, l'application émulée (Android Studio) semble effectivement implémenter tout ou partie de ces protections et affiche un écran de démarrage inerte - curieusement anglophone. Une décompilation (JADX) et la recherche de mots clés à l'instar de "root" permettent de circonscrire les portions de code responsables et de procéder à l'instrumentation d'un contournement (script Frida) :
Cette étape réalisée, s'ensuit alors un procédé habituel à la conduite des tests réels : une configuration à l'échelle du système d'exploitation du téléphone permet d'envoyer toute requête HTTP(S) émise vers un proxy d'attaque (BURP) et d'observer ainsi le trafic de l'application ainsi que la manière dont elle interagit avec le serveur au moyen de son API.
Une première tentative de rejeu est effectuée sur un service arbitraire en modifiant les paramètres de la requête initiale. Les auditeurs découvrent alors un mécanisme anti-rejeu des requêtes émises à l'API mobile, basé sur le calcul local d'un condensat et transmis dans les en-têtes à la logique serveur pour contrôle ; retournant un code d'erreur en cas d'incapacité à vérifier la validité de la signature.
Force est de constater l'implémentation d'un mécanisme de protection peu commun et extrêmement limitant pour les tests, ainsi qu'une volonté manifeste de protéger un actif critique : un actif constituant la voie d'accès légitime vers un ensemble de données sensibles.
Rétro-ingénierie du mécanisme anti-rejeu
Analyse de l'algorithme de génération de la signature
Un mécanisme de sécurité implémenté côté client n'étant jamais indéfectible, nous décidons de poursuivre l'analyse et identifions rapidement l'algorithme de signature au sein du code source de l'application précédemment décompilé :
Explication des paramètres :
- deux chaines de caractères à ce stade non identifiées, considérées comme des secrets dans la suite de cette analyse (respectivement secret#1 et secret#2) ;
- l'ensemble des éléments constitutifs de la requête (à l'exception des en-têtes et du FQDN) ;
- l'horodatage ;
- un booléen contrôlant ou non l'usage intermédiaire de l'encodage base64.
Pseudo-code :
- Le verbe HTTP, la portion de chemin relatif de l'URL, les paramètres de l'URL, le corps de la requête et l'horodatage sont concaténés avec une barre verticale ("|") comme séparateur, formant la valeur à signer (sigval);
- Si le booléen utile est positionné, l'ensemble sigval est encodé en base64 ;
- Enfin la fonction renvoie :
- Une chaine de caractère vide (signature invalide qui sera rejetée) si le secret#1 est lui-même nul ou vide ;
- Si le secret#2 est nul ou vide, le condensat de la valeur à signer calculé avec l'algorithme de hachage à clé HMAC SHA-256 et le secret#1 comme clé, i.e HMAC_SHA-256(sigval, secret#1) ;
- Si non, HMAC_SHA-256(sigval, HMAC_SHA-256(secret#2, secret#1))
Récupération des secrets
À ce stade de l'analyse, l'algorithme semble indubitablement reproductible sous réserve de pouvoir identifier les secrets effectivement utilisés.
Pour ce faire, nous décidons une nouvelle fois d'utiliser l'instrumentation (script Frida) et d'hameçonner la fonction de signature ci-dessus afin de déterminer les valeurs utilisées :
Ces valeurs s'avérant constantes au cours de multiples requêtes et appels successifs à la fonction, nous prenons pour hypothèse leur validité à moyen terme.
La recherche de ces valeurs dans l'historique du trafic capturé pour l'application (toujours via le proxy d'attaque BURP) permet alors d'identifier leur origine et de confirmer cette hypothèse :
- secret#1 (s1) s'avère être une valeur statique, récupérée au démarrage de l'application à l'aide d'une requête à destination de Firebase ;
- secret#2 (s2) s'avère être le jeton de session retourné par l'application après une authentification réussie.
Militarisation
L'ensemble de ces données en main, le rejeu d'une requête forgée est possible (incluant des paramètres altérés pour les besoins de test).
Un très grand nombre de ces requêtes est cependant très classiquement effectué au cours d'un audit incluant une API au périmètre.
Il apparait donc impensable de répéter "manuellement" ou par voie d'exécution de script unitaire le procédé de mise à jour d'une signature mis à nu ci-dessus.
La nécessité d'automatiser le processus apparait donc comme une clé de voute à la poursuite de l'audit et nous décidons la conception d'un plugin BURP dédié.
Défense en profondeur ou défense de surface ?
À ce stade, nos auditeurs ont les sourcils froncés. Non moins que quelques heures de travail auront été nécessaires pour enfin démarrer le travail de fond sur l'API et la recherche de potentiels défauts de cloisonnement des données ou des violations possibles du modèle d'autorisations.
Tout lecteur attentif au préambule de cet article pourrait d'ailleurs à ce stade s'interroger sur la validité de notre choix d'approche, voire prôner ici la mise en œuvre d'une véritable défense en profondeur applicative.
Pourtant, la suite des tests sera expéditive.
Les premières requêtes forgées (capturées, modifiées et rejouées) par l'intermédiaire de notre proxy d'attaque BURP recalculant désormais à la volée la signature anti-rejeu montrent un défaut total de cloisonnement et tout utilisateur authentifié s'avère pouvoir récupérer l'ensemble des données adressables par les API retournant elle-même l'intégralité des modèles en base de données, toujours sur simple modification des paramètres de requêtes.
Ce constat se répétant sur de multiples services exposés (champs de recherche, de consultation de fiches, etc.), un développement complémentaire est réalisé et permet une seconde automatisation pour extraire des données à grande échelle, administratives d'abord (patronymes, dates de naissance, adresses postales, courriels, numéros de téléphone...), puis de santé (discussions entre professionnels assignés au suivi d'un patient, compte-rendu d'examen, photocopies de carnet de santé, etc.)
Au final, un échantillon de données concernant plus de 33 000 patients d'un territoire de France est exfiltré et remis au commanditaire de l'audit à titre de preuve de concept (avant d'être supprimé de nos répertoires chiffrés).
Conclusion
Nous avons exploré ici un cas illustratif d'une cause que nous hasarderons comme un retard de fond dans l'intégration de la cybersécurité au sein des développements applicatifs, même s'il s'agit bien sûr d'un cas peut-être anecdotique, d'une application spécifique, d'un éditeur particulier…
Pourtant, l'actualité semble démentir la possibilité qu'il s'agisse d'un cas véritablement isolé.
En France, la part des attaques ciblant le secteur et traitées par l’ANSSI est passée de 2,87 % en 2020 à 11,4 % en 2023, avec 86 % des incidents concernant des établissements de santé.
À l’échelle mondiale, le secteur enregistre une intensification similaire : entre janvier et septembre 2024, les organisations de santé subissaient en moyenne quelques milliers d'attaques par semaine, soit une augmentation atteignant +56 % en Europe. Cette pression croissante se traduit également par une explosion des compromissions : en 2023, plus de 133 millions de dossiers médicaux ont été exposés de par le monde, un record historique, tandis que 92 % des organisations de santé mondiales déclaraient avoir subi au moins une cyberattaque en 2024.
Alors que faire ?
Rien que d'autres n'auront déjà conseillé en pareille situation, mais que nous nous permettrons ici de rappeler sous la forme de quelques bonnes pratiques parmi :
- La sensibilisation de toutes les parties prenantes aux risques cybersécurité ;
- La formation continue des DevSecOps aux pratiques de développement sécurisé ;
- L'inscription de vos actifs à un plan d'audit récurrent et priorisé par niveau de criticité ;
- L'engagement contractuel de la responsabilité des tiers fournisseurs et le contrôle de leurs pratiques.
Postface
Depuis 2023, le plan CaRE vient permettre d’adresser une dette cybersécurité française dans l’écosystème santé, en apportant un investissement de près d'un milliard d'euros jusqu'en 2027 pour renforcer la résilience des établissements de santé.
Au‑delà de CaRE, la France a également mobilisé d’autres leviers à l'instar des audits financés par l’ANS et les dispositifs d’appui opérationnel de l’ANSSI et du CERT‑Santé visant à réduire l’exposition des établissements face aux attaques récurrentes.
La dynamique d'ensemble de ces dernières années crée une traction positive pour tout l’écosystème cybersécurité en santé, le plaçant durablement sur les rails de l’amélioration continue — une trajectoire qu’il convient désormais de poursuivre et amplifier.
Akyl s’engage dans ce programme et au‑delà, en soutenant la montée en maturité cyber des acteurs de santé, en développant des outils (EWS, AIR2...), avec une approche pragmatique et opérationnelle pour réduire les surfaces d’attaque, accélérer la remédiation et sécuriser durablement l’écosystème.
.svg)
