Chris Petersen wrote: > A friend of mine (who introduced me to SEC) just sent over a link to a > rather interesting/disturbing article that details methods of > attacking log analysis tools like SEC: > > http://www.ossec.net/en/attacking-loganalysis.html > > I suspect a lot could be fixed by updating the patterns that we use > (given that SEC has the power of perlre behind id). It's also a good > reason to use strict matching and anchoring to the start *and* end of > log strings. > > -Chris Thanks for posting that to the list Chris, I read the article with great interest when you posted it and have been giving it some thought since then.
I run Sec on my logserver and I've come to the conclusion that it is extremely difficult to prevent attacks on log analysis when using variables from regex matches in things like shellcmd, spawn, report etc which execute in a shell. The reason for this is that the logserver accepts logs from the network, so no matter how tight your regex, it is alway possible for someone to insert an arbitrary string which the regex will match and cause the variable you are capturing to be injected with an arbitrary string, resulting in command execution in things like shellcmd, spawn, report etc. One example in which it can be safely done is if you are limiting your variable to the hostname for the log and you use keep_hostname(no) in syslog-ng or equivalent logserver software, which should guarantee it is a correct ip address or hostname (assuming your DNS isn't compromised/intercepted if using that to resolve the hostname - another potential threat). Otherwise, pretty much the entire rest of the log is vulnerable to tampering through manual network insertion of logs in to the logserver since it has to accept logs from the network being a logserver. Also, what about just inserting arbitrary string matches locally using logger... so not even a stand alone box seems safe from injection outside past the hostname... Question 1: I'd love you hear anyone's view on this or if anyone out there has anything more to add. Question 2: As you can imagine, I'm being extremely careful to make sure that my setup is impervious to such injections, which brings me on to my next question: Risto, is there something we can do to "100% guarantee" nullify the effects of shell metachars by using built-in escaping or similar in Sec? I think this is worthy of a feature request to reduce the likelihood that there could be a log analysis attack on/through Sec itself through funny injected chars and cmd subshells, command continuation characters or whatever. I know there is a quoting/noquoting option but I'm not sure if this is enough or even applies to vars in spawned shells? In it's absence I am simply not using any vars at all that could potential form a point of injection, but I wouldn't mind starting to use more if I could be assured of their shell safety... Could you shed some light on this Risto? -h -- Hari Sekhon ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Simple-evcorr-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
