How I managed to gain access to The Indian Digital treasure – 3 Billion documents on Digilocker

During the beginning of May 2020, there was a large commotion about the arogyasetu app and its security after a so called “hack” by infamous political hacker named Elliot Alderson. In light of all this, we at the YAS (Yet Another Security) community, had some talks in our WhatsApp group. So, it turned out to be a discussion on techniques used for bypassing SSL pinning on the mobile apps. This whole discussion made be curious about other apps from India government and since I have worked on similar projects outside of India, digilocker caught my attention.

Hence, I downloaded the app and installed on my test devices and fired up my favorite toolset burpsuite + Frida. I used my homebrewed pinning bypass scripts to actively intercept the app’s communication with the backend. To my surprise, I found that digilocker was not matching with the basic security features of arogyasetu, such as custom root detection, custom ssl pinning checks all wrapped inside obfuscated binary.

That made it interesting, I decided to dig in, as I was not current user of the platform it asked me to signup first and setup a pin to access the system. The immediate thing that caught my eye on the request to set pin was it was a normal http request with no session, in layman’s terms, the platform allows an anonymous user to set pin for any active user of the platform. Shocking!!!

To give more technical context, internally the system denotes each user with a unique v5 UUID (v5 denotes it has enough entropy and that there is less chance of duplication and has enough randomness to it), so to set a new pin for the user all you need is to call the endpoint with uuid and new pin value.

All of this made me think about how to bypass sms otp of a user, because pin is asked after the OTP. So by looking at how the communication progresses between mobile app and backend server I came to conclusion that the steps of verifying sms otp and submitting pin are not linked together. Meaning you can do the sms otp as one user and submit pin of second user and finally you will end up logging in as second user. Bingo!!!

I figured all this by looking at the mobile app of digilocker, wait a minute there is a web portal for digilocker. I started to look at the web portal of digilocker, this then gave me more internal knowledge on the mobile app. Here are some observations that I sent to CERT-IN and digilocker teams.

Timelines

May 10th – I reported this to CERT-IN
May 14th – CERT-IN finally acknowledged the issue
May 28th – CERT-IN confirmed the issues are fixed
June 3rd – I saw another blog with similar findings and decided to write one of my own.

Credits

Dedicated to all 215 members who are my hardcore brothers & sisters from YAS community. Thanks for all your support and inspiration to do this.

Detailed observations

Below is a summary of the findings that i found, I just gave risk rating based on industry standards for each.

1) OTP bypass due to lack of authorization – Critical

The OTP function lacks authorization which makes it possible to perform OTP validation with submitting any valid users details and then manipulation flow to sign in as totally different user. Let’s assume attacker creates/gets hold of a valid dummy account.

Attack path

Use any valid account attacker has access to and complete otp
Proceed with pin submission to totally different victim account
Logs into victim account

Below is attack steps

Attacker uses a valid user account that he has access and starts the login process by submitting phone number.
- The submission of otp via both mobile and web app is on url https://accounts.digitallocker.gov.in/signin/verify_otp
Attacker completes the OTP validation with account (mobile number) he possesses.
Attacker proceeds to submit the secret pin
- Mobile calls two urls for this – POST request
  - https://accounts.digitallocker.gov.in/signin/login
  - https://accounts.digitallocker.gov.in/signin/mobile_view
- Web application calls two urls – POST request
  - https://accounts.digitallocker.gov.in/signin/login
  - https://accounts.digitallocker.gov.in/signin/oauth
- All the above calls posts a base64 combination of user_uuid:secret_pin (similar to basic auth) on the parameter loginTxn
- Attacker modifies these calls to call any users uuid and secret pin combo before it is submitted
- Attacker logs in as victim now, hence the victims otp protection is bypassed

Sample screen shot of login call, similar calls can be observed to all above mentioned urls.

2) Secret PIN Bypass/takeover – Critical

The pin setting API/URL lacks any authorization and can be used to reset pin of any user without authentication.

Attack path

Attacker finds the uuid of a user or randomly picks one
Attacker sets the pin via the url
Attacker uses vulnerability #1 mentioned above to gain access to the account

Below is attack steps

Attacker submits the uuid of the user and new pin to the url https://accounts.digitallocker.gov.in/signup/set_pin
Pin gets updated

Sample screenshot of the call. Notice there is no session related information on the POST request so its not bound to any user

3) Poor session mechanism in APIs – High

It was observed that the API calls from mobile were using basic authentication to fetch data or do transactions. All calls from mobile has a header flag is_encrypted: 1 which denotes that the user has to submit the credentials (user_uuid:secret_pin) in basic auth format encrypted with Algorithm: AES/CBC/PKCS5Padding with key We4c4HYS5eagYdshfEP2KY27KwkjaZNH

However it was found that the same api can be accessed with removing the is_encrypted: 1 flag and then submitting the credentials in basic auth format (user_uuid:secret_pin)

Attack path