WordPress Exploit Allows Admin Password Reset

Multiple readers have sent word of a vulnerability in WordPress 2.8.3 which allows anyone to lock an admin out of his or her account by resetting the password. "The bug ... 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." An alert on the Full Disclosure mailing list detailed the vulnerability, and WordPress quickly rolled out version 2.8.4 to address the issue.

Comments

Clarification

[Jugalator]

For those who don't RTFA, this doesn't give the attacker access to the new, reset, password. That requires access to the admin's mailbox as well. So the link saying "lock an admin out" is a bit, well, not completely true. It could be true if his/her inbox is hacked, but not otherwise.

Re:Clarification

[Jellybob]

Using the special URL, the old password is removed and a new one generated in its place with no confirmation required.

While you're right in saying the attacker can't access the admin's account, the admin themselves also can't access it, because their password has already been reset to something else, and they'll have to get the new one. It seems more like a minor inconvenience to me, then a massive bug which will end the world, but still a flaw.

Re:Clarification

[evanbd]

If I write a script that resets your password every 3 seconds, you'll find it to be more than a minor inconvenience.

Re:Clarification

[hcdejong]

Can't the administrator use the same hack to change the password again, regaining access?

Re:Clarification

[makomk]

RTFA? Did you RTFSummary? The point is that the password is reset but the reset doesn't get sent to the admin email as per usual.

Except that's not actually what it says, and even if it was TFA states otherwise:

As a result, the first account without a key in the database (usually the admin account) would have its password reset and a new password would be emailed to the account owner.

The e-mail that doesn't get sent is the one asking the user to confirm they want to reset their password, since that step is bypassed by the exploit.

Re:Clarification

[Tumbleweed]

> Using the special URL, the old password is removed and a new one generated in its place with no confirmation required.

While you're right in saying the attacker can't access the admin's account, the admin themselves also can't access it, because their password has already been reset to something else, and they'll have to get the new one. It seems more like a minor inconvenience to me, then a massive bug which will end the world, but still a flaw.

The admin still gets the password change notification, though, so the net effect is that someone is changing their password for them, notifying them of that, yet the attacker still can't get access to the admin login info unless they have access to the admin's email account. The admin can simply check their email for the new password, though, so they're not really locked out. Annoying, yes, but a pretty minor issue, and it's already been fixed.

Re:Clarification

[Thaelon]

Why wait 3 seconds?

while true; do lynx -dump <specially crafted URL>; done &

Re:Clarification

[stuckinphp]

Hardly specially crafted.. Here you go script kiddies, have fun while true; do lynx -dump http://domain_name.tld/wp-login.php?action=rp&key%5B%5D=; done &

Full disclosure a day after discovery?

[SmitherIsGod]

Is that not a bit soon? Especially with wordpress - it's going to be ages before many people update, and it's not a critical problem.

That's why I stopped using Wordpress

[krovisser]

I was tired of constantly having security issues and having to upgrade. Isn't there less feature-filled blog app out there that's all lightweight and whatnot?

Re:That's why I stopped using Wordpress

[Deanalator]

*laugh explosion* Ya, that's an awesome idea for making sure your app is secure. Remember that old rule about writing your own crypto? That still applies today to CMS webapps. Unless you have a *set* of friends that pentest webapps professionally, writing your own CMS is an absolutely terrible idea.

Re:That's why I stopped using Wordpress

[Deanalator]

blogspot

Unless you have a team of developers and pentesters constantly maintaining your blog, you are better off getting it hosted somehwere else. Any given blog instance that is not properly maintained is only going to remain secure for about 6 months or so. If you, or you and a few people, or even a small company just want a simple blog to post stuff on, and you don't want to hire a staff of infosec monkeys, blogspot is definitely the way to go. The code is maintained by google, and data is redundantly backed up for you for free.

Re:Thanks

[D Ninja]

Now to do the other sites later tonight.

What, by chance, is the web addresses for your other sites.

No particular reason why I'm wondering. Just...um...want to read your blogs...

