High Severity CSRF to RCE Vulnerability Patched in Code Snippets Plugin
Affected Plugin: Code Snippets
Affected Versions: <= 2.13.3
CVE ID: CVE-2020-8417
CVSS Score: 8.8 (High)
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Patched Version: 2.14.0
On January 23rd, our Threat Intelligence team discovered a vulnerability in Code Snippets, a WordPress plugin installed on over 200,000 sites. The flaw allowed anybody to forge a request on behalf of an administrator and inject executable code on a vulnerable site. This is a Cross-Site Request Forgery (CSRF) to Remote Code Execution (RCE) vulnerability. We privately disclosed the full details to the plugin’s developer on January 24th, who was quick to respond and released a patch one day later.
This is a high severity security issue that could cause complete site takeover, information disclosure, and more. We highly recommend updating to the latest version (2.14.0) immediately.
Wordfence Premium customers received a new firewall rule on January 24th to protect against exploits targeting this vulnerability. Free Wordfence users will receive the rule after thirty days on February 23rd.
Lack of CSRF Protection to Complete WordPress Site Takeover
Code Snippets is a handy and easy to use plugin that allows users to add code snippets to a WordPress site in order to customize site functionality without having to navigate the site’s underlying code. It makes it easy to enable and disable code snippet functionality in order to test adding new code to a WordPress site.
The plugin developer protected nearly all endpoints of this plugin with WordPress “nonces” for greater security. However, the plugin’s import function lacked that same CSRF protection. Without this protection, an attacker could craft a malicious request to trick an administrator into infecting their own site. This request would execute an action, send a request to the site, and the attacker’s malicious code could be injected and executed on the site. With remote code execution vulnerabilities, exploit possibilities are endless. An attacker could create a new administrative account on the site, exfiltrate sensitive information, infect site users, and much more.
Defaults Can Be Bypassed
Code snippets were implicitly set as ‘disabled’ by default upon import. For imported code snippets to be enabled, additional action needed to be taken. This seemed like great news as it appeared no code snippets that were imported as a result of CSRF would actually be executed on the site unless a site administrator enabled that code – which would be unlikely during a CSRF attack. However, we discovered that this protection could easily be bypassed to allow a code snippet to be enabled upon import.
An attacker could simply inject an "active" flag with a value of "1" into the JSON body containing the code import details, and the code snippet would be enabled upon import. This escalated a minor problem into a very severe one, as an attacker could now inject malicious code and ensure it would be activated and executed whenever someone accessed the site.
{"generator":"Code Snippets v2.13.3","date_created":"2020-01-23 16:56","snippets":[{"name":"PoC","scope":"global","code":"MALICIOUS CODE HERE","priority":"1","active":"1"}]}
The developer corrected this so that code snippets would always be disabled upon import explicitly, rather than using a more implicit technique to disable snippets upon import found in vulnerable versions of the plugin.
Proof of Concept Walkthrough
We’ve created this short video to show how this vulnerability could be exploited and what the potential impact could be.
Firewall Rule Impact Disclosure
We encountered some restrictions while trying to write a firewall rule to protect against this vulnerability. CSRF vulnerabilities can be hard to protect against without blocking normal functionality for site administrators as these types of vulnerabilities require an administrator to be logged in and unknowingly execute an action to send a request. From a firewall perspective, this means exploit attempts appear to come from a legitimate, logged-in source.
Due to the risk associated with the vulnerability, we opted to completely block the functionality of the import feature, which means that Wordfence users may experience a false positive block when trying to import code snippets if using a vulnerable version of this plugin.
Fortunately, the plugin developer changed the endpoint associated with the import functionality, ensuring that updated versions will not encounter any false positive blocks by the Wordfence Firewall. As always, we highly recommend updating to the latest version of this plugin – not only for the security of your site, but also to preserve functionality.
Disclosure Timeline
January 23rd, 2020 – Vulnerability initially discovered and analyzed. Initial reach to developer.
January 23rd, 2020 – Developer confirms appropriate inbox for handling discussion.
January 24th, 2020 – Full report sent to developer. Firewall rule released for Wordfence Premium users.
January 24th, 2020 – Developer confirms details and begins working on patch.
January 25th, 2020 – Patch released.
February 23rd, 2020 – Wordfence free users receive firewall rule.
Conclusion
In today’s post, we detailed a CSRF to RCE vulnerability in the Code Snippets plugin. This flaw has been patched in version 2.14.0 and we recommend that users update to the latest version available immediately. Sites running Wordfence Premium have been protected from attacks against this vulnerability since January 24th. Sites running the free version of Wordfence will receive the firewall rule update on February 23rd, 2020.
Special thanks to the plugin developer, Shea Bunge, for responding promptly and reacting swiftly to get a patch out a day after full disclosure.
Comments
5:13 pm
I am just trying to get a sense of this. Does the attack require that the target website has comments activated? Are there any different ways (such as a comment) by which the attacker could get in? And does the target need to click something (like 'Submit request' in the video) for the attack to complete?
12:55 pm
Hi David!
Exploiting this vulnerability does not require that the target website has comments enabled - we just used this as our method of demonstration to show one of many ways an attacker could exploit this vulnerability (and how easily disguised it could be). There are numerous ways this could be exploited, but in the context of WordPress, it usually stems from a target administrator clicking on something like a link in a comment or from an email and being concurrently logged into the target WordPress site. The target administrator does not have to click on something like "Submit Request" from the malicious site in order for there to be a successful exploit, usually just clicking on a link that takes you to a malicious site is enough for compromise as a forged request can be sent in the background. Here is documentation from OWASP that explains CSRF vulnerabilities in further detail.
9:35 am
Nice detailed explanation and thanks for reporting that and sharing.
3:23 pm
Another good reason to get the Premium version... Is there a way to know if the exploit was used on a website? Something to look for in the logs, etc.?
12:02 pm
Hi Pete!
Unfortunately, due to the nature of CSRF vulnerabilities, it can be hard to identify an attack on a site. However, since we know that the developer changed the import endpoint to "import-code-snippets" in the patched version, I would say you could look for POST requests in your logs being sent to the old endpoint "import-snippets" and consider that an exploit attempt. Alternatively, assuming you are running Wordfence on your site, you can take a look at the live traffic feed and filter down to blocked requests, if you see a request that is blocked by "Rule 198" then that is likely an exploit attempt, assuming you didn't attempt to import a code snippet and get blocked.