“Let’s Hack!” Workshop

Congratulations on completing the “Let’s Hack!” Workshop at WordSesh 2021! I’m guessing this was the first website you’ve hacked into, and I trust you’ll use your new skills to better protect your sites and learn more about the ever changing world of security.

To save you having to remember everything, I’ve put together some notes and links about the vulnerabilities that you just learnt. If you’re seeking more information that I haven’t provided here, please email me or leave a comment below.

Goal 1: Gaining Access

Finding the username

To start with, we identified a user account on the site. This can be done through a number of methods:

1. Look at the author name and URL on posts.
2. Check the RSS feed for the dc:creator tag:
   /?feed=rss2
3. Check the JSON API users endpoint for name or slug:
   /wp-json/wp/v2/users
4. Brute-force an author ID to look for a redirect to a username URL:
   /?author=1

You can also use a tool like WPScan to scan the site and look for usernames.

Finding the login form

We used a known vulnerability version 1.5.2 of the in the wps-hide-login plugin to identify the login page.

Vulnerability Details: https://secupress.me/blog/wps-hide-login-v1-5-2-2-multiples-vulnerabilities/

Exploiting the vulnerability was a simple as visiting:
/wp-login.php?SECUPRESSaction=confirmaction

Brute-forcing the Password

We crowd-sourced a password brute-force attack on the login form to guess the password. It was a password found on the top most common passwords lists.

Goal 2: Persisting Access

Editing Posts

The site had a vulnerable version of the wp-page-builder plugin installed. This allowed anyone with an account to directly edit any posts by modifying the ID in the URL:
/wp-admin/post.php?post=1004&action=wppb_editor

This type of vulnerability is known as an IDOR – Insecure Direct Object Reference. It occurs when access control hasn’t been correctly implemented on specific URLs, which allows an attacker to modify identifiers (usually incrementing numbers) in order to access resources they are not supposed to be able to access.

Vulnerability disclosure: https://www.wordfence.com/blog/2021/04/vulnerabilities-patched-in-wp-page-builder/

Injecting Javascript

This vulnerability had the side effect of allowing Persistent Cross-Site Scripting, as the attacker was able to use the Raw HTML block to add Javascript to the modified posts. This could lead to a complete site takeover if an administrator user visits the modified post.

Goal 3: Escalating Access

Looking around…

Sometimes developers will hide important or sensitive things from the user with CSS (with display: none, etc), and not consider that HTML is fully open and available. In this case, the wp-central Connection Key was hidden in the HTML at the bottom of all /wp-admin/ pages – regardless of user level.

This key allowed anyone who possessed it to gain administrator access to the site by visiting this URL when logged out:
/wp-admin/admin-ajax.php?action=my_wpc_signon&auth_key=<KEY>

Super simple to exploit and easily overlooked if you don’t consider what’s hiding in the HTML.

Vulnerability Disclosure: https://www.wordfence.com/blog/2020/02/vulnerability-in-wpcentral-plugin-leads-to-privilege-escalation/

Hackable Site Setup

I used Laravel Forge to provision the server, with PHP 7.4. Once provisioned, I created the database and an isolated site. I used a Forge Recipe as root to install wp-cli and tweak PHP, and a user recipe to configure WP and the vulnerable plugins.

https://gist.github.com/valorin/e47cf8876126d5a8ef04c4d1b0da6a75

Logging Plugin: https://gist.github.com/valorin/e3924234976a767d586d6c065965552f