In November 2024, I found and reported a security vulnerability in a University of Chicago system which allowed a malicious actor to access sensitive student data. This was reported in a Chicago Maroon article, but the following is the full story of how it all went down.
Discovery
When I first arrived at the University of Chicago, obviously the first thing I did was add my classes to my calendar. Logging in to the student portal, I copied the iCal link from the calendar icon (circled in red below), pasted it in my calendar application of choice, and all my classes appeared!
It wouldn’t be until several years later that I would think back to this moment and realize that I had just taken advantage of a yet-undetected vulnerability.
Investigation
A few years later, I thought I would revisit this link, and quickly I discovered that something was wrong. The link is pasted below (with a fake subdomain and student ID).
https://fakesubdomain.uchicago.edu/coursecalendar?termid=2248&emplid=12345678This endpoint seems to accept two parameters, termidand emplid. Given that emplid matched my student ID, it was straightforward to conclude that it asked for the ID of the student from which to return the schedule. termidonly took a little longer to figure out, but I quickly discovered that it represented the quarter of classes (UChicago works on a quarter system instead of semester) to return.
The pattern turned out to be as follows: the first three digits represented the year (with the hundredths digit missing), and the last digit represented the specific quarter: Winter (2), Spring (4), Summer (6), Fall (8). Here’s how to read a termidof 2248:
2248 –> 224, 8 –> 2024, Fall
It’s then that I realized there was no authentication token passed. So naturally, I tried opening the link in a private window. When Firefox downloaded the iCal file of my classes without any problem, I knew that things had just gotten serious.
Given the incremental nature of UChicago Student IDs, my Student ID +1 is someone else’s Student ID, and I now could know their entire schedule, which included the building and classroom number of each lesson.
From this vulnerability, I identified two main attack methods.
Attack Method 1: Previous Knowledge of a Student’s ID
As I’ve previously mentioned, the endpoint only takes two parameters: the student’s ID and the quarter desired. If we have both pieces of information, then we are able to access their full schedule for their entire time at UChicago.
The question now becomes How frequently do others have access to a student’s ID? Unfortunately, the answer is “very frequently”. Here are a few examples:
- Faculty seeing their student’s ID numbers
- University Organizations using Student IDs to manage enrollment (ex: UChicago Dining)
- RSOs (Registered Student Organizations) collecting their members’ Student IDs to uniquely identify them and assign them privileges (ex: room or equipment access)
- External (non-UChicago) entities using Student IDs to validate a student’s enrollment status
However, someone having knowledge of a Student’s ID number shouldn’t entitle them to know a student’s entire whereabouts.
Attack Method 2: Without Knowing a Student’s ID
But what if we don’t know the student’s ID, can this endpoint still be exploited to gain information? We actually can due to UChicago’s sequential Student IDs: a student ID + 1 usually is another valid Student ID.
With this knowledge, we can apply the following to figure out a student’s ID and find their classes:
- Collect the schedules for all students by iterating Student IDs and quarters
- Narrow down the list of students with any known information (ex: I know this student took MATH 152 in Spring 2023)
- Apply Attack Method 1
To demonstrate this attack method, I decided to run an experiment.
To replicate Step 1 of this attack method, I built a website that anonymously collected 102 consenting students’ schedules. While not perfect, the resulting sample is generally representative of the undergraduate student population across majors and years.
Then, for Step 2, I ran a simulation to test how many classes I needed to know a student attended (ex: I know this student took MATH 152 in Spring 2023) before I could uniquely identify them. On average, it took 1.455 classes (median: 1.0; min: 1; max: 10).
Let’s now assume that our hypothetical attacker didn’t have such precise information but instead had observed our hypothetical victim and knew which buildings they had classes in. For example: I know this student had classes in Kent during Fall 2024. Then, it only takes 4.087 observations on average to uniquely identify the victim (median: 4.0; min: 1; max: 57).
Implications & Recommendations
Allowing anyone to know any student’s whereabouts is obviously a very serious breach of privacy which may have severe repercussions. This vulnerability may be used by stalkers or other individuals with bad intentions to obtain the location of a target student, putting them in potential physical harm.
This unauthorized divulgence of Personally Identifiable Information (PII) is also a FERPA violation, which may result in legal action and criminal penalties to the school if not resolved.
In my report to the University, I recommended the immediate termination of the affected endpoint, and suggested that when they bring this feature back, that it be secured.
Outcome
A few hours after I sent my report to the University, the endpoint was taken down, and a secure version came back up a few days later.
The Chicago Maroon published an article about the vulnerability three months its termination.
Timeline
- September 2021: First observed
- October 2024: Began investigating
- November 11, 2024:
- 11:46 AM: Submitted the vulnerability report
- 12:42 PM: UChicago Chief Information Security Officer (CISO) Acknowledged receipt of the report
- ~6 PM: Endpoint taken down
- November 14, 2024: New endpoint released to restore the feature, this time protected behind UChicago Single Sign-On
- November 21, 2024: Asked CISO for an update
- November 22, 2024: CISO replied asking for questions about my supervisors; went back and forth to answer their questions
- November 25, 2024: CISO requests a meeting with me and my supervisors
- December 3, 2024: Meeting time set
- January 16, 2025: Meeting with CISO and my supervisors going over details of the vulnerability and the status of IT security at UChicago. Case closed.
- March 25, 2025: Chicago Maroon article is published about the vulnerability.