Tout compte DigiLocker indien aurait pu être accédé sans mot de passe

Le gouvernement indien a déclaré qu’il avait adressé une vulnérabilité critique dans son service de portefeuille de documents sécurisé Digilocker qui aurait pu permettre à un attaquant distant de contourner les mots de passe mobiles à usage unique (OTP) et de se connecter en tant qu’autres utilisateurs.

Découvert séparément par deux chercheurs indépendants sur le bug bounty, Mohesh Mohan et Ashish Gahlot, la vulnérabilité aurait pu être exploitée facilement pour accéder sans autorisation à des documents sensibles téléchargés par des utilisateurs ciblés sur la plateforme gérée par le gouvernement.

« La fonction OTP manque d’autorisation, ce qui permet d’effectuer la validation OTP en soumettant tous les détails d’utilisateurs valides, puis le flux de manipulation pour se connecter en tant qu’utilisateur totalement différent », a déclaré Mohesh Mohan dans une divulgation partagée avec The Hacker News.

Avec plus de 38 millions Utilisateurs enregistrés, Digilocker est un référentiel basé sur le cloud qui agit comme une plate-forme numérique pour faciliter le traitement en ligne des documents et une livraison plus rapide de divers services de gouvernement à citoyen. Il est lié au numéro de téléphone mobile d’un utilisateur et à l’identifiant Aadhar, un numéro d’identité unique (UID) attribué à chaque résident de l’Inde.

Selon Mohan, tout ce qu’un attaquant doit savoir est soit l’identifiant Aadhaar de la victime, soit le numéro de téléphone mobile associé ou le nom d’utilisateur pour accéder de manière non autorisée à un compte Digilocker ciblé, ce qui incite le service à envoyer un OTP et exploite ensuite la faille pour contourner le processus de connexion.

Il convient de noter que la version d’application mobile de Digilocker est également livrée avec un code PIN à 4 chiffres pour une couche de sécurité supplémentaire. Mais les chercheurs ont déclaré qu’il était possible de modifier les appels API pour authentifier le code PIN en associant le code PIN à un autre utilisateur (identifié par un UUID version-5) et connectez-vous avec succès en tant que victime.

Cela signifie « vous pouvez faire le SMS OTP [verification] en tant qu’un utilisateur et soumettez la broche d’un deuxième utilisateur, et enfin, vous finirez par vous connecter en tant que deuxième utilisateur », a déclaré Mohan.

De plus, le manque d’autorisation pour le point de terminaison de l’API utilisé pour définir le code PIN secret implique effectivement que l’API peut être exploitée pour réinitialiser le code PIN lié à un utilisateur aléatoire en utilisant l’UUID de l’individu.

« Il n’y a pas d’informations relatives à la session sur la requête POST, donc elle n’est liée à aucun utilisateur », a ajouté Mohan.

En plus des problèmes mentionnés ci-dessus, les appels d’API à partir des applications mobiles ont été sécurisés par une authentification de base qui peut être contournée en supprimant un indicateur d’en-tête « is_encrypted: 1. » Il a également été constaté que l’application implémentait un mécanisme d’épinglage SSL faible, ce qui les rendait vulnérables à un contournement à l’aide d’outils tels que Frida.

Après que la faille ait été signalée au CERT-In le 10 mai par Mohan et à DigiLocker le 16 mai par Ashish, la cyber-agence a déclaré que le problème avait été résolu le 28 mai.

« La nature de la vulnérabilité était telle que le compte DigiLocker d’un individu pouvait potentiellement être compromis si l’attaquant connaissait le nom d’utilisateur de ce compte particulier », Digilocker a dit dans un tweet la semaine dernière reconnaissant la faille. « Ce n’était pas une vulnérabilité qui pouvait permettre à quiconque d’accéder à [the] Compte DigiLocker de toute personne dont le nom d’utilisateur et les autres détails n’étaient pas connus. « 

«Lors de l’analyse, il a été découvert que cette vulnérabilité s’était glissée dans le code lorsque de nouvelles fonctionnalités ont été ajoutées récemment. La vulnérabilité a été corrigée en priorité par l’équipe technique dans la journée suivant la réception de l’alerte de CERT-In. Ce n’était pas une attaque contre l’infrastructure, et aucune donnée, base de données, stockage ou chiffrement n’a été compromis », a ajouté l’équipe.