Ah it’s WordPress again, sometimes I wonder how many holes there are in WordPress. I guess a dedicated attacker could find some serious ones with the complexity of the code base.
It’s suspected some of the recent high profile breaches have come from WordPress exploits.
The latest one to become public is a simple but effective flaw, it doesn’t enable take-over but it does allow a prankster to lock an admin out of their blog by resetting the password.
Developers of the widely used WordPress blogging software have released an update that fixes a vulnerability that let attackers take over accounts by resetting the administrator password.
The bug in version 2.8.3 is trivial to exploit remotely using nothing more than a web browser and a specially manipulated link. Typically, requests to reset a password are handled using a registered email address. Using the special URL, the old password is removed and a new one generated in its place with no confirmation required, according to this alert published on the Full-Disclosure mailing list.
The flaw lurks in some of the PHP code that fails to properly scrutinize user input when the password reset feature is invoked. Exploiting it is as easy is directing a web browser to a link that looks something like:
I actually saw the alert as it was published on Full-Disclosure, obviously anything to do with WordPress catches my attention.
The exploit can be executed by running the following code on a WordPress 2.8.3 blog:
|
1 |
http://www.domain.com/wp-login.php?action=rp&key[]= |
Simple but effective.
According to WordPress documentation here, the bug has been fixed by changing a single line of code so the program checks to make sure the input supplied for the new password isn’t an array. If it is, the user gets an error message and must try again.
That would appear to be the end of it, but security researchers Rafal Los and Mike Bailey wonder aloud here whether it would have made more sense to check instead whether the input is a string.
“Hasty coding?” he asks. “Why take the blacklist vs. whitelist approach?”
The bigger point he and other observers seem to make is that PHP is the coding equivalent of an everyman’s jet pack. It allows him to quickly soar into the sky with a minimal amount of training but doesn’t necessarily provide the means to check for buildings, planes or other hazards that may greet the user once he gets there.
WordPress 2.8.4 has already been released so if you’re running WordPress do update ASAP to ensure you are safe from this bug.
With the core updates now available on auto-update there’s no excuse for not updating (no more download, extract, upload via FTP).
Of course with its history, this doesn’t mean you are safe from any of the other exploits that haven’t been made public.
Source: The Register
Of course, this only effectivly locks the admin out when he doesn’t have access to his e-mail address. Or his DB.
Interesting bug. Clever use of PHP’s get/post array notation, but can’t really be considered exploitable to any serious extend.
wordpress…..again…..at least this part of the article was mildly humerous….
“The bigger point he and other observers seem to make is that PHP is the coding equivalent of an everyman
@cbrp1r8
I’ll agree and disagree with your comment. PHP does provide the tools to easily soar indeed. It DOES provide the means to check for buildings etc, however it doesn’t enforce, or require you to use them.
You can write crappy code in any language and leave yourself open for attack. Just because PHP lets you get the ball rolling very quickly, doesn’t mean it’s inferior.
I do shutter everytime I have to dive into the wordpress code though. It’s far from elegant and you’d think with the adoption that it has it would be better.
I’m not tracking. Which account is it resetting the password on? In my blogs I have the default admin account deleted, so just curious. Can’t tell by a cursory inspection of the code.
rather annoying exploit, especially if you dont have direct access to the db.
good thing they already fixed it .
This attack vector bypasses the empty() checks but does not yeild an empty string as the value in the WHERE clause, rather it yeilds the string ‘Array’…therefore NOT A PROBLEM.