Generate online votes using Race Condition Vulnerability in Woobox Web Application (Write Up)

Good day Readers,

In this post I will show you how I found a simple Race Condition Vulnerability in Woobox. It affects their customers that used their platform for online voting contest. 

Early of December 2020 while watching a Valorant stream on Twitch, the streamer said that she is nominated for a contest operated by Riot Games and she gives the link of the contest on her stream chat.

As a viewer of her stream, I opened the link of the contest and tried logging in using my Google account and voted for her and I noticed that you can only vote once on your account so that means only one streamer in every account. Since I'm doing a recon that time and curious about the voting system, I tried logging in again with my other account and tried voting again but before I click on her profile to vote, I captured the request using Burp to see how the voting feature works and what program they are using.

After intercepting the request I noticed something interesting. I tried sending the request to the repeater and started checking every parameters of it and one of the parameters caught my attention after a few analysis. I noticed that one of the parameter is the one that adds a number of vote after clicking the profile of the streamer and the other interesting thing is that there is no user authentication after repeating the request though if you will do it without intercepting, you can't vote multiple times with one account but due to the vulnerability I noticed that I can vote many times using one account when intercepting it.

So my idea is to send the request to intruder and automate that request and surprisingly it works and the streamer that I voted increased her votes instantly and within a few minutes by just automating the request. (and btw she won the contest)

So long story short, I found a Race Condition Vulnerability on Woobox which affects their customers that used their platform for online voting contest. An attacker can manipulate or generate votes by automating because it lacks user authentication. I tried contacting Woobox and the Website that runs the contest but got no response from both sides.

--Proof of Concept--

Below is the actual video demonstration of the vulnerability.

--Timeline--

Reported: Dec 7, 2020

Opened a Disclosure Assistance on Hackerone: Dec 21, 2020

But no response from Woobox and H1 Disclosure Assistance so I decided to publish this writeup.

I hope you enjoy this write up, stay safe and have a great day y'all!

"At the end of life, what really matters is not what we bought, but what we built; not what we got, but what we shared; not our competence, but our character; and not our success, but our significance. Live a life that matters. Live a life of love"

HTML Injection and a dream in Google Chrome for Linux (Write Up)

Henlooo...

In this writeup I will show you a simple vulnerability that I found few days ago on Google Chrome Version 91.0.4472.101 for Linux.

The vulnerability is not remotely exploitable since the attacker needs an access on victim's user credentials and physical access on his device. This kind of issue is not acceptable on Google bug bounty program since physically-local attacks are not in Chrome’s threat model.

I asked my friend for help about this issue and we did some research on it, we tried to exploit the vulnerability to trigger something bigger than HTML Injection but after a long hours of figuring out how to make it a good bug (we aim for RCE), we found nothing.

So I spend hours reading RCE related writeups on the internet and found this cool writeup from Gaurav Mishra which he mentioned the payload he used for his SSRF bug. I tried using his payload and something happened. The browser crashed instantly after the payload executes. I asked my friend if he has a Burp Pro to try using the Burp Collaborator for some SSRF stuff but he said he is also using Burp Community edition. so we ended up reporting this issue instead of continuing the research since also in my mind it will not qualify because as what I have mentioned, it requires access to victim's user credentials and device to reproduce this issue. 

--Proof of Concept--

1. Open Google Chrome for Linux (I used Kali Linux)
2. Login your account to your Google Chrome account
3. After you login to your account, click your account profile/avatar in the upper right corner of your chrome browser
4. Click the Customize Profile button next to your avatar
5. Input the payload in the Name your Chrome profile
Payload: ${("".getClass()).forName("java.lang".concat("Runtime")).getMethods()[6].invoke(("".getClass()).forName("java.lang".concat("Runtime"))).exec("wget")}

and this one if you try HTML Injection: <font color="green"><h1>HTML Injection Vulnerability</h1></font><br /><i>found by @evanricafort</i>
6. Now open terminal and type google-chrome or click your profile again in the upper right corner of the browser and then click the + Add button in the Other profile section
7. A new tab will popup and now click + Add
8. Input any name on it and click Done
9. Click the Already a Chrome user? Sign in below the Get Started button
10. Login to your account again (same account you login on step 2) and see the result

FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION
Type of crash: Browser
Crash State: 

root@evanricafort:~# google-chrome
libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
[36540:36540:0614/235457.931329:ERROR:viz_main_impl.cc(160)] Exiting GPU process due to errors during initialization
[36591:36591:0614/235457.961095:ERROR:gpu_init.cc(440)] Passthrough is not supported, GL is swiftshader
[36510:36510:0614/235528.443094:ERROR:account_info_fetcher.cc(62)] OnGetTokenFailure: Request canceled.
Will not apply HSTS. The HSTS database must be a regular and non-world-writable file.
ERROR: could not open HSTS store at '/root/.wget-hsts'. HSTS will be disabled.
--2021-06-14 23:55:28--  https://clients2.google.com/cr/report
Resolving clients2.google.com (clients2.google.com)... 172.217.161.142, 2404:6800:4005:813::200e
Connecting to clients2.google.com (clients2.google.com)|172.217.161.142|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: ‘/dev/fd/4’
     0K                                                        10.9M=0s

Crash dump id: 84b1ebfc0c559df4
2021-06-14 23:55:30 (10.9 MB/s) - ‘/dev/fd/4’ saved [16]
Will not apply HSTS. The HSTS database must be a regular and non-world-writable file.
ERROR: could not open HSTS store at '/root/.wget-hsts'. HSTS will be disabled.
--2021-06-14 23:55:30--  https://clients2.google.com/cr/report
Resolving clients2.google.com (clients2.google.com)... 216.58.220.206, 2404:6800:4005:81b::200e
Connecting to clients2.google.com (clients2.google.com)|216.58.220.206|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: ‘/dev/fd/4’
Crash dump id: ffe8ac349204a557
Illegal instruction
root@evanricafort:~# [0614/235532.220447:ERROR:nacl_helper_linux.cc(307)] NaCl helper process running without a sandbox!
Most likely you need to configure your SUID sandbox correctly

--Timeline--

Reported: June 15, 2021

Public Disclosure: June 17, 2021

Here's one of the response of Chromium team

An attacker must have access to the user's browser to modify a profile name. I don't think this is a security issue since this bug cannot be exploited remotely. Physically-local attacks are not in Chrome’s threat model [1].

This issue still needs to be fixed, though. I'll look into escaping the profile name before displaying it in web contents.

 

So that is all for this writeup. Stay safe and happy hacking everyone!

"The future belongs to those who believe in the beauty of their dreams."

― Eleanor Roosevelt

Unexpected IDOR Vulnerability in [REDACTED] - [redacted].net (Write Up)

Howdy Guys!

So first of all let me ask you a question. If you are a company owner, would you let your customers data such as their email address, phone numbers, address and other sensitive information's to be accessible to anyone specially to a malicious user? If yes then this one is not for you.

So last month a friend of mine hit me up thru my Facebook Messenger and ask me something related to bug bounty and after some few chitchats he gave a website that has a private bug bounty program and so I decided to give it a try. after a few hours of testing, I found few vulnerabilities including Insecure Direct Object Reference Vulnerability [IDOR]. I compiled all the vulnerabilities that I found and decided to report it to the program.

After a week I received a response from them and I didn't expected the amount of bounty they issue to this vulnerability [IDOR]. Since I think the reward they issue is not worth it for the reported vulnerability, I decided to ask them why is it like that and their response was "I can't give any further details as to why it earned the respective bounty!".

So long story short, I found a simple IDOR vulnerability by changing the value of one of the parameters. here's my report timeline for this issue.



 --Proof of Concept--

1. Login to your [REDACTED] account

2. Go to https://secure.[redacted].net/welcome.php?dad=domain&jc=profiles

3. If you already created a Profile, click the "More" button on it

4. Click Edit

5. After you click Edit you will go to this link https://secure.[redacted].net/welcome.php?dad=domain&jc=profiles&hs=&a=form&id=VULNERABLE

6. The parameter "id" in the link was the vulnerable parameter so if you will change the value of it into any numbers, you will be able to see other users information if you can luckily hit the exact ID of your target user.

--Live Demo-- 

https://secure.[redacted].net/welcome.php?dad=domain&jc=profiles&hs=&a=form&id=XXX<--- My Profile

https://secure.[redacted].net/welcome.php?dad=domain&jc=profiles&hs=&a=form&id=187 <--- Victim's Profile (Sample Victim)

So by changing the value of the parameter "id" you will be able to see other users information due to this vulnerable parameter.

--Timeline--

Reported: Jun 17, 2019, 4:25 PM
First Response: Jun 17, 2019, 4:29 PM
Fixed and Bounty Awarded: Jul 1, 2019, 11:44 AM

"Thank you so much for your contributions in identifying this mulfunctionality.
It has been verified and resolved.
As such based on the level of harm and risk you have earned a bounty of $2. These funds have been credited to your [REDACTED] Live Credits.
When you want them withdrawn to your PayPal account, please create a ticket with this request forgetting not to include your PayPal email address.
We are hoping to continuously hear from you while you are in the hunt of bugs."

My Follow Up Question: Jul 1, 2019, 1:44 PM
Their Follow Up and Last Response: Jul 1, 2019, 1:51 PM

"Domain name profiles are really domain name pre-registration whois preset data and don't necessarily represent the client's data. Who's data is kinda public anyway!
None the less, I can't give any further details as to why it earned the respective bounty!"

In my demo there are ID's that has my account information on it and that means that the ID doesn't belong to someone else and instead of giving and error response, it gives my account information instead.

Well, I respect the program owner's decision on this report and I hope you guys enjoy reading this write up. see you on my next write up :)

PS: The bounty is not even enough for the PayPal tax :p lmfao

"The harder you work for something, the greater you’ll feel when you achieve it."