Dom, [
> Andrew, > > In my implementation, all my services are granted to all users. If a user's > account is compromised when all services are compromised. This is irrespective > of how the client's host name is defined or created. Because the TGC would > allow > entry to all services. > > Regards, > > Dom ] The end user's hostname is irrelevant. The exploit does not involve the TGC and in particular the adversary does not acquire the TGC in this exploit. The adversary also does not acquire the end user's credentials. I agree, if the adversary were to compromise the end user's web browser, and so access the TGC or even better keystroke log the actual credentials, then the adversary could avoid mucking about with Host: headers on requests. However, reliance on Host: headers on requests when determining the value of the service request parameter to use in validating a presented service ticket in a CAS client implementation, without exposing the credentials, browser, or TGC, does expose the relying application to this exploit. The exploit is one of mis-using legitimately issued service tickets in order for compromised web applications to authenticate to other web applications. Alice is an end user. She has a secure, uncompromised web browser. Alice desires to authenticate to Eve's Student Cheating Service, a web application that is CASified. Eve is the adversary and controls Eve's Student Cheating Service. Another web application, also CASified, is Bob's Web File Storage. Bob's Web File Storage only allows direct service tickets. It does not allow proxy tickets. In particular, it does not trust Eve's Student Cheating Service to proxy authentication to it. Eve desires to illicitly access Bob's Web File Storage in the name of Alice, thereby getting at Alice's personal files stored there. Alice visits Eve's Student Cheating Service to get answers to her upcoming test. She logs in via CAS. So Eve's web application redirects the browser to CAS with service=https://evil.eve.com/login . Alice authenticates to CAS with her username and password and is redirected back to https://evil.eve.com/login?ticket=ST-1460986-A2h8gh8E9g6aEUghfMiI . Instead of validating the service ticket, Eve's web application crafts a clever request to Bob's Web File Storage. Eve makes the request https://files.bob.com/login?ticket=ST-1460986-A2h8gh8E9g6aEUghfMiI , setting the Host: header to reflect a host of evil.eve.com . If Bob's Web File Storage is secure, it will ignore the Host header and attempt to validate the service ticket with CAS as https://secure.its.yale.edu/cas/serviceValidate?ticket=ST-1460986-A2h8gh8E9g6aEUghfMiI&service=https://files.bob.com/login This validation will fail since the service ticket was issued to access https://evil.eve.com/login. If Bob's application is relies on the Host header to determine its own server name, then it will validate the ticket as https://secure.its.yale.edu/cas/serviceValidate?ticket=ST-1460986-A2h8gh8E9g6aEUghfMiI&service=https://evil.eve.com/login This validation will succeed; CAS will respond to the validation request with a validation response indicating that the service ticket was issued to Alice. Eve's web application will then have successfully illicitly proxied authentication as Alice to Bob's application, accessing Alice's files. In this circumstance, we can say that Eve's application is compromised in a deep way by the Adversary -- the Adversary is running it, intercepting service tickets! Bob's web application has been compromised in a more modest way: the adversary is successfully authenticating to it as users she is not. However, Bob's application hasn't necessarily leaked to the Adversary the ability to inject code, unless a user as whom Eve illicitly proxies authentication is able to inject code. Andrew > Andrew, > > In my implementation, all my services are granted to all users. If a user's > account is compromised when all services are compromised. This is irrespective > of how the client's host name is defined or created. Because the TGC would > allow > entry to all services. > > Regards, > > Dom > > _______________________________________________ > Yale CAS mailing list > cas@tp.its.yale.edu > http://tp.its.yale.edu/mailman/listinfo/cas > _______________________________________________ Yale CAS mailing list cas@tp.its.yale.edu http://tp.its.yale.edu/mailman/listinfo/cas
