Oh no, you're thinking, yet another cookie pop-up. Well, sorry, it's the law. We measure how many people read us, and ensure you see relevant ads, by storing cookies on your device. If you're cool with that, hit “Accept all Cookies”. For more info and to customize your settings, hit “Customize Settings”.

Review and manage your consent

Here's an overview of our use of cookies, similar technologies and how to manage them. You can also change your choices at any time, by hitting the “Your Consent Options” link on the site's footer.

Manage Cookie Preferences
  • These cookies are strictly necessary so that you can navigate the site as normal and use all features. Without these cookies we cannot provide you with the service that you expect.

  • These cookies are used to make advertising messages more relevant to you. They perform functions like preventing the same ad from continuously reappearing, ensuring that ads are properly displayed for advertisers, and in some cases selecting advertisements that are based on your interests.

  • These cookies collect information in aggregate form to help us understand how our websites are being used. They allow us to count visits and traffic sources so that we can measure and improve the performance of our sites. If people say no to these cookies, we do not know how many people have visited and we cannot monitor performance.

See also our Cookie policy and Privacy policy.

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

TIP US OFF

Send us news


Other stories you might like