SAML Simple paper:
https://www.owasp.org/images/5/5a/07A_Breaking_XML_Signature_and_Encryption_-_Juraj_Somorovsky.pdf Fun take-aways: One valid SOAP message to Amazon EC2 is enough to start and stop cloud instances, download and upload virtual images, and get full control over the victim's cloud. If XML parsing errors are signaled to the client as errors, you can break XML encryption to decrypt a message. You might even be able to create your own encrypted messages. Complicated Paper: https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf Net result: 11 of 14 SAML frameworks were vulnerable to some kind of attacks that allow you to impersonate whoever you want to, assuming you can get access to any valid SAML assertion, in some cases even an expired one from a different identity provider. SAML is used to authenticate against a server (e.g. AD) and provide an assertion to a relying party (e.g. SAAS apps) about who you are. The relying party is programmed to trust assertions from the identity provider. It can be used for various kinds of single-sign on (SSO). The problem is that it relies on XML digital signatures <http://en.wikipedia.org/wiki/XML_Signature>. XML digital signatures have several problems that most other cryptographic systems don't have, IMHO: 1. It was designed with so that you can sign the canonical/ideal form of some data - so you sign a piece of binary data and then base64 encode it, and wrap it in XML tags. The recipient has to decode it first, then check the signature. So the decoding routines operate on unauthenticated data, and now your XML decoding routines are part of the anonymous attack surface. 2. It's relying on XML which is pretty general-purpose and more-or-less designed with lots of functionality that isn't relevant to this use case. For example, XML entity encoding, external references, namespaces, etc. There were a variety of problems. I only skimmed the paper but they look like: 1. One, Apache Axis, ignored the signature altogether. 2. Two SAML frameworks accepted the message if there was no signature present. Doh! 3. Advanced attacks broke ten of the frameworks. Presumably this overlaps with the three above. These attacks often took the form of having two elements with the same URI in the message, so that the "pointer" from the signature actually referenced two items, or having a second assertion that "overwrote" the one that was validated. You've probably seen similar attacks where there can be two HTTP headers, and the software may honor the first or the last, but with XML it's even more complex since there is a tree instead of a simple list. "In our evaluation of real-world SAML implementations we observed that Microsoft Sharepoint 2010 and SimpleSAMLphp were resistant to all applied test cases" Defense Take-away: This stuff is very complex and the people using XML libraries in SAML frameworks aren't always aware of the corner cases and how it handles stuff whose meaning is ambiguous. Pen-Test Take-away: http://ws-attacker.sourceforge.net/ WS-Attacker is a modular framework for web services penetration testing. It is a free and easy to use software solution, which provides an all-in-one security checking interface with only a few clicks. Other Non-Langsec Links I collected on similar technologies: http://arstechnica.com/security/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong/ http://identitymeme.org/doc/draft-hodges-saml-openid-compare.html OpenID security issues: https://sites.google.com/site/openidreview/issues http://amifan.googlecode.com/svn/trunk/Documents/Security-analysis-of-OpenID-ISSE-2010-paper.pdf http://www.nds.rub.de/media/nds/veroeffentlichungen/2010/12/20/CameraReady_SecurityofSingleSignOn.pdf http://www.technologyreview.com/view/421872/how-openid-lost-to-facebook-connect-in-the-battle-for-your-online-identity/ http://www.nada.kth.se/utbildning/grukth/exjobb/rapportlistor/2009/rapporter09/lindholm_alexander_09076.pdf http://www.it.uc3m.es/muruenya/papers/MCSS10OpenID.pdf OpenID attribute flaw: http://www.informationweek.com/security/vulnerabilities/openid-warns-of-serious-bug/229403066 http://openid.net/2012/03/14/vulnerability-report-data-confusion/ http://www.untrusted.ca/cache/openid.html Universally Composable Security Analysis of OAuth v2.0: http://eprint.iacr.org/2011/526.pdf Oauth http://www.sans.org/reading-room/whitepapers/application/attacks-oauth-secure-oauth-implementation-33644 http://www.infoworld.com/d/security/facebook-said-fix-oauth-based-account-hijacking-flaw-213312 http://readwrite.com/2009/04/25/how_the_oauth_security_battle_was_won_open_web_sty#awesm=~omhgcscMx6sMI3 http://lersse-dl.ece.ubc.ca/record/279/files/279.pdf http://www.theregister.co.uk/2013/07/25/linkedin_oauth_token_snaffling_vuln/ http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html http://developer.yahoo.com/oauth/faq/ http://timourrashed.com/oauth-risk/ http://hueniverse.com/2010/09/all-this-twitter-oauth-security-nonsense/ http://www.ehackingnews.com/2013/04/another-oauth-vulnerability-allowed-to_13.html http://cakebaker.42dh.com/2008/04/01/openid-versus-oauth-from-the-users-perspective/ http://softwareas.com/oauth-openid-youre-barking-up-the-wrong-tree-if-you-think-theyre-the-same-thing http://stackoverflow.com/questions/2837553/saml-vs-federated-login-with-oauth -- http://www.subspacefield.org/~travis/ I'm feeling a little uncertain about this random generator of numbers.
pgptCNSU_Vnco.pgp
Description: PGP signature
_______________________________________________ langsec-discuss mailing list langsec-discuss@mail.langsec.org https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss
