Les applications mHealth exposent des millions de clients

0

Quelque 23 millions d’utilisateurs d’applications mobiles de santé (mHealth) sont exposés à des attaques d’interface de programmation d’application (API) qui pourraient exposer des informations sensibles, selon les chercheurs.

De manière générale, les API sont un intermédiaire entre les applications qui définit comment elles peuvent se parler et leur permettre d’échanger des informations. La chercheuse Alissa Knight de Approov a tenté de pénétrer dans les API de 30 fournisseurs d’applications mHealth différents, avec l’accord qu’elle n’identifierait pas les plus vulnérables. Il s’avère qu’elles étaient toutes vulnérables à un degré ou à un autre.

Le nombre moyen de téléchargements pour chaque application mHealth testée était de 772 619.

Selon le rapport d’Approov, sur 30 applications mHealth populaires analysées, 77% d’entre elles contenaient des clés API codées en dur, ce qui permettrait à un attaquant d’intercepter cet échange d’informations – dont certaines n’expirent pas. Sept pour cent d’entre elles appartenaient à des traiteurs de paiement tiers qui mettent explicitement en garde contre le codage en dur de leurs clés secrètes en texte brut.

7% contenait des noms d’utilisateur et des mots de passe codés en dur.

mHealth

Mais ce n’est pas tout: plus d’un quart (27%) des applications mHealth testées n’ont pas de protection d’obscurcissement du code contre l’ingénierie inverse; et toutes, sans exception, manquaient d’épinglage de certificat, ce qui empêche les attaques de l’homme (ou de la femme) du milieu (MITM), pour intercepter les communications dans le but d’observer ou de manipuler les données.

En outre, 50% des API testées n’ont pas authentifié les requêtes avec des jetons.

Et enfin, si les dossiers d’un patient sont accessibles, il est souvent possible d’accéder à de nombreux autres sans discernement: 100% des points de terminaison d’API testés étaient vulnérables aux attaques BOLA (Broken Object Level Authorization), ce qui permettait au chercheur de visualiser les informations de santé personnelles (PHI) et les informations personnellement identifiables (PII) pour les patients qui n’ont pas été attribuées au compte clinicien du chercheur.

Le rapport indique que plus de 318 000 applications mHealth sont disponibles dans les principaux magasins d’applications.

Les dossiers médicaux attirent les cybercriminels

La pandémie a poussé les hôpitaux et les prestataires de soins à s’appuyer de plus en plus sur les applications mHealth. Mais l’analyse révèle que ces applications sont souvent vulnérables aux attaquants, exposant des informations critiques et précieuses sur la santé.

Ce qui a exacerbé la posture de sécurité des applications mobiles de santé(mHealth), c’est la course folle à l’innovation d’abord, puis à la sécurité, a expliqué Knight. Et le moment est venu pour la sécurité de rattraper son retard avant qu’une grande faille ne se produise, a-t-elle ajouté.

mHealth

Les pirates informatiques ont quant à eux un grand intérêt financier à cibler ces API mHealth. Knight a souligné que si le prix courant chez les cybercriminels pour un numéro de sécurité sociale est de 1$ et qu’un numéro de carte de crédit se vend à environ 110$, le pactole se trouve dans les dossiers médicaux complets, qui coûtent environ 1000$ chacun.

«Cette surface d’attaque croissante attire rapidement l’attention des syndicats du crime transnational qui veulent la verrouiller et la divulguer afin d’extorquer des paiements à ses propriétaires de données et de les vendre au plus offrant», écrit Knight dans le rapport.

Quelle est la principale menace pour les applications mHealth?

BOLA (a.k.a. Insecure Direct Object Reference, ou IDOR) est le vecteur d’abus le plus courant pour les API mHealth, a déclaré Knight, soulignant que ce n’est pas un hasard si la liste récemment publiée par OWASP des principales menaces d’API place ces types de vulnérabilités en tête.

«En termes simples, une vulnérabilité BOLA permet à un adversaire de remplacer l’ID d’une ressource par l’ID d’une autre», a expliqué Knight. «Lorsque l’ID d’objet peut être directement appelé dans l’URI, cela ouvre le point de terminaison jusqu’à l’énumération d’ID qui permet à un adversaire de lire des objets qui ne lui appartiennent pas. Ces références exposées à des objets d’implémentation internes peuvent pointer vers n’importe quoi, qu’il s’agisse d’un fichier, d’un répertoire, d’un enregistrement de base de données ou d’une clé. « 

Les attaques BOLA en laboratoire menées par Knight ont piraté 100% des applications qu’elle a testées, lui donnant un accès théorique aux dossiers complets des patients, y compris les résultats de laboratoire, les images radiographiques, les analyses de sang, les antécédents familiaux, les dates de naissance, les numéros de sécurité sociale et plus.

Autorisation d’API et authentification

Knight a expliqué qu’en ce qui concerne les API, les RSSI et les équipes de sécurité doivent réfléchir à la distinction entre authentification et autorisation.

Knight a utilisé l’analogie de la sécurité dans une boîte de nuit.

Dans un scénario d’autorisation uniquement, le videur (l’autorisation) vérifie les ID et détermine qui est autorisé à l’intérieur de la boite de nuit. Pour que, à l’intérieur, quand quelqu’un se présente au bar et commande un verre, le barman peut simplement supposer que cette personne est majeure et peut consommer de l’alcool.

Mais dans un scénario d’authentification, il y a deux vérifications.

Le videur vérifie les pièces d’identité et délivre des bracelets aux personnes autorisées à boire. Une fois au bar, le barman (l’authentificateur) recherche un bracelet comme couche supplémentaire de contrôle. La double vérification du barman confirme que la personne n’est pas seulement autorisée à être dans le bar, mais elle garantit également que son identité est authentifiée pour s’assurer qu’elle est à la fois autorisée à entrer et à consommer de l’alcool.

Les API fonctionnent à peu près de la même manière, a expliqué Knight. La moitié des API mHealth qu’elle a testées pour ce rapport n’ont pas authentifié les requêtes avec des jetons.

«Les types d’authentification dans les API incluent les clés d’API, une longue chaîne de nombres aléatoires et de caractères générés par le point de terminaison de l’API qui accorde l’accès à quiconque le transmet dans l’en-tête d’autorisation de la requête; Basic Auth où un nom d’utilisateur et un mot de passe sont utilisés pour authentifier une personne; Jetons Web JSON (JWT) et OAuth, qui utilisent des jetons au lieu de partager les informations d’identification; OAuth2, qui échange un nom d’utilisateur et un mot de passe contre un jeton; SMART, qui devient de plus en plus une implémentation d’OAuth dans les soins de santé; et OpenID Connect », a déclaré Knight.

«Il existe également d’autres méthodes d’authentification, telles que la mise en œuvre de l’authentification multifactorielle via des solutions tierces.»

Implémenter une meilleure sécurité des applications mHealth

David Stewart, fondateur et PDG d’Approov, a expliqué que les normes de sécurité existantes ne sont pas adéquates pour faire face aux menaces de sécurité croissantes pesant sur les applications de santé mobiles. Les entreprises doivent faire plus.

«Ces résultats sont décevants mais pas du tout surprenants», a déclaré Stewart. «Le fait est que les principaux développeurs et leurs clients professionnels et organisationnels ne parviennent systématiquement pas à reconnaître que les API desservant des clients distants tels que les applications mobiles ont besoin d’un nouveau paradigme de sécurité dédié. « 

Les entités de soins de santé doivent comprendre que les API sont une porte ouverte aux acteurs malveillants, en particulier sur le marché lucratif des informations de santé protégées, a-t-il souligné.

«Étant donné que si peu d’organisations déploient des protections pour les API qui garantissent que seules les instances d’application mobile authentiques peuvent se connecter aux serveurs backend, ces API sont une porte ouverte pour les pirates informatiques et représentent un véritable cauchemar pour les organisations vulnérables et leurs patients», a déclaré Stewart.

Si cet article vous a plu, jetez un œil à notre article précédent.

Vous pourriez aussi aimer
Laisser un commentaire

Votre adresse email ne sera pas publiée.