TL;DR

The mAadhaar app is shoddily coded and puts the Aadhaar data of people who install it on their phone at risk. It stores the data locally on the phone, is easy to breach, and can be reverse engineered by malicious hackers to steal secure data. Also losing your phone or a malicious hacker temporarily having access to it could result in identity theft.

======================================

A French security researcher, Elliot Alderson who uses the handle @fs0c131y on Twitter has made a series of tweets regarding the mAadhaar app that describe poor coding practices. It began with these tweets and resulted in a lengthy “schooling” of UIDAI and Khosla Labs on secure coding practices interspersed with (well deserved) sharp taunts.

To make a long story short, the mAadhaar app is coded in a fairly shoddy manner that puts user data at risk. The app stores the user’s data in a local database (on the phone) that lets anyone with some coding experience easily get the password used. As a proof of concept, he released sample code on Github that shows how this method results in the same, predictable password every time the app is started.

He goes on to describe the code of the app further with the unnecessary inclusion of the developer endpoint data in the published app, which reveals the details of the testing server used in the development of the app and is not relevant to the functioning of the published app.

Followed by the demonstration that people handling the data of a country the size of India don’t understand basic things like password salt.

A password salt is a string used to add randomness and protect against dictionary attacks and such. Randomness is important here, which is why you NEVER use predictable words and phrases. You use random strings. Like so ‘_Ezm<39>etgf<D{S mV-yhu2#|m#K{`jq!MdeeZEf6g:-YuBW!TZ;*W?wT!y5HOs’. See here for example, the random salts generator offered by wordpress for those who don’t understand how to create a random string (many new people don’t, so there is a generator provided to protect them from the mistake of predictableness.) Every time you load that page, you’ll have a different set of random strings. Determined hackers can even hack computer generated randomness, so those really paranoid about encryption attempt to bring in further unpredictableness to the generation – for example Cloudflare’s Lava Lamp wall (also read for an easy to understand explanation of randomness in cryptography). For an app dealing with Aadhaar data to use a variant of “Betty Botter had some bitter butter”….. does not need comment.

He went on to show that Khosla Labs had left the application files for the aadhaar bridge SDK in an open git repository (which has since been removed), showed that the mAadhaar app stored the authenticated data of the Aadhaar holder in cleartext (readable like you can read this post) in an application log file on the SD Card and showed that he was able to access the mAadhaar application folder on the SD card. In other words, losing your phone (or even someone temporarily accessing – your local mobile shop, when you send it for repairs?) could mean losing your Aadhaar altogether, because a person who knows enough about tech could easily get your Aadhaar details and use your phone itself to authenticate changes to your Aadhaar to take control of it.

He then went on to show how the mAadhaar app had been designed to not work on rooted phones, but how that could easily be bypassed, because while five methods were implemented to check if a phone were rooted, only three were actually used – he speculates that that may be because the developers using an emulator to test the app kept the workaround. He explained how a simple unpacking of the app and repacking after changing a single flag from V1 to V0 could bypass the check for a rooted phone altogether because of a security method to prevent this (checking for a changed certificate – as a result of repacking) not being used in spite of being available.

Even more amusing was that he found that the certificate for signing the app was in the name of Google (as a result of using sample code without edits?), implying that the app was owned by Google.

While this is not so much of a security risk, it is indeed hilarious and highlights the carelessness of coding that such an important app is using copy-pasted sample code for something as critical as a certificate, without applying even as little mind as to edit the name of the owner of the application. What is even more funny is that unlike the hasty removing of the git repository, this can’t be fixed as easily, because every app in the playstore must have the same certificate used all through. So simply updating the app to hide this embarrassment won’t work – to change the certificate, they will have to remove the mAadhaar app and republish it as a new app.

He went on to show that there is a debug feature in the published app, that can be enabled by a malicious attacker by unpacking and repacking the app (remember how the developers haven’t actually used the check for a changed certificate?) With the debugging enabled, the app writes all the debug data to the SD Card in cleartext as well, after which it is a simple matter for the attacker to upload it to a remote server.

In reply to a comment, he said that it could be possible to hack the app further to retrieve data of other users.

He showed that there already was a malware version of the app in an alternative Android app repository.

All in all, within a matter of a day, the mAadhaar app stood stripped as insecure and a potential attack vector.

And this is just the mAadhaar app. A cute way of carrying your Aadhaar card on your phone. Not an Aadhaar pay app. Yet.

Trivia: Elliot Alderson is a character in the American TV series Mr. Robot – a cybersecurity engineer and hacker.


Vidyut

Vidyut is a commentator on socio-political issues with a keen understanding of tech and policy. She has been observing and commenting on Aadhaar since 2010 from a perspective of human rights, democracy and technological robustness.

Leave a Reply

Your email address will not be published. Required fields are marked *