Serious Security Issues

  • There are some serious security issues... I and Aztrix found these issues with very little digging...
    There might be more security-related issues on the site..
    But I will show the ones we found

    alt text
    For some weird reason the recaptcha key and the front-end developers username and password are available to the public with simple network logging in google chrome...........

    alt text
    I also found that the server seed HASH's SALT is public...
    With this, I can literally crack the server-seed and predict my rolls beforehand.... but would require a ton of power

    Dear @anil5638 @goldenberg21 @DEV-TEAM please make sure all your data is encrypted before being sent to the user...

    P.S. Note: All this information can be used for wrong but I love this site.... that's why I am informing you guys

    If there's a bounty... I would love to receive it

  • @skrpopbop

    To clarify what Skrpopbop has stated (my role in the situation);

    The data was "stumbled apon" by accident, whilst troubleshooting lag and network issues using the Chrome Console tool kit made freely available to anybody using chrome (or firefox for that matter). I was targeting network traffic during Dice rolling on Casino Royale to determine if it was contributing to the lag as rolls seemed to "choke" the longer i left autoroll running.

    For the most part, no attempt was made to specifically data mine for private information or credentials, and no attempt was made to reverse engineer, decode or decrypt any part of the site or its code. After little effort plain text unencrypted private data relating to Dev credentials was found, prompting investigation to check if personal credentials were being transmitted in a manner that would breach privacy laws or open a door for account hacking, theft or similar. I can say that users personal information, aside from user name, email etc, is not transmitted in the same manner and seems to be transmitted using industry best practice at the time of viewing.

    The data Skrpopbop is referring to needs to be view and addressed as a matter or urgency, although the "front-end" username and password are for an instance accessible on "LocalHost" only, without going into detail, the credentials could still be abused and serious attempts could be made to use them. Of most concern, the credentials are plain text and require little effort to find.

    In regards to Skrpopbop's reference to "Server Seed Hash Salt", the only type listed in plain text is the "PreviousServerSeed" which is freely published in the "Fairness" window on Casino Royale. The "CurrentServerSeed..." is only listed in its hashed SHA512 and MACK forms, also both freely available on the "Fairness" window. Furthermore, despite claims that the Hash could be cracked, yes it could be brute forced however to successfully "crack" a hash, one must have a solid understanding of bloom fields, rainbow tables and a bucket load of processing power. then and only then would it be viable to spend (potentially depending on your luck) the next 1000+ years trying to bruteforce the SHA512 Hash. I can give you a head start by telling you the Server Seed, like the default Client Seed, is in the format of a UUID Version 4. this is something the Devs may want to address since it is easily identified by the user.

    On another note, in the spirit of keeping the site "Provably Fair", DEVS can you separate Server Seed randomization from Client Seed Update/Randomization please. At the current time Server Seed is "Randomized" after Client Seed, allowing for potential to manipulate the Server Seed, as the Client Seed would be known by the system before Server Seed is "Randomized". If the two events are treated independently, users can keep a chosen Client Seed and only randomize the Server Seed or visa versa. Additionally, in my opinion, this change would bring about more transparency and support the sites/admins claims that Casino Royale is in fact "Provably Fair". The change does not introduce any new security issues nor does it create a situation that would allow manipulation by either party.


    Edited to remove unnecessary text. Az

  • This is a big problem.

  • I'm assuming since nobody has made any attempt at contacting me, that Devs are hard at work fixing the concerns outlined above. If screenshots or instructions are required to locate the data of concern im happy to retrace the steps to get it all for you. On that note, i would be worried if the Devs, those who wrote the site scripts, didnt know where to find it. But stranger things have happened.

    Happy to help or provide further details, preferably in private conversation rather than in public however.


  • administrators

    @skrpopbop when do not know , do not write. these keys are intended to be public.

  • @dev-team why? public

  • administrators

    @skrpopbop u can read documentation here: link text, but it is bound to domain