WordPress Out of the Box
User Enumeration
Out of the box, user accounts can be enumerated with unauthenticated REST API requests. This API will return all authors who have written at least one post. Additionally, the generated welcome post, automatically created on new installs, exposes the administrator user by default.
In the screen capture below, we can see 2 interesting pieces of metadata for the administrative user: its username (superadmin) and its email address hash in the form of a gravatar link (http://0.gravatar.com/avatar/6e2b22791df03c1290687b2807f52afd). Email MD5 hashes can be reversed (cracked) in most cases. For example, Dominique Bongard presented at PasswordCon 2013 that he manage to recover 45% from a sample of 2800 hashes taken on a french political website.
/wp/v2/users endpoints accessible by default |
Potential Hardening
The simplest way to avoid this user enumeration is to disable the REST API. It can be done by installing a third-party plugin. There are also plenty of manual code edits that are being used to avoid installing third-party plugins. The iThemes Security plugin does filtering on the most sensitive endpoints by default.
Examples of errors messages |
The Jetpack Plugin
Jetpack and WordPress.com
Jetpack comes with the promise of improving security, performance, and management. Being developed by Automattic, the company supporting WordPress.com, the plugin is said to be installed on 5 million WordPress instances. To activate the plugin, the user must authenticate with a valid wordpress.com account. Most of the dashboard features and settings are hosted on wordpress.com. With the help of the Jetpack plugin, wordpress.com will obtain an authentication token to allow the synchronization of data including the list of users and posts.
WordPress is connecting through a privileged XML-RPC connection
The Jetpack plugin by itself is not causing any harm, however, part of the data that it synchronizes on WordPress.com servers is exposed publicly with a documented REST API.
Looking at the REST API for potential information leaks, we can see that the main endpoints returning user information are protected.
REST URL | Require Authentication Token |
/sites/$site/users | YES |
/sites/$site/users/login:$user_id | YES |
/me | YES |
However, most of the user metadata is also publicly available on the posts endpoints. The following endpoints are returning post objects which include author metadata. The author object includes the username and the hashed e-mail via the Gravatar URL.
REST URL | Require Authentication Token |
/sites/$site/posts/$post_ID | NO |
/sites/$site/posts | NO |
Why are emails so important?
First, there are privacy concerns with the disclosure of user emails. A user might want to remain anonymous when publishing their personal blog. Some organizations might need to protect their employees to avoid attacks targeting them. Associated metadata, such the organization and website, could also be used to personalize phishing attacks.
While we could extend on the topic of privacy and phishing, the present article will focus on the application security aspects. Email disclosure of all users can greatly improve brute force attack success rates. As we live in an era of periodic password breaches, single factor authentication is more vulnerable than ever to brute force attacks. An attacker can correlate the list of a specific user’s email addresses against known passwords that they have used.
An automated bot could do the following steps:
- Enumerate the user’s emails for a given blog
- Attempt to log in with every password known for the specific emails
- For a successful login, verify the permission of the user.
- Install a malicious plugin / Edit template page (PHP) / Insert malicious HTML in article post / etc…
Quick data analysis
Since email addresses are in a relatively straightforward format, obfuscating them as MD5 in order to anonymize them is no longer sufficient. Using modern GPUs and simple rulesets we were able to deanonymize over 53 million emails out of the 91 million hashes we extracted with the WordPress.com API. 32 million users had one password leak in the past 10 years. This is at least 36% percent accounts that are more susceptible to credential stuffing attacks. The correlation was made using a collection of 2.6 billion leaked emails and passwords provided by Flare Systems.
When we analyzed the dataset, we verified the number of illegitimate accounts. Less than 1% of the accounts were either of invalid email format, temporary email inboxes or known spam emails. This is a sign that Automattic is actively closing spam accounts. The remaining emails are likely to be legitimate WordPress users.
Category | Numbers | |
Emails that could not be cracked (40%) | 36,381,990 | |
Cracked Emails (60%) | With at least one leaked password | 32,735,798 |
With no leaked password found | 20,644,054 | |
Invalid | 480,879 |
Organization | Number of Users | Alexa Rank |
newsfeed.time.com | 186 | 1524th |
vimeo.com/blog | 177 | 170th |
blog.ted.com | 120 | 1291st |
blog.etsy.com | 2570 | 76th |
techcrunch.com | 57 | 1754th |
wired.com | 1052 | 1525th |
devblogs.microsoft.com | 1000+ | 21st |
gblogs.cisco.com | 123 | 824th |
godaddy.com/garage | 1430 | 172nd |
books.disney.com | 14 | 4436th |
Moving Forward
Response from WordPress.com
Regarding the e-mail disclosure through the Gravatar URL, the Automattic team responded with the following message:
“Thanks for the report.
I have just confirmed with the team that Gravatar is working as it should be. The information that is exposed by Gravatar are intended for the public.”
Our interpretation is that Automattic is not willing to remove the Gravatar integration from their APIs.
Conclusion
Easy user enumeration is not a fatal flaw. However, it is something to keep in mind if you are deploying a blog for commercial or personal purposes. Here are a few ideas to mitigate this risk:
- Enforce multi-factor authentication for all your users with the JetPack plugin
- Force users to use generated passwords
- Disable the Jetpack plugin if you are not using any of its features
No comments:
Post a Comment