Just a few simple tips for Inspecting and Hardening Windows systems.

6.1.1 Regular applications up to Win7/Win2K8 R2, and also as "non-WinRT" apps on Win8:

• First of all, we have the "oldfashioned WinApi" Desktop apps, which "deal" with the well-known WinApi.
  They all have basically the same "look and feel" over the years that Windows exists by now.
  It's those category of applications with the typical user32 controls as radio buttons, "OK/Cancel"dialogboxes etc..
  Suppose somebody creates a WinApi app, for example using VB6 (not the dot NET version), then it directly uses comdlg32, user32 and a series
  of other API dll's, all belonging to the WinApi, which can be largely associated with the "csrss" subsystem.
  CSRSS is short for "Client Server SubSystem".
  These apps are nowadays also often called "unmanaged" code.


• The newer "Dot Net" apps (and "webservices"), uses a well defined series of class libaries.
  Those apps live/run in the socalled " Common Language Runtime "(CLR)" susbsystem.
  The CLR is a sort of Virtual Machine, which provides all the interfaces for such a dot NET app, to perform it's work.
  So, dot NET apps are not (direct) WinApi apps. You might say that the CLR "encloses" the dot NET app.
  You may visualize this as if the CLR is a container which encloses the apps, and provides services to those apps.
  This is not exactly the same as "sandboxing".
  
  Although dot NET is new compared to oldfashioned Desktop apps, Microsoft also made it possible for developers
  to use existing COM code from within .NET, and the other way around.
  For example, COM TLBs can be converted into .NET metadata, allowing .NET programs to treat COM components
  in a way as if it was all produced in .NET. Note that DCOM will be discussed in the next section.
  This way, you can question the "purity" of dot NET apps, but it was all legal and by "design".
  
  In DOt NET, having precise metadata describing the application, is much more prominent compared to e.g. WinApi Desktop apps.
  
  DOT NET apps have a selfdescribing "manifest" which (should) clearly define what this application needs.
  So, there is (generally) no need for all sorts of wild dll's and unclear Registry entries.
  As it was presented quite some time ago, you can xcopy the app from some sort of media to your system, and it
  can be run without difficulties (this is somewhat "relaxed" nowadays).
  These apps are often called "managed" code. "Managed Code" is code whose lifetime and execution is managed by the CLR,
  and which uses selfdescribing "manifests".
  
  Indeed, generally security should be enhanced using fully managed code.
  

As DOT NET uses a higher abstraction level (compared to e.g. traditional C/C++), so all sorts of physical details like
heap allocation, and de-allocation etc.., is not for the developer to worry about.
For example, a special routine, the Garbage Collector (GC), like in Java, will clear out constructs if they are not used anymore.


• As they are a bit special, we have the "Native" NT apps, which use the (true) systemcall interface directly (ntdll.dll),
  instead of using the WinApi first, that is, instead of using the regular "crsss", or the WoW64 subsystem.
  Almost all regular apps (like Exchange Server, SQL Server etc..) are NOT native.
  So, a native application uses the functions of NTDLL.DLL directly, so a lot of "comfortable" functions which are offered
  by the higher level WinApi, now must be taken care of by the app itself, like requesing a Heap allocation and deallocation (etc..),
  using the functions of NTDLL.DLL.
  
  Some Windows components themselves are called Native NT apps, because they need to activate and perform
  work during the bootphase, before the WinApi is up an running.
  
  For example, the SMSS subsystem is up quite early in the bootphase (before the WinApi)
  and it checks "HKLM\System\CurrentControlSet\Control\Session Manager\BootExecute
  to find modules which should run before all of the "rest" of the usermode systems are up.
  
  Ofcourse, WinApi (csrss) itself is a native app, since it "floats" on the true fundamental systemcall interface.


• "DCOM" apps. DCOM, or "Distributed COM" applications are composed of a set of binary components, where those components may
  run one the same machine, or are distributed over a number of machines.
  DCOM is like COM "over the wire" (between machines). It's not dependent on a certain programming environment (like that you must
  use C++ or so). COM is a specific 'object model" with clearly defined interface descriptions, which allow the objects
  to communicate, using "Remote Procedure Calls". So, the underlying communication protocol is "RPC" (over TCPIP).


• "Java" applications, like dot NET apps, live in their own Virtual Machines, called "JVM's" (Java Virtual Machines).
  Such a JVM is very comparable to the working of the dot NET Virtual Machine (that is: the CLR VM).
  However, the Java apps themselves are a completely different "world", compared to for example dot NET apps. But, the way how the apps
  (dot NET and Java) use the services offered from their VM's, are quite similar.

Note: figures like fig. 10 are, in a sense, "not really great". However, they provide a means to present a quick "birdseye view" on API's and Architecture.
So, this gives them some justification. But they are never fully satisfactory. Please note that the "app store" and "WinRT" API
only apply for Windows 8.

6.1.2 "Store Apps" and WinRT on Win8:

All the "traditional" applications as seen in section 6.1.1, work (generally speaking) also in Win8.
So, Desktop applications for the usual WinApi, will run too in Windows 8.

But a new additional API and application model is implemented, which set Win8 apart from the former versions.
Here we mean the "app store" applications using the new "WinRT" api. These were formerly called "Metro apps".

WinRT apps should not interfere with other running applications, because they are ran in a "sandboxed" environment.
A "sandboxed" environment "looks" like an application Virtual Machine, shielding the application, as well as restricting
the application in accessing resources like filesystem objects. For example, you can restrict an app to where it can write.
However, sandboxing is certainly not the same as what we understand to be a true VM.

The following "facts" with respect to "Store apps/WinRT" can be listed:

- They are Distributed only through the Windows Store.
- They live in a "sandboxed" environment.
- WinRT itself uses the COM API as well as the WinAPI.
- There are more restrictions possible on resource access.
- There are better facilities for permissions like for "launching" the application.

But.., the situation for what we consider to be "business" applications, is that the majority still fall in the catagories we have
listed in section 6.1.1.

The "app Store" applications are under tight control by Microsoft, so it seems reasonable to think that this type of application
using WinRT is less prone to malware compared to the traditional applications listed in section 6.1.1.
It also seems reasonable to expect that quite some business applications might shift from Desktop to "Metro Apps" in due time.

It's remarkable to see how strong WinRT depends on COM, and how the "mechanics" of both are very similar.
So, it's very important to get grip on COM & DCOM, since this helps us in appreciating security with the traditional applications as well
as with WinRT applications.

6.2. Stacks and Heaps and some system details:

Here are a few notes on system details like "stacks" and "heaps", which concepts are quite important in our study.

Modern development environments (like C#) are business oriented: the developer does not deal anymore with
heaps and stacks, in the way the traditional programmer did (like in using "C").
Even maintenance on objects and memory areas are nowadays "covered" by a Garbage Collector process, which may
destroy objects if references to the objects are zero, or it may use other "triggers" for cleaning memory.

However, even in modern environments, under the hood stacks and heaps are still used on the system level.

⇒ The "stack" is the memory set aside for variables and function addresses, for a thread of execution.
Each thread created, gets attached to it's own stack. When a function is called, a new block can be used on
top of the stack.
A stack is relatively small (compared to a heap), and is a "sort of map" of the running code, containing "pointers".

⇒ "Heap" is the usual name for the larger "free space", the memory space where dynamic objects are allocated.
File pages are loaded here, as well as programmatic "objects", and other stuff the program needs or creates.
It's much harder to keep track of used/unused blocks in the heap, compared to the simplicity of stacks.

Typically, a process has one (or a few heaps), while each thread has its own stack.

when you use a function call for a new "object", the memory for the object is allocated from the heap. However, pointers
to internal methods are "stacked" on the stack.

Normally, When a new object is instantiated this way, you will be allocating memory from the heap
but you need a pointer (sort of variable) to store the location (in the stack).

The figure below tries to illustrate the difference between a stack and a heap.

Fig 11. High-level illustration of Stack and Heap.



Stacks are for the small "things": variables, addresses for functions. Heaps is for the larger "things":
objects, filepages and that kind of objects.

In case of objects and that sort of "stuff": A stack "says" where the stuff is. A heap stores stuff.

A "quick note" on Program Load:

Here are a few short descriptions of a program load:

⇒ A WinApi program:

When an executable is started, a new process is created. Each process gets a virtual address space.
In this address space various things are loaded or created by Windows, before the executable can run.
Among which are:
- All Windows needed libraries (kernel32.dll, etc...)
- The executable itself
- All the libraries that the executable imports
- The Process Environment Block (PEB), which stores information about the process
- A Thread Environment Block (TEB) for the main thread
- A stack for the main thread
- One or more heaps (often one, sometimes two)
- a stack for each new thread.

Viewed from a "file format" perspective, the executable file (.exe, .dll., .sys, .drv, and others) uses
the PE (Portable Executable) header, which also carry information about the sections in other parts of the file.
In a way, it resembles a sort of index.
One important field is the RVA, or the "relative virtual address". It specifies the offset of the "entry point"
relative to the loadaddress of the file. This sort of "explains" how an executable gets "running".

⇒ A DOT NET program:

From a logical view, .NET executable is an "assembly" and is more or less a selfcontained solution.
It runs "in" the Common Language Runtime (CLR), which is a runtime environment for .Net applications.
The development environments, will take care that the source code get's build to MSIL bytecode,
which "is fit" to run in the CLR environment.
This situation is really somewhat (or quite a lot), from a logical perspective, comparable to the Java platform.

Another thing is, that the .Net programmers do not have to deal with thread management, heaps etc..
that will all be done by the .Net environment. From a hard technical viewpoint, heaps, stacks, threads
are still there, but not in immediate sight of the developer.

Viewed from a "file format" perspective, the executable file has an extended PE header, with CLR sections,
which plays a similar role compared to the traditional executables.
Certainly, a program gets it virtual address space, and the RVA again points to the entry point.
There are entry points (like importing) to .Net core files as well (e.g. mscoree.dll).

Section 7. Some notes on "traditional/legacy" COM/DCOM Security

7.1 A birds-eye view on the DCOM architecture:

7.1.1 Some general notes:

We need to have a basic understanding of DCOM before we can say anything usefull about security.

A complex technology as DCOM cannot be learned in one short "Big Bang". So, as always, by "slowly" presenting some facts
we will be able to appreciate DCOM.
The "Distributed Components Object Model", is a technology which makes it possible that COM objects
communicate, and work together, in a distributed environment (across multiple hosts).
Ofcourse, a DCOM application can work on single host as well.

DCOM objects use the RPC framework. We will see in a minute what that means.
DCOM is just like COM, but in case of DCOM, it uses COM components over several Host computers.
If "COM" sounds a bit alien, then rest assured: many Windows programs are COM components, or use COM components,
like programs as "Wordpad", or the Office Suite (Word, Excel etc..), or parts of SQL Server etc...

The objects usually have implemented "internal functions" (or procedures), which are often called "methods".
You should look at it this way, that a client object, calls a procedure of a Server object in order to get some work done.
This upper statement is already pretty close to what is the "heart" of RPC (Remote Procedure Call).

You might say, that such a implementation resembles a Client/Server setup. It is, but it can be "peer to peer" as well: With DCOM, any component
can be both a provider and a consumer of functionality.

A client object "can talk" to the Server component through method calls. The client could obtain the addresses
of these methods from, for example, a simple table of method addresses (a C++ like "vtable").
This then, is actually one of the possible implementations of "finding methods", by using a compiled "static" approach.
However, the upper statements are not fully correct, when we talk about DCOM. It's pretty close, but in case of DCOM
we must talk about the "Interface descriptions" too.

It's also important to understand that the Operating System find it as one of it's main tasks to "shield" processes (like DCOM processes),
and one process cannot just interfere or talk to another process. That's why a number of "Inter Process Communication" (IPC) techniques
were implemented to achieve just that, like for example "shared memory", "pipes", and "RPC".
Indeed, in DCOM it's the RPC implementation of IPC.

What is very typical of COM/DCOM, is that well-defined Interfaces have to be in place, to access methods of an object.
The objects themselves, appear as if they are black boxes. It is not important how the object was programmed (like using C++ orso).
Only the interface matters: objects cannot be accessed directly, but only through its interfaces.

Questions arise ofcourse, as to how a client "knows" about the available interfaces.

In OO (object oriented) environments, objects and classes are almost the same thing. Generally, a class
is a sort of template from which real objects can be instantiated. In DCOM, people use it the same way, but often
a "class", or "object class", just as easily refers to the live code. Here, we don't care about that too much.

Let's take a look at typical picture (fig. 12) as to how DCOM objects communicate between Hosts:

Fig 12. High-level illustration DCOM communication.



In the figure above, some things really deserve an explanation.
Figure 12 suggest that the client object and server object are on different Hosts. This is called "Remote Server".
So, an "exe" or "dll" client, wants something done by the remote Server object.
The client needs to know about the Interfaces associated with this Server object. The theory is like this:

While setting up a DCOM project, an IDL (Interface Definition Language) file is created that defines the interfaces and its methods,
and also associates these interfaces with an "object class". If such an IDL file is run through an IDL compiler,
then it generates "proxy" and "stub" code and header files which are used by the server code and the client code.

Now, this proxy and stub code will function as an "in process" Server at the client, and an "in process" client at the Server.
It probably sounds strange, but this is how "remoting" is done. As it has turned out, a pure RPC implementation does not work,
and a process of marshalling/unmarshalling "wraps" requests and responses over the RPC network.
So, for example, at the Server object, the stub unwraps a request, and now looks like a local client, which does a method call.

In other words: The proxy resides in the same process as the client. From perspective of the client all interface calls look local.
The proxy takes the client's call and forwards it to where the real Server object is running.
This implementation enables the client to access objects in a different process space, even on a different Host,
as if it's all local in it's own process space. This is often denoted as marshaling.
However, since COM objects are binary objects, and may reside on different platform (NT, OpenVMS, Linux), marshalling
is also used for the representation and serialization of arguments and results, so that it can be correctly understood
by the libraries on those different platforms.

The proxy and stub are COM objects too. The will be created as neccessary.

Next to IDL files, in many cases, like with Visual Basic, socalled type library files (.TBL files) might be created (depending on the environment)
which are binary files, also used to define interfaces and other metadata for COM objects, just like IDL does.
It so can also happen that IDL files get's compiled by the MIDL compiler into a type library (TLB). These sort of files are pretty
good "readable" by several different other environments, what may result in that the metadata for a COM object, can be
imported into another development environment (like DOT NET).

Although you may have the code on the machines, what about when you have lot's and lot's of COM objects and their interfaces?
How do you distinguish between them?


This situation is solved by using "unique ID's" for each interface, and each object (or, as most say: "object class").
So, in order to identify an interface and object, ID's are used. The best sort of ID, are "GUID" or a Globally Unique Identifiers".
These are 16 byte strings, or what is the same, 128 bit strings in hexadecimal, enclosed by curly braces.

• A CLSID is a globally unique identifier that identifies a COM class object.
  The "HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID" key stores the CLSID, or it is stored in a deeper level like
  "HKEY_LOCAL_MACHINE\SOFTWARE\Classes\identifier\CLSID
• An interface is registered as a IID in "HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface".
• DCOM objects hosted by the same executable are grouped into one AppID.
  The "HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppId\AppId" key registers GUID for the AppId.

The above is not a strict listing for all Windows versions.
A Windows system using COM and DCOM, can have lots of registry keys, all identfying Objects and interfaces,
and additional properties like the "thread model" used.

The original DCOM implementations, rely very heavily on the Registry settings.

A later variant, uses a sort of "manifest", like DOT NET does, but stored as a seperate XML file to the executable.
However, since DOT NET was Microsoft's successor to DCOM, DCOM was more or less expected to be phased out
in favor of DOT NET. DOT NET got big indeed, but DCOM did not exactly phased out.
Nowadays it seems that DCOM still holds a "niche" in Business Apllications, and even today it's not a small "niche".
Many large applications use DCOM in various parts, like some components of "SAP", and too many others to list here.

7.1.2 Remote Activation:

It's very important to realize that a DCOM cient can "instantiate" a Server object if that one does not exists yet.
It means that on some Server, probably some .dll is installed, which actually carries the Server object code.

So, suppose we have a SERVER1 with a live client object, which wants to have work done by the DCOM object "SrvObj" on SERVER2.
As a very simple example, take a look at this metacode at SERVER1, which we assume that it gets executed right now.

At SERVER1:

CoInitialize;
COSERVERINFO ServerInfo = {L"SERVER2"};
CoCreateInstanceEx(CLSID SrvObj);

Although it's only a sort of meta code, the "CoCreateInstanceEx(CLSID SrvObj)" statement really is the key to the activation.

Here a remarkable security event takes place. Under which identity may the "SrvObj" object be launched, and
from which places, and at which places? This is for section 7.2.

Note that the CLSID identifies the object class at SERVER2.

7.1.3 A few words on COM:

Since we already have touched on DCOM, which is "COM over the wire", we will only briefly touch on COM.
COM is local, and uses the same notion of "objects", "interfaces" and Registry keys as "CLSID's", in the same way as DCOM does.

Some people distinguish between 3 types of COM, with attention on how COM objects communicate:

• In-process (on the same machine, same process space, No IPC neccessary, the client makes "direct calls")
• Out-of-process (on the same machine, different process spaces, using IPC)
• Remote Server (this is DCOM: objects on different machines, different process spaces, using IPC)

Fig 13. High-level illustration COM communication.


In figure 13, I have left out the "COM runtime libraries" and "RPC libraries" (if they apply), as compared to figure 12.


- For "In-process" COM objects, the client instantiates a Server object which loads in the same process space.
Everything is local to the client and Server objects, and a proxy and stub is not neccessary, since IPC does not apply here.
For example, a dll is loaded and now running in the same process space as the client.

- For "Out-of-process" COM objects, the client instantiates a Server object in a different process space.
IPC is neccessary here, since two processes must communicate. So, a proxy and stub is neccessary, like in DCOM.
Remember from section 7.1.1 why a proxy and stub was neccessary when using IPC (here RPC) ?
But it all happens in the same Operating System, on the same machines.

- Remote Server: already seen in section 7.1.1. See figure 12.
For example, objects on an Application Server connecting to objects on Machine acting as a Service Bus (ESB) etc..

Note: Using IPC as RPC on the local machine, is sometimes called "Local Procedure Call" (LPC).

7.1.4 Does my system use COM or DCOM?

You bet it does. Many components of Microsoft standard programs, and components in suites like Office, are either COM based,
or can call Server objects directly, or use COM/OLE API's to instantiate objects.

Also Business environments, components in Exchange, SQL Server etc.. are based on COM, and sometimes they use "COM across the wire" (DCOM).
Again, if browing the Registry for example, you will find many well-known programs, with references to COM.

7.1.5 A few other facts of DCOM:

⇒ Since it's based on RPC, we know from section 5 that the main port is port 135.
This port is used by the RPC endpoint mapper in Windows, and which is practically mandatory to have open in an internal network.
As we know, the mapper will assign higer ports to applications, but the listener sits on 135.
For this reason, and others, DCOM is certainly "not done" on public interfaces (see section 5 for further explanation).

⇒ DCOM is quite old (early nineties), and was implemented at many locations, before the "Internet Explosion".
The internet apps are often HTML/XML/SOAP (and related tech) based, and that's not the DCOM style.
Web services and newer Microsoft Technologies are ready for Internet apps, but DCOM is not.

⇒ Many cients can be connected to many Server objects. When an object is not referenced anymore, for some time,
it must be removed from memory. When a Server object receives a first request from a new client, a reference counter
in the Server object is increased by one. If communications stop, objects still ping each other at some interval. If a ping is not
received again within 6 minutes, the client is considered to be disconnected, and the reference count decreases by one.
If the reference count reached zero, the Server object will be cleared from memory.
This mechanism actually is the "Garbage Collection" protocol in DCOM.

⇒ Errors related to DCOM can also be found in the "event viewer" of Windows. Possibly, the term "DCOM" is explicitly visible,
or you may see "RPC_some_error" code records too. Sometimes, you may see a CLSID of an object class, or an Appid (see above).
If the information in the eventvwr is not sufficient, you can search the registry on the (for example) the CLSID which is
that 128 bit string between the "{ }".
You can also use the "dcomcnfg" command on 32/64 bit systems, or "C:\WINDOWS\sysWOW64>mmc comexp.msc /32" command
for a 32 bit app on a 64 bit platform.
The registry and the dcom configuration commands, will probably give you pointers to which application it is all about.

Note: always be extra carefull when using those commands on any system of any importance.

7.1.6 rpcdump and Endpoint Mapper:

RPC is a higer level protocol, and usually uses the "winsock/tcpip" stack to access the network. Maybe you want to view figure 6 again in section 5.
How DCOM applications use the RPC protocol, and lower services, can for example be seen in the Registry in:

"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc".

Here you may find a record like "DCOM protocol: ncacn_ip_tcp", meaning that RPC uses the regular tcpip stack.
Actually, as we have seen in a former section, the "Endpoint Mapper" (RPCSS) usually listens on port 135, and will use higher numbered dynamic ports
to establish communication between RPC servers and clients.
(The term "ncacn" is short for "Network Computing Architecture Connection-Oriented RPC Protocol").

The standard DCOM implementation is not a success for Internet applications, since port 135 must be opened in firewalls,
which nobody will do.

To make DCOM more appealing for Internet applications, the "ncacn_http" protocol was developed, which makes it possibel
to "tunnel" DCOM traffic through a Webserver on both sides.
The WebServers then acts like a "proxy" for DCOM applications.
In fact, "ncacn_http" enables "RPC over HPPT", making it wider in scope than DCOM alone.

Using it with http is "not done". Using SSL, so in fact using HTTPS (HTTP with SSL) could make it acceptable.
Since there exists interoperability issues among versions, be very carefull to make it work with SSL only.
This is a seperate "study" actually, and it probably needs quite some time and effort: Its a bit of an "expert" work only.

rpcdump:

The following protocols can be used by the RPC endpoint mapper:

Local RPC: ncalrpc
TCP/IP: ncacn_ip_tcp
SPX: ncacn_spx
Named pipes: ncacn_np
NetBIOS: netbios
RPC over http: ncacn_http

The rpcdump "endpoint diagnostic utility" (Resource Kit commandline utility) can show you which protocol bindings are registered on your machine.
Using a cmd window (started with "Run As Administrator), you can try:

C:\> rpcdump /I

shows you all...

C:\>rpcdump /p ncacn_http
Querying Endpoint Mapper Database...
0 registered endpoints found.

7.2 A note on Unregistered legacy COM objects:

Please be aware that we are talking about legacy COM or DCOM here. So, like the stuff created with environments like C++,
or VB, before DOT NET was getting a firm hold in development.
So, the discussion below must be viewed in that (somewhat older) context.

You know that for example a "CLSID" identifies a COM object (or "class"). So, tools like "dcomcnfg", or "mmc comexp.msc /32", or regedit,
or tools that goes with a dev environment, will show you the registered COM objects.

With "legacy" COM, objects and interfaces are supposed to be registered in the Registry.

As a side advantage, some tools from development environments like COM/OLE viewer "like" tools, can show you listings of interfaces
and all sorts of metadata. This then suggests, that you get a view on "all" objects.

Immediately, a question arise. Are there "unregistered" COM objects around on your system, and can they still be activated?
And, is that "bad" or not?

I am afraid generally quite a few "unregistered" COM objects are on most systems.

Can such objects be activated? Yes, various ways. For example smart tools can create XML files (or similar files) containing the same information
as would be registered, and in effect creating a manifest for the object. It could make them runnable.

The method above, seems to have some resemblance with DOT NET. Just use a manifest to make something selfdescribing, not using
a repository like the registry.

The opinions with respect to COM vary. "Registration-free COM" is seen as great by many, while others don't that idea at all.
It might be a problem if "Non Admin" people or processes can "just" use COM objects from e.g. powershell, or any other interface,
without the Admin sees (or knows) about any of the objects from the tools listed above.

Or, if you think the above is nonsense: what if people or processes can use unregistered objects, while never before someone with Admin rights,
registered that object (probably using some setup or installer of an application) . In such a context, it was probably never meant
that the object was ever to be used.
It might even be considered to be a way in which a non-Admin might "outsmart" an Administrator.

If you say that's "bs", then maybe you are right. I think it's not. Maybe it's just a bit of a fuzzy area.

Anyway, "Registration-free COM" was even supported by Microsoft, and several MSDN articles describe the way to implement it.
Seen from that angle: how bad can it be then?

There is no "good" or "bad" here. Legacy COM just makes it all possible. And, suppose you were not aware of it, then now you are, and that's probably good.

7.3 Configuring DCOM in Win7 / Win2K8 (R2) systems:

! Warning !:

Maybe it looks a bit exaggerated, but I don't want to be the guy who gave the wrong advise.

So, I better start with a warning here! Better not use the information presented here, as the sole basis for removing accounts.
For example, removing too much might cripple your system, or cripple applications.
It's very important to get more information, and perform a test first. The material in this note may serve as "just one" of your sources
This is so, since the discussion below also refer to "Everyone" and "Anonymous Logon" usage in COM/DCOM.

All text in this section applies to test scenario's only.

The following figures shows you typical COM/DCOM "security setting" dialog boxes in (Win7) Win2K8/Win2K8R2 systems.
Those systems are still very prominent Operating Systems, in business environments.

So, it's very wise to check your System-wide, and application specific, security settings.
Some short comments, and recommendations, will accompany figures 14-18 shown below.

The dialog boxes can be seen (Win7/Win2K8) by starting the "dcomcnfg" utility from the command prompt.
They look "harmless" but they may have a large impact on system security.

Important:

Using GPO (or policies) on the AD level is much more effective, than a "per Server approach" as seen below.
However, I just want to show and comment on the COM/DCOM dialogboxes, since that might be helpfull for understanding the procedure.


Fig. 14. Enabling/Disabling DCOM at the System level.



See fig. 14. Note that I have rightclicked the My Computer object, and choose "properties".

All controls here, are very important. These are system-wide settings.

⇒ Enable/Disable DCOM:
If your system uses DCOM, then enable it, if the system is purely on an internal network.
What DCOM is, was touched upon in section 7.1, so at least you should have a basic idea on what it is.
Note that many insist on disabeling DCOM. However, depending on the functions of your Server, some features might not work anymore,
like e.g. Replication of databases, "connectors" between applications, and many more examples are possible.
In general, a consensus seems to exist to disable it for high security requirements.

Recommendation: No recommendation is possible. Just depends on the situation.

⇒ Enable/Disable COM Internet Services:
For COM/COM+ services over the Internet, no requirements should exists for internal Servers. The "default" is off, and you should never enable this one.
If a consultant, or developer or so, advises to put in it back on, he/she should provide for a 100% valid explanation for that action.
If not 100% convinced, or if you still can't interpret the explanation, keep it "OFF" at all times.
"ON" would also activate the "tunneling" protocol as was touched in section 7.1.6. Using SSL makes it better, but it's also hard to configure such setup so that it is secure.

Recommendation: keep it "OFF".

⇒ Default Athentication Level:
This one is not easy. It's about "authentication" on the packet level. It means: are the packets originating from the client you expect it to be?
To achieve it, a number of options can be select. See the list below.
But..., what if a programmer has used an "override" for this setup? Then your "default" is gone.
However, choosing the most stringent option here is certainly advised. Ofcourse, some apps might then not work anymore.

1. Default: The authentication level is chosen as to be the regular COM(+) negotiation algorithm.
2. None: No authentication. Do not implement this.
3. Connect: Authenticates the client only when the client first connects to the server.
4. Call: Authenticates the client at each remote call.
5. Packet: Authenticates client, and verifies that all data received is from this client.
6. Packet Integrity: Authenticates client, verifies that all data received is from this client, and not modified.
7. Packet Privacy: As above, and encryption on.

Recommendation for Testing: Choose the best level, that is: 7 or 6 or 5. Never choose 2.

Please note the word "Testing" in the above recommendation.

⇒ Default Impersonation Level:
"Impersonation" means that the Server (who gets request from the client), acts "as if" it is the client when
accessing resources. But these "resources", are they local to the Server object, or remote? That makes a difference as well.
See the following list for the options to choose from.

1. Default: The impersonation level is chosen as to be the regular COM(+) negotiation algorithm.
2. Anonymous: The client is anonymous. The Server object will not act "as if" it is the client, but as itself.
3. Identify: The server gets the client's identity. The server object uses it for ACL checking, but it cannot access resources as if it is the client.
4. Impersonate: The server gets the client's identity. It uses the client's token to access resources local to the Server's machine.
5. Delegate: The server gets the client's identity. It uses the client's token to access resources local to the Server's machine, and remote resources.

Recommendation: I think no general recommendation is possible here. It just depends on the situation.

Let's go to the next dialogbox.


Fig. 15. Access and Activation permissions at the System level.




See fig. 15. Note that I am still busy browsing the properties of the My Computer object.
So, again these concern system-wide settings, and not on a particular COM component (which can be done too).

Note too that this tab is about COM security, meaning "activation", "access" and "launch" permissions granted to users and/or groups.
It means too, that we are talking about COM objects on "this" machine.

In listings of users and groups, you can evidently remove and add users/groups.
However, it can be a bit dangerous to remove accounts which turned out to be essential. So, all text only applies for test scenarios's.

Since figure 15 is about global settings, an override is possible on setting permissions on the individual COM component level.
Actually you should have a good idea on "who" may launch any COM object, since this is a systemwide setting.

As of Win2K3 SP1, the "Distributed COM users" group is available, and this Windows group is a good choice to use
in permission lists for authenticated users. As always, you can add user accounts and Domain Groups in this special group.

Fig. 16. The "Distributed COM users" as a Local Group in Windows Servers.




=> If you see "Everyone" in listings, it looks better (safer) to remove that group.
But there could be a "catch" here if you remove it.

=> Secondly, you might even find the "Anonymous Logon" ('NT AUTHORITY\ANONYMOUS LOGON') listed.
But there could also be a very LARGE "catch" too if you remove it.

The "Everyone" group covers almost all connections (so to speak). The "Anonymous Logon" is not a member of Everyone.
The "ANONYMOUS LOGON" is sometimes a better option than Everyone. It sounds "spooky", but it's often
neccessary. Ofcourse, ideally, you would work with fully authenticated users only.
A problem might arise if programmatic objects, or services, uses the "Anonymous Logon". And they often do.
So, killing this one, is not a simple task.

A COM client application might be able launch a remote COM Server, but is unable to receive further responses
if the "anonymous logon" is removed from permission lists. Thus, the Client will be unable to continue communicating
with the Server application.

Note:
You could even use the "Anonymous Logon" in almost all ACL's, as of for example NTFS, and even in COM.

Recommendations for Testing:
1. For normal accounts, consider using "Distributed COM users".
2. You might try removing "Everyone" in a test environment, but chances are that apps do not work anymore.

Please note the word "test" in the above recommendations.

Catches:

1. The "System" account is member of "Everyone" too. Implicitly, COM classes might be activated using the System account.
But you can add System seperately in permission listings.

2. The "Anonymous Logon" is used for COM messaging. This could pose a problem too, if you remove it.
You need more information before touching this one.


Although certainly not satisfactory, I hope that this section was usefull anyway.

Section 8. Some notes on .NET / WinRT Security

Section 9. A short study on the Win Architecture, and a few well known exploits on Windows