The prevalent use of CID's and possible vulnerabilities
How CIDs are used for verification in most government portals and how this could lead to weak security measures.
CID & Bhutan is almost synonymous. No matter what you do, where you go, if you ever wanna do something of substance in Bhutan, CID is a prerequisite. It is absurd how many extra steps you must take if you don't have a CID. But I won't delve any deeper into that. This post is about how accessible our CID numbers are to everyone and how often we use them for verification. How we provide our CID numbers without hesitation. And how malicious actors might be able to steal a lot of sensitive information.
The use of CID as a unique identifier(primary key) in government portals makes sense. Most citizens are provided one, it is unique to every citizen and for the citizen it means they only have to remember one unique key, great user experience. But I do believe there is more room for improvement. An interesting idea would be to centrally aggregate citizen data and manage access rights for each government organization(like how G2C does it now but a more standardized version).
Although it’d be interesting to see, there prolly are challenges associated with it and reasons why it has not been done already. Also as a junior dev, I have no idea if it’d be scalable, secure and all the other tech words.
But what I do know is the current state of affairs. All organizations/businesses take your CID, personal information and save it on their own database. And at one point in time they might make a public facing API where the verification is usually your CID and your birthday. It would be fine if we treated our CID numbers as secret IDs but we don’t. Every time there is an announcement for kidney donation, missing person or wanted person, BBS always displays it with their photo and CID. CID numbers are also often found next to scholarship announcement results, Facebook groups and shareholder pdfs loool.
The vulnerabilities listed below result from a combination of the factors I mentioned above and from our current limited level of technological capability. It appears to me that Bhutan's knowledge economy is finally beginning to feel the effects of the previous years of stagnation. But this is another topic I would like to delve in another post.
In recent years we’ve had a boom in the number of software solutions. From MBOB to CPMS, they’ve helped turn our society cashless and also massively aided in containing COVID. There are numerous public facing software, and this necessitates many public facing APIs.
But some of these public APIs provide a lot of information on someone given their CID card. For example the CPMS API: https://cpms.rbp.gov.bt/api/getcitizendetails/:cid would give information on your House number, Parents name, Birthday etc. I’m unable to access the API anymore.
Since our CID numbers are sequential, you might raise your CID number by 1 to obtain the information for the following person. I first came across this API when registering my dad on CPMS. A significant portion of the data returned above was never used by the front end; all that was presented were the CID, Name, and Phone Number. Although the information is harmless in the isolated context of CPMS but as we see below, it could be used to create a domino effect of security lapses.
To highlight how public/accessible our CIDs are: there is a pdf of a firm's shareholders online (I won't say which company it is) which has roughly 1500 CIDs and who they belong to.
And recently while I was going through RSEBLs website I stumbled upon their feature to get an online share statement. As I looked at the network tab I discovered this API: https://rsebl.org.bt/agm/api/checkshareExist?cidNo=CID_HERE&phoneNo=&email=&otpNo=&accType=I returning not just whether or not I own shares, but also which shares and the number of shares I own. I switched the CID from my own to one from the shareholders pdf, and voila, I now know which shares and how much they own. Credit to RSEBL for fixing it quickly after I informed them.
Another example is this API from the G2C services. https://www.citizenservices.gov.bt/census/getFamilyTree In the payload of the request I can switch my CID to someone elses’ and get their Household Number, immediate family members details and much more. Below is a picture of the family tree of random CID I found online
You can start to see how if someone connected all the dots and the APIs a lot of sensitive information could be easily accessible. A prime case of this is with tax returns. Due to our limited technological capacity, the majority of these systems have very shoddy or careless security implementation. If you know someone's CID and DOB, you can use the RAMIS system's TPN search to check for their TPN number. Below is a picture illustrating this: note this is not my TPN.
Now you cant do much with this TPN but RAMIS also has another feature to return your TDS report. http://ramis.drc.gov.bt/report/renderReport.html?report__________TDS&tpn=________&________=2021_______torTPN= I’ve removed some of the API route since this vulnerability is still exposed.
But if you hit this API and replace the tpn= with the TPN from the search feature, you get their TDS report for the given year. Below is a redacted pdf of the tax returns of the above person.
With just this small subset of APIs, you can see how intricately tied the system is to our CIDs. And how a lapse in security from one of these public facing APIs can trigger a domino effect for all of these other APIs.
This blog post includes only the vulnerabilities I know about and I wasn’t even intentional about finding them. Added to that I am not even an expert in this field nor am I the brightest person. And its hard to imagine what someone with ingenuity, experience and a goal could extract from these systems.
CID has been viewed as a shareable key in our culture. But right now, we're developing an ecosystem that leverages CID for verification. Given that we are creating more software on shaky underpinnings, this is somewhat alarming.
All of those data leak could be prevented if their backend implemented just one line of code for authorization. Most Bhutanese apps miss the basic concepts of data protection.