The inside man (Part 4)

A version of this story appeared in a different form in AltNews. Do read Part 1 (Very technical), Part 2 (Non technical) and Part 3 (Technical) for background.

The Breach

Was Aadhaar really breached? After all did not Nandan Nilekani, proudly say “Show me even one example of data theft. Aadhaar is very, very secure” ? So why was Abhinav Srivastav arrested for Aadhaar data theft?

The answer is complicated.

Aadhaar is a digital vault. No biometric data ever gets out, but demographic data like Name, Age, Date of Birth, Phone number, Email address and the postal address are routinely given out after user consent. Only 254 entities are given the license key to take it out via the eKYC API, with the explicit contractual understanding that they cannot share this key to anyone else.

These entities are called Know Your Customer User Agencies (KUA). They are permitted by UIDAI to provide Know Your Customer (KYC) services for the purchase of SIM cards, opening bank accounts, invest in mutual funds etc, for which they have to sign a license agreement with KYC Service Agencies (KSA). The KSAs are directly regulated by the UIDAI and have restricted leased line connectivity to the digital vault.

This scheme is shown below.

One of these 254 KUA entities is the National Informatics Centre, that builds e-governance portals and applications for the central and state government. They built an android application to allow anyone to schedule appointments and manage payments to government hospitals and the onboarding process needed users to register with their Aadhaar number.

Since it allowed booking appointments with just Aadhaar number, the back end was integrated with Aadhaar eKYC API.

The NIC back end, however had the following vulnerabilities.

1. It was hosted on HTTP (http://ors.gov.in/ORSServicecontainer/services) and hence communication to the back end was not encrypted.
2. The back end was protected by a single default credential dG9rZW5Ad2ViQGFwcG9pbnQjbmlj
3. This allowed any application or person to call the NIC eKYC Proxy APIs using the default credential to do an Aadhaar eKYC.
4. Since the NIC eKYC Proxy APIs used the KUA license key internally, UIDAI was not able to distinguish these requests as coming from a third party application.

So what did Abhinav Srivastava do? He wrote a custom back end, which used this vulnerability to roll out a android app. which allowed users to do self eKYC as shown below.

The Impact

So why did UIDAI panic and file the FIR? It is not the App. that Abhinav developed. It is the implications.

1. Almost all the service providers like Banks, Telephone companies and Mutual funds are mandated to verify or reverify their users via the eKYC process.
2. The eKYC process requires an Aadhaar number and an OTP/FingerPrint. When both these are provided, the eKYC API sends back a signed XML/PDF, which could be used as a non repudiable proof, that a genuine user has indeed provided his/her consent for availing the service (SIM Card, Bank account).
3. So an App which once installed on a user’s mobile phone and has “Read SMS” access, can silently perform multiple eKYC requests in the background, once it knows the user’s Aadhaar number, since it can also read the OTP automatically without the user being aware of it.
4. UIDAI will not be able to distinguish these requests as malicious as they are routed via the NIC back end through the Proxy API.
5. Since every successful eKYC request, sends back a signed XML/PDF, a malicious back end can harvest these XML/PDFs and sell it to the highest bidder in the black market.
6. The bidder using these harvested XML/PDFs can now connive with a corrupt telco agent or a bank employee to either issue SIM cards or open a bank account for money laundering on the victim’s name without them being aware of it.
7. This would make eKYC practically worthless.

Did Abhinav’s App did any of the above? It did not. The evidence so far indicates that all it did was offer self eKYC to interested users. And the App showed generic Ads in the screen, while users were typing their Aadhaar numbers or waiting for the OTP.

Hence UIDAI should let him go because he committed no crime, did not break into the CIDR and did not harvest signed XML/PDFs of those who used this App. But he did expose a giant hole in the entire KYC infrastructure, which UIDAI has completely missed.

Integrators are the weak link

The basic principle in the eKYC infrastructure is that not every entity is trustworthy to be given full access to CIDR. Thus KYC Service Agencies (KSA) are directly regulated, since they are closer to CIDR than other parts of the ecosystem and every KYC User Agency is vetted by UIDAI and the KSA.

However applications like the NIC eHospital were never considered as part of the ecosystem and hence were not audited by UIDAI’s auditors (PwC). The scope of the audit was only restricted to KSA and KUAs. This is a crucial mistake as the above example indicates since all it requires is one vulnerable application using the KYC API, which can allow a back door access to the eKYC and Authentication APIs.

There are now 254 such KUAs and there could be a large number of vulnerable applications like NIC eHospital, which were built on top of the eKYC service offered by these KUAs. Every one of these applications can potentially allow a back door to the authentication infrastructure, which significantly expands the risk of abuse.

For a normal user, an App. developed by UIDAI will be indistinguishable from the numerous “mygov” apps released by third parties as this example indicates and one malicious app is all that it takes for an actual data theft.

The example also clearly points out the complete and total lack of awareness of basic security practices even by the top-most e-Governance vendor. By digging deeper into the eHospital App, it is possible to understand how bad NIC’s security practices were.

The Disassembler

The disassembler is the standard tool used in the android eco system to analyse an App. for security vulnerabilities. Running the disassembler on the eHospital App, shows us the vulnerabilities in the back end.

Exhibit A: The App. uses an unencrypted HTTP channel, which allows anyone to snoop on the contents (Aadhaar number and the OTP and the signed PDF)

Exhibit B: The back end accepts a call to do eKYC from anyone, who knows the magic password, dG9rZW5Ad2ViQGFwcG9pbnQjbmlj. .

Exhibit C:
The back end “http://ors.gov.in” allowed anyone to obtain the complete list of APIs, through which one can surmise how it uses Aadhaar eKYC APIs.

Conclusion

UIDAI has shown time and again that it is not capable of handling security incidents without resorting to bullying tactics as is evident by their past behavior. The design problems of Aadhaar and the ecosystem security issues will not go away because of these tactics. Instead they will remain unreported or worse sold to the highest bidder and will be exploited by malicious actors and nation states.

It is time the organisation realises that it cannot make citizens secure by making them more vulnerable, in the mistaken false confidence that “Aadhaar is very very secure”. The security concerns have become real and the grudging acknowledgement by Nandan Nilekani was long overdue and perhaps too little and too late.

Nevertheless letting go Abhinav Srivastava for a crime he did not commit would be a good start to address the gaping design issues that led to this incident. The FIR must be expunged from his records with an apology and he should be hired as a security consultant for UIDAI, if he were not able to go back to Ola. After all, it is not the mirror’s fault, one’s face is ugly.

Postscript:

1. Multiple emails were sent to UIDAI CEO, CERT-IN and to NCI IPC reporting the full spectrum of issues with the NIC back end. Only after the critical ones were fixed, the name of the end point has been put out. (Email copies are available on request)
2. I personally thank Prasanna, Apar Gupta, Pranesh Prakash and Naavi for explaining me the legal aspects behind using the disassembler and why it could be construed as illegal under certain circumstances and how to avoid them (Using disassembler for vulnerability disclosures is usually acceptable).
3. CERT.IN and NCIIPC usually does not respond back, if the bug filed is indeed fixed, which makes public disclosure problematic, since the disclosure might be used by other malicious actors. This could result in a FIR on the person who filed the bug, under a variety of non-bailable sections.
4. May be we need the right to file a bug without being prosecuted first?