Class Weak encryption Remote Yes Published 6th June 2014 Credit Robin Bailey of Dionach (vulns@xxxxxxxxxxx) 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 ______________________________________________________________________
