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?
Yes, of course
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-...
They should stop asking for user's password right there, because it makes people trust any iframe
Deja vu, man.
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.
EDIT: For what it's worth, judging by the upvotes, a lot of people are hoping for any answer.
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.
Ryan McGeehan of our security team has posted an official response at the bottom of this page:
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.
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.
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.
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.
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.
Source:
http://www.reddit.com/r/Bitcoin/comments/21wx59/coinbase_ema...
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.
I'd probably go all-out and send from coinbasemail.com though.
Just confirming that an email address is in the system is fairly 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.)
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".
Granted it is not a critical flaw, but is having no limits over time really necessary for Coinbase API users?
More importantly, don't ever give the user the full name of someone whose email address they pulled out of thin air!
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"
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 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.
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.
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?
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.
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
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.
