Class                      Weak encryption
Remote                Yes
Published            6th June 2014

Credit                    Robin Bailey of Dionach (vulns@dionach.com)
Vulnerable          CodeIgniter <= 2.1.4

Session cookies created by the CodeIgniter PHP framework contain a number of variables in a serialized PHP array. To prevent users from tampering with this cookie two options are available: either an MD5 checksum is used or the cookie is encrypted.

If the application is configured to encrypt the cookie, it will attempt to use 256bit AES from the Mcrypt PHP library. If this library is not available (note that the library was not required, and was not mentioned in the framework documentation) then it will silently fall back to using a custom XOR based encryption.

Because the structure of the session cookie is known, and the cookie contains a number of user-defined parameters (such as the UserAgent), it is possible to decrypt the cookie by performing an offline brute-force attack to obtain the (hashed) encryption key with keys of increasing length. Real world tests showed that this takes between a few seconds and a few minutes.

Once the encryption key has been obtained, there are a number of attacks that can be performed:

1. The session cookie can be decrypted, which may expose session variables.
2. The cookie is passed to an unserialize() call immediately after decryption, so PHP object injection may be possible depending on the classes available (note that the core CodeIgniter classes are not exploitable).
3. Session variables can be injected, which can lead to an authentication bypass in some applications by injecting a "username" or "email" session variable.

Full details of the vulnerability and proof of concept attack scripts are available here:

http://www.dionach.com/blog/codeigniter-session-decoding-vulnerability
https://github.com/Dionach/CodeIgniterXor

After this issue was reported to the vendor (EllisLab), CodeIgniter 2.2.0 was released that removes the XOR based encryption, and required Mcrypt if encryption is used in the application. Note that this vulnerability can be mitigated by installing Mcrypt, as the vulnerable code will no longer be used.

Timeline:

27/05/2014         Vulnerability identified
28/05/2014         Initial vendor contact
28/05/2014         Vendor response to contact
29/05/2014         Vulnerability disclosed to vendor
29/05/2014         Vendor confirms vulnerability
05/06/2014         Vendor releases patch
06/06/2014         Public disclosure of vulnerability

______________________________________________________________________

Disclaimer: This e-mail and any attachments are confidential.

It may contain privileged information and is intended for the named
addressee(s) only. It must not be distributed without Dionach Ltd consent.
If you are not the intended recipient, please notify the sender immediately and destroy this e-mail. 

Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Unless expressly stated, opinions in this e-mail are those of the individual sender, and not of Dionach Ltd.

Dionach Ltd, Greenford House, London Road, Wheatley, Oxford OX33 1JH Company Registration No. 03908168, VAT No. GB750661242

______________________________________________________________________