Re: What happened with the session fixation bug?
James A. Donald wrote: | Adversary accesses web site as if about to log in, gets | a session ID. Then supplies false information to | someone else's browser, causes that browser on some one | else's computer to use that session ID. Someone else | logs in with hacker's session ID, and now the adversary | is logged in. An excellent plan and the reason sessions shouldn't be automatically given to every user of a site. In my experience though, sessions aren't created until the login button is pressed - the malicious user needs an existing account. This might then become a permissions escalation problem - emphasis on the might. Question: how does one convince the victim's browser to use the malicious ID? And if one can modify cookies on the browser for a remote site (what needs to be done in most cases), doesn't this raise much more serious questions about XSS? I think this is probably a low-impact issue unless sessions are used improperly. Then again, given some web apps I've seen, might be high impact :/. Regards, Michael Cordover -- http://mine.mjec.net/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: What happened with the session fixation bug?
-- James A. Donald wrote: Adversary accesses web site as if about to log in, gets a session ID. Then supplies false information to someone else's browser, causes that browser on some one else's computer to use that session ID. Someone else logs in with hacker's session ID, and now the adversary is logged in. Michael Cordover Question: how does one convince the victim's browser to use the malicious ID? Assuming we can intercept and modify cleartext, no problem. There are also several other ways that do not require such man in the middle attack, For example, the adversary might represent himself as selling some item for egold. The victim clicks on the egold link on the adversary's web page, but it is a session fixation link which looks something like this. a href=http://e-gold/index.php?PHPSESSID=64383-34324-9874 37 As a result, when the victim logs in to egold, logs in to the genuine e-gold. not a phishing site, he logs the adversary in. Adversary then drains all of user's account. (Assuming that e-gold is vulnerable to session fixation.) --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG /xB6pMv9fT1fIGlyhzRyAjdO+X1POcedv7maASR+ 4rXw3i2fw8a6eXIV31Rc11GLSM+BsAqwdlNX3AVVO - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: What happened with the session fixation bug?
James A. Donald wrote: -- James A. Donald: PKI was designed to defeat man in the middle attacks based on network sniffing, or DNS hijacking, which turned out to be less of a threat than expected. However, the session fixation bugs http://www.acros.si/papers/session_fixation.pdf make https and PKI worthless against such man in the middle attacks. Have these bugs been addressed? On 20 May 2005 at 23:21, Ben Laurie wrote: Do they exist? Certainly any session ID I've ever had a hand in has two properties that strongly resist session fixation: a) If a session ID arrives, it should already exist in the database. b) Session IDs include HMACs. The way to beat session fixation is to issue a privileged and impossible to predict session ID in response to a correct login. If, however, you grant privileges to a session ID on the basis of a successful login, which is in fact the usual practice, you are hosed. The normal programming model creates a session ID, then sets variables and flags associated with that session ID in response to forms submitted by the user. To prevent session fixation, you must create the session ID with unchangeable privileges from the moment of creation. Why? I suspect you are thinking of an attack other than session fixation. How does your attack work? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: What happened with the session fixation bug?
-- James A. Donald wrote: The way to beat session fixation is to issue a privileged and impossible to predict session ID in response to a correct login. If, however, you grant privileges to a session ID on the basis of a successful login, which is in fact the usual practice, you are hosed. The normal programming model creates a session ID, then sets variables and flags associated with that session ID in response to forms submitted by the user. To prevent session fixation, you must create the session ID with unchangeable privileges from the moment of creation. Ben Laurie wrote: How does your attack work? Your business about MACS and stuff was to prevent the adversary guessing the users session ID. With session fixation, the adversary does not try to guess the legitimate users session ID, instead he fools the browser of the legitimate user into using the adversary's session ID. Adversary accesses web site as if about to log in, gets a session ID. Then supplies false information to someone else's browser, causes that browser on some one else's computer to use that session ID. Someone else logs in with hacker's session ID, and now the adversary is logged in. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG fUQA7VMYJROi7AAUHD8ZmEHReDprBvrg3u3cL2VI 4NzEz9SAfaOzb7GhsAkM//vmMQKDsrdLEInHLumm3 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: What happened with the session fixation bug?
In message [EMAIL PROTECTED], James A. Donald writes: -- PKI was designed to defeat man in the middle attacks based on network sniffing, or DNS hijacking, which turned out to be less of a threat than expected. First, you mean the Web PKI, not PKI in general. The next part of this is circular reasoning. We don't see network sniffing for credit card numbers *because* we have SSL. Since many of the worm-spread pieces of spyware incorporate sniffers, I'd say that part of the threat model is correct. As for DNS hijacking -- that's what's behind pharming attacks. In other words, it's a real threat, too. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: What happened with the session fixation bug?
James A. Donald wrote: PKI was designed to defeat man in the middle attacks based on network sniffing, or DNS hijacking, which turned out to be less of a threat than expected. asymmetric cryptography has a pair of keys ... the other of the key-pair decodes what has been encoding by one of them. a business process was defined using this technology where one of the key-pair is designated as public ... and freely distributed and the other of the key-pair is designated as confidential and never divulaged. an authentication business process was defined using public/private business process called digital signature where a hash of a message is taken and encoded with the private key. the recipient can recompute the hash of the received message and compare it to the digital signature that has been decoded with the corresponding public key. this catches whether the message has been altered and from 3-factor authentication http://www.garlic.com/~lynn/subpubkey.html#3factor * something you have * something you know * something you are implies something you have authentication ... i.e. the originator has access and use of the corresponding private key. PKI was somewhat targeted at the offline email model of the early 80s; the relying party dials up their (electronic) post office, exchanges email, and hangs up. They then may be dealing with first time correspondance from a total stranger with no (offline or online) recourse for determining information about the sender. Relying parties could be seeded with trusted public key repository of trusted third party certification authorities. Stangers could be issued certificates (digitally signed by one of these certification authorities) containing informoation about themselves bound to their public key. Email recipients in the offline email days of the early 80s ... could now of source of information regarding first time communication from total strangers (sort of the letters of credit model from the sailing ship days). we were asked to work this small client/server startup in menlo park http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 that wanted to do payments on something they called a commerce server. In the year we worked with them ... they moved from menlo park to mountain view and changed their name (trivia question ... who previously had the rights to their new name? also what large corporate entity was providing most of the funding for the commerce sever?). some topic drift ... recent postings referencing this original e-commerce work as an example of service oriented architecture (SOA): http://www.garlic.com/~lynn/2005i.html#42 http://www.garlic.com/~lynn/2005i.html#43 they had this technology called SSL which was configured at addressing two issues: a) is the webserver that the user had indicated to the browser ... the actual webserver the browser was talking to and b) encryption of the transmitted information. SSL digital certificates would be issued http://www.garlic.com/~lynn/subpubkey.html#sslcert which would contain the domain name of the webserver bound to their public key. the browsers would have trusted public key repository seeded with the public keys of some number of trusted third party certification authorities. the browser SSL process would compare the domain name indicated by the user to the domain name in the digital certificate (after validating the certificate). (at least) two (other) kinds of vulnerabilities/exploits have shown up. 1) in the name of convenience, the browsers have significantly obfuscated the certificate operation from the end-user. attackers have devised ways for the end-users to indicate incorrect webservers ... which the browser SSL process (if it is even invoked) will then gladly validate as the webserver the user indicated. 2) a perceived issue (with knowing that the webserver that a browser is talking to is the webserver the user indicated) were integrity issues in the domain name infrastructure. however, as part of doing this consulting with this small client/server startup ... we also had to do detailed end-to-end business process due dilligence on some number of these certification authorities. it turns out that a certification authority typically has to check with the authoritative agency for the information they are certifying. the authoritative agency for domain name ownership is the domain name infrastructure ... the very institution that there are integrity questions giving rise to the requirement for SSL domain name server certificates. In the second vulnerability, the certification authority industry is somewhat backing a proposal that when somebody registers a domain name with the domain name infrastructure ... they also register their public key. then in future communication with the domain name infrastructure, they digitally sign the communication. the domain name infrastructure then can
Re: What happened with the session fixation bug?
-- James A. Donald: PKI was designed to defeat man in the middle attacks based on network sniffing, or DNS hijacking, which turned out to be less of a threat than expected. However, the session fixation bugs http://www.acros.si/papers/session_fixation.pdf make https and PKI worthless against such man in the middle attacks. Have these bugs been addressed? On 20 May 2005 at 23:21, Ben Laurie wrote: Do they exist? Certainly any session ID I've ever had a hand in has two properties that strongly resist session fixation: a) If a session ID arrives, it should already exist in the database. b) Session IDs include HMACs. The way to beat session fixation is to issue a privileged and impossible to predict session ID in response to a correct login. If, however, you grant privileges to a session ID on the basis of a successful login, which is in fact the usual practice, you are hosed. The normal programming model creates a session ID, then sets variables and flags associated with that session ID in response to forms submitted by the user. To prevent session fixation, you must create the session ID with unchangeable privileges from the moment of creation. Perhaps you do this, but very few web sites do. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG en30AWb8dk9T67RFzUse67CG7ZHHoOHC5OR/mndW 4T4xroZR7GeKinK0sMRNQ+4Pdj6ApUEu4FCGDghE5 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: What happened with the session fixation bug?
James A. Donald wrote: PKI was designed to defeat man in the middle attacks based on network sniffing, or DNS hijacking, which turned out to be less of a threat than expected. all of them may have been less than expected ... the comoningly recognized SSL certificate issuers (that have their public key preloaded into common browsers) sell their certificates and have processes that look at whether you have a validly registered corporation. For most practical purposes this has been for e-commerce sites and the objective for the majority is protecting credit card numbers. however, the reported exploits and what seem to represent a significantly larger ROI (fraud for effort invested) is to harvest the merchant transaction file (containing all the accumulated transaction information that would have taken months of listening to gather) ... aka it is much easier to let the merchant gather and organize all the information on behalf of the crook. slightly related posting ... http://www.garlic.com/~lynn/2001h.html#61 Security proportional to risk the original ssl e-commerce work http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 had the user typing in the merchant webserver URL as a HTTPS session from the start and then it would check the domain name in the returned certificate (after all the digital signature gorp) with the domain name typed in. this is rarely if ever happening ... the common justification is running SSL during the shopping experience cuts the thruput by 80-90 percent. as a result, SSL is typically saved for the check-out button. so lets say you have been redirected to a fraudulent site and don't know it because the SSL domain name stuff hasn't been done yet. then comes time to do the check-out button. if it is a fraudulent site ... and since the crooks would then be supplying the URL with the check-out button ... the crooks are likely to have obtained a valid SSL certificate for some domain and that domain will match whatever the check-out button supplies. random past ssl certificate posts http://www.garlic.com/~lynn/subpubkey.html#sslcert crooks are capable of setting up valid dummy front companies ... it isn't a very large effort. most of what the CA TTPs do when they are verifying stuff ... is that the person applying for a certificate is in some way associated with a valid company that they claim to be associated with. then the CA TTPs check with the domain name infrastructure to see if the corporation that they just checked on ... is the same one listed as the owner of the subject domain name (modulo the issue that there can be a common company name, a DBA company name, and a legal company name ... all for the same corporation and all completely different names ... you sometimes will see this in credit card statements where the store-front name and the company name on the statement are different). As observed, one of the things SSL was for a countermeasure for integrity problems in the domain name infrastructure involving domain name hijacking (where the mapping of the domain name to an ip-address was altered to be a different ip-address, potentially fraudulent website). However, there have been more sophisticated domain name hijackings that have occured where both the domain name infrastructure records had both the name of the corporate owner as well as the ip-address altered. In this more sophisticated form, a crook with a perfectly valid dummy front corporation ... that has done the more sophisticated form of domain name hijacking ... could apply for a perfectly valid SSL domain name certificate ... and pass all the tests. in any case, that was my perception of what we were doing with SSL ten years ago. PKI is slightly different. One of the reasons that we coined the term certificate manufactoring was to try and differentiate what was comingly being referred to as PKI ... and what SSL domain name certificate stuff was actually doing. Note that there has been a proposal to somewhat address the more complex form of domain name hijacking (both the company name take-over as well as the ip-address take-over) ... which involves having domain name owners register a public key when they get a domain name. Then all future correspondance with the domain name infrastructure is digitally signed ... which then can be veriefied with the onfile public key. as a side note ... this is a non-PKI, certificateless implementation of public key. In any case, with authenticated correspondance ... there supposedly is less chance of domain name hijacking occuring. http://www.garlic.com/~lynn/subpubkey.html#certless This has somewhat been supported by the CA SSL domain name certification industry. The have a complex, expensive, and error-prone identification process to try to establish a valid corporation. And even then they are at the mercy of whether the company name listed in the domain
Re: What happened with the session fixation bug?
James A. Donald wrote: -- PKI was designed to defeat man in the middle attacks based on network sniffing, or DNS hijacking, which turned out to be less of a threat than expected. However, the session fixation bugs http://www.acros.si/papers/session_fixation.pdf make https and PKI worthless against such man in the middle attacks. Have these bugs been addressed? Do they exist? Certainly any session ID I've ever had a hand in has two properties that strongly resist session fixation: a) If a session ID arrives, it should already exist in the database. b) Session IDs include HMACs. Session fixation is defeated by either of these. Modulo insider attacks, of course. :-) -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
