iClicker Authorization Bypass Vulnerability

During my research into the iClicker web application, I discovered a vulnerability in it that allowed users to bypass location-based restrictions. This flaw made it possible for students to spoof their locations and join sessions remotely, undermining the integrity of the platform’s location-based attendance system.

iClicker requires students to be physically present in a session’s location to join. However, this check was enforced through a flawed system. When a student attempted to join a session, the iClicker app would request the device’s geolocation and send it to iClicker’s servers. If the location check failed, the server responded with the exact coordinates of the session’s location. This was the key flaw—rather than simply displaying a static map image, the server directly sent latitude and longitude data, making it easy to capture and reuse.

To bypass the restriction, a user could simply capture the session’s coordinates from a failed attempt and reuse them in a subsequent request. While location spoofing through third-party apps was already a known workaround, this flaw allowed users to exploit iClicker’s own responses to gain access without needing any additional tools.

Additionally, the iClicker web app was built with Angular 8, an outdated version of the framework. Without the proper security settings enabled, old versions of Angular expose a global angular object in the developer console, which provides an entry point for manipulating the application’s behavior with ease. This weakness enabled deeper exploitation of the session system.

To demonstrate the exploit, I developed a user script that automates session joining, location spoofing, and poll answering. The script takes advantage of the Angular dependency injection system to override key functions in the application. It intercepts and modifies geolocation data before it is sent to the iClicker servers. It retrieves the instructor’s session coordinates, stores them locally, and then uses them in future requests. This allows the user to bypass the location requirement seamlessly. It also listens for session availability and automatically submits the stored location data to join the session as soon as it becomes active. Additionally, when a poll question is detected, the script waits a predefined time before selecting and submitting a random answer from the available choices.

This proof of concept highlights the risks of exposing data and the dangers of insufficient security practices in web applications. It’s important to note that this research was conducted purely for educational purposes and security awareness. My goal in this project was to understand security flaws in web applications and demonstrate the importance of robust data handling practices.

This project reinforced my knowledge of web security, API exploitation, and front-end security best practices. Some key takeaways include being cautious with user data, keeping frameworks up to date, and minimizing client-side exposure. Returning exact coordinates instead of a static map image unnecessarily exposed sensitive location data. Using outdated versions of frameworks like Angular 8 increased the risk of security vulnerabilities. Exposing objects like angular in the developer console provided an easy entry point for attackers.

Security should never be an afterthought, especially in applications that rely on authentication and real-world location validation. This project was a fascinating deep dive into security loopholes, and it further solidified my interest in ethical hacking and secure software development.