Rootkit Ntoskrnl Executive Order
Author: Greg Hoglund - Phrack Magazine - Vol. 9 Issue 55 - 09.09.99 - 05 of 19 - A.REAL. NT Rootkit, patching the NT Kernel - Greg Hoglund Introduction - First of all, programs such as Back Orifice and Netbus are NOT rootkits. They are amateur versions of PC-Anywhere, SMS, or a slew of other commercial applications that do the same thing. If you want to remote control a workstation, you could just as easily purchase the incredibly powerful SMS system from Microsoft.
A remote-desktop/administration application is NOT a rootkit. What is a rootkit? A rootkit is a set of programs which.PATCH. and.TROJAN.
existing execution paths within the system. This process violates the.INTEGRITY. of the TRUSTED COMPUTING BASE (TCB). In other words, a rootkit is something which inserts backdoors into existing programs, and patches or breaks the existing security system. A rootkit may disable auditing when a certain user is logged on. A rootkit could allow anyone to log in if a certain 'backdoor' password is used.
A rootkit could patch the kernel itself, allowing anyone to run privileged code if they use a special filename. The possibilities are endless, but the point is that the 'rootkit' involves itself in pre-existing architecture, so that it goes un-noticed. A remote administration application such as PC Anywhere is exactly that, an application. A rootkit, on the other hand, patches the already existing paths within the target operating system. To illustrate this, I have included in this document a 4-byte patch to the NT kernel that removes ALL security restrictions from objects within the NT domain. If this patch were applied to a running PDC, the entire domain's integrity would be violated. If this patch goes unnoticed for weeks or even months, it would be next to impossible to determine the damage.
List And Full Text
Network based security & the Windows NT Trust Domain - If you know much about the NT Kernel, you know that one of the executive components is called the Security Reference Monitor (SRM). The DoD Red Book also defines a 'Security Reference Monitor'. We are talking the same language. In the Red Book, a security domain is managed by a single entity. To Quote: 'A single trusted system is accredited as a single entity by a single accrediting authority.
A ``single trusted system' network implements a reference monitor to enforce the access of subjects to objects in accordance with an explicit and well defined network security policy DoD Red Book.' In NT parlance, that is called the Primary Domain Controller (PDC). Remember that every system has local security and domain security. In this case, we are talking about the domain security. The PDC's 'Security Reference Monitor' is responsible for managing all of the objects within the domain.
In doing this, it creates a single point of control, and therefore a 'single trusted system' network. How to violate system integrity - I know this is alot of book theory, but bear with me just a bit longer. The DoD Orange Book also defines a 'Trusted Computing Base' (TCB). If you are an NT programmer, then you have likely worked with the security privilege SETCBPRIVILEGE. That privilege maps to the more familiar 'act as part of the Operating System' User-Right. Using the User Administrator for NT you can actually add this privilege to a user.
If you have the ability to act as part of the TCB, you can basically do anything. There is very little security implemented between your process and the rest of the machine. If the TCB can no longer be trusted, then the integrity of the entire network system is shot. The patch I am about to show you is an example of this. The patch, if installed on a Workstation, violates a network 'partition'. The patch, if installed on a PDC, violates the entire network's integrity.
What is a partition? The Red Book breaks the network into NTCB (Network Trusted Computing Base) 'Partitions'. Any single component or machine on the network may be considered a 'partition'.
This makes it convenient for analysis. To Quote: 'An NTCB that is distributed over a number of network components is referred to as partitioned, and that part of the NTCB residing in a given component is referred to as an NTCB partition. A network host may possess a TCB that has previously been evaluated as a stand-alone system.
Such a TCB does not necessarily coincide with the NTCB partition in the host, in the sense of having the same security perimeter DoD Red Book.' On the same host you may have two unique regions, the TCB, which is the traditional Orange Book evaluation for Trusted Computing Base, and the NTCB. These partitions do not have to overlap, but they can. If any component of one is violated, it is likely that the other is as well. In other words, if a host is compromised, the NTCB may also be compromised. Obviously to install a patch over the TCB, you must already be Administrator, or have the ability to install a device driver.
Given that Trojans and Virii work so well, it would be very easy to cause this patch to be installed w/o someone's knowledge. Imagine an exploit - Before I digress into serious techno-garble, consider some of the attacks that are possible by patching the NT kernel. All of these are possible because we have violated the TCB itself: 1.
Insert invalid data. Invalid data can be inserted into any network stream. It can also introduce errors into the fixed storage system, perhaps subtly over time, such that even the backups get corrupted.
This violates reliability & integrity. Patch incoming ICMP. Using ICMP as a covert channel, the patch can read ICMP packets coming into the kernel for embedded commands. Patch incoming ethernet. It can act as a sniffer, but without all of the driver components. If it has patched the ethernet, then it can also stream data in/out of the network. It can sniff crypto keys.
Patch existing DLL's, such as wininet.dll, capturing important data. Patch the IDS system.
Rootkit Ntoskrnl Executive Orders
It can patch a program such as Tripwire or RealSecure to violate its integrity, rendering the program unable to detect the nastiness. Patch the auditing system, i.e., event log, to ignore certain event log messages. Now for the rare steak. Let's delve into an actual kernel patch. If you already understand protected mode and the global descriptor table, then you can skip this next section.
Otherwise put on your hiking boots, there are a couple of switchbacks ahead. Rings of Power - Windows NT is unlike DOS or Windows 95 in that it has process-space security. Every user-mode process has an area of memory that is protected by a Security Descriptor. Usually this SD is determined from the Access Token of the user that started the process.
Access to all objects is handled through a 'Access Control List'. For Windows NT, this is called 'Discretionary Access Control'.
Personally I find it really hard to grasp something if I don't understand it's most basic details. So, this next section describes the very foundation that makes security possible on the x86 architecture. First, it is important to understand 'protected mode'. Protected mode can only be understood by memory addressing. Almost all of the expanded capabilities of the x86 processor are built upon memory addressing.
Protected mode gives you access to a 4 GB memory space. Multitasking and privilege levels are all based upon tricks with memory addressing. This discussion only applies to 386 and beyond.
Memory is divided into code and data segments. In protected mode, all memory is addressed as a segment + an offset.
Conversely, in real mode, everything is interpreted as an actual address. For our discussion, we only care about protected mode. In protected mode things get a little more complicated. We must address first the segment, followed by an offset into that segment. It is sort of a two step process. Why is this interesting?? This is how most modern operating systems work, and it is important for exploits and Virii.
Any modern mobile code must be able to work within this arena. What is a selector?
A selector is just a fancy word for a memory segment. Memory segments are organized by a table. These table entries are often called descriptors. So, remember, a selector is-a segment is-a descriptor. It's all the same thing. If you understand how the memory segments are kept track of, then you pretty much understand the whole equation. Every memory segment is first a virtual address (16-bits) plus an offset from that address (32-bits).
A segment is not an actual address, like in realmode, but the number of a selector it wants to use. A selector is usually a small integer number. This small number is an offset into a table of descriptors. In turn, the descriptor itself then has the actual linear address of the beginning of the memory segment. In addition to that, the descriptor has the access privilege of the memory segment. Descriptors are stored in a table called the Global Descriptor Table (GDT). Each descriptor has a Descriptor Privilege Level (DPL), indicating what ring the memory segment runs in.
Suffice it to say, the selector is your vehicle. Under NT and 95, there are selectors which cover the entire 4GB address range. If you were using one of these selectors, you could walk all over the memory map from 0 to whatever. These selectors do exist, and they are protected by a DPL of 0. Under Windows 9x, selector 28 is a ring 0 that covers the entire 4gb region. Tekken 7 apk.weebly.
Under NT, selectors 8 and 10 achieve the same purpose. Dumping the GDT from SoftIce produces a table similar to this: GDTBase=80036000 Limit=0x03FF 0008 Code0 FFFFFFFF 0 P RE 0010 Data0 FFFFFFFF 0 P RW 001B Code0 FFFFFFFF 3 P RE 0023 Data0 FFFFFFFF 3 P RW 0028 TSS32 8001D000 000020AB 0 P B 0048 Reserved 0000000 0 NP 0060 Data0 0000FFFF 3 P RW etc, etc. You can see what segment you are currently using by checking the CPU registers.
The registers SS, DS, and CS indicate which selectors are being used for Stack Segment, Code Segment, and Data Segment. The stack and code segments must be in the same ring. Segments can overlap one another. In other words, more than one segment can represent the same address-space. Segments can overlap one another wholly, or only in part. The address range for a segment is important, of course, but there is other delicious information we care about.
For instance, a segment also has a Privilege Level (DPL). - - - - - What is a DPL?
Descriptor Privilege Level. This is important to understand. Every memory segment is protected by a privilege level, often called a 'ring'. The Intel processor has 4 rings, 0 through 3, usually only ring 0 and 3 are used. Lower ring levels have more privilege.
In order to access a memory segment, the caller must have a current privilege level equal to or lower than the one being accessed. Current privilege level is often called CPL, and descriptor privilege level is often called DPL. This type of protection is a requirement for almost any security architecture. In the old days of DOS, mobile code such as virii were able to hook interrupts and execute any code at whim. They were walking all over the memory map at will. No such luck with the advent of Windows NT. There's a gaping need for Windows NT exploits that can take advantage of the old tricks.
The central problem is that most code is executing within user mode, and has not access to ring 0, and therefore no access to the Interrupt Descriptor Table or the memory map as a whole. Under NT, the access to ring 0 is controlled from the right to add your own selector to the GDT. When you transition to ring 0, you are still in protected mode and the Virtual Memory Manager is still operating.
Lets suppose you have written a virus that patches the Global Descriptor Table (GDT) and adds a new descriptor. This new descriptor describes a memory segment that covers the entire range of the map, from 0 to FFFFFFFF.
The DPL of the descriptor is 0, so any code running from it can access other ring-0 segments. In fact, it can access the entire map.
A DPL 0 memory segment marked as 'conforming' will violate integrity. The sensitivity label, in this regard, would be the DPL. The fact it is conforming violates the DPL's of other segments, if they overlap. If your descriptor is marked conforming, it can be called freely from ring-3 (user mode). This new entry goes unnoticed, of course.
Who monitors the GDT on their system? Most people don't even know what that is. There are few IDS systems that monitor this type of information. Now you have effectively placed a backdoor into the memory map.
You could be running under any process token, and have full read/write access to the map. This means reading/writing other important tables, such as the Interrupt Table. This means reading other procii's protected memory. This means infecting other files and procii w/ your virii at whim. Patching the SRM - The Security Reference Monitor is responsible for enforcing access control. Under NT, all of the SRM functions are handled by ntoskrnl.exe. If the integrity of that code were violated, then the SRM could no longer be trusted.
The whole security system has failed. The Security Reference Monitor is responsible for saying Yes/No to any object access. It consults a process table to determine your current running process' access token. It then compares the access token with the required access of the object. Every object has a Security Descriptor (SD). Your running process has an Access Token. Comparing these two structures, the SRM is able to deny or allow you access to the object.
Orange book: 'In October of 1972, the Computer Security Technology Planning Study, conducted by James P. Anderson & Co., produced a report for the Electronic Systems Division (ESD) of the United States Air Force.1 In that report, the concept of 'a reference monitor which enforces the authorized access relationships between subjects and objects of a system' was introduced. The reference monitor concept was found to be an essential element of any system that would provide multilevel secure computing facilities and controls.' It then listed the three design requirements that must be met by a reference validation mechanism: a. The reference validation mechanism must be tamper proof. The reference validation mechanism must always be invoked.
The reference validation mechanism must be small enough to be subject to analysis and tests, the completeness of which can be assured.' 1 The SRM is.NOT. tamper proof. It may be protected by the TCB security privilege, but I suggest that the only truly tamper-proof SRM is going to use cryptographic mechanisms. Using an attack vector such as Virii or Trojan's, a patch could easily be placed within the TCB. You can patch the SRM itself if you have access to the map.
In this, you can insert a backdoor such that a certain user-id ALWYAS has access. However, this does not require you to edit the user's security level in any way.
You are patching it at the access point, not the source. So, auditing programs will not be able to notice the problem. This is a simple trick that could be employed in any NT RootKit. There are several key components to the NT Kernel. They are sometimes referred to as the 'NT Executive'. The NT executive is really a group of individual components with a well defined interface.
Each component has such a well defined interface, in fact, that you could actually take it out completely and replace it with a new one. As long as the new component implemented all of the same interfaces, then the system would continue to function. The following are all components of the NT Executive: HAL: Hardware Abstraction Layer, HAL.DLL NTOSKERNL: Contains several components, NTOSKRNL.EXE The Virtual Memory Manager (VMM) The Security Reference Monitor (SRM) The I/O Manager The Object Manager The Process and Thread Manager The Kernel Services themselves -(Exception handling and runtime library) LPC Manager (Local Procedure Call) Hey, these are some of the modules listed when a Blue Screen occurs! The system is just a big memory map!
With all of this data we are bound to find structures of interest! Many key data structures are crucial to security. Once we know what we are looking for, we can get into SoftIce and start poking around. A list of the exported functions for some of these components is in Appendix A. Using a tool such as SoftIce, reverse engineering the SRM and other components is easy;) The methodology is simple. First, we must find the component we are interested in. They all sit in system memory at some point.
Some key data structures are: ACL (Access Control List), contains ACE's ACE (Access Control Entry), has a 32-bit Access Mask and a SID SID (Security Identifier), a big number PTE (Page Table Entry) SD (Security Descriptor), has an Owner SID, a Group SID, and an ACL AT (Access Token) Now for some tricks! The first thing we need to do is identify which of these data structures we will be using.
If we want to reverse engineer the Security Reference Monitor, then we can be assured that our SID is going to be used in some call somewhere. This is where SoftIce comes in. SoftIce has an incredible feature called expressions.
SoftIce will let you define a regular expression to be evaluated for a breakpoint. In other words, I can tell SoftIce to break if only a special set of circumstances has occurred. So, for example (working implementation): 1. I want softice to break if the ESI register references my SID.
Since a SID is many words long, I will have to define the expression in several portions: bpx (ESI-0 0x12345678) && (ESI-4 0x90123456) && (ESI-8 0x78901234) What I have done here is tell softice to break if the ESI register points to the data: 0x1234. Notice how I use the - operator to offset ESI for each word.
Now, try to access an object. SoftIce will promptly break when your SID is used in a call. There are many system components that are worth reverse engineering. You may also want to play with the following: 1. GINA, (GINA.DLL) The logon screen you see when you type your password. Imagine if this component was trojaned. A Virii could capture passwords across the enterprise.
LSA (The Local System Authority) This is the module responsible for querying the SAM database. This would be an ideal place to put a rootkit-password that.ALWAYS. allows you access to the system. SSDT, The System Service Descriptor Table 4.
GDT, the Global Descriptor Table 5. IDT, the Interrupt Descriptor Table Getting to ring zero in the first place - User mode is very limiting under NT. Your process is bound by the selector it is currently using.
The process cannot simply waltz over the entire memory map. As we have discussed, the process must first load a selector. You cannot simply read memory from 0 to FFF, you can only access your own memory segment. There are tricks however.
If the process is running under a user token that has 'add service' privilege, then you can create your own call gate, install it in realtime, and then use it to run your code ring 0. Once you are running ring 0 you can patch the IDT or the Kernel. This is how User-Mode normally accesses a Ring-0 Code Segment. If you don't want to go to this trouble, you can upload a byte patcher that runs in ring zero on boot. This is as simple as writing a driver and installing to run on the next reboot. However, installing your own call-gate is by far the most sexy.
Lets talk sexy. The answer is a call gate. All of the functions provided by NTDLL.DLL are implemented this way. This is why you must call Int 2Eh to make a call. The entire set of Int 2Eh functions are known as the Native Call Interface (NCI). What really happens is the Int 2Eh is handled by a function in NTOSKRNL.EXE. This function is called KiSystemService.
KiSystemService routes the call to the proper code location. When you make a system call, you must first load the index of the function you wish to call. This is loaded into register EAX. Next, if the call takes parameters, a pointer to this block is loaded into EDX.
Interrupt 2Eh is called, and EAX holds the return value. This is old hat to most assembler programmers. What is not obvious is how this is implemented in the Kernel. The function KiSystemService is called, and left with the responsibility for dispatching the call. KiSystemService must first determine.WHAT. function to call next, based on what we put in EAX.
So, to this end, it maintains a table of functions and their index numbers. Imagine that! SofIce will dump this table if your interested.