Bug #464
closed
Suricata http request double encoded null byte FN
Added by rmkml rmkml about 12 years ago.
Updated almost 12 years ago.
Description
Hi,
ok Im continue my Suricata testing, tested with this cmd:
wget "http://192.168.1.1/a%2500b.c"
next, use only two Suricata signatures:
fire:
alert tcp any any -> any 80 (msg:"null byte http encoded 1"; flow:to_server,established; content:"%2500"; classtype:attempted-recon; sid:21; rev:1;)
not fire:
alert tcp any any -> any 80 (msg:"null byte http encoded 2"; flow:to_server,established; content:"|00|"; http_uri; classtype:attempted-recon; sid:22; rev:1;)
Suricata not fire if detect double encoded null byte with http_uri, of course snort always fire.
Tested on suricata git at 16 May 2012. same results with v1.2.1.
Regards
Rmkml
Files
To update on what rmkml has posted, any double encoded sequence isn't double decoded by libhtp.
Ideally libhtp would take care of this.
- Status changed from New to Assigned
- Assignee set to Victor Julien
- Target version set to 1.3beta2
- Target version changed from 1.3beta2 to 1.3rc1
- Status changed from Assigned to Closed
Fixed by improving the HTPCallbackRequestUriNormalize callback.
- Status changed from Closed to Assigned
- Target version changed from 1.3rc1 to 1.3.1
Playing with Apache and this encoding the original behaviour was correct after all. Apache (the server used in the pcap) doesn't seem to decode %00 or it's double encoded variant %2500. In such a case Suricata should not invent it's own decoding. It should stay as close to what the end host does as possible.
- Status changed from Assigned to Closed
Update this to only double decode if instructed in the config:
# double-decode-path: Double decode path section of the URI
# double-decode-query: Double decode query section of the URI
libhtp:
default-config:
personality: IDS
double-decode-path: no
double-decode-query: no
Also available in: Atom
PDF