Loopholes in Aadhaar authentication API services
Aadhar Logo
Using this loophole anybody can use Aadhaar demographic authentication API by piggybacking my requests through NSDL servers and bypass the checks at place by UIDAI.
This story is going to be about how just about anyone can access the API that Aadhaar provides to third party services.
What is Aadhaar?
Aadhaar is the world’s largest biometric ID system, with over 1.19 billion enrolled members as of 30 Nov 2017. As of this date, over 99% of Indians aged 18 and above had been enrolled in Aadhaar.
What is Aadhaar API?
UIDAI (Unique Identification Authority of India) provides different APIs (application programming interface) which can be used to perform various actions like authentication (demographic and biometric), e-KYC (know your customer), e-sign etc.
We are discussing about Aadhaar Authentication API for now.
Going further, you have to know what AUA and SA are
Authentication User Agency (AUA): AUA is an organization or an entity using Aadhaar authentication as part of its applications to provide services to residents. Examples include Government Departments, Banks, and other public or private organizations. All AUAs (Authentication User Agencies) must be registered within Aadhaar authentication server to perform secure authentication.
Sub-AUA (SA): SA is an organization, a department or an entity having a business relationship with AUA offering specific services in a particular domain. All authentication requests emerging from an AUA contains the information on the specific SA. For example, a specific bank providing Aadhaar enabled payment transaction through NPCI as the AUA becomes the SA. Similarly, a state government being an AUA can have the health department under them as the SA using Aadhaar authentication while providing healthcare benefits.
What is Demographic Authentication?
As depicted in Aadhaar API website(which is another AUA) just like Aadhaarbridge.
The above image explains everything. If you have the Aadhaar number and/or any of the other details like Date of birth, Name, Gender, Address the server will give you a YES if the details match in the Aadhaar database and NO otherwise. Sub-AUA is allowed to do only Yes/No Authentication.
The current list of active AUAs is here. There are 301 active AUAs right now. There is no public list of active Sub-AUAs anywhere.
Who can be a AUA/SUB-AUA?
In order to be an AUA, one has to apply to the UIDAI and must follow certain guidelines. In order to register as a Sub-AUA under any AUA, you need approval from UIDAI, and the AUA will also charge a substantial amount. Which means UIDAI knows which organisations are using Aadhaar services.
The reason for writing the above in detail is to help you understand the problem better.
What is the vulnerability?
Recently the author was applying a PAN card online for his relative where he noticed that they use Aadhaar authentication services to check if the details we provide are indeed true. Curious, author checked the request that was being sent to verify this. He got shocked seeing how it was implemented.
No doubt UIDAI is taking steps to protect the data. According to them, only registered AUA/SUB-AUA can perform any Aadhaar authentication request. They also track every request that is generated.
How about an insecure SUB-AUA?
The way the authentication is implemented presently in the NSDL(National Securities Depository Limited) website, anybody can just send the following POST request with the necessary details like Aadhaar number, name, date of birth, gender etc. and the server will reply with either a PASSor FAIL. If you notice, there is no need for cookies.
https://www.onlineservices.nsdl.com/paam/verify3.html Content-Type:application/x-www-form-urlencoded; charset=UTF-8 Accept:*/* X-Requested-With:XMLHttpRequest
adharNo=************&name=****+****&yob=**%2F**%2F****&gen=*&userId=0000000000&verification=K
The body data in the POST request is as follows.
adharNo=Aadhaar Number&name=Name on card&yob=dd/mm/yyyy&gen=M(or)F&userId=0000000000&verification=K
Look at the screenshots attached below. The first one shows a YES case. In the second image, He has changed the date of birth by one day and the response is a FAIL, which indicates a NO case.
Look at the changed date in the date of birth.
Same Request in Burp Suite which shows a PASS case without the cookies.
Basically, we are piggybacking on their services to make our requests. And since there is no login required, UIDAI thinks that all the requests are originating from NSDL servers.
Which is clearly not the case, as one can make as many requests as needed for free.
This in fact should have been chargeable by the other AUAs.
Which is clearly not the case, as one can make as many requests as needed for free.
This in fact should have been chargeable by the other AUAs.
The issue here is that the author found this loophole in less than 5 minutes in a SUB-AUA that performs demographic authentication for the general public.
Which means there are plenty more such hidden vulnerabilities present.
The Above awesome post is written and researched by
Sai Krisha Kothapalli : kmskrishna@protonmail.com
You can find his profile here.
Comments
Post a Comment