lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
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