Recently, a 31-year-old MSc graduate from IIT-Kharagpur, Abhinav Srivastav, was arrested for allegedly stealing Aadhar data. If an analogy were to be drawn between the story in the first paragraph and this incident in which various sections of main stream media are claiming that Srivastav ‘hacked’ Aadhar data, then Srivastav would be the Person B in the story.

Through the course of this article, we’ll show that Person A in this story is the team at National Informatics Center (NIC) who designed and developed the eHospital hospital management software. NIC is the prime builder of e-Government / e-Governance applications for Government of India. This story will show how NIC released a horribly designed application which published a secret token in a non-secure manner. Abhinav Srivastav got hold of this secret token and gained unauthorised access to Aadhar data.

What is Abhinav Srivastav accused of ?



As reported by Indian Express, Srivastava had accessed UIDAI (Aadhaar) data without authorisation between January 1 and July 26 for an app called ‘eKYC Verification’. The app delivered demographic data like name, address, phone number of individuals from the central identities data depository of Aadhaar to authenticate unique identity numbers. It was placed on Google Play Store with the claim that it was developed by an entity called myGov linked to the start-up Qarth Technologies, which had been acquired by the taxi hailing service Ola in 2016. Further, Times of India reported the police version which stated that Srivastav accessed Aadhaar data through the e-hospital application hosted by the government’s National Informatics Centre (NIC). Quint reported a follow up statement by Bengaluru Police which stated that Srivastav had exploited weak security protocols of the e-hospital system, a government server, for easy access of Aadhaar data.

To understand how Abhinav Srivastav exploited the eHospital system, it is necessary to have a basic understanding of eHospital, Aadhaar/UIDAI and the eKYC service offered by UIDAI.

What is eHospital?


According to the eHospital website, it is a Hospital Management System designed and developed by NIC for Government sector hospitals across India. It is a generic software which covers major functional areas like patient care, laboratory services, work flow based document information exchange, human resource and medical records management of a Hospital.

One of the features provided by eHospital is Online Registration System (ORS) which utilizes Aadhaar to provide an online appointment system across various Government hospitals. As part of the eHospital suite, an Android application has been developed which enables access to the Online Registration System (ORS). ORS is hosted by NIC and uses the Aadhaar number to get eKYC data of a customer for authorisation in order to create online appointments.
eHospital Online Registration

What is eKYC?

eKYC is a service provided by UIDAI which enables a resident having an Aadhaar number to share their basic demographic information such as name, age, date of birth, post address, phone number and a digitally signed photograph with a UIDAI partner organization after user consent either through biometric authentication or OTP (One Time Password). eKYC service by UIDAI thus provides an online verification service for Proof of Identity (PoI) and Proof of Address (PoA). KYC in eKYC stands for ‘Know Your Customer’.

Who can get access to eKYC service by UIDAI?



UIDAI has 254 partner organisations who can access the eKYC service by UIDAI. National Informatics Center (NIC), who built the eHospital service and Android application, is one of the partner organisations. In the UIDAI world, these partner organisations are called KUA or KYC User Agencies. Each KUA is given a unique license key using which it can access UIDAI’s eKYC service.
Can UIDAI’s eKYC service be accessed over a regular Internet connection?
No. The eKYC service can only be accessed over secure leased lines which provide connectivity to UIDAI’s data store also known as Central Identities Data Repository (CIDR). At the time of writing, 27 partner organisations have secured leased line connectivity with the CIDR (Aadhaar data). These partner organisations are called ASA or Authentication Service Agency. Those ASAs who are eligible to provide access to the eKYC service are called KSA or KYC Service Agency. NIC or National Informatics Center is also a registered KSA.
Definitions Aadhaar
Screen Shot 2017-08-09 at 10.53.30 PM.png

How did Abhinav Srivastav exploit the eHospital application to gain access to Aadhaar data?

If the eKYC service provided by UIDAI can only be accessed over a secure leased line with only 27 partner organisations having access to the Aadhaar data, how did Abhinav Srivastav manage to get access to it?
The leak was not at the KSA level but at the KUA level. In this particular case, NIC or National Informatics Centre is both a registered KSA as well as KUA. What this entails is that NIC has secured leased line access to CIDR (Aadhar Data) and is also eligible to access the e-KYC service by UIDAI. For the eHospital application and more specifically the Online Registration System, NIC built an additional service on top of the existing eKYC service already provided by UIDAI. In the software engineering world, such a service is also called an API or Application Programming Interface.
This additional API, which piggybacked on existing UIDAI eKYC service, was utilised by the Android eHospital Online Registration application to create online appointments while using the patient’s Aadhaar number for eKYC verfication. This additional API which gave proxy access to UIDAI’s eKYC service and was created by NIC and was exploited by Abhinav Srivastav to gain access to Aadhar Data. For the purpose of this story, we will call this additional API the ‘NIC eKYC API Proxy‘.
Screen Shot 2017-08-06 at 9.16.33 PM.png

How did Abhinav Srivastav exploit the NIC eKYC API proxy?

