India’s Aadhaar implementation is the largest biometric system in the world, holding about 1.2 billion locals’ data. It’s operating in an era of increasingly large repositories of personal data held by both private companies and governments alike. It’s also an era where this sort of information is constantly leaked to unauthorised parties; last year Equifax lost control of 145.5 million records on US consumers (this started a series events which ultimately led to me testifying in front of Congress), South Africa had data on everyone living in the country (and a bunch of deceased folks as well) leaked by a sloppy real estate agent and data from Australia’s Medicare system was being sold to anyone able to come up with $30. Sooner or later, big repositories of data will be abused. Period.
Which brings us back to Aadhaar and some rather unpleasant headlines of late, particularly the likes of The World’s Largest Biometric ID System Keeps Getting Hacked. Here, Motherboard talks about personal data being sold for less than $10 a pop in a case that sounds eerily similar to the previously mentioned Medicare one. Both during this week and over previous years, there’s been various headlines calling the security posture of Aadhaar into question and the Indian government has been vehemently refuting any suggestion that the system isn’t top notch. But there’s been one claim more than any other that’s really caught my eye, and it’s this one:
— /dev/null 💡⌛️ (@agarwal_mohit) January 5, 2018
Now, I don’t want to enter the debate about whether Aadhaar should exist in the first place, that’s a much more nuanced discussion. Especially in a rapidly modernising country with over a billion people (a huge number of which still live in poverty), there are many reasons why much of what Aadhaar sets out to achieve does make sense. But claiming the service is “hack-proof”, that’s something I definitely have an issue with.
Claiming that the government has said this is something I wanted to verify before starting down this path because I appreciate that emotions are high on the issue and that there may have been some liberal interpretation of what’s been said. However, the Indian government’s view of Aadhaar’s security is made very clear in this piece on CNN from November:
The government has filed an affidavit before the Supreme Court in the Aadhaar case which claims that the data cannot be hacked or breached
The video within that story reiterates over and over again that “Aadhaar data cannot be breached”. It then goes on to quote the government as saying that:
it cannot be questioned by a handful of individuals
Of course it can! Many people are doing that just now, including myself regarding that “hack-proof” claim. It’s not the only such claim either; earlier last year in the wake of another security controversy, another similarly spectacular claim was made:
In public, UIDAI claimed Aadhaar was completely secure
UIDAI is the Unique IDentification Authority of India and they run the Aadhaar project. Their statement echoes comments made around this latest incident that espouse the complete security of the system:
The Aadhaar data, including biometric information, is fully safe and secure
Here’s the issue I (and many others) have with these statements and I want to make it crystal clear:
Security is not a boolean proposition. It’s not “secure” versus “insecure”, “safe” versus “unsafe”, rather it is a spectrum of controls that all contribute to an overall security posture. There is no “fully”, there is no “completely”; every system – every single one – has weak points and a sufficiently well-equipped and determined adversary will find them.
It’s the hubris of the UIDAI’s statements which is the most worrying and it neglects so many of the highly sophisticated precedents that have come before the current situation. Precedents like Stuxnet, created by the US and Israeli governments to damage the Iranian nuclear program by targeting air-gapped centrifuges via 4 previously unknown “zero-day” flaws. That’s almost a cliched example to pull out these days, the point is simply that where there is sufficient will and resources, any information system can be compromised.
But let’s get back to that original tweet and the question therein: “Can you prove otherwise?” I certainly wouldn’t want to be the person probing away at Aadhaar in an unauthorised fashion in order to prove otherwise (although make no mistake, many people are), but per the title of this post, there are many publicly observable things I can easily draw attention to. To be crystal clear, none of this is “hacking”, it will merely involve looking at how the system responds to legitimate requests and observing the gap between what it does at present and what it ideally should do. The intention is to highlight the point I made in bold a little earlier – that there is a spectrum of controls – and there are many things that Aadhaar could be doing better. And just to ensure this is broadly consumable, where possible I’m going to avoid getting too deep into the techie stuff and try to present this in a way that makes sense to most people.
Geo-Blocking is (Almost) Useless
A little context first: the Aadhaar website runs over at uidai.gov.in and it’s accessible all over the world. This is the jumping off point for many different UIDAI services:
Thing is though, most of those links don’t work particularly well:
I suspected it was due to my Australian IP address so I put the question out:
Indian friends, has the gov geo-blocked the Aadhaar transaction history tool? I think the URL is right but it seems inaccessible from other countries: https://t.co/1Jxh8Zosd3
— Troy Hunt (@troyhunt) January 9, 2018
The responses confirmed it was indeed a geo-block which was intended to keep non-Indians out of specific parts of the Aadhaar site. This is implemented by IP address which means 2 things:
- Many legitimate Indian residents would not be able to access the service if they were outside of India (i.e. travelling)
- Anyone can access the service from anywhere so long as they can get themselves an Indian IP address
Geo-blocking is a really weak, easily circumvented control that often does more harm than good. Blocking legitimate users is part of that problem, blocking users wanting to protect their traffic with a VPN is another:
This has been there for the past year now. They also blacklist vpn IP addresses. Security /= George blocking
— Vatsalya Goel (@vatsalyagoel) January 9, 2018
And as for that second points about anyone from anywhere accessing the site, a couple of minutes later I had a list of open Indian proxy servers and a couple of minutes after that I had the site successfully loaded (I’ll show all geo-blocked resources in Firefox):
None of this is news to people in the tech industry but it was worth laying out here because it’s part of the fabric of their security controls and it’s pretty much useless. It’ll stop indiscriminate crawling and basic non-targeted automatic attacks from outside the country, but it does nothing to stop anyone with an inkling of knowledge about what they’re doing.
Much of what I’m going to cover in the remainder of this blog post will focus on the site at uidai.gov.in rather than on the various subdomains. Before anyone objects with “yeah, but the important stuff is on those subdomains”, that root site is the entry point for those services. It’s the address on Aadhaar’s Twitter account, it’s the first result on a Google search and time and time again, it’s promoted as the site people should go to before doing anything else Aadhaar related. Just as in my post on NatWest last month, that entry point must be as secure as possible or else everything else behind there gets put at risk.
We are rapidly approaching a “secure by default” web and the green padlock is becoming the norm (about two thirds of all browser traffic is now encrypted). But as I’ve written before, there’s a lot more to HTTPS than simply redirecting all the traffic). For example, if someone was to type “uidai.gov.in” into the browser address bar and press enter, here’s what happens:
We’re seeing 3 things here:
- An insecure request is made over the http:// scheme because that’s what browsers default to
- The website responds with HTTP 301 “Moved Permanently” and instructs the browser to made a second request to the secure https:// scheme
- That second request is shown to the left of the screen after the first one
Websites should do this, but it’s not enough and there’s a very simple explanation why not: The UIDAI is using HTTPS because they recognise that someone may be able to intercept traffic between the browser and the server – that’s the whole point of having it in the first place! (We’d normally refer to this as a “Man in the Middle” or MitM attack.) By recognising this, they also must accept that the interception may occur on that first request – the insecure one – and that subsequently leaves a very real risk in their implementation.
The fix for this risk is HTTP Strict Transport Security or HSTS for short. We’ve had it for years and it works in every browser. When a site properly implements HSTS, the browser will not send any traffic to the domain in an insecure fashion. For example, here’s what happens if you attempt to load my own service Have I Been Pwned (HIBP) insecurely:
I’m going to call out 4 things this time:
- An attempt is made to request the site insecurely
- The browser responds with a 307 “Internal Redirect” which means the request is never sent over the network
- The browser recognises that a request must now be made over the secure https:// scheme due to the presence of HSTS
- A second request is made, this time securely
This is free to implement and is nothing more than a simple response header. HIBP also implements the includeSubdomains and preload keywords which ensures that HSTS is cascaded down to every subdomain of the site and is implemented in every browser when it ships from the manufacturer (more on both of those in my post on HSTS). By not using HSTS, the UIDAI has also made the next problem even worse:
(Footnote: I later discovered that under some circumstances the site will set an HSTS header. It appears highly erratic and even when present, doesn’t include the preload keyword which would ensure the connection is always secure, regardless of whether some responses omit the header or not. The most likely suggestion I’ve had for the root cause is that some machines within a server cluster aren’t configured to return it)
Insecure Links to Resources That Redirect to HTTPS
This is another one of those nuances to watch out for when implementing HTTPS. Here’s the problem:
Assuming you get the UIDAI site loaded securely, you should now remain on HTTPS for the remainder of your browsing experience. Any requests that drop back to HTTP pose the same MitM risk discussed earlier yet here we are with a link to http://appointments.uidai.gov.in/easearch.aspx which is obviously using the insecure http:// scheme. If you’re not in India, clicking on that link won’t get you much anyway because it’s also geo-blocked but as we’ve already established, that’s a pointless security control so here’s what happens when you do:
The “appointments” subdomain is requested insecurely after which it redirects to HTTPS just like the primary domain does. Curiously though, HSTS is then implemented in the response:
After receiving this header, anything on this subdomain must be requested securely for the next year (31,536,000 seconds is 1 year). Why HSTS is here and not (consistently) on the root domain is unclear and unfortunately, it means that someone browsing from uidai.gov.in to the enrolment centre is going to have traffic compromised before seeing the HSTS header if an MitM risk is indeed present. Even more strange is that despite implementing HSTS to force a secure connection to the appointments subdomain once you’ve been to the site, Aadhaar’s own Twitter account is linking to the insecure http:// scheme in their tweets (hover the mouse over the second link if you’re on a PC):
Always keep your mobile number updated in Aadhaar. Check the registered number from: https://t.co/bq4PUgIirL. To add/update new number, visit nearest Aadhaar Kendra (Locate: https://t.co/SADO8sC0tI)#AadhaarEssentials pic.twitter.com/dyOgCpLAGz
— Aadhaar (@UIDAI) January 8, 2018
The “Address Update Request (By Post)” link in the earlier screen cap also links to the insecure scheme on the same root domain which again, leaves the request open to interception and manipulation (plus it causes an additional request when the site responds with an HTTP 301). But they’re not the only screwy insecure references on the page either, there’s one more.
Other Insecure Content Embedded in the Page (and Commented out HTML)
This is an oddity within the source code of the UIDAI website which speaks to other issues as well:
The green text shows code to embed a YouTube video commented out, specifically one titled Know all about your Aadhaar Enrolment ID. Because it’s commented out the browser won’t attempt to render it, but if it did, we’d see a mixed content warning which would result in the loss of the padlock, the “Secure” text in Chrome and the green highlighting that would normally accompany it. The browser would now be serving “mixed content” which is a security anti-pattern.
When you see a production website with a bunch of the HTML commented out, what conclusions do you draw?
— Troy Hunt (@troyhunt) January 10, 2018
They don’t know how to use version control, which leads to other assumptions about their ability.
— Khas Mek (@KhasMek) January 10, 2018
Amateur and rushed; subsequently I find myself asking other questions..
— Fergus 🥃 (@FergusInLondon) January 10, 2018
“Ship now, consequences later” https://t.co/QN4PXXq663
— Mr. K Whestrivy (@mrkwhrvy) January 10, 2018
Students made it.
— Oleksii Udovychenko (@boades_net) January 10, 2018
Low $investment value seen from ownership
— ẅ̛̰̑̀͐̃̍͘ͅⓘⓝɔɥǝsʇer (@thebigpictoday) January 10, 2018
Don’t let the trainee deploy in prod.
— JuanJo G.R. (@jujogoru) January 10, 2018
— Michael Dowden (@mrdowden) January 10, 2018
I don’t want to go too far down that rabbit hole because it’s tangential to the security discussion, but it’s certainly a “code smell” not befitting of a service like Aadhaar. Let’s move on.
No Certificate Authority Authorisation (CAA)
Certificate Authority Authorisation (CAA) is a really neat control that ensures certificates can only be issued by white-listed certificate authorities (CAs). The significance of this is that as Scott Helme explains in that link, it significantly limits the ability for a CA to be exploited and incorrectly issue a cert for a site it shouldn’t.
I’ve implemented CAA on HIBP and it’s simply a matter of some DNS records and a check with a CAA validator:
Unfortunately, there are no such records for Aadhaar:
Now in fairness to Aadhaar, CAA is very new and the take-up is low; we cannot be critical of them for not having implemented it yet. However, it speaks to the point I’m trying to get across in this post that security is a spectrum of controls. CAA is one of those controls – it makes things more secure – and they don’t have it in place. It won’t make Aadhaar “hack-proof”, but it will strengthen their security posture.
SSL Labs, ROBOT and Symantec Certificates
A great resource for getting a quick snapshot of how a site implements their SSL / TLS / HTTPS (“encryption of traffic”, for the masses) is SSL Labs. This service simply looks at the ways in which a website is willing to communicate with a browser and spits out a nice report):
This is a good result, although the presence of the aforementioned missing HSTS would bring it up an A+. But there are two things worth pointing out they have to fix, albeit with a bit of time remaining.
The first issue listed here is a vulnerability to the ROBOT attack. Now they’ve still scored an “A” grade so let’s not over-hype the risk, but what tends to happen over time is that we gradually raise the security bar and we’ve seen many precedents of new vulnerabilities in encrypted communications which have caused us to reclassify what was previously deemed secure (POODLE, DROWN and BEAST to name but a few). If the UIDAI doesn’t move away from RSA encryption in the next few weeks, their grade will drop to an “F”. However, nothing suddenly gets worse or breaks, their score for those looking at SSL Labs simply drops.
The next issue, however, is different. The Aadhaar website is still using a Symantec certificate (actually, it’s a GeoTrust certificate which is a Symantec brand). Because their certificate was issued before June 2016 (it was issued on the 31st of March, 2016), Google will begin distrusting it in Chrome this March (although I note the present release date for v66 which will implement this is scheduled for April 17). What that means in real terms is that if the UIDAI doesn’t hop to it and replace that existing cert over the coming weeks, the site will cease to work for users on Chrome.
I want to reiterate that these are not immediate term causes for concern, but they are flagged in the SSL Labs report as things that need addressing very soon.
No Content Security Policy (CSP)
One of the first things I noticed was a total lack of content security policy (CSP). These are enormously useful for everything from blocking unauthorised external assets from being loaded into the page to prohibiting script tags from being injected to even fixing up content being insecurely embedded such as we saw with that commented out YouTube video. Those first couple of points are especially important as they’re key defences against cross site scripting attacks (XSS).
Like CAA, CSP is one of those things that still has very limited adoption, despite the value they provide. Much of this is simply due to lack of awareness; I must have taught 50 security workshops where the vast majority of attendees had simply never heard of CSP before. Also like CAA, this is not a vulnerability per se, but rather a reminder that the Aadhaar website still has some way to go in implementing modern security practices.
There’s a number of other oddities about the Aadhaar website not necessarily strictly related to security. For example, the footer of the page:
W3C compliance logos have always struck me as a throwback to the 90’s but for some objectivity, I asked the masses what these make them think of:
What do you think of when you see W3C logos on a web page in this day and age? pic.twitter.com/VVtGTHm8re
— Troy Hunt (@troyhunt) January 10, 2018
Which resulted in some pretty predictable responses:
— Oliver Brammer (@octobyte) January 10, 2018
— Ben (@transverberate) January 10, 2018
“Hasn’t been updated since 1998”
— Peter Ellis, Metastable Genius (@almostconverge) January 10, 2018
“This site hasn’t been updated in a while”
— Colin Scott (@AbstractCode) January 10, 2018
The site must be rife with security issues since the site is clearly living in the past.
— Karsten Huttelmaier (@kphutt) January 10, 2018
That last one is reflective of the queasy feeling many of us have when seeing relics of a bygone era on a modern service. Of course, it may also be totally unrelated to their actual security posture, but nobody sees W3C logos on a page and think “yeah, these guys are running a modern, progressive ship”. Plus, the UIDAI website has a heap of W3C validation errors on it anyway which makes the logos a bit pointless but then again, even the world’s biggest website has a heap of errors and so does the second biggest and so does the third biggest so take the whole thing with a grain of salt. All of this merely emphasises the point that the relevance of those logos on the page is frankly, completely pointless.
The earlier tweets about the page not having been updated for some time are also telling, and those comments were made about an image that didn’t include a copyright date from 2 years ago! That same date is on the (geo-blocked) “check Aadhaar status” page:
They’ve incorrectly encoded the © logo here, but you get the idea. However, that’s nothing compared to the enrolment centre search page (also geo-blocked):
Which, coincidentally, immediately made me think of Scott Hanselman’s tweet from last week because a copyright even a couple of days out of date starts to make things feel old:
Copyright @DateTime.Now.Year y’all
— Scott Hanselman (@shanselman) January 2, 2018
W3C logos (despite failing compliance), copyright dates and incorrect encoding are certainly not security shortcomings but again, they do imply things about how much attention has been paid to the details and when you’re dealing with a 10-figure number of citizens’ data, details are important.
I ended up moving this section after the miscellaneous one simply because of this:
We’ve seen a 2016 copyright, a 2010 copyright and now a 2013 copyright published on a 2014 page! Again, see comments above re why this is odd.
But getting onto the title of this section, the page in question is the E-Aadhaar authentication page (also geo-blocked). It looks like this:
The problem here is obvious as soon as you try to paste anything into the form – it’s blocked. This is poor form as it can break tools that encourage good security practices such as password managers. In fact, the UK government’s National Cyber Security Centre (NCSC) drew attention to this poor security practice once again only a few days ago:
One of the things people often tweet to us are examples of websites which prevent you pasting in a password. Why do websites do this? Let them paste passwords! https://t.co/llQuha05Ch
— NCSC UK (@ncsc) January 8, 2018
It’s considered such poor practice that a dedicated Chrome extension called Don’t Fuck With Paste was created specifically to neuter this security anti-pattern.
So once again, we’re at a point where whilst this is not an outright vulnerability like say, SQL injection, it’s another chink in the armour of the overall security posture.
Many people may be surprised by my earlier comment about not being totally against the concept of Aadhaar, especially in light of Ed Snowden chiming in the other day. But just as the entire premise of this post was that infosec is a spectrum of controls, so too are the reasons that Aadhaar exists; some of them are very good reasons, others, probably not so much…
But unequivocally and without caveats, no matter how good of an idea Aadhaar is or is not, claims that it’s “hack-proof” are absurd. What worries me most in all of this is the representation by people in positions of authority to the masses – most of whom will understand very little about infosec – that complete, blind confidence is warranted. When this is coupled with police action against a journalist reporting on abuses of the system, that’s an extremely worrying precedent that immediately made me think of the Streisand effect followed quickly by this:
So here’s my 3-part advice to the UIDAI:
Firstly, address all the technical points above because most of them are quick wins and they will make Aadhaar more secure. Not “completely secure”, not “fully safe” and certainly not “hack-proof”, but they move the needle in the right direction. And just so this post doesn’t lead to news headlines along the lines of “Aussie security researcher says Aadhaar is insecure”, no, that’s not what I’m saying. Frankly, everything I’ve observed above is pretty normal, but I also suggest that the world’s largest repository of biometric data should be held to a higher standard than “pretty normal”.
Secondly, acknowledge the simple, immutable fact that you will never have any of those things in absolute terms, rather that just like every other organisation building information systems you are on a journey that requires continual self-improvement. Just yesterday, the UIDAI introduced a new privacy control in the wake of recent criticisms so perhaps that’s a positive sign that they’ve acknowledged there’s room for improvement. The mindset that everything is perfect already will limit the ability to improve.
And finally, recognise that it’s an important issue for the people of India. This is their data and they’re entrusting the government with it. Their voices are important and whether it’s individuals raising concerns or journalist reporting on issues, they deserve to be heard, acknowledged and respected. I had a lot of people contact me both publicly and privately whilst I was writing this piece and there was an alarming level of concern that anyone raising issues with Aadhaar would be targeted by law enforcement. Whether that’s the case or not, people are fearful because of situations like with the journalist mentioned above. That’s not cool.
Aadhaar is complex and it will have flaws just like any other complex software product does. Some of them may be quite serious and they must be treated as such. That will require an open and receptive attitude from the government and above all, acknowledgment that Aadhaar is not “hack-proof”.