--

[Boris007]

--

[khaled0111]

Please remove the video if the vulnerability hasn't been patched yet (aasuming that it works)!

[logfiles]

I have sent a detailed solution to email bugs.stake.com but haven't heard from them for 5 days. Pinged steven on stake discord channel and haven't heard from him. Talked the support and showed him the vulnerability live but he says to post on forum.

It's quite weird that the support would want you to share a vulnerability in their platform to a public forum. What are they trying to achieve?

[EliteCrash]

Well there could be many reasons on why they didn't respond to you urgently, I can't really comment on the fact of the csrf key being leaked but I can comment about the vulnerability you mentioned.

I tested out the 'vulnerability' you pointed out, but the funds you get from the cash-out are purely visual meaning they don't affect anything on the site. After a quick refresh your balance will return back to normal as it would be after a normal cash-out. So looking at it financially they don't lose anything so that's probably a reason for why they are taking some time to respond.

[Lakai01]

I have sent a detailed solution to email bugs.stake.com but haven't heard from them for 5 days. Pinged steven on stake discord channel and haven't heard from him. Talked the support and showed him the vulnerability live but he says to post on forum.

The CSFR token must be known to the client. To prevent CSFR attacks, the token is attached to the URL, for example.
Of course you can send requests over and over again and Stake.com should react with error messages, that the effect is only visual you can see in your video. As soon as you click on Cashout at minute 1:26, the amount changes back again.

A very interesting but quite easy to understand post about csfr can be found here at stackoverflow.

So yes, you are right. Stake.com should respond to those subsequent requests with error messages, but the impact is very minor because you are only changing the state of your ui. You would be able to do this with any simple dev tool like the Google Chrome Dev Tools, too

[Boris007]

I have sent a detailed solution to email bugs.stake.com but haven't heard from them for 5 days. Pinged steven on stake discord channel and haven't heard from him. Talked the support and showed him the vulnerability live but he says to post on forum.

The CSFR token must be known to the client. To prevent CSFR attacks, the token is attached to the URL, for example.
Of course you can send requests over and over again and Stake.com should react with error messages, that the effect is only visual you can see in your video. As soon as you click on Cashout at minute 1:26, the amount changes back again.

A very interesting but quite easy to understand post about csfr can be found here at stackoverflow.

So yes, you are right. Stake.com should respond to those subsequent requests with error messages, but the impact is very minor because you are only changing the state of your ui. You would be able to do this with any simple dev tool like the Google Chrome Dev Tools, too

Leave the cashout, what if someone place bets on your behalf using your csfr ?? : THE BET THAT YOU DONT want to place??

All gambling platform has tokens that expire after each operation, thus making you secure.
Why should I have the same token for an indefinite amount of time...no matter how many times I open/close/change tabs

Another CVE-2018-7504 : https://bitcointalk.org/index.php?topic=5247038.msg54393291#msg54393291

[Lakai01]

All gambling platform has tokens that expire after each operation, thus making you secure.
Why should I have the same token for an indefinite amount of time...no matter how many times I open/close/change tabs

There are 2 common strategies for the CSFR-key generation:

1) per request
2) per session

I think stake.com has a session-based key generation strategy in place.
Are you sure that the token stays the same after you have created a new session (e.g. logout and login)? The keys usually are invalidated as soon as your session ends. There are exceptions, of course, some sites use keys which are valid for 24 hours, but usually those sites or instances are not accessible from the internet like your intranet SAP installation.

There is little to no security-advantage to "per request invalidations" (this is what you mean with "after each operation"). Here is a very interesting discussion about the differences and the pros and cons of per session/per request-invalidation.

[bob123]

I had earlier sent the full report with code and explanation on how the open parameters on forum.stake.com is leaking the csrfKey.

Nothing is being leaked. The CSRF Token is nothing which has to be kept secret from the client.
The Client always sees this token.

The point of this token is, that some other website can't create that request on your behalf (because they would need this token for that).
And with proper HTTP access control, they can't access this token.

I found a cashout flaw which is bad for the reputation of stake sports betting system, though I was unsuccessful in withdrawing the amount

You were unsuccessful in withdrawing, because there is no vulnerability. All you did was manipulating the requests which resulted in visual representation of your manipulated requests (because it is being handled by JS).
Because of the (proper) server verification, you weren't able to withdraw.

Talked the support and showed him the vulnerability live but he says to post on forum.

This is not a relevant vulnerability.
It just changes some visual representation client-sided.

The server still does handle everything properly.

Leave the cashout, what if someone place bets on your behalf using your csfr ?? : THE BET THAT YOU DONT want to place??

That's not possible, because of the CSRF token.


Long story short:

• Just changes visual representation client-side
• No Cashout/Withdraw possible
• Not a concerning Bug (just a visual one)
• Not a vulnerability
• Does not compromise the security in any way

[Boris007]

I had earlier sent the full report with code and explanation on how the open parameters on forum.stake.com is leaking the csrfKey.

Nothing is being leaked. The CSRF Token is nothing which has to be kept secret from the client.
The Client always sees this token.

The point of this token is, that some other website can't create that request on your behalf (because they would need this token for that).
And with proper HTTP access control, they can't access this token.

I found a cashout flaw which is bad for the reputation of stake sports betting system, though I was unsuccessful in withdrawing the amount

You were unsuccessful in withdrawing, because there is no vulnerability. All you did was manipulating the requests which resulted in visual representation of your manipulated requests (because it is being handled by JS).
Because of the (proper) server verification, you weren't able to withdraw.

Talked the support and showed him the vulnerability live but he says to post on forum.

This is not a relevant vulnerability.
It just changes some visual representation client-sided.

The server still does handle everything properly.

Leave the cashout, what if someone place bets on your behalf using your csfr ?? : THE BET THAT YOU DONT want to place??

That's not possible, because of the CSRF token.


Long story short:

• Just changes visual representation client-side
• No Cashout/Withdraw possible
• Not a concerning Bug (just a visual one)
• Not a vulnerability
• Does not compromise the security in any way

I was able to upload a script on your server, wasn't I ??
It is strange,  I gave you information regarding the manipulation but you seems to challenge me and deny.
Here are some points from a OWASP about csrf:

Use a non-predictable, well-established random number generator with enough entropy.  You Pass in this.

Expire tokens after a short amount of time so that they cannot be reused. You fail in this, your token stays for  large unknown amount of time no matter if I close browser, I go out for a coffee or for a 6 hour Nap.

Do not send tokens in HTTP GET requests so that they are not directly available in the URL and they do not leak in the Referer header. You fail in thos also.

There was a time when keybase.io used to leak CSRF tokens on every invalid request.
More text you can find it here : https://hackerone.com/reports/77065

Importantly forum.stake.com leaks 6 the parameters, why not hide them

It is easy to say that csrf key is important for client but should not the gambling platform use strict methods to protect its players?

A saying goes : Locks are for good people like you, me and people reading this so that they fear breaking into others house even if they want.
Locks are not for thieves or robbers because , No matter if Lock is there or not they will break into...

SO SHOULD WE PUT LOCK IN OUR DOORS??

[Boris007]

[li]Does not compromise the security in any way[/li][/list]

Does not uploading JS files in your system and bypassing XSS sanitizer shows a vulnerable system??

I can show you 10 examples on hackerone where things like yours is a vulnerability.
Responsible firms accept reviews and just dont deny.
I did not posted the XSS video because I dont want people to try it on your system.

[bob123]

I was able to upload a script on your server, wasn't I ??

You didn't upload anything on my server. I am not affiliated with stake.com in any way.
I am not owning or administrating the server, neither have i used their website even once.

It is strange,  I gave you information regarding the manipulation but you seems to challenge me and deny.

You didn't manipulate anything. All you did was playing around with the free version of burp suite, changing a few parameters.
The server obviously reacted properly. If there was a vulnerability, you would have been able to withdraw funds this way (which btw was possible with a vulnerable exchange in the past).

But this was not the case here. Nothing happened. You were able to "trick" the locally running javascript with your own parameters... Nothing special.

Does not uploading JS files in your system and bypassing XSS sanitizer shows a vulnerable system??

You didn't upload anything and neither did you bypass anything.

All you did was changing a parameter in a POST request.
You showed nothing regarding a server vulnerability.

[Boris007]

I was able to upload a script on your server, wasn't I ??

You didn't upload anything on my server. I am not affiliated with stake.com in any way.
I am not owning or administrating the server, neither have i used their website even once.

It is strange,  I gave you information regarding the manipulation but you seems to challenge me and deny.

You didn't manipulate anything. All you did was playing around with the free version of burp suite, changing a few parameters.
The server obviously reacted properly. If there was a vulnerability, you would have been able to withdraw funds this way (which btw was possible with a vulnerable exchange in the past).

But this was not the case here. Nothing happened. You were able to "trick" the locally running javascript with your own parameters... Nothing special.

Does not uploading JS files in your system and bypassing XSS sanitizer shows a vulnerable system??

You didn't upload anything and neither did you bypass anything.

All you did was changing a parameter in a POST request.
You showed nothing regarding a server vulnerability.

When you have no information about, if i did uploaded anything in the server why the hell are you speaking up?

All payloads is not available for people like you.

[bob123]

When you have no information about, if i did uploaded anything in the server why the hell are you speaking up?

Because your whole OP is nonsense and completely irrelevant.
The title is misleading. You can not cashout anything. You even stated it in your OP:

I was unsuccessful in withdrawing the amount

Manipulating parameters in a request without any outcome is not a vulnerability. Period.
You showed us that the server does not accept those wrong parameters. So why do you claim that THIS is a security vulnerability ?

[Boris007]

When you have no information about, if i did uploaded anything in the server why the hell are you speaking up?

Because your whole OP is nonsense and completely irrelevant.
The title is misleading. You can not cashout anything. You even stated it in your OP:

I was unsuccessful in withdrawing the amount

Manipulating parameters in a request without any outcome is not a vulnerability. Period.
You showed us that the server does not accept those wrong parameters. So why do you claim that THIS is a security vulnerability ?

Read this : https://bitcointalk.org/index.php?topic=5247038.msg54393291#msg54393291

[bob123]

Read this : https://bitcointalk.org/index.php?topic=5247038.msg54393291#msg54393291

That's a different topic.

Regardless of the other topic, what you have mentioned here is not a security vulnerability and is completely irrelevant.

[Boris007]

Read this : https://bitcointalk.org/index.php?topic=5247038.msg54393291#msg54393291

That's a different topic.

Regardless of the other topic, what you have mentioned here is not a security vulnerability and is completely irrelevant.

If you know about vulnerability disclouse peogrammes then you would know that all details are not provided in public, and that is what I did.
I posted some information here and is communicating over other peivate medium.
This thread is meant to keep a poof of the current communication.

[bob123]

~snip~

You have basically 2 statements in your OP:

1)

[...] the open parameters on forum.stake.com is leaking the csrfKey [...]

2)

[...] I found a cashout flaw [...]

And as i already have mentioned:
Regarding 1), the token is not being "leaked". The client needs to know it.
Regarding 2), your so-called "cashout flaw" does not allow you to really cashout. You are just able to manipulate visual things client-side.

[Boris007]

~snip~

You have basically 2 statements in your OP:

1)

[...] the open parameters on forum.stake.com is leaking the csrfKey [...]

2)

[...] I found a cashout flaw [...]

And as i already have mentioned:
Regarding 1), the token is not being "leaked". The client needs to know it.
Regarding 2), your so-called "cashout flaw" does not allow you to really cashout. You are just able to manipulate visual things client-side.

I leave the argument up to you.
Password is needed but protecting it and changing it from time to time is required same is with csrf token.
 Good day.