On May 26th Veronica Valero of Talsoft S.R.L. posted a security advisory on the Full Disclosure mailing list outlining a username disclosure vulnerability via a Direct Object Reference.
This is a problem in itself, however, what was more interesting to me was Zerial’s reply to the advisory;
“Also you can “enumerate” wordpress users using the wp-login.php. When you enter a non-existent user wordpress returns “Invalid username” and when you enter a valid user with any random/dummie password, wordpress returns “Invalid Password”. Now you can use brute-force to enumerate all valid users using, for example, a name&username dictionary.”
As we can see from a simple test on https://wordpress.org/wp-login.php, what he was saying was true.
Existent user ‘admin’:
As we can see from the two screenshots above, there is a clear difference in the error message that is displayed by WordPress when a user exists or does not.
According to OSVDB 55713 this vulnerability was reported to WordPress by Core Security Technologies in June 2009. At the time of writing, the latest version of WordPress is 3.1.3 and is still vulnerable to this vulnerability.
Here is how to patch the vulnerability highlighted by ‘Zerial’ yourself:
wp-includes/user.php:91
Change:
return new WP_Error(‘invalid_username’, sprintf(__(‘ERROR: Invalid username. Lost your password< /a>?’), site_url(‘wp-login.php?action=lostpassword’, ‘login’)));
To:
return new WP_Error( ‘invalid_username’, sprintf( __( ‘ERROR: Invalid username and/or password.’)));
wp-includes/user.php:111
Change:
return new WP_Error( ‘incorrect_password’, sprintf( __( ‘ERROR: The password you entered for the username %1$s is incorrect. Lost your password?’ )
To:
return new WP_Error( ‘incorrect_password’, sprintf( __( ‘ERROR: Invalid username and/or password.’)));
Let’s hope WordPress patches this and the one Veronica disclosed sooner rather than later.
UPDATE
After some further researching it seems a bug report was issued in 2007 on WordPress’s Trac. http://core.trac.wordpress.org/ticket/3708
“There are other ways to verify user names. You can reverse engineer them from the author archive URLs (e.g. http://example.com/author/mark/). I believe the consensus last time this came up was that it was trivial to figure out the user names anyway, and that it is much more user-friendly to tell them when they messed up their username, and not the password. Also, “admin” is created on install, and can’t be changed using WordPress itself, so there’s no hiding that.”
Cross-posted from ethicalhack3r