Code is Poetry

[pathological liar]

If Code is Poetry then Wordpress is some 15 year old's notebook scribblings on angst, Twilight and Dashboard Confessional.

If you're looking for alternatives that don't have gaping security issues with seemingly every release, check out Serendipity.

Re:The great fallacy of root passwords

[TheRaven64]

The kernel does not run at the same privilege level as root. Root is a user which the kernel allows to access (some) privileged services. Root programs run in ring 3 (on x86, unprivileged mode on other platforms), while the kernel runs in ring 0 (or privileged mode on non-x86 platforms). The kernel can access physical hardware directly. The root user can not, they can only request that the kernel access it on their behalf. On some UNIX systems there is a device node which allows a sufficiently-privileged user to map arbitrary memory pages, however this is not something that root can do without the kernel exposing this device and without the kernel deciding which userspace processes are allowed to do so. A program running as root can not, for example, write to a device or alter the page tables without the kernel mediating this.

A privilege escalation vulnerability in the kernel may or may not be related to the root user. Often they are not, for example the recent SCTP vulnerability in Linux permitted arbitrary code to be run in kernel space, meaning that the root user was completely irrelevant. Other privilege escalation vulnerabilities only allow you to run your code as if it were run by root, in which case systems like SELinux or system immutable flags in the filesystem may still prevent you from doing things you want to.

Re:WordPress is Awesome

[dubbreak]

*opens dashboard, presses "Upgrade to 2.8.4" button*

Fixed. :D

Not sure why you got modded down (probably just the way you put it). Upgrading Wordpress is trivially easy.

Exploits happen, and this is a pretty minor one (just an annoyance, not user permission escalation, admin rights etc). They got a fix out quick and it's easy enough to apply.

PHP is to blame

[sverrehu]

It appears that PHP, upon seeing an incoming parameter with a name that ends in [something] (where something may be empty), automatically turns that variable into an array.

How many of you PHP developers out there knew that? I didn't. And I had to dig quite a bit to find a reference to this behaviour in the docs.

So, incoming stuff from the URL or the POST data are no longer strings all the time. Can they magically become other things than strings and arrays as well? Maybe not now, but what if some PHP developer thinks up another "nifty" feature _after_ I read the docs; how then am I supposed to protect my application in the future? Do I need to re-read the docs every time I upgrade PHP?

And is there a way to turn this "we know better than you what you need"-behaviour off?

I'm sick of seing framework developers add "nifty" features that you have to know about in order to write secure code. It's not only PHP, but also several highly popular Java frameworks that I work with these days. Some of them make it quite easy to write to object fields that are normally out of reach of the input fields in a form.

I want a framework that makes it impossible to make mistakes, and where you have to _enable_ potentially dangerous features when you _know_ you need them, rather than _disable_ potentially dangerous features most people don't know about (or use).

Re:Don't get it

[MtlDty]

There is a discussion about the vulnerability on StackOverflow

Stupidity

[pkretek]

I wonder why somebody would code that part the way they did it. As far as I understand it, they are trying to validate code by blacklisting instead of whitelisting:

(from http://core.trac.wordpress.org/changeset/11798)
$key = preg_replace('/[^a-z0-9]/i', '', $key);
if ( empty( $key ) )
    die();

If you expect a hash you generated yourself, why don't you test if it preg_matches the spec you used to generate it in the first place? (/^[a-zA-Z0-9]{20}$/ in this case)

Well that and being naive enough to expect $_GET["key"] to always return a string....

Re:Stupidity

[Skadet]

Right, I wondered myself why there was no validate_key_is_valid() function, or even a simple cast for that matter. $key = (string)$key.

On the other hand, this isn't exactly PHP's fault (or MySQL's, for that matter). The query:

$user = $wpdb->get_row($wpdb->prepare("SELECT * FROM $wpdb->users WHERE user_activation_key = %s", $key));

They're selecting a row (the user) by a column (user_activation_key) that can be blank. Not NULL but literally an empty string. Bad.