On June 24th, 2024, the Wordfence Threat Intelligence Team became aware of a WordPress plugin, Social Warfare, that was infected with malware through the WordPress repository. Upon further investigation, our team quickly identified 4 additional affected plugins through our internal Threat Intelligence platform. We immediately notified the WordPress Plugin’s Team and they removed the malicious content from the plugins and performed some automated actions to invalidate the passwords of the injected administrator accounts.
The injected malware was used to exfiltrate data, inject malicious administrative user accounts, and inject SEO spam as well as crypto miners and drainers into the footer of websites. Roughly 35,000 sites could have been affected by this supply chain attack, though it’s unclear how many actually updated to a vulnerable version.
At this point, the Wordfence Threat Intelligence team has released a series of malware signatures that can be used to detect the malicious code on any compromised site using Wordfence the plugin, or Wordfence CLI – the command line security scanner. Wordfence Premium, Care and Response users received these malware signatures immediately, and Wordfence free users will receive them after a 30 day delay on July 25th, 2024. All Wordfence users will be notified by the Wordfence plugin and Wordfence CLI if they are running a vulnerable version of one of the plugins, and they should update the plugins immediately where available.
Social Warfare 4.4.6.4 – 4.4.7.1
Vulnerable versions: 4.4.6.4 to 4.4.7.1
Patched version: 4.4.7.2 (malicious code has been removed)
Fully patched version: 4.4.7.3 (code to invalidate admin passwords was added)
Blaze Widget 2.2.5 – 2.5.2
Vulnerable versions: 2.2.5-2.5.2
Patched version: 2.5.3 (malicious code has been removed)
Fully patched version: 2.5.4 (code to invalidate admin passwords was added)
Wrapper Link Element 1.0.2 – 1.0.3
Vulnerable versions: 1.0.2-1.0.3
Patched version: 1.0.4 (malicious code has been removed)
Fully patched version: 1.0.5 (code to invalidate admin passwords was added)
Contact Form 7 Multi-Step Addon 1.0.4 – 1.0.5
Vulnerable versions: 1.0.4-1.0.5
Patched version: 1.0.6 (malicious code has been removed)
Fully patched version: 1.0.7 (code to invalidate admin passwords was added)
Simply Show Hooks 1.2.2
Vulnerable version: 1.2.2
Patched version: 1.2.1
Note: The plugin response team reverted the changes, however the patched version is set to 1.2.1 which is lower than the affected version. It’s unclear if an infected version (1.2.2) was ever officially deployed.
While we plan to follow-up later this week with a thorough analysis of the malware, we wanted to shed some light on how this situation occurred in the first place and what can be done to prevent it from happening again in the future. WordPress.org officially released a statement today, that the incident occurred due to credential reuse. Five WordPress.org accounts with commit access were compromised due to the accounts utilizing passwords found in external data breaches.
A Brief History on Supply Chain Attacks in WordPress
This isn’t the first time we’ve seen a supply chain attack on WordPress. In the past, we investigated and led the story about Mason Soiza, a malicious threat actor who bought a series of WordPress plugins for the sole purpose of injecting SEO pharma spam into them. We’ve seen plugin authors with malicious intent inject malware to leverage their paying customers to DDoS competitors and harvest user data in the Pipdig scandal, and we’ve seen other plugin authors simply inject backdoors into their plugin allowing them to log in as administrators. We’ve even seen PHP itself become the target of a supply chain attack, that luckily wasn’t successful, though would have led to remote code execution on web applications running PHP.
This isn’t limited to just WordPress. We’ve also covered the story on SolarWinds back in 2020 which was a Supply Chain attack impacting thousands of organizations and dove into who might be responsible.
A Reminder: What is a Supply Chain Attack?
A supply chain attack occurs when one element in a chain of supply (i.e. software/tool/product/etc.) becomes compromised thus affecting whoever is the recipient of the software/tool/product down the chain. It is a prime target for attackers as vendors often trust their suppliers’ security based on information they’ve provided them, and vendors often don’t do extra due diligence checks with each delivery. WordPress is a prime example. WordPress.org and plugin developers are the supplier, while WordPress site owners are the ones using the product and receiving the supply. Most site owners don’t review each individual code update for their plugins and themes, trusting that the vendors are engaged in proper security measures. This means site owners typically update plugins and themes without reviewing them for any malicious code.
It’s no surprise that WordPress plugins and themes, an element in the WordPress supply chain, are a prime target for threat actors. WordPress site owners are often reminded that the best practice is to keep plugins and themes up to date, making it fairly easy for an attacker to be successful in infecting a large number of victim sites once they go to update their plugins/themes, granted the attacker is able to infect the plugin or theme prior to it being updated on the WordPress site.
It’s also worth mentioning that there are many potential targets for threat actors wishing to compromise the supply chain of WordPress. For example, inexperienced developers using random code tutorials, poorly trained AI introducing vulnerabilities and malware, external libraries used in plugin code, committer accounts on WordPress.org, and even the infrastructure supporting these supply points could all be targets.
Any one of these points in the WordPress supply chain can lead to several thousands or even millions, in extreme and rare cases, sites being compromised. An attacker would only need to infect one point to achieve mass success, making plugins and themes a prime target.
Who Was Behind This, and How Did it Happen?
Prior to WordPress.org releasing a statement, we reviewed the evidence available and made the determination that this was likely a series of developer account compromises. While this article was written prior to the released statement, we’ve left the investigation portion found below in tact for educational purposes.
During our investigation, we found that there appeared to be no clear correlation between the various plugin authors making the commits that would lead us to believe that someone took ownership of these plugins and then infected them. Further, considering the malicious updates were available in the SVN, it was not likely the attacker infected a server and pushed updates to all of these plugins bypassing the standard release cycle. The attacker simply had access to WordPress.org accounts, which also provided access to commit to the SVN repository.
This led us to two potential scenarios. The first was that these developer accounts with commit access were simply compromised and then leveraged to push updates to these plugins, and the second was that WordPress.org infrastructure was compromised in some way that made it possible for the attacker to commit updates to the plugins. We believed the former of the two, that these developer accounts were compromised, was the most likely for several reasons. We had no reason or evidence to suspect that WordPress.org infrastructure was compromised, and the following highlights why we suspected it was compromised developer accounts as the root cause.
The WordPress Plugins Affected Have No Correlation
None of the affected plugins had more than 40,000 users, and there was no relationship between the various different plugins. This means that instead of it being a targeted and precise attack, it was likely based on the luck of the draw (i.e. which accounts the attacker could gain access to). If the attacker had more widespread access to the repository, we would have expected more stealth, more precision, and more care with chosen targets.
Unsophisticated Code and Suspicious Timeline of Events
Our team reviewed the various commits by the threat actors which also had an odd timeline of events. The first plugin that appears to have been infected was Blaze Widgets, a plugin that hadn’t been updated in 4 years, which all of a sudden had a commit with the message recon four months ago. Recon is generally short for Reconnaissance which is a term often used in the security world when doing information gathering and testing targets before actually launching an attack. The threat actor may have had a foothold as early as 3 months ago if this commit was them performing reconnaissance to see if it would work and if they would get detected.
After that commit we see the next one about 4 days ago on June 21st, which appears to be testing the plugin’s updating mechanism. This was the first malicious commit across the 5 affected plugins.
After that, there is a series of commits all within the next two days with the threat actor manipulating and testing their new code before what looks like one of the final payloads being uploaded on June 24th, 2024.
We suspect that this plugin, which only has 10 active installations, was the test plugin for the threat actor, prior to them launching the malicious code in the plugins with larger installations counts.
It’s also worth noting the code is well commented, which is fairly uncommon to see in malware, so the attacker likely used an AI tool to help generate some of the code, or they were copying it from other sources.
This lack of evasion and sequence of events leads us to believe that the attacker may not have been very sophisticated.
Lax Security Controls on Accounts with Commit Access
As it stands, WordPress.org does not currently enforce or require any security measures for account owners with access to perform software commits. It does however, provide access to some tools such as 2FA for .org accounts and release confirmation emails, though given the history of security vulnerabilities in WordPress plugins and themes, it’s likely a fair amount of developers are not actually utilizing these security features.
This means that if a developer’s account is compromised through a password, there is no second layer of authentication providing protection against unauthorized commits.
All of the Commits Were from Different Users Associated with the Respective Repositories
All of the malicious commits came from different user accounts, all of which had previously issued commits to their respective repository. This rules out the idea that a single account or piece of infrastructure was compromised allowing the threat actor to commit to these various repositories.
Committer Accounts Currently Appear Disabled
We did find that the five plugin author accounts associated with the commits appear to be disabled, and additional plugins under their development have been closed for downloads. This is likely to prevent any further compromise of any plugins associated with those accounts.
Once we completed our investigation, we assumed that the developer accounts with commit access were likely compromised, and the mostly likely reason is that the developers were using weak or reused passwords, which is a fairly common source of compromise. We suspect these developers didn’t have any extra security controls enabled, so there was nothing standing in the way of the attacker committing malicious code once the account was compromised. WordPress.org corroborated our theory today when announcing that the 5 accounts were compromised due to credential reuse.
Developers and Organizations: How Can This Be Prevented in the Future For Your Plugins and Themes?
With this now in the history books, it’s time to start taking preventative action. Plugin vendors and organizations should start improving their security to ensure a situation like this doesn’t occur again in the future through their plugins and themes. Utilizing defense in depth practices, it’s best to implement a few layers of protection against unauthorized access. The following is a list of recommendations from the Wordfence team on how you can secure your WordPress.org accounts from unauthorized access and commits.
Utilize Release Confirmation Emails
WordPress.org introduced a feature called “Release Confirmation Emails” 3 years ago. This feature makes it a requirement for plugin committers to verify a release through a tokenized link that is emailed to them as needed.
“When WordPress.org detects a new version has been tagged in SVN, all committers are automatically sent an email notifying them that a new release is pending, who made it, and a link to the dashboard to confirm the release.”
All WordPress.org vendors should ensure they have this feature enabled for their plugins, and it can be managed from the Release Management dashboard. This is a critical feature that can help prevent unauthorized commits from being released.
Software vendors can enable this feature by navigating to the plugin’s page and clicking `Advanced View.`
Once there, you can find the `Release Confirmation` section where you can enable release confirmations.
Use Strong (Unique) Passwords For All Accounts with Commit Access
Strong and unique passwords are important for any account, but are exceptionally crucial when the account can perform actions like committing code. All users with commit access should use a strong password which is generally at least 12 characters (WordPress.org recommends 20) with a combination of letters, numbers, symbols, and cases. You should also never share passwords across accounts so that if one password is compromised, no other accounts will be compromised.
Enable 2-Factor Authentication For All .org Accounts
While 2-Factor Authentication can be seen as a pain by many, it is a crucial step to securing accounts from unauthorized access. It is a second line of defense that is often not able to be bypassed when a user’s password is compromised thus blocking any further compromise of the account and escalation of access. Please note that while this won’t provide 2FA on commits, it will provide protection against compromised accounts that could be leveraged further in an attack.
This can be enabled under a user’s account by going to ‘Edit Account.’
Monitor Your Own Plugin/Themes Release Independently
Configure a notifier that alerts you when a new version of the software you maintain is released, or better yet when a new commit is made. That will allow you to take action immediately if you spot a release or commit that you know was not authorized.
Limit Commit Access to Plugins
Following the principle of least privilege, only authorized users should have access to commit changes to software repositories. Always be sure to periodically review your list of committers and revoke access to any users that should no longer have access to commit, even if you think there is a small chance that user might need it in the future). This will reduce the available attack surface and limit the chance of success when an attacker is targeting individual users with poor security hygiene.
What Can Site Owners Do to Protect Themselves?
We understand that this can be incredibly alarming for many site owners who trust that the plugins they are updating on their site won’t be infected with malicious code. Unfortunately, it will be impossible to entirely eliminate the risks associated with supply chain attacks, so it is more important to focus on minimizing the risk as much as possible. As a site owner, there are a few steps you can take to protect your sites.
Don’t Use Auto Updates on All Plugins/Themes and Review the Code Prior to Updating
One of the first things you can do is disable auto-updates on plugins and themes where you can’t verify the vendor’s commitment to security. This means that instead of allowing plugins/themes to update automatically with each plugin update, you would need to go in and manually update the plugin/theme yourself. For optimal security, each plugin or theme update should be reviewed to ensure there is no malicious code (or vulnerabilities) being introduced, and only once the code is determined safe should it be updated.
A little bit of research can go a long way in determining how serious a vendor takes security. Check for compliance and certifications like ISO27001, which Wordfence has. These solidify the vendor’s commitment to security as they have to follow many industry standards to acquire these certifications and maintain compliance. You can also check to see if the vendor has a security policy or any documents outlining how they handle security and security incidents. Only when you trust a vendor’s commitment to security should you allow auto-updates.
If you have a high value WordPress site running, and you can’t review the code, then hire a security professional to review and manage your plugin updates for you. Often the most secure option is to hire the help of a security specialist.
If you’re running a small blog or low value site, then it may be perfectly okay to simply accept the risk of automatic updates without proper vetting, just be sure to have a good incident response plan in place in the event a compromise does occur.
Don’t Use Abandoned Plugins
We always recommend not using abandoned plugins for several reasons. While one of the plugins infected in this campaign was actively maintained, most were abandoned or hadn’t received any real updates in years. Abandoned plugins are a prime target for attackers because it means the developer is likely not active on WordPress.org and their account could have weak security making it susceptible to compromise.
Limit the Plugins and Themes Running on Your Site (Limit Attack Surface)
This is general security advice to make sure you only run plugins and themes that you actually need, and always delete any that are not in use. By doing so, you limit the potential surface area for an attack not just in a supply chain compromise, but any attack targeting your site.
Conduct Regular Malware Scanning
It can be hard for a Web Application Firewall (WAF) to prevent a supply chain attack like this from occurring due to the fact that a plugin update is inconspicuous and appears mostly legitimate. That is why it is always important to run a malware scanner like Wordfence or Wordfence CLI so that if malware does make it on to your site, you’ll be notified immediately and can take action quickly to prevent any further spread.
Conclusion
In today’s post, we highlighted the recent supply chain attack on WordPress that led to 35,000 sites being affected by malicious code due to a threat actor pushing updates to plugins in the WordPress.org repository. As a reminder, the root cause of this attack was due to 5 WordPress.org accounts with commit access being compromised due to credential reuse and the passwords being present in an external data breach.
While it can often be difficult to prevent supply chain attacks from being detected and prevented due to their stealth and nature, we hope that we’ve provided enough security guidance and information to help both site owners protect themselves from supply chain attacks, and developers preventing their plugins from being a successfully compromised target in a supply chain attack similar to the one we’ve highlighted today.
The post Developer Accounts Compromised Due to Credential Reuse in WordPress.org Supply Chain Attack appeared first on Wordfence.
