Hello,
In the month of June 2021, inspired by the awesome Twitter infosec community’s tweets of sticking to a single target and keep hunting on it until you understand it better than the developer who created it. I decided to start the hunt on a new program and stick to it. I decided to only focus on OAuth related bugs for the first week.
Following my usual methodology, I started the nuclei scan with the community nuclei-templates for spreaker.com and started browsing all its features, registration, forgot password functions with burp suite turned.
After a while, the nuclei scan came with no hit
But I didn’t quit and I registered an account on the site and kept exploring its features. Then there I found an option to create OAuth apps, which allows integrating spreaker OAuth login into 3rd party sites.
So, I created an app there and tried injecting XSS, CSTI, SSTI payloads in the app name, description, callback URL, website URL but no luck.
Then, I started reading different writeups on OAuth listed at Pentester.land
Those writeups taught me to test for authorization code multiple usage vulnerabilities, authorization code never expires issue, race condition on using the authorization code, read the RFC#6749, etc. That finally leads me in finding my first vulnerability at spreaker
1. OAuth app related
- I found that the authorization code generated by the app can be exchanged for an access token even after deleting the OAuth app from spreaker
- One can use the refresh token to generate a fresh access token even after deleting the OAuth app
- Access tokens created by OAuth app isn’t expired or revoked even after a developer deletes his/her OAuth app
- New access token can be used to make API calls even the app for that access token doesn’t exist
- I found that the old access token pair is still not expired meaning even after generating an access token with the refresh token the old access token can still be used but the rfc clearly states to revoke such access tokens (https://datatracker.ietf.org/doc/html/rfc6749)
Immediately, I created a report, recorded a POC, and sent the report. After a week of waiting they reply “token expiration times are carefully chosen to balance security and user experience”
I tried explaining the detailed impact of such issues based on the RFC which strictly forbids such behavior but I never got any response from their side
Similar reports:
https://hackerone.com/reports/57603
https://hackerone.com/reports/55140
2. Access tokens for 3rd party logins aren’t expired even after deleting the account at spreaker.com
I found that the access tokens for the 3rd party OAuth providers aren’t expired on disconnecting the 3rd party app or even after deleting your account at spreaker
An attacker can use leaked access tokens to fetch the user resources even after the user has disconnected the 3rd party app or even deleted his/her account
Again created another report and sent it to them. After a week I got the same response like on my first report “token expiration times are carefully chosen to balance security and user experience”.
3. OAuth CSRF due to no state param at login with FB
I found that the state parameter is not used along with Login with Facebook which leads in OAuth CSRF.
Because of this an attacker can login the victim to his account, making the victim that this is his own account and the victim may store sensitive data PII at there, which can be accessed by the attacker.
I agree they could mark this one as informative/NA because some programs don’t accept CSRF on Login/Logout but I still reported it and they closed this as NA.
Similar reports:
https://hackerone.com/reports/2228
4. Pre-account takeover of victim/Blocking victim from accessing his/her account
After a couple of days later I found that signing up an account at spreaker using OAuth login an attacker can access/control a victim’s account by just changing his/her account’s email address to the victim’s email address
I also found out that once an attacker changes his/her account’s email to a victim’s email. The victim won’t be able to sign up or reset the password of his/her account. Only the attacker can send account confirmation emails to the victim’s email address.
Immediately, I wrote a report and sent it to them. After a week of waiting they reply “In order to exploit this vulnerability, you need to perform a man-in-the-middle attack” Seriously?
5. com.spreaker.android leaking OAuth secret key for the spreaker’s own OAuth app
I found that the spreaker’s android app com.spreaker.android is leaking client_secret token during OAuth login.
Created a report and sent it to them and this time they say “In order to exploit this vulnerability you need to perform a man-in-the-middle attack.”
6. com.spreaker.android.studio leaking OAuth secret key for the spreaker’s own OAuth app
I found that the spreaker’s another android app com.spreaker.android.studio is also leaking client_secret token during OAuth login.
Created a report and sent it to them and their response “This doesn’t describe a vulnerability and it doesn’t qualify for a reward since what you described is the intended behavior”
FML
I quit hunting on that program that same week. All of my reports were closed as NA and I tried explaining to them about the impact of each vulnerability several times but I never received any response from their side.
