WordPress MU

Here's a strange one. I'm using WPMU 1.2.5a still. Yes, I know.

I was pretty sure that I'd blocked off user registration and if I go into the Edit page of my main WPMU domain blog, the "Users can register" field is empty. If I try to change it, WPMU informs me that that field has a value of 0, so it sounds to me like users cannot register.

Wrong. Today, an IP that has never been to my site before hit me 10 times with urls like this:

http://johndoe.my-wpmu-domain.com/wp-activate.php?key=cxasdljldf2334d4

Where 'johndoe' and the key value were different every time.

In each case, a user and blog were created in one shot.

After making sure I had logs of everything, I banned the IP, deleted the users, blogs, wp-activate.php and wp-signup.php (I don't need them anyway, for now).

Now, I can imagine the guy/bot having used a different IP to discover my WPMU install, but what's required to generate working keys out of the box like that?

Is it as simple as going into the WPMU code and finding the key generating algorithm? I can't believe that because then I could do what he did here above but use the same key for any WPMU install I decided to hack, and it would work in each case. Massive security hole.

Thoughts?

Jacob

If you're running an earlier version, the first thing to do is upgrade (preferably to the latest version in trac). If that doesn't correct the issue, then submit a ticket to trac.

If you're blocking registrations all together, just remove the signup and activate files as a temporary fix.

Thanks for the quick response, lunabyte.

Would you happen to know if I could recycle some of his keys to test the upgrade? I would think they'd be one-time keys, but none of those 10 spam users existed before he went straight to the wp-activate urls so I don't know where the keys came from.

You can always try, but the question is, where did those keys come from?

They had to register first to get a key.

Which means that, most likely, they just posted straight to your signup form, and bypassed the main signup page.

Which, with 1.2.5, was an issue. It's been corrected in the latest version available from trac though.

Just browse the trunk, and look for the download link at the bottom of the page.

[Junk removed - Mark]

@mod

The post above is bogus.

Is this what you mean:
main signup page = wp-signup.php
signup form = wp-activate.php

I wouldn't think so, but that's what it sounds like.

According to my logs, each of the 10 user and blog pairs was created at exactly the same time yesterday, the time of their corresponding hits to wp-activate.php, whereas there was only 1 hit to wp-signup.php the whole day and it was hours after the attack.

I've grabbed the 1.3 release, I'm not willing to stick a nightly into my production environment.

If you want the problem "corrected", you'll need the version from Trac. It was something corrected after 1.3 was released. Trac also has some additional fixes which I'm sure you'll find useful as well.

In all honesty, trunk is better/more stable than what's on the download page above.

Ah. Well then I'll test the nightly as you recommend.

Thanks lunabyte

I won't disagree that there are times that using the latest revision from trac isn't a good idea for a live site, but right now it's pretty stable. Not that I'm sure there isn't something that isn't goofy, but far less than what's on the download page.

Agreed.

Donncha released 1.3.2 as I was playing around with the nightly, so I've just upgraded to that. I then turned off registration and I can confirm when I check wp-signup.php. However, wp-activate.php still allows someone to input a key if they can get it.

The real test would be to make a php script that would post to wp-signup.php and see if an account is created, thats seems to be the issue you had. It should not be a big deal that an activation key can be entered because none would work because none are generated in wp-signup.php doesn't create blogs.

Why doesn't someone open up a trac ticket then with some details?