Unpatched Code Snippets Plugins Puts over 200,000 WordPress Sites at Risk
More than 200,000 websites using WordPress with unpatched open-source code snippets allows attackers to take over WordPress sites due to missing referrer checks on the import menu.
(Figures are based on the number of active installations in the WordPress Library).
Wordfence researchers explained that “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 results in a Cross-Site Request Forgery (CSRF) to Remote Code Execution (RCE) vulnerability, which allows anybody to forge a request on behalf of the administrator and inject malicious code on a vulnerable website remotely.
A CVE-ID, CVE-2020-8417 [with CVSS v3.0 score: 8.8 (High)] has been assigned and Code Snippets plugin with versions lower than 2.13.3 are at risk of the attack.
What causes CSRF protection to be bypassed?
The code snippets come with a graphical interface and are managed, similar to a Plugins menu. Snippets can be added and run on your WordPress site as though they were in your theme’s functions.php file. Snippets are then activated and deactivated, just like plugins. Snippets can also be exported for transfer either in JSON or PHP.
Wordfence researchers found out that code snippets were implicitly set as ‘disabled’ by default upon import. However, an attacker can easily modify the code snippet to ‘enabled’ upon import by injecting an “active” flag with a value of “1” into the JSON body containing the code import details.
Fig. 1: (Source: High Severity CSRF to RCE Vulnerability Patched in Code Snippets Plugin [Link])
A Proof of Concept video by Wordfence researchers showing how the vulnerability can be exploited and what the potential impacts are can be found at the YouTube Link Here
What is Cross-Site Request Forgery (CSRF)?
A Cross-Site Request Forgery (CSRF) attack is an attack where a third-party web application is able to execute actions at a target website with the privileges of a ‘trusted’ user.
The ‘trusted’ user has an authenticated session between the client and the web server, and web applications can send requests to other web applications without showing the response.
CSRF vulnerabilities occur mostly in cases when applications track sessions by relying only on HTTP cookies. Once the application sets a cookie in a user’s browser, the browser will automatically submit the cookie to the application in every subsequent request.
This happens regardless of whether the request originates from a link, form within the application itself, or from any other source such as an external website or a link clicked in an email. The application will be vulnerable to CSRF if no precautions are taken against an attacker “riding” on its users’ sessions.
A typical example on how a CSRF attack can occur is shown below:
- Alice (the victim) visits example.com, logs in to her account and leaves the site without logging out.
- Alice then moves on to visit foo.com (a malicious website). Unknown to Alice, a request is also sent from her browser to example.com (e.g. to buy a dress).
- The victim browser sends this request, along with the victim’s cookies to example.com. (The request seems legitimate to example.com and example.com processes the request).
The HTML code that triggers this request would be something like:
<html>
<head>
<script>
// 1. Create a new XMLHttpRequest object
let xhr = new XMLHttpRequest();
xhr.open(‘POST’, ‘http://example.com/buy?item=prettydress’);
xhr.withCredentials = true;
var params = “action=buyItem&confirm=yes”
xhr.setRequestHeader(“Content-type”,”application/x-www-form-urlencoded”)
xhr.send(params);
</script>
</head>
</html> - The request to purchase a dress goes through and money is deducted from Alice’s account as she is still logged in to example.com (session with example.com is authenticated).
So, what happens when there is a CSRF to RCE vulnerability?
Remote code execution provides an attacker the ability to access and make changes to a victim’s computing device. The attack is not restricted by its geographical location.
In a Cross-Site Request Forgery (CSRF) to Remote Code Execution (RCE) vulnerability, the attacker only needs to inject malicious code on a vulnerable website and wait for a victim to execute it.
When the malicious code is executed, the attacker will be able to take complete control of the affected system, resulting in a full site takeover with the privileges of the user running the application.
It can lead to consequences such as creating of a new administrative account on the site, deleting or stealing data (e.g. credit card numbers, details of new products that is in the pipeline to roll out), using the application to launch attacks to the product’s users or competitors, and much more.
The victim will be completely unaware of the attack as they do not need to engage in any interaction except for visiting the vulnerable website that has been set up by the attacker.
Although Cross-Site Request Forgery (CSRF) has been removed in the OWASP Top 10 – 2017 version, it should be noted that CSRF has appeared in previous versions of the Top 10 and it has also been ranked No. 9 (CWE:352) in the list of 2019 CWE Top 25 Most Dangerous Software Errors.
How to remediate?
It is highly recommended for system owners to update the Code Snippet plugin to version 2.14.0 or later as soon as possible.
Consider using WPScan to run a check if system owners are unsure if their Code Snippet plugin is up-to-date or known to be vulnerable. System owners can also consider performing a Vulnerability Assessment (VA) quarterly, or Penetration Testing (PT) yearly to have a security assessment of their website and to address any cyber security vulnerabilities.
Another good mitigation strategy is to installing a web application firewall (WAF) to protect their website against web-based attacks or implement security monitoring to obtain more visibility on their internet-facing assets such as web servers.
For general CSRF remediation information, please refer to OWASP’s Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet.
Author: Sheena
Web Security Research Engineer
CPSA, GSEC
References:
- https://wordpress.org/plugins/code-snippets/
- https://www.wordfence.com/blog/2020/01/high-severity-csrf-to-rce-vulnerability-patched-in-code-snippets-plugin/
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8417
- https://owasp.org/www-project-cheat-sheets/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
