Menu
▾
▴
#302 Major security hole still exists ....
Just upgraded from version 0.511 to initially 0.82 but this failed login, then used SVN273 created this evening, however the original security problem I was hoping to escape from still exists in that any additional user created requires only the first two letters of the password to be entered to gain access .... a massive hole in the security and one that is known to exist with exploit code freely all over the web ...
I do notice that users2.php is now better encrypted, but it takes very little effort to try a password combination of just two characters!!!
Thanks I wasn't aware of that one. Any idea why that is? Seems like an unusual bug. Will check it out when I get back to my computer.
Ticket moved from /p/sphpblog/support-requests/87/
No as to why, but its well published on the web, I suspect everybody jumped on the easy access to the users.php file, and didn't spot that the exploit only uses the first two characters of the badly encrypted password see here, end of second line and then used in the last line the first two characters leak thru every time, and it appears to be accepted when tested for as well;
print "\nDone! Found - $n users:\n";
for ($x=0;$x<$n;$x++){
$up=explode("|",$line[$x]);$user[$x]=$up[1];$pass[$x]=substr($up[2],0,2);
print "\nUsername - ".$up[1]."\tPassword - ".$up[2];
}
}
print "\n
Trying to Login...";flush();
$postvar="user=$user[0]&pass=$pass[0]&";
Maybe it might be better to use the PHP function password_hash() which uses crypt() several times with plenty of salting! But not checked to see if that really is the problem or what ....
I believe this is fixed in svn r275. I will make a new release soon. Alright so here is the post mortem.
Vulnerable systems: Those with a config/users.php file present and enabled users. Very old versions may have a similar file called config/users.txt.
Not Vulnerable systems*: Those with only the admin user. Those with additional users stored in users2.php only.
*Note: Password guessing is always possible, as previously mentioned if you have really old password hashes for users using DES it won't take long to make it through all possible 2 character passwords. This is probably rare unless you have been running SPHPBLOG for a long time.
Description: Whoever wrote the user management code did not implement the crypt() call correctly. Instead of passing in (password, salt) it was called as (user, password) instead. So in reality the stored password hash for a user was simply the combination of his/her username and salt which was easily obtained from the exposed user database. In the case of the weakest implementation of crypt() (DES), the salt length is exactly two characters. For this reason the exploit code shown should only work on passwords created on very old systems that use this instead of MD5 or newer options. The exploit could, however, easily be modified to exploit any newer crypt() algorithms.
Mitigations: Upgrade to a recent version (current release is 0.8.3) to protect the user password hashes. Upgrade to 0.8.4 or newer to use the correct crypt() calls. Every user's password will then need to be reset by the administrator to generate a new (correct) hash.
Last edit: nabber00 2014-02-23
A technical note, I was not able to implement this using the password_XXXXX functions because those are only available in PHP 5.5 and newer. I am running Ubuntu 12.04 LTS which is running PHP 5.3 and this version is still officially supported. As PHP 5.5.x becomes more widely deployed these should be implemented as the preferred calls. However, Ubuntu 12.04 LTS offers (and defaults?) to SHA512 with the crypt() function which should provide sufficient security.
Morning! Glad you seem to have tracked it down, will give the latest release ago a bit later today (UK).
Yup, that seems a lot happier and now requires the full password!