Wordpress gets a bad wrap, often cited as being insecure and subsequently overlooked as a platform for creating excellent websites. However, it is the plugins that often cause the issues and, by association, Wordpress gets the blame.
Whilst performing a pentest for a great client recently, we discovered two security vulnerabilities in a popular Wordpress plugin. These vulnerabilities can be exploited to expose private email addresses and create stored cross-site scripting (XSS), allowing attackers to compromise administrative accounts.
The BuddyBoss plugin has an issue with lack of input validation around the creation of Groups and an interesting way to generating user profile URIs.
When I identified the vulnerabilities that I'll explain in this post, we immediately:
Informed our client of the issue and a temporary mitigation plan
Contacted BuddyBoss
Got in touch with MITRE to assign the issues CVEs
The saving grace on the XSS issue is that whilst it is stored in BuddyBoss, it requires other plugins to trigger it. One such plugin is AccessAlly (more on why they are actually awesome later).
BuddyBoss have since made it clear that they think that neither issue is a security concern and that the XSS one does not even belong with them, despite the fact that they are the ones taking the input and storing it. Plugins that use that data should obviously validate input but that's a different issue entirely. Given the history of BuddyBoss not responding well to security issues (see CVE-2018-21014) we feel it is now time to go public with this issue and share a way to mitigate it, until BuddyBoss either silently fixes the issue or takes public responsibility and fixes it.
Details on CVE-2021-43334 - CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Versions affected:
1.8.0 and below
Here is a simple Proof of Concept (POC):
To ascertain if the current site is vulnerable, adding the following code to the Name or/and Description fields of a Group, and subsequently visiting any page showing the Group title will trigger the payload.
<iframe srcdoc="<img src=1 onerror=alert(1)>"></iframe>There are many, many pages that the Group name will appear, but you will need a secondary plugin to trigger the issue on most of them.
*authors note*
As we all know alert(1) shouldn't really be used for POC during your pentest, however using something like alert(document.domain) would have given away our clients details in this blog post, so don't yell at me.
CVE-2021-43334 Mitigation
Communication with BuddyBoss has ended with them confirming that they are not planning to fix this issue. The only way around this is to either disable/remove the BuddyBoss plugin or, where that is not possible, remove the ability for non-administrators to create Groups. It may also be possible to remove secondary plugins like but this does not mean that another plugin couldn't trigger it either now or in the future. The attack is stored by BuddyBoss and it is that plugin which should be avoided.
So, now, on to the second CVE we discovered in BuddyBoss.
Details on CVE-2021-44692 -
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Versions affected:
1.8.0 and below
POC: BuddyBoss Platform through to 1.8.0 allows remote attackers to obtain the email address of each user.
When creating a new user, it generates a Unique ID for their profile. This UID is their private email address with symbols removed and periods replaced with hyphens. For example:
JohnDoe@example.com would become /members/johndoeexample-com
Jo.test@example.com would become /members/jo-testexample-com
The members list is available to everyone and (in a default configuration) often without authentication. It is therefore trivial to collect a list of email addresses.
Due to the obviously sensative nature of this information we cannot give you screenshots for this issue.
CVE-2021-44692 Mitigation
There does not appear to be a good mitigation at this time, except to replace BuddyBoss. Whilst we are pleased to announce that this issue is now thankfully on the BuddyBoss roadmap, we are sad to see that it does not have any timeframe associated with it.
We strongly suggest you swap from BuddyBoss to avoid exposing your end-users' private email addresses or, if you cannot, we suggest you go and vote for this feature here (https://roadmap.buddyboss.com/c/105-customize-the-urls-of-member-profiles) which might urge them to hurry things up.
Good news!
Our client was also using the AccessAlly plugin and when we approached them with our concerns they responded very positively. They have created a new version of AccessAlly plugin that mitigates all the issues above! They sanitise the input from BuddyBoss and harmlessly deal with the malicious code. So whilst the stored XSS is still technically there, it won't be rendered by AccessAlly. Other plugins may still trigger them, so be warned! AccessAlly has also implemented a new way for usernames to be generated and so mitigating the CVE-2021-44692 issue as well.
We would like to thank Nathalie from New Software Marketing as well as the responsive and responsible team at AccessAlly. We hope that BuddyBoss will soon follow their lead, understanding that security is something that people are concerned with when it comes to third party plugins.