Request a reattack

Role required: User, Vulnerability Manager or User Manager

1. Go to the Vulnerabilities section and choose the vulnerability type you want to reattack.

   

2. In the Locations section, you must select the vulnerability that has already had a solution applied and is ready to do the reattack. Keep in mind that to request a reattack, locations must be in Vulnerable status, and only those whose reattack status is neither Requested nor On Hold are eligible to do this action. Once you have selected it, click on the Reattack button on the right side of the screen.

   

3. A pop-up window will open where you must detail the solution applied to the vulnerability.

   

4. After requesting the reattack, you will see the word Requested in the Reattack column corresponding to that vulnerability. From then on, you will have to wait for the response from the Fluid Attacks team. The latter’s response time will comply with the conditions outlined in the service-level agreement.
   

   

5. In the Consulting section, you will see a new comment related to the justification you gave when requesting the reattack. In this same tab, our hackers can generate other comments and notify the decision taken on your request.

   

The reattack status will be Verified (vulnerable) if the vulnerability you requested to reattack is still exploitable. Our hackers will give you evidence of how it was exploited, which you can access in the Evidence section.

If the vulnerability is still vulnerable and you cannot close it for the moment, you can consider defining other Treatments. One of them is Permanently accepted vulnerability. However, you can later try to remediate this vulnerability and request a reattack to verify its remediation.

The status will be Verified (safe) if the vulnerability you requested to reattack has been proven by our hackers to have been successfully remediated.

Reattacks on hold

Sometimes reattacks are delayed due to events in your environment, and having to send another reattack request can be tedious. That is why Fluid Attacks' platform has the On_hold status for reattacks. This status denotes when reattack requests are put on hold. When the events are solved, the reattack request is automatically reactivated without having to be repeated. This use of automation provides agility to the reattack process.

Reattacks for vulnerabilities detected by the automated tool

If the vulnerability was reported by the tool, there is no need to attach or write any detailed justification, since this service only analyzes code that is found on the repository and does not account for anything extra. If you believe the report might be a False Positive or is not a vulnerability due to extra configurations in your environment, you can contact a hacker or request the Zero Risk treatment, instead of the reattack.

Because of the automated nature of the tool, the consulting report will only have a simple message, detailing open or closed locations resulting from the re-attack. If the reasons for the results of the re-attack are not clear, you can check the documentation of the vulnerability for code examples, or, contact a hacker if it is still unclear.

Reattack a permanently accepted vulnerability

Role required: User, Vulnerability Manager or User Manager

Over time, you may request a reattack on a vulnerability that has been permanently accepted. This may happen, as it is possible that you may have found a solution to this vulnerability and would therefore like our hackers to test whether or not its implementation was effective. Thus, the permanently accepted treatment represents an open location for which you can request a reattack on the platform with no problem.

To request a reattack on a permanently accepted vulnerability, you must go to the vulnerability type, tick the check box on the left of the location you want to reattack, and click Reattack.

A pop-up window will appear asking you to provide a description of the solution you applied to this vulnerability.

Click Confirm, and the description saying Requested will appear in front of the previously selected location.

For the purpose of traceability, you can go to the Consulting section, where all the history of reattack requests, along with their respective justifications, persons in charge and submission dates are recorded.

An ethical hacker will be responsible for verifying the effectiveness of the remediation, with a response deadline of 16 business hours. In case the evaluation results show that the vulnerability is still open, this means that the ethical hacker found a way to exploit it. Evidence of this will be provided by the ethical hacker. You can access this evidence by going to the Evidence tab.

To know the status of the reattack, you simply need to go to the Locations tab and see what is next to Reattack. The gray circle with the description Requested will appear at the beginning when the reattack is about to be carried out or is in progress. The red circle and the description Verified will appear if the vulnerability remains open in the corresponding location after the reattack. Conversely, the green circle and the description Verified will appear if the vulnerability is closed in the corresponding location after the reattack.

Error when requesting reattacks

Sometimes, when attempting to request a reattack, the platform may not allow it. A pop-up error message is displayed in such cases, asking you to update the repository before requesting the reattack. The image below shows the error message:

This issue usually arises because the latest version (last commit) of the repository associated with the vulnerability you are attempting to fix is old (more than 1 day old), or because the vulnerability is still present in that last commit of the repository (or even in a previous commit). Therefore, the platform checks if there is a more recent commit available and determines that a fix for the vulnerability you are trying to reattack has not yet been implemented.

When a certain situation occurs, it is recommended that you take the following steps:

1. Check the current version of the stored repository (in your remote version control system or remote container where the repository is hosted) and make sure that the latest commit is a recent one (in which the solution to the vulnerability you are trying to reattack is found).

2. If so, update the repository (i.e., upload the necessary changes to fix the vulnerability). Make sure that the changes are uploaded to the same branch that is registered in Scope.

3. Return to the platform and request the reattack again.

4. If necessary, go to Scope and manually update the repository (by clicking the Sync button available), and once the status goes to OK, request the reattack again.

Notes:

1. To reattack several vulnerabilities associated with multiple repositories, you must perform the above steps on each repository associated with those vulnerabilities.
   
2. In case you have any inconvenience, or if you consider that an update of the repository is not required to verify the presence of the vulnerabilities that are being addressed, we suggest you contact the support channel help@fluidattacks.com.