Earlier, WordPress administrators were urged to update to the popular All-in-One SEO plug-in to address a persistent cross-site scripting vulnerability. But other widely used plug-ins also need updating.
The plug-in model for WordPress is simultaneously the platform’s greatest asset and biggest vulnerability. Administrators can happily search the rich ecosystem of plug-ins and find all manner of advanced features and functionality to enhance their WordPress sites. Once downloaded, these plug-ins are easy to install. However, the plug-ins are frequently poorly coded or not regularly updated, exposing WordPress sites to potential web attacks. WordPress itself is a pretty stable platform, but WordPress sites are frequently compromised because the attackers uncover a vulnerability in one of the plug-ins.
Not alone
It turns out All-in-One was not the only vulnerable plug-in found by Summer of Pwnage, a Dutch community project working on uncovering vulnerabilities in popular applications. The project posted advisories on a dozen or so other XSS vulnerabilities in widely used WordPress plug-ins.
The WP Fastest Cache WordPress plug-in creates static HTML files from dynamic WordPress pages. A local file inclusion vulnerability in this plug-in can be exploited to run arbitrary PHP code. Attackers must place an arbitrary PHP file on the target system in order to exploit the vulnerability. The issue is in /admin/partials/menu/options.php and is caused by the lack of input validation on the id POST parameter.
WP Live Chat Support turns on the chat function on the WordPress site. The persistent XSS flaw in WP Live Chat Support is similar to the one found in All-in-One SEO in that attackers can inject malicious JavaScript code into the application, which executes within the victim’s browser with the privileges of the logged-in WordPress user. The attacker can exploit the flaw to steal a victim’s session tokens and login credentials, executing code, and logging keystrokes.
Referrer
The plug-in uses the Referrer header to present the current page on which the chat is initiated to back-end users, but the URL retrieved from the data isn’t properly output encoded according to output context. Stored XSS flaws are typically more serious because they do not need to be delivered separately to the users. The victim — potentially the logged-in Administrator — only has to view wplivechat-menu page to execute the malicious code. Administrators should update to Version 6.2.02.
Another stored XSS vulnerability was found in the WordPress Activity Log plug-in, which allows administrators to monitor and track site activity. An unauthenticated attacker would be able to inject malicious JavaScript code into the application, which will then execute within the browser of any logged-in user who views the Activity Log. The Activity Log plug-in fails to sufficiently check input supplied to the X-Forward-for HTTP header and perform output encoding when an incorrect password is entered. The malicious request gets stored in the Activity Log on the wp-admin page and executes every time someone views the page.
Attackers would be able to steal victims’ session tokens and login credentials, log keystrokes, perform arbitrary actions in the context of the user, and deliver malware. Administrators should update to Version 2.3.2.
Cross-site
The remaining plug-ins on this list had a cross-site scripting vulnerability that would allow an attacker to perform a variety of actions, such as stealing Administrator session tokens and performing arbitrary actions on the website with Administrator privileges. The flaws could be exploited by tricking WordPress administrators who were logged in to open a malicious site.
All-in-One was vulnerable because the plug-in failed to properly sanitise the requests, which let attackers inject malicious JavaScript code in the request headers. The vulnerability in all the other plug-ins was the result of a lack of output encoding on the page request parameter.
Not sanitising inputs and outputs is a common enough mistake in coding. WordPress normally validates this parameter to shut down cross-site scripting, but didn’t in these instances because of the way the parameter value was set.
Attackers like to target WordPress sites through vulnerabilities in third-party plug-ins. Plenty of administrators neglect to patch the CMS. Even those diligent about staying on top of the core updates may forget to update the plug-ins, or opt not to because they don’t want the updated plug-ins to break existing functionality.
When plug-ins are no longer being actively maintained, the administrator may decide to keep using the plug-in instead of looking for an alternative. There are many reasons for still using outdated plug-ins, but the bottom line is that they provide attackers with a simple way to compromise and seize control of the WordPress site.
IDG News Service
Ltd
