This article is more than 1 year old

Don't be a WordPress RCE-hole and patch up this XSS vuln, pronto

Not on 5.1.1? You should be

A newly revealed vuln in the open-source CMS WordPress allows an unauthenticated website attacker to remotely execute code – potentially letting naughty folk delete or edit blog posts.

The flaw, detailed by German code-checking company RIPS Technologies in a blog post, can be exploited "by tricking an administrator of a target blog to visit a website set up by the attacker" in order to activate a cross-site request forgery exploit.

The attack relies on a) the target site having comments enabled, and b) the site admin being oblivious enough to click a dodgy link, however the attacker presents it to them. Security-aware folk are unlikely to be affected by this.

With WordPress claiming to power a third of websites on the WWW, including a large number of news websites and corporate blogs, the vuln could have business-critical implications.

"WordPress performs no CSRF [Cross-Site Request Forgery] validation when a user posts a new comment. This is because some WordPress features such as trackbacks and pingbacks would break if there was any validation," wrote RIPS' Simon Scannell, explaining that WordPress site admins can include arbitrary code in comments they post on their own websites. "In theory, an attacker could simply abuse the CSRF vulnerability to create a comment containing malicious JavaScript code."

While WordPress sanitises code snippets out of comments, it does so by running them past one of two internal lists (depending on whether the admin account passes nonce validation; something an attacker should not be able to achieve) and deleting tags that are not on the approved list. If an admin posts a comment but fails nonce validation, his comment is still sanitised but not as harshly as an ordinary user's comment would be.

"An attacker can create a comment containing a crafted <a> tag and set for example the title attribute of the anchor to title='XSS " onmouseover=alert(1) id="'. This attribute is valid HTML and would pass the sanitization step. However, this only works because the crafted title tag uses single quotes," wrote Scannell. He said that an attacker could add an additional double quote to insert extra attributes that would not be stripped out by the sanitising code.

For example: <a title='XSS " onmouseover=evilCode() id=" '> would turn into <a title="XSS " onmouseover="evilCode()" id=""> after processing.

Thanks to WordPress's frontend not implementing x-frame-options protections, the payload-containing comment can be displayed as an iframe. Scannell suggested the "attacker can make the iframe follow the mouse of the victim to instantly trigger the XSS payload". From there it is a relatively straightforward step to have the target admin executing arbitrary JavaScript. Scannell added that one route to complete pwnage would be to insert a PHP backdoor into a WordPress theme or plugin. Doing so in the default theme shipped with out-of-the-box WordPress installs could be one method of staying below the radar.

To avoid this rather convoluted vuln, WordPress admins should ensure their installs are patched to version 5.1.1, or, failing that, disable comments until the core site can be patched.

"Most importantly, make sure to logout of your administrator session before visiting other websites," advised RIPS. ®


Similar topics

Similar topics

Similar topics


Send us news

Other stories you might like