Re: DNS CACHE POISONING? - Our Portal is redirecting to our first competition

["Jason Stelzer" <jason.stelzer () gmail com>]

All bets are off because there is no way to conclusively prove that a
compromise stopped at a certain point. Best practice dictates that you
reimage the box[1]. The issue really is that nobody has complete
knowledge of everything. Any number of as yet unreported exploits
could have been used to elevate privileges for example. I'll go out on
a limb and claim that various blackhat communities know of exploits
that vendors and admins are as yet unaware of.

The only defense against that sort of thing is a reliable recovery
process. In my experience the cost of 'overreacting' to a compromise
is greatly offset by the risk posed by not fully eliminating the risk
of exposing sensitive internal processes/data.

I will grant you that each incident does present different degrees of
exposure/risk. However, if I were going to put my name beside the
solution, I would want to recommend the best course of action to
completely mitigate/eliminate risk. What is actually implemented may
differ, but at that point I would feel that my expected due diligence
had been met and that everyone understood what any remaining risks
were and found them acceptable.

[1]
http://www.cert.org/tech_tips/root_compromise.html

On Jan 29, 2008 7:22 PM, Eduardo Tongson <propolice () gmail com> wrote:
> Yeah, completely forgot about those ran as root and setuid programs.
> Been a while since I have seen those. Also forgot about the usual
> admin errors. But it is ridiculous to say "all bets are off" when a
> user gets a shell. Thats got a lot to say about the admin in charge.
>
>
>   Ed <http://blog.eonsec.com>
>
>
>
>
> On Jan 30, 2008 2:59 AM,  <Valdis.Kletnieks () vt edu> wrote:
> > On Tue, 29 Jan 2008 07:57:39 +0800, Eduardo Tongson said:
> > > kernel used is fully updated and root SSH login dismissed do you know
> > > a way of getting root without an unknown kernel bug?
> >
> > The *vast* majority of "get r00t kwik" exploits do *not* involve exploiting
> > kernel bugs, but involve exploiting daemon processes running as root or
> > set-UID programs.  So if you have CUPS running, they don't need a kernel
> > exploit, they just need a CUPS exploit (and CUPS *has* had a few issues).
> > Same for Sendmail, NTP, the X server, or any of the other things found on
> > the average Unix/Linux install....



-- 
J.