8000 Introduce reverse matches on cascading rules to enforce scope · Issue #761 · secureCodeBox/secureCodeBox · GitHub
[go: up one dir, main page]

Skip to content

Introduce reverse matches on cascading rules to enforce scope #761

@EndPositive

Description

@EndPositive

➹ New Feature implementation request

Is your feature request related to a problem?

As a pentester, I want to gain confidence in letting run secureCodeBox cascading rules unattended, so that I have assurance that secureCodeBox will only scan in-scope targets given the engagement.

Currently, cascading rules are triggered based on whether a static value exists in the finding.

spec:
  matches:
    anyOf:
      - category: "Subdomain"
        osi_layer: "NETWORK"
  scanSpec:
    scanType: "nmap"
    parameters:
      # Target Port of the finding
      - "{{location}}"

It is however not possible to verify whether the matched subdomain is present in the given scope.

A practical example engagement scope:

  • example.com
  • subdomain.example.com
  • 12.34.56.78/24

A pentester would like to investigate whether more subdomains exist so runs AMASS, it returns example.com, subdomain.example.com, and subdomain2.example.com. Nmap is triggered on all of them, while subdomain2.example.com was out-of-scope. Furthermore, it should have been verified whether example.com and subdomain.example.com even resolve to an IP in 12.34.56.78/12.

Describe the solution you'd like

In the cascading rule spec, we can introduce a field allowing rule developers to do reverse matching on scan labels.

metadata:
  labels:
    "engagement.scope/domains": "example.com,subdomain.example.com"
    "engagement.scope/cidr": "12.34.56.78/24"

Then in cascading rule yaml:

spec:
  matches:
    scanSelector:
      allOf:
        - key: "engagement.scope/domains"
          operator: Contains
          value: {{attributes.host}}
        - key: "engagement.scope/cidr"
          operator: InCIDR
          value: {{attributes.ip}}
    anyOf:
      - category: "Subdomain"
        osi_layer: "NETWORK"
  scanSpec:
    scanType: "nmap"
    parameters:
      # Target Port of the finding
      - "{{location}}"

scanSelector would be a similar field to the Kubernetes-native labelSelector, but fully interpreted in the cascading scans hook. This also allows us to define special operators (like Contains or InCIDR).

allOf is used in the example above. Would anyOf or noneOf have any further use cases?

In any case, I'd like some feedback on the problem and potential solution 🤔 . What do you think?

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0