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

, , , , , , ,

Windows Kernel Objects

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

The Windows Kernel offers different resources to developers: Process, Socket, Thread, Mutex…

A kernel object is a memory block which structure has different members containing information about the object.
There are common members across all object types (like security descriptor) but each object type has its own specific members (like ID of a Process object).

Let’s begin playing with WinDbg that can be used to debug windows in kernel mode.

The best way to retrieve the list of kernel objects is to query the ObjectTypes directory:

lkd> !object \ObjectTypes
Object: e1000110  Type: (823ed418) Directory
    ObjectHeader: e10000f8 (old version)
    HandleCount: 0  PointerCount: 25
    Directory Object: e1001150  Name: ObjectTypes

    Hash Address  Type          Name
    ---- -------  ----          ----
     00  823ed418 Type          Directory
     01  823c8ca0 Type          Thread
         823c55e0 Type          Mutant
     03  82335770 Type          FilterCommunicationPort
     05  823b4958 Type          Controller
     07  823ed5e8 Type          Type
         823c4ca0 Type          Profile
         823c5980 Type          Event
     09  823ed248 Type          SymbolicLink
         823c4560 Type          Section
         823c57b0 Type          EventPair
     10  823c4730 Type          Desktop
     11  823c4e70 Type          Timer
     12  823c4900 Type          WindowStation
         823eb040 Type          File
     16  823b45b8 Type          Driver
     18  823ae250 Type          WmiGuid
         823c4ad0 Type          KeyedEvent
     19  823c8040 Type          Token
         823b4788 Type          Device
     20  823c8408 Type          DebugObject
     21  823b43e8 Type          IoCompletion
     22  823c8e70 Type          Process
     24  823b4b28 Type          Adapter
     26  823c18a0 Type          Key
     28  823c8ad0 Type          Job
     31  823ec3d0 Type          WaitablePort
         823ec5a0 Type          Port
     32  823c5410 Type          Callback
     33  82335940 Type          FilterConnectionPort
     34  823c4040 Type          Semaphore

Then we have a list with all the available object types managed by the Kernel.

We can get more info about an object type querying its address:

lkd> dt _OBJECT_TYPE 823c4900 
ntdll!_OBJECT_TYPE
   +0x000 Mutex            : _ERESOURCE
   +0x038 TypeList         : _LIST_ENTRY [ 0x823c4938 - 0x823c4938 ]
   +0x040 Name             : _UNICODE_STRING "WindowStation"
   +0x048 DefaultObject    : (null) 
   +0x04c Index            : 0x11
   +0x050 TotalNumberOfObjects : 5
   +0x054 TotalNumberOfHandles : 0x76
   +0x058 HighWaterNumberOfObjects : 5
   +0x05c HighWaterNumberOfHandles : 0x80
   +0x060 TypeInfo         : _OBJECT_TYPE_INITIALIZER
   +0x0ac Key              : 0x646e6957
   +0x0b0 ObjectLocks      : [4] _ERESOURCE

And ever more information:

lkd> dt _OBJECT_TYPE_INITIALIZER 823c55e0 
ntdll!_OBJECT_TYPE_INITIALIZER
   +0x000 Length           : 0x5690
   +0x002 UseDefaultObject : 0x3c '<'
   +0x003 CaseInsensitive  : 0x82 ''
   +0x004 InvalidAttributes : 0x823c5908
   +0x008 GenericMapping   : _GENERIC_MAPPING
   +0x018 ValidAccessMask  : 0
   +0x01c SecurityRequired : 0 ''
   +0x01d MaintainHandleCount : 0 ''
   +0x01e MaintainTypeList : 0 ''
   +0x020 PoolType         : 0 ( NonPagedPool )
   +0x024 DefaultPagedPoolCharge : 0
   +0x028 DefaultNonPagedPoolCharge : 0
   +0x02c DumpProcedure    : (null) 
   +0x030 OpenProcedure    : (null) 
   +0x034 CloseProcedure   : (null) 
   +0x038 DeleteProcedure  : 0x823c5618     void  +ffffffff823c5618
   +0x03c ParseProcedure   : 0x823c5618     long  +ffffffff823c5618
   +0x040 SecurityProcedure : 0x000e000c     long  +e000c
   +0x044 QueryNameProcedure : 0xe1005498     long  +ffffffffe1005498
   +0x048 OkayToCloseProcedure : (null)

All the kernel objects are managed by the object manager which manage all the resources: kernel data structures, kernel references, user references, synchronization…

The Windows Kernel provides “Object directories” to categorize objects being managed according to the types. For example we previously queried the ObjectTypes directory to retrieve the list of object types.

Another example, query the \Drivers directory to get the list of drivers present on the system:

lkd> !object \Driver
Object: e1023908  Type: (823ed418) Directory
    ObjectHeader: e10238f0 (old version)
    HandleCount: 0  PointerCount: 96
    Directory Object: e1001150  Name: Driver

    Hash Address  Type          Name
    ---- -------  ----          ----
     00  823343b0 Driver        NDIS
         82335340 Driver        KSecDD
         82171320 Driver        Beep
     01  8217ef38 Driver        Raspti
         82233260 Driver        Mouclass
         8217dd68 Driver        es1371
     02  82060030 Driver        vmx_svga
...
...

In the next post I will explain the way to query object directories from user land via NtQueryDirectoryObject [Ntdll.dll] and take advantage of it for incident response and malware detection.

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

, , , ,