WordPress security continued

Of course, not two seconds after publishing my previous post, while talking about it with a friend, he realized that it is not only the WordPress log-in form which has clear security implications (as in providing which of the two login-data was erroneous), but that WordPress could potentially leak information through the lost password retrieval / reset feature.

Don’t get me wrong, I love WordPress, but I am beginning to suspect that the immense popularity it has attracted, is due to its ease of use, and usability have never been known to often go hand in hand with security. And indeed, WordPress, with all the security “flaws” one can find in it, seem to have chosen ease of use over security.

It was, however, rather easy to fix this too, although it meant diving head first into some PHP code. The affected lines of code which we wish to disable is inside a switch-statement far down in wp-login.php.

It ended up looking like this:

case 'lostpassword' :
case 'retrievepassword' :
        $redirect_to = 'wp-login.php';
        wp_safe_redirect($redirect_to);
        exit();
break;

case 'resetpass' :
case 'rp' :
        wp_redirect('wp-login.php');
        exit();
break;

case 'register' :
        wp_redirect('wp-login.php?registration=disabled');
        exit();
break;

Not everyone can use this approach of course, since your blog might wish to let users retrieve their password, or to register, or whatever, but for this blog, with me as the sole author, it works quite nicely.

Tags: ,

4 Responses to “WordPress security continued”

  1. lbe says:

    Nice post, how does the resetpass and lostpassword functions work in WordPress? Haven’t studied the source myself.

  2. Patrik says:

    I’m not sure exactly how you mean by “work” (superficially i.e. what makes them vulnerable, or “under the hood”). I’m hoping that you are meaning my first interpretation, since that’s the one I know the answer to ;)

    Basically, if you call the “lost password” function, it lands you with a form asking for your username, and upon a faulty username the error message tells you so, and upon a correct username, it responds with a success message. One could argue that this is still not much of a vulnerability as, after having guessed the username, would still have to guess the password, which would presumably just have been reset. (And by guess I of course mean bruteforce search).

    If your question was about the “under the hood” stuff, I’m sorry, I can only point you in the right direction (wp-login.php in the root of the wordpress install directory) in which I just ripped out the parts connecting the POST/GET data with any password manipulation functions. Hope it helps.

  3. lbe says:

    That is interesting, I’m not sure how up-to-date my installation of WordPress is but when I answer to comments on a post my username gets displayed as well. Maybe there is a setting for this, haven’t thought of it as a security issue before, but that should probably be changed as well then.

  4. Patrik says:

    Oooh, deadly security sin number one :P Out of date software ;D But seriously, I can’t remember how the older versions worked, but 2.7 allows you to specify a string (name) to display. Which is neat. And as always, these measures are just speed bumps. A sufficiently determined attacker could gain entry anyway, but then again, this little piss-ant blog isn’t worth enough to attack, and these measures just might be enough to keep it from being attacked (as there are far more vulnerable installations out there).