David Ohsie - Distinguished Engineer, EMC Corporation

David Ohsie - Distinguished Engineer, EMC CorporationBill Thompson CISSP, CSSLP - Director IAM Practice, UniconAaron Weaver

Leveraging OWASP in Open Source Projects - CAS AppSec Working Group

Hosted by OWASP & the NYC Chapter


Central Authentication Service (CAS)

Simple, Flexible, Extensible Open SourceWeb Single Sign-On for the Enterprise

● Alfresco● Confluence● DokuWiki● Drupal● Google Apps● JIRA● Joomla!● Liferay● MediaWiki

● Moodle● OpenCMS● PeopleAdmin● Roller● Sakai● Twiki● uPortal● Wordpress● Zimbra

● Spring Security● Apache Shiro● Java CAS Client● .Net CAS Client● php CAS Client● mod_auth_cas● ASP to Zope



● CAS initially create by Shawn Bayern in 2001 at Yale

● CAS3 jointly designed and developed by Rutgers and Yale in 2005 as Jasig project

● Simple protocol, flexible architecture, wide deployment



But...is it secure? How do we know?

● Based on Kerberos● Wide deployment and many eye balls● Reports of dynamic scans from time to time● Maybe we should really check?



CAS AppSec Working Group - Jan 2013

• Joachim Fritschi

• Jérôme Leleu

• Misagh Moayyed

• Parker Neff

https://wiki.jasig.org/display/CAS/CAS+AppSec+Working+Group

• David Ohsie

• Andrew Petro

• Bill Thompson

• Aaron Weaver

https://wiki.jasig.org/display/~fritschi

https://wiki.jasig.org/display/~jleleu

https://wiki.jasig.org/display/~pneff

https://wiki.jasig.org/display/~david.ohsie

https://wiki.jasig.org/display/~awp9

https://wiki.jasig.org/display/~wgthom

● Proactively work to improve the security posture

● Respond to potential vulnerabilities

● Produce artifacts that help potential CAS adopters evaluate the security of CAS

● Create and maintain recommendations on good security practices for deployments


CAS AppSec Working Group Goals



Google pays coders to improve open-source security


Open Source software needs to be open on software security.


As an adopter or potential adopter I want to know how the project deals with security


Security can be a strong “selling” point!


How to avoid being one of the "73%" of WordPress sites vulnerable to attack

Or it can detract from your project


Vulnerability Handling Practices



OSS AppSec Program● Form a working group● OWASP Resources● Meet regularly● Make it easy to report vulnerabilities● Threat Analysis with Developers● Run security tools (ZAP, Static Code)


Contributors

● Use OWASP Resources and Libraries

● Threat Model● Work with security

researchers


Make it easy to report a vulnerability

● Security issue email address

● Provide a PGP Key


Static Code AnalysisIssues were found, prioritized and worked through false positives

● What people think/say: “We probably don’t have any major security issues.”

● Threat analysis gives you a way to systematically analyze the possible threats against your system and rank them by potential impact.

● Threat analysis also gives adopters the information they need to analyze the deployment of your system in their environment.


Threat analysis: Purpose

● Decompose the application: Draw a dataflow diagram in order to enumerate the attack surfaces.

● For each attack surface, enumerate the threats to the system and rank them.

● For each threat, create a list of possible mitigations.

● More details: https://www.owasp.org/index.php/Application_Threat_Modeling


Threat analysis: Methodology

https://www.owasp.org/index.php/Application_Threat_Modeling

https://www.owasp.org/index.php/Application_Threat_Modeling

● Started with whiteboarding session at Apereo conference to produce initial DFD and threats

● Biweekly follow-up meeting via Webex

● Used STRIDE to help identify threats

● Results maintained on wiki page

● https://wiki.jasig.org/display/CAS/CAS+Threat+Modeling


CAS Appsec Experience

https://wiki.jasig.org/display/CAS/CAS+Threat+Modeling


CAS Context DFD


CAS Protocol DFD

Browser

CASServer

CASClient

(Agent)

Application

Username/Password+ Application Service URL

SSO Session Cookie (TGT)Application Service Ticket (ST)

HTTP(S) Request + ST

HTTP(S) + Optional Session Cookie

HTTPS


STRIDE

Threat Security ControlSpoofing Authentication

Tampering Integrity

Repudiation Non-Repudiation

Information Disclosure Confidentiality

Denial of Service Availability

Elevation of Privelege Authorization

● Identifier: PC_3● Category: Information Disclosure● Threat: The pgtIou and pgtId are send as GET

parameters, which can be a problem as they might be stored in logs or indexed in internal search engines...

● Mitigation: Never log the GET parameters on the proxy callback url. Though, it might be not sufficient. Should we change the CAS protocol in the next revision (v4.0) to POST these parameters ?


CAS Appsec Sample Threat

● Easy: Security Guide Contents○ Disable http○ How to write a safe CAS client/plugin○ Securing the ticket registry

● Harder: Change the code○ Secure-by-default○ Encrypted/signed ticket registry


Classifying Remediation

● Classified 19 threat against the system● Generated 10 proposals● One proposal (secure-by-default) integrated into CAS

4.0● Paraphrase from a CAS committer:

○ “I thought when we started that we would not find any problems, but now I see that there are lots of improvements to be made”


CAS Threat modeling results

● Even in a security project, features are favored over security!

● Difficult to get consistent participation (although a core of contributors have kept it up; thank you, Jérôme Leleu and co-presenters!)

● Difficult to get changes prioritized and into the project


Challenges


Application Security Professionals

Find an open source project and volunteer!


Thanks!David Ohsie

Bill Thompson, CISSP, CSSLPIAM Practice Director, [email protected]

Aaron Weaver

mailto:[email protected]

Documents

David Ohsie - Distinguished Engineer, EMC Corporation