feat: upload textproto for Ofbiz_CVE_2023_51467 #708
Conversation
|
Hi @W0ngL1, thanks for your contribution! |
|
In this PoC, I chose to use a direct response-based detection method instead of an OOB channel. The main reason is that if the target environment is unable to initiate outbound network requests, OOB-based detection will fail. In contrast, using an in-band response makes the PoC more straightforward, easier to verify, and more compatible across different deployment environments — especially those with restricted egress traffic. |
|
Hello @W0ngL1, Adding a fallback to response-based detection would definitely be useful when egress filtering blocks OOB callbacks. The ideal flow would be: if CBS is configured, run OOB detection first; if that fails or CBS isn’t configured, fall back to response-based detection. The templating engine doesn’t appear to support this natively, but @tooryx might know whether there’s a practical workaround with the current capabilities or if this is planned for future support. That said, having a dedicated workflow for OOB detection is still the preferred approach. For now, keep the current logic as a fallback only when CBS is not configured, following the guidance here: https://google.github.io/tsunami-security-scanner/howto/new-detector/templated/06-callback-server. |
|
Thanks for the detailed guidance — that makes sense from a framework design perspective. Just to share the reasoning from a practical penetration-testing standpoint: we typically prioritize detection methods based on the vulnerability behavior itself. If a vulnerability provides a direct in-band response, that's usually preferred because it’s faster, more reliable, and leaves no dependency on outbound connectivity — which also makes it more stealthy and less intrusive. OOB is generally used when no direct response can be observed. That said, I understand the preference to standardize on OOB-first workflows within the Tsunami framework. If it's required that future detectors always default to OOB first, I can certainly follow that convention. However, for this particular vulnerability, given that the response-based indicator is explicit and deterministic, I still believe it makes sense for it to be the primary detection method. Happy to adjust if needed — just let me know your final expectation. |
|
Sorry for the delayed response, after some internal discussion we've come to the conclusion that this is fine as it is. Thank you for your patience. |
|
LGTM - Approved Reviewer: Giacomo, Doyensec |
3 participants
Hi @tooryx, @leonardo-doyensec,
It's the templated plugin for Ofbiz_CVE_2023_51467, whick linked to #388.
Here is the testbed PR: google/security-testbeds#168.
I found a small but practical issue when testing Apache OFBiz: after deployment OFBiz treats localhost as a trusted host by default, so requests that use any other IP trigger a “host not trusted” error. To work around this I added a Host: localhost header in my vulnerability plugin requests, but in real scans the trusted host can get changed by the configuration, which makes reliable reproduction harder.
I considered using the built-in T_NS_HOSTNAME variable, but that doesn’t match the local deployment behavior I want to reproduce (it’s inconvenient to force a scanner to use the machine’s hostname as Host).
A few ideas that might help:
Add an explicit option to the scanner/plugin to force a custom Host header (e.g. force_host: "localhost") so tests can reliably reproduce host-based checks even when proxying or using different target IPs.