[cas-user] CAS Client Security Vulnerability CVE-2014-4172

[Marvin Addison]

A critical security vulnerability has been discovered in several Jasig
CAS clients that allows URL parameter injection due to improper URL
encoding at the back-channel ticket validation step of the CAS
protocol. The following CVE number has been assigned to track this
vulnerability:

CVE-2014-4172

Affected Software
----------------------------------------
Jasig Java CAS Client
Vulnerable versions: <3.3.2
Fix version: 3.3.2, http://search.maven.org/#browse%7C1586013685

.NET CAS Client
Vulnerable versions: <1.0.2
Fix version: 1.0.2,
http://downloads.jasig.org/cas-clients/dotnet/dotnet-client-1.0.2-bin.zip

phpCAS
Vulnerable versions: <1.3.3
Fix version: 1.3.3,
http://downloads.jasig.org/cas-clients/php/1.3.3/CAS-1.3.3.tgz

There may be other CAS clients that are vulnerable.

Impact
----------------------------------------
The nature of the vulnerability allows malicious remote (network)
agents to craft attack URLs that bypass security constraints of the
CAS protocol. The following attack scenarios are known and have been
demonstrated:

1. A malicious service that can obtain a valid ticket can use it to
access another service in violation of the CAS protocol requirement
that a ticket issued for a service can only be used to access the
service for which the ticket was granted. This type of access amounts
to an illicit proxy: the attacker is proxying authentication for the
target.
2. A malicious user can request a ticket for service A and use it to
access service B with the access privileges of A.

Attacks like scenario 1 could result in unauthorized data disclosure,
while scenario 2 could result in privilege escalation. Other attack
scenarios may be possible.

Remediation
----------------------------------------
Upgrade affected CAS clients as soon as possible. Consider mitigation
if upgrading is not possible.

Mitigation
----------------------------------------
The CAS Service Management facility [1], which is enabled by default,
can be used to restrict services that are permitted to use CAS (i.e.
allowed to request tickets). Whitelisting trusted services can reduce
the scope of attacks like scenario 1 above.

The following servlet filter may provide additional defense at the CAS
server against some forms of this attack:

https://github.com/Jasig/cas-server-security-filter/tree/cas-server-security-filter-1.0.0

Best,
Marvin Addison
CAS Developer

[1] http://jasig.github.io/cas/4.0.0/installation/Service-Management.html

--
You are currently subscribed to cas-...@lists.jasig.org as: jasig-cas-user...@googlegroups.com
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Chad Killingsworth]

I actually stumbled across similar behavior last week. In my case the CAS Server issued a ticket for service:

https://mydomain.com/path

And the successfully validated the ticket against service:

http://mydomain.com/path

Even though both services had different configurations.

Shouldn't this be a bug with the CAS Server? The server should refuse to validate a ticket if the the validation service URL is not exactly equal to the requesting service.

This was observed against CAS Server version 3.5.2.

Chad Killingsworth
Assistant Director of Web and New Media
Missouri State University

[Marvin Addison]

> I actually stumbled across similar behavior last week. In my case the CAS Server issued a ticket for service:
> https://mydomain.com/path
>
> And the successfully validated the ticket against service:
> http://mydomain.com/path

That's unlikely related to the client security vulnerability. We would
need logs from the server and possibly client(s) to say for certain. I
would appreciate your starting a separate thread to discuss further.

Thanks,
M

[Scott Battaglia]

We would need logs to confirm this.  The service should be doing an extract string match.

Cheers,

Scott

On Mon, Aug 11, 2014 at 12:40 PM, Chad Killingsworth <CHADKILL...@missouristate.edu> wrote:

I actually stumbled across similar behavior last week. In my case the CAS Server issued a ticket for service:

https://mydomain.com/path

And the successfully validated the ticket against service:

http://mydomain.com/path

Even though both services had different configurations.

Shouldn't this be a bug with the CAS Server? The server should refuse to validate a ticket if the the validation service URL is not exactly equal to the requesting service.

This was observed against CAS Server version 3.5.2.

Chad Killingsworth
Assistant Director of Web and New Media
Missouri State University

--
You are currently subscribed to cas-...@lists.jasig.org as: scott.b...@gmail.com

To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Tim McLaughlin]

Does this affect ALL versions of the Java client prior to 3.3.2? For
example, I have an application that is using 3.1.8. It's not in the 3.3.x
version.

Also, is there a way to get the 3.3.2 jar without having to do a Maven
build? Latest on the downloads site is 3.2.x.

Thanks,
Tim

>tim.mcl...@wwu.edu

[Marvin Addison]

> Does this affect ALL versions of the Java client prior to 3.3.2?

I did code review of the latest 3.2 and 3.1 versions and they were
both vulnerable. I built one-off patches for my institution, but we
will consider providing official patches for those lines if there is
interest.

> Also, is there a way to get the 3.3.2 jar without having to do a Maven
> build? Latest on the downloads site is 3.2.x.

I noticed there's no download bundle as well. I imagine Scott simply
hasn't gotten to it yet, but I'm sure simply mentioning it here will
make it magically appear :)

M

[Tim McLaughlin]

On 2014/08/11, 12:46 PM, "Marvin Addison" <marvin....@gmail.com> wrote:

>> Does this affect ALL versions of the Java client prior to 3.3.2?
>
>I did code review of the latest 3.2 and 3.1 versions and they were
>both vulnerable. I built one-off patches for my institution, but we
>will consider providing official patches for those lines if there is
>interest.

So far I'm doing fact-finding before I announce to folks here, but if they
were available that would ease the patching, I'm sure. Don't know how
much trouble that is. :)

For my couple of apps, I will probably take the opportunity to get current.

>
>> Also, is there a way to get the 3.3.2 jar without having to do a Maven
>> build? Latest on the downloads site is 3.2.x.
>
>I noticed there's no download bundle as well. I imagine Scott simply
>hasn't gotten to it yet, but I'm sure simply mentioning it here will
>make it magically appear :)
>
>M

:) As always, the work of those of you officially involved with CAS is
much appreciated.

Thanks,
Tim

[Ed Hillis]

I see directories leading to the various jars at http://search.maven.org/#browse%7C-1210596150. Hopefully these are the right ones to use!

Ed

On Mon, Aug 11, 2014 at 4:50 PM, Tim McLaughlin <Tim.McL...@wwu.edu> wrote:

On 2014/08/11, 12:46 PM, "Marvin Addison" <marvin....@gmail.com> wrote:

>> Does this affect ALL versions of the Java client prior to 3.3.2?
>
>I did code review of the latest 3.2 and 3.1 versions and they were
>both vulnerable. I built one-off patches for my institution, but we
>will consider providing official patches for those lines if there is
>interest.

So far I'm doing fact-finding before I announce to folks here, but if they
were available that would ease the patching, I'm sure.  Don't know how
much trouble that is.  :)

For my couple of apps, I will probably take the opportunity to get current.

>
>> Also, is there a way to get the 3.3.2 jar without having to do a Maven
>> build?  Latest on the downloads site is 3.2.x.
>
>I noticed there's no download bundle as well. I imagine Scott simply
>hasn't gotten to it yet, but I'm sure simply mentioning it here will
>make it magically appear :)
>
>M

:) As always, the work of those of you officially involved with CAS is
much appreciated.

Thanks,
Tim

--
You are currently subscribed to cas-...@lists.jasig.org as: hil...@southwestern.edu

To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

--

Ed Hillis

Web Programmer, Information Services

Southwestern University, Georgetown, Texas

512.863.1066 hil...@southwestern.edu

[Scott Battaglia]

If by magically appear, you mean hours later, then yes :-)

http://downloads.jasig.org/cas-clients/

On Mon, Aug 11, 2014 at 3:46 PM, Marvin Addison <marvin....@gmail.com> wrote:

> Does this affect ALL versions of the Java client prior to 3.3.2?

I did code review of the latest 3.2 and 3.1 versions and they were
both vulnerable. I built one-off patches for my institution, but we
will consider providing official patches for those lines if there is
interest.

> Also, is there a way to get the 3.3.2 jar without having to do a Maven
> build?  Latest on the downloads site is 3.2.x.

I noticed there's no download bundle as well. I imagine Scott simply
hasn't gotten to it yet, but I'm sure simply mentioning it here will
make it magically appear :)

M

--
You are currently subscribed to cas-...@lists.jasig.org as: scott.b...@gmail.com

To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Andrew Petro]

MA> we will consider providing official patches for [Java CAS Client 3.2 and 3.1] lines if there is interest.

TM> if [fixed versions of 3.2 and 3.1 Java CAS client versions] were available that would ease the patching, I'm sure.

Yes, it would ease patching.  I'm finding getting a uPortal 4.0 release squared away jumping from a Java CAS Client 3.2 version to 3.3.2 to be substantially unpleasant.

Andrew

On Mon, Aug 11, 2014 at 4:50 PM, Tim McLaughlin <Tim.McL...@wwu.edu> wrote:

On 2014/08/11, 12:46 PM, "Marvin Addison" <marvin....@gmail.com> wrote:

>> Does this affect ALL versions of the Java client prior to 3.3.2?
>
>I did code review of the latest 3.2 and 3.1 versions and they were
>both vulnerable. I built one-off patches for my institution, but we
>will consider providing official patches for those lines if there is
>interest.

So far I'm doing fact-finding before I announce to folks here, but if they
were available that would ease the patching, I'm sure.  Don't know how
much trouble that is.  :)

For my couple of apps, I will probably take the opportunity to get current.

>
>> Also, is there a way to get the 3.3.2 jar without having to do a Maven
>> build?  Latest on the downloads site is 3.2.x.
>
>I noticed there's no download bundle as well. I imagine Scott simply
>hasn't gotten to it yet, but I'm sure simply mentioning it here will
>make it magically appear :)
>
>M

:) As always, the work of those of you officially involved with CAS is
much appreciated.

Thanks,
Tim

--
You are currently subscribed to cas-...@lists.jasig.org as: apetro...@gmail.com

To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Marvin Addison]

> Yes, it would ease patching. I'm finding getting a uPortal 4.0 release
> squared away jumping from a Java CAS Client 3.2 version to 3.3.2 to be
> substantially unpleasant.

Ok. Here's the catch. Some of the integration modules,
cas-client-integration-atlassian comes to mind, have dependencies in
third-party repositories that are defunct. That makes a complete
project build sufficiently difficult if not impossible that the return
on investment is not justifiable. I would imagine that most folks need
cas-client-core exclusively, and I would recommend we focus our
efforts on patches for that module alone. Additionally, that's the
only module affected by patching.

M

[Andrew Petro]

Okay.  So, a cas-client-core-3.2.1.1 that 

1) Fixes cas-client-core , and

2) drops whatever integration modules cannot be built

?  And then many folks can bop to 3.2.1.1, ignore the missing integration modules they aren't using anyway, and be happy.  And folks who are using those modules can monkey patch only their cas-client-core .jar and be somewhat happy. ?

Andrew

On Tue, Aug 12, 2014 at 8:02 AM, Marvin Addison <marvin....@gmail.com> wrote:

> Yes, it would ease patching.  I'm finding getting a uPortal 4.0 release
> squared away jumping from a Java CAS Client 3.2 version to 3.3.2 to be
> substantially unpleasant.

Ok. Here's the catch. Some of the integration modules,
cas-client-integration-atlassian comes to mind, have dependencies in
third-party repositories that are defunct. That makes a complete
project build sufficiently difficult if not impossible that the return
on investment is not justifiable. I would imagine that most folks need
cas-client-core exclusively, and I would recommend we focus our
efforts on patches for that module alone. Additionally, that's the
only module affected by patching.

M

--
You are currently subscribed to cas-...@lists.jasig.org as: apetro...@gmail.com

To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Misagh Moayyed]

This makes sense to me, Andrew. Anybody on 3.2.x should be able to upgrade with a drop-in Jar and if we can manage that with a 3.2.1.1 release that all the better.

You are currently subscribed to cas-...@lists.jasig.org as: mmoa...@unicon.net

To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Andrew Petro]

This set of transitive dependency exclusions *might* allow bumping from Java CAS Client 3.2.1 to 3.3.2:

https://github.com/Jasig/uPortal/pull/404

I'm concerned about potentially losing Tomcat 6 support (needs testing?) and about how fragile this solution may be.  Still feeling like a bump to a Java CAS Client 3.2.1.1 would be a more conservative and appropriate move for this late in the rel-4-0-patches uPortal maintenance branch.

-- 
You are currently subscribed to cas-...@lists.jasig.org as: jasig-cas-user...@googlegroups.com

[Scott Battaglia]

That exclusion list is alarming.  Not that this is "great" solution, but I wonder if most of those would be excluded automatically by excluding the SAML jar.

Nonetheless we should definitely look at the effort involved in a 3.2.1.1 release as we want to maximize the number of people who upgrade.

-- 
You are currently subscribed to cas-...@lists.jasig.org as: scott.b...@gmail.com

To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Waldbieser, Carl]

Can someone explain to me how #2 is not a CAS *server* issue?
There weren't any examples given.
For #1, I can see how if you are running CAS open to all services you could trick someone into using the wrong service.
However, for #2, I have a hard time seeing how the server would allow you to request a ticket for A and then use it for B.
Is the idea that the client is *really* requesting a ticket for B in the first place?

Thanks,
Carl Waldbieser

>> 1. A malicious service that can obtain a valid ticket can use it to
>> access another service in violation of the CAS protocol requirement
>> that a ticket issued for a service can only be used to access the
>> service for which the ticket was granted. This type of access amounts
>> to an illicit proxy: the attacker is proxying authentication for the
>> target.
>>
>> 2. A malicious user can request a ticket for service A and use it to
>> access service B with the access privileges of A.

[Marvin Addison]

> However, for #2, I have a hard time seeing how the server would allow you to request a ticket for A and then use it for B.

Both attacks are really the same with different origins. While it's
not appropriate to provide an attack sequence here, I encourage you to
continue thinking about this with URL encoding in mind. The client is
guilty of accepting unvalidated input, and the ticket validation
request can be made to look legitimate to the CAS sever when in fact
it violates the service/ticket pairing.

> Is the idea that the client is *really* requesting a ticket for B in the first place?

No. It's tricking B to send a ticket validation request for A. The
prerequisite is a legitimate ticket for A. The trick is to make B use
A's service URL with the legitimate ticket for A. That would not be
possible if the client URL encoded request parameters properly.

M

[Andrew Petro]

MA> we will consider providing official patches for [Java CAS Client 3.2 and 3.1] lines if there is interest.

I'm still interested in a patch fixing this issue for the Java CAS Client 3.2 line specifically, since that's the CAS client version used in uPortal 4.0 and 4.1.

However, I've also developed a no-dependencies just-add-a-Filter solution:

https://github.com/Jasig/cas-server-security-filter/pull/6

and intend to ship (a fork of) that Filter in uPortal 4.0.15 and 4.1.1 in order to un-block the uPortal releases without having to bump those releases to Java CAS Client 3.3 under duress.  

https://github.com/Jasig/uPortal/pull/405

https://github.com/Jasig/uPortal/pull/406

(It might very well be appropriate to circle back and upgrade to the Java CAS Client 3.3 more calmly for other reasons.  In fact, I expect to update uPortal `master` (towards uPortal 4.2) to use the Java CAS Client 3.3 version. But this Filter allows that upgrade to not be required in order to be safe from this vulnerability.)

On Mon, Aug 11, 2014 at 10:50 PM, Andrew Petro <apetro...@gmail.com> wrote:

[Andrew Petro]

AP> developed a no-dependencies just-add-a-Filter solution

This Filter is now described in this blog post, with instructions for patching-in-place existing old Java CAS client usages, and with a compiled .class file ready to download and apply.

http://apetro.ghost.io/cve-2014-4172-workaround-filter/

This should be a viable workaround for all potentially affected Java CAS client libraries, even the old Yale ones, even third party libraries, for environments where upgrading to Java CAS Client 3.3.2 or better isn't the best first move to block this vulnerability.

Happy patching,

Andrew

[Baron Fujimoto]

On Mon, Aug 11, 2014 at 12:03:48PM -0400, Marvin Addison wrote:
>[...]

>
>Mitigation
>----------------------------------------
>The CAS Service Management facility [1], which is enabled by default,
>can be used to restrict services that are permitted to use CAS (i.e.
>allowed to request tickets). Whitelisting trusted services can reduce
>the scope of attacks like scenario 1 above.
>
>The following servlet filter may provide additional defense at the CAS
>server against some forms of this attack:
>
>https://github.com/Jasig/cas-server-security-filter/tree/cas-server-security-filter-1.0.0

This CAS server security filter[*] seems to catch the Services Management app if you edit an entry to release more that one attribute.

java.lang.IllegalArgumentException: 'allowedAttributes' parameter appears more than once for url: /cas/services/edit.html
org.jasig.cas.security.SecurityFilter.checkParameterOnlyAppearOnce(SecurityFilter.java:79)
org.jasig.cas.security.SecurityFilter.doFilter(SecurityFilter.java:62)

Is there a way to exclude the Services Management app?

Aloha,
-baron

[*] I found I also needed to deploy an slf4j jar file as well to get this
to work (slf4j-api-1.7.7.jar was minimally required. Other versions probably
work, but that seemd to be the latest available. YMMV)
--
Baron Fujimoto <ba...@hawaii.edu> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum

[Jérôme LELEU]

Hi,

Yes, for CAS server version < 4.0, the filter will wrongfully block multi-attributes service setup.

The documentation was updated: https://github.com/Jasig/cas-server-security-filter to explain that explicit mappings are required in that case.

Best regards,

Jérôme LELEU

Founder of CAS in the cloud: www.casinthecloud.com | Twitter: @leleuj

Chairman of CAS: www.jasig.org/cas | Creator of pac4j: www.pac4j.org

You are currently subscribed to cas-...@lists.jasig.org as: lel...@gmail.com

To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

[Baron Fujimoto]

That works, mahalo!

Aloha.
-baron