Security Analysis of the Indian Government's Student Assessment Platform

This post discusses about various security concerns regarding an Indian Government's Platform which is used to assess lakhs of students across India.

Introduction

Students are assessed on several bases after their graduation to test their knowledge before starting a job or for admission to further studies. Digitally assessing students has several advantages such as calculating results after students submit their assessments, and reducing the workload on professors/examiners. But are those Platforms really secure? Can a student cheat in their exams? these questions can be a bit gray area to be discussed. In this post, I'm sharing all my findings on an Indian Government Assessment Platform used by several students across India. The Security Analysis is performed from a student account that has the lowest privileges on the web application. A Professor has complete access to view user data.

Security Analysis Steps

Reconnaissance

Using several tools and scripts get as much information about the target domains and try to map their network stack such as what technologies are being used to build the web application, what are their versions, whether are there any third-party services used, etc. Amass can help to gather information on the target domain. I usually have a python script that runs amass in passive mode gathers all the domains, checks for working domains/subdomains, and stores them into a txt file, which I use as the scope in BurpSuite. So, after this step, I usually end with various working subdomains, and using advanced scope control I filter traffic in BurpSuite.

Interacting with Web Application

This step included capturing various HTTP requests and responses. This is the most important step, explore all the functionalities of the web application so we can reverse engineer and understand the web application and what an API endpoint or URL accepts and returns in a response. Using Burpsuite Proxy with the interception option off and configuring Foxy Proxy on my browser to route all the traffic to Burp Proxy, which captures all the logs while I explore the web application navigating through each and every option available on the web app.

Note: There are several tools available that can intercept traffic and generate API documentation but I prefer using BurpSuite since I'm more comfortable using it.

Reverse Engineering APIs

We go through the HTTP/HTTPS captured logs and try to understand what that endpoint is used for and how can we use it to exploit the web application. Several open-source tools are available which can be used to generate OAS documentation. While going through the logs, I used several filters such as viewing only in-scope URLs, and JSON responses; ignoring javascript, images, and other responses. It provided me with only API endpoints to which I can send vulnerable suspected API endpoints to the repeater, view responses, and later test for vulnerabilities.

Testing and Exploitation

In this step, API endpoints are tested against several payloads, OWASP API security Top 10 vulnerabilities, and other known attacks such as SQL injection, etc. based on the Tech STACK used. I always avoid using automated tools, while testing API in the start, since they can generate a lot of traffic and trigger rate limiting. Rate limiting can be bypassed using several methods but it's out of the scope of this analysis. Using repeater and intruder several attacks, and issues found in the API used by web application APIs are discussed below.

Issues Discovered

Returns Backend Server and Tech stack versions

HTTP response returned various backend information in headers such as Apache and PHP versions used that were found to be outdated and vulnerable, which can be exploited using PoCs available on GitHub and exploit-db.

Broken Captcha Check Implementation

The captcha is being used on the front-end Login page but if the captcha is removed from the API request server still accepts the request. Captcha's are being implemented to avoid bot/automated interactions with the web application but It isn't being checked on the web application backend. But this can allow attackers to brute-force the user's passwords. Though the web application was implemented with rate limiting, which can be easily bypassed using rotating proxies and introducing delays between consecutive requests.

IDOR on Profile Pics and Signatures

The web application is using an endpoint that allows anyone to view any user's profile picture and signature without any sort of authentication. Sensitive data should be protected with authentication mechanisms.

Can Link Another User's Account to Attacker's Account to retrieve their complete information or Account Take Over (ATO)

An API endpoint allowed an attacker to add basic student info using the BOLA attack method from request JSON data, attacker can link any user's account to their account and use an updated endpoint to retrieve user detail which provided both the attacker and target account's complete information consisting name, their educational details, home, alternate phone number, and email, etc. in the response. But this led to an update of the target's primary phone and email to the attacker's details leading to Account Take Over. It leads to several privacy issues.

Student can change their Role in API HTTP requests to view another role's message

The application used to load messages on the dashboard based on their role, If the attacker changes the role id in the HTTP request JSON data then it was able to view messages for another role. leading to BFLA vulnerability.

Can change any user's Assessment answer

An Attacker can change any user's response if they're appearing for the assessment test. Anyone can write a simple python script to forge answers in anyone's ongoing test leading to BOLA vulnerability.

Can submit Anyone's Assessment

An attacker can submit any user's assessment if the user has answered all the questions. This vulnerability can be chained with the previous one to automatically submit anyone's assessment answer and then submit the assessment.

Able to generate Assessment reports for any other User

Most of the endpoints are vulnerable to BOLA and BFLA attacks. There existed an endpoint that allowed users to generate the report and receive it via email. The vulnerable endpoint allowed the attacker to generate a report and receive it on their email address leading to privacy issues.

Conclusion

The web application APIs aren't secure they are vulnerable to several attacks including BOLA, BFLA, excessive data exposure, etc. and it also arises the question can we trust organizations and governments with our data? Complete User data is available to any authorized user once they generate an auth token. It should be the responsibility of the organizations and govt. to secure their applications and increase the transparency of what data is being collected and for what reason, also allowing them to opt out of such policies.

All these vulnerabilities have been already reported to the CERT-IN team but they have a maximum 120 days triage period in which malicious actors exploit these vulnerabilities. CERT-IN should prioritize vulnerabilities based on CVE ratings and reduce PII triage duration to as low as possible.