WordPress Security: Learning from the NextGEN Gallery Vulnerabilities
On February 8, 2021, in a Wordfence blog post, threat analyst Ram Gall made public two vulnerabilities the WordFence team discovered in the popular NextGEN Gallery plugin. Because vulnerabilities that could lead to a hacker taking over a WordPress site and a plugin with over 800,000 active installs were involved, it was pretty big news in the world of WordPress security.
Today, we’re going to take a look back at the NextGEN Gallery vulnerabilities, help you determine if your site is affected (spoiler alert: update to 3.5.0 or later ASAP), and review some of the key takeaways from a security perspective.
TLDR: What Happened and What NextGEN Gallery Versions Are Affected?
If this is your first time hearing about the NextGEN Gallery vulnerabilities, let’s get you up to speed. Here’s what happened:
- Wordfence discovered the popular NextGEN Gallery WordPress plugin was vulnerable to CVE-2020-35942 and CVE-2020-35943 on December 14th, 2020.
- Wordfence notified Imagely (the company that develops and maintains NextGEN), the next day on December 15th, 2020.
- Imagely released a patch to address the vulnerabilities in NextGEN Gallery 3.5.0 on December 17, 2020.
So, if you’re running a version of NextGEN Gallery below 3.5.0, you should upgrade to address the vulnerabilities right away.
Are the Vulnerabilities Critical?
In the world of security vulnerabilities “critical” can have specific implications. In the case of CVE-2020-35942 and CVE-2020-35943, it depends on your source.
Several early announcements and blog posts – including the original Wordfence post – indicated the vulnerabilities were Critical (CVE-2020-35942) and High (CVE-2020-35943) severity.
However, the current CVSS 3.x scores in the National Vulnerability Database rank them as High (8.8 CVSS 3.x score for CVE-2020-35942) and Medium (6.5 CVSS 3.x score CVE-2020-35943) severity.
We’ll stop short of calling these vulnerabilities critical, but it’s a good idea to patch if you’re affected.
How Did the Exploits Work?
Now that we’re all up to speed on the chain of events and severity, let’s dive into the technical aspects of the NextGEN Gallery vulnerabilities.
CSRF Attacks: A Crash Course
Exploits for both of the vulnerabilities are Cross-Site Request Forgery (CSRF) attacks. CSRF attacks occur when an authenticated user is tricked into performing an action in a web app, usually by clicking a malicious link.
For standard users, a CSRF attack could do things like make a purchase, transfer funds, or change a password. If the user is an administrator, a well-crafted CSRF attack could compromise an entire website.
To exploit a CSRF vulnerability, an attacker needs to create a malicious link or script and get the user to click it while they are authenticated. In most cases, the tricking is done via some form of social engineering like phishing.
Here’s a simple example of how a CSRF attack can happen:
- User is signed into a web application
- Hacker sends User a malicious link with a prompt to ACT IMMEDIATELY TO RENEW YOUR CAR WARRANTY or something similarly enticing
- User clicks the link
- The link performs some malicious action using an HTTP request to the web application (e.g. changes User’s password so Hacker can take over the account)
? Note: CSRF attacks go by several different names including “sea surf”, session riding, hostile linking, and one-click attack, but from a technical perspective they’re all the same.
CVE-2020-35942: CSRF That Enables XSS and RCE
This exploit worked by taking advantage of a logic flaw in an
is_authorized_request function NextGEN Gallery used to protect most of the plugin’s settings. In simple terms, some of the code in the function would process a request if a parameter was missing (but not if it was invalid). As a result, attackers could – if they had access to at least one album on the site and tricked an admin into clicking a link that had two malicious requests – achieve LFI and RCE. Once they did that, they could effectively take over the site. There are two approaches to exploiting the vulnerability:
- Upload files with double extensions that execute arbitrary code. Admins can upload custom CSS files in NextGEN Gallery. This vulnerability meant that a successful CSRF attack could upload files with double extensions (e.g. .php.css) that enabled LFI and RCE.
- Exploit a Legacy Templates feature of NextGEN Gallery. In addition to the double extensions exploit, a Legacy Templates feature in the WordPress plugin. The Legacy Templates feature made it possible to exploit the vulnerability without using double extensions. Going this route, an attacker can set an album to use a template that points to a file with malicious code that has been uploaded to the site.
CVE-2020-35943: CSRF That Allows File Upload
CVE-2020-35943 works a lot like CVE-2020-35942. In this case, a
validate_ajax_request function has the logic flaw. The vulnerability here allows hackers to trick admins into uploading image files that have hidden executable code or a webshell. The Legacy Templates exploit also comes into play with CVE-2020-35943 as the templates can be set to call the hidden malicious code or shell.
Want to see exactly what changed to fix the vulnerabilities? Because NextGEN Gallery is open source, you can. For example, you can see the changes made to the
validate_ajax_request functions on December 15th, 2020 here in Imagely’s GitHub repo.
WordPress Security Lessons Learned: Be Wary of Social Engineering & Stingy with Admin Access
So, looking back, what can we learn from the NextGEN Gallery vulnerabilities? For starters, many of the tips Rebecca Skane mentions in WordPress Vulnerabilities are Candy for Hackers apply. Case in point: Users that applied the 3.5.0 NextGEN Gallery update when it came out would have patched the vulnerability almost 2 months before the Wordfence announcement.
However, the biggest takeaways from this story are from the human side of WordPress security. Like with many attacks today, all the NextGEN exploits required a user to be tricked into clicking something they shouldn’t have. Even if you do everything right from a technical perspective on your site, human error can lead to a breach.
Tips for Avoiding Social Engineering
Because there are so many iterations of WordPress vulnerabilities – particularly in the plugin ecosystem – administrators of WordPress sites need to be particularly wary of social engineering attacks. If you click the wrong thing while logged in as an admin, you could wind up doing an attacker’s work for them. Here are some key points to keep in mind to help you stay diligent and avoid social engineering:
- Think before you click that link or download that attachment – Only click links and download attachments from sources you trust. This goes for email which is a very common attack vector for phishing scams, chats, and websites. Additionally, examine links before you click them. If something looks suspicious in the URL, don’t click.
- Examine domain names – Many scammers will slightly modify a domain name (e.g. g00gle with zeros instead of the letter “o” ) to make it seem legitimate. Make sure not to get tricked into thinking an email or website is legit just because the name is close.
- Be wary when something seems urgent – Social engineering scams often rely on creating a sense of urgency. This is because when we feel something is urgent, we’re more likely to react without giving a lot of thought. If you get an email that’s trying to get you to take urgent action, be wary. For an example of some real-world phishing examples that try to invoke a sense of urgency, check out UC Berkeley’s Phishing Example Archive.
Why You Should Limit Admin Privileges
In addition to admin privileges being an important aspect of exploiting CVE-2020-35943 and CVE-2020-35942, they can increase your attack surface in general. If you’re a WordPress admin, keep these points in mind:
- Only give admin access to those who MUST have it – All else equal, fewer admins means a smaller attack surface. If a user doesn’t need to be an admin, don’t make them one.
- When you’re done doing admin work, logout – For attacks like CSRF exploits, you’re vulnerable when you’re authenticated. Logging out when you don’t need admin access reduces the window of vulnerability.
- Protect your account with MFA and strong passwords – While this tip isn’t directly related to CSRF exploits, it is a very important part of WordPress security. Combining multi-factor authentication (MFA) with strong passwords can reduce the risk of your account being compromised.
Final Thoughts and a Tip of the Hat to Wordfence and Imagely
All things considered, both Wordfence and Imagely did good for the larger WordPress ecosystem here. While we’d all rather have no security vulnerabilities in the WordPress ecosystem, that’s simply not realistic.
However, proactive collaboration and communication between infosec professionals and developers can help mitigate issues when they occur. So, a tip of the hat to Wordfence for catching the bugs and Imagely for addressing them. A three-day turnaround for a patch is good work. One thing that could have been done better: The release notes for 3.5.0 should have informed users there was a security patch they should apply.
From the perspective of a WordPress administrator, there are several important security takeaways from the story. There’s no one-size-fits-all approach to security and getting the right mix of functionality and security out of your site can be a balancing act.
Technical WordPress security solutions – like proactive malware scanning with Sucuri (which powers the Media Temple Security Pack) that mitigate many threats – are an important part of getting that functionality/security mix right.
However, the human aspect of WordPress security – like being diligent when it comes to social engineering – can be just as important.