{"id":595,"date":"2009-09-14T17:27:09","date_gmt":"2009-09-14T10:27:09","guid":{"rendered":"http:\/\/adityo.blog.binusian.org\/?p=595"},"modified":"2009-09-14T17:27:09","modified_gmt":"2009-09-14T10:27:09","slug":"recent-wordpress-admin-login-security-vulnerability","status":"publish","type":"post","link":"https:\/\/adityo.blog.binusian.org\/?p=595","title":{"rendered":"Recent WordPress Admin login Security Vulnerability"},"content":{"rendered":"

It was discovered by\u00a0Laurent Gaffie, who posted it to Full-Disclosure\u00a0\u00a0http:\/\/seclists.org\/fulldisclosure\/2009\/Aug\/0113.html<\/a>. \u00a0I quote from\u00a0http:\/\/preachsecurity.blogspot.com\/2009\/08\/wordpress-bugs-disturbing-vulnerability.html<\/a><\/p>\n

From the disclosure, submitting a query into the server like so<\/p>\n

http:\/\/domain_name.tld\/wp-login.php?action=rp&key[]<\/span>=<\/p><\/blockquote>\n

causes it to simply skip verification and just re-set the password… how interesting!<\/p>\n

Under ordinary circumstances, a user clicks on “forgot my password” then the server sends a one-time URL complete with random “key” to re-set the password. The thing to remember here is that the field in the user’s record remains empty (null<\/span>) until a password reset is requested! The user then gets an email with a URL that looks something like this:<\/p>\n

http:\/\/domain_name.tld\/wordpress\/wp-login.php?action=rp&<\/span>key=RANDOM0987654321<\/span><\/p><\/blockquote>\n

which he or she will click on. The server will then parse the request and compare the key<\/span> parameter against the key<\/span> stored in that user’s database record. Easy so far.<\/p>\n

Guessing the key is probably not realistic and not worth the attack bandwidth… but if you could just reset passwords without knowing the key then that would be insanely annoying, wouldn’t it? The $64k question is… why does submitting a key[] (an empty array)<\/span> work?<\/p>\n

Looking at this issue it’s clear there are several things possibly at play, including a little bug that may plague more PHP apps than we give it credit for – casting. Looking at the very first relevant line:<\/p>\n

$key = preg_replace(‘\/[^a-z0-9]\/i’, ”, $key);<\/p><\/blockquote>\n

it appears as though this looks and works just fine… as long as the input in the $key variable is a string<\/span> the line goes about making sure you only have alpha-numeric values in the $key parameter… golden so far. If you happen to try and stuff an array<\/span> in there (or worse, an empty array), as evidenced by the key[]= above, this all goes sideways. As you’ll now end up with an array in the $key variable… which the rest of the code is clearly not expecting.<\/p>\n

Moving on… let’s look at the SQL query string that gets built…<\/p>\n

$user = $wpdb->get_row($wpdb->prepare(“SELECT * FROM $wpdb->users WHERE user_activation_key = %s<\/span>“, $key<\/span>));<\/p><\/blockquote>\n

Aha! If you’ve got an array in the $key variable, and you try to run this select statement then you end up with a very ugly array<\/span> being flattened and stuffed into the %s (string<\/span>)… What happens here is that WordPress will flatten the array – take the first value of the key[] which will be null and shove it into %s… and then go off and perform its database query. It ends up ooking something like this:<\/p>\n

SELECT * FROM $wpdb->users WHERE user_activation_key = null<\/span><\/p>\n

<\/span>Since the administrator has not requested a password change<\/span>, the value of $key,<\/span> in the admin record will be null<\/span>… thus you have a match and a password reset takes place. Makes perfect sense… Whoops.<\/p>\n

Now presumably this hits admin<\/span> every time since this is the first user typically created in the database, but I’m just speculating now since I haven’t had a chance to thoroughly test this yet.<\/p>\n

Even more interesting is the fix from the WordPress folks…
\n<\/p>\n

if ( empty( $key ) || is_array( $key ) <\/ins>)<\/span><\/p><\/blockquote>\n

The “patch” simply replaces the broken if empty<\/span> statement and adds an is_array<\/span>, which will check to see if we’ve accidentally<\/span> left key blank or passed in an array and bomb if we have. Of course, this patches this<\/span> bug but …<\/p>\n

Mike Bailey (@mckt_ on Twitter) and I were poking at this and wondered… why wouldn’t you use “is_string<\/a>” instead? Hasty coding? Why take the blacklist vs. whitelist approach?<\/p>\n

Obviously, you have to wonder now… how many other bugs are there of this type in other PHP apps? What about other parts of WordPress? Hey… isn’t there a rumor going around that Kaminsky and Matasano got taken by an undisclosed WordPress bug? Hrmm… While I agree with Mike’s assessment that these types of bugs are rare, PHP certainly makes them more possible, especially when it doesn’t have the opportunity to throw errors in a situation like this.<\/p>\n

I think Mike’s comment sums it up nicely though…
\n<\/p>\n

“It’s [the source] full of WTF moments… I’m amazed anybody uses WordPress”<\/p><\/blockquote>\n

<\/span>Indeed.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

It was discovered by\u00a0Laurent Gaffie, who posted it to Full-Disclosure\u00a0\u00a0http:\/\/seclists.org\/fulldisclosure\/2009\/Aug\/0113.html. \u00a0I quote from\u00a0http:\/\/preachsecurity.blogspot.com\/2009\/08\/wordpress-bugs-disturbing-vulnerability.html From the disclosure, submitting a query into the server like so http:\/\/domain_name.tld\/wp-login.php?action=rp&key[]= causes it to simply skip verification and just re-set the password… how interesting! Under ordinary circumstances, a user clicks on “forgot my password” then the server sends a one-time URL […]<\/p>\n","protected":false},"author":386,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[40],"tags":[3470],"class_list":["post-595","post","type-post","status-publish","format-standard","hentry","category-wordpress","tag-wordpress-security-vulnerability"],"_links":{"self":[{"href":"https:\/\/adityo.blog.binusian.org\/index.php?rest_route=\/wp\/v2\/posts\/595","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/adityo.blog.binusian.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/adityo.blog.binusian.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/adityo.blog.binusian.org\/index.php?rest_route=\/wp\/v2\/users\/386"}],"replies":[{"embeddable":true,"href":"https:\/\/adityo.blog.binusian.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=595"}],"version-history":[{"count":1,"href":"https:\/\/adityo.blog.binusian.org\/index.php?rest_route=\/wp\/v2\/posts\/595\/revisions"}],"predecessor-version":[{"id":596,"href":"https:\/\/adityo.blog.binusian.org\/index.php?rest_route=\/wp\/v2\/posts\/595\/revisions\/596"}],"wp:attachment":[{"href":"https:\/\/adityo.blog.binusian.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=595"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/adityo.blog.binusian.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=595"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/adityo.blog.binusian.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=595"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}