There'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?
"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"
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.
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?
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.
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"
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.
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.
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.
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.
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.
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:
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
- 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).