While UIDAI’s eKYC service is only accessible over a secured leased line connection and not a regular internet connection, NIC eKYC API proxy is accessible over a regular internet connection and anybody in the world can access the API provided they have the authentication details. NIC had to create this API since the eHospital Android application would create eKYC assisted appointments over a regular internet connection.
Unfortunately, the NIC eKYC API Proxy had major security holes.
  1. The API was protected by a single default password/credential –dG9rZW5Ad2ViQGFwcG9pbnQjbmlj
  2. The API was hosted on HTTP (and not HTTPS) (http://ors.gov.in/ORSServicecontainer/services) and hence communication to the back end was not encrypted.
  3. This allowed anyone who could figure out the default password to be able to call the NIC eKYC Proxy APIs and thus be able to do Aadhaar eKYC verficiation.
  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.

How did Abhinav Srivastav find out the default password for the NIC eKYC API proxy

The eHospital Android application was communicating with the eHospital backend via NIC eKYC API proxy. However, as pointed out earlier, this communication was over an insecure HTTP connection instead of a secure HTTPS connection. Anybody who knows how to sniff this HTTP communication would be able to find the password. While it is not possible to determine the exact software application used by Abhinav Srivastav to determine the default password, here are the two methods using which one could have found the default password.
  1. Proxying the phone traffic: One can use a software like the Charles Web Debugging Proxy to view the communication between the Android Phone and the eHospital/ORS backend. Essentially, one needs to setup Charles on their own computer and set it up as a proxy server. Thereafter, change Android’s proxy settings and setup your own computer’s IP Address as the proxy server in Android. Once this is done, all the unencrypted traffic that goes on between the Android Phone and the Internet can be captured using Charles. A detailed tutorial can be found here. Thus by running the eHospital application on the Android phone and proxying all the Android traffic through a software like Charles proxy, it is possible to find the default password.
  2. Disassembling the Android application: Android applications are written in a programming language called JAVA. The JAVA code is compiled into a code (bytecode) which is interpreted and executed by a software interpreter called Dalvik. It is possible to ‘decompile’ an Android application to extract an equivalent of the original JAVA source, a detailed tutorial of which can be found here.
    Anand Venkatanarayan and Anivar Aravind who did the background research for this entire story decompiled the eHospital Android application and found out that the password ‘dG9rZW5Ad2ViQGFwcG9pbnQjbmlj’ is visible as plain text in the decompiled JAVA code. Based on their research of the decompiled code, here are their three findings:
    • 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 XML)
      Screen Shot 2017-08-06 at 9.38.46 PM.png
    • 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.
      Screen Shot 2017-08-10 at 1.08.13 AM.png

    3. How did Abhinav Srivastav use this vulnerability in the eHospital app to create his own Android application?

    By either sniffing the HTTP traffic using a proxy or decompiling the Android application, Abhinav Srivastav must have figured out the default password and the API required to do Aadhaar eKYC. He used this knowledge to create his own service on top of the NIC eKYC API proxy. This service was accessed by the ‘eKYC verfication’ app that he created. For the purpose of this story, the Android application created by Abhinav Srivastav will be called the ‘Qarth App’ and the service that utilised the compromised password to communicate with the NIC eKYC API proxy will be called the ‘Qarth App Back End’.
    Screen Shot 2017-08-06 at 9.25.36 PM.png

    If Person B is culpable, why isn’t Person A culpable too?

    We started this article with a small story where Person A jots down username/password of your email account on a piece of paper and Person B manages to find that piece of paper and misuses the information. In this story, Person A is the team at National Informatics Center who designed and developed the insecure eHospital service and application which uses a single default password ‘dG9rZW5Ad2ViQGFwcG9pbnQjbmlj’. Person B is Abhinav Srivastav who found out this default password and misused it to create the ‘eKYC verification’ application. If Abhinav Srivastav is culpable of misusing the vulnerability in eHospital app, isn’t the team at NIC also equally responsible for creating a service with a Jupiter-sized security hole?

    What are the implications?

    So why did UIDAI panic and file the FIR? It is not the Application 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 signed XML, 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. An App which once installed on a user’s mobile phone that has “Read SMS” permission, 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 signed XML, a malicious back end can harvest these PDFs and sell it to the highest bidder in the black market.
    6. The bidder using these harvested 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.

    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 (Aadhaar data). Thus KYC Service Agencies (KSA) are directly regulated by UIDAI since they are closer to CIDR than other parts of the ecosystem. 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. The scope of the audit was only restricted to KSA and KUAs. This is a crucial mistake as the above example indicates that all it requires is one vulnerable application using the eKYC 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 Application developed by UIDAI will be indistinguishable from the numerous 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.

    Conclusion

    UIDAI has shown time and again that it is incapable 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.
    If you like our stories, do follow Alt News on Facebook.
    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.

    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. Many thanks to Prasanna, Apar Gupta, Pranesh Prakash and Naavi for explaining 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?
    The background research for this article was done by Anand Venkatanarayan andAnivar Aravind. This article has been jointly written by Anand Venkatanarayan andPratik Sinha.