Operation Godavan (A Rajasthan Government Project)

Day 1

On the first day of the event, I was given no prior knowledge about the target machine. My only directive was to retrieve the question paper from the server.

I began by setting up my Wi-Fi adapters in monitor mode to scan for hidden networks, suspecting that the exam vendors might conceal the network. My assumption proved correct. The network was hidden and secured with WPA2 protection. If it had been WPS-enabled, it could have been compromised more easily. However, breaking WPA2 encryption demands significant time. Although an evil twin attack could have been a potential option, it was impractical in this scenario because the network was hidden. Moreover, the tablets running the examination app had the application pinned, preventing users from exiting the app or accessing other functionalities. During my analysis, I discovered that approximately 53 tablets and 9 mobile devices were connected to the network.

This was an exceptional case of a highly secure setup. Strong passwords were in use, and the network was monitored by 5–10 professionals working 8–10 hours a day. Under ideal conditions, an organization might deploy only 2–3 professionals per center, making such a large-scale monitoring setup unusual.

I also managed to acquire one of the tablets. By extracting the application to my laptop, I analyzed its source code and discovered a vulnerability. The application allowed brute-forcing of the 4-digit login PIN without implementing a timeout or banning mechanism. This vulnerability could potentially be exploited by attackers to brute-force their way into the application.

This finding highlights a critical security lapse, which, if not addressed, could lead to serious breaches in a high-stakes environment like this.

The only feedback I would provide is at the application level: ensure thorough analysis of the app. I did not have much time to analyze it in detail, but it was evident that if anyone gained access to the app, they could potentially identify vulnerabilities within it.

Day 2

Day 2 began on a positive note as I motivated myself to uncover vulnerabilities by collaborating with other participants at the event. We all reported to the location around 9:45 AM, with the exam scheduled to start at 11:00 AM. The servers were set up by 10:45 AM, and we began our attempts to hack.

The highlight of Day 2 was discovering that the Wi-Fi network had no protection—it was like finding water in a hot desert. Additionally, I managed to get my hands on the app that was used for the examination. I set up Genymotion with ADB to inspect the app and see if anything noteworthy appeared. Upon investigation, I found that the app was transmitting unfiltered traffic, which could be intercepted by any hacker on the same Wi-Fi network. Through the source code, I also identified the website used to monitor and capture data from the system: (Link)

The first approach I tried was to bypass the login. Despite attempting various methods and techniques, I was unable to bypass it. My next step was to fuzz the website to uncover any sensitive information, and indeed, I discovered an open directory: /sdk/doc.

The /sdk/doc directory contained all the documentation detailing how API calls were made on the site.

Still, this information was insufficient to gather anything substantial. So, I decided to approach the app from a different perspective. As mentioned earlier, I was monitoring the data captured through ADB and Genymotion. During this process, I observed that the app was making a POST request to the server's IP address to fetch the MAC address of the device.

For instance, if the server IP is 192.0.0.0, the app would send a POST request to:

http://192.0.0.0:3001/api/getMacAddr.

This confirmed my suspicion that the app could be easily compromised if I connected my laptop to the hidden Wi-Fi and replicated the request. Upon connecting to the hidden Wi-Fi via my laptop, I performed a ping sweep across the network to identify active devices. Eventually, I pinpointed the server IP used for the exam: http://192.168.0.214:3001.

The next step was running an Nmap scan to identify open ports. To my surprise, I found that port 8080 was open, and it led directly to the server application. Accessing this port brought me to the server's login page.

Instead of attempting default credentials, I initially tried to bypass the login page using SQL injection, but my attempts were unsuccessful. Interestingly, one of our team members decided to try the default credentials admin:admin, and it worked! This gave us complete access to the server, allowing us to do everything from adding new users to finding the exam paper and even deleting users.

Additionally, the Nmap scan revealed other open ports, such as 3301, which was their SQL server, providing further insights into their setup.

Here are a few photos from inside the server after logging in:

All users currently in the exam

Recommendations

Here are some actionable recommendations to help secure the application and the overall system:

• Use WPA3 or WPA2 with strong passwords: Ensure the network is encrypted with a robust key.
• Segment the network: Use VLANs to isolate critical systems from general devices.
• Avoid default credentials: Never deploy systems with default usernames and passwords like admin:admin. Enforce strong, unique passwords.
• Use Multi-Factor Authentication (MFA): Add an extra layer of security to the login process.
• Rate-limit login attempts: Use rate-limiting to prevent brute-force attacks.
• Restrict sensitive actions: Limit API endpoints like /getMacAddr to trusted devices or IPs only.
• Enforce logging and monitoring: Track suspicious activities, such as unauthorized API calls or brute-force attempts.
• Static and dynamic analysis: Analyze the source code and runtime behavior to detect potential issues.

Finally, I would like to extend my heartfelt thanks to Alok Sir for providing such a fantastic opportunity. It was a truly wonderful experience, and initiatives like this should be conducted more frequently if India aims to achieve robust security protection and minimize data loss.

Conclusion

This security assessment revealed several critical vulnerabilities in the examination infrastructure:

• Unprotected network traffic susceptible to MITM attacks
• Weak PIN authentication with no brute-force protection
• Exposed server directories with potentially sensitive information
• Insufficient application security controls

These findings demonstrate the importance of implementing comprehensive security measures in high-stakes examination environments to protect the integrity of the assessment process.