Systematic Analysis of Linux (Part I) (First Edition)
============================================================================================================================================================================================================= ====================
---- Original: Mariusz Burdach
Translation: Xi'an University of Posts and Telecommunications 0101 Xu Zhaoyuan ?? 02985384887
Translation Copyright: Xu Zhaoyuan Xi'an Posts and Telecommunications Academy 156 # flxyzsby @ 163.com / Flxyzsby @ Yahoo.com.cn
2004.8.15
Reprinted please notify
============================================================================================================================================================================================================= ====================
1. Introduction to the second part
In the first part of this article, we discussed some steps to analyze the preparations of non-secure systems. Now we will continue to analyze the system to find out the system is the malicious code, and then discuss from being transferred to the remote host Methods of searching in data.
?
Record:
Some readers pointed out after reading the first part of this article: Before the transfer of any data from the non-safety system, the shell should be run. I think this is a good idea, so let's compile the Bash Shell and then put it. Copy to us on the storage device. The 2A step is replaced by:
(compromised) # / mnt / cdrom / bash
?
We must pay attention to what the command interpreter will write them to a history record file when any command is healthy. But we don't want to turn it off to the files that modify the local system.
2.3 Data Collection for a Live System - Continued
?
Step 6: Physical memory mirror
• One step of data collection is to get a copy of the entire system memory. We can get the physical memory directly by copying / dev / MEM devices or copying Kcore files. Kcore files are used in the Linux system to record the contents of the RAM.. It is a virtual file that is stored in the / procalog. The size of the entire file is the same, the size of the physical memory is the same, expands about 4KB. The advantage of using the KCORE file is that it is an ELF format, so you can use GDB to debug The GDB toolset is a great tool for tracking and analyzing small module code or memory. In Section 2.7, I will show you how to use these tools in the analysis. But as the basic analysis I will use more common Tools such as GREP, STRING editors,, HEX (Hexadecimal) editor.
?
In addition, in order to better analyze the entire physical memory. We must understand some knowledge about the memory of the operating system ------- Data structure of the virtual address table relative to the physical address. We must know that the physical memory contains Virtual memory page. In the page table (block table) we can find the index of the page written to the physical memory (4KB per page in the Intel processor).
?
As mentioned earlier, we naturally change the content of memory when using the software tool to obtain the content of volatile memory. More seriously, we will rewrite may have invasive evidence. The following example I use / PROC virtual file system to get memory mirror
?
(transote) #nc -l -p port> kcore_compromised
(Compromised) # / mnt / cdrom / DD
(transote) # md5sum kcore_compromised> kcore_compromised.md5
In fact, when copying the entire system memory, we have copied the memory that has been assigned and copied, because we only copied this physical memory mirror. In the ninth step we will try to use / proc The virtual file system goes to copy the memory used by the exact process. I must explain that when we use / proc, we will change the content in the SWAP exchange partition. In order to copy those suspicious processes, we will force some pages that we will force the main memory. For SWAP swap partitions are readable, other pages are writable. Another important aspect is that we only copy the memory space that has been assigned by the process.
?
Step 7: Module lists that are loaded into the operating system memory
?
We must ensure that the data collected is complete, and the results of NetStat and LSOF commands cannot be modified on the kernel level. So we must detect those modules to be loaded into memory.
?
(transote) # nc -l -p port> LKMS_COMPMISED
(Compromised) # / mnt / cdrom / cat / proc / modules | / mnt / cdrom / nc (remote) Port
(transote) # nc -l -p port> LKMS_COMPROMIT.MD5
(Compromised) # / mnt / cdrom / md5sum / proc / modules | / MNT / CDROM / NC (REMOTE) Port
?
Unfortunately, some malicious processes will not be listed at all (the translator's note: the malicious process itself has a protection mechanism). In order to detect the information of the module loaded from / proc / modules, I will use the recent Phrack Magazine article " Finding Hidden Kernel Modules (The Extrem Way) "Method. Detection Module Hunter.O Check a series of modules loaded into the kernel.
?
(compromised) # / mnt / cdrom / insmod -f /mnt/cdrom/hunter.o
?
I used the -f parameter, which indicates that the hunter.o module is mating because the version does not match. The version does not match is the system kernel on the compile of Hunter.O, which is caused to avoid this situation. A good way is to recompile the code on each system you use. If you know the kernel version of the non-secure system you operate, you can download the source code and love the corresponding header file from www.kernel.org to recompile and Connects to generate Hunter.o that matches your system version.
?
(transote) #nc -l -p port> modules_hunter_compromised
(compromised) # / mnt / cdrom / cat / proc / showmodules && / mnt / cdrom / DMESG | / MNT / CDROM / NC (Remote) Port
(remote) # md5sum modules_hunter_compromised> Modules_hunter_compromised.md5
?
We can now compare the results. You must also pay attention to the size of the module, sometimes some malicious code will insert a legal file. (Translator Note: This will change the size of the file)
?
The last thing is the symbolic data of our copy of the kernel module. Sometimes the fragile LKM-based rootkit will output its own symbolic data. We can detect if there is an intruder in the system by analyzing the Ksyms file system.
?
(transote) #nc -l -p port> ksyms_compromised
(Compromised) # / mnt / cdrom / cat / proc / ksyms | / mnt / cdrom / nc (remote) port (remote) # nc -l -p port> ksyms_compromiad.md5
(Compromised) # / mnt / cdrom / md5sum / proc / ksyms | / mnt / cdrom / nc (remote) Port
?
We can use other tools (such as kstat or kern_check) modules to detect malicious modules, but unfortunately all these tools use system.map file. This file is generated and edited by the system. If the administrator does not copy this file and not If you build a school inspection and, we should not trust the address called where the system is stored there. Even if the address called by the system is correct, the intruder can use the usual trick to hide the malicious module in kernel memory. As this situation An example, the Adore-NG tool can replace the resident memory manager that has existed the list of system directories.
?
If we can ensure that the system call address in System.Map and Ksyms files will not be modified and confirm that the call address in the system call address table is not changed by the intruder. For details, please see Section 2.7.
?
Eight step eight: Active process list
All processes, open ports and files information can be collected by LSOF tools. Of course, where the requirements do not have any LKM-based tools in memory. In the next step we will copy suspicious process. By copying specific We can easily distinguish malicious data from the system's memory. You should be able to recall, we have collected all memory data in the sixth step (Kcore or / dev / MEM)
?
(transote) #nc -l -p port> LSOF_COMPMISED
(Compromised) # / mnt / cdrom / lsof -n -p -l | / mnt / cdrom / nc (remote) Port
(transote) # md5sum lsof_compromised> LSOF_COMPROMITED.MD5
?
Now let's analyze the results from the LSOF tool. If you find any activity process is suspicious, then it is a good time to copy them. If we find that the LSOF tool is detected when it is initialized, At this time, we see that the results are obviously inaccurate. Even so we still have the opportunity to recover results. I will show you anything in the next step.
?
I list a few suspicious processes as an example:
○ Procedure is being listening to the original Socket for TCP / UDP ports or open
○ One process with an active connection with a remote host
○ One is running again in the deleted procedure
○ One file is turned on by a process (for example: a log file)
○ A very strange process name
○ One process is initialized by a non-existent user, or is initialized by a user without permission.
?
Step Ninth: Current connection to the process
?
I use the PCAT tool to copy the entire memory allocated by the process.
?
(transote) #nc -l -p port> proc_id_compromised
(compromised) # / mnt / cdrom / pcat proc_id | / mnt / cdrom / nc (remote) port
(transote) # md5 proc_ip_compromised> proc_ip_compromised.md5
?
In fact, I can copy a specific data for the process. For more information, please see the next section.
Step 10: Useful information for non-safety systems
The next step is to collect useful information for a large number of non-safety systems.
This information requires an appropriate description and prepares a copy of a system file. Note that all results must be sent to the remote host. In Table 2 I have already listed all commands that must be run in the non-secure system.
?
Table 3: useful information about the compromised host
Command
Description
/ MNT / CDROM / CAT / PROC / VERSION
Version of the operation system
/ MNT / CDROM / CAT / Proc / Sys / KERNEL / NAME
Host Name
/ mnt / cdrom / cat / proc / sys / kernel / domainamedomain name
/ MNT / CDROM / CAT / Proc / CPUInfo
Information About Hardware, INFORMATION
/ MNT / CDROM / CAT / Proc / SWAPS
All swap partitions
MNT / CDROM / CAT / PROC / Partitions
All Local File Systems
/ MNT / CDROM / CAT / Proc / Self / Mounts
Mounted File Systems
MNT / CDROM / CAT / PROC / UPTIME
Uptime
?
?
Step 11: Current time
?
The final step is about the collection of current time information.
?
(transote) #nc -l -p port> end_time
(compromised) # / mnt / cdrom / date | / mnt / cdrom / nc (remote) port
?
Now we have to turn off the system's non-secure system. Please note that do not use any shutdown or init command to turn off the system. To take a directly unplugable cable or UPS power supply to force up.
?
2.4 file system mirror
?
We should establish a copy of the entire file system to copy nuclear exchange partition before shutting down the non-safety system. I suggest that it is done after shutting down the system. So we can ensure that the memory of the non-safety system is not It is modified. What needs to be mentioned is that the contents of the exchange partition will still be modified or rewritten when our acquisition process is performed.
?
The next step is to simultaneously act on the system and run the operating system from it. We can use Linux's default settings without loading a local file system. Now we can copy the entire local partition or the entire hard drive from this point.
?
2.5 Basic Data Analysis
?
Let us now think about the process in the eighth step, where we use the LSOF tool. Let's analyze and consider two examples on this situation.
Example 1: A process of deleted procedures opened up
?
In this case, the Linux file that has been initialized the process is still allocated in memory. To recover the file we must know the ID of the process established by the program. This executable can be found in the / proc / directory. This It is a copy of the file that is deleted. We send it to the remote host.
?
When we recover files we can get some information. There are two operations optional: disassembly, static analysis, or dynamic analysis of this unknown file in controllable environments.
?
Example 2. The file opened by the active process is deleted (such as a log file)
?
The parties returned by LSOF are as follows:
?
SMBD ???? 3137? root? RTD ??? DIR ???? 8, 1 ???? 4096 ???????? 2 /
SMBD ???? 3137? root? txt ??? REG ???? 8, 1 ?? 672527 ??? 92030? / usr / bin / smBD -D
SMBD ???? 3137? root? MEM? REG ???? 8, 1 ?? 485171 ??? 44656? /LIB/ld-2.2.4.so
...
SMBD ??? 3137? root ?? 16u? IPv4 ????? 976 ???????????????? TCP *: https (listen)
SMBD ??? 3137? root ?? 17u? IPv4 ????? 977 ????????????????? TCP *: http (listen)
...
SMBD ?? 3137? root? 20w rag ?? ???? 8, 1 ?? 253 ????? 46934 / var / log / httpd / access_log (deleted)
...
?
To restore this file, you need to list the contents of soft-driven traders (file descriptors) from / proc / 3137 directory.
(remote) # nc -l -p port> LS_FROM_PROC_3137
(Compromised) # / mnt / cdrom / ls -la / proc / 3137 / fd / | / mnt / cdrom / nc (remote) Port
(transote) # more ls_from_proc_3137?
L-WX ------ 1 Root root 64 AUG 10 21:03 12 -> / var / log / httpd / access_log (deleted)
...
We can see that the first file descriptor is deleted. We must do this is to transfer this file with the NETCAT tool to the remote host.
?
(transote) # nc -l -p port> deleted_access_log
(Compromised) # / mnt / cdrom / cat / proc / 3137 / fd / 1 | / mnt / cdrom / nc (remote) Port
?
This is not the only way to restore this file. We can also find unallocated nodes and data blocks when offline analysis.
?
2.6 keyword lookup
In the first part of this article, I show you a method for analyzing process and memory mirroring. Remember, the entire process is done on the remote host, and the memory mirror is completed. The biggest benefit of the whole method is me We don't have to know the use of low-level languages.
?
I will find the signal of the invader with the following simple tools.
● Strings
● Less
● GREP
I will use string tools to collect all printed characters in the mirror file. The default settings for tools allow us to display all of the printed characters. There are at least four characters. We use -t parameters to start from the beginning of the file statistics.
?
$ Strings -t D Kcore> Kcore_Strings
$ MD5SUM KCORE_STRINGS> KCORE_STRINGS.MD5
?
The operation of the GREP tools and rules is important in the initial analysis. We can find the obvious traces of invaders after a few minutes. Must think about what type of data we have to find -, for example, if you are looking for intruders Ordered, IP address, password, or even obvious malicious code of the fashionable code?
?
There are some examples of keywords to find. We use these keywords to find out the obvious traces of intruders in the Kocre_String file.
?
● Host Name or Prefix of The Comipped SYSTEM
$ grep "root @ manhunt" kcore_strings
$ GREP "] #" kcore_strings
?
11921096 [root @ manhunt] #
16643784 [root @ manhunt root] #
30692969] #] #
?
The above result is the offset of some strings we list. The next step is to open the file with the text editor and jump to a place close to the direct offset address. If you are lucky, we can find the previously used commands. But we also It must be aware that the pages and exchange partitions of the virtual memory in physical memory are written, so our conclusion may be completely incorrect.
?
$ less kcore_strings
/ 11921096
?
11921096 [root @ manhunt] #
11921192 / usr / bin / perl
11921288 Perl apache_mod_exploit.pl
...
?
The above example shows some commands for non-secure systems that have been typed.
?
● File and directory name
$ GREP -E "// proc //" -e "// bin //" -e "//bin//.*SH" kcore_strings
$ GREP -E "ftp" -e "root" kcore_strings
$ GREP -E "RM -" KCORE_STRINGS
$ grep -e ".tgz" kcore_strings
?
● IP address and domain name
?
$ GREP -E "[0-9] / /. [0-9] / /. [0-9] / /. [0-9] / " kcore_strings
$ grep -e "/.pl" kcore_strings
?
2.7 Advanced Qualitative Analysis
?
In the last section I show how to analyze the copy of the KCORE file with GDB tools. Start me to describe how to detect whether the address value in the system call table is appropriate. Change the system call address is installed in the system installed LKM The easiest way to tools. The next example I will show you how to list all the processes that have been running in non-safe. This example can be compared with the results obtained in the eighth steps and ninth.
?
In order to analyze, we must do the following requirements ::
● Memory image recorded in ELF format
● A copy of a kernel mirror (we must mount the sight of the non-secure system and copy a VMLinux file from the / boot directory
● Output list (system.map file in / boot directory or we can use Ksyms file --- See Section 7)
● Source code for the system used
?
The next step is to run the GDB tool:
#gdb vmlinux kcore
GNU GDB Red Hat Linux (5.1.90CVS-5)
CopyRight 2002 Free Software Foundation, Inc.
GDB IS Free Software, Covered by the gnu general public license, and you are
Welcome to change IT and / or or distribute copies of it under certain conditions.
Type "Show Copying" to see the conditions.
There Is Absolutely No Warranty for GDB. Type "Show Warranty" for Details.
THIS GDB WAS Configured AS "i386-redhat-linux" ...
?
Warning: Core File May Not Match Specified Executable File.
Core Was generated by `ro root = / dev / sda2 hdc = IDE-scsi '.
# 0 0x00000000 in ?? ()
(GDB)
?
Now we start to analyze.
Example 1: System call address verification
?
The first step is to identify the call address value of the system call table. Almost all Linux operating systems output this information, can find this in Symbol.map.
?
# cat symbol.map | grep sys_call_table
C02C209C D SYS_CALL_TABLE
Now, we can list all the entrance addresses of the address call table. Each entry address is the address of the system call.
In order to get the correct entry address parameter We have to check the entry.s file in the internal nuclear source code. This file records the order of the system call.
Entry (SYS_CALL_TABLE)
???? .long symbol_name (sys_ni_syscall) / * 0 - OLD "setup ()" System call * /
???? .long symbol_name (sys_exit)
???? .long symbol_name (sys_fork)
???? .long symbol_name (sys_read)
???? .long symbol_name (sys_write)
???? .long symbol_name (sys_open) / * 5 * /
???? .long symbol_name (sys_close)
???? ...
?
There is also the same order in sys_call_table. The following is listed below the 10-start system call address value:
?
(GDB) x / 10x 0xc02c209c
0xc02c209c
: 0xc01217c0 0xc011ac50 0xc0107510 0xc0138D50
0xc02c20ac
: 0xc0138E50 0XC0138880 0XC01389B0 0XC011B010
0xc02c20bc: 0xc0138930 0xc01445c0
?
0xc01217c0 is the SYS_NI_CALL system call address, 0xc011ac50 is the SYS_EXIT address call address.
?
If you trust the address from the SyeTem.map file or the Ksyms file, then we can compare all the value values. Of course, invaders do not change all system viewing address values. For example, Sys_READ, SYS_GETDENTS, SYS_WRITE These normal processes.
?
Example 2. Active process list
?
In order to get a list of the entire running process we must find the init_task_union structure. This structure indicates the descriptor of the first process, which is called "process 0" or "swapper".
?
# cat symbol.map | GREP INIT_TASK_UNION
C02DA000 D Init_Task_Union
?
The next step is how to find the entire structure. In fact, init_task struct can be found in the SCHED.H header file in the source code, and the Task_Struct This structure can also be found in this header file.
?
#define init_task (tsk) ?????????????????????????
{??????????????????????????????????
??? state: ?????? 0, ???????????????
??? Flags: ????? 0, ????????????????????????????????????
??? Sigpending: 0, ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
??? addr_limit: kernel_ds, ???????????????????
??? EXEC_DOMAIN: ??? & default_exec_domain, ?????
...
??? run_list: ?? list_head_init (tsk.run_list),?
??? Time_Slice: Hz, ?????????????
??? next_task :? & tsk, ??????????????
??? prev_task :? & tsk, ???? ????????????????????
??? p_opptr: ?? & tsk, ?????????????????????????????????
...
The important part of our process descriptor is prev_task and next_task .. They can help us build a list of processes. Next_Task points to the descriptor of the next process of the process, prev_task points to the descriptor of the last process being inserted.
?
Here, I lists the pieces of the process descriptor, which is found at the address: 0xc514C000 is found.
?
(GDB) X / 180X 0xC514C000
...
0xC514C040: ???? 0x00000000 0xfffffffff ???? 0x00000004 ????? 0xc1be0000
0xc514c050: ???? 0xc4dac000 0xc5ea8e40 ???? 0xc5ea8e40 ????? 0xc02c56d4
...
0xc514c070: ???? 0x00000001 0x00001Ace ???? 0x00001Ace ????? 0x00000000
...
0xc514c230: ???? 0xffffffffff 0xfffffffff ???? 0x61620000 ????? 0x00006873
0xc514c240: ???? 0x00007974 0x00000000 ???? 0x00000000 ????? 0x00000000
...
Description:
0xC1BE0000 is the next_task
0xc4dac000 is the prev_task
0x00001Ace Is The Process Pid = 6268 in Decimal Format0x61620000 and 0x00006873 Is The Name of Process (THE COMM TABLE IN THE STRUCT) = "Bash" in this part particular example
?
Print out the next descriptor we do this:
(GDB) X / 180X 0xC1BE0000
?
Information from each process descriptor We can build a list of all active processes.
?
3. Summary
?
The purpose of this article is to introduce some methods of data collection, basic, and advanced analysis. Special, I will focus on the loss of data after we will force the system. This part is difficult to complete, we must complete each The steps are very careful and to ensure a record (document) for each detail. We can also see the benefits and drawbacks of the software collection process. In the end, I introduced you how to collect operations in the Linux system, in fact you can completely These steps are ported to other operating systems. There will be an article that guides you how to collect intrusion data in a Windows operating system.
?
reference:
Adore-ng rootkit, http://stealth.7350.org/rootkits/
Alessandro Rubini, Jonathan Corbet. Linux Device Drivers, 2nd Edition. O'Reilly; 2001.
Dan Farmer, Wietse Venema. Column Series for The Doctor Dobb's Journal. Http://www.porcupine.org/forensics/column.html.
Daniel P. Bovet, Marco Cesati. Understanding The Linux Kernel, 2nd Edition. O'Reilly; 2002.
Kernel Source Code. Http://www.kernel.org/
Linux MANUAL PAGES.
National Institute of Standards and technology. Computer security incident handling guide. Http://csrc.nist.gov/.
Phrack # 61. Finding Hidden Kernel Modules (The Extrem Way) By Madsys. Http://csrc.nist.gov/.
RFC 3227. Guidelines for evidence Collection and archiving.
SMITH FRED, BACE REBECCA. A Guide to Forensic Testimony. Addison Wesley; 2003.
Symantec Corporation. CodeRed Worm. Http://securityResponse.symantec.com/.
The Honeynet Project. Scan 29. http://www.honeynet.org/
The Sans Institute. Incident Handling Step by Step. Http://www.sans.org/
About the Author
View more articles by Mariusz Burdach on SecurityFocus.
Credits
Thanks to Kelly Martin and Dan Hanson for their suggestions, Careful Reviewing and Help.
?
?
