I couldn't wait, and was trying to devise a solution for a couple of
rules that I didn't want to cripple so I think I've come up with a
workaround....
If you pipe all of the suspect variables strings into the std input of
a spawned app rather than putting any vars on the shell line then it
should be 100% safe to pass in anything you like no matter how suspect
as long as the program you are passing to have no vulnerabilities or
interpretation of the injected strings.
Here is a very simple rule to demonstrate what I think should be safer
to implement:
type=Single
ptype=RegExp
pattern=(\w+)
desc=$0
action=create testcontext; \
add testcontext $1 --> H4R1 was ere 2k8; \
report testcontext /bin/cat; \
delete testcontext
Since $1 is passed in to the context body, and then piped via std to
the shell command, the variable itself never comes in to contact with
the shell and therefore poses no thread of command injection as long
as the command to which it is passed makes no evaluation of it and
treats it as a string literal.
Feedback welcome.
Thanks
-h
2008/7/29 Hari Sekhon <[EMAIL PROTECTED]>:
> 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
>
>
--
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
