“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.

Summary

This attack exploits security through obscurity (the hidden password field), and an easily guessable password. If the user had a unique password or two-factor authentication, the attack would have failed.

You can use https://haveibeenpwned.com/Passwords to check your passwords haven’t been compromised.

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.

Summary

This attack exploits insecure access controls as default in the plugin. There are mechanisms to block user levels, they are not enabled and anyone installing the plugin opens up post editing to all users.

Admins need to keep their sites updated and check for security updates in release notes. Also, they should always try logging in as lower privilege users to see what access is available.

Developers need to check permissions and always default to giving the least amount of access as possible.

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/

Summary

This vulnerability was caused by the developer not considering access controls when displaying sensitive data on the page. They used the incorrectly WP function (is_admin()) and because the content was hidden on the page, it wasn’t noticed.

Developers need to consider what they are hiding on the page and where it is being loaded.

Admins need to be careful of what plugins they install, and keep them updated.


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

One reply on ““Let’s Hack!” Workshop”

Leave a Reply

Your email address will not be published.