7 ms·

Account hijacking on MtGox

117 points by homakov 13y ago

jstanley 13y ago
Would 2 factor auth even fix this? If you are hijacking the session ID, the user has already authenticated.
- homakov 13y ago
  Depends how 2FA is used. If on per/action basis it could save (you know the SID but don't know the OTP/token)
  - mef 13y ago
    MtGox requires a new 2FA code for pretty much every action you can take (buy/sell/withdraw)
- tlrobinson 13y ago
  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-on-coinbase http://blog.coinbase.com/post/73364231652/security-updates-o...
  - ye 13y ago
    Looks like Coinbase 2FA is crap http://www.reddit.com/r/Bitcoin/comments/1vjr7b/please_advise_on_bitcoin_theft/ http://www.reddit.com/r/Bitcoin/comments/1vjr7b/please_advis...
    - tlrobinson 13y ago
      This happened the day Coinbase enabled 2FA on transactions, so it's hard to say whether it was before or after it was enabled.
jacobhansen 13y ago
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-a-bitcoin-application/ https://blog.crowdcurity.com/how-to-measure-the-security-of-...
- homakov 13y ago
  No rewards
  - becherovka 13y ago
    Is there a quality bitcoin bounty reward program for vulnerabilities?
  - dobbsbob 13y ago
    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 https://angel.co/jobs?slug=bex-io
    - 3pt14159 13y ago
      lol, this guy is a legend around here. If he wanted a job, he'd have it.
    - shiven 13y ago
      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!
      - homakov 13y ago
        Nobody hires egor in fact. Not wow.
dobbsbob 13y ago
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]'.
- jaggederest 13y ago
  6+ months, actually. Still waiting on one transfer.
  - sillysaurus2 13y ago
    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...
    - mwilcox 13y ago
      The higher price is because of all the USD trapped in the exchange
maxtaco 13y ago
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-stores-his-bitcoin/ http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne...
- cap2002 13y ago
  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/ https://xkcd.com/538/
  - maxtaco 13y ago
    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.
    - quantumpotato_ 13y ago
      IIRC, Julian Assange worked on torture resistant passwords: users memorize a maze that they would have trouble doing under duress.
      - nikcub 13y ago
        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).
malloreon 13y ago
Is the real reason bitcoin prices are so high that people can't get any real money out of the system?
- TheCoelacanth 13y ago
  That's the reason they are so much higher on MtGox than other exchanges (roughly $150/btc higher).
zaroth 13y ago
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:// 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 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.
anandvc 13y ago
homakov, I'm a fan. Some day, we'll hire you to do security consulting for our products.
- homakov 13y ago
  You're welcome :)

117 points by homakov 13y ago

jstanley 13y ago

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

homakov 13y ago
Depends how 2FA is used. If on per/action basis it could save (you know the SID but don't know the OTP/token)
- mef 13y ago
  MtGox requires a new 2FA code for pretty much every action you can take (buy/sell/withdraw)
tlrobinson 13y ago
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-on-coinbase http://blog.coinbase.com/post/73364231652/security-updates-o...
- ye 13y ago
  Looks like Coinbase 2FA is crap http://www.reddit.com/r/Bitcoin/comments/1vjr7b/please_advise_on_bitcoin_theft/ http://www.reddit.com/r/Bitcoin/comments/1vjr7b/please_advis...
  - tlrobinson 13y ago
    This happened the day Coinbase enabled 2FA on transactions, so it's hard to say whether it was before or after it was enabled.

jacobhansen 13y ago

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-a-bitcoin-application/ https://blog.crowdcurity.com/how-to-measure-the-security-of-...

homakov 13y ago
No rewards
- becherovka 13y ago
  Is there a quality bitcoin bounty reward program for vulnerabilities?
- dobbsbob 13y ago
  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 https://angel.co/jobs?slug=bex-io
  - 3pt14159 13y ago
    lol, this guy is a legend around here. If he wanted a job, he'd have it.
  - shiven 13y ago
    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!
    - homakov 13y ago
      Nobody hires egor in fact. Not wow.

dobbsbob 13y ago

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]'.

jaggederest 13y ago
6+ months, actually. Still waiting on one transfer.
- sillysaurus2 13y ago
  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...
  - mwilcox 13y ago
    The higher price is because of all the USD trapped in the exchange

maxtaco 13y ago

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-stores-his-bitcoin/ http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne...

cap2002 13y ago
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/ https://xkcd.com/538/
- maxtaco 13y ago
  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.
  - quantumpotato_ 13y ago
    IIRC, Julian Assange worked on torture resistant passwords: users memorize a maze that they would have trouble doing under duress.
    - nikcub 13y ago
      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).

malloreon 13y ago

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

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

zaroth 13y ago

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:// 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 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.

anandvc 13y ago

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

homakov 13y ago
You're welcome :)