a guest Oct 30th, 2018 1,701 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
- MapleChange Bug
- MapleChange was originally constructed based off the open-source framework called Peatio. We originally forked off another fork called Graviex (https://github.com/gravio-net/graviex). Without proper inspection, the code seems pretty much the same with the exception of some improvements to the engine and stability. For comparison, take Peatio (https://github.com/peatio/peatio). The code shares many similarities.
- The Exploit:
- Upon further inspection, we have discovered one potential source for how the bug was caused. One must note, that it is not a single existent bug that caused this, but potentially a series of them caused by our upgrade on October 27. Where we have upgraded our entire source from Ruby 2.2.1 and Rails 4 to 2.5.1 and Rails 5 respectively. This in turn required massive rewrites to the code and enhancements such that it would be compatible with the new dependencies. We believe this is primarily one of the sources for the bug. Had this following function been properly monitored, it would've raised an error when one would go below negative balance and simply error out the entire order without continuing.
- See the following from function from Peatio, this is an example of how it should've been. (Line 72 in https://github.com/peatio/peatio/blob/master/app/models/account.rb)):
- The method `unlock_and_sub_funds` has proper conditionals, immediately raising exceptions if the sub amount goes below the balance of the user. In this case, even if the malformed/exploited order did get processed, it would stop here, properly throwing an error in our logs and allowing us to properly investigate. However, the perpetuators knew exactly how this code would run, and as a result abused it using a series of accounts, as you notice in order.rb (https://github.com/peatio/peatio/blob/6fe7e960a12c40053370cb25cdd0968b67041aa0/app/models/order.rb), the call `strike` both calls `hold_account.unlock_and_sub_funds` (removing funds from one account) and adding it onto `expect_account`. If properly executed, this exploit could continue to subtract funds from one account and add onto the other one with no limitations. This is primarily the cause of the bug.
- In our version of the code, we have noticed something strikingly bizarre. The conditionals in `account.rb`'s `unlock_and_sub_funds` were completely commented out. Considering our code is base off of Graviex, this is by far the best proof we can provide, the code hasn't been touched for months and we have done little to no work on the ordering system -> https://github.com/gravio-net/graviex/blob/master/app/models/account.rb (line 82).
- Source 2:
- The other possibility for this exploit would have to do with how the orders were forced into the order book without any restrictions. This may have been largely due to the fact we have upgraded the entire engine.
RAW Paste Data