Metasploit and CVEMetasploit

Begin Learning Cyber Security for FREE Now!

Already a Member Login Here

Home Forums Courses Metasploit Metasploit and CVE

This topic contains 2 replies, has 3 voices, and was last updated by  ingochris 2 years, 11 months ago.

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
  • #95517


    how do you do to exploit the CVE-2017-3167 with msf , because i can’t find it in the database exploit of msf , can you help me ?


    According to the CVE database there is no module within Metasploit related to 2017-3167. You would need to design your own exploit for it at this time.



    Feel free to write your own and submit a module PR in the repo following contribution guidelines 🙂

    # Hello, World!
    Thanks for your interest in making Metasploit -- and therefore, the
    world -- a better place!
    Are you about to report a bug? Sorry to hear it. Here's our [Issue tracker].
    Please try to be as specific as you can about your problem; include steps
    to reproduce (cut and paste from your console output if it's helpful) and
    what you were expecting to happen.
    Are you about to report a security vulnerability in Metasploit itself?
    How ironic! Please take a look at Rapid7's [Vulnerability
    Disclosure Policy](, and send
    your report to using our [PGP key].
    Are you about to contribute some new functionality, a bug fix, or a new
    Metasploit module? If so, read on...
    # Contributing to Metasploit
    What you see here in is a bullet point list of the do's
    and don'ts of how to make sure *your* valuable contributions actually
    make it into Metasploit's master branch.
    If you care not to follow these rules, your contribution **will** be
    closed. Sorry!
    This is intended to be a **short** list. The [wiki] is much more
    exhaustive and reveals many mysteries. If you read nothing else, take a
    look at the standard [development environment setup] guide
    and Metasploit's [Common Coding Mistakes].
    ## Code Contributions
    * **Do** stick to the [Ruby style guide].
    * **Do** get [Rubocop] relatively quiet against the code you are adding or modifying.
    * **Do** follow the [50/72 rule] for Git commit messages.
    * **Don't** use the default merge messages when merging from other branches.
    * **Do** create a [topic branch] to work on instead of working directly on <code>master</code>.
    * **Do** license your code as BSD 3-clause, BSD 2-clause, or MIT.
    ### Pull Requests
    * **Do** target your pull request to the **master branch**. Not staging, not develop, not release.
    * **Do** specify a descriptive title to make searching for your pull request easier.
    * **Do** include [console output], especially for witnessable effects in <code>msfconsole</code>.
    * **Do** list [verification steps] so your code is testable.
    * **Do** [reference associated issues] in your pull request description
    * **Do** write [release notes] once a pull request is landed
    * **Don't** leave your pull request description blank.
    * **Don't** abandon your pull request. Being responsive helps us land your code faster.
    Pull requests [PR#2940] and [PR#3043] are a couple good examples to follow.
    #### New Modules
    * **Do** run <code>tools/dev/msftidy.rb</code> against your module and fix any errors or warnings that come up.
      - It would be even better to set up <code>msftidy.rb</code> as a [pre-commit hook].
    * **Do** use the many module mixin [API]s. Wheel improvements are welcome; wheel reinventions, not so much.
    * **Don't** include more than one module per pull request.
    * **Do** include instructions on how to setup the vulnerable environment or software
    * **Do** include [Module Documentation]( showing sample run-throughs
    #### Scripts
    * **Don't** submit new [scripts].  Scripts are shipped as examples for
      automating local tasks, and anything "serious" can be done with post
      modules and local exploits.
    #### Library Code
    * **Do** write [RSpec] tests - even the smallest change in library land can thoroughly screw things up.
    * **Do** follow [Better Specs] - it's like the style guide for specs.
    * **Do** write [YARD] documentation - this makes it easier for people to use your code.
    * **Don't** fix a lot of things in one pull request. Small fixes are easier to validate.
    #### Bug Fixes
    * **Do** include reproduction steps in the form of verification steps.
    * **Do** include a link to any corresponding [Issues] in the format of
      <code>See #1234</code> in your commit description.
    ## Bug Reports
    * **Do** report vulnerabilities in Rapid7 software directly to
    * **Do** write a detailed description of your bug and use a descriptive title.
    * **Do** include reproduction steps, stack traces, and anything else that might help us verify and fix your bug.
    * **Don't** file duplicate reports; search for your bug before filing a new report.
    If you need some more guidance, talk to the main body of open
    source contributors over on the [Freenode IRC channel],
    or e-mail us at the [metasploit-hackers] mailing list.
    Also, **thank you** for taking the few moments to read this far! You're
    already way ahead of the curve, so keep it up!
    [Issue Tracker]:
    [PGP key]:
    [development environment setup]:
    [Common Coding Mistakes]:
    [Ruby style guide]:
    [50/72 rule]:
    [topic branch]:
    [console output]:
    [verification steps]:
    [reference associated issues]:
    [release notes]:
    [pre-commit hook]:
    [Better Specs]:
    [Freenode IRC channel]:
    • This reply was modified 2 years, 11 months ago by  ingochris.
Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.

Our Revolution

We believe Cyber Security training should accessible for everyone, everywhere. Everyone deserves the OPPORTUNITY to learn, begin and grow a career in this fascinating field. Therefore, Cybrary is the world's largest community where people, companies and training come together to give everyone the ability to collaborate in an open source way that is revolutionizing the cyber security educational experience.

We recommend always using caution when following any link

Are you sure you want to continue?