I patched for shellshock and was barraged a few days later. However, I would not have known any attempts were made at all if not for a regular expression I found on the internet. This has inspired me to look further into my logs. Is there any centralized list of regexes I can use in a script to parse my logs for common exploits attempts such as SQL Injection or XSS?
2 Answers
The best solution would be to implicitly deny, i.e. allow exactly the data you want, but no other.
You could write regexps matching all input that's not according to your filter to find any odd input, that might be an exploit. It is also a good way to find valid input you omitted in your regex.
A username might be fine with [a-zA-Z0-9]+
, rather than removing single quotes or similar to sanitize input.
EDIT:
This is the approach I would take:
- Add regexps to implicitly deny all inputs, to fix this problem in the future.
- Check the data in the log files against the regexps that were written in step 1
- Remove all input data in the log files that matches the regexps.
- Reduce the logs by counting identical rows and deduplicating them, so we don't have to look at 1000 identical rows, but still know that we had 1000 rows like that in the log files.
- Check if any of the logged input should be valid. If so, update the relevant regex and goto step 2.
- Check if any of the remaining log inputs look suspicious.
- 1,593
- 1
- 11
- 20
-
Wouldn't that return an immense amount of false positives? – Dylan Katz Nov 10 '14 at 17:30
-
Probably. Deduplicate it and if that's enough you just go through them all. Next time you'll add the regex input validation at once, because you're never going to make this misstake again. – Filip Haglund Nov 10 '14 at 18:04
-
I'm not using this for input validation. I'm sorry I didn't make that clear. This is for searching through logs to find attack attempts in post/get requests. – Dylan Katz Nov 10 '14 at 18:17
-
Edited my answer. I hope I clarified what I ment. – Filip Haglund Nov 10 '14 at 19:56
Regular expressions are of very limited use here as any attack delivered via a HTTP POST request is unlikely to get logged. There are also many examples of header values having an impact while not being logged, ie: shellshock. There will also be alot of noise from automated scanners like Nikto that have no impact unless the visited url exist and is vulnerable.
If you are going to go looking through your logs a good place to start would be to export rules from mod_security or snort. It is worth noting that these may need modification to be compatible with the regex engine used by your search tool, such as grep.
- 5,745
- 2
- 17
- 26