Several Critical Vulnerabilities Patched in UserPro WordPress Plugin

On May 1, 2023, the Wordfence Threat Intelligence team began the responsible disclosure process for multiple high and critical severity vulnerabilities they discovered in Kirotech’s UserPro plugin, which is actively installed on more than 20,000 WordPress websites.

Firewall rules were released by Wordfence in May and July. Wordfence states that they have no evidence to suggest that these vulnerabilities were known or targeted during this period, nor have we seen any evidence that they are currently being targeted.

We made an initial attempt to contact Kirotech, the vendor of UserPro, on May 1, 2023, but we did not receive a response until May 10, 2023, after many additional attempts. After providing full disclosure details, the developer released the first patch on July 27, 2023, and the final patch on October 31, 2023.

We urge users to update their sites to the latest patched version of UserPro, which is version 5.1.5 at the time of this writing, as soon as possible.

Source and more details: https://www.wordfence.com/blog/2023/11/several-critical-vulnerabilities-including-privilege-escalation-authentication-bypass-and-more-patched-in-userpro-wordpress-plugin

It’s Still Easy for Anyone to Become You at Experian

In the summer of 2022, KrebsOnSecurity documented the plight of several readers who had their accounts at big-three consumer credit reporting bureau Experian hijacked after identity thieves simply re-registered the accounts using a different email address. Sixteen months later, Experian clearly has not addressed this gaping lack of security. I know that because my account at Experian was recently hacked, and the only way I could recover access was by recreating the account.

Entering my SSN and birthday at Experian showed my identity was tied to an email address I did not authorize.

I recently ordered a copy of my credit file from Experian via annualcreditreport.com, but as usual Experian declined to provide it, saying they couldn’t verify my identity. Attempts to log in to my account directly at Experian.com also failed; the site said it didn’t recognize my username and/or password.

A request for my Experian account username required my full Social Security number and date of birth, after which the website displayed portions of an email address I never authorized and did not recognize (the full address was redacted by Experian).

I immediately suspected that Experian was still allowing anyone to recreate their credit file account using the same personal information but a different email address, a major authentication failure that was explored in last year’s story, Experian, You Have Some Explaining to Do. So once again I sought to re-register as myself at Experian.

The homepage said I needed to provide a Social Security number and mobile phone number, and that I’d soon receive a link that I should click to verify myself. The site claims that the phone number you provide will be used to help validate your identity. But it appears you could supply any phone number in the United States at this stage in the process, and Experian’s website would not balk. Regardless, users can simply skip this step by selecting the option to “Continue another way.”

Experian then asks for your full name, address, date of birth, Social Security number, email address and chosen password. After that, they require you to successfully answer between three to five multiple-choice security questions whose answers are very often based on public records. When I recreated my account this week, only two of the five questions pertained to my real information, and both of those questions concerned street addresses we’ve previously lived at — information that is just a Google search away.

Assuming you sail through the multiple-choice questions, you’re prompted to create a 4-digit PIN and provide an answer to one of several pre-selected challenge questions. After that, your new account is created and you’re directed to the Experian dashboard, which allows you to view your full credit file, and freeze or unfreeze it.

At this point, Experian will send a message to the old email address tied to the account, saying certain aspects of the user profile have changed. But this message isn’t a request seeking verification: It’s just a notification from Experian that the account’s user data has changed, and the original user is offered zero recourse here other than to a click a link to log in at Experian.com.

If you don’t have an Experian account, it’s a good idea to create one. Because at least then you will receive one of these  emails when someone hijacks your credit file at Experian.

And of course, a user who receives one of these notices will find that the credentials to their Experian account no longer work. Nor do their PIN or account recovery question, because those have been changed also. Your only option at this point is recreate your account at Experian and steal it back from the ID thieves!

In contrast, if you try to modify an existing account at either of the other two major consumer credit reporting bureaus — Equifax or TransUnion — they will ask you to enter a code sent to the email address or phone number on file before any changes can be made.

