Seems like Coinbase Security Team doesn't know how their cookie works

[giulio () anche no]

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/