s4lt5 / control-rod

A front end UI for Nuclei and Nuclear Pond to manage findings, responses, history, and artifacts.

Control Rod

A front end for Nuclei and Nuclear Pond

Getting Started

Authentication

This app is based on the T3 App and configured for the data APIs to be protected.

To get some sort of auth working, check out the Authentication section at T3 First Steps

Discord authentication is easy to implement and recommended for local development.

After setting up auth, make sure you run npx prisma db push on a fresh install. This will create the authentication database.

Nuclearpond / s3 / athena

If you are deploying to an instance with Nuclear Pond's Terraform Module deployed, set the following in your .env:

LONG_DATA_SOURCE="athena"
AWS_BUCKET_NAME=nuclearpond-instance-name-artifacts

And specify your artifacts bucket name in the AWS_BUCKET_NAME value.

Local File Based / Developer Mode

If you have not yet done so, copy .env.example to .env and select a LONG_DATA_SOURCE of either "json" or "csv"

For "json", copy a result JSON output file from nuclei into ./data/findings.json (You may need to wrap the JSONLines output into an array to make it a proper JSON file)

For "csv", copy a result csv file from a nucleearpond athena query to data/findings.csv

You will then need to run the mysql database via docker compose. copy the EXAMPLE-docker-compose.yml to docker-compose.yml and change the root and controlrod passwords.

Finally, update the .env file with the password you have created.

Nginx reverse proxy

If you want to host this via nginx and expose the local dev port to external hosts, an example config file is contained in this repo at example-nginx-config/sites-available.

First install nginx, then copy this file into /etc/nginx/sites-available/default

Also, copy example-nginx-config/snippets/* to /etc/nginx/snippets/

run the following in a root shell:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/nginx-selfsigned.key -out /etc/ssl/certs/nginx-selfsigned.crt
openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048
ufw allow 'Nginx Full'
ufw delete allow 'Nginx HTTP'
nginx -t

If there is no error, follow with

systemctl restart nginx

Finally run the following

Disclosure Template

In the /artifacts directory, there is a disclosure_template.docx file which contains a basic disclosure template with various {field} tags. This can be edited with your team's logo, letterhead, formatting to allow for quick generation of disclosure notices of a particular finding.

control-rod's Issues

"Hide Disclosed Findings" should not hide issues that are marked remediated, but still show up as findings

If there is a regression, it should not get hidden, and there is some back end work needed to accomplish this.

Potentially, the following could happen:

• We find a critical vuln on site A
• DIsclose it, note it is fixed
• Vulnerability resurfaces on a later date
• But it is still hidden because it is "disclosed".

"Hide disclosed" should probably explicitly ignore certain disclosure statuss.

Landing Page

Potentially, mulitple groups will be accessing the dashboard.

It should be obvious what is and what is not in CR, as well as where they are.

The dashboard should highlight all of the major areas of the app and make it plain what it does and does not do.

If we add a major feature, it should be on the dashboard prominently.

The "default" page should drop to a dashboard that has summary info including

• Most recent scan date
• Breakdown of open tickets and counts (critical high medium low)
• Other disclosure status (false positive, disclosed, etc)
• Link between disclosure and resolved (time to resolve, open tickets, blah blah blah)
• Probably contact info for issues

Findings / Hosts / Disclosures should be easily exportable

On each major page, there should be an "export to..." button that exports the general collection to e.g. CSV or JSON

On the main dashboard, a "export (ALL) data" option should be present that provides a .zip of each host/disclosure/findings major dataset.

"FInding History" is broken / unimplemented.

When I look at a particular finding, there is a "last seen" field in the UI. This should a) work, and b) give insight into how many times this hit has appeared.

Disclosures Management

The app needs a section for disclosures to keep track of:

• What has or has not been reported on
• What has been remediated
• Where additional report/disclosure information is found (e.g. the ticket)
• False positives / or otherwise ignored findings.
• Inconclusive findings / where it is not known if an exploit is possible or not
• Timeline for disclosure, remediation, regression
• regression e.g. when a finding re-appears after disclosure
• The host(s) involved
• The specific finding being disclosed or otherwise discussed

The disclosure section should be able to create the "Disclosure Template" and pre-fill host information as much as possible.

Ideally, the disclosure section can create a new "disclosure ticket" from a finding, and pre-populate as much information as possible.

Disclosures should exist in a separate "disclosures" page, but also fill in data directly into the "findings" page such that an issue with related disclosure(s) shows e.g. a badge next to the severity or somewhere in the finding row.

The findings page should have a "hide disclosed" filter.

(VERY) roughly drawn out, I think we should have an option to directly create a disclosure from a row and fill in as much as possible.

"Wizard Mode" for nuclei

Red teamers need a UI in the app to run ad-hoc scans.

A end user should be able to:

Launch a nuclei scan from the GUI while specifying the following:

• Severity ( low med info high)
• Host(s)
• Rate limit options
• Debug on/off
• Interact.sh options

The UI ideally will launch the nuclei process in the background and "tee" the output into a live window.

Ideally, when a nuclei scan is finished, the output should be directly consumable by the app in e.g. the mounted data directory.

Here is a (VERY ROUGH) concept

We need to test what does and does not work in the host input with nuclei as a red teamer may be specifying CIDR ranges, single IPs, domain names, etc.

The output "a scan" should have the minimum data attached to it:

• The host
• Text output
• JSON or other structured findings data
• The start and end time
• exit code
• The initiator
• The version of the tool and plugins

There is potential for disaster here, and a solution for this should have one or more of:

• A disclaimer for the 'foot gun' that we are providing
• Limitations on the host range or number hosts that can be scanned at once
• Activity log of who did what, when and logging of each individual scan and user who initiated.
• Potentially, host whitelisting to avoid accidental out of scope scanning.

Findings scans should be deduplicated

We're not really sure how multiple scans will show up in nuclearpond.

In findings views, multiple findings for the same host and template id should be grouped and summarized under the "last seen / found when" section of the finding details.

A finding that was picked up on a scan 10 different times, should still only show up as one row in the "findings" view.

Findings should be keyed on:

• host
• template id

And differentiated by timestamp

Host / Scope Management

There is almost always a list of in-scope targets before operations begin.

The application should provide a method for ingestion and management of in-scope hosts.

A /hosts page should exist where we can view information about each host, related organization, and historical findings.

Scans such as from #2 should be restricted to targets declared in-scope, and findings and disclosures should also be related to the host record.

A host record should have at least:

• a endpoint (hostname)
• an organization

Hosts should be able to be bulk-imported from e.g. CSV with options for single-record editing as well as bulk import/export/purging.