[langsec-discuss] XML DIGSIG, SAML, and langsec

travis+ml-langsec at subspacefield.org travis+ml-langsec at subspacefield.org
Sat Sep 27 18:20:34 UTC 2014


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.





-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <https://mail.langsec.org/pipermail/langsec-discuss/attachments/20140927/7527be7b/attachment.pgp>


More information about the langsec-discuss mailing list