Account hijacking on MtGox | Hacker News Reader

Account hijacking on MtGox

homakov.blogspot.com

117 pointshomakov37 comments

Gox uses a special 3FA where it takes 6+weeks to get anything out of that exchange. See 144 page bitcointalk thread 'Mtgox delays [gathering]'.

6+ months, actually. Still waiting on one transfer.

So the higher price on Gox isn't worth trusting them to actually complete their transfers within their claimed 6week window? How much was the transfer for?

I guess it's better to use some other exchange for selling if Gox is taking 6 months to process some transfers...

The higher price is because of all the USD trapped in the exchange

I'm not sure whether Egor Homakov received a reward for reporting this to Mt.Gox which he clearly deserves. However we have contacted to Mt.Gox to understand if they would be launching a vulnerability reward program and the response we got is that they would launch one during Q1 2014. Read more at our blog about it. https://blog.crowdcurity.com/how-to-measure-the-security-of-...

No rewards

Is there a quality bitcoin bounty reward program for vulnerabilities?

dont know if you are interested but bex.io is hiring for security engineers/auditors, and most of their employees are remote. Since these guys puport to be a cookie-cutter template for running your own bitcoin exchange I'm sure they will need you. https://angel.co/jobs?slug=bex-io

lol, this guy is a legend around here. If he wanted a job, he'd have it.

You have no idea who this fellow is, right !?!

Given his street cred, I doubt he needs any help looking or finding the work he'd like to do and totally do so on his and his terms alone!

Nobody hires egor in fact. Not wow.

I always thought you would get a lot of work via HN people. It surprises me but I don't find it hard to believe. Why it doesn't surprise me is because security and pen testing work is as much about sales, marketing and presentation - perhaps more than skill.

Some of the best security guys I know find it hard to pitch their services, so they end up working low-end generic programming or sysadmin jobs. I've tried to get more and more of them involved in my work (I do contract pen testing while also doing my own sec startup at the moment) by including them in proposals I write up, works out well. I messaged you on twitter.

That's a shame. What is your bitcoin address which we, and the rest of the community, could tip to?

just homakov@gmail.com on coinbase

Ok, just transferred $100 to your coinbase account. Since this was transferred directly to your mail within coinbase, the transaction does not get included in the blockchain. Let me know if you didn't received them. Best Jacob, CrowdCurity.

Wow, Thanks!

that's sad bro, you deserved a really fair gift for that discovery. I mean others (could've) used it. We need more people who report security issues and go public, if nobody listens.

Would 2 factor auth even fix this? If you are hijacking the session ID, the user has already authenticated.

Depends how 2FA is used. If on per/action basis it could save (you know the SID but don't know the OTP/token)

MtGox requires a new 2FA code for pretty much every action you can take (buy/sell/withdraw)

In addition to login, 2FA is typically required for irreversible and other sensitive operations like transfers, for exactly this reason (local malware, XSS, etc, can steal cookies)

This should be pretty much required for all services where users may have significant amounts of money at stake. And users need to be educated to actually enable it.

Coinbase finally enabled 2FA for transfers (of more than $100/day) this week: http://blog.coinbase.com/post/73364231652/security-updates-o...

Looks like Coinbase 2FA is crap

http://www.reddit.com/r/Bitcoin/comments/1vjr7b/please_advis...

This happened the day Coinbase enabled 2FA on transactions, so it's hard to say whether it was before or after it was enabled.

I wrote a little blog article on how to store the majority of your bitcoin using a security-enhanced brainwallet. Part of the argument is that exchanges and online wallets are and will continue to be magnets for good XSS/CSRF attacks. Mt.Gox/Coinbase Engineers are fighting a difficult fight against well-incentivized enemies.

http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne...

While your WarpWallet is a nice initiative, it doesn't meet the 5th demand of a storage system; immune to physical coercion.

I'll just leave this here; https://xkcd.com/538/

That's not a totally fair analogy. The adversary in this case shouldn't even know you have bitcoin or a WarpWallet; so why would they bother to torture it out of you in the first place?

Edit: but I guess I agree, it would be a nice feature to have that we didn't think much about. I wonder what a solution would even look like.

IIRC, Julian Assange worked on torture resistant passwords: users memorize a maze that they would have trouble doing under duress.

Ive been thinking about how to implement a dead mans switch for passwords or private keys. A remote server that is synced with your local login and will change the password to something random every x hours unless you 'check in'. If you do check in, your password works, if you dont check in because you are being held or have had your phone taken away from you then it will change it to something random.

Problems to solve at the moment are the security of the remote server, recovery after you let go of the switch and how ti implement the sync (instead of a remote connection, something like a shared secret used as a generation seed, like RSA tokens, that only needs to be synced once).

I like that. I think there's a market for key combinations, passwords or even facial recognition to say "I've been compromised, scramble everything"

Yeah the issue is in recovery. As a general rule, when I've attempted to implement something like this, I run into the issue of "if I can recover, they can force me to" :( would be seriously interested in a solution if you come up with one!

I just submitted this to HN expecting to be taken to the most recent submission of it, but was surprised to discover it hasn't ever been submitted. Sorry. https://news.ycombinator.com/item?id=7083393

These are such an incredible opportunity for learning. I've been reading Egor's blog for a while now, and it just gets better and better, and I think the writing is getting much easier to follow as well.

But I do wish someone would start writing a "super-verbose-homakov.blogspot.com". I can see the magic, but I'd love just a bit more hand-holding, and discussion about detecting your own versions of these types of bugs, and proper layers of mitigation.

0) The 'name=...' payload...

- is the 'SID' literal, or is that replaced by a real session id? (see below) - the https:// url, assume that came from MtGox when creating the payment button? - 'payment[cancel]=cancel' : assume egor had to figure out to put that there? how did he figure that out? what is happening by putting that there?

1) Setting cancel URL to javascript:eval(name)

- so do you fix this exploit by blacklisting this kind of cancel URL? - would a blacklist even work reliably? - can you protect window.name anyhow? - just like innerText prevents XSS for display strings, is there an equivalent we can use for URLs to know they are inert?

2) Put your payload in window.name and redirect to..

- if I google "window.name xss payload" there are plenty of links - like this gem from 2008: https://bugzilla.mozilla.org/show_bug.cgi?id=444222 - I can understand this technique could work in an iframe, how does this work across a redirect? - does it matter how exactly the redirect is triggered?

3) User is supposed to wait 5 seconds..

- I have no idea what this is telling me, is this some MtGox implementation quirk? - Maybe user is checking out from attacker's site using the payment button and this is a timeout during checkout?

4a) Get some guest SID with server side...

- server side, as in server hosting the page with the checkout button? - the point here is you need a valid SID to insert into the payload in place of 'SID'? - assume you have to keep it valid, fixating to an expired session is useless, right? - if mtgox doesn't allow a session to float between ip/user-agent, it's not perfect (e.g. Wi-fi hotspot, spoof agent of victim) so is it worth storing that data with your session IDs and expiring if it ever doesn't match?

4b) our cookie shadows original SESSION_ID because more specific Path-s are sent first

- "shadows" is a great way to describe this, like that term! - does fixation always use shadowing? can you fixate with other techniques? - does shadowing always mean multiple copies of the same cookie are sent? - should servers be looking for unexpected duplicate cookies sent from the client in each request? - if the cookie also had a signature (server-side HMAC, secret key), would that definitely prevent shadowing?

5) Close the window.

- Huh?

6a) Someday user logs in

- Logs into what, Gox? - They have to come from your malicious page, right, for window.name payload to be there? - So should this say, someday user tries to buy your alpaca socks?

6b) Your server script should run cron task every 5 minutes, checking if SID is still "guest"

- in other words, checking with the fixated SID if mtGox thinks you are logged in? - also probably updating your window.name payload as session times out and such?

7) Describe how mt.gox fixed it and how you would have fixed it?

Another thought, if the victim was already logged into Gox when they click your checkout button, their cookie is changing to your guest SID, so they get logged out. Probably only 1 in 1000 would even raise an eyebrow though.

Oh, signing doesn't matter because of course attacker is grabbing a perfectly valid and signed cookie from you in the first place.

They don't have to login from your malicious page, your malicious page plants your fake cookie only. The important part is that your browser sends your cookie, instead of the proper one, because it has a more specific path. When the user logs in, they login on your session.

A fix would probably be checking cookies more carefully, ensuring the value and path components are what they should be. You could also assign a new session id when a user logs in, so there is no chance of a polluted session.

Is the real reason bitcoin prices are so high that people can't get any real money out of the system?

That's the reason they are so much higher on MtGox than other exchanges (roughly $150/btc higher).

homakov, I'm a fan. Some day, we'll hire you to do security consulting for our products.

You're welcome :)

Reply on news.ycombinator.com