Message-ID: <CAH8yC8kucaVykXNoui3z9eUfZQcUskcgcV1dqzUgBiOKOD__Cw@mail.gmail.com>
Date: Sat, 30 Nov 2013 13:40:39 -0500
From: Jeffrey Walton <noloader@...il.com>
To: giulio@...he.no
Cc: Full Disclosure List <full-disclosure@...ts.grok.org.uk>
Subject: Re: Seems like Coinbase Security Team doesn't
 know how their cookie works

> 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?
Cookies don't completely remediate Injections and CSRF (as you can see).

You really only have two defenses: fix the injection or
re-authenticate the user during high value transactions. For the
later, challenge them with their password to ensure they initiated the
transaction.

Jeff

On Fri, Nov 29, 2013 at 11:24 AM,  <giulio@...he.no> wrote:
> 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/

Powered by blists - more mailing lists