Reached for comment, Experian declined to share the full email address that was added without authorization to my credit file.

“To ensure the protection of consumers’ identities and information, we have implemented a multi-layered security approach, which includes passive and active measures, and are constantly evolving,” Experian spokesperson Scott Anderson said in an emailed statement. “This includes knowledge-based questions and answers, and device possession and ownership verification processes.”

Anderson said all consumers have the option to activate a multi-factor authentication method that’s requested each time they log in to their account. But what good is multi-factor authentication if someone can simply recreate your account with a new phone number and email address?

Several readers who spotted my rant about Experian on Mastodon earlier this week responded to a request to validate my findings. The Mastodon user @Jackerbee is a reader from Michican who works in the biotechnology industry. @Jackerbee said when prompted by Experian to provide his phone number and the last four digits of his SSN, he chose the option to “manually enter my information.”

“I put my second phone number and the new email address,” he explained. “I received a single email in my original account inbox that said they’ve updated my information after I ‘signed up.’ No verification required from the original email address at any point. I also did not receive any text alerts at the original phone number. The especially interesting and egregious part is that when I sign in, it does 2FA with the new phone number.”

The Mastodon user PeteMayo said they recreated their Experian account twice this week, the second time by supplying a random landline number.

“The only difference: it asked me FIVE questions about my personal history (last time it only asked three) before proclaiming, ‘Welcome back, Pete!,’ and granting full access,” @PeteMayo wrote. “I feel silly saving my password for Experian; may as well just make a new account every time.”

I was fortunate in that whoever hijacked my account did not also thaw my credit freeze.  Or if they did, they politely froze it again when they were done. But I fully expect my Experian account will be hijacked yet again unless Experian makes some important changes to its authentication process.

It boggles the mind that these fundamental authentication weaknesses have been allowed to persist for so long at Experian, which already has a horrible track record in this regard.

In December 2022, KrebsOnSecurity alerted Experian that identity thieves had worked out a remarkably simple way to bypass its security and access any consumer’s full credit report — armed with nothing more than a person’s name, address, date of birth, and Social Security number. Experian fixed the glitch, and acknowledged that it persisted for nearly seven weeks, between Nov. 9, 2022 and Dec. 26, 2022.

In April 2021, KrebsOnSecurity revealed how identity thieves were exploiting lax authentication on Experian’s PIN retrieval page to unfreeze consumer credit files. In those cases, Experian failed to send any notice via email when a freeze PIN was retrieved, nor did it require the PIN to be sent to an email address already associated with the consumer’s account.

A few days after that April 2021 story, KrebsOnSecurity broke the news that an Experian API was exposing the credit scores of most Americans.

More greatest hits from Experian:

2022: Class Action Targets Experian Over Account Security
2017: Experian Site Can Give Anyone Your Credit Freeze PIN
2015: Experian Breach Affects 15 Million Customers
2015: Experian Breach Tied to NY-NJ ID Theft Ring
2015: At Experian, Security Attrition Amid Acquisitions
2015: Experian Hit With Class Action Over ID Theft Service
2014: Experian Lapse Allowed ID Theft Service Access to 200 Million Consumer Records
2013: Experian Sold Consumer Data to ID Theft Service

Source: https://krebsonsecurity.com/2023/11/its-still-easy-for-anyone-to-become-you-at-experian/

Unauthenticated SQL Injection Vulnerability Addressed in WP Fastest Cache 1.2.2

During an internal review of the WP Fastest Cache plugin, the WPScan team discovered a serious SQL injection vulnerability. This vulnerability may allow unauthenticated attackers to read the full contents of the WordPress database using a time‑based blind SQL injection payload.

Upon discovering the vulnerability, we promptly alerted the plugin development team, who released version 1.2.2 to fix the issue. It is crucial for administrators to ensure their WordPress installations are fully updated to safeguard against this vulnerability.

