WordPress News for the week of 3/6/2006

or “WordPress news finally posted a week late”

With the “hacking” of the original WordPress 2.0 theme competition and a new security release of WordPress 2.0, it has been an exciting week. First a quick word on the competition then a break down of the changes in 2.01.

Now about the competition: When WordPress 2.0 was released, everyone was looking for themes. And google led everyone to just a few places. The main one ended up being a competition site by someone known only as Justin. It seems now, even to an eternal optimist like myself, that it is likely that either the whole KyCap.com competion was a fraud or the Justin just got in over his head. Here are the final posts from that site:

Better News

6th March 2006

I had contacted the server admin and they told me they will look into it and get back to be as soon as possible. At the mean time, i had received a lot of help e-mails from everyone on how to retrive back almost every post from the google cache. I am very grateful on this help. I would like to say thanks to those who help me out.

Trying to retrive Database

5th March 2006

I am truely very sad on what happening to my competition blog. I took more than a month time planing everything up before i organise this competition to let everyone share their works. I don’t earn anything from this competition and i don’t even put up any google adsense to earn any side income. I just hope everyone could enjoy looking for a nice themes.

Message to the hacker, “If you did clear up all this competition blog database, we got nothing to say but if you did save a backup for this database. Please send a copy to us to our email at kcyap@kcyap.com. We will appreciate if you could send it over as soon as possible”

It is really everyone’s hard work on organising this competition. We spend most of our time trying our best to host the best competition ever.

I am very happy with all the comments and the e-mails that had been sent to me regarding this incident. A lot of people had been helping me up on how to get back all the lost post. For your information, my whole database had been deleted by the hacker. Not even a thing left on my server directory. Luckily i did back at least something up for my personal blog. I guess the only way to retrieve all the lost post is trought google cache. Google cache doesn’t shows every page for my post that had been publish. Are there any better ways to retrieve them all?

The themes will all be publish as we had moved them to a new server. The new server is sponsored by one of the followers for this competition blog. I will blog about it soon. Thanks.

Website Got Hacked

5th March 2006

Very regret to announced that this competition blog website had been hacked. I have no backup for all this data and not sure if the server admin did have a backup on it or not. I am very sorry for this incident.
The prizes will still be the same and i will upload once again all the submitted themes on by one from now. This may takes quite some time, please be patient.

The result for this competition will still be announce don the 10th March 2006.

To the sponsors who had agreed to sponsor for this prize, i wont put all the blame on your if u retrieve from sponsoring the prizes because of this incident. We will sponsor the prizes ourself. Luckily we did prepare on it.

Anyone have any idea on how to get back all the deleted post ? Once again, i am very sorry on what had happened. I will try to get back the deleted post if possible. I guess today will be the worst day of my life after i’ve hardly organising this competition for over a month period.

Ironically, it seems his website now HAS been hacked since it is totally crashed. It only displays "No such file or directory in /home/u1/ahkiongkc1/html/index.php" , something I am putting on record here since I can’t see any reationship between the name “Justin” and “achkiongks1”. But that is just matter for further speculation. On the positive side, there were several decent themes put up including the one I am using right now, Binary Blue by Count Zero.

I’ve decided that I will actually put together a 2.0 theme database that people could log their themes to and even upload them for distribution if they don’t have the storage space. So, you’ll soon see some posts explaining what I’ve learned about web forms and fields. I think I’ve got all of the peices working now. 1. An Entry form with the fields I’d use to evaluate whether or not to download a theme. 2. A Page to allow the uploading of an archived theme to my site. 3. A page that performs the actual upload and validation and hopefully provides some protection from abuse security. Oh, and I need the form that iterates the database and displays the result in a table, but that’s easy. So I just need to put them together.

NOTE: This will NOT be a theme competion. This is just a compendium or listing of themes. HOPEFULLY it will be the BEST listing of themes but it is in no way is this meant to compete with the new theme competion at http://www.wordpressarena.com/ which will stop accepting new themes in a week.

Regarding Count Zero, and that’s the English translation – in German he would be known as Count Null (making his website www.4null4.de 404 like the invalid page error Get it? Get it?), we’ve been emailing back and forth all week and, despite my earlier comment about his Customer Relations skills (which I’ll have to rescind – I guess everyone is entitled to get grumpy now and again), I really like the guy. In spite of an off the wall conspiracy theory that he might actually be Justin (lol), I think a good friendship can evolve here, assuming I ever get around to reviewing his theme like I said I would last weekend.

One of the things we’ve discussed over the last week is the security holes in the WordPress Blogging system. They did indeed exist. Count pointed me at where the flaw was and later that night I tested an attack on this website. Luckily the site I host this blog through has a setting that protects against that kind of attack I was using. I still want to determine which knitting blogs may be vulnerable to this kind of attack and tell them how to fix it. Yes I said knitting. With my wife’s knitting blog getting me into this, I feel like I should try to help that community with the technical sides of things. I already know there are a bunch of vulnerable sites. How to approach them is the key. I’m pretty sure that leaving a comment that changes the title of the post I am commenting on by adding a period to it is the wrong aproach. But it is still tempting and would get the point across. 😉

The good news is that the the security in Worpress 2.02 fixes this particular vulnerability. The other good news is that no one has gone around taking advantage of this hole yet in the fashion that they could. KnitChat.com was actualy hacked twice through holes in WordPress 1.52 that have since been plugged. That allowed the index.php file to be replaced with a hacked version. As of tonight, I’m pretty sure I know how that was done. Repairing the attack was easy. If you haven’t taken the right precautions in your blog, this attack could do anything from deleting all of your posts, to wiping the whole DB or worse (yes there is worse).

So, onto what has changed in 2.02 (this was supposed to be the meat of this post and was the only reason why I started it.) Since this is a security release, the WordPress developers didn’t do a detailed “Here is how you can attack older blogs” listing, but they could have gone further than they actually have. The people that will attack blogs, will already know how to compare files between versions and can write their own attacks. I want to know what holes there are in older systems so that I don’t make the same mistakes in what I write.

BTW there will be a couple areas in which I am technically correct in what I say, but I am somewhat vague or don’t explain all of the effects of the code. These are intentional, please do not supply extra detail. However, if I am blatently wrong on something, let me know. Thanks!

So here is the break down:

End User Changes

\WP-Comments-Post.PHP

Old code:
[php]
51 $comment_id = wp_new_comment( $commentdata );
52
53 if ( !$user_ID ) :
54 $comment = get_comment($comment_id);
55 setcookie(‘comment_author_’ . COOKIEHASH, $comment->comment_author, time() + 30000000, COOKIEPATH, COOKIE_DOMAIN);
56 setcookie(‘comment_author_email_’ . COOKIEHASH, $comment->comment_author_email, time() + 30000000, COOKIEPATH, COOKIE_DOMAIN);
57 setcookie(‘comment_author_url_’ . COOKIEHASH, clean_url($comment->comment_author_url), time() + 30000000, COOKIEPATH, [/php][php]COOKIE_DOMAIN);
58 endif;

New code:
[php]
51 $comment_id = wp_new_comment( $commentdata );
52
53 if ( !$user_ID ) :

54 setcookie(‘comment_author_’ . COOKIEHASH, stripslashes($comment_author), time() + 30000000, COOKIEPATH, COOKIE_DOMAIN);
55 setcookie(‘comment_author_email_’ . COOKIEHASH, stripslashes($comment_author_email), time() + 30000000, COOKIEPATH, COOKIE_DOMAIN);
56 setcookie(‘comment_author_url_’ . COOKIEHASH, stripslashes($comment_author_url), time() + 30000000, COOKIEPATH, COOKIE_DOMAIN);
57 endif;
[/php]
Why:
See how the stripslashes was added? That is to ensure that the cookies that are stored on the poster’s computer contain the raw unprotected code. WordPress will do the protection each time a post is madeIf you protect an already protected entry, the data just gets garbled.

[/php]See how the stripslashes was added? That is to ensure that the cookies that are stored on the poster’s computer contain the raw unprotected code. WordPress will do the protection each time a post is madeIf you protect an already protected entry, the data just gets garbled.

\wp-register.PHP

Old Code:
[php]
26 } else if (!is_email($user_email)) {
27 $errors[‘user_email’] = __(‘ERROR: The email address isn’t correct.’);

28 }
29


30 if ( ! validate_username($user_login) )
31 $errors[‘user_login’] = __(‘ERROR: This username is invalid. Please enter a valid username.’);
[/php]

New code:
[php]
26 } else if (!is_email($user_email)) {
27 $errors[‘user_email’] = __(‘ERROR: The email address isn’t correct.’);
28 $user_email = ”;
29 }
30
31 if ( ! validate_username($user_login) ) {
32 $errors[‘user_login’] = __(‘ERROR: This username is invalid. Please enter a valid username.’);
33 $user_login = ”;
34 }
[/php]

Why:
This is fairly straight forward. If the UserName or User Email supplied while registering contains invalid info, possibly from an attack, don’t leave the info there to be built upon. Just clear it out and have the user try again.

Old Code:
[php]
68 <div id=”login”>
69 <h2><?php _e(‘Registration Complete’) ?></h2>
70 <p><?php printf(__(‘Username: %s’), “<strong>$user_login</strong>”) ?><br />
71 <?php printf(__(‘Password: %s’), ‘<strong>’ . __(’emailed to you’) . ‘</strong>’) ?> <br />
72 <?php printf(__(‘E-mail: %s’), “<strong>$user_email</strong>”) ?></p>
73 <p class=”submit”><a href=”wp-login.php” mce_href=”wp-login.php”><?php _e(‘Login’); ?> »</a></p>
74 </div>
[…]
113 “user_login” id=”user_login” size=”20″ maxlength=”20″ value=”” />[/php][php]114 =”user_email” id=”user_email” size=”25″ maxlength=”100″ value=”” />

[/php]New code:
[php]
71 <div id=”login”>
72 <h2><?php _e(‘Registration Complete’) ?></h2>
73 <p><?php printf(__(‘Username: %s’), “<strong>” . wp_specialchars($user_login) . “</strong>”) ?><br />
74 <?php printf(__(‘Password: %s’), ‘<strong>’ . __(’emailed to you’) . ‘</strong>’) ?> <br />
75 <?php printf(__(‘E-mail: %s’), “<strong>” . wp_specialchars($user_email) . “</strong>”) ?></p>
76 <p class=”submit”><a href=”wp-login.php” mce_href=”wp-login.php”><?php _e(‘Login’); ?> »</a></p>
77 </div>
[…]
116 […]=”user_login” id=”user_login” size=”20″ maxlength=”20″ value=”<?php echo wp_specialchars($user_login); ?>” /><br /></p>
117 […]=”user_email” id=”user_email” size=”25″ maxlength=”100″ value=”<?php echo wp_specialchars($user_email); ?>” /></p>
[/php]

Why:
This two changes are simple too. Using wp_specialchars, it takes any OEM characters (and what not) and makes sure they are displayed correctly in the user login name and email. This is crucial in todays international world.

\wp-settings.php

Old code:
[php]
188 // If already slashed, strip.
189 if ( get_magic_quotes_gpc() ) {
190 $_GET = stripslashes_deep($_GET );
191 $_POST = stripslashes_deep($_POST );
192 $_COOKIE = stripslashes_deep($_COOKIE);
193 $_SERVER = stripslashes_deep($_SERVER);
194 }
[/php]
New code:
[php]
188 // If already slashed, strip.
189 if ( get_magic_quotes_gpc() ) {
190 $_GET = stripslashes_deep($_GET );
191 $_POST = stripslashes_deep($_POST );
192 $_COOKIE = stripslashes_deep($_COOKIE);

193 }
[/php]
Why?
Magic_quotes_gpc() is a setting for the PHP server on your site. It automatically protects PHP database applications (like blogs) from common security breeches. It is the ONLY reason why there are not hundreds of WordPress blogs being crashed out there. magic_quotes_gpc protects the four ways of submitting information to the server: Gets, Posts (puts), Cookies, and Server settings (Server in this case includes information from your machine). WordPress simulates Magic quotes and doesn’t rely on the server settings. However, it doesn’t want to do the work twice and scramble the input. This change removes the line removes the slashes put in by Magic Quotes for the Server variable. To be quite honest, I’m not sure why yet… The Server variables must be special somehow in that we do want to double protect them. This doesn’t seem to make any sense to me. To be quite honest, I expected to see more protection around the server variables since they are a commonly abused area and are often used means of attacking websites. Maybe not removing the slashes – and thus allowing double slashes? – adds more protection? however to me it seems that slashed slashes would just produce scrambled results…. Maybe the developers wanted to show proof positive that these areas were protected? I’m missing something here…

Admin User Changes

OK this post is getting Way to long. So I am not going to go into the level of detail I did for the other area.
\wp-admin\admin.php – Protects a reference to plugins page
\wp-admin\admin-functions.php – There were several areas of protection added to this routine. It largely centers around using processed/retreived variables rather than variables that could be overridden by the users. It also blanks out or closes post settings that have no default values.
\wp-admin\admin-header.php – Enforces the priveledges to edit categories.
\wp-admin\edit-pages.php – Protects post edits by using a processed variable rather than one that could be supplied by the user.
\wp-admin\List-manipulation.php – Blocks hack attacks from malformed links.
\wp-admin\menu-header.php – Adds the ablity for plugins to give admin notices in the header.
\wp-admin\post.php – Ensures that posts can only be made by admins that have logged in through the control panel.
\wp-admin\user-edit.php – Ensures that the edit user event comes from the admin control pannel and not a hack attack.
\wp-admin\blogger.php – Adds a missing html header

Suffice it to say that these changes largely protect blog administrators that allow their Users to post.

Shared Units

\wp-includes\comment-functions.php Protect WP from malformed cookies
\wp-includes\functions.php Minor bug fix in date processing
\wp-includes\template-functions-general.php Adjustments to the date display methods
\wp-includes\template-functions-links.php The routine for testing user permissions was rewritten. Calls to that routine had to be updated.
\wp-includes\version.php – Upped the version number
\wp-includes\js\* – TinyMCE was updated.

the update to TinyMCE makes better but it is STILL horribly broken. I’ve still decided to turn it off for writing posts. Re-Editing posts is just IMPOSSIBLE with it on. It probably works if you ONLY use the limited buttons that are at the top of the post box, but if you use more than that, it just messes up.

Conclusions

This release does protect WordPress users from several forms of attack. Some of which I hadn’t thought of myself. I still don’t fully understand why the system does not strip out the slashes in the _server varibles before it re-applies them. Perhaps someone can address that in the comments, but that change does further increase the protection of an already vulnerable area and perhaps there was an avenue of attack in that area that I cannot see at this point. However, I do strongly recommend you apply this update. It makes you safer from attacks and spamming.

One Comment

Add a Comment

Your email address will not be published. Required fields are marked *