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: <de8c8e1d15dad72bc1a2300d0e4d08ac@anche.no> Date: Fri, 29 Nov 2013 16:24:09 +0000 From: giulio@...he.no To: full-disclosure@...ts.grok.org.uk Subject: Seems like Coinbase Security Team doesn't know how their cookie works 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