Story and details about a session-related vulnerability found in EPFL's COM-301 homework submission and grading website, which eventually allowed any student to take over another student's account.
Disclaimer: This post describes a vulnerability found in the homework submission and grading website of EPFL's COM-301 Computer Security course. In case it is not already clear and obvious, I should state that the presence of such a vulnerability doesn't discredit in any way neither the course in itself nor the research work carried out by the responsible lab. On the contrary, this course is really great. I had a good time following it, and I do find Prof. Carmela T. to be both an interesting and pedagogical teacher (in my year, Prof. Edouard B. was actually the one responsible for the lectures, but I mostly followed the videos). The aim of this post is, thus, rather to put lights on an unusual session vulnerability made possible thanks to (or 'due to', maybe...) a specific setup (the sibling websites, as later discussed) that I have personally never encountered or read about elsewhere.
One year ago, during my 3rd bachelor year at EPFL, I was following COM-301's Computer Security course, an introductory course to security. The final exam was coming in a few days. After having finished my very intensive 2-hour pomodoro 50/10 study session, I took a very well deserved break, and eventually came to read an exciting piece of text from COM-301 Lab's website mentioning that students were welcome to report security vulnerabilities if they managed to identify any and that doing so could even lead to a bonus on the grade! This was enough to motivate me to have a look at it :)
The COM-301 course's grade is based on two elements: the final exam and practical homework, which are small assignments that students should complete and submit through the semester. The main platform for submitting the solution to these homework — in the form of a flag, CTF like — is the website com301.epfl.ch. Two other intermediary websites were also set-up: com301-vuln.epfl.ch and com301-pcap-validation.epfl.ch. These two sites were specific to separate assignments and would allow students to submit intermediary work in exchange for a flag that could then be submitted on the main platform. One last thing to precise, which would be important for later, is that these 3 sites are kind of lookalikes and only differ by small features, while the general template appears identical. I chose to refer to them as sibling websites.
At first sight, finding any relevant security issue in COM-301 didn't appear trivial at all due to how narrow the attack surface was. There were only the three aforementioned homework websites, which incorporated very limited functionalities with only two distinct possible user inputs: the solution (flag) submission and a homework file upload. At this point, it was obvious that many common vulnerability classes would basically not exist in such a small surface.
Given the described features, the most obvious candidates still worth trying were the below:
1. Server-side-related injections in the solution input field. E.g., SQL injection if the solution is checked through an SQL query; command injection in case the flag is validated within an OS command, etc.
2. Arbitrary file upload in the homework upload field. E.g., ability to upload a PHP shell and somehow manage to put it in a publicly accessible folder to control it back, exploit CVEs related to insecure file parsing, etc.
However, after some manual testing and fuzzing, none of these candidates ended up bringing interesting results... Reflecting on this, I don't exclude the possibility that I missed something there. Additional time could have surely been spent on this, but I actually preferred to move on at some point since looking for server-side vulnerabilities is generally not what excites me the most in web security; I prefer client-side things (^_^)
So, without any success in the above, there was still one thing potentially relevant to look into: authentication and session handling.
In order to access their dedicated and personal interface on each of the three homework websites, students are required to authenticate via a password received by email in the first week of the semester.
In com301.epfl.ch, after submitting a valid password, the session is maintained in the student's browser via one of the two different cookies:
- cookie named 'session', of the following form:
eyJfZnJlc2giOmZhbHNlLCJfdXNlcl9pZCI6IjE3OCIsImNzcmZfdG9rZW4iOiIzODkxMDU3MDdkMTE3YTY3NjU4MmJkN2MzNGNhM2MyN2JiOTY2OWViIn0.Y83GQg.M5dVxwAilDc[...]
- cookie named 'remember_token' - set in the browser if the user selects the 'Remember me' option when logging in - of the following form:
178|eae4b44beb76f8eb70105e2e752aef8d3d61b8d942495bc386769c51ddffadffd8df62a0cb01d4bbdf2423bbbcfcdcf5750f3e2ade2da1b9650fb397bbbf8331
Focusing on the session cookie, it looks to be segmented into three parts, each delimited by a dot, with the first component being base-64 encoded. Decoding it back, we get the following string:
{"_fresh":false,"_user_id":"178","csrf_token":"389105707d117a676582bd7c34ca3c27bb9669ebIn0"}Now looking at the remember_token cookie, the above decoded string allows us to infer that the value 178, included in the first part of this particular cookie, each delimited by the vertical separator '|', represents the user ID.
Any tampering attempt on the user ID in remember_token (e.g., replacing '178' by '179') would, however, make the application return an error message in the HTTP response. This indicates that the user ID is happily correctly validated by the backend, and that the second part of the cookie's value, located after the vertical delimiter '|', most likely consists of a signature or MAC based on the UID, e.g., SECRET_KEY {user_id}.
Now, remember that these three homework sites (com301.epfl.ch, com301-vuln.epfl.ch, and com301-pcap-validation.epfl.ch) are lookalikes and very similar to each other. They were so similar that they were naturally found to maintain the user's session in the same way. Thus, as in com301.epfl.ch, session and remember_token are also involved in the two other web applications.
And there finally comes the vulnerability:
It was found that the same student would be identified by the three sibling web applications under different user IDs, while the backend's secret key, used to build the signature or mac of the session cookies, would be the same one across the different sites.
Given that remember_token cookie is solely based on the user ID, this implies that any student could reuse his remember_token value from com301-vuln.epfl.ch or com301-pcap-validation.epfl.ch to access the session of another student in the main grading system website com301.epfl.ch.
For instance, if a student is assigned the user ID '111' in the realms com301-vuln.epfl.ch and com301-pcap-validation.epfl.ch (user ID is consistent between these two), the server would assign after authentication a remember_token cookie of the form: '111|SIG/MAC{111}', which would then allow to authenticate as the student with user ID '111' in the com301.epfl.ch realm (user ID inconsistency here).
Below is a proof-of-concept video for this issue:
The impact of this issue is the ability for any student in the course to hack into the com301.epfl.ch grading panel of another student. At this point, if you follow through, a single attacker isn't supposed to be able to access all the student accounts, only the one whose user ID was assigned to the former on the intermediary homework websites.
However, this doesn't take into account one last thing, omitted so far, which increases the capabilities of a single adversary: com301-vuln.epfl.ch is vulnerable by design to cross-site scripting, as per the associated homework. Given the fact that remember_token isn't protected with HttpOnly, the previous statement thus implies that an attacker could, by tricking many students into visiting a specific malicious URL, abuse the arbitrary javascript execution to steal their remember_token cookie (in com301-vuln) and then reuse the collected ones to pivot to other student accounts in com301.epfl.ch.
This vulnerability was immediately reported to the SPRING lab upon discovery. They quickly responded and identified the root cause of the issue. As the course is only given during the fall semester, the appropriate fix could be deployed during the following one.
It is interesting to notice that even though session-related issues could, in 2023 at the time, be considered as dying vulnerabilities due to how modern frameworks are supposed to handle everything out of the box, they're often, in my experience at least, worth a look. Even in bug bounty, in fact... Some related reports are still ongoing, but these may be the topic of a future post :).
By the way, I still don't know, to this date, if reporting this issue actually had any impact on my final grade.