Baidu Security Attack and Defense Lab. 2015/06/19 17:06

I haven’t written for a long time. BSRC is writing something to ease the pressure of the request and the start of the personal ridicule mode.

Chkrookit and RkHunter have largely become standard for emergency response on Unix-like systems. For most security incidents, the first step on the machine is basically a two-shot. But many end up disappointed, or come to a conclusion and don’t know what to do. This article may solve some of your confusion. This article is mainly about CHkRootkit, RkHunter will ridicule later when he is free.

First of all, we should have a clear understanding of tools. Tools are dead, man is alive, attack and defense itself is the confrontation between man and man. When the challenge is to live people rather than pre-defined programs, relying mechanically on a tool to actually go to war is doomed to tragedy. For the tools used in the actual confrontation, when to use them, what problems to solve, and what to expect from them. We should know, even how much we can trust its conclusions and what the costs of cheating or bypassing it are.

Get to the point, this article we first talk chkrootkit: http://www.chkrootkit.org. From README we know that the last update is 04/30/2014 and the last update was 2009… Looking at CHANGELOG, you can probably understand what functions it has, which is well reflected in the name of the code directory:

The chkRootKit itself is a shell script. Run chkRootKit -L to see all check sets. Note that the chkRootkit script is highlighted in red. In general, such open source scripts call security checkers that work in an external command-style fashion, at a pace that experience has doomed to tragedy. Moreover, it is easy to be backfired by executing this kind of detection program without looking at the operating environment on the machine

Open the chkRootKit and we start with two shells like this

#! Bash PTH = ` echo $PATH | sed -e "s /, / / g" ` PTH = "$PTH/sbin/usr/sbin/lib/usr/lib/usr/libexec."Copy the code

Tut, tut, tut, tut, tut, tut, tut, tut

Generally speaking, what is the detection process like?

  1. Default detection of legacy rootkit/ Backdoor/worm; Find files by location, particular filename, character, etc., and see if there is a specific backdoor based on the bound port number (please…). . But these search features are written in the script chkRootKit naked, how much is the cost of bypassing this kind of check, expect in the actual confrontation, what can be found, we do not expect too high.
  2. In the checking phase, there are a few interesting check points, but most of them are implemented by the external bin. But let’s not forget that these bin environments can be malicious.

The redirect from a simple open file can bypass a lot of traffic. If you’re interested, go to Phrack 1997 for a look at idea 3. Relying on ring3 open source program to check ring0 level unknown backdoor itself has a problem, here note is open source ah, then use ring0 to bypass is pure bullying ah :). (Of course, there are possibilities for poorly implemented rootkits that can only be called beta versions, such as file reference counts that differ, CD and readdir calls that don’t work well together, and so on. But you open source ah ~ TSK TSK.

I’d rather limit the implementation of backdoors under Ring3.

Ldd to look at

In Linux, make with no arguments produces a bunch of bin files that use dynamic connections. Ld.so.preload can be KO. Determine the open file read and write object, insert a normal to him. Let’s see if we can find a more interesting way around it. Analyze the detection principle one by one:

1 chkproc program

A) Chkproc completes the detection of ps command hiding and readdir function hiding.

B) Detection logic: Compare the output of ps and readdir and the result of trying to chdir to each directory /proc by traversing MAX_PROCESSES (99999) to find and report the difference (only 99999 ah, tut), It is possible to pull the PID up , but this checking will result in an OooPS error being reported

C) Reading /proc from the /proc directory after the ps output is complete will cause a large error in the time window

D) Invalid for backdoor checks using ptrace or other methods to inject Shellcode or SO into other processes

E) Processes that are not hidden are invalid

2 Chkdirs program:

A) Accept the directories to be checked, recursively check, and find exceptions by comparing the link count of the parent folder with the child folder count. Normally the link count for the parent directory should be the number of all children +2

/ TMP /usr/share /usr/bin /usr/sbin /lib /usr/bin /usr/sbin /lib/TMP /usr/share /usr/bin /usr/sbin /lib

C) Files that are not hidden are invalid

3 Chklastlog, chkutmp CHKWTMP

A) Essentially these programs are cross-referencing files such as UTMP WTMP, and some tools check for special fields such as whether time is 0. This kind of check tool check ideas are more from the outside world widely circulated log erasing tool understanding.

B) the program implementation has a hard-coded skip account in it, you can directly change the generated log body to it can bypass the check

C) Do not easily clear the fields of the log completely, even to some extent, you can copy one from other entries

4 ifpromisc program

A) Enumerate the programs of interfaces in promiscuous mode and PF_PACKET link layer sockets on the system to find sniffers

B) So hijack is recommended for hiding

By now, you should probably have a feel for the positioning and functionality of the ChkRootKit:

  • First, basic, low-level intrusions, such as UID =0, permission exceptions, file substitutions and additions and deletions on file systems, are up to you. Even the currently listed process ports, you still have to look at them yourself. The Chkrootkit is at best an aid, or an aid to an aid.
  • There is no way to detect it without the crontab (first call), so if you just hit the crontab back door, it won’t even squeak at all. It doesn’t pick up things that are slightly more complicated, like so injection and backdoors. The Chkrootkit can only help you do a limited set of intrusion signature checks, and the checks are empirical, based on guesses about the attacker’s urine.
  • Because it is open source, the logic of detection is easy to circumvent, and there are many ways to do it. The attacker changes position and goes blind, almost certainly undetectable by a custom rootkit.
  • Chkrootkit backdoor /rootkit detection and anti-rootkit work is very simple. Don’t expect to find anything big.

Clear the working principle and limitations of a security detection tool, open the check point, in a “general” operating system against, attackers with mental calculation and unintentional always can gain. There are so many holes or features in a general-purpose system, such as boot locations, that a malicious program can take advantage of a list of places it has never heard of before.

If such targeted tools, developed by studying the urine of attackers, are needed for emergency response, it is best to be honest and private.

Pay more attention to CVE, ha ha, your check running procedures, do not become a local way to raise rights. Maybe someone will make a big noise waiting for you to chkrootkit!

Finally, to end with a quip, the most important goals of emergency response are all too easy to lose sight of in practice. Find out how you got in, what you did, what damage you did. We’re not playing hide and seek with our assailants, you hide and I’ll find. When we’re done, we can do it again, not clean out the back door. It could be a small detail you didn’t notice or a feature you didn’t know about. Focus on the goal, do not forget the original purpose.

References:

(1]https://www.exploit-db.com/exploits/33899/

(2) https://github.com/ossec/ossec-hids/releases/tag/2.8.2

(3]http://www.phrack.org/issues/51/9.html#article