interesting sk backdoor
From my experience with the suckit backdoor by sd/devik/etc :
The sk backdoor which is not really a virus/worm because its not spreading by itself
but it is still spreading very fastly on poorly secured linux systems (redhats.. suses.. etc) (thanks to mass hacking scripts)
The typical schem is : mainly intrusion via php/whatever injection,
good old ptrace exploit and to end sk rootkit + reboot.. after this the guy might be cleaning the http logs and so on.
Very hard to detect because no use of system.map, directly in memory from kmem,
hides directories, files, pids, sockets, and is not compiled on the victim server directly,
only the binary is used. Mostly from my experience with "online" checking : tools such as rkhunter,
chkrootkit were not efficient. Later i found out that kern_check from la-samhna.de could detect sk,
by reading System.map and checking if the memory system calls were at the same addresses as the one shown by
System.map - in fact itcould (maybe its already done) be easy to trick via changing the system.map file i guess
(or whatever other method).
The only true way i have got to detect it is mainly to boot the server with a rescue cd or whatever
boot disk and find for hidden files, which makes appears mostly the good old .pwdhack from suckit
and a few other files. find / -name ".*" -print is approx the best here, or checking the /sbin directory
for multiple "init" because sk used to replace old init by itself (to survive reboot). Now i guess newer versions
might be more sophisticated, such as putting themselfs into /etc/rc.d files to survive reboot (?) .
by the way sk is pretty stable, unlike for instance gmon (been talking about it a few days ago).
it can be running for a long time if you dont detect any hacking attempts/suspicious things on the server.
At the time, a good experience online with sk 1.1 i used to see the hacker on the fly playing with his shell via ettercap
that was reading the "hidden sockets" - i never got the chance again to do so, very hard to catch a hacker on the fly and
its pretty sensitive to do.
Also i noticed that mainly people using sk on hacked servers wont remove logs of the sk sniffer giving tracks of
their boxes and logins/passwords hacking/spam tools download. I could for instance track back this guy from Chicago,
(running some hosting company) checking up his home server, taking a fast look to his "email-VISAxxx.txt lists" , also
to his paypal.tgz , amazon.tgz and other washington mutual, ebayspams which are mostly html designs for scam websites.
(so much for the hacker psychology...)
Anyways - ive been seeing sks versions 1.1 / 1.3a and lately 1.3b on thoses hacked boxes - do yourself have seen any more sophisticated versions of sk (not speaking of adore/stealth of course.)?
by the way lately ive been online stringing kmem to check for sk tracks (strings /proc/kmem > kmem-strings), then reading kmem-strings for tracks of the string "./sk" for instance or whatever, but this method would be only efficient to detect the sk, not to remove it.. and well when a sk is on a server, luck is that many other things are there as well... better to backup the data and to reinstall the server.. (well any rooted servers mainly need this.)
I'm curious if you tried samhain's kernel checking to see if it detects the install of the rk. The samhain client will build an entry in its db based of the system.map and should detect any changes to the kernel.
Well actually from what i just read kern_check is a tool from samhain i think, and it detects the rootkit due to the system calls change.. i truely believe that for now it is able to detect sk after installation (for now, when system.map has not been altered), so however it must certainly detect it during installation still for now because i could notice that its checking "real time" with a default delay of 300 seconds by default, which gives in theory (even if its more luck than anything) 300 secs to an attacker to make its move against samhain. But lets be real on this, samhain looks to me as the best tool easy to install against that kind of syscalls change rootkits.
What would you do with the 300 seconds anyway? If you change system.map to match the new table, you cause a file integrity alert in samhain, if you disable samhain, you cause an alert. So you might change it but if someones watching they'll know( or at least get an e-mail from the yule server) I use samhain in client/server mode so the client just downloads(authenticated and encrypted) the database from a remote server, so the db cant be altered either.
ps. Samhain kicks ass.
however, samhain nicely used is a really powerfull tool - sk is indeed from what i read is installing its own private system.map file, which would trigger the file integrity alert. (just got to monitor wherever is your system.map file).