Hacking Online Classrooms - Part 1

 Hello folks, hope you guys are doing awesome. This post is the first part in the series of hacking online classrooms. In this part I will be covering the vulnerabilities I found in one of the Online Classroom. Currently I cannot reveal the name of the classroom so for this blog we will use example.com.

I found multiple vulnerabilities in the online classroom example.com but I will discuss some of the coolest ones in this post. 

Combining Self XSS and CSRF to report Stored XSS ...

So in the classroom there is a functionality to create classes. A teacher can create a class and then invite students to his class.

So my first instinct to test classroom name for XSS. I created two account one as a teacher and one as a student. From the teacher's account I created a classroom called test from the teacher's account and than joined the classroom from the student's account. 

Now in the Teacher's account the classroom name test was getting reflected in 3 (Two html context and one attribute context) different places. And in the Student's account the classroom name test was getting reflected in only one place.

So I changed the name of the classroom to a some like <svg onload=alert(1)> and the change was reflected in both of the accounts. 

In the student's account the payload was properly escaped and hence XSS is not possible.

And in the Teacher's account the payload was properly escaped in the two of the contexts but it was reflected as it is in one of the context. 

So XSS is possible in this scenario -

But it's not so cool cause it is a self XSS and it's of no security impact. Only a user authenticated as Teacher can create a classroom. 

Than I observed there was no CSRF protection in the Add Classroom functionality. Means an attacker can CSRF the teacher to add a arbitrary classroom  - 

As you can clearly see the CSRF protection is missing but the POST request is in JSON format as you can see in the above pic.

So I tried to change the Content-Type to application/x-www-form-urlencoded and changed the body of the request to simple param-value query type.

And Look it worked -

 

Exploitation -

1. Now and attacker can perform a CSRF attack on the victim to create a arbitrary classroom on the victim's behalf and will send and XSS payload in the name of the classroom. Basically this becomes a scenario of Stored XSS.

PoC -

2. An attacker can also perform the CSRF to change the name of a class. Means he don't need to create a new class and  can rename a already running class's name to XSS payload to maintain low profile.

But there is a constraint here, the request to change the name of a class looks something like this -

 Can you see to create a URL to rename the classroom an attacker need to know the unique ID of the class which. As each classroom has a unique ID which is assigned during classroom creation so we need to find a way so that we can leak the ID of the classroom.

So when a student joins the classroom of a teacher than he can see the unique ID of the classroom. So a student of a classroom can change the name of the already created classroom to some XSS payload to XSS the teacher. 

PoC -

Fetch Metadata headers as mitigation for CSRF

My CSRF PoC was not working in Firefox but was not working in Chrome. It seems that some CSRF protection is in place. So I intercepted the request in Burp and I saw some weired extra headers which are not present in the Firefox :-

So Fetch metadata headers is a browser's security mechanism for the cross-origin request. As you can see in case of cross-origin request browser set sec-fetch-site header to cross origin which redirect the user to login page that's why the CSRF attack got failed in case of Chrome. 

Currently Fetch metadata headers is only Chrome, Edge and opera and is under development in Firefox and Safari. I still believe that Fetch Metadata headers are not a good way to mitigate cross-origin attacks read more about Fetch Metadata Headers here.

I also got some cool IDORs 😋

IDOR to delete the classroom of a Teacher

As you know when a classroom is created than a unique ID is provided which is then used to refer the classroom thereafter.

So there was an option to delete a classroom and I was interested in looking how delete classroom functionality works so I intercepted the request 

So delete classroom functionality simply pass the unique ID of the classroom to the delete endpoint. But after some testing I get to know that the /delete endpoint has a Broken Access control issue which a user can leverage to delete a classroom which doesn't belong to him/her.

So an attacker can delete the classroom he just need to know unique ID of the classroom. So as I told earlier unique ID of the classroom seems totally random so we the attacker must find some way to leak the unique ID of the classroom he wants to delete.

As discussed above if a student joins a classroom then he can see the unique ID of the classroom. So a Student of the classroom can delete the classroom without any interaction with the teachers account

IDOR to view the Draft Assignment of a classroom 

So one of the functionality of the classroom is that a Teacher can create an assignment and share it with students of the classroom. There are two stages of  an assignment Draft and Published. So students can only see the the assignment if the Teachers publishes it. So what if a student can view the assignment when it is in its draft state?? Cool na..

A request to create a assignment looks like this  -

So a numeric ID 26908 is assigned to a assignment when it is created. And each time a new assignment is created it is assigned a new numeric ID. 

So it's pretty easy to guess the ID of an assignment, each time a new assignment is created the numeric ID is incremented by 1. If any user create an assignment than the numeric ID increases by 1. Pretty Simple!!

So I created two accounts one for Teacher and one for Student. In the Teacher there are two assignments - Published Assignment (id - 26914) and Draft Assignment (26913).

In the student's account I joined the classroom and the student can only see the Published Assignment.

So if the student clicks on the assignment the url looks something like this -

So it simple the assignment is referred by its ID - 26914. Now I thought since I know how assignment ID is created so I changed the assignment to 26913 and it looks like I can access the Draft Assignment of Demo Classroom -

 Cool!!

Since the endpoint is not validating assignment ID and we can also calculate it. This means a student of an classroom can view the assignment which is still in draft state and not published. 

Note - The "s" parameter in the url denotes that it is an student account.

Okay Folks, that's all for now. Until next time 😎

Stay Hydrated and Keep hacking...