IDOR + Account Takeover: How I Secured Personal Information (PII) of 5.17M Electricity Consumers
This blog discusses the discovery of 2 critical vulnerabilities at APDCL, exposing personal data of 5.17M electricity consumers.
Hello, my name is Biraj Baishya, aka brutexploiter. I am an independent security researcher, a full-time bug bounty hunter, and a mechanical engineer.
In this write-up, I will discuss how I discovered two critical vulnerabilities and protected the data of approximately 5.17 million electricity consumers that could have been exploited by cyber attackers, potentially leading to a massive data breach.
Let’s begin… but first, let’s learn some basic terms:
Access Control:
Access control is the application of constraints on who or what is authorized to perform actions or access resources. In the context of web applications, access control is dependent on authentication and session management:
- Authentication confirms that the user is who they say they are.
- Session management identifies which subsequent HTTP requests are being made by that same user.
- Access control determines whether the user is allowed to carry out the action that they are attempting to perform.
Insecure direct object references (IDOR):
Insecure Direct Object References (IDOR) occur when an application provides direct access to objects based on user-supplied input. Insecure Direct Object References allow attackers to bypass authorization and access resources directly by modifying the value of a parameter used to directly point to an object. This is caused by the fact that the application takes user supplied input and uses it to retrieve an object without performing sufficient authorization checks.
Discovery Phase:
1. IDOR on Unauthenticated API Endpoint leads to PII Exposure
I visited the APDCL website to pay my electricity bill. I had registered before, so I directly went to the login panel. When I visited the login panel, I saw there was an option to enter my mobile number. The login flow is as follows: you enter your mobile number, the server sends an OTP to your mobile number, and by using this OTP, you are able to log in to the website.
Next, I went through all the traffic captured by my proxy tool, Burp Suite.
I came across several endpoints, but the ones that caught my attention were as follows: one endpoint, /website/myBijulee/fetchConsumer, is fetching electricity consumer numbers via the mobile_no query parameter using the consumer’s mobile number.
This endpoint is not authenticated; therefore, anyone can simply input any mobile number. If the records exist, the server will return the consumer numbers of the customers.
Request 1:
POST /website/myBijulee/fetchConsumer?mobile_no=<mobile_number> HTTP/1.1
Host: www.apdcl.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/116.0
Referer: https://www.apdcl.org/website/
Origin: https://www.apdcl.org
Content-Length: 0
Te: trailers
Connection: close
The next endpoint that I found changed everything. This endpoint, /cbs/RestAPI/myBijulee/ConsDetails, fetches consumer details via the cons_no query parameter. I remember that I already found an endpoint that fetches consumer numbers by mobile number.
Request 2:
POST /cbs/RestAPI/myBijulee/ConsDetails?cons_no=<consumer_number> HTTP/1.1
Host: www.apdclrms.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/116.0
Referer: https://www.apdcl.org/
Origin: https://www.apdcl.org
Connection: close
Therefore, we can retrieve anyone’s personal details if we know their mobile number or directly brute-force the cons_no query parameter, as the consumer number input is numeric.
A very simple vulnerability with critical impact. Any attacker, without any privileges, can obtain all consumer data by exploiting unauthenticated API endpoints, potentially leading to a massive data breach.
2. 0-Click Account Takeover via Response Manipulation
When I manually audited the login flow, I found a very strange behavior with the web application logic flow. The first request is used to send an OTP to the consumer’s mobile number, which is good so far.
Request 3:
POST /website/api/generateOtp?mobNo=<mobile_number> HTTP/1.1
Host: www.apdcl.org
Cookie: ARMSSESSIONID=M2Y5MzY5YTItODFiOS00ZmQyLWIzMTAtOTNkMTdhOGNjZjlm; JSESSIONID=5F5BB3B3B8711282CD8BA7D5F2118886.server2
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/116.0
Referer: https://www.apdcl.org/website/
Origin: https://www.apdcl.org
Content-Length: 0
Connection: close
The second request is used to verify the OTP. If the OTP is correct, the server responds with a 302 and redirects to Location: /website/ConsumerDashboard with the session cookie, and the user is logged in.
If the OTP is wrong, the server responds with a 302 and redirects the user to Location: /website/?mobileNo=<mobile_number>
Request 4:
POST /website/api/postOtp HTTP/1.1
Host: www.apdcl.org
Cookie: ARMSSESSIONID=M2Y5MzY5YTItODFiOS00ZmQyLWIzMTAtOTNkMTdhOGNjZjlm; JSESSIONID=5F5BB3B3B8711282CD8BA7D5F2118886.server2
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/116.0
Referer: https://www.apdcl.org/website/
Content-Type: application/x-www-form-urlencoded
Content-Length: 29
Origin: https://www.apdcl.org
Connection: close
mobNo=<mobile_number>&otpNo=000000
Can you spot the difference where the login flow is broken?
Yes, you’re correct. I spotted the same thing when I first saw both requests.
In what context does setting the session cookie as the mobile number of the user make sense? Firstly, using the mobile number as a session cookie is highly insecure. Mobile numbers are sensitive personal information, often used for authentication and verification purposes. Using a mobile number as a session cookie opens up the possibility of unauthorized access and various other security risks.
Attack Scenario:
The attack scenario is very straightforward. If an attacker knows the mobile number of any electricity consumer, then it’s easy to take over the account. No need for OTP… because the login flow is broken.
Steps to Reproduce:
- Access the APDCL login page at https://www.apdcl.org/website and click on login.
- Enter a valid user account’s mobile number, which the attacker doesn’t have access to, and enter the captcha value. Click on send OTP, which initiates the login process.
- Turn on Intercept for both request & response using a proxy tool like Burp Suite or Caido.
- Enter any wrong or random six-digit OTP value. As an attacker, we do not have access. Click on login.
- Go to the proxy tool and forward the captured request.
- Modify the response
Location: /website/ConsumerDashboard
Set-Cookie: mobile={mobile_no}; Domain=www.apdcl.org; Path=/;Secure;7. Forward the manipulated response to the server and turn off the intercept.
The server accepts the manipulated response because the session cookie is the consumer’s mobile number, allowing the attacker to gain unauthorized access to the victim’s account, bypassing two-factor authentication.
Therefore, an attacker can use the mobile number of the victim user to takeover the electricity consumer account.
Impact:
- Personal Information Exposed
Name
Email Address
Mobile number
Address
PAN Number
Voter ID
Aadhar Number
2. Account Takeover
Disclosure Timeline:
- Aug 6, 2023: Vulnerability reported to Assam Power Distribution Company Limited (APDCL) and CERT-In
- Aug 7, 2023: Initial response received from CERT-In
- Sep 19, 2023: Vulnerability fixed
- June 6, 2024: No response received from Assam Power Distribution Company Limited (APDCL)
- June 15, 2024: Public disclosure
On the bright side, the data of 5.17 million consumers is secure now. Unfortunately, some organizations address the issue quietly and proceed without providing any acknowledgment or update regarding the fix.
Nonetheless, what truly matters is that the data of 5.17 million users is now safer, and that remains my primary concern.
Thank you for reading. I hope you enjoyed reading the write-up!
Reference:
For collaboration or any other queries, please contact me at brutexploiter@gmail.com.
