Home page logo
/

fulldisclosure logo Full Disclosure 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

Hi,
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 can perform a man in the middle attack on the victim (like a public hotspot, a
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 pointing
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 _coibase_session
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 server.

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 and
at least i wanted to share it :)

0A simple fix would just be to regenerate the csrf_token once the user logs
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 the session cookie prevent from leaking the csrf token or any injection at all.

kind regards,
[removed]


and replied with

Hi,
I think that's not true.
Actually the point is that we are impersonating the domain in order to set
an already known _coinbase_session.
It is possible to set cookie with 'secure' flag trough HTTP while as you said is not obviously possible to read it, but since we're defining it we
already know it.

I hope now is more clear.
Thank you.


They replied
interesting.

and how would you get around the browsers cert warning if you mitm arp/dns
spoof the domain?


Replies:

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 the
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 sites
seems vulnerable.
So yes, if the victim browse only coinbase.com and do nothing else before
login or before signing out this doesn't work but i think in most cases
this won't happen.


Their reply

so what you are really saying is that the csrf token is shared among secure
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 for the victim, so instead of trying to grab a valid sessions we simply force
the user to validate the one we provided.
This can be achieved performing the dns spoofing attack i described before. With coinbase it is a bit different because in the session cookie there is a 'session_token' value which is unknown until the user log in so a normal
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:
before login:

    session_id:"acedfa683d0d9aa4001c7ac6da40c09a";
    _csrf_token:"1NaNj4IXj+FVMJcEYimczqYrJNXejTh2x0E1Wgg5GyeE";

after login

    session_id:"acedfa683d0d9aa4001c7ac6da40c09a"
    _csrf_token:"1NaNj4IXj+FVMJcEYimczqYrJNXejTh2x0E1Wgg5GyeE"
session_token:"E72b357fa634f0849c9170d80320aba1230e4a2cdae50b7e3ef45ae2d0540968c";


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 considered?

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]