Coinbase design allows for mass, targeted phishing of its users
blog.shubh.amThere's another bug when you can substitute coinbase's iframe with your own, when you use coinbase button. This iframe can ask for username / password, and there's no way for user to distinguish fake iframe from real. They also not into replying emails on their whitehat@ address.
>substitute coinbase's iframe with your own, when you use coinbase button
How would they go about fixing that? Verified by Visa is the same - you get redirected to some random domain "arcot.com"?. There's a verification code, but that's viewable by anyone that has your credit card (including the site operator where you just input your CC number).
Wouldn't Coinbase need to fully redirect to their own domain, or popup a window with the URL visible in order for users to know they're really dealing with Coinbase?
>Wouldn't Coinbase need to fully redirect to their own domain, or popup a window with the URL visible in order for users to know they're really dealing with Coinbase?
Yes, of course
I'm surprised that even homakov's emails are going unanswered.
+ there was another bug (or "feature") that allowed all access to all funds via API access key.
Sure, the user needs to allow the permissions first, but the warning where disproportionate to the power it gave away.
They've disabled this kind of access since though.
http://www.theverge.com/2014/2/7/5386222/a-string-of-thefts-...
That was an old trick used by Liberty Reserve scammers too who would social engineer you to activate the API then clean out your wallets.
Sounds more like a design decision. Do you have any suggestions besides not using iframes?
No, since there's no way to check iframe's domain I don't think it can be fixed for iframes.
They should stop asking for user's password right there, because it makes people trust any iframe
Maybe they can force login via their main site first. Lousier user experience though.
Lousy user experience is not being able to verify what site I'm about to enter my payment credentials into.
It would be a terrific experience if there was no reason to worry.
"Initially, Coinbase ignored me. My succession of emails to their official "whitehat@coinbase.com" domain were ignored until I posted that they weren't replying on reddit"
Deja vu, man.
The default state of every bug report ever is for the reporter to think they've found something that ends the world and the developer to think it's nothing to worry about at all. I've been on both sides and I've felt it.
Banks have entire security teams working around the clock and they work in an area where transactions are mostly reversible. When you work with Bitcoin nothing is reversible so you have to take things even more seriously than the banks.
Coinbase CEO here. You can see an updated response on this issue here for more information: https://hackerone.com/reports/5200
I apologize in advance for the following unsolicited advice, but if there's anything that should have been learned from the press after the Gox implosion, it's that you absolutely must stay ahead on security and the perception of security. If you don't, the entire cryptocurrency ecosystem ultimately suffers. You have a responsibility far beyond your active userbase to be responsive and professional, rather than dismissive, especially when a whitehat is just offering up auditing. There's no obvious downside to rate limiting some types of API requests, so why not simply be responsive and do it?
Any info on why emails to whitehat@coinbase.com are being ignored?
EDIT: For what it's worth, judging by the upvotes, a lot of people are hoping for any answer.
Because Coinbase has moved the program out of email and into here: https://hackerone.com/coinbase
What they could do is turn it into an autoresponder at least with a link to that inside.
Yep, that's on the way!
Meh, this is an extremely poor bug report despite the super-serious introductory tone. The "proof of concept" makes no sense. Quoting:
1. Scrape email addresses from bitcoin related websites, and organise them into a large list.
This has nothing to do with Coinbase.
2. Test for emails which are actual Coinbase accounts, and extract their First and Last names, associated to the emails.
Ok...
3. All sorts of panic happens.
Huh? How?
To prove "panic" he then leaps to a screenshot someone posted to Twitter of a money request email he generated. However,
a) It's not clear whether this was sent via the coinbase money request feature or whether it was spoofed (or why it would even need to be spoofed).
b) It doesn't even show usage of a firstname or lastname to "assist" in the spoofing.. which was the whole point of the bug report.
So it remains to be demonstrated how the exposure of firstname/lastname could be exploited to significantly assist phishing, especially when weighed against the other design tradeoffs -- like accidentally irreversibly sending money to the wrong person.
The lack of responsiveness to the whitehat email is the bigger problem here, but now that they've joined HackerOne perhaps that will improve.
The author does spend a LOT of effort writing stuff (and showing a silly gif) to basically say "requests aren't rate limited, can disclose existence of user and full name if email is known".
Coinbase responded to him on the 25th[1]:
"We've spent some time considering the implications of this behavior and have built this intentionally. The benefits to obscuring this information is minimal and, in our opinion, not worth the additional friction alternative flows would introduce"
Anyone can signup on Coinbase, right? So even if they did add some rate limiting, unless it was severe (or required a verified account), attackers would just sign up for more accounts.
1: http://shubh.am/bugs/coinbase.htm
Edit: I also like this part of their response: "Furthermore, it's not necessary to use "Burp Suite Intruder" in the manner demonstrated here. The functionality is exposed more directly in an intentional fashion over our API"
The actual bug report is the technical section of my blog post:
http://blog.shubh.am/full-disclosure-coinbase-security/#tech...
You're reading the Proof of Concept, which is meant to be a practical demonstration of how once could use the bug to their advantage. I didn't document the proof of concept in detail, to ensure that others couldn't easily use the blog post as a guide to harvesting Coinbase emails.
If you want the full, technical bug report, please visit: http://shubh.am/bugs/coinbase.htm
The "full, technical" report doesn't offer any new information. It just shows how to get the firstname and lastname.
The PoC does not at all demonstrate how the alleged bug could be used by phishers to their advantage.. it doesn't even show usage of the firstname or lastname! That makes it incoherent.
I don't think you understand, the PoC is not supposed to be a PoC for phishing but rather a PoC for their lack of rate limiting [1] , and user enumeration. I have showed the first name and last name [2], but have accordingly blurred them out [3] as I felt it was only appropriate.
In the technical section, I demonstrate where the first and last name would show up in the response from Coinbase. If you still think it's unclear, let me know, as reporting is something I wish to improve critically.
I appreciate the response from the Bitcoin community and the semi-fix from Coinbase they wish to implement in the future (optional masking of names on coinbase). However, I do also hope that rate limiting is implemented in the future, as I still personally consider this insecure by design.
[1] : http://i.imgur.com/nauHivq.png
[2] : http://blog.shubh.am/full-disclosure-coinbase-security/#tech...
[3] : http://i.imgur.com/l84eOi6.png and http://i.imgur.com/SDlbtty.png
How would rate limiting really solve this though? Wouldn't it just result in needing to use a botnet/spend more time harvesting?
Assuming that this is still the easiest way to harvest email/name pairs for phishing, then it seems like the time it takes isn't really a factor in the outcome since it can be parallelized and is still easier than phishing alternatives. It seems like the real answer is just to have it return the same response no matter if there is an account or not.
Olaf from Coinbase here.
Ryan McGeehan of our security team has posted an official response at the bottom of this page:
Olaf, it would be helpful if your team posted an official response on the Coinbase site.
API rate limiting seems to be their best course of action, and it's disappointing that they're ignoring you.
Shouldn't they also stop letting the requester know whether the requested email address corresponds to a Coinbase user?
The reasonable use case for this seems to be that you'd send a request for payment as part of a payment processing system.
So, user is on your site wanting to buy something, selects "pay with coinbase", and you ask for their email, then send the payment request.
In that case, you'd want to know that the email isn't in Coinbase's system so you could tell the user that the request didn't work, and can they check their email address or try another form of payment.
A reasonable way to limit this would be % of attempts that fail. If you're using this call reasonably, then the ratio of success to fail calls should be in some reasonable range. If it's too high, either you've designed a very confusing interface for payment, or you are doing something fishy.
At a minimum, it would be nice if they just stopped providing users' full names when a request is valid. While it does increase someone's threat surface to have their e-mail address identified as a coin base user, it is even more problematic to link names to accounts and makes it easier to spear phish.
They addressed that here[1]. Sending invoices to lists of clients is specifically something they want to allow.
And anyways, an attacker could simply sign up for multiple accounts.
I don't think much of Coinbase technically (terrible execution in the past, use of MongoDB), but this breathless report is really overhyping an minor design decision on Coinbase's part.
I received a phishing email from the author. I guess he must have scraped my email address from a blog post I wrote about bitcoin and coinbase.
While I am glad he has made attempts to contact Coinbase, I felt like live execution of the attack was spammy, so my first instinct was the block the domain of the sender's email, which Coinbase passes through to me. In execution of his proof of concept, the author is likely badly ruining his spam score / sender score.
Hey, I'm the author of this blog post. I think you're mistaken, I didn't send any phishing emails to anyone. All the emails were sent through coinbase via their request money featurein which I am trying to get them to fix. All emails to you were from Coinbase legitimately and none of them are phishing for your credentials. The lack of rate limiting on the api which allows for money requests is hence very dangerous.
It wouldn't have been nearly as compelling without a live demonstration. I guess he felt it was worth the bad score.
This is obviously a serious issue. One way to mitigate it is to use email addresses that have specific purposes.
firstinitiallastname@gmail.com is my "public" email address that is used for friends and what not.
genericemail@gmail.com is the email address I use for many retail sites.
I then have an email address dedicated to each commonly used site (Amazon, Coinbase, etc).
I also have Google two-factor authentication turned on for each email.
Why so many accounts? You can use the "jsmith+coinbase@gmail.com" syntax to get a unique email address for each service. Two factor auth drastically frustrates an account hijack, so you're gaining almost nothing by separating them.
you're gaining almost nothing by separating them.
This isn't true at all. jsmith+coinbase@gmail.com can be easily guessed by someone doing a spearphishing attack, either directly against you or indirectly against you using a vendor. Read this to see a real world example:
http://www.wired.com/2012/08/apple-amazon-mat-honan-hacking/
If the person who was hacked in that article had a unique email address at Amazon like mnmnmnmnmnmnmn696969696969@gmail.com then the attacker wouldn't have had any place to start the conversation with Amazon over the phone. Security by obscurity isn't perfect, but in many cases it does put up enough roadblocks to make someone give up.
If you use your technique, someone can also send you a spearphishing email purporting to come from any vendor that might fool you. On the other hand, if you get an email from Amazon to your Coinbase account it will be readily apparent it's fake.
Same logic applies, "jsmith+mnmnmnmnmnmnmn696969696969@gmail.com" then. Add a filter to discard email to that address unless it's from Coinbase. Done.
I gave up on that long ago because few sites actually allow the foo+bar@email.com syntax. + seems to be disallowed by most regex filters.
Apparently these names and email addressed have been gathered:
Source:
http://www.reddit.com/r/Bitcoin/comments/21wx59/coinbase_ema...
Nice article. Coinbase should be paying you for your service!
Oops, pressed downvote accidentally. (HN really needs a way to reverse votes, or at least further separation between arrow buttons)
On the screenshow of Humayun Khan's tweet it says "Click here to create an account". Does this mean that every email address that's not signed up with Coinbase yet will also get an email?
I think this is by design. If the email address is not associated with a registered coin base account, you get a link to sign up and receive money.
The email content copy should include a footer with a link to get out of receiving such emails. Since they are sending emails to "unverified" email address there is a good chance they get marked as spam by recipients there by damaging their email sender reputation.
Ever so slight mitigation of this is that Coinbase uses SPF, but they use SPF with a fairly open list (just phish via Amazon SES, Mailgun, etc.). So phishing mail has some chance of getting marked down as spam by recipients if you make it appear to be from coinbase.com.
I'd probably go all-out and send from coinbasemail.com though.
To phish via SES, you'd have to get coinbase.com as a verified domain, which mean you'd need DNS access. I assume the same is true of other email providers.
Divulging a name when presented with an email address is pretty bad and I'm not sure why it would be necessary.
Just confirming that an email address is in the system is fairly minor.
Official Coinbase response to sharing your personal details with the internet: Email Address / User enumeration on Coinbase: We've spent a good amount of time investigating this behavior and we believe that the risks are incredibly minor.
Gee, that's just what I look for in a financial service provider! This is the natural, uncontrolled result of Silicon Valley startup culture meets financial services. It's hard to get everything right, all the time, but particularly when operating in a financial domain it seems companies are better off accepting the severity of security issues and rewarding and engaging people who have taken the time to raise them than creating PR problems by demonstrating a lack of professionalism through suggesting that customer information (name, email, fact they use your service) is of no consequence and that enumeration issues are invalid.
Clearly:
(1) most users care about their privacy and time (ie. the sanctity of their inbox);
(2) the issue has been misevaluated by Coinbase; and
(3) the poster has been extremely patient and deserves an apology.
(Disclaimer: I, too, grew up in Sydney and spent my younger years doing security research. I work at one of Coinbase's competitors, Payward, operator of the Kraken exchange. We have an extremely successful bounty program that frequently pays out for all sorts of little issues. We consider this a requirement for security-conscious operation on the modern internet. After all, security is a process! Should security researchers choose to dedicate some of their valuable time to helping us improve our systems, I can promise them - at the bare minimum - a friendlier and less dismissive response.)
Coinbase says the name is optional, so only people that chose to share their name are affected.
They didn't "choose to share their name". They just typed it into the form and there was no evidence that what is normally kept private was going to be divulged.
As someone who studies human nature I'd like to ask this question of the OP and anyone else who cares to answer. I'd seriously like to know this.
Why do people spend extensive time [1] documenting security flaws like this [2] and going to the trouble of informing the company. And then if that doesn't work take more time to write up a blog post to get the info out?
What do they gain by doing so exactly? Is this a play for internet notoriety? Or a way to gain attention that results in future fame that leads to something later?
Or, is it as simple as it just makes them feel good (like "hey why do you play poker") or is it they believe they are making the world a better place?
[1] Because this took considerable time.
[2] Yes I know the OP indicates he is a "Information Security Enthusiast".
There's no one-size-fits-all answer to your question just as there isn't to questions like why someone wants to be a programmer, or a startup founder. The micro-motivations of individuals doing this sort of work can be all over the map from person to person.
But as someone who very occasionally does such things (but isn't looking to "make a name" for myself as a security researcher, which is often a motivation):
1) The initial motivation isn't so much about documenting security flaws, but finding them in the first place. It is a very hands-on immediate-results-oriented type of problem solving where you look at a system that is intended (or should be intended, based on what it is doing) to be secure and find ways in which the security is lacking.
2) From there, informing the company is just about being a decent net citizen. If you can work around their security from the outside, other (potentially more nefarious) people can too, and in most cases the company simply doesn't realize they have a security problem, so informing them is good for everyone.
3) From there, if they refuse to fix the problem and it is very legitimately a security issue, responsible full disclosure (with a solid window of not talking about the bug publically, I go with Google's 60-day window as a guideline) is about being a decent net citizen toward the product's users (if not the product's company). If they have gaping security flaws in their product that they won't fix, users who could and likely will get screwed by them deserve to know so they can make an informed decision as to whether the company they are using is adequately protecting their interests.
But as I said, everyone is different, for some people they are mostly resume building a collection of public CVEs on their way to a security research position, for me it is just a fun very occasional hobby and I've not publicly disclosed a gaping security flaw since the mid-1990s because most companies will do the right thing in fixing real security issues if poked a bit these days.
"informing the company is just about being a decent net citizen."
With respect to this would you say that there is a bit of a buzz when the company acknowledges and pats you on that back and says "hey thanks good job" (like your elementary school teacher?).
So taking this one step further I would say if that is the case then it becomes a big motivating factor, especially if the reinforcement is intermittent. Because you are searching for the next hit of approval.
Agree? Or?
He's just upset there was no reward given to him and is blowing this thing out of proportion.
Demonstrates expertise in a particular domain. It's a good exercise to improve one's skills and a good opportunity to provide evidence of one's skills. No one knows what you're good at unless you tell them.
I am curious why Coinbase is not rate limiting that API call (temp-fix) or addressing this yet (even privately)?
Granted it is not a critical flaw, but is having no limits over time really necessary for Coinbase API users?
What do rate limit by? There's billions of IP addresses a spammer could use, captchas can be solved by offshore farms, there's almost nothing to go by.
The call is made on behalf of an user account using an API key. You could rate limit by either one and/or both.
Nothing really stopping somebody automating the creation of those either when you're up against people with ridiculous amounts of cost-free (read, botnet) resources to spam with. The Bitcoin reddit gets flooded with spam on an almost minutely basis despite reddits heavy rate limiting and captchas.
I agree a lot of this becomes cat and mouse game but rate limiting is necessary for the health of their system if not to counter same basic spam prevention. Ideally you want to remove the incentive to spam, which in this case is figuring out emails that have registered coin base accounts that could later be phished.
User account.
Lots of small businesses are perfectly happy to lock out foreign IP addresses on the slightest breeze, and it's probably a good result because for those businesses 1000 out of 1000 requests from the Eastern Hemisphere are hostile.
Assuming malicious requests come from other countries would be foolhardy.
If you are saying "malicious requests only come from foreign countries" then of course that is silly.
But "for these businesses every connection from certain continents is an attack" is absolutely true.
I've worked with these businesses, worked with their CEO on their business needs, and seen their internet traffic. They, really, have absolutely no need to interact with Asia. They aren't hotshot SV companies trying to become the global leader of VR selfies, they are just boring[1] businesses sending plain old physical goods to customers within a thousand miles of them.
[1] Boring isn't a pejorative in my mind, but I know it is for some other people.
You can read some more information on our response here https://hackerone.com/reports/5200
Thanks for this! Perhaps an internal flag (to review) can be set when too many bounced emails come from a single api key?
I don't know if it's related or not, but their website is running horribly slow right now. Took me about five minutes to initiate a buy order, as most clicks were non-responsive or took ages to load.
I didn't see any suggestion from the author, did I miss it?
Don't allow users to determine whether an email address is registered in your system. (Even if they click "forgot password" or "send money request").
More importantly, don't ever give the user the full name of someone whose email address they pulled out of thin air!
Seems viable, and if you had previous "relationship"/transaction with this user you can display name etc.
- Rate limit API requests (flag / suspend if there are too many request for money requests from the same user) - Don't disclose which email addresses is registered/not registered with coinbase (right now they even go a bit further and actually disclose first and last names in the response).