Brief Introduction to ROOTKIT search in LINUX

 

Thanks to Liu shipping in practice

 

First, I would like to introduce this one-year-old hacker, who is expected to become a non-mainstream brain hacker after the 90 s.

 

I have waited for four months for article 9, which is of the quality .. Promise not to despise him .. We can never find the poor cool-Performance of MM...

 

 

 

Recently I have followed the rootkit in linux. in linux, rk is divided into application layer and kernel layer. er, I simply read rkhunter. application Layer checks are usually some sshd backdoors. bind shell and reverse shell. this kind of things is better checked. first, make sure that the environment of the checked machine is clean. run rpm-qV or md5sum to check whether netstat, ps, and lsof are modified. finally, I used busybox to compile a static tool kit to check the tool. then we can check the situation.

Port: checking the port is the easiest way to identify the problem, and finally compare nmap-p1-65535 localhost with netstat-anp. I find that netstat does not exist and nmap has a port, so I am sure there is a problem. you can directly telnet or nc to check it out. the popular ddrk, shv5 and sshd backdoors in China will be invisible. they all need bind ports to wait for the connection. if there is a problem with netstat, replace it with a clean one and continue. next, let's look at the reverse shell.

Through netstat-antp, you can see that the port is related to a process. for the port, we can use lsof-I: [port] To look at the port details .. we can find some files on the 2b page. then lsof-p [pid] checks the files used by the process. let's take a look at the detailed content in the strings file.

 

After the general check is complete, we can use some 2b points to check .. when you read the rk feature of the application layer of rkhunter. we will find that those rk are stored in some very 2b directories.

 

Find/-name "... "find/-name" "find/-name ".. "find/-name ".. "find/-name ". bashrc "// check if in other dirs

 

Don't explain. Then you can manually check sensitive directories.

 

/Lib /. */usr/lib /. */bin /. log/usr/lib /. lib/usr/bin /. system/dev /. */dev/proc /. *

 

By default, the directories hidden by "." are suspicious.

Then, rkhunter checks whether sensitive files such as/bin/sbin/usr/bin/usr/sbin are replaced by sh files in common directories. so in many cases, false positives/sbin/ifup and ifdown will occur. :) it seems that modern rk does not use this method anymore :(

 

There is also a sshd backdoor that once or now seems very popular. this backdoor replaces our favorite sshd and then logs in with a universal password. this method is actually quite good. however, anyone who has done this kind of backdoor knows that this kind of backdoor compares the password entered by the user with a string before the user checks passwd upon login (sb points will use the plaintext password, it's wise to use des for encryption .). in addition, some bad people will also consider using it to steal passwords entered by others (the common practice is to open a file and write the password again). Based on these two points, we can first use strings 'which sshd' to analyze the sshd. Generally, some sensitive strings prove an accident. of course, rpm-V can also be checked, and md5dum. in addition, strace 'which sshd' 2> & 1 | grep open can easily identify problems by looking at system calls.

 

In fact, there are also udp door, icmp door, irc bot... but it is rare in reality. Well, if you are interested, you can contact me ..

 

In the deep layer, it is kernel-level rk.

Deep-layer rk is rarely seen, but kernel-level rk is lethal. the existence of such rk makes the previous application-level checks almost futile. the best solution to this rk is reinstallation. because of technical problems. dishes like me have seen several types of adore and knark. others are basically not compiled. (there is no reason for kernel head and so on. I don't know much about it either. Please kindly advise ). I just pulled down the lkm technology I know, And rkhunter checked lkm very easily. It was actually a direct comparison between the modules in lsmod output and/proc/modules files. it seems that adore can bypass this check. A better check seems to be able to use kstat. generally, lkm rk hides itself by reading and modifying syscall, hiding ports, and reusing ports. with kstat, we can check whether the syscall of the kernel has been modified. well, now the best way seems to be this.

 

Ps: http://www.reddit.com/r/linux/comments/9zqm5/what_is_the_most_advanced_rootkit_for_linunix/

 

From root @ Dis9Team:/share # ls-la