The Indian Government said it has addressed a critical vulnerability in its secure document wallet service Digilocker that could have potentially let a remote attacker bypass mobile one-time passwords (OTP) and sign in as other users.
Discovered separately by two independent bug bounty researchers, Mohesh Mohan and Ashish Gahlot, the vulnerability could have been exploited easily to unauthorisedly access sensitive documents uploaded by targeted users' on the Government-operated platform.
"The OTP function lacks authorization which makes it possible to perform OTP validation with submitting any valid users details and then manipulation flow to sign in as a totally different user," Mohesh Mohan said in a disclosure shared with The Hacker News.
With over 38 million registered users, Digilocker is a cloud-based repository that acts as a digital platform to facilitate online processing of documents and speedier delivery of various government-to-citizen services. It's linked to a user's mobile number and Aadhar ID—a unique identity number (UID) issued to every resident of India.
According to Mohan, all an attacker needs to know is either victim's Aadhaar ID or linked mobile number or username to unauthorizedly access a targeted Digilocker account, prompting the service to send an OTP and subsequently exploiting the flaw to bypass the sign-in process.
It's worth noting that the mobile app version of Digilocker also comes with a 4-digit PIN for an added layer of security. But the researchers said it was possible to modify the API calls to authenticate the PIN by associating the PIN to another user (identified with a version-5 UUID) and successfully login in as the victim.
This means "you can do the SMS OTP [verification] as one user and submit the pin of a second user, and finally, you will end up logging as the second user," Mohan said.
What's more, the lack of authorization for the API endpoint used to set the secret PIN effectively implies the API can be exploited to reset the PIN linked to a random user using the individual's UUID.
"There is no session-related information on the POST request, so it's not bound to any user," Mohan added.
In addition to the issues mentioned above, the API calls from mobile apps were secured by basic authentication that can be circumvented by removing a header flag "is_encrypted: 1." The application was also found to implement a weak SSL pinning mechanism, making them vulnerable to a bypass using tools like Frida.
After the flaw was reported to CERT-In on May 10 by Mohan and to DigiLocker on 16th May by Ashish, the cyber agency said the issue was fixed on May 28.
"The nature of the vulnerability was such that an individual's DigiLocker account could potentially get compromised if the attacker knew the username for that particular account," Digilocker said in a tweet last week acknowledging the flaw. "It was not a vulnerability that could let anyone get access to [the] DigiLocker account of anyone whose username and other details were not known."
"Upon analysis, it was discovered that this vulnerability had crept in the code when some new features were added recently. The vulnerability was patched on a priority basis by the technical team within a day of getting the alert from CERT-In. This was not an attack on infrastructure, and no data, database, storage, or encryption was compromised," the team added.
Discovered separately by two independent bug bounty researchers, Mohesh Mohan and Ashish Gahlot, the vulnerability could have been exploited easily to unauthorisedly access sensitive documents uploaded by targeted users' on the Government-operated platform.
"The OTP function lacks authorization which makes it possible to perform OTP validation with submitting any valid users details and then manipulation flow to sign in as a totally different user," Mohesh Mohan said in a disclosure shared with The Hacker News.
With over 38 million registered users, Digilocker is a cloud-based repository that acts as a digital platform to facilitate online processing of documents and speedier delivery of various government-to-citizen services. It's linked to a user's mobile number and Aadhar ID—a unique identity number (UID) issued to every resident of India.
According to Mohan, all an attacker needs to know is either victim's Aadhaar ID or linked mobile number or username to unauthorizedly access a targeted Digilocker account, prompting the service to send an OTP and subsequently exploiting the flaw to bypass the sign-in process.
It's worth noting that the mobile app version of Digilocker also comes with a 4-digit PIN for an added layer of security. But the researchers said it was possible to modify the API calls to authenticate the PIN by associating the PIN to another user (identified with a version-5 UUID) and successfully login in as the victim.
This means "you can do the SMS OTP [verification] as one user and submit the pin of a second user, and finally, you will end up logging as the second user," Mohan said.
What's more, the lack of authorization for the API endpoint used to set the secret PIN effectively implies the API can be exploited to reset the PIN linked to a random user using the individual's UUID.
"There is no session-related information on the POST request, so it's not bound to any user," Mohan added.
In addition to the issues mentioned above, the API calls from mobile apps were secured by basic authentication that can be circumvented by removing a header flag "is_encrypted: 1." The application was also found to implement a weak SSL pinning mechanism, making them vulnerable to a bypass using tools like Frida.
After the flaw was reported to CERT-In on May 10 by Mohan and to DigiLocker on 16th May by Ashish, the cyber agency said the issue was fixed on May 28.
"The nature of the vulnerability was such that an individual's DigiLocker account could potentially get compromised if the attacker knew the username for that particular account," Digilocker said in a tweet last week acknowledging the flaw. "It was not a vulnerability that could let anyone get access to [the] DigiLocker account of anyone whose username and other details were not known."
"Upon analysis, it was discovered that this vulnerability had crept in the code when some new features were added recently. The vulnerability was patched on a priority basis by the technical team within a day of getting the alert from CERT-In. This was not an attack on infrastructure, and no data, database, storage, or encryption was compromised," the team added.