Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generic SSRF DNS - No Reflection Lower Severity #2230

Open
random-robbie opened this issue Jan 30, 2025 · 1 comment
Open

Generic SSRF DNS - No Reflection Lower Severity #2230

random-robbie opened this issue Jan 30, 2025 · 1 comment
Assignees
Labels
enhancement New feature or request

Comments

@random-robbie
Copy link
Contributor

Describe the bug

description: 'Out-of-band interaction: [Generic SSRF (GET)] [Triggering Parameter:
  Host] [DNS] Echoed Response: False'
host: xxxx.com

Expected behavior
This type of result is not particularly useful for review and should have either lower severity or an option to ignore.

BBOT Command
Example: bbot -m httpx -t evilcorp.com -m generic_ssrf

Additional Context:
Is it worth noting that there was a DNS response at all? Many of these detections occur due to proxying, CDNs, and other factors that don’t necessarily indicate an actual SSRF vulnerability. HTTP-based SSRF is more critical, but right now users can get bombarded by irrelevant results.

It would be great to have a configuration option to filter out or deprioritize these cases.

@random-robbie random-robbie added the bug Something isn't working label Jan 30, 2025
@liquidsec
Copy link
Collaborator

I think any OOB interaction is notable and is often telling you something interesting about the target. Both DNS and HTTP interactions can be triggered by something like a WAF and cause a false positive, unfortunately there is really no good way to rule those out.

I agree that DNS interactions are potentially much less interesting and FP more often. However they very much can indicate a full blown vulnerability, especially when it comes to XXE - that may never be capable of causing an HTTP request but may still be fully exploitable via an error-based technique, etc.

I need to think about each case and may have a different adjustment for each. But I think an http_interaction_only option or something like that would be fine.

@liquidsec liquidsec added enhancement New feature or request and removed bug Something isn't working labels Jan 30, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants