CodeIgniter <= 2.1.4 Session Decoding Vulnerability
Class Weak encryption
Remote Yes
Published 6th June 2014
Credit Robin Bailey of Dionach (vulns@dionach.com)
Vulnerable CodeIgniter <=3D 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 wi=
th this cookie two options are available: either an MD5 checksum is used o=
r 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 availa=
ble (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 conta=
ins a number of user-defined parameters (such as the UserAgent), it is pos=
sible to decrypt the cookie by performing an offline brute-force attack to=
obtain the (hashed) encryption key with keys of increasing length. Real w=
orld 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 t=
hat 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 decrypt=
ion, so PHP object injection may be possible depending on the classes avai=
lable (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 v=
ariable.
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 b=
e 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 immediatel=
y and destroy this e-mail.=20
Any unauthorised copying, disclosure or distribution of the material in th=
is e-mail is strictly forbidden. Unless expressly stated,=20opinions in th=
is e-mail are those of the individual sender, and not of Dionach Ltd.
Dionach Ltd, Greenford House, London Road, Wheatley, Oxford OX33 1JH Compa=
ny Registration No. 03908168, VAT No. GB750661242
______________________________________________________________________