[abalone]

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.

[MichaelGG]

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"

https://hackerone.com/reports/5200

[infosec-au]

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

[abalone]

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.

[infosec-au]

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

[gaadd33]

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.