log4j-scanner is a project derived from other members of the open-source community by CISA to help organizations identify potentially vulnerable web services affected by the log4j vulnerabilities.
1.28k
stars
215
forks
source link
Update Scanner to allow individual requests, sleep timer and payload identifier #29
Update Scanner to allow individual requests, sleep timer and payload identifier
π£ Description
I added 3 aspects:
Noticed that the scanner submits all headers/parameters at once. This can cause issues with how the target server responds to the request (ie: server may not accept certain headers, but this is not easily identifiable). Added a functionality to send all headers individually (-i, --individual)
Added ability to sleep between requests (--sleep-time [Default: 1]). This will assist with reviewing DNS/CanaryToken logs to more easily identify which header is vulnerable based off the REQUEST time and RESPONSE time by custom DNS.
Added payload header canary. When submitting a request, the payload will contain the header and parameter value. For example: ${jndi:ldap//.User-Agent.}. Now, when reviewing logs, you can identify that the User-Agent header was where the vulnerability was.
Terminal will display the type of request (GET/POST), the Header that was submitted and the UTC time in which it was sent. This will also help with identifying CanaryToken, Interact.sh and Burp Collaborator responses
π Motivation and context
I noticed that the scanner submits all headers at once. This can cause issues with how the server responds (it may give a 400 for example). It may be impossible to know which header is not accepted. Instead, this update allows individual requests to be submitted for a more targeted scan.
With that said, if the vulnerability is triggered, it may be difficult to know which header or parameter triggered the vulnerability. Added a RegEx ability to remove a canary token in the payload (HEADER) with the Header/Parameter that is being submitted. This will allow an easier time identifying what triggered the vulnerability.
π§ͺ Testing
I tested this by scanning a vulnerable host with a smaller header.txt file (to speed up testing). Proxied the request through burp to verify that request is working as intended (is the header name in the payload, is it sleeping for proposed time, is the parameter in the payload, does the terminal display the request time and appropriate header, etc)
I tested with the waf-bypass and appears to incorporate these changes correctly. Also tested with --test-CVE-2021-45046 and appeared to work correctly as well.
I did not teste with the default interact.sh callback provider. All tests were performed with Burp Collaborator and CanaryToken.org
β Pre-approval checklist
[ ] This PR has an informative and human-readable title.
[ ] Changes are limited to a single goal - eschew scope creep!
[ ] All future TODOs are captured in issues, which are referenced
in code comments.
[ ] All relevant type-of-change labels have been added.
Update Scanner to allow individual requests, sleep timer and payload identifier
π£ Description
I added 3 aspects: Noticed that the scanner submits all headers/parameters at once. This can cause issues with how the target server responds to the request (ie: server may not accept certain headers, but this is not easily identifiable). Added a functionality to send all headers individually (-i, --individual)
Added ability to sleep between requests (--sleep-time [Default: 1]). This will assist with reviewing DNS/CanaryToken logs to more easily identify which header is vulnerable based off the REQUEST time and RESPONSE time by custom DNS.
Added payload header canary. When submitting a request, the payload will contain the header and parameter value. For example: ${jndi:ldap//.User-Agent.}. Now, when reviewing logs, you can identify that the User-Agent header was where the vulnerability was.
Terminal will display the type of request (GET/POST), the Header that was submitted and the UTC time in which it was sent. This will also help with identifying CanaryToken, Interact.sh and Burp Collaborator responses
π Motivation and context
I noticed that the scanner submits all headers at once. This can cause issues with how the server responds (it may give a 400 for example). It may be impossible to know which header is not accepted. Instead, this update allows individual requests to be submitted for a more targeted scan.
With that said, if the vulnerability is triggered, it may be difficult to know which header or parameter triggered the vulnerability. Added a RegEx ability to remove a canary token in the payload (HEADER) with the Header/Parameter that is being submitted. This will allow an easier time identifying what triggered the vulnerability.
π§ͺ Testing
I tested this by scanning a vulnerable host with a smaller header.txt file (to speed up testing). Proxied the request through burp to verify that request is working as intended (is the header name in the payload, is it sleeping for proposed time, is the parameter in the payload, does the terminal display the request time and appropriate header, etc)
I tested with the waf-bypass and appears to incorporate these changes correctly. Also tested with --test-CVE-2021-45046 and appeared to work correctly as well.
I did not teste with the default interact.sh callback provider. All tests were performed with Burp Collaborator and CanaryToken.org
β Pre-approval checklist
β Pre-merge checklist
β Post-merge checklist