darien gap

A bit more on moving to SYSTEM...

2006-08-08T20:19:00.000-07:00

Last time, I covered using the Scheduler service to run a disk image in the context of SYSTEM. As I don't have a lot of interest in writing the remaing posts on the subject, I'll cover the topics here - maybe I'll get back to them.

First, I received a comment on my last post, which I responded to:
http://dariengap.blogspot.com/2006/06/admin-to-system-scheduler-service.html#comments

Thank you, j.j., for your unsolicited but welcomed input.

Some of the other means of running as SYSTEM are as follows:

The documented CreateService(); create a service which, by default, will run in the context of SYSTEM.
Assert the SeDebugPrivilege, then use some combination of VirtualAlloc() and CreateRemoteThread() or their native counterparts. When using this technique, the function pointer passed to CreateRemoteThread() can be your own copied code, or a Win32 (or third-party) function (such as LoadLibrary()). I believe this last was originally published by Jeffrey Richter.
Use the SeTakeOwnership or SeRestore privileges to modify the DACL on a process object (optiona; the SeDebugPrivilege can be used instead) and the primary access token object for that process. A handle to this token can then be used with ImpersonateLoggedOnUser or CreateProcessAsUser. In the latter case, remember to use DuplicateToken - if you forgot, the very helpful return code will let you know what happened. Also, you can use the native API to set the process token on an already running process.
Assert the SeDebugPrivilege and open lsass.exe and enumerate the handles to token objects in this process using Nt/ZwQuerySystemInformation. In my experience, there are two or more handles to tokens for SYSTEM that have DACLs that allow BUILTIN\Administrators to use without modifying security.

That is it for now...

Admin to SYSTEM: Scheduler Service

2006-06-01T21:47:00.000-07:00

This is the first in a series of posts on means to "escalate" from a non-SYSTEM administrative context to the context of SYSTEM.

The first means of performing this escalation is the documented and well-established method of using the scheduler service. The scheduler service is installed with all versions of NT through 2k3, and provides a simple means of scheduling one-time jobs or periodic jobs. Jobs are backed by an on-disk executable image - this means that the code you'd like to run must hit the disk. Because jobs are ultimately a child process of the scheduler services process (svchost.exe in win2k and above), they inherit the user context of the scheduler services, which by default is SYSTEM. Therefore, it is possible to use the scheduler service to run arbitrary code as SYSTEM.

A good way to become familiar with the scheduler service is to use the native Windows command line tool at.exe, which allows you to schedule, view, and delete jobs. You can run regedit.exe interactively in the context of SYSTEM by doing the following:

>at 11:54pm /INTERACTIVE regedit.exe

This assumes that you'd like to run the job at 11:54 PM and that it is before 11:54 PM; if it is after 11:54 PM the job will be scheduled (silently!) for 11:54PM tomorrow. It appears that the scheduler services works on one minute intervals, so you might have to wait a minute for the result.

If you are interested accessing the scheduler service programmatically, you can use the well-documented NetSchedule* API, consisting of NetScheduleJobAdd, NetScheduleJobDel, NetScheduleJobInfo, and NetScheduleJobEnum. Although I happened to be familiar with these APIs, one way you could have determined that these were in fact the APIs to use is to check out the dependencies of at.exe. From the Visual Studio command line, try:

>dumpbin /IMPORTS at.exe

Check out the imported functions from netapi32.dll.

The documentation on MSDN in self-explanatory. I have provided an example program anyway at http://www.dariengap.net/code/schedulersvc.zip.

A few final notes:

You can use the scheduler service over RPC to schedule a job on a remote host.
The scheduler service must be running. You can start the scheduler service either locally or remotely using the Win32 Service API. In particular, check out OpenSCManager, OpenService, and StartService.
If you'd rather not run a custom executable, you can schedule a custom DLL to "run" through the use of rundll32.exe, or schedule a batch file (which auto-magically is converted to cmd.exe... by CreateProcess)
You can schedule a job to be backed by an image on a network share. The network share will be accessed via a "NULL" session (in the case of NT 4 and below, or a non-domain host) or in the context of the computer account (2k and up in a domain environment).

Layer 8 Tunneling over HTTP

2006-06-01T16:44:00.000-07:00

Tunneling is the concept of encapsulating one protocol inside another, in particular (to me, anyway) in violation of the traditional OSI reference model. For example, pushing SSH (a layer 7 or application protocol) over HTTP (another layer 7 protocol) is an example of tunneling. SSH provides "port redirection", allowing the tunneling of arbitrary protocols over tcp (a layer 4 protocol). Dan Kaminsky (http://www.doxpara.com/) is well-known for demonstrating the tunneling of arbitrary protocols over DNS.

The important point, in my opinion, to take away is that if you have the ability to transmit arbitrary data over any protocol (HTTP, DNS, and SMTP are some obvious examples) and you control the remote endpoint, you can manipulate the format of your data such that you can tunnel any protocol. The logical extreme of this that you can, as the saying goes, tunnel IP (or gopher, or SSL, or Bluetooth L2CAP) over smoke signals.

Another point is that tunneling is most definately not the same as manipulating "well-known ports" or their equivalent. For example, pushing HTTP traffic over TCP 53 (to 'simulate' DNS by, for example, exploiting a hole popped for DNS in a firewall) is not tunneling. However, breaking HTTP traffic into small chunks, encoding them in well-formed, legal DNS packets, and tramsitting those DNS packets over TCP 53, and then decoding on the far side is an example of tunneling.

While tunneling is traditionally applied to network protocols, it has a logical corollary in any other means of transferring or storing data. File formats are an especially obvious example.

Consider the case of the bitmap (.BMP) file format. Use an image editor to make a one pixel by one pixel BMP and take a look at the resulting file in a hex editor. With a reference to the BITMAPFILEHEADER and BITMAPINFOHEADER structures (take a look at wingdi.h or http://www.fortunecity.com/skyscraper/windows/364/bmpffrmt.html), you have everything you need to know to understand the format (at least, in its simplest incarnation). The fun part about this is that the actual data is a bunch of RGB values representing the series of pixels. Nothing prevents you from writing any bytes you'd like as the image data - a text file, a Word document, an executable - anything at all. Of course, the image will look like noise, with obvious blocks or bands of consistency depending upon the entropy of the data you injected as the "image".

This is different from the concept of stenography. Anyone who looks at this image file will notice immediately that something is wrong - and might take the time to investingate the image data and find, for example, a MS-DOS executable preamble as the first two bytes and deduce that someone was trying to sneak an exe past them. This can be circumvented trivially by compressing and/or encrypting the payload data.

An obvious application of this technique is to take an illicit file type, "tunnel" it in a bitmap, and then upload the bitmap via an HTTP POST. The web proxy that handles the transaction, any sensor that is watching the traffic, and the recipient all can handle the file as a bitmap. After ripping off the bitmap headers (and decompressing and/or decrypting), the recipient has the orignal file.

Over HTTP, by changing the MIME type to image/bitmap and "tunneling" the data in a well-formed BMP file, this process can be thought of as "layer 8 tunneling". It is not a new idea, and there is probably a better name for it already, but I think it is descriptive and succinct.

Lastly, the BMP file format was used as an example only because of its simplicty. JPG, PDF, AVI, DWG, even TXT (hey, what is UUEncoding and Base64 again?) - all file formats can be used for layer 8 tunneling.

Escalating from Administrator to SYSTEM

2006-05-29T19:28:00.000-07:00

Running code in the context of SYSTEM is desirable to perform certain tasks. While running as an administrator, it is possible - by design - to be able to run arbitrary code in the context of SYSTEM. There are numerous means by which this "privilege escalation" can be accomplished; I will document a few in later posts, but first I'll provide some background.

By administrator, I mean any context which includes the BUILTIN\Administrators group (S-1-5-44) group. Furthemore, this group SID should be enabled and should not be deny-only. Programmatically, see the documentation for GetTokenInformation, TOKEN_GROUPS, and SE_GROUP_ENABLED and SE_GROUP_USE_FOR_DENY_ONLY on MSDN.

Additionally, I mean a user context which includes the privileges assigned to the administrators local group as part of a default Windows install. Most notably, I mean the SeIncreaseQuotaPrivilege, SeTakeOwnershipPrivilege, SeRestorePrivilege, SeDebugPrivilege and SeImpersonatePrivilege. For more information, see the documenation for GetTokenInformation, TOKEN_PRIVILEGES on MSDN, Default User Accounts and Groups on TechNet, and the "NT Defined Privileges" section in winnt.h.

If you are not familiar with some or all of the concepts above, you'll find that the normal case is that any member of the Administrators group will work just fine. For example, if you log in using the "500" account (by default, named administrator) you'll be able to "escalate" to SYSTEM using the techniques described.

There are numerous examples of what can be easily done in the context of SYSTEM that is much more difficult to do (and impossible to do while avoiding race conditions) while running in a non-SYSTEM administrative context. An example is reading the famed SAM and SECURITY keys in the registry.

Another example is to easily gain certain privileges which are not, by default, assigned to administrators but are assigned to SYSTEM, such as the SeTcbPrivilege and the SeAssignPrimaryTokenPrivilege. While an administrator can assign these privileges to any account, they do not take effect (are not reflected in the tokens of processes running in the relevent user context) until a new logon session is created. Take a look at LsaAddAccountRights and "How to Manage User Privileges Programmatially in Windows NT" in the KB.

Understanding how to move from Administrator to SYSTEM, and, more importantly, why this works is a great way to understand the Windows security model, especially concepts such as security descriptors, DACLs, SIDs, ACEs, groups, privileges, logon sessions, and tokens. Over the next few posts, I'll provide more details (and, in some cases, code) to help you do this.

Finding the PID of LSASS

2006-04-20T20:45:00.000-07:00

Finding the PID of the LSASS process is a necessary prerequisite for a variety of interesting tasks – consider pwdump from Todd Sabin. In Sabin’s pwdump posting, he writes:

This newer version of pwdump2 is able to find the pid of lsass.exe automatically. Several people sen[t] me source code to do this, but they all required an extra DLL, which is why I never incorporated them. Recently, Gary Nebbett published Windows NT/2000 Native API Reference, an invaluable reference, documenting virtually every undocumented NT kernel call. Among other things, it demonstrates a method of determining pids without linking to more DLLs.

The source code for pwdump – and countless other source code listings – demonstrate how to use the native api to enumerate a list of all processes on a box and slog through them, looking for the pid for a process backed by a specific image. While there are documented means to do this – notably, the toolhelp and process helper apis, they do – as noted – require statically or dynamically linking to an additional library.

An alternate, although undocumented (and therefore subject to change without notice) method of determining the PID of LSASS is by reading the LsaPid DWORD value from the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

One means of reading this value is to use the Win32 registry APIs; this, however, has the side-disbenefit of requiring advapi32.dll, which is precisely the effect Sabin was trying to avoid in pwdump. Of course, the native api registry functionality can be imported from ntdll.

One potential use of this value is in batch scripting; reg.exe can be used to query the value without so much busywork parsing the output from tasklist or equivalent.

I have made no effort to use tools such as RegMon from Mark Russinovich at Sysinternals to determine which process, if any, uses this value. If anyone knows, I’d love to hear from you.