File-system Intrusion Detection by preserving MAC DTS: A Loadable Kernel Module based approach for LINUX Kernel 2.6.x

Transcription

1 File-system Intrusion Detection by preserving MAC DTS: A Loadable Kernel Module based approach for LINUX Kernel 2.6.x Suvrojit Das suvrojit.das@gmail.com Arijit Chattopadhayay arijitnit06@gmail.com Monojit Saha meetmanojit@gmail.com Dipesh Kumar Kalyani dipesh.thepace@gmail.com ABSTRACT Every operating system has its own set of critical files, whose access is generally protected by access control mechanisms, native to the operating system. The importance of such files also simultaneously invites their inspection, unauthorized modification and tampering. So, the need for preserving the authenticity of these critical files along with tracking any unauthorized access to them demands paramount importance. This addresses the need of a good file-system intrusion detection system which is capable of monitoring and tracking any accidental, benign, malicious, intentional changes made to the files that reside in the file-system. For any file the MAC DTS, i.e. the modification, access and creation date and timestamp is a major parameter which can be helpful in detecting any unauthorized access to the documents and monitoring file system intrusion in a broader perspective. So by preserving the MAC DTS we can gain crucial evidence about unauthorized access in the file system. This paper proposes one solution to preserve the MAC DTS for the LINUX operating system (kernel version 2.6.x) with pre-installed plug-ins in the form of Loadable Kernel Modules (LKM). Keywords Intrusion Detection System (IDS); File system; Modification, Access and Creation date and time stamps (MAC DTS); Authentic Date and Time Stamps (ADTS); Virtual File System (VFS) Layer; Loadable Kernel Modules (LKM) Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. CSIIRW '09, April 13-15, Oak Ridge, Tennessee, USA Copyright 2009 ACM $ INTRODUCTION There are many levels of access protection in the Linux file system, still illegal intrusion into the system is a very common phenomenon. Intruders find their way to enter into the file system, investigate the nature of the file system in order to learn where the vulnerable points are and where the most damage can be caused with the least effort, and then cause serious damage to the system. So providing and maintaining the security in a file system is a challenging issue. An Intrusion Detection System (IDS) are the combination of tools that the security administrator uses to detect an intrusion. To stop the illegal intrusion in a system, it is absolutely necessary to detect them first. The illegal intrusion in a system s file system can be detected by presence of a new unfamiliar file in the system, changes in file permissions, changes in the MAC DTS, missing files. The MAC DTS entities reveal the fundamental information regarding the time of creation of the file and its subsequent modification and access, which provides a crucial role in reconstruction of sequence of events in the file system type operations, in a strict time line. As file systems overwrite the changes in MAC DTS, we cannot get back the original MAC details, as the retrieval of overwritten data is very difficult and expensive. Also, all currently available date and time stamp procedures simply acquire available date and time stamps of the system at that particular instance, which are easy to change. It may so happen that intruders can even tamper with the MAC DTS of the critical files with an objective to remain untraced of their activities and even to deny forensic evidence of their mischief [1]. Hence what we want is the capability in file system itself to assist in preserving original MAC DTS to help in file system intrusion detection. This paper proposes one solution to preserve the MAC DTS of system wide critical files for the LINUX kernel version 2.6.x, by logging the MAC DTS of critical files in a LOG file at the VFS layer itself, so that every unauthorized access can be logged as evidence and as a framework for taking future actions.

2 Fig 1: Virtual File System Architecture 2. RELATED WORK A solution based on ext2 file system for Linux kernel version 2.4, using pre-installed plug-ins in form of Loadable Kernel Modules (LKM) to preserve MAC DTS information, is found in [1]. Though the authors have highlighted the forensic aspects, their idea can be used with further refinements made in this paper, for the purpose of file system intrusion detection. Also, [1] refers to use of data structures specific for the ext2 file system which has its own disadvantages, detailed in section 5. This paper takes care of this type of problems also by not using file system specific data structures. 3. BACKGROUND Linux distinguish between processes running within the kernel (running in kernel mode) and processes started by users (running in user mode) including the special user root. Functions inside the kernel can only be accessed by the use of system calls which provide a well defined and static interface. Even the user root cannot run arbitrary code in kernel mode. Though, Linux is able to load kernel modules at run time. Special system calls are used to bring the code of the module into the kernel. One of Linux's keys to success is its ability to co-exist comfortably with other systems. To support this feature Linux uses a concept called the Virtual File System (VFS) which is a layer of abstraction between the system call interface and the actual implementation of different file systems [Fig. 1]. The key idea behind VFS consists of introducing a common file model capable of representing all supported file systems. For instance in this model each directory is regarded as a file, which contains a list of files and other directories. However several non- UNIX disk based file systems use a file allocation table (FAT) which stores the position of each file in the directory tree. These file-systems do not treat directories as files. To satisfy VFS's common file model the Linux implementations of such FAT based file systems need to construct on the fly the files corresponding to the directories and such files exist only as objects in kernel memory. Actually the Linux kernel does not hard code a particular function to handle an operation such as read() or ioctl(). Instead it uses a pointer for each operation and the pointer is made to point to the proper function for the particular file system being accessed. Fig 2: Interaction Of different objects in a VFS implementation For example, if we want to read a file in an MS-DOS file system, the kernel converts the read() system call into a call specific to the MS-DOS file-system. The application's call to read() makes the kernel invoke the corresponding sys_read() service routine, like every other system call. The file is represented by a file data structure in the kernel memory. The data structure contains a filed called f_op that contains pointers to functions specific to MS- DOS files, including a function that reads a file sys_read() finds the pointer to this function and invokes it. Thus, the application's read() is turned into the rather indirect call: file->f_op->read(...); The common file model consists of the following object types (data structures) [Fig 2]: 1. super block objects: stores information concerning a mounted file system. For disk based file systems this object usually corresponds to a file system control block stored on disk. 2. inode objects: stores general information about a specific file. 3. file objects: stores information about the interaction between an open file and a process. This information exists only in kernel memory during the period when a process has the file open. 4. dentry object: stores information about the linking of a directory entry( i.e. a particular name of a file) with the corresponding file. Each disk based file system stores this

3 Fig 3: generic system call interface information in its own particular way on disk. The most recently used dentry objects are contained in a disk cache (which is a software mechanism that allows the kernel to keep in RAM some information that is normally stored on disk) named the dentry cache which speeds up the translation from a file path name to the inode of the last path name component.each specific file system has its own meta data on disk which includes the super block, the block group descriptors, etc. which can be found in literature. 4. DESIGN AND IMPLEMENTATION Our objective is to develop the kernel module in such a way that it redirects the flow of execution in the VFS layer itself, and so it is not limited to the use of different underlying file system specific data structures. Our implementation does not manipulate central resources like the interrupt descriptor table (IDT) or the system call table [Fig. 4] i.e. we provide a solution at the VFS layer and so it is not file system specific. In our design we are maintaining a LOG file that logs the MAC DTS of the files being accessed and changed in any underlying file system that is registered to the VFS and mounted. To achieve this we have kept in mind the following objectives: 1. Each time some of the specific system files have been accessed or changed, we will be tracking the MAC timestamps and log them in our LOG file, along with the effective user id of the calling process. 2. The LOG file is hidden in such a way that it is not accessible to a normal user. 3. The LOG file can be accessed only by the administrator (valid root user) whenever he wish to do so. 4. In case the system is compromised, i.e., the root password is exposed to the intruder, even then the intruder cannot gain access to the LOG file unless he knows the name of the LOG file; in fact it is the kernel module that writes to the LOG file which is otherwise hidden from the normal file system view. As long as the name of the file is unknown to the intruder, in spite of his gaining the super user privileges, he cannot access the file. 5. The mechanism does not slow down or affect the system performance. 6. The administrator (root) is privileged to consider and mark some system files or other documents as critical to the system and hence allowing it to be monitored for any unauthenticated access. Fig 4: Time line of execution of a system call from user space and trapping of system calls Whenever a file is being monitored, each invocation of sys_open() system call implicitly or explicitly over this file would generate a record of inode number, the EUID of the calling process, and MAC- DTS of that file, describing this access. To understand this fact let us first look at how a file is accessed. Each and every regular file is accessed via the sys_open() system call. When a user process wants to open a file for reading or writing it makes a call to the sys_open() system call either explicitly or implicitly [Fig 4]. By explicit calling we mean that it directly calls sys_open(). Implicit invocation of open is when the system call is invoked by some other program on behalf of the user. The sys_open () or more commonly known by its C wrapper function open() finds an unused file descriptor in the processes file descriptor table. The lowest numbered file descriptor is returned to the process. In our implementation we have modified the sys_open() system call with the help of LKMs. This also provides flexibility in our implementation as this logging mechanism can be inserted and removed at the will of the administrator. Now whenever a user calls sys_open() from any user program, it is being trapped and our own substitution for the sys_open() system call, my_open() is invoked, where we are examining the file which the user program tries to open and if it is among the critical files to be monitored then we keep a LOG of the MAC DTS of that file in our LOG file. After that we call the original sys_open() system call. The salient features of the implementation are: 1. Monitoring the critical files of any recent access or modification or change. 2. Logging in the MAC DTS, inode number of the critical file being accessed, along with and EUID of the caller. 3. Hiding the LOG file from normal file system view provided by the VFS. Our implementation is capable of hiding the file also from the root user as long as the module is loaded in the system, i.e., in case of a compromised system whose super user password is cracked, our implementation demands that the LOG file

4 remains inaccessible, as long as the intruder (who otherwise has the super user privileges) does not know the name of the LOG file. So the complexity of gaining access to the LOG file even in a compromised system is as hard as guessing a standard system password. So, we choose the name of the Log file in such a way that guessing its name is as hard as guessing a password. 4. Preventing access to the LOG file i.e. reading from or writing to it. 5. We have also trapped the unlink system call which prevents intentional or unintentional deletion of the file. 4.1 Details of design and implementation The sequence of steps followed to track access to the critical files by preserving MAC DTS and prevent its alteration is: 1. Trapping the system call by using the system call table address. 2. Writing the LOG into a file. 3. Hiding the LOG file from the file system, unless administrator unloads the module from the system. The entire procedure is implemented on kernel 2.6.x on ext2, ext3 file systems. It ensures that only root has the permission to mention the critical files Trapping System calls In order to trap the system calls in 2.6 Kernel we need to get the address of the system call table. In kernel 2.4.x it was exported by the kernel so this was available easily. In kernel 2.6.x, the system call table's address can be obtained either directly from System.map file or /proc/ kallsyms or by running a loop from two known checkpoints whose addresses are exported. The following steps are followed: a. Get the address of the system call to be replaced. b. Replace address of the system call with the address of the specified code to be run instead of it, so that when the system will call that specific system call then instead of that system call this particular code will run. c. From the modified code the original system call, call the original system call. During the removal we have to restore the address of the original system calls, so that in absence of the module the system will function properly Trapping the open system call Whenever anybody (whether it is the system or any user) tries to access a file, the open system call is implicitly or explicitly called by the system so we trap the open system call [Listing 4.1.1] and monitor some specific critical files (as defined by the administrator) and LOG its MAC DTS Writing to the Log file We have defined a function wrt_file() called from the my_open () function [Listing 4.1.2]. System call: my_open Input: file_path, flags, modes Output: file_descriptor { file_descriptor=get a file_descriptor by opening the file_path in desired mode. Inode=locate the VFS inode of the file; Check whether the file is to be monitored or not. if(to_be_monitored) { Write the inode to the LOG file. Write the modification time, access time, change time of the file. } return (file_descriptor); } Listing Modified sys_open system call Function: wrt_file Input: file_name, data Output: data written to the file { STEP 1. Retrieve the legal virtual address boundaries for that process(virtual Address Space represented by mm_segment_t). STEP 2. Store the address in old_add. STEP 3. Set the address limit to the kernel space (via set_fs(kernel_ds)).kernel_ds stores the address limit for the kernel. STEP 4. Set the wrt_flag as 1. STEP 5. Get file_descriptor by calling sys_open with the file_name and O_APPEND mode. STEP 6. Write the data into the file. STEP 7. Close the file_descriptor STEP 8. Set the address limit to old_add,i.e. to the user s virtual address space. } Listing Algorithm for my_write function Usage of the wrt_flag in the program The wrt_file() calls the open() system call to write into the LOG file. Then the control will move to my_open()which eventually calls the wrt_file(). Thus a loop will be created. For this purpose, we have introduced a variable wrt_flag, a static integer, which will take care of this problem. This variable

5 is set when wrt_file() calls the my_open(). The function my_open() first checks whether this is called from wrt_file() or not. If it is called by wrt_file() then my_open() will not execute the later part; rather it unsets the flag calls the original open system call code and returns. Since this wrt_flag is not a shared by any other process in the system, so even in the case of a context switch between the part of the code where flag is set & unset, it will not affect the system. It will avoid forming the loop and keeps the open() system call in the trapped state, such that if any other file is opened then the system will start trapping Hiding the LOG file After storing the information of the critical files in a LOG, it is mandatory to hide the LOG file from the normal file system view (includes hiding from the purview of the super user). When a file is viewed several dirent structures of a directory must be read irrespective of the local or network file opening procedures. For this purpose getdents64() or getdents() system call is needed. This can be explained with the example of viewing the files in a directory by using the ls command. This command calls getdents64() or getdents() system call. So we need to trap this system call, for hiding the LOG file Trapping the getdents64 system call The basics behind the algorithm of trapping this system call [Fig 5.2], is that whenever a command like ls is issued, it will: 1. Find out the current directory. 2. It will copy the linux_dirent64 structure into a variable declared by us. 3. The directory path is compared with the directory path where the LOG file is kept and if it matches then the getdents64() call is intercepted else the normal call is executed. 4. If the directory is the same, it ll search the entire directory whether the LOG file exists in that particular directory or not. 5. If the LOG file exists in that directory then it ll skip that entry of the LOG file such that although the LOG file exists in the system then also user cannot see the LOG file. Thus, we make the LOG file invisible to the user Avoiding the deletion of the LOG file This is done by trapping the unlink system call 1. It checks the absolute path of the file 2. Compares it with that of the LOG file 3. Prevents deletion if the file to be deleted is the LOG file. Similarly the module and its entry in /proc/modules can be hidden. 5. DISCUSSIONS The whole process is swift and doesn t compromise with the speed of task execution and at the same time maintains the log of MAC DTS of files of paramount importance and prevents this information from any unauthorized access. This LOG file can also serve as forensic digital evidence in computer crimes [1]. But for Fig 5.1 Original working of getdents_64 () Fig 5.2 Trapped version of getdents_64 () that, a standardization of the LOG file and issues like secure storage and unbiased creation of the LOG is necessary so that it becomes a valid digital forensic document acceptable by the Court of LAW. The proposed mechanism has been implemented and tested in both ext2 and ext3 file systems (although not modifying any specific data structures of either ext2 or ext3, rather controlling the whole operation from the VFS layer) with Linux kernel version 2.6.x. A mechanism of directly modifying data structures specific to the ext2 file system, on disk, directly allocating and using data blocks to record MAC- DTS, can be found in [1]. This process does not create inodes to refer to these data blocks. These data blocks are then marked allotted and used for the purpose of hidden storage (of the logged MAC trail information). But then they have to store

6 the addresses of the data blocks to be used for future reference. Rather, they have created and maintained a linked list of these data blocks and stores the address of the header of the linked list in a so far unused field called bg_reserved, of the ext2 block group descriptor. So, this is a case of introducing deliberate inconsistency between the file system metadata and the actual file system data which helps in hiding the data during normal or forceful file system checking operations like that done by e2fsck, which is required in case of any file system errors, detected by the system. When a file system consistency checking program such as e2fsck executes a consistency check on the file system status it refers to the super block and the group descriptors stored in block group[0] and then copies them into all other block groups [4]. Even, if data corruption occurs in the main super block or the main group descriptors in block group[0] become invalid, the system invokes e2fsck to refer to the old copies of the super block and the group descriptors stored in a block groups other than the first. In this process, it may so happen that the contents of fields of bg_reserved, used to save MAC trail log [1], are lost in such a process. Moreover, if certain blocks are marked as being used (1 in block bitmap table) even when no file uses them, (the approach given in [1]) e2fsck will identify and de-allocate the blocks. Since our solution aims at logging MAC DTS at the VFS layer itself, we overcome such problems that arise due to use of data structures specific to different file systems. So, if the very purpose of logging the MAC DTS of a set of critical files and hiding the LOG can be carried out in the VFS layer itself, and if the process of finding out the LOG information is as hard as guessing a password, we can avoid using file system specific data structures. 6. REFERENCES [1] Mridul Sankar Barik, Gaurav Gupta, Subhro Sinha, Alok Mishra, Chandan Mazumdar. An efficient technique for enhancing forensic capabilities of Ext2 file system. Digital Investigation 4S (2007) S55-S61. [2] Dr. Knut Eckstein, Forensics of Advanced Unix FS, 2004 IEE/USMA IA Workshop. [3] Swevson C, Philips, R Shevoi, S 2007 in IFP, Int Federation of Information Processing, Vol. 242, Advances in Digital Forensics III, eds. P Caiger K S Shevoi, ( Borton, Springer), P [4] Bovet Daniel P, Cesati Marco. Understanding the Linux kernel. 3rd ed. O Reilly & Associates. [5] Bach Maurice J. The design of the UNIX operating system. Prentice Hall of India; 1988.