Hacking WordPress with Some Common Vulnerabilities

Olger Torres
5 min readApr 27, 2019

--

Hi, today I would like to share some PoC about some recent vulnerabilities and the importance to apply some good hardening practicies to make more secure your WordPress. All of these test were made in WP 4.9.18, but should apply to WP 5.1.1. I made this machine aiming to improve my WordPress Hacking techniques. So let´s begin.

Here we have the “Damn Vulnerable WordPrress” machine to practice.

Main page of the website

Allow Any user to register, to be honest, a really bad idea.
By default WordPress does has this feature off, but in some organizations, where are few people on IT lineup, could be good if you allow users with some privileges, but when you give them more than they need, surely they will be grateful and test everything.

User with quite privileges

When we are logged in, we have to reconnaissance the entire site, and test how much we can do to exploit it. One of them could be see the users who had already registered and the version of the running sofware, attempting to find some vulnerable versions, and if they have a PoC which would make you viable to exploit it.

WPScan found a vulnerable plugin

However a tool is itself, it will make things quicker, on the other hand you should check if there is something missing in it, in this case we have access to see all plugins installed. In this machine everything is vulnerable, but we will not exploit XXE in this post.

If we already tested and navigate to all site we will find that there is some ajax requests to load others posts from the main page. On the other hand we could see which wordpress plugin is making it (seeing installed plugins). Lets check with our friend Google if we can find some information about the plugin.

Gathering info from Google-chan

In fact there is no exploit available to download from exploitdb, so we have to research a little more about it.

I even doesn’t know that that webpage exist, however, there was an explanaition about the bug on Advanced Ajax Page Loader, and a PoC that we can use to exploit it. Usually if you have vulnerable software a good way to test is finding a PoC. On the other hand, this plugin does not validate correctly the type of file that you are uploading if you have an admin account.

preparing the payload

Using the PoC provided by “pluginvulnerabilities.com” we just have to make our php malicious file in order to upload it after. Important: We have to be logged in. And setup our handler to listen for a connection from the server.

How the PoC looks like

Once we do click on “seleccionar archivo”, we can select our poc.php in order to connect with our handler.

Directory listing

Once executed the PoC, if we want to be sure if it uploaded, we can search on upload plugin folder, whithout regard it load the “poc.php” by default when it is already uploaded. We will have a session even if it the server is rebooted, when a user load again the page, we will have the connection.

exploit/multi/handler

Exploiting CSRF and XSS on the current WordPress

According with Simon Scannell research there is a flaw in the way that WordPress handle the user input, in fact there is not validation! you can read more about that research here below.

So, let’s login and prepare a PoC to exploit it. First we have to see what kind of request is happening when we are sending a comment to the WordPress server, and the flow of itself.

Original Request

When we send a comment on a specific post, that is the request that is sent. When you are testing for a good CSRF tokens, if the tokens are missing, the response should be an error 403, also if I erase a value or variable of a POST body they should response with an error if that value or variable is missing!. If it does not, then you can be quite sure that there is a bug. In this case there is no CSRF Tokens, even if the last value or variable of this WP implementation would act “like” a “CSRF Token” or another control, the response is always be HTTP 200 OK.

The only thing that we have to do is build a similar request, also our localhost must work for it. Because the only thing that you need to make it happen is a logged user and use the same browser with a session cookie.

CSRF PoC

Even if the flow is not exactly the same, if the response is 302, you can be sure that the attack was susccesfully completed.

Stored XSS

So that is everything for today, I hope it will be helpful to you

--

--