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...
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-...
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.
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
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 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.
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.
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.
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
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.
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).
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!
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.
