Qu'est-ce que JPCERT/CC a identifié comme les principales causes des récentes fuites de données au Japon ?

JPCERT/CC a relié la recrudescence des fuites de données à l'abus d'API d'applications mobiles et à des failles logicielles connues, notamment une faille d'injection SQL exploitée dans Metabase.

Qu'est-ce que l'injection SQL et comment fait-elle fuiter des données ?

L'injection SQL se produit lorsqu'une application transmet une entrée fournie par l'utilisateur dans une requête de base de données sans la vérifier correctement, permettant aux attaquants de concevoir une entrée qui modifie la requête et de lire des données qu'ils ne devraient jamais voir.

Qu'est-ce que l'abus d'API mobiles et comment mène-t-il à des fuites de données ?

L'abus d'API mobiles se produit lorsqu'une API ne vérifie pas correctement qui fait la demande ou ce qu'il est autorisé à récupérer, permettant à quelqu'un d'envoyer des requêtes directement à cette API et de récupérer des données en masse.

À qui incombe la responsabilité de corriger ces vulnérabilités ?

La faiblesse réside chez l'organisation qui exploite le service, et corriger les failles connues et renforcer les contrôles d'accès aux API relèvent de l'opérateur, pas du client.

Que peuvent faire les utilisateurs individuels pour se protéger ?

Il y a peu de choses que les utilisateurs peuvent configurer directement, mais ils peuvent surveiller les signes qu'un service a été affecté, tels que des e-mails de notification, des messages de réinitialisation de mot de passe inattendus, ou du hameçonnage faisant référence à des détails que seule cette entreprise devrait connaître.

JPCERT/CC relie les fuites de données japonaises à l'abus d'API mobiles

L'équipe nationale d'intervention en cas d'urgence informatique du Japon, JPCERT/CC, a relié une récente recrudescence des fuites de données web à deux causes principales : l'abus d'API d'applications mobiles et des failles logicielles connues, notamment une faille d'injection SQL exploitée dans Metabase. Cette affaire rappelle utilement que les fuites de données web japonaises et les faiblesses des API mobiles sont généralement des problèmes côté serveur, dans des systèmes que les utilisateurs ne peuvent ni voir ni contrôler.

Ce que JPCERT/CC a découvert derrière les fuites de données japonaises

Selon le rapport, JPCERT/CC relie la récente recrudescence des fuites de données au Japon à l'abus d'API d'applications mobiles et à des vulnérabilités déjà connues du public. L'un des exemples cités est une faille d'injection SQL dans Metabase, que des attaquants ont exploitée.

Le fil conducteur est qu'il ne s'agit pas d'attaques exotiques. Des failles connues et des interfaces mal protégées constituent les points d'entrée. Le résumé du document source ne relie pas les fuites à quoi que ce soit que les utilisateurs individuels auraient fait, et cela importe pour la manière dont les lecteurs devraient envisager le risque : les données personnelles ont été exposées par les services qui les détenaient.

Comment l'injection SQL et les API mobiles exposées font fuiter des données personnelles

Deux termes techniques structurent cette affaire, il est donc utile de les définir simplement.

L'injection SQL se produit lorsqu'une application transmet une entrée fournie par l'utilisateur dans une requête de base de données sans la vérifier correctement. Un attaquant peut concevoir une entrée qui modifie la requête, ce qui peut lui permettre de lire des données qu'il ne devrait jamais voir. Metabase est un outil d'analyse de données qui se connecte à des bases de données, de sorte qu'une faille en son sein peut mettre les enregistrements sous-jacents à portée de main.

L'abus d'API mobiles est une voie différente vers un résultat similaire. Une application mobile communique avec les serveurs d'une entreprise via une API. Si cette API ne vérifie pas correctement qui fait la demande, ou ce qu'il est autorisé à récupérer, quelqu'un peut envoyer des requêtes directement à cette API, en dehors de l'application, et récupérer des données en masse. L'application sur votre téléphone peut sembler parfaitement normale alors que le serveur derrière elle distribue plus qu'il ne devrait.

Dans les deux cas, la faiblesse réside chez l'organisation qui exploite le service. Corriger les failles connues et renforcer les contrôles d'accès aux API sont les remèdes, et les deux relèvent de l'opérateur, pas du client.

Ce que les utilisateurs et les services japonais devraient vérifier maintenant

Pour les organisations, l'accent mis par le rapport sur les failles connues renvoie à une liste de vérification de base :

Confirmer que tout déploiement de Metabase est mis à jour vers une version qui corrige la faille d'injection SQL exploitée.
Examiner les API des applications mobiles pour s'assurer que chaque requête est authentifiée et que les utilisateurs ne peuvent récupérer que leurs propres enregistrements.
Traiter les vulnérabilités divulguées publiquement comme urgentes, car les attaquants les utilisent déjà.

Pour les utilisateurs individuels, il y a peu à configurer directement, mais vous pouvez surveiller les signes qu'un service que vous utilisez a été affecté : e-mails de notification, messages de réinitialisation de mot de passe inattendus, ou hameçonnage faisant référence à des détails que seule cette entreprise devrait connaître.

Comment limiter votre exposition après une fuite

Il vaut la peine d'être direct sur un point : un VPN ne règle pas ce problème. Un VPN chiffre le trafic entre votre appareil et un serveur VPN et masque votre adresse IP, ce qui est utile pour la confidentialité sur des réseaux non fiables. Il ne fait rien contre une faille dans une base de données ou une API qui stocke vos informations. Si un service fait fuiter vos enregistrements, le chemin emprunté par les données pour y arriver n'a aucune importance pour la manière dont elles ont été exposées.

Ce qui aide, c'est de limiter les dégâts lorsqu'une fuite se produit :

Utilisez un mot de passe unique pour chaque compte. Si un service est compromis, les attaquants ne peuvent pas réutiliser les mêmes identifiants ailleurs. Un gestionnaire de mots de passe rend cela praticable.
Activez la surveillance des fuites. De nombreux navigateurs, gestionnaires de mots de passe et services indépendants vous alerteront lorsque votre e-mail apparaît dans une fuite connue.
Partagez moins de données avec les applications. Les champs que vous n'avez jamais fournis ne peuvent pas fuiter. Ignorez les détails facultatifs et utilisez une adresse e-mail distincte pour les services à faible confiance.
Activez l'authentification multifacteur là où elle est proposée, afin qu'un mot de passe fuité ne suffise pas à lui seul.
Soyez prudent avec les messages inattendus. Les coordonnées fuitées alimentent souvent des campagnes de hameçonnage ciblées.

Ce que cela signifie pour vous

Les conclusions de JPCERT/CC renforcent l'idée que votre exposition dépend fortement de la manière dont les entreprises en lesquelles vous avez confiance entretiennent leurs systèmes. Vous ne pouvez pas corriger leurs serveurs, mais vous pouvez réduire ce qui est en jeu. Partez du principe qu'une partie de vos données finira par être exposée quelque part, et assurez-vous que cette exposition ne déverrouille pas vos autres comptes.

Pour un exemple récent de ce à quoi ressemble une exposition à grande échelle au Japon, consultez notre couverture de la fuite KDDI qui a exposé 12,2 millions d'e-mails clients au Japon. Les adresses e-mail seules peuvent sembler anodines, mais elles sont exactement le type de données qui alimente les campagnes de hameçonnage.

Points clés à retenir

Les fuites de données web japonaises liées à l'abus d'API mobiles et à des logiciels non corrigés sont un problème côté service, et un VPN ne les résoudra pas. Utilisez des mots de passe uniques, activez la surveillance des fuites, activez l'authentification multifacteur et ne donnez aux applications que les données dont elles ont réellement besoin. Ces habitudes n'empêcheront pas une fuite, mais elles peuvent éviter qu'une seule ne devienne un problème bien plus grave pour vous.