Automatically generate evidence for a broad range of security issues you might discover during a penetration test. The intended workflow is that you determine a vulnerability either manually or through a different tool and then verify the relevant issue using Verifier to add it to your report. However, many of the issues in Verifier also have checks to see if the issue is present, which allows for scanner-like behaviour.
We use this tool extensively at Northwave to spend less time on low-hanging fruit vulnerabilities in order to spend more time on vulnerabilities that are harder to find.
Verifier has integrations with Dradis and Reporter for automatically adding the findings to your reports. The issues in Verifier can be linked to issues in your issue library to automatically create these issues in your reporting tool and add the generated evidence to it. Verifier is built to be extendable. It should be easy to add your own issues, evidence savers (for integration with reporting tools) and other extensions. Currently, the evidence templates in the public version of Verifier are very bare-bones and only support the English language. If you want to use this tool for your reports, we recommend that you improve the templates to match the style of your reports.
Verifier supports parsing the output from tools like Curl, Nmap, Dig, NetExec/Crackmapexec, BloodHound, Scoutsuite, etc.
Copy config.sample.ini to config.ini and edit the values.
Build the docker container:
make docker
Setup and configure the verifier application (make sure to add your dradis API key):
docker run --name verifier_container -it verifier configure
Run verifier through docker:
docker start verifier_container docker exec -it verifier_container verifier verify ...
pip install -e ".[dradis]"
In the [dradis] section in ~/.config/verifier.ini edit the values.
Note that evidence_saver is set to dradis by default. This means that if the -s flag is passed, evidences are saved to Dradis.
The parameter -p <dradis_project_id> is then required to indicate the project in which to save the issue.
For use with Reporter, the config file can be edited to set evidence_saver = issue-library.
In that case, evidences are saved to the current report using the reporter library.
It is required that verifier is run from the report directory.
verifier --help verifier verify -i all -t example.com verifier verify -i dns-cache-snoop -t 8.8.8.8 verifier verify -l nl -i dns-cache-snoop -t 8.8.8.8 verifier verify -i all-missing-headers -t example.com verifier verify -i cors -t example.com -c request-response.txt verifier verify -i all-missing-headers -t example.com -c request-response.txt verifier verify -i content-security-policy x-frame-options -t https://example.com verifier verify -i content-security-policy -t https://example.com -s dradis -p <dradis_project_id> verifier verify -i content-security-policy -t https://example.com -s issue-library verifier verify -i bloodhound -t domain.local verifier verify -i cme -t domain.local verifier verify -i cookie-flags-browser -t example.com
Export
verifier verify -x output.json -i content-security-policy -t https://example.com -s dradis -p <dradis_project_id>
Import
verifier import output.json verifier import output.json -s dradis -p <dradis_project_id>
For some issues a file with content can be provided or is required, for example for cors. This file has the following format:
[key]
value
value continued
value continued
[key1]
value1
value1 continued
value1 continuedExample:
[request]
GET / HTTP/1.1
[response]
HTTP 200 OK
...The variables are read into a dictionary which is accessible to the issues as self.content.
If no key is provided, the content is available under the key content.
Extra arguments passed to verifier are sometimes passed to subcommands, this behaviour is issue-dependent. For example, for curl, the following works to add authentication to a curl command:
verifier verify -i curl -t google.com --basic -u test:test #[Description]# The following curl command shows that TODO. bc.. $ curl --basic -u test:test https://google.com <HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>301 Moved</TITLE></HEAD><BODY> <H1>301 Moved</H1> The document has moved <A HREF="https://www.google.com/">here</A>. </BODY></HTML> p. TODO.
COOKIE: The content of the cookies header that should be sent with requests. VERIFIER_CONFIG: An additional config file to use. This can be used for overriding the global config on a project-specific basis
The start_test script tests a set of standard issues and imports them into a given dradis project
Usage:
start_test --help start_test -s dradis example.com -p <dradis_project_id> start_test -s dradis -l nl example.com -p <dradis_project_id>
Export
start_test -x output.json example.com
Importing can be done using verifier.py.
pip install -e ".[dradis]"
Copy config.sample.ini to config.ini or ~/.config/verifier.ini and edit the values
To add Dradis support to an issue, add a _standard_issue_id attribute to the issue class like the following:
class Issue:
...
_standard_issue_id = {
# Number of the issue in Dradis Issue Library add-on
"en": 1,
"nl": 2,
}
To create a new issue create a new file in the issues directory, this file should have content like the following:
from .base import add_issue, Issue, Evidence
class NewIssue(Issue):
# This template is later converted to language-specific using self.template
_template = {
"en": "English template ...",
"nl": "Dutch template ...",
}
_standard_issue_id = {
# Number of the issue in Dradis Issue Library add-on
"en": 1,
"nl": 2,
}
def verify(self, host):
...
yield Evidence(self.template.format(...))
add_issue('new-issue', NewIssue)