
Account hijacking on MtGox - homakov
http://homakov.blogspot.com/2014/01/account-hijacking-on-mtgox.html?#
======
dobbsbob
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
6+ months, actually. Still waiting on one transfer.

~~~
sillysaurus2
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
The higher price is because of all the USD trapped in the exchange

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

~~~
homakov
No rewards

~~~
dobbsbob
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)

~~~
shiven
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
Nobody hires egor in fact. Not wow.

~~~
nikcub
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.

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

~~~
tlrobinson
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...](http://blog.coinbase.com/post/73364231652/security-updates-on-
coinbase)

~~~
ye
Looks like Coinbase 2FA is crap

[http://www.reddit.com/r/Bitcoin/comments/1vjr7b/please_advis...](http://www.reddit.com/r/Bitcoin/comments/1vjr7b/please_advise_on_bitcoin_theft/)

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

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

~~~
cap2002
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
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_
IIRC, Julian Assange worked on torture resistant passwords: users memorize a
maze that they would have trouble doing under duress.

~~~
nikcub
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).

~~~
girvo
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!

------
zaroth
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.

~~~
keeperofdakeys
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.

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

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

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

~~~
homakov
You're welcome :)

