This is a guest blog post by our friend Sai Krishna whom LD founder Gobi Dasu met at IIT Guwahati on his way to the Kaziranga Rhino Reserve in Assam in Jan 2018. Sai is a prolific author on medium and covers important computer security issues across multinational corporate infrastructure and also Indian government websites. We founders of Learning Dollars had a wonderful chat with him at the CCD on IIT Guwahati’s picturesque campus and look forward to new updates on his startup Hackrew. Without further ado, here is how Sai was able to identify within 5 minutes an issue with the Aadhaar API (which is of course fixed now):
TLDR: 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. Read till the end to find out how.
This story is going to be about how just about anyone can access the API that Aadhaar provides to third party services.
In order for you to understand the content better, I will write this blog in a question-answer format. You can skip the questions you are already aware of.
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 NOotherwise. 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 I was applying a PAN card online for my mom. I noticed that they use Aadhaar authentication services to check if the details we provide are indeed true. Curious, I checked the request that was being sent to verify this. I 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 PASS or 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
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, I have 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.
Well, now that you know my birthday, don’t forget to wish me!! 😀
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 I can make as many requests as I want for free. This in fact should have been chargeable by the other AUAs.
In this case my intention was not to mess around with anything related to Aadhaar. I understand that this is not such a serious issue because I can’t retrieve the Aadhaar information, I can only verify it. I believe if you look closely into the AUAs, KUAs and SUB-AUAs which are only going to increase in future, you will find loopholes for sure. Remember the Srivastava case from last year who made a e-KYC app(as far as I remember he also did something like this but for the KYC API)
I understand that your infrastructure and the way you store the data is secure but that doesn’t mean that there are no vulnerabilities along the way.
The issue here is that I found this loophole in less than 5 minutes in a SUB-AUA that performs demographic authentication for the general public. I believe that on closer inspection, you can find implementation vulnerabilities in bio metric authentication and AUAs too.
Hello UIDAI people, I love you all. Please don’t file an FIR against me. I personally think that the idea of Aadhaar is great, at the same time, I don’t really like how you deal with the security issues. Listen to the security community; let them help you. So who is here to blame? You for creating a database, the NSDL developers for writing a bad code or me for talking about it? We both want the same thing here, which is, our data being safe and secure.
I also read through the entire Chapter VII — Offences and Penalties in the Aadhaar Act 2016 before writing this blog and came to the conclusion that I am not breaking any law.
I think this is a serious issue that needs to be looked into. I read a lot of your technical documentation and white paper to understand where the vulnerability lies, and I know that you take the security of Aadhaar data seriously.
Proof that the SUB-AUA server is indeed authenticating. You can view how many times your Aadhaar details have been accessed from UIDAI repository here.
It shows that there are no Aadhaar authentications which are done in between 11–01–2018 and 12–01–2018. After I perform the above mentioned POST request I get a PASS(YES) response.
You can clearly see that the request was made by me. But the Aadhaar server thinks that the request has been made by NSDL(pan card online apply) server.
I had no prior knowledge about how the Aadhaar API works and how it is accessible. I did a lot of research about how these things worked. If you found some misinformation in my post or you want to reach out, please mail me at firstname.lastname@example.org
Readers, share this post so that it will reach even more people.
Edited to add (23/06/2018): In a similar exposure of Aadhaar’s cybersecurity weaknesses, over 70 subdomains under a Government of India website were found to be providing access to demographic-authentication services without requiring identity verification from the requester. This vulnerability was discovered independently by two security researchers — Srinivas Kodali and Karan Saini.
This is similar to what I had found — and even after so many months of my first reporting, nothing has been done for the bug to be fixed.
If you liked my writeup don’t forget to clap and if you like similar writeups don’t forget to follow me on Medium.