This is How I Managed To Change My Teams Availability Schedule With A Simple Vulnerability

Broken Access Control API vulnerability

6 min readJan 8, 2023

Background story:

Well, there was me and my club (cyber-security club btw) and every semester we try to see what time is the best time for everyone (so more members can attend the club). Anyways, we had to use this app called “When2Meet” which looks like a very outdated app (spoiler: it is).

So this got me thinking “This app seems simple and old, what would happen if I play with it a bit more”, and by “playing” I mean, checking how it works.

Setting up the scenario:

Before I start explaining how I came up with that I am going to set up the same sort of situation again.

So, back when I had my club meeting there were like 20+ members, so I will just set up 5 accounts which already allocated their availability.

I recommend you checking the app first in case it doesn’t make much sense to you.

When2Meet accounts (on the left) and the availability (on the right) from such accounts

Hands on:

Now! Lets get to the fun part!
For this example I will be account1 and will be using burpsuite community edition (as it is all I need to show the website’s behavior)

First, I got curious on how the application really updates the availability from a user, so I decided to check the network tab using the developer tools (Press F12) to open the panel.

Then, I decided to add a new availability time slot (let’s say 12:00 PM)

When2Meet Adding 12:00PM Slot Availability

At the same time, I checked if there was any request as soon as I updated my availability and there was!

Network Requests Shown When Adding New Slot Available

I got more curious about it, especially about the format for the request, I was not sure how would it send that 12:00 PM slot as a proper request (I mean, look at it, is just one rectangle).

So I clicked on “Request” in the developer tools in the same request and saw the parameters sent.

Okay…
So we got “person”, “event”, “slots”, “availability” and “ChangeToAvailable”

Let’s break this parameters down into what they mean:

person: The id of the current user logged in

event: The id of the meeting/event (in my case it was club’s availability for next semester)

slots: The IDs of the slots you want to change (those rectangles) in this example I only changed one, but If I selected more for example, I would’ve gotten more of these.

Availability: The slots encoded in 1's and 0’s (The most important field after the person and event id in my opinion) this defines how will someone’s availability will look.

ChangeToAvailable: This field defines if its going to be available or not, True will turn it to green, while False will leave it in grey.

Now, let’s play with it

Changed Availability for account1 (our account)

Let’s open burpsuite and access our account (Account1) and create a simple request to modify a bunch of slots.

Let’s send that to the repeater and forward it normally so the changes get saved.

Done! it has been normally saved, as it should be.
Now, let’s clear those white spaces and turn them back into red (not available) leaving it empty.

Cleared Availability for Acount1 (our account)

I know what you’re thinking “Yeah, so now what?”

The reason why we do this, is to check if I can re-send the previous request and see any changes reflected. This is to check if there is something else required or if that is all I need.

So we go back to the “Repeater” Tab in Burpsuite and re-send the previous request.

Re-sending the previous request for Account1

Now…

What do you think happened? If you guess is “Well, in theory it should make those empty slots green, meaning it worked”, then you will be right!

Right now you might be thinking something like
“Yeah, well, that is not so impressive”

However, let me tell you something.

Did I have to log into this account to change it? remember, the account has username and password.

Sign in Fields For Accessing The Corresponding Account Availability

No right? during the request, there not a single token or way to verify that the user is properly logged in and making the request.

In other words: anyone with the proper request crafted can make changes to your account’s availability.

The only issue here…

Well, you possibly have spotted something important.

“How do we get other’s ID?”

Believe me, it was easier than I thought.

Let’s go back to the main page before we log in and open the developer tools. After that I decided to see if my ID (76749636) would appear somewhere in the code, so I went in the “debugger” tab and pressed CTRL + SHIFT + F and typed the id: 76749636

To my surprise, after entered this ID and pressing enter, I realized it was in the index. Meaning, in the source code from the page.

Now, you can see that it not only shows my ID, but also all the other members IDs.

BINGO!!! We go them.

Now you could modify everyone’s schedule by just changing the “person” field with the other members IDs.

And that’s how I was able to change my club’s availability and later show it to them.

PeopleNames[0] = 'Account1';
PeopleIDs[0] = 76749636;
PeopleNames[1] = 'account2';
PeopleIDs[1] = 76749648;
PeopleNames[2] = 'account3';
PeopleIDs[2] = 76749659;
PeopleNames[3] = 'account4';
PeopleIDs[3] = 76749667;
PeopleNames[4] = 'account5';
PeopleIDs[4] = 76749673;

Now we just had to put those IDs into the previous request, and send them over and over again.

Let’s get a bit technical, just a bit I swear

So, what happened? why is this app vulnerable?

Well, one main thing I realized is that there is no user authentication required when submitting a request.

This is something quite common among APIs, an unauthorized user can make a request on behalf of another.

This is called:

“Broken Access Control”

Why? because as account1, I shouldn’t be able to modify others account’s.

I reported this issue to the owner/s via e-mail and explained this matter. However, I doubt the owner/s still maintain the website.

Enjoyed the ride?

Follow for more stories and content!