[WEB SECURITY] SSO request hijack

[Thomas Ptacek]

I don't have the background on this thread, but figured I'd chime in to say:

* If you're using the default mode (ECB) you can be cryptanalyzed a byte-at-a-time

* CBC mode is susceptible to bit flipping attack, the default mode isn't (don't ever use the default mode).

* If you reuse or generate predictable CBC IVs you can be cryptanalyzed a byte-at-a-time

* If you don't encrypt-then-MAC, verify-then-decrypt, your plaintext can be rewritten through the ciphertext (a simplification, but a useful one). 

* If you pick the wrong MAC, &c.

* If you implement MAC verify with data-dependent timings, &c

* The other modes have similar or worse problems, as do the stream ciphers

Basically just don't do your own encryption. 

If you're writing Java code, you can use BouncyCastle's PGP support to get an all-singing all-dancing cryptosystem that resists these attacks. 

On Mar 14, 2012, at 1:12 PM, Daniel unicornFurnace Crowley wrote:

> Hi Subin,
> 
> There are a few potential issues I see.
> 
> First, depending on how you perform the encryption, attacks might be
> possible. If, for instance, you use ECB, you might be subject to block
> shuffling or bit-flipping attacks. If you're using a timestamp in the
> XML blob to indicate the validity period for the session request, a
> bit-flipping attack might be sufficient to replay a stale session
> token outside the normal validity period.
> 
> If you're using CBC, you might be subject to padding oracle attacks
> which would allow for an attacker to tamper with the encrypted data.
> 
> If you reuse keys and are subject to an encryption oracle anywhere in
> your application (see
> http://www.slideshare.net/BaronZor/daniel-crowley-speaking-with-cryptographic-oracles)
> you might allow anyone to create their own session using this
> mechanism.
> 
> Encryption is difficult to do correctly. Do not rely on it as the only
> thing standing between your application and an attacker.
> 
> Second, placing data in the URL is considered unwise, as that data is
> logged in various places like proxies, browser history and web logs.
> Should an attacker gain access to any one of those items, they could
> replay the session within the three minute validity period.
> 
> Third, if a user controls any part of the XML data, you might be
> subject to XML injection attacks which might allow for things like
> privilege escalation.
> 
> Is there any reason the user needs to log into the old version of the
> application at all? Why not just force them to log into the new
> version?
> 
> Cheers,
> -- 
> Dan Crowley
> "All the forces in the world are not so powerful as an idea whose time
> has come." - Victor Hugo
> 
> _______________________________________________
> The Web Security Mailing List
> 
> WebSecurity RSS Feed
> http://www.webappsec.org/rss/websecurity.rss
> 
> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
> 
> WASC on Twitter
> http://twitter.com/wascupdates
> 
> websecurity at lists.webappsec.org
> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org


---
Thomas Ptacek // thomas at matasano.com
Principal, Matasano Security --- 888-677-0666x7805