Creating Vulnerabilities
Overview
When creating a vulnerability in AttackForge, we assign it to an asset on the project scope. There are two (2) methods you can use to create a vulnerability:
Add Vulnerability
Import Vulnerability
Considering that adding vulnerabilities is part of the role for a pentester - only users with Edit access to the project can perform this function.
Adding Vulnerabilities
To add a vulnerability on a project, click on Create Vulnerability from the project quick actions menu.
Step 1: Select Your Library
Select the relevant library.
Main Vulnerabilities contains the majority of the vulnerability write-ups/templates.
Imported Vulnerabilities contains write-ups/templates for vulnerabilities that have been imported from tools and scanners.
Project Vulnerabilities is where you can define and create project-specific vulnerability write-ups/templates. This is useful if the vulnerability contains sensitive information or data you do not want shared with other users for other projects.
Custom Libraries: any custom libraries which have been created and which you have access to.
Step 2: Select Writeup From Vulnerability Library
Select the write-up/template from the chosen library. Hovering over an entry in the library will show you the details in the right-hand side. You can use keywords to search your library.
If you cannot find a vulnerability write-up/template you wish to use, you can create a new entry in the relevant libraries by clicking on Create Writeup button.
Step 3: Select Affected Assets
Select one or more assets which are affected by the vulnerability.
You can choose from Individual or Grouped options to:
Create unique vulnerabilities on every project, and assign relevant affected assets to each unique vulnerability;
Create individual vulnerabilities for every asset; or
Create a combination of unique vulnerabilities and individual vulnerabilities – for ultimate flexibility!
Using grouped assets on vulnerabilities can help you to:
Increase efficiency when working on infrastructure penetration tests;
Reduce the overall number of vulnerabilities whilst preserving affected asset data;
Reduce effort required for quality review cycles on vulnerabilities;
Every asset can have its own notes, tags, and components.
Components can be used to track which part(s) of the asset has the vulnerabilities.
Every component can also have its own notes and tags.
Every asset can be individually tracked and actioned.
This is useful for monitoring the progress against assets on a vulnerability.
Step 4: Select Visibility
By default, vulnerabilities are set to be immediately visible. This means any project team member can see the vulnerabilities right away. This is by design, to help information flow faster to the right people and to reduce Time-To-Remediate (TTR). However you can choose to set visibility to Pending which will place the vulnerability in the draft/pending state. Only users with Edit privileges on the project will be able to see the vulnerability (for quality review, tech review, peer review).
Step 5: Score Vulnerability
If you are using manual scoring - you will have option to manually select the Likelihood of Exploitation (from 1 [difficult to exploit] to 10 [trivial to exploit]) and Priority (Critical / High / Medium / Low / Info).
If you are using the CVSS scoring, you will see in-app calculator which will help you easily determine the CVSS score and adjust Likelihood of Exploitation and Priority accordingly, including adding CVSS scores + vector string as tags.
Step 6: Add Steps to Reproduce (Proof-of-Concept)
Include detailed steps to reproduce the issue. This is a rich-text field so you can include HTML payloads.
Step 7: (Optional) Add Supporting Notes
You can include additional asset-level notes which relate to the finding. This is an optional field. You can add as many notes as needed.
Step 8: (Optional) Modify Tags
By default, tags will be assigned based on the vulnerability template in the library. However you can add additional tags if required. Note if using CVSS scoring - additional tags related to scores are automatically created for you.
You can also create custom tags which support arbitrary key/value pairs.
Step 9: (Optional) Complete Custom Fields
Custom fields may be configured in your AttackForge application. See this link for more details.
Step 10: (Optional) Link Test Cases
Where possible, try linking test cases to the vulnerability. This will help developers / engineers better understand what you were testing when it lead to discovery of this issue, which in turn provides knowledge transfer to help them avoid making same mistakes in the future.
You can link multiple test cases.
Step 11: (Optional) Upload Evidence
Upload any files and supporting evidence such as screenshots. If you want the screenshots to appear in-line in either the Steps to Reproduce or Notes sections when report is generated, you can click Add to Steps to Reproduce button or use shorthand syntax {{{YOUR_FILE_NAME}}}
The vulnerability (or vulnerabilities) will now be registered and assigned to the affected assets on the project. They will be automatically included in all on-demand reporting.
Importing Vulnerabilities
To import a vulnerability on a project, select Import Vulnerabilities from the project quick actions menu.
Select a tool you wish to import from, for example Nessus, BURP, Qualys, etc.
After you select a tool, you will be prompted to select the output file from the tool in order to parse the data. See example below for Nessus.
Once the data has been parsed, you can then select the vulnerabilities you wish to import into your project.
You will have a choice between selecting Individual or Grouped.
Individual will allow you to import one vulnerability per affected asset.
Whereas Grouped will allow you to automatically group affected assets for each vulnerability.
In the example above, we can see there was a 94% reduction in vulnerabilities when choosing Grouped option, whilst preserving the same amount of data.
This means you can focus your attention on the important vulnerabilities and track their affected assets much more efficiently.
You can view all of the affected assets, and for each asset – see related data for its affected components.
You can configure the Grouping options to adjust the rules for how the grouping is performed.
Once you have made your selection, you can move to the Edit and Review step.
Here you can see the final set of vulnerabilities for selection and make any remaining adjustments as needed prior to import.
You can still choose to configure your import options such as dynamic parser actions and selection of libraries.
Once your import begins, you will be kept update to date with its progress.
And once it’s finished, you will see a summary of the import and option to view the vulnerabilities.
When importing vulnerabilities, if a writeup does not exist in the library or cannot be mapped to using the default or custom mapping expressions - it will be automatically created for you.
Similarly if the affected asset does not exist on the project, it will be automatically created for you.
Vulnerabilities with grouped assets will now show in your vulnerability tables, with option to expand each vulnerability to see its asset data.
Custom Import Mapping
AttackForge supports the ability to define a custom import mapping expression. This can be used to map your vulnerabilities to specific entries in your vulnerability libraries.
This powerful utility helps you to:
Combine vulnerabilities into a single unique writeup
Ensure your imported vulnerabilities are matched against known good and customer-ready write-ups
Speed up your quality assurance and review process
Reduce the amount of duplicate and similar entries in your vulnerability libraries
For example, say you have three (3) vulnerabilities your wish to import from Nessus:
SSL Version 2 and 3 Protocol Detection
TLS Version 1.0 Protocol Detection
TLS Version 1.1 Protocol Detection
However, you want to map these against one (1) single known-good writeup in your library which covers all various TLS related configuration issues:
Weak TLS Implementation
You can achieve this as follows:
Example 1: Custom mapping on Tags
This expression works as follows:
For every imported vulnerability (vuln), do the following
For every writeup in the selected library (writeup), do the following
Does the vulnerability have a tag 'pluginID' (vuln.tags.pluginId)?
Does the writeup have a tag 'pluginID' (writeup.tags.pluginID)?
Is one in the other? (vuln.tags.pluginID $in writeup.tags.pluginID)
If Yes, map this imported vulnerability to the writeup in the selected library
Otherwise, move to the next writeup or proceed to import vulnerability as per normal if no match found
Add the expression:
Compare the pluginID tag in the vulnerability:
With the pluginID tag in the write-ups within the selected library:
The imported vulnerabilities which matched are now grouped by Weak TLS Configuration writeup:
Example 2: Custom mapping on Custom Tags
This expression works as follows:
For every imported vulnerability (vuln), do the following
For every writeup in the selected library (writeup), do the following
Does the vulnerability have a custom tag 'tls_weakness' (vuln.custom_tags.tls_weakness)?
Does the writeup have a custom tag 'tls_weakness' (writeup.custom_tags.tls_weakness)?
Do they match? (vuln.custom_tags.tls_weakness === writeup.custom_tags.tls_weakness)
If Yes, map this imported vulnerability to the writeup in the library
Otherwise, move to the next writeup or proceed to import vulnerability as per normal if no match found
Datapoints - Imported Vulnerabilities
vuln.priority - <string> priority of the vulnerability. Is either Critical / High / Medium / Low / Info
vuln.title - <string> title of the vulnerability
vuln.tags.<tag> - <string> a specific tag listed within tags. Requires the tag to have a colon-separator within the tag e.g. key:value
vuln.custom_tags.<tag> - <string> a specific custom tag listed within custom tags. Replace <tag> with the name of your custom tag
vuln.likelihood_of_exploitation - <integer> likelihood of exploitation for vulnerability. Is a number between 1 to 10
vuln.description - <string> description of the vulnerability
vuln.attack_scenario - <string> attack scenario of the vulnerability
vuln.remediation_recommendation - <string> remediation recommendation of the vulnerability
vuln.custom_field.<key> - <string> vulnerability custom field. Replace <key> with the key of your custom field
vuln.proof_of_concept - <string> proof of concept / steps to reproduce for the vulnerability
vuln.import_source - <string> import source for the vulnerability
vuln.import_source_id - <string> import source id for the vulnerability
Datapoints - Writeups
writeup.title - <string> title of the vulnerability writeup
writeup.tags.<tag> - <string> a specific tag listed within tags. Requires the tag to have a colon-separator within the tag e.g. key:value
writeup.custom_tags.<tag> - <string> a specific custom tag listed within custom tags. Replace <tag> with the name of your custom tag
writeup.likelihood_of_exploitation - <integer> likelihood of exploitation for vulnerability writeup. Is a number between 1 to 10
writeup.description - <string> description of the vulnerability writeup
writeup.attack_scenario - <string> attack scenario of the vulnerability writeup
writeup.remediation_recommendation - <string> remediation recommendation of the vulnerability writeup
writeup.custom_field.<key> - <string> vulnerability writeup custom field. Replace <key> with the key of your custom field
writeup.import_source - <string> import source for the vulnerability
writeup.import_source_id - <string> import source id for the vulnerability
Operators
Expressions support multiple operators which can be used to build more complex expressions:
NOT or ! - used to negate an expression. For example !(vuln.title === "TLS")
AND or && - used to and multiple expressions. For example vuln.title === "TLS" AND writeup.title === "TLS Weakness"
OR or || - used to or multiple expressions. For example (vuln.title === "TLS" OR vuln.title === "SSL") AND writeup.title === "TLS Weakness"
== - used to check for equivalency. For example vuln.title == "TLS"
=== - used to check for equality. For example vuln.title === "TLS"
!= or !== - used to check for not equivalency. For example vuln.title !== "TLS"
> - used to check for greater-than comparison. For example vuln.likelihood_of_exploitation > 5
< - used to check for less-than comparison. For example vuln.likelihood_of_exploitation < 5
>= - used to check for greater-than-or-equals comparison. For example vuln.likelihood_of_exploitation >= 5
<= - used to check for less-than-or-equals comparison. For example vuln.likelihood_of_exploitation <= 5
( ) or !() - used to group statements together. For example (vuln.title === "TLS" OR vuln.title === "SSL") AND writeup.title === "TLS Weakness"
$in - used to check if a value is in a list of values. For example vuln.tags.pluginID $in writeup.tags.pluginID
$nin - used to check if a value is not in a list of values. For example vuln.tags.pluginID $nin writeup.tags.pluginID
=~ /RegEx/i - used to check for a regular expression. For example writeup.title =~ /SSL/i checks whether the vulnerability writeup has 'SSL' within its title.
Examples
This expression will match a writeup if its title partially or fully matches the title of the vulnerability. For example, if your vulnerabilities were Out-of-date Version (React) & Out-of-date Version (Bootstrap) - you can match them to a writeup with the title Out-of-date Version.
This expression will match a vulnerability that has a tag 'pluginID' which is also found in the writeups' tags.
This expression will match a vulnerability and a writeup that both have a custom tag 'tlsweakness' which has the same value.
This expression will match a vulnerability that has either a tag 'pluginID' or 'someID' which is also found in the writeups' tags.
Last updated