Source and more details: https://a8cteam5105.wordpress.com/blog/unauthenticated-sql-injection-vulnerability-addressed-in-wp-fastest-cache-1-2-2/

Possible site takeover through stolen API credentials in combination with SQLi – (MalCare <= 5.09)

MalCare uses broken cryptography to authenticate API requests from its remote servers to connected WordPress sites.

Requests are authentication by comparing a shared secret stored as plaintext in the WordPress database to the one provided by MalCare’s remote application.

This can allow attackers to completely take over the site because they can impersonate MalCare’s remote application and perform any implemented action, including, but not limited to:

  • Creating malicious admin users.
  • Uploading random files to the site.
  • Installing/Removing plugins.

This is exploitable if any of the below pre-conditions are given:

MalCare has received the full details of this vulnerability three months before this public release, and despite us offering (free) help, they subtly dismissed it because “supposedly” this is the industry standard for API authentication.

Note: WPUmbrella had the same conceptual vulnerability and fixed it within days.

Furthermore, concerns were raised, because the vulnerability requires a pre-condition that on its own, would be a vulnerability.

While this is true, the irony should be obvious here:

  • MalCare, being a Malware Scanner, is only “useful” if your site has been infected with Malware.
  • All Malware can read data from the database and steal the shared secret.
  • Instead of infecting sites with “actual” Malware, hackers can steal the API key and then remove the Malware.
  • ==> MalCare gives any Malware an undetectable, indefinite backdoor that can be used to reinfect sites repeatedly.

WPRemote and Blogvault have identical vulnerabilities because they all share 99% of their code.

Source: https://snicco.io/vulnerability-disclosure/malcare/site-takeover-through-stolen-api-credentials-in-combination-with-sqli-malcare-5-09

WordPress 6.4.1 Fixes a Critical cURL/Requests Bug

WordPress contributors have worked quickly over the past 24 hours to prepare a 6.4.1 maintenance release after a critical bug emerged from a change in the Requests library, causing problems with updates on servers running older versions of cURL.

Hosting companies began reporting widespread impact of the bug. Tom Sommer, from one of Denmark’s largest hosting companies, filed a GitHub issue outlining how the cURL timeouts were affecting sites:

  • #657 breaks downloads towards https://api.wordpress.org/ and many other sites when using Curl 7.29.0 (and perhaps other versions)
  • Error: RuntimeException: Failed to get url 'https://api.wordpress.org/core/version-check/1.7/?locale=en_US': cURL error 28: Operation timed out after 10000 milliseconds with 807 out of -1 bytes received.
  • It also causes issues with the REST API in Site Health with the error: REST API response: (http_request_failed) cURL error 28: Operation timed out after 10005 milliseconds with XXX out of XXX bytes received”
  • It also prevents WordPress plugin and core updates, basically anything that relies on the internal Curl handler in WordPress.

The issue became a top priority as it wasn’t clear how it would be possible for users to receive an update.

“Even if you fix this now the issue prevents any future auto-upgrade to a 6.4.1, since it breaks Curl requests, so the only way for people to update would be manually,” Sommer said. “The longer you wait, the bigger the problem will become.”

Nexcess reported tens of thousands of sites being affected by the bug. The issue was beyond what most users would be able to manually patch on their own, relegating hosts to figure out how to update their customers.

“All my websites locked after updating to WordPress 6.4,” Javier Martín González reported. “The ones without updates are working normally.”

The bug was also reported to be causing causing potential Stripe API, WP-Admin, and performance issues.

Liquid Web/Nexcess product manager Tiffany Bridge summarized how this problem emerged:

It looks like:

  • Someone reported a bug having to do with an interaction between his Intrusion Protection System and WordPress
  • They then submitted their own patch to WordPress
  • The project lead for that area asked the submitter to write tests, which he did not do
  • Then they merged the PR anyway, despite the lack of tests
  • Meanwhile hosts are all going to have to revert that change ourselves on our own fleets so that our customers can still have little things like core and plugin updates if we are running an affected cURL version. (7.29 confirmed, there may be others)

WordPress core contributors will have to get to the bottom of how this bug was allowed through, via a postmortem or other discussion to prevent this from happening on such a large scale in the future.

WordPress 6.4.1 updates the Requests library from version 2.0.8 to 2.0.9. as a hotfix release to mitigate the issue. It reverts the problematic change. Version 6.4.1 also includes fixes for three other separate issues. Automatic updates shipped out this evening for anyone with sites that support automatic background updates.

Source: https://wptavern.com/wordpress-6-4-1-fixes-a-critical-curl-requests-bug

Several Critical Vulnerabilities Patched in AI ChatBot Plugin for WordPress

On September 28, 2023, the Wordfence Threat Intelligence team initiated the responsible disclosure process for multiple vulnerabilities in AI ChatBot, a WordPress plugin with over 4,000 active installations.

After making their initial contact attempt on September 28th, 2023, they received a response on September 29, 2023 and sent over their full disclosure details. Receipt of the disclosure by the vendor was acknowledged the same day and a fully patched version of the plugin was released on October 19, 2023.

Wordfence issued a firewall rule to protect paid customers. Users of the free Wordfence plugin will receive the same protection on October 29, 2023.

Please note that these vulnerabilities were originally fixed in 4.9.1 (released October 10, 2023). However, some of them were reintroduced in 4.9.2 and then subsequently patched again in 4.9.3. We recommend that all Wordfence users update to version 4.9.3 or higher immediately.

Source and full details: https://www.wordfence.com/blog/2023/10/several-critical-vulnerabilities-patched-in-ai-chatbot-plugin-for-wordpress

4 Million WordPress Sites affected by Stored Cross-Site Scripting Vulnerability in LiteSpeed Cache Plugin

On August 14, 2023, the Wordfence Threat Intelligence team identified and began the responsible disclosure process for a stored Cross-Site Scripting (XSS) vulnerability in LiteSpeed Cache plugin, which is actively installed on more than 4,000,000 WordPress websites, making it the most popular cache plugin. The vulnerability enables threat actors with contributor-level permissions or higher to inject malicious web scripts into pages using the plugin’s shortcode.

All WordFence customers are protected against any exploits targeting this vulnerability by the Wordfence firewall’s built-in Cross-Site Scripting protection.

WordFence contacted The LiteSpeed Cache Team on August 14, 2023, and we received a response on the same day. After providing full disclosure details, the developer team made a patch on August 16, 2023, and released it to the WordPress repository on October 10, 2023. We would like to commend the LiteSpeed Technologies for their prompt response and timely patch.

We urge users to update their sites with the latest patched version of LiteSpeed Cache, version 5.7 at the time of this writing, as soon as possible.

Source and more details: https://www.wordfence.com/blog/2023/10/4-million-wordpress-sites-affected-by-stored-cross-site-scripting-vulnerability-in-lightspeed-cache-plugin

4 Million WordPress Sites affected by Stored Cross-Site Scripting Vulnerability in LiteSpeed Cache Plugin

The popular LiteSpeed WordPress plugin patched a vulnerability that compromised over 4 million websites, allowing hackers to upload malicious scripts.

LiteSpeed was notified of the vulnerability two months ago on August 14th and released a patch in October.

Cross-Site Scripting (XSS) Vulnerability

Wordfence discovered a Cross-Site Scripting (XSS) vulnerability in the LiteSpeed plugin, the most popular WordPress caching plugin in the world.

XSS vulnerabilities are generally a type that takes advantage of a lack of a security process called data sanitization and escaping.

Sanitization is a technique that filters what kind of files can be uploaded via a legitimate input, like on a contact form.

In the specific LiteSpeed vulnerability, the implementation of a shortcode functionality allowed a malicious hacker to upload scripts they otherwise would not be able to had the proper security protocols of sanitization/escaping data been in place.

The WordPress developer page describes the sanitization security practice:

“Untrusted data comes from many sources (users, third party sites, even your own database!) and all of it needs to be checked before it’s used.

…Sanitizing input is the process of securing/cleaning/filtering input data.”

Another WordPress developer page describes the recommended process of escaping data like this:

“Escaping output is the process of securing output data by stripping out unwanted data, like malformed HTML or script tags.

This process helps secure your data prior to rendering it for the end user.”

This specific vulnerability requires that the hacker first obtain contributor level permissions in order to carry out the attack, which makes carrying out the attack more complicated than other kinds of threats that are unauthenticated (require no permission level).

According to Wordfence:

“This makes it possible for threat actors to carry out stored XSS attacks. Once a script is injected into a page or post, it will execute each time a user accesses the affected page.

While this vulnerability does require that a trusted contributor account is compromised, or a user be able to register as a contributor, successful threat actors could steal sensitive information, manipulate site content, inject administrative users, edit files, or redirect users to malicious websites which are all severe consequences.”

Which Versions of LiteSpeed Plugin Are Vulnerable?

Versions 5.6 or less of the LiteSpeed Cache plugin are vulnerable to the XSS attack.

Users of the LiteSpeed Cache are encouraged to update their plugin as soon as possible to the latest version, 5.7 which was released on October 10, 2023.

Source and more details: https://www.wordfence.com/blog/2023/10/4-million-wordpress-sites-affected-by-stored-cross-site-scripting-vulnerability-in-lightspeed-cache-plugin/

See also: https://www.searchenginejournal.com/wordpress-litespeed-plugin-vulnerability-affects-4-million-websites/499074/#close

Unauthenticated File Upload Vulnerability Addressed in Royal Elementor Addons and Templates 1.3.79

During an investigation of a series of website being actively compromised we noticed the constant presence of the Royal Elementor Addons and Templates plugin installed. And all sites had at least one malicious file dropped into the /wpr-addons/forms/ directory.

As we reviewed the plugin it was found that the upload ajax action wasn’t properly validating the uploaded file’s extensions, allowing bad actors to bypass the check and drop malicious files to the /wpr-addons/forms/ directory.

Upon identifying the vulnerability, we promptly alerted the plugin development team, who released version 1.3.79 to fix the issue. It is crucial for administrators to ensure their WordPress installations are fully updated to safeguard against this vulnerability.

Source and full details: https://wpscan.com/blog/unauthenticated-file-upload-vulnerability-addressed-in-royal-elementor-addons-and-templates-1-3-79/

and https://www.wordfence.com/blog/2023/10/psa-critical-unauthenticated-arbitrary-file-upload-vulnerability-in-royal-elementor-addons-and-templates-being-actively-exploited/

Finding A RCE Gadget Chain In WordPress Core

During a recent team gathering in Belgium, WPScan had an impromptu Capture The Flag game that included a challenge with an SQL Injection vulnerability occurring inside an INSERT statement, meaning attackers could inject random stuff into the targeted table’s columns, and query information from the database, the intended “flag” being the credentials of a user on the affected blog.

The vulnerable SQL query inserted new rows into the wp_termmeta table, which while WPScan knew it could potentially lead to Object Injection attacks due to the inserted metadata being passed through maybe_unserialize upon retrieval, WPScan didn’t think too much about it since the common thought on the matter was that there was no known current RCE gadget chain in WordPress Core, and thus the challenge was “safe” since it didn’t use any other external plugins.

This proved to be enough to win that flag, however, the thought that there might be an alternative solution to the challenge piqued our curiosity. What if there was a working RCE gadget chain in Core waiting to be found?

Turns out, there was a way, which the WordPress Security Team fixed on version 6.3.2 by preventing several classes used in the final chain from either being unserialized at all, or restricting what some of their unserialized properties may contain.

Source and more details: https://wpscan.com/blog/finding-a-rce-gadget-chain-in-wordpress-core/