Hello. I'm unemployed so I have nothing better to do except mess around with nuclei to create evasions for JA4+, similar to what you can do with -tlsi that I pointed out here
... When I noticed this:
The offending nuclei template is ./2021/CVE-2021-44228.yaml
Steps to reproduce, create a packet capture and then run nuclei -t ~/nuclei-templates/cves/http/2021/CVE-2021-44228.yaml against a target to generate the Accept-Language header.
Seems like an easy fix here. I have attached a pcap of that CVE here. It just seems bad overall to have a Log4shell payload appear anywhere where something upstream from ja4h.py could parse it. A minor change would be to force it to truncate to [:4] regardless of what payload is there, since I believe that is the intended purpose:
def http_language(lang):
lang = lang.replace('-','').replace(';',',').lower().split(',')[0]
return f"{lang[:4]}{'0'*(4-len(lang))}"
Hello. I'm unemployed so I have nothing better to do except mess around with nuclei to create evasions for JA4+, similar to what you can do with
-tlsithat I pointed out here... When I noticed this:
The offending nuclei template is
./2021/CVE-2021-44228.yamlSteps to reproduce, create a packet capture and then run
nuclei -t ~/nuclei-templates/cves/http/2021/CVE-2021-44228.yamlagainst a target to generate the Accept-Language header.Seems like an easy fix here. I have attached a pcap of that CVE here. It just seems bad overall to have a Log4shell payload appear anywhere where something upstream from ja4h.py could parse it. A minor change would be to force it to truncate to
[:4]regardless of what payload is there, since I believe that is the intended purpose:Something like that maybe?
:point_down: Packet cap for you. CVE-2021-44228_http.zip