Hello everyone. Today, I’m going to talk about two minor vulnerabilities based on insecure parameters that I discovered in the same program. This will be a short story and I will call it as “redacted.com” cause the company runs a private program. So, let’s get started.

I. Bypassing mail verification using insecure parameters

redacted.com has 2 mail features, primary mail and extra mail. A user with primary mail can add extra mail. However, to make the extra mail the primary mail, the app needs to send a verification code to the extra mail.
So, the extra mail cannot be converted to the primary mail without confirmation.

First, let’s analyze how this process takes place under normal conditions.

1- I entered a mail in the extra mail section and observed that verification is required for the mail.

(As you can see in the picture, it sends a confirmation mail and our two options next to the field are “resend” or “delete” the mail.)

2- I ran Burp Suite and went back to the page. I entered an email again and got the request.

3- Two insecure parameters as “activated” and “for student verification” would return false, I changed both to true and submit the request.

4- I went back to redacted.com and I saw a tick button next to the email field. I clicked the tick button and refreshed the page.

Finally, the extra mail has moved to the primary mail section, the old primary mail has become an extra mail.

II. Bypassing study verification using hidden insecure parameter

At redacted.com, users can add custom “study” information. However, for this the study information must be verified and approved by the management first.
I mean, there is a verification process when users add their custom study information. Verification is done directly by redacted.com management.

But, a hidden insecure parameter can make users’ custom study information look like they’ve already been approved, and eventually actually get approved.

Let’s analyze it.

1- As I said, in the “I study” section, we can add our own special study information. for example let’s type “admin” and send the request.

2- I ran Burp Suite and I sent the request again by typing “admin”.

3- The request was as above. I didn’t see anything of interest so I submitted the request and reviewed the response. In response, I saw a parameter “isVisible:” was set to false.

4- I resubmitted the request and added the parameter “isVisible:true” to the end of the request.

I refreshed the page and saw that the information I added appeared directly on my profile.

In this way, attackers would be able to add any information they wanted, bypassing the verification.

The bugs has been fixed and company was rewarded me with €300 for these two minor bugs.

That’s all for now. Thanks for reading. See you in another write up!

You can follow me on twitter: https://twitter.com/canmustdie