>> In order to hack into a Solaris box I think that you >> pretty much have to get >> through SSH and then somehow drop a kernel module >> into place or something >> that can not be tracked with ps, prstat, sar activity >> or userland activity >> of any kind. > > No, no special Voodoo-hoodoo is required. Breaking SSH and using a few lines > in DTrace will do. > > After that, you'll be virtually invisible in the process table, but your > processes will still run. > > If my memory still serves me correctly, the DTrace approach doesn't even so > much as require any modification of utilities like ps(1), therefore, not > even an integrity check with bart(1M) or tripwire will pick anything up. A > little bit of Googling will get you to the article (PDF, from what I > remember), and another way is through Slashdot, someone posted a link to the > whitepaper detailing the DTrace approach step-by-step. > > Using a tool like cd00r.c, which opens up one of these invisible processes > after a sequence of specially crafted packets are sent, and there's your > backdoor into a Solaris box. The network logs will be empty and the sysadmin > will have no clue that you're on his system. The code is available here: > > http://www.phenoelit-us.org/fr/tools.html > > Just hope that any OpenSSH vulnerabilities (which Sun SSH is based upon) are > fixed and your systems patched before you get hit. >
Thankfully I run openssh-4.7,REV=2007.12.26_rev=p1 ( from Blastwave.org ) pretty much everywhere and I disable the SunSSH entirely. It is updated too slowly for my tastes. Also I try to watch the IPFilter maillists closely and while I know that Darren Reed is a Sun guy now I don't think that the ipfilter in Solaris is anywhere kept up to date. So long as the door is slammed shut I'm safe. I hope. >> Really, I don't know how someone would hack a Solaris >> box. and I didn't. gee thanks for giving me one more thing to worry about. Dennis _______________________________________________ opensolaris-discuss mailing list [email protected]
