mailing list archives
Seems like Coinbase Security Team doesn't know how their cookie works
From: giulio () anche no
Date: Fri, 29 Nov 2013 16:24:09 +0000
During last summer i wrote them a report with the following content. I
was not expecting a reward because my poc could work only in Man In The
Middle scenarios and only under certain circumstances, but at least i
was expecting a good reply and a fix.
Here is what i wrote them
i do not know if this type of vulnerability may qualify for your bug
bounty but it's in someway exploitable and it was funny to think on.
Firstly please excuse me if i'm not so clear as you may hope because
english is not my native language.
This proof of concept works in a scenario where a malicious attacker
perform a man in the middle attack on the victim (like a public
university network etc.).
Here is an example of attack:
1) Attacker visit conibase.com and grab a normal session cookie
(_coinbase_session), which is base64 encoded and contains both a
'session_id' and a '_csrf_token' values.
2) Attacker start a webserver on localhost which set the cookie grabbed
before for coinbase.com domain.
3) Attacker start DNS poisoning trough ARP spoofing on the victim
coinbase.com to his own box.
4) Attacker start a code injection trough ARP spoofing and inject an
hidden iframe that point to coinbase.com which now resolve to his box.
5) The victim visits any random non-SSL website and the
is set by the attacker.
6) As soon as the victim visit a non-SSL website at least one time the
attacker stops DNS Spoofing and point coinbase.com to its original
7) The victim logs in (or logs in again if he was previously logged).
8) The attacker can now inject perfectly crafted post or get requests
using the csrf_token he previously set for the victim.
9) As soon as the victim visit a random non-SSL website and is still
logged in the attacker can perfom the actions he wants on his account.
The advantage is a sort of 'SSL bypass' since the user in theory has no
why to defend or notice this attack.
I know and understand that is really tricky to do but i worked on this
at least i wanted to share it :)
0A simple fix would just be to regenerate the csrf_token once the user
in but i'm sure you'll find a better why.
The only thing that i didn't mention here is that they have an HSTS
policy so this may have worked only with users with haven't visit
coinbase with the browser they're using before.
I got this response
Thank you for the disclosure, we appreciate it.
I have only looked at it briefly by now but doesn't the secure flag on
session cookie prevent from leaking the csrf token or any injection at
and replied with
I think that's not true.
Actually the point is that we are impersonating the domain in order to
an already known _coinbase_session.
It is possible to set cookie with 'secure' flag trough HTTP while as
said is not obviously possible to read it, but since we're defining it
already know it.
I hope now is more clear.
and how would you get around the browsers cert warning if you mitm
spoof the domain?
Writing a script that detect when the user start browsing a non-SSL
website and when it returns true it starts dns spoofing and injecting
iframe which load http://coinbase.com, which set the cookie. As soon as
the user load the iframe at least one time the dns poisoning stops and
user shouldn't notice anything.
I'm actually writing a tool to automatize this process because most
So yes, if the victim browse only coinbase.com and do nothing else
login or before signing out this doesn't work but i think in most cases
this won't happen.
so what you are really saying is that the csrf token is shared among
and non secure cookie our app sets. because if the user browser
coinbase.com(http) it would not net the same cookie with the secure
flag like it does
when you get redirected to https
Actually i did not completely undertood that statement, probably because
of my english, anyway i replied with
Normally a session fixation consists in setting a known session cookie
the victim, so instead of trying to grab a valid sessions we simply
the user to validate the one we provided.
This can be achieved performing the dns spoofing attack i described
With coinbase it is a bit different because in the session cookie there
a 'session_token' value which is unknown until the user log in so a
session fixation won't work as expected.
Beside that the csrf_token remain the same so performing the session
fixation will make this known to the attacker too so he can craft valid
requests to inject in random non-ssl user traffic.
Then because problems with my mobile mail client i sent them this last
mail four times, anyway i got no response even when i tried contacting
them later or with different address.
How actually a _coinbase_session decode looks like:
While i don't see the point of saving the csrf token in a cookie i must
say that in every fucking programming book there is written that tokens
should be regenerated after logins.
Or maybe i am just crazy or there are some other factors i did not
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/
- Seems like Coinbase Security Team doesn't know how their cookie works giulio (Nov 30)