AlienVault R&D Labs Portal. Get the latest news from our research.
Header

Exploring Windows Objects ACL’s

December 29th, 2009 | Posted by jaime.blasco in Windows - (Comments Off)

In the last post, we talked about mutex objects and how to enumerate them. Today we’ll learn how to check mutex access lists from WinDBG as well as from user-mode extending the EnumerateMutex example.

Let’s see an example using WinDBG. First query the “\BaseNamedObjects” directory that usually contains mutex objects:

lkd> !object \BaseNamedObjects
Object: e18ce788  Type: (823ed418) Directory
    ObjectHeader: e18ce770 (old version)
    HandleCount: 71  PointerCount: 593
    Directory Object: e1001150  Name: BaseNamedObjects

    Hash Address  Type          Name
    ---- -------  ----          ----
     00  e15a8880 SymbolicLink  Local
         81e996d0 Event         userenv: Machine Group Policy has been applied
         82286598 Mutant        SHIMLIB_LOG_MUTEX
         82308700 Mutant        ZonesCacheCounterMutex
         e1dfe298 Section       CTF.AsmListCache.FMPDefaultS-1-5-21-507921405-412668190-839522115-500
         817e3ea0 Timer         userenv: refresh timer for 1048:768
         e1f12ed8 Section       MSCTF.MarshalInterface.FileMap.MPJ.DI.HDGDJDJ
         813f90d0 Event         CorDBIPCLSEventReadName_5752
         e25994a8 Section       Cor_Private_IPCBlock_4760
         e2319518 Section       Cor_Private_IPCBlock_4448
         e1fc1818 Section       MSCTF.MarshalInterface.FileMap.ILD.FOB.FNOEBJE
         8231e468 Event         userenv: machine policy force refresh event
         82196f50 Event         jjCSCSessEvent_UM_KM_0
         82111148 Event         AgentToWkssvcEvent

Now query one of them:

lkd> !object \BaseNamedObjects\SHIMLIB_LOG_MUTEX
Object: 82286598  Type: (823c55e0) Mutant
    ObjectHeader: 82286580 (old version)
    HandleCount: 8  PointerCount: 9
    Directory Object: e18ce788  Name: SHIMLIB_LOG_MUTEX

And query the object header at 82286580:

lkd> dt nt!_OBJECT_HEADER  82286580
   +0x000 PointerCount     : 9
   +0x004 HandleCount      : 8
   +0x004 NextToFree       : 0x00000008
   +0x008 Type             : 0x823c55e0 _OBJECT_TYPE
   +0x00c NameInfoOffset   : 0x10 ''
   +0x00d HandleInfoOffset : 0 ''
   +0x00e QuotaInfoOffset  : 0 ''
   +0x00f Flags            : 0x20 ' '
   +0x010 ObjectCreateInfo : 0x8055a000 _OBJECT_CREATE_INFORMATION
   +0x010 QuotaBlockCharged : 0x8055a000
   +0x014 SecurityDescriptor : 0xe1756a7e
   +0x018 Body             : _QUAD

The security descriptor is at 0xe1756a7e so, convert it:

lkd> ?? 0xe1756a7e & ~0x7
unsigned int 0xe1756a78

And then we can check the information we wanted:

lkd> !sd 0xe1756a78 0
->Revision: 0x1
->Sbz1    : 0x0
->Control : 0x8004
            SE_DACL_PRESENT
            SE_SELF_RELATIVE
->Owner   : S-1-5-32-544
->Group   : S-1-5-18
->Dacl    :
->Dacl    : ->AclRevision: 0x2
->Dacl    : ->Sbz1       : 0x0
->Dacl    : ->AclSize    : 0x44
->Dacl    : ->AceCount   : 0x2
->Dacl    : ->Sbz2       : 0x0
->Dacl    : ->Ace[0]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl    : ->Ace[0]: ->AceFlags: 0x0
->Dacl    : ->Ace[0]: ->AceSize: 0x14
->Dacl    : ->Ace[0]: ->Mask : 0x001f0001
->Dacl    : ->Ace[0]: ->SID: S-1-5-18

->Dacl    : ->Ace[1]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl    : ->Ace[1]: ->AceFlags: 0x0
->Dacl    : ->Ace[1]: ->AceSize: 0x18
->Dacl    : ->Ace[1]: ->Mask : 0x00120001
->Dacl    : ->Ace[1]: ->SID: S-1-5-32-544

->Sacl    :  is NULL

So now that we now how to check an object ACL via WinDBG, let’s take advantage of .NET classes inside System.Security.AccessControl namespace to query objects ACL’s.

We can query a previously created mutex object via Mutex.OpenExisting method:

[SecurityPermissionAttribute(SecurityAction.LinkDemand, Flags = SecurityPermissionFlag.UnmanagedCode)]
public static Mutex OpenExisting(
    string name,
    MutexRights rights
)

We’ll use MutexRights.ReadPermissions to be able to read ACL information and then call Mutex.GetAccessControl to read access control information.

Here is the EnumerateMutex example extended to print ACL information from mutexs inside object directories:

(Tested on Windows XP SP2 and Windows 7)

Example:

This method can be useful to identify weak ACL’s that can lead to a local Denial of Service. Example Winsock Mutex Vulnerability

jaime.blasco

At AlienVault Jaime manages the Lab and runs the Vulnerability Research Team. Prior to working in the AlienVault lab he founded a couple of startups (Eazel, Aitsec) working on web application security, source code analysis and incident response. His background stems from a number of years working in vulnerability management, malware analysis and security researching.

More Posts - Website

Follow Me:
TwitterLinkedIn

, , , , , ,

Malware: Exploring mutex objects

December 28th, 2009 | Posted by jaime.blasco in Code | Malware | Windows - (1 Comments)

A mutex, also called a lock is a program object commonly used to avoid simultaneous access to a resource, such a variable.

It’s used in concurrent programming to allow multiple program threads to share the same resource.

Mutexs are usually used by malware creators to avoid the infection of a system by different instances of the same malware.
When the trojan infects a system, the first step is to obtain a handle to a “named” mutex, if the process fails, then the malware exits.

The easiest way to check for the presence of a Mutex is using the CreateMutex Function

HANDLE WINAPI CreateMutex(
	__in_opt  LPSECURITY_ATTRIBUTES lpMutexAttributes,   
	__in      BOOL bInitialOwner,   __in_opt  LPCTSTR lpName );

This is the same function that malware uses for checking if the system is infected so one approach to detect the presence of a piece of malware is trying to obtain a handle to the created mutex.

Here is a list of some malwares (md5′s) and the Mutex created:

60f733d6d0b077e4a668fb49aab44a30, xx464dg433xx16
fb663100308285afb4debdcab8d67fe2, 6E523163793968624
47c6313ec393d0c55d57529e2a9a418d, Security Tool
72631c3c853d706daf1153b3c8fea54f, psec_once
c37f47c9071eed101a67532e5d412171, YMING
cdcd59a5fb80808cad7376c001586c6e, 290541776
6013de3fed84d40bb173ec23f408a67e, mymutsglwork
62a3f867becfea136aea4ec83a4d9c44, 5BB0650C
5f33aa0b5660bc932af969301635d818, XGBPPAQHSE
2e40abf579e4d8d5d1ba7df34d5e507a, _!SHMSFTHISTORY!_

I’ve uploaded a small piece of code in .NET (console) using PInvoke that takes the name of the mutex to check for.

(Tested on Windows XP SP2 and Windows 7)

Example:

You can use this small application to quickly check if a system is compromised if you know the name of the mutex created by the malware.

In the previous post, we talked about the Windows Kernel Objects as well as the “Object directories”.
We learnt how to query a directory using WinDBG and we found that Mutex as well as other kernel objects are present inside directories.

So now I will explain how to query object directories from user land via NtQueryDirectoryObject to list mutexs present in the system.

We will use the functions NtOpenDirectoryObject and NtQueryDirectoryObject

NTSTATUS WINAPI NtOpenDirectoryObject(   
	__out  PHANDLE DirectoryHandle,   
	__in   ACCESS_MASK DesiredAccess,   
	__in   POBJECT_ATTRIBUTES ObjectAttributes );
NTSTATUS WINAPI NtQueryDirectoryObject(
	   __in       HANDLE DirectoryHandle,   
	   __out_opt  PVOID Buffer,   
	   __in       ULONG Length,   
	   __in       BOOLEAN ReturnSingleEntry,  
	   __in       BOOLEAN RestartScan,   
	   __inout    PULONG Context,   
	   __out_opt  PULONG ReturnLength );

So the best approach to enumerate the Mutex objects is to traverse all the directories beginning with the root directory (“”\\”") and check for “Mutex objects” inside the directory.
We have to take into account that a directory may contains another directory so we have to traverse all of them.

Here is another piece of code to enumerate all the mutex present in the system:

(Tested on Windows XP SP2 and Windows 7)

Example:

Remember that Windows Objects belongs to a namespace and each user session has a different namespace so you will retrieve different results from different user sessions.

I was looking at some mutex results an then I found these:

0x16F:Mutant                   VMwareGuestDnDDataMutex
0x170:Mutant                   VMwareGuestCopyPasteMutex

I think is another interesting trick to detect the presence of a system running inside Vmware.
Searching the Internet I found this report from ThreatExpert about a malware called W32.Neshuta that creates exactly the previous two mutexs.
So the question is if the malware checks for the presence of Vmware with this technique (I bet you a beer) or it uses the same mutants to hide and deceive computer users.

 

jaime.blasco

At AlienVault Jaime manages the Lab and runs the Vulnerability Research Team. Prior to working in the AlienVault lab he founded a couple of startups (Eazel, Aitsec) working on web application security, source code analysis and incident response. His background stems from a number of years working in vulnerability management, malware analysis and security researching.

More Posts - Website

Follow Me:
TwitterLinkedIn

, , , , , , ,