Skip to content

Instantly share code, notes, and snippets.

@lifeforms
Created November 25, 2014 22:02
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save lifeforms/660e995254aba740856e to your computer and use it in GitHub Desktop.
Save lifeforms/660e995254aba740856e to your computer and use it in GitHub Desktop.
@fuzzyHash problems and ideas

###@fuzzyHash rule doesn't fire

The @fuzzyHash example from regression tests doesn't seem to fire for me.

Config (in early part of httpd.conf before CRS):

SecRule REQUEST_BODY "@fuzzyHash /opt/httpd/tmp/ssdeep.txt 1" "id:1,phase:2,log,deny,status:409"
SecRule REQUEST_BODY "wtf" "id:2,phase:2,log,deny,status:409"
SecRule REQUEST_BODY "SecCookieFormat" "id:3,phase:2,log,deny,status:405"

Test:

# curl -s -w "%{http_code}" -o /dev/null --data @mod_security2.conf https://test/
405
# curl -s -w "%{http_code}" -o /dev/null --data-urlencode @mod_security2.conf https://test/
405
# curl -s -w "%{http_code}" -o /dev/null --data-urlencode '/etc/wtf' https://test/
409
# curl -s -w "%{http_code}" -o /dev/null --data-urlencode '/etc/passwd' https://test
403

Code 405 reveals that the request was not blocked by @fuzzyHash, but by the rule matching SecCookieFormat which is also contained in the post data. The last two examples demonstrate that this piece of configuration is really running before CRS.

Running ssdeep on the command line works:

# ssdeep -m /opt/httpd/tmp/ssdeep.txt mod_security2.conf 
/usr/local/etc/apache24/security2/mod_security2.conf matches /opt/httpd/tmp/ssdeep.txt:modsecurity.conf-recommended (72)
# cat /opt/httpd/tmp/ssdeep.txt
ssdeep,1.1--blocksize:hash:hash,filename
96:MbQ1L0LDX8GPI8ov3D2D9zd6/gz2wZhFvV0O598La8Kqvfi0znNa8Xi5SM7XRWCK:KvL8Gg8rWIz2ZKqvfjzQ55RpRHjftQ++,"modsecurity.conf-recommended"
192:b8B5UQvywcMIJuavpde/Yyz/U/vF+vGCoCvrQr/dw:afcnrvp8zqUvGrzr6,"README_WINDOWS.TXT"
96:+qK8Z4gA165/hquKNMi68zuEyMM9qNB26x:+RG4z6c1LyZOB26x,"README.TXT"

###ssdeep file is read after chroot

As a second point, the ssdeep input file is apparently being read after the chroot call (when using ModSecurity SecChrootDir functionality). This means the ssdeep files now are required to reside in the chroot. I would not recommend people to store configuration in there. Is it possible to move initialization to some other point?

###Nonexistent file handling

As a third point, it seems that ModSecurity only complains about a nonexistent ssdeep input file when a request happens. If the path name after @fuzzyHash operator does not exist, the rule fires on every request that has a body:

Message: Access denied with code 403 (phase 2). Not able to open fuzzy hash file: /usr/local/etc/apache24/security2/activated_rules/ssdeep.txt [file "/usr/local/etc/apache24/security2/activated_rules/early_01_global.conf"] [line "24"] [id "192372"]

It would be preferable if this error is given during Apache reload/configtest, as for the other files. If it turns out that ssdeep initialization cannot be moved into this phase, I recommend that ModSecurity itself tries to stat the file.

###Documentation

Finally, I would recommend adding usage examples for @fuzzyHash to documentation. (Maybe I'm calling it wrong and more information is needed to test it.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment