Ready to Start Your Career?

Metasploit And CVE

Author's profile image

January 1, 2016

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 ```master```. * **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 ```msfconsole```. * **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 ```tools/dev/msftidy.rb``` against your module and fix any errors or warnings that come up. - It would be even better to set up ```msftidy.rb``` 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 ```See #1234``` 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]: [wiki]: [scripts]: [development environment setup]: [Common Coding Mistakes]: [Ruby style guide]: [Rubocop]: [50/72 rule]: [topic branch]: [console output]: [verification steps]: [reference associated issues]: [release notes]: [PR#2940]: [PR#3043]: [pre-commit hook]: [API]: [RSpec]: [Better Specs]: [YARD]: [Issues]: [Freenode IRC channel]: [metasploit-hackers]:!forum/metasploit-hackers```
Schedule Demo