Topic: Monero dice seed hacked? (Read 4159 times)

Custom API, so I don't think this affects anyone else. We've disabled betting in the meantime whilst we sort this out, but I really think the lesson to other operators is not to be overconfident in your code or in your setup. Everything can and will be compromised, so assume it's going to happen and put safeguards in place to handle that eventual scenario.

Yeah, that's how it sounds like. Actually when I designed the moneypot investment system, what I did was create a repayable log of all the investment/divestment/bet events for in a nightmare situation like this (or software bug) it could be replayed so investors wouldn't have made/lost money from the changes in the bankroll when a fake better (or software bug) was playing.

The situation is probably a big mess now, as some investors have lost more than they should've and others made more than they should've. And it's probably pretty likely the ones who unfairly made money have already withdrawn (?) or at the very least, will be unhappy if their balance gets put to the correct amount

We found the bug he exploited that leaked the seed, and we've subsequently patched it.

We made a decision on how to handle it at the time, under pressure, to the best of our ability. You are welcome to disagree with that decision, but unless you're in that scenario running your own site your opinion is largely meaningless. It's easy to look at it after the fact and go "well I would have done X" - I can think of any one of 30 different ways we could have handled things.


So then you cut your losses and you get out, the end. There is no coming back later on to try reclaim imagined profit.

Perhaps a comparison will help: let's say that you have 10 BTC in Poloniex. You hear that Poloniex isn't processing BTC withdrawals, along with panic that they're hacked, and use your BTC to buy a bunch of WaffleCoin and withdraw it. You sell your WaffleCoin on ShapeShift, but now the market's tanked and you end up with 9 BTC. Later that day Poloniex put out a statement apologising for the issues and stating that they're now fixed. Would you insist that they roll the trades back? What about the shorters that took profit from you?

Or what if you invested in a startup, and then when it looked like things were going south you sold your investment at a loss. Two years later the startup is a huge, successful company. Do you insist on taking profit from the growth because you *used to be* an investor?


We thought about this, but we decided that it would be too dangerous for us to spend days and weeks trying to build a magical "undo" script, completely wrecking any auditability, and potentially ending up with a screwed up data set at the end.


With all respect to the affected investor, he took his $100 loss and walked away. He didn't contact us, he didn't ask for input on how we were going to handle things. He just assumed that it was the end, and he would have been the *only* investor to get out with his money had we not had safeguards and had the attacker been able to actually drain the wallet. What would have happened then?

You stated at the outset that you understand that the situation would have been different had the attacker managed to withdraw, but you're not actually following that thought through. Had that played out we'd have a total loss on the part of all the investors, and one investor who only incurred a $100 loss, and you can bet that investor wouldn't volunteer to divvy up his remaining funds among the affected investors.

Ultimately you're asking us to take up a morally hazardous position. What happens when someone "accidentally" places a large bet and loses? Should we undo their bet, and take the profits from the investors? An investor that divests and withdraws is no longer part of the bankroll. They bailed out with a profit or with a loss, and that's the end of that.

Nevertheless, I've already offered to send $100 to the affected investor, so I'm not sure what more you expect?

Custom API, so I don't think this affects anyone else. We've disabled betting in the meantime whilst we sort this out, but I really think the lesson to other operators is not to be overconfident in your code or in your setup. Everything can and will be compromised, so assume it's going to happen and put safeguards in place to handle that eventual scenario.

Why do you even care ? If he is clever and can hack then shame for you. He found a way into the system so good for him. Ga!nbling sites mostly bitch so its good to see someone got them back.

Look at the bets, look at the bet sizings, looks at the results of the bets and the sizings together. If you cant see it let me know so I can face palm.

Looks like its just a bug not a hack because the gambler is gamble in normal until the 3 result  from nearly end are bug..
It is a large amount of monero if this is true and i think they should contact the support and maybe they give some rewards to say that than withdrawing it because like other said its manually withdrawal..

Yeah, that's how it sounds like. Actually when I designed the moneypot investment system, what I did was create a repayable log of all the investment/divestment/bet events for in a nightmare situation like this (or software bug) it could be replayed so investors wouldn't have made/lost money from the changes in the bankroll when a fake better (or software bug) was playing.

The situation is probably a big mess now, as some investors have lost more than they should've and others made more than they should've. And it's probably pretty likely the ones who unfairly made money have already withdrawn (?) or at the very least, will be unhappy if their balance gets put to the correct amount

So then you cut your losses and you get out, the end. There is no coming back later on to try reclaim imagined profit.

Perhaps a comparison will help: let's say that you have 10 BTC in Poloniex. You hear that Poloniex isn't processing BTC withdrawals, along with panic that they're hacked, and use your BTC to buy a bunch of WaffleCoin and withdraw it. You sell your WaffleCoin on ShapeShift, but now the market's tanked and you end up with 9 BTC. Later that day Poloniex put out a statement apologising for the issues and stating that they're now fixed. Would you insist that they roll the trades back? What about the shorters that took profit from you?

Or what if you invested in a startup, and then when it looked like things were going south you sold your investment at a loss. Two years later the startup is a huge, successful company. Do you insist on taking profit from the growth because you *used to be* an investor?
-snip-
We thought about this, but we decided that it would be too dangerous for us to spend days and weeks trying to build a magical "undo" script, completely wrecking any auditability, and potentially ending up with a screwed up data set at the end.
-snip-
With all respect to the affected investor, he took his $100 loss and walked away. He didn't contact us, he didn't ask for input on how we were going to handle things. He just assumed that it was the end, and he would have been the *only* investor to get out with his money had we not had safeguards and had the attacker been able to actually drain the wallet. What would have happened then?

Looks like they managed to grab the server seed through a leak in the API - we're busy patching it, and will rollback the naughty bets. Thankfully we process every single withdrawal manually, and most of the funds are all locked up in a cold wallet, so no money was lost. It's precisely because of the very high risk of an exploit that we don't let withdrawals process automatically!

Nevertheless, I've already offered to send $100 to the affected investor, so I'm not sure what more you expect?

...
Am I the only one who thinks this is just unacceptable?

Exactly, see http://martinfowler.com/eaaDev/EventSourcing.html

Note that even if you don't follow strict event sourcing best practices you should still have a log of everything anyway so that you can replay, just takes more effort. Surely each bet/invest/divest actoin must have a timestamp on his MySql rows?

It's entirely possible, but one of the Monero Research Lab wrote a paper (for fun) a year ago establishing a way to analyse whether someone is cheating by determining whether they are massively changing the deviation of the site.

We run this analysis in the back all the time, so if someone was consistently cheating, even if they were using multiple accounts and small amounts, we'd see it show up because the site would (statistically speaking) be far out of the expected variance.

You can read the paper here: https://lab.getmonero.org/pubs/MRL_Monte_Carlo_Edition.pdf

::sigh::

That's not what a replayable log is, at all. A replayable log is logging all the individual events (e.g. bets, investments and divestments), in such a way that if you found a mistake had occurred (or in this case, fraud) you could fix the mistake (in this case, delete the bets) then replay everything so the investors balance is exactly is if the fraud never occurred in the first place.

It's actually just a good practice to be in, when ever I mutate state I *always* store the cause of it. (e.g. if someone transfers money, I log an event of the transfer. If someone claims the faucet, I store the details of that, if someone invests I store a record of it (and things like how much the bankroll was before they invested) etc).

And probably the other mistake people make, is over-constraining their database to not allow negative values. e.g. While a user balance never should be negative, the system should support it as cases like this might cause some accounts to legitimately be negative (them withdrawing gains they shouldn't have) or even deposits reverting after a blockchain reorg etc.

It's great for a disaster recovery situation like this, and it's great from an audibility perspective

We already have a replayable log (that's the point of the MySQL log after all), but we couldn't rewind the entire system. Consider, for instance, a new user that created an account and deposited funds. If we roll the system state back we would have to manually allocate all of those and manually recreate the users. And, too, consider the exact issue we've got above, where a user divested and withdrew - how do you roll that back? You can't, so you have to move forward with the system in the current state.