Giter Club home page Giter Club logo

soter-command's Introduction

ssnepenthe/soter-command

Easily check your plugins, themes and core against the WPScan API from the command line.

Installation

Installing this package requires WP-CLI v1.1 or greater. Update to the latest stable release with wp cli update.

Once you've done so, you can install this package with:

wp package install [email protected]:ssnepenthe/soter-command.git

Usage

The following commands are available:

wp soter check-plugin <slug> [<version>] [--format=<format>] [--fields=<fields>]
wp soter check-plugins [--format=<format>] [--fields=<fields>] [--ignore=<ignore>]

wp soter check-site [--format=<format>] [--fields=<fields>] [--ignore=<ignore>]

wp soter check-theme <slug> [<version>] [--format=<format>] [--fields=<fields>]
wp soter check-themes [--format=<format>] [--fields=<fields>] [--ignore=<ignore>]

wp soter check-wordpress <version> [--format=<format>] [--fields=<fields>]
wp soter check-wordpresses [--format=<format>] [--fields=<fields>] [--ignore=<ignore>]

<slug> is the plugin or theme slug.

<version> is the version string you wish to check.

<format> can be any of count, csv, ids, json, table or yaml - default is table. If set to ids, it will print a space-separated list of vulnerability IDs as given by the WPScan API.

<fields> should be a comma-separated list of fields. Valid fields are package_slug, package_type, package_version, id, title, created_at, updated_at, published_date, vuln_type, fixed_in - default is package_type,package_slug,title,vuln_type,fixed_in.

<ignore> should be a comma-separated list of installed package slugs that should not be checked.

Examples

Full site check formatted as a table

vagrant@vvv:/srv/www/wordpress-default/public_html$ wp soter check-site

Checking 24 packages  100% [==============================================================================] 0:00 / 0:00
+--------------+----------------+---------------------------------------------------------------+------------+---------------+
| package_type | package_slug   | title                                                         | vuln_type  | fixed_in      |
+--------------+----------------+---------------------------------------------------------------+------------+---------------+
| plugin       | contact-form-7 | Contact Form 7 <= 3.7.1 - Security Bypass                     | AUTHBYPASS | 3.7.2         |
| plugin       | contact-form-7 | Contact Form 7 <= 3.5.2 - File Upload Remote Code Execution   | UPLOAD     | 3.5.3         |
| theme        | twentyfifteen  | Twenty Fifteen Theme <= 1.1 - DOM Cross-Site Scripting (XSS)  | XSS        | 1.2           |
| wordpress    | 475            | WordPress 2.3-4.7.5 - Host Header Injection in Password Reset | UNKNOWN    | NOT FIXED YET |
+--------------+----------------+---------------------------------------------------------------+------------+---------------+

Plugin check: All versions of Contact Form 7 formatted as CSV

vagrant@vvv:/srv/www/wordpress-default/public_html$ wp soter check-plugin contact-form-7 --format=csv
package_type,package_slug,title,vuln_type,fixed_in
plugin,contact-form-7,"Contact Form 7 <= 3.7.1 - Security Bypass",AUTHBYPASS,3.7.2
plugin,contact-form-7,"Contact Form 7 <= 3.5.2 - File Upload Remote Code Execution",UPLOAD,3.5.3

Theme check: Version 1.1 of twentyfifteen, formatted as JSON, display title, vulnerability type and fixed in version

vagrant@vvv:/srv/www/wordpress-default/public_html$ wp soter check-theme twentyfifteen 1.1 --format=json --fields=title,vuln_type,fixed_in
[{"title":"Twenty Fifteen Theme <= 1.1 - DOM Cross-Site Scripting (XSS)","vuln_type":"XSS","fixed_in":"1.2"}]

WordPress check: Version 4.7.5, format as YAML, display id, title and fixed in version

vagrant@vvv:/srv/www/wordpress-default/public_html$ wp soter check-wordpress 4.7.5 --format=yaml --fields=id,title,fixed_in
---
-
  id: 8807
  title: 'WordPress 2.3-4.7.5 - Host Header Injection in Password Reset'
  fixed_in: null

Extending

A number of actions are available which allow plugins to implement custom behavior in response to individual checks (logging, notifications, etc.).

soter_command_package_check_complete: This action is triggered after every individual package has been checked. Callbacks receive a Soter_Core\Vulnerabilities object as the first param and a Soter_Core\Response object as the second.

soter_command_{$command}_results: This action is triggered within each command before the results are displayed. $command is the name of the command (check-plugin, check-themes, etc.) with - replaced with _ (e.g. soter_command_check_site_results). Callbacks receive a Soter_Core\Vulnerabilities object.

API Errors

It is recommended to occasionally run a full site check with --debug=soter-command.

This will notify you if you have received any error responses from the API:

vagrant@vvv:/srv/www/wordpress-default/public_html$ wp soter check-site --debug=soter-command
Checking 28 packages  3  % [===>                                                                                              ] 0:00 / 0:00
Debug: Error checking plugin recaptcha-for-wp: Non-200 status code received [HTTP 404] (1.279s)
Debug: Error checking plugin terms-archive: Non-200 status code received [HTTP 404] (1.282s)
Debug: Error checking plugin wp-hashids: Non-200 status code received [HTTP 404] (1.283s)
Debug: Error checking theme tf-child: Non-200 status code received [HTTP 404] (1.285s)
Checking 28 packages  100% [==================================================================================================] 0:00 / 0:00
+--------------+--------------+---------------------------------------------------------------+-----------+---------------+
| package_type | package_slug | title                                                         | vuln_type | fixed_in      |
+--------------+--------------+---------------------------------------------------------------+-----------+---------------+
| wordpress    | 482          | WordPress 2.3-4.8.2 - Host Header Injection in Password Reset | UNKNOWN   | NOT FIXED YET |
+--------------+--------------+---------------------------------------------------------------+-----------+---------------+

Possible errors include a non-200 status code, a non-JSON response body, an invalid JSON response body and a response that does not match the requested package.

Non-200 status codes tend to pop up for (but are not limited to) custom plugins and themes. When that is the case, they should be ignored via the ignore option via either the command line (e.g. --ignore=comma,separated,slugs) or by overriding the command defaults in wp-cli.yml.

It is unlikely that you will ever see any of the other errors, but if you do, please report them to the WPScan team.

soter-command's People

Contributors

ssnepenthe avatar

Stargazers

avatar

Watchers

avatar avatar avatar

Forkers

pombredanne mlapibp

soter-command's Issues

Consider implementing update command

Something like wp soter update-vulnerable - would be great for a system cron job to ensure any security issues are automatically addressed.

Then again, core already handles automatic security updates - maybe this is just wasted time?

An alternative might be to implement a list format or porcelain like in wp-cli/entity-command that just prints a list of slugs which could be piped to various update commands... The problem (at least as far as I can tell): there is no master command for updating everything so you would have to run once each for plugins, themes and core.

Consider adding config component

Could be stored in the options table or maybe better as a file under ~/.wp-cli.

Primary goal would be to allow user to override defaults for command options:

Would need add, remove, set and unset commands to go with it.

Add new format for dislaying list of slugs

Plugin and theme commands accept a space-separated list of slugs.

To stick with the WP-CLI philosophy of "composability is always a good idea" it would be nice if bulk commands were able to output a list of vulnerable package slugs.

--format=ids already does something similar, but it is for vulnerability IDs and so is not useful in this particular case.

Maybe we could add a custom --format=slugs?

Alternatively - consider --format=porcelain or just--porcelain.

Of note - some of the core commands (like https://github.com/wp-cli/entity-command) allow for a --porcelain flag which just outputs the ID of the entity that is the subject of the command.

Action not triggered when no vulns

->display_results() prints a success message and exits if there are no vulnerabilities.

Since soter_command_{$command}_results is triggered after results are displayed, it won't actually be triggered when there are no vulnerabilities.

Consider adding command-specific post-check hooks

Similar to the hooks available in the soter plugin.

It would provide a simple way for plugins to perform custom actions (logging, mailing, etc.) based on the results of a check.

Or maybe the expectation should be that since we are running from the command line, results can already be piped elsewhere so there is no need for plugins to be able to extend...

Prepare/format datetime fields before output

Currently:

$ wp soter check-plugin contact-form-7 --format=yml --fields=title,created_at

---
-
  title: 'Contact Form 7 <= 3.7.1 - Security Bypass'
  created_at:
    date: 2014-08-01 10:59:06.000000
    timezone_type: 2
    timezone: Z
-
  title: 'Contact Form 7 <= 3.5.2 - File Upload Remote Code Execution'
  created_at:
    date: 2014-08-01 10:59:07.000000
    timezone_type: 2
    timezone: Z

$ wp soter check-plugin contact-form-7 --format=json --fields=title,created_at

[{"title":"Contact Form 7 <= 3.7.1 - Security Bypass","created_at":{"date":"2014-08-01 10:59:06.000000","timezone_type":2,"timezone":"Z"}},{"title":"Contact Form 7 <= 3.5.2 - File Upload Remote Code Execution","created_at":{"date":"2014-08-01 10:59:07.000000","timezone_type":2,"timezone":"Z"}}]

$ wp soter check-plugin contact-form-7 --format=csv --fields=title,created_at

title,created_at
"Contact Form 7 <= 3.7.1 - Security Bypass","{""date"":""2014-08-01 10:59:06.000000"",""timezone_type"":2,""timezone"":""Z""}"
"Contact Form 7 <= 3.5.2 - File Upload Remote Code Execution","{""date"":""2014-08-01 10:59:07.000000"",""timezone_type"":2,""timezone"":""Z""}"

Consider creating WP-CLI package manager implementation

Ex:

public function get_plugins( $ignored = [] ) {
    $plugins = WP_CLI::runcommand( 'plugin list --fields=name,version --format=json', [
        'parse' => 'json',
        'return' => true,
    ] );

    // Filter ignored.

    // Map to Soter_Core\Package instances.

    return $plugins;
}

Not sure there is much benefit here aside from staying within WP-CLI...

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.