IDOR at Election Commission Website

Hello folks,

Back with another blog, and a trendy one this time!

P.S: This blog is for educational purposes only and is an attempt to help the cybersecurity community.

I needed to get some changes done to my voter ID and had a few changes to be made to my parent’s cards as well before the season. Naturally, I had both of their credentials with me, along with mine. So what do you do as a pentester? Test IDOR testcases? No?

Well, I didn’t think about it until I got yet another sign. I logged into my dad’s account and I suddenly observed someone else’s details listed on his session and they seemed to be from a completely different state. What’s next? I fire up my proxy and start digging into the APIs making use of the set of credentials I had at the back of my pocket!

I started scrambling for APIs that showed critical information in their response and I observed that the application was vulnerable to IDOR at the /api/v1/e-epic/get-epic-detail endpoint where the vulnerability lay in the stateCd and epicRefNo parameters which were being sent in the body of the request. Since there was no rate limiting, user A could brute force details of other users using their own JWT token.

The details like epic number, application reference number, relative name, user name, place of constituency, etc for multiple users could be found.

I observed that the problem lay in the EpicRefNo as it was a predictable parameter. So what else could I get? I decided to brute force the last three digits of the epicRefNo and perform a Clusterbomb attack through intruder because I also had to consider the stateCd PnC, as someone with a different number could be from a different stateCd.

And to my expectation, I got the details of these many users on a short-range brute force.

Now that I had epic numbers, I could use them on the /api/v1/elastic/search-by-epic-from-national-display endpoint to fetch voting details of the user associated with the entered EPIC number and find out details like their polling booth, voting date, name, age, father’s name, constituency, gender, epicID, partserialnumber etc.

Overall problems associated with this:

• No rate limiting helps with brute force
• unpredictable parameters in the body of the request specifically used for generating a customized response can lead to guesswork and help brute-force
• The authorization token not being tied to body parameters which are in turn used to fetch resources from the backend.
• Single authorization token being relied upon to verify the identity of the user.

Then what? I reported it to the NCIIPC and received an ack.

Do follow me on YouTube for more cybersecurity-related content: https://www.youtube.com/channel/UC8yOCh7nJ-sFdEsWDXTSTJw