[+]Jaką funkcjonalność posiada LapSec?
Myślę, że sporo można wyczytać z powyższego screen’a . Jeśli jednak, ktoś życzy sobie czytelniejszą listę dostępnych opcji,
zapraszam na stronę poświęconą LapSec’owi -> LapSec Laptop Securer.

[+]Czy LapSec posiada więcej opcji niż te widoczne na screen’e?
Binarka LapSec.exe nie, ale wraz z LapSec’emi instalowany jest SecDel, który z menu kontekstowego

pozwala na bezpieczne usunięcie pliku. Co to znaczy ? Tzn, że założeniem tej aplikacji jest jak najskuteczniejsze nadpisanie danych powiązanych z konkretnym pliki w celu uniemożliwienie ich przywrócenia przez aplikacje do odzyskiwania danych.

[+]Dla kogo jest ten tool?
Naprawdę trudno jest mi to powiedzieć . I z chęcią usłyszę jakie są wasze odczucia w tej kwestii.

Hymm to chyba na tyle . Czekamy na wasze opinie, propozycje, uwagi i słowa krytyki .

LapSec setup.exe
md5: 042b3dde2f0674d0dc57b1ea1ac082f3
sha1: 0b376e42e77698e6294b772601ff85e5061730af
Więcej info: Laptop Securer

[+]Lokalizacja problemu
Jeśli jakiś plik nie może zostać usunięty w standardowy sposób, gmer stara się zamknąć wszystkie otwarte handlery odwołujące się do tego pliku, a następnie go usunąć. Moim zdaniem, niestety implementacja tej procedury przez twórcę gmer’a nie została do końca dobrze przemyślana.
Rzućmy okiem na tą prockę:

.text:0001B488 ; int __stdcall sub_1B488(wchar_t *filePath, int a2)
.text:0001B488 sub_1B488       proc near               ; CODE XREF: sub_1CB32+299 p
.text:0001B488
.text:0001B488 PFILE_OBJECT    = dword ptr -30h
.text:0001B488 var_2C          = dword ptr -2Ch
.text:0001B488 var_28          = dword ptr -28h
.text:0001B488 PSYSTEM_HANDLE_INFORMATION= dword ptr -24h
.text:0001B488 pEPROCESS       = dword ptr -20h
.text:0001B488 index           = dword ptr -1Ch
.text:0001B488 ms_exc          = CPPEH_RECORD ptr -18h
.text:0001B488 filePath        = dword ptr  8
.text:0001B488 a2              = dword ptr  0Ch
.text:0001B488
.text:0001B488                 push    20h
.text:0001B48A                 push    offset stru_1EED0
.text:0001B48F                 call    __SEH_prolog
.text:0001B494                 xor     esi, esi
.text:0001B496                 mov     [ebp+pEPROCESS], esi
.text:0001B499                 lea     eax, [ebp+var_28]
.text:0001B49C                 push    eax             ; int
.text:0001B49D                 push    10h             ; SystemHandleInformation
.text:0001B49F                 call    wrap_NtQuerySystemInformation
.text:0001B4A4                 mov     [ebp+PSYSTEM_HANDLE_INFORMATION], eax
.text:0001B4A7                 cmp     eax, esi
.text:0001B4A9                 jz      error
.text:0001B4AF                 mov     [ebp+ms_exc.disabled], esi
.text:0001B4B2                 mov     [ebp+index], esi
.text:0001B4B5                 mov     ebx, ds:NtClose
.text:0001B4BB
.text:0001B4BB loc_1B4BB:                              ; CODE XREF: sub_1B488+119 j
.text:0001B4BB                 mov     ecx, [ebp+index]
.text:0001B4BE                 cmp     ecx, [eax]      ; eax = NumberOfHandles
.text:0001B4C0                 jnb     end_of_SYSTEM_HANDLE_INFORMATION
.text:0001B4C6                 shl     ecx, 4
.text:0001B4C9                 lea     edi, [ecx+eax+4]
.text:0001B4CD                 mov     [ebp+var_2C], edi
.text:0001B4D0                 mov     esi, [edi+8]
.text:0001B4D3                 mov     [ebp+PFILE_OBJECT], esi
.text:0001B4D6                 test    esi, esi
.text:0001B4D8                 jz      next_struct
.text:0001B4DE                 push    esi             ; VirtualAddress
.text:0001B4DF                 call    ds:MmIsAddressValid
.text:0001B4E5                 test    al, al
.text:0001B4E7                 jz      next_struct
.text:0001B4ED                 cmp     word ptr [esi], 5
.text:0001B4F1                 jnz     next_struct
.text:0001B4F7                 mov     eax, [esi+34h]
.text:0001B4FA                 test    eax, eax
.text:0001B4FC                 jz      next_struct
.text:0001B502                 push    eax             ; VirtualAddress
.text:0001B503                 call    ds:MmIsAddressValid
.text:0001B509                 test    al, al
.text:0001B50B                 jz      next_struct
.text:0001B511                 push    [ebp+filePath]  ; VirtualAddress
.text:0001B514                 call    ds:MmIsAddressValid
.text:0001B51A                 test    al, al
.text:0001B51C                 jz      short next_struct
.text:0001B51E                 push    [ebp+filePath]  ; wchar_t *
.text:0001B521                 call    ds:wcslen
.text:0001B527                 pop     ecx
.text:0001B528                 sub     eax, 6
.text:0001B52B                 mov     [ebp+a2], eax
.text:0001B52E                 movzx   ecx, word ptr [esi+30h] ; fileObject->FileName.Length
.text:0001B532                 shr     ecx, 1
.text:0001B534                 cmp     ecx, eax
.text:0001B536                 jnz     short next_struct
.text:0001B538                 push    eax             ; size_t
.text:0001B539                 mov     eax, [ebp+filePath]
.text:0001B53C                 add     eax, 0Ch
.text:0001B53F                 push    eax             ; wchar_t *
.text:0001B540                 push    dword ptr [esi+34h] ; fileObject->FileName.Buffer
.text:0001B543                 call    ds:_wcsnicmp
.text:0001B549                 add     esp, 0Ch
.text:0001B54C                 test    eax, eax
.text:0001B54E                 jnz     short next_struct
.text:0001B550                 lea     eax, [ebp+pEPROCESS]
.text:0001B553                 push    eax
.text:0001B554                 push    dword ptr [edi]
.text:0001B556                 call    ds:PsLookupProcessByProcessId
.text:0001B55C                 mov     status, eax
.text:0001B561                 test    eax, eax
.text:0001B563                 jnz     short next_struct
.text:0001B565                 mov     eax, [ebp+pEPROCESS]
.text:0001B568                 cmp     eax, current_process_EPROCESS
.text:0001B56E                 jz      short handleBelongsToCurrentProcess
.text:0001B570                 push    eax
.text:0001B571                 call    ds:KeAttachProcess
.text:0001B577                 movzx   eax, word ptr [edi+6]
.text:0001B57B                 push    eax             ; Handle
.text:0001B57C                 call    ebx ; NtClose
.text:0001B57E                 mov     status, eax
.text:0001B583                 call    ds:KeDetachProcess
.text:0001B589                 jmp     short loc_1B592
.text:0001B58B ; ---------------------------------------------------------------------------
.text:0001B58B
.text:0001B58B handleBelongsToCurrentProcess:          ; CODE XREF: sub_1B488+E6 j
.text:0001B58B                 movzx   eax, word ptr [edi+6]
.text:0001B58F                 push    eax             ; Handle
.text:0001B590                 call    ebx ; NtClose
.text:0001B592
.text:0001B592 loc_1B592:                              ; CODE XREF: sub_1B488+101 j
.text:0001B592                 mov     ecx, [ebp+pEPROCESS] ; Object
.text:0001B595                 call    ds:ObfDereferenceObject
.text:0001B59B
.text:0001B59B next_struct:                            ; CODE XREF: sub_1B488+50 j
.text:0001B59B                                         ; sub_1B488+5F j ...
.text:0001B59B                 inc     [ebp+index]
.text:0001B59E                 mov     eax, [ebp+PSYSTEM_HANDLE_INFORMATION]
.text:0001B5A1                 jmp     loc_1B4BB
.text:0001B5A6 ; ---------------------------------------------------------------------------
.text:0001B5A6
.text:0001B5A6 _end:                                   ; DATA XREF: .rdata:stru_1EED0 o
.text:0001B5A6                 xor     eax, eax
.text:0001B5A8                 inc     eax
.text:0001B5A9                 retn

Gdzie tu jest problem?
Przyjrzyjmy się samej kwesti odnalezienia przez gmer’a uchwytu, który jest powiązany z plikiem do którego handlery chcemy pozamykać. Autor gmer’a postanowił tutaj skorzystać z dostarczonego w strukturze SYSTEM_HANDLE_INFORMATION FILE_OBJECT’u i slusznie,no ale…

Sprawdzenie rozpoczyna się od zbadania długości scieżki podanej jako argument i tej zawartej w file object’e.

.text:0001B51E                 push    [ebp+filePath]  ; wchar_t *
.text:0001B521                 call    ds:wcslen
.text:0001B527                 pop     ecx
.text:0001B528                 sub     eax, 6
.text:0001B52B                 mov     [ebp+a2], eax
.text:0001B52E                 movzx   ecx, word ptr [esi+30h] ; fileObject->FileName.Length
.text:0001B532                 shr     ecx, 1
.text:0001B534                 cmp     ecx, eax
.text:0001B536                 jnz     short next_struct

Jeśli długości są identyczne przechodzimy do następnego testu. Zanim jednak przejde dalej odczuwam wielką potrzebe czepienia się jednej kwestii związaną z dobrymi praktykami jak i optymalizacją kodu.
Chodzi dokładnie o ten fragment:

.text:0001B51E                 push    [ebp+filePath]  ; wchar_t *
.text:0001B521                 call    ds:wcslen

Ten fragment znajduję się wewnątrz pętli i przy każdej iteracji, kiedy obiektem okazuje się plik, wywoływana jest zupełnie bez sensownie funkcja wcslen na zmiennej filePath, która została podana jako parametr do sub_1B488!!! Takie wielokrotne wyliczanie tej samej wartości wewnątrz pętli prowadzi do niczego innego niż zmniejszenia wydajności kodu, a w tym przypadku wydajność będzie mala wręcz wprost proporcjonalnie do długości stringu. Także, nie polecam takich konstrukcji (btw: jak zobaczyłem ten twór to przypomniał mi się post Malcom’a „Programowanie wymaga myślenia!” , polecam).

Kontynuujmy:

.text:0001B538                 push    eax             ; length
.text:0001B539                 mov     eax, [ebp+filePath]
.text:0001B53C                 add     eax, 0Ch
.text:0001B53F                 push    eax             ; wchar_t *
.text:0001B540                 push    dword ptr [esi+34h] ; fileObject->FileName.Buffer
.text:0001B543                 call    ds:_wcsnicmp

Tutaj dokonywane jest już porównanie stringów reprezentujących ścieżki do plików.
Ale, ale !!! Nie jest to porównanie zawierające litery partycji, na której dany plik się znajduje!!!
Ścieżki mają tu postać:
„\folder\file.ext”

Tylko i wyłącznie takie porównanie doprowadza do sytuacji, w której handler powiązany z plikiem o takiej samej ścieżce jak ścieżka podana jako parametr funkcji, lecz znajdujący się na innej partycji zostanie zamknięty!!!

[+]Przykład
Na potrzeby testów stworzyłem niewielką aplikację, która otwiera handler do pliku bez praw do usunięcia( bez FILE_SHARE_DELETE, w celu zmuszenia gmer’a do wywołania powyżej omawianej procki). Kod tej aplikacji jest następujący:

int main(int argc, char* argv[])
{

	HANDLE h = CreateFileA(argv[1],
				GENERIC_READ,
				FILE_SHARE_READ | FILE_SHARE_WRITE,
				0,
				OPEN_EXISTING,
				FILE_ATTRIBUTE_NORMAL,
				0);
	if(h == INVALID_HANDLE_VALUE)
	{
		cout<<[+]INVALID_HANDLE_VALUE;
		return 0;
	}
	cout<<[+]File opened!<<endl;
	getchar();
}

oraz narzędzia Handle v3.42, do wylistowania wszystkich otwartych handlerów przez dany proces. Na dwóch konsolach odpaliłem swój kod skompilowany do pliku zlo.exe z następującymi parametrami:

Console_1:
zlo.exe C:\install.exe

oraz

Console_2:
zlo.exe E:\install.exe

Po odpaleniu aplikacji wylistowałem otwarte przez nie handler:

// Przed proba usuniecia C:\install.exe [+]
c:\Documents and Settings\virtual>handle.exe -p zlo.exe

Handle v3.42
Copyright (C) 1997-2008 Mark Russinovich
Sysinternals - www.sysinternals.com

------------------------------------------------------------------------------
zlo.exe pid: 1928 SLAVE\virtual
    C: File  (RW-)   C:\Documents and Settings\virtual
  7E8: File  (RW-)
C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_d08d0375
  7F4: File  (RW-)   C:\install.exe
------------------------------------------------------------------------------
zlo.exe pid: 932 SLAVE\virtual
    C: File  (RW-)   C:\Documents and Settings\virtual
  7E8: File  (RW-)
C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_d08d0375
  7F4: File  (RW-)   E:\install.exe

Następnie przy pomocy gmer’a usunąłem plik C:\install.exe i ponownie wylistowałem handlery:

//Po usunieciu przez gmer'a C:\install.exe
c:\Documents and Settings\virtual>handle.exe -p zlo.exe

Handle v3.42
Copyright (C) 1997-2008 Mark Russinovich
Sysinternals - www.sysinternals.com

------------------------------------------------------------------------------
zlo.exe pid: 1928 SLAVE\virtual
    C: File  (RW-)   C:\Documents and Settings\virtual
  7E8: File  (RW-)
C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_d08d0375
------------------------------------------------------------------------------
zlo.exe pid: 932 SLAVE\virtual
    C: File  (RW-)   C:\Documents and Settings\virtual
  7E8: File  (RW-)
C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_d08d0375

Efekt potwierdził moją teorie, tak jak widać uchwyt do E:\install.exe również został zamknięty.

[+]Rada
Dodanie pełnego badania ścieżek do plików m.in z wykorzystaniem np. IoQueryFileDosDeviceName.

No i chyba tyle;)

1. Zabicie procesu malware’u i próba usunięcia jego pliku wykonywalnego jest utrudniona z tego względu, że innym proces wciąż odnawia proces naszych zainteresowań.

3.Usuniecie pliku nie jest możliwe ze względów na hooki , czy to na poziomie r3 czy r0, które chronią wybrane pliki malware’u.

Poniżej przedstawię parę sposobów na radzenie sobie w takich „trudnych sytuacjach” spowodowanych przez nie do końca poprawnie działającą aplikacje lub malware.

1.

Zabicie procesu malware’u i próba usunięcia jego pliku wykonywalnego jest utrudniona z tego względu, że innym proces wciąż odnawia proces naszych zainteresowań.

Porzućmy kwestie jaką przedstawiam w tytule tego punktu i wyobraźmy sobie prostszy scenariusz o identycznym charakterze.
Załóżmy teoretyczną sytuację, że istnieje malware, który składa się dwóch modułów na potrzeby przykładu nazwane następująco:
matka.exe – „dobrze ukryty” plik w systemie, który uruchamia się przy każdym uruchomieniu komputer’a następnie tworzy zdalny wątek w jednym z procesów systemowych i stamtąd wykonuje swoje zadania. Jego jedynym zadaniem jest uruchamianie modułu zle_dziecko.exe oraz monitorowanie jego stanu. W przypadku kiedy, proces zle_dziecko.exe zostanie zabity ukryty gdzieś w czeluściach systemu wątek matki tworzy jego nowy proces.

zle_dziecko.exe – moduł posiadający najważniejsza funkcjonalność keyloggingu,itp uruchamiany i utrzymywany przy życiu przez moduł matka.exe.

Dodatkowo scenariusz postępowania zakłada, że naszym priorytetem jest w pierwszej kolejności pozbycie się złośliwego procesu zle_dziecko.exe ponieważ co każdą minutę wysyła on cenne skradzione dane z naszego systemu na drop host.
Niestety pojawiają się drobne problemy, ponieważ po zabiciu procesu zle_dziecko.exe jest on wciąż odnawiany, przez co „nie możliwe” staje się usunięcie jego pliku wykonywalnego ze względu na „blokady” ze strony systemu.

[+]Sposób na obejście tego przypadku:
Analizując driver filesystemu (w moim przypadku źródłem zainteresowań był NTFS[ntfs.sys]) dochodzimy do wniosków, że tak naprawdę dwa pola w FILE_OBJECT’e pliku wykonywalnego, który posiada aktywny proces mogą uniemożliwiać usunięcie powiązanego z nim pliku.

kd>dt _FILE_OBJECT [ecx]
ntdll!_FILE_OBJECT
   +0x000 Type             : 5
   +0x002 Size             : 112
   +0x004 DeviceObject     : 0x88fd1900 _DEVICE_OBJECT
   +0x008 Vpb              : 0x88fa5780 _VPB
   +0x00c FsContext        : 0xe12f33d0
   +0x010 FsContext2       : 0xe189f870
   +0x014 SectionObjectPointer : 0x88c4d964 _SECTION_OBJECT_POINTERS
   +0x018 PrivateCacheMap  : (null)
   +0x01c FinalStatus      : 0
   +0x020 RelatedFileObject : (null)
   +0x024 LockOperation    : 0 ''
   +0x025 DeletePending    : 0 ''
   +0x026 ReadAccess       : 0x1 ''
   +0x027 WriteAccess      : 0 ''
   +0x028 DeleteAccess     : 0 ''
   +0x029 SharedRead       : 0x1 ''
   +0x02a SharedWrite      : 0x1 ''
   +0x02b SharedDelete     : 0x1 ''
   +0x02c Flags            : 0x840042
   +0x030 FileName         : _UNICODE_STRING "\zle_dziecko.exe"
   +0x038 CurrentByteOffset : _LARGE_INTEGER 0x0
   +0x040 Waiters          : 0
   +0x044 Busy             : 0
   +0x048 LastLock         : (null)
   +0x04c Lock             : _KEVENT
   +0x05c Event            : _KEVENT
   +0x06c CompletionContext : (null) 

„File object dla pliku zle_dziecko.exe posiadający aktywny proces”

Czytając specyfikacje FILE_OBJECT na msdn’e:
DeleteAccess
A read-only member (nie był bym tego taki pewny ). If TRUE, the file associated with the file object has been opened for delete access. If FALSE, the file has been opened without delete access. This information is used when checking and/or setting the share access of the file.
Źródło: http://msdn.microsoft.com/en-us/library/ff545834(VS.85).aspx

I bardzo ważna informacja znajdująca się na dole strony:

During the processing of an IRP_MJ_CREATE request, a file system driver calls the IoSetShareAccess routine (if the client is the first to open the file) or the IoCheckShareAccess routine (for subsequent clients that want to share the file). IoSetShareAccess and IoCheckShareAccess update the ReadAccess, WriteAccess, and DeleteAccess members to indicate the access rights that are granted to the client if the client has exclusive access to the file.
Źródło: http://msdn.microsoft.com/en-us/library/ff545834(VS.85).aspx

Ważną wskazówką tutaj dla nas jest to, iż sprawdzenie flagi DeleteAccess odbywa się podczas przetwarzania zapytania IRP_MJ_CREATE przez driver( już teraz dopowiem, że zapytanie to jest wysyłane również podczas usuwania pliku, a procedura obsługująca je w NTFS’e nazywa sie NtfsFsdCreate) w funkcji IoCheckShareAccess i tam należy badać jej wpływ na dalszy przebieg operacji usuwania.
Oczywiści z badań wynikło, że ustawienie tej flagi na TRUE pozwala przejść check w IoCheckShareAccess pozytywnie.

SectionObjectPointer :_SECTION_OBJECT_POINTERS
w tej strukturze interesuje nas tak naprawdę jeden wskaźnik

ImageSectionObject : PVOID
Opaque pointer to an image section object (that is, a CONTROL_AREA structure) that is used to track state information for an executable file stream. Memory manager sets this member whenever an executable image section is created for the stream. A NULL value indicates that the executable image is currently not in memory; this value, however, can change at any time.
Źródło: http://msdn.microsoft.com/en-us/library/ff563687(VS.85).aspx

W skrócie, pointer ten ma wartość NULL wtedy, gdy plik wykonywalny nie jest załadowany do pamięci(nie posiada aktywnego procesu). W innym przypadku pointer ten jest ustawiony, a próba skasowania pliku wykonywalnego kończy się kodem błędu STATUS_SHARING_VIOLATION.

[+]Implementacja: [źródło inspiracji gmer.sys]
Żeby móc manipulować na file object’e musimy zejść w czeluści piekielne naszego OS’u , czyli ring0.
Oczywiście dokonamy tego pisząc driver, w którym przykładowa funkcja realizująca nasze zadanie będzie wyglądała tak :

NTSTATUS ForceDelete(wchar_t *path)
{

	HANDLE fileHandle;
	NTSTATUS result;
	IO_STATUS_BLOCK ioBlock;
	DEVICE_OBJECT *device_object;
	void* object = NULL;
	OBJECT_ATTRIBUTES fileObjectAttr;
	wchar_t deviceName[14];
	UNICODE_STRING uDeviceName;
	UNICODE_STRING uPath;

	//switch context to UserMode
	EPROCESS *eproc = IoGetCurrentProcess();
	KeAttachProcess(eproc);

	//e.g "\??\C:\"
	memset(deviceName,0,sizeof(deviceName));
	wcsncpy(deviceName,path,7);

	RtlInitUnicodeString(&uDeviceName,deviceName); //initialize volume name
	RtlInitUnicodeString(&uPath,path); //initialize path

	/* get volume handle */
	InitializeObjectAttributes(&fileObjectAttr,
								uDeviceName,
								OBJ_CASE_INSENSITIVE,
								NULL,
								NULL);

	result = ZwOpenFile(&fileHandle,
						SYNCHRONIZE,
						&fileObjectAttr,
						&ioBlock,
						FILE_SHARE_READ,
						FILE_SYNCHRONOUS_IO_NONALERT|FILE_DIRECTORY_FILE);

	if(result != STATUS_SUCCESS)
	{
		DbgPrint("Some problems with open file ;[");
		goto _end;
	}

    if ( !ObReferenceObjectByHandle(fileHandle, 0, 0, 0, &object, 0) )
    {

      device_object = IoGetBaseFileSystemDeviceObject(object); //get the lowest-level file system volume device object associated with a file
      ObfDereferenceObject(object);
    }

    ZwClose(fileHandle);	

	InitializeObjectAttributes(&fileObjectAttr,
							   &uPath,
							   OBJ_CASE_INSENSITIVE,
							   NULL,
							   NULL);

	result = IoCreateFileSpecifyDeviceObjectHint(
			   &ileHandle,
			   SYNCHRONIZE | FILE_WRITE_ATTRIBUTES | FILE_READ_ATTRIBUTES | FILE_READ_DATA,
			   &fileObjectAttr,
			   &ioBlock,
			   0,
			   0,
			   FILE_SHARE_READ | FILE_SHARE_WRITE |FILE_SHARE_DELETE,
			   FILE_OPEN,
			   FILE_NON_DIRECTORY_FILE | FILE_SYNCHRONOUS_IO_NONALERT,
			   0,
			   0,
			   CreateFileTypeNone,
			   0,
			   IO_IGNORE_SHARE_ACCESS_CHECK,
			   device_object);
	if(result != STATUS_SUCCESS)
	{
		DbgPrint("error in IoCreateFileSpecifyDeviceObjectHint");
		goto _end;
	}

	result = ObReferenceObjectByHandle(fileHandle, 0, 0, 0, &object, 0);

	if(result != STATUS_SUCCESS)
	{
		DbgPrint("error in ObReferenceObjectByHandle");
		ZwClose(fileHandle);
		goto _end;
	}
	/* set up proper FILE_OBJECT members  to allow file delete */
	((FILE_OBJECT*)object)->SectionObjectPointer->ImageSectionObject = 0; //.exe file is not in memory
	((FILE_OBJECT*)object)->DeleteAccess = 1; //we have access to delete file (.exe file doesn't have active process)

	 /*Try of file deletion*/
	 result = ZwDeleteFile(&fileObjectAttr);

	if(result != STATUS_SUCCESS)
	{
		DbgPrint("\nerror in ZwDeleteFile");
	}
	ObDereferenceObject(object);
	ZwClose(fileHandle);

_end:
	//return to r0
	KeDetachProcess();
	return result;
}

Myślę, że małe wyjaśnienia przydadzą się w następujących linijkach:

device_object = IoGetBaseFileSystemDeviceObject(object); //get the lowest-level file system volume device object associated with a file

pobieramy najniżej położony na stosie device_object związany z naszym plikiem, po to by później w:

IoCreateFileSpecifyDeviceObjectHint(
(...)
device_object);

DeviceObject [in, optional]

A pointer to the device object to which the create request is to be sent. The device object must be a filter or file system device object in the file system driver stack for the volume on which the file or directory resides. This parameter is optional and can be NULL. If this parameter is NULL, the request will be sent to the device object at the top of the driver stack.
Żródło: http://msdn.microsoft.com/en-us/library/ff548289(VS.85).aspx
gdzie nasz device object przedstawia się następująco:

//88f8b020 == device_object
kd>; !devobj 88f8b020
Device object (88f8b020) is for:
  \FileSystem\Ntfs DriverObject 88f733d0
Current Irp 00000000 RefCount 0 Type 00000008 Flags 00000000
DevExt 88f8b0d8 DevObjExt 88f8b880
ExtensionFlags (0000000000)
AttachedDevice (Upper) 88fc4b30 \FileSystem\sr
Device queue is not busy.

kd< !devstack 88f8b020
  !DevObj   !DrvObj            !DevExt   ObjectName
  88fc4b30  \FileSystem\sr     88fc4be8
>88f8b020  \FileSystem\Ntfs   88f8b0d8

Myślę, że cały sens użycia tego api wyjaśnia jego opis:

The IoCreateFileSpecifyDeviceObjectHint routine is used by file system filter drivers to send a create request only to the filters below a specified device object and to the file system.

Co dzięki temu zyskujemy? Większą pewność, że nasze zapytanie nie zostanie po drodze zmodyfikowane przez sterownik rootkit’a podpiętego pod stos urządzeń powiązanych z file systemem.

2.

Wiele aplikacji/malware posiada otwarte handler’y do pliku z takimi uprawnieniami (brak FILE_SHARE_DELETE) , które uniemożliwiają jego usunięcie.

W tym przypadku nasz trick z ustawieniem odpowiednich flag dla FILE_OBJECT’u niestety nie zda egzaminu, ze względu na to, że file system w swoich wewnętrznych strukturach utrzymuje np.ReferenceCount dla takiego pliku i nie pozwoli na jego usunięcie, jeśli nie jest ono równe 0. Modyfikacja wewnętrznych struktur NTFS’a nie jest kwestią trywialną imo ze względu na sama kontrukcje tych struktu:
Root FCB jest tworzone dla kazdego plik tylko w jednej instacji -> FCB zawiera pointer na LCB , który łączy FCB z SCB, gdzie może występować wiele SCB posiadających wiele dzieci typu FCB,a do tego wszystkiego dochodzi jeszcze CCB tworzone w zależności od wymaganych praw na otwieramy pliku . Dorzućmy jeszcze do tego wszystkiego to, że struktury te nie są udokumentowane i myślę, że już wystarczająco zachęciłem was do ich ręcznej modyfikacji .

My podejdziemy do tego tematu w prostszy sposób, i do tego jakże logiczny, bo przecież jak pewna aplikacja ma jakiś otwarty handler do pliku i przez to tego pliku usunąć się nie da ,to co należało by zrobic? Oczywiście zamknąć jej ten uchwyt! . I tak też uczynimy.

[+]Sposób na obejście tego przypadku:
Dla tego przypadku zaproponuje dwa rozwiązania, jedno na poziomie ring 3 oraz kolejne na poziomie ring0.
Zajmijmy się w pierwszej kolejności r3.

[+]Implementacja
W potrzebie tworzenia aplikacji, która zrealizuje dla nas założone zadanie przychodzi nam api:

__kernel_entry NTSTATUS
NTAPI
NtQuerySystemInformation (
    IN SYSTEM_INFORMATION_CLASS SystemInformationClass,
    OUT PVOID SystemInformation,
    IN ULONG SystemInformationLength,
    OUT PULONG ReturnLength OPTIONAL
    );

oraz jego nieudokumentowana klasą informacji wraz z strukturami:

#define SystemHandleInformation 0x10

typedef struct _SYSTEM_HANDLE_TABLE_ENTRY_INFO {
    USHORT UniqueProcessId;
    USHORT CreatorBackTraceIndex;
    UCHAR ObjectTypeIndex;
    UCHAR HandleAttributes;
    USHORT HandleValue;
    PVOID Object;
    ULONG GrantedAccess;
} SYSTEM_HANDLE_TABLE_ENTRY_INFO, *PSYSTEM_HANDLE_TABLE_ENTRY_INFO;

typedef struct _SYSTEM_HANDLE_INFORMATION {
    ULONG NumberOfHandles;
    SYSTEM_HANDLE_TABLE_ENTRY_INFO Handles[ 1 ];
} SYSTEM_HANDLE_INFORMATION, *PSYSTEM_HANDLE_INFORMATION;

Korzystając z jej dobrodziejstwa otrzymamy tablice zawierającą wszystkie procesy oraz uchwyty należące do tych procesów wraz z typami obiektów, z jakimi te handler’y są powiązane.
Te wszystkie informacje pozwolą nam na zlokalizowanie otwartych uchwytów do naszego pliku w każdym procesie istniejącym w systemie, dzięki czemu po przez drobne sztuczki uzyskamy możliwość ich zamknięcia, a następnie usunięcia pliku.

//funkcja główna
void fileToDelete(char *filePath)
{
	closeAllHandles(filePath);

	//after closing all handler to the file ,try to delete it
	DeleteFileA(filePath);

}

Rzućmy okien na funkcje closeAllHandles:

void closeAllHandles(char* filePath)
{
	SYSTEM_HANDLE_INFORMATION *shiTable;
	char foundPath[MAX_PATH];

	shiTable = enumerateHandles();
	for(int i = 0; i < shiTable->NumberOfHandles;i++)
	{
		if( isFile( shiTable->Handles[i].ObjectTypeIndex) )
		{
			HANDLE fileHandle = getDuplicatedHandle(shiTable->Handles[i].UniqueProcessId,
															    shiTable->Handles[i].HandleValue,
																false);
				if(!fileHandle)
					continue;//probably a bad handle

			if(!GetFileNameFromHandle(fileHandle,foundPath))//check whether we have been able to receive filePath
					continue;
			if( !strcmp(filePath,foundPath) )
			{
				//handle to interesting file has been found,,,let's close it
				getDuplicatedHandle(shiTable->Handles[i].UniqueProcessId,
									shiTable->Handles[i].HandleValue,
									true);
			}
		}
	}

	VirtualFree(shiTable,0,MEM_RELEASE);
}

postępując w kolejności:

SYSTEM_HANDLE_INFORMATION * enumerateHandles()
{
	SYSTEM_HANDLE_INFORMATION shi = {0};
	SYSTEM_HANDLE_INFORMATION *shiTable;
	unsigned long shiTableSize;

	int status  = NtQuerySystemInformation((SYSTEM_INFORMATION_CLASS)SystemHandleInformation,
						     &shi,
							 sizeof(SYSTEM_HANDLE_INFORMATION),
							 &shiTableSize);
	//TODO: check status
	shiTable = (SYSTEM_HANDLE_INFORMATION*)VirtualAlloc(0,shiTableSize,MEM_RESERVE|MEM_COMMIT,PAGE_READWRITE);
	status = NtQuerySystemInformation((SYSTEM_INFORMATION_CLASS)SystemHandleInformation,
									  shiTable,
									  shiTableSize,
									  0);

	return shiTable;
}

Myślę, że tutaj wszystko jest jasne, a funkcja getDuplicatedHandle będzie bardziej interesująca. Ahh
jeszcze mała funkcja isFile:

bool isFile(unsigned char type)
{
	return type == 0x1c; //for XP
}

Sprawdzamy tutaj czy element opisany przez SYSTEM_HANDLE_TABLE_ENTRY_INFO jest plikiem. Jeśli tak, to przechodzimy dalej:

HANDLE getDuplicatedHandle(unsigned long procID,unsigned long handleValue,bool closeSourceHandle)
{
	HANDLE rFile = (HANDLE)handleValue;
	HANDLE rProc;
	HANDLE duplicatedHandle;
	rProc = OpenProcess(PROCESS_DUP_HANDLE,0,procID);
	unsigned long option = closeSourceHandle?(DUPLICATE_CLOSE_SOURCE | DUPLICATE_SAME_ACCESS):DUPLICATE_SAME_ACCESS;

	DuplicateHandle(rProc,rFile,GetCurrentProcess(),&duplicatedHandle,0,0,option);
	CloseHandle(rProc);
	if(closeSourceHandle)
	{
		CloseHandle(duplicatedHandle);
		return 0;
	}

	return duplicatedHandle;
}

Do funkcji trafiają trzy parametry:

unsigned long procID      // ID procesu do którego należy handler
unsigned long handleValue // wartość handler’a
bool closeSourceHandle    // flaga, na podstawie której będzie wybierana opcja dla api DuplicateHandle

W pierwszej kolejności uzyskujemy handler do procesu, który być może, trzyma otwarty handler do interesującego nas pliku. Istotną kwestią tutaj jest flag DesiredAccess ustawiona na PROCESS_DUP_HANDLE, ponieważ zawiązana ona jest z mechanizmem, który wykorzystamy za chwilę.
Api DuplicateHandle pozwala nam na stworzenie kopi uchwytu pochodzącego z naszego procesu lub też (co jest najciekawsze) z procesu zdalnego. Bez tej możliwości wartość handler’a uzyskanego przez NtQuerySystemInformation była by dla nas bezużyteczna, ponieważ nie moglibyśmy skorzystać z niej w obrębie naszego procesu. Myślę, że co niektórym z was nasuwa się kolejna idea, a mianowicie możliwość wykorzystania zdalnych wątków. Fakt, w ten sposób również można podejść do tego tematu, jednak mi bardziej do gustu przypadło to rozwiązanie.

Opcja DuplicateHandle, która najbardziej nas tutaj interesuje to:

DUPLICATE_CLOSE_SOURCE

dzięki, której jak się domyślacie stworzymy kopie uchwytu przy jednoczesnym zamknięciu uchwyty źródłowego!;]. Oczywiście nie chcemy zamykać wszystkich uchwytów każdego procesu, dlatego też, przed sprawdzeniem, z jakim plikiem powiązany jest dany handler ustawiamy tylko opcje:

DUPLICATE_SAME_ACCESS

Po uzyskaniu klonu uchwytu wypadałoby, w jakiś sposób teraz ustalić, z jakim plikiem powiązany jest ten handler. Z pomocą przychodzi tutaj funkcja
GetFileNameFromHandle
źródło: http://msdn.microsoft.com/en-us/library/aa366789(VS.85).aspx
, a tak naprawdę api związane z mapowaniem pliku, dokładnie mówiąc:

GetMappedFileName

Ja delikatnie zmodyfikowałem tą funkcje na swoje potrzeby i teraz prezentuje się ona następująco

BOOL GetFileNameFromHandle(HANDLE hFile,char* filePath)
{
  BOOL bSuccess = FALSE;
  char pszFilename[MAX_PATH+1];
  HANDLE hFileMap;

  // Create a file mapping object.
  hFileMap = CreateFileMapping(hFile,
                    NULL,
                    PAGE_READONLY,
                    0,
                    1,
                    NULL);

  if (hFileMap)
  {
    // Create a file mapping to get the file name.
    void* pMem = MapViewOfFile(hFileMap, FILE_MAP_READ, 0, 0, 1);

    if (pMem)
    {
      if (GetMappedFileNameA (GetCurrentProcess(),
                             pMem,
                             pszFilename,
                             MAX_PATH))
      {

        // Translate path with device name to drive letters.
        char szTemp[1024];
        szTemp[0] = '\0';

        if (GetLogicalDriveStringsA(BUFSIZE-1, szTemp))
        {
          char szName[MAX_PATH];
          char szDrive[3] = " :";
          BOOL bFound = FALSE;
          char* p = szTemp;

          do
          {
            // Copy the drive letter to the template string
            *szDrive = *p;

            // Look up each device name
            if (QueryDosDeviceA(szDrive, szName, MAX_PATH))
            {
              UINT uNameLen = strlen(szName);

              if (uNameLen < MAX_PATH)
              {
                bFound = strnicmp(pszFilename, szName, uNameLen) == 0;

                if (bFound && *(pszFilename + uNameLen) == '\\')
                {
					strcpy(filePath,szDrive);
					strcpy(filePath+strlen(szDrive),pszFilename + strlen(szName));
                }
              }
            }

            // Go to the next NULL character.
            while (*p++);
          } while (!bFound && *p); // end of string
        }
      }
      bSuccess = TRUE;
      UnmapViewOfFile(pMem);
    } 

    CloseHandle(hFileMap);
  }
  CloseHandle(hFile);

  return(bSuccess);
}

Istotną zmianą jest tutaj usunięcie check’u polegającego na sprawdzaniu wielkości pliku po przez GetFileSize. Niestety ale dla pewnych handler’ow wskazujących na takie twory jak:
78: File (---) \Device\NamedPipe\net\NtControlPipe15
GetFileSize zawisa.
Kiedy uda nam się zdobyć ścieżkę do pliku kwestia jest już prosta. Wykonujemy check czy dana ścieżka jest identyczna do tej podanej przez nas

if( !strcmp(filePath,foundPath) )

Jeśli tak, to wywołujemy wcześniej omawianą funkcję duplicateHandle, lecz tym razem z parametrem closeSourceHandle ustawionym na true

				//handle to interesting file has been found,,,let's close it
				getDuplicatedHandle(shiTable->Handles[i].UniqueProcessId,
									shiTable->Handles[i].HandleValue,
									true);

[+]Analogiczne rozwiązanie lecz w świecie ring0[inspiracja gmer.sys].
Początek prezentuje sie identycznie jak wersja dla r3.

void r0_fileToDelete(wchar_t *filePath)
{
	r0_closeAllHandles(filePath);
	/*
		after closing all handles to the file ,try to delete it
		ofc,,,before it convert DosPath to NtPath (just add \??\ before filePath)
	*/
	//ZwDeleteFile();
}

Przyjrzyjmy się obecnej wersji closeAllHandles:

void r0_closeAllHandles(wchar_t* filePath)
{
	MY_SYSTEM_HANDLE_INFORMATION *shiTable;
	EPROCESS *eprocess;
	unsigned long i;
	FILE_OBJECT *file;
	OBJECT_NAME_INFORMATION *objectNameInformation = 0;
	unsigned long filePathLength = wcslen(filePath);

	shiTable = enumerateHandles();
	for(i = 0; i < shiTable->NumberOfHandles;i++)
	{
		if( isFile( shiTable->Handles[i].ObjectTypeIndex) )
		{
			file = (FILE_OBJECT*)shiTable->Handles[i].Object;
			if(!file || file->FileName.Length == 0)
				continue;

			getFullPathName(file,&objectNameInformation);

			if((objectNameInformation->Name.Length/2 ) != filePathLength)
				continue;

			if( !_wcsnicmp(filePath,(wchar_t*)objectNameInformation->Name.Buffer,filePathLength) )
			{
				PsLookupProcessByProcessId((HANDLE)shiTable->Handles[i].UniqueProcessId,&eprocess);
				KeAttachProcess(eprocess);//switch context to process one
				ZwClose((HANDLE)shiTable->Handles[i].HandleValue);
				KeDetachProcess();
			}
		}
	}

	ExFreePoolWithTag(shiTable,0xdeadbeef);
}

Tak jak poprzednio używamy enumerateHandles do zdobycia informacji o handler’ach, jedyna zmianą tutaj jest sposób alokacji:

MY_SYSTEM_HANDLE_INFORMATION * enumerateHandles()
{
	MY_SYSTEM_HANDLE_INFORMATION shi = {0};
	MY_SYSTEM_HANDLE_INFORMATION *shiTable;
	unsigned long shiTableSize;

	int status  = ZwQuerySystemInformation((SYSTEM_INFORMATION_CLASS)SystemHandleInformation,
						     &shi,
							 sizeof(MY_SYSTEM_HANDLE_INFORMATION),
							 &shiTableSize);
	//TODO: check status
	shiTable = (MY_SYSTEM_HANDLE_INFORMATION*)ExAllocatePoolWithTag(NonPagedPool,shiTableSize,0xdeadbeef);
	status = ZwQuerySystemInformation((SYSTEM_INFORMATION_CLASS)SystemHandleInformation,
									  shiTable,
									  shiTableSize,
									  0);

	return shiTable;
}

Poruszając się w głab funkcji r0_closeAllHandles napotykamy linijkę gdzie:

file = (FILE_OBJECT*)shiTable->Handles[i].Object;

Możemy skorzystać z tej dogodności, jaką daje nam obecność w r0, a mianowicie do wyciagnięcia interesujących nas informacji o ścieżce do pliku przy pomocy FILE_OBJECT’u dostarczonego w _SYSTEM_HANDLE_INFORMATION przez ZwQuerySystemInformation. Niestety sytuacja na wstępie nie jest taka kolorowa jak mogła by się wydawać, chodzi tutaj o nie dogodność związana z formatem sciężki do pliku z jaki powiązany jest FILE_OBJECT:

kd> dt _FILE_OBJECT 88e280d0
ntdll!_FILE_OBJECT
   +0x000 Type             : 5
   +0x002 Size             : 112
   +0x004 DeviceObject     : 0x88f76900 _DEVICE_OBJECT
   +0x008 Vpb              : 0x88fa5780 _VPB
   +0x00c FsContext        : 0xe154c0d0
   +0x010 FsContext2       : 0xe154c228
   +0x014 SectionObjectPointer : 0x88ee87ac _SECTION_OBJECT_POINTERS
   +0x018 PrivateCacheMap  : (null)
   +0x01c FinalStatus      : 0
   +0x020 RelatedFileObject : (null)
   +0x024 LockOperation    : 0 ''
   +0x025 DeletePending    : 0 ''
   +0x026 ReadAccess       : 0x1 ''
   +0x027 WriteAccess      : 0x1 ''
   +0x028 DeleteAccess     : 0 ''
   +0x029 SharedRead       : 0 ''
   +0x02a SharedWrite      : 0 ''
   +0x02b SharedDelete     : 0 ''
   +0x02c Flags            : 0x40008
   +0x030 FileName         : _UNICODE_STRING "\WINDOWS\system32\config\default.LOG"
   +0x038 CurrentByteOffset : _LARGE_INTEGER 0x0
   +0x040 Waiters          : 0
   +0x044 Busy             : 0
   +0x048 LastLock         : (null)
   +0x04c Lock             : _KEVENT
   +0x05c Event            : _KEVENT
   +0x06c CompletionContext : (null)

Tak jak widać ścieżka do pliku nie zawiera informacji o partycji, na której plik się znajduje. Jak uzyskać literę partycji? Jest na to parę sposobów.
Najwygodniejszym wydaje się użycie IoQueryFileDosDeviceName. getFullPathName w wersji dla r0 prezentuje się następująco:

NTSTATUS getFullPathName(FILE_OBJECT* fileObject,OBJECT_NAME_INFORMATION **objectNameInformation)
{

	 return IoQueryFileDosDeviceName(fileObject,
							  objectNameInformation
							  );
	//remeber about _OBJECT_NAME_INFORMATION deallocation!!!
}

Funkcja ta zwróci nam wypełniona strukturę, która tak naprawdę zawiera jedno pole UNICODE_STRING, zawierające pełną ścieżkę do pliku. Po porównaniu ścieżek do plików i znalezieniu tej interesującej nas przystępujemy tak jak poprzednio do zamknięcia uchwytu. I tu kolejna zmiana:

				PsLookupProcessByProcessId((HANDLE)shiTable->Handles[i].UniqueProcessId,&eprocess);
				KeAttachProcess(eprocess);//switch context
				ZwClose((HANDLE)shiTable->Handles[i].HandleValue);
				KeDetachProcess();

Tak jak odrazu widać nie posługujemy się DuplicateHandle jak poprzednio, lecz korzystamy z możliwości zmiany kontekstu(KeAttachProcess) na kontekst procesu, w którym dany handler istnieje i zamykamy go w trywialny sposób korzystając z ZwCloseHandle. Po zamknięciu wszystkich otwartych handler’ów do naszego pliku jesteśmy gotowi na jego usunięcie przy pomocy ZwDeleteFile.

3.

Usuniecie pliku nie jest możliwe ze względów na hooki , czy to na poziomie r3 czy r0, które chronią wybrane pliki malware’u.

Niestety czasami bywa tak, że chcemy usunąć jakiś plik, lecz nie jest to możliwe, a przeglądając listę otwartych handlerów wszystkich procesów nie odnajdujemy tam interesującego nas pliku o_0. So WTF?!.
Problemem mogą tu być hooki zakładane przez malware na różne api, których zdaniem jest zwracania kodu błędu w przypadku kiedy użytkownik zapragnie usunąć plik znajdujący się na liście plików chronionych przez malware.

Zanim przejdziemy do konkretnego przypadku i moim zdaniem jednego z lepszych rozwiązań w tym przypadku, prześledźmy z grubsza drogę, jaką musi przebyć żądanie usunięcia pliku z pod r3.

Ring3
------------
DeleteFile
|
V
NtOpenFile
|
V
KiFastSystemCall
|
V
Ring0
---------
NtDeleteFile
|
V
ObOpenObjectByName
|
V
ObpCaptureObjectCreateInformation
|
V
ObpLookupObjectName
|
V
ObpLookupDirectoryEntry
|
V
IopParseDevice
|
V
IofCallDriver
|
V
IRP_MJ_CREATE in filter drivers
|
V
File system driver (e.g NtfsFsdCreate)

Tak jak widać ścieżka od DeleteFile do NtfsFsdCreate jest dość długa i na każdej z jej etapów mogą pojawić się hooki uniemożliwiające usunięcie wybranego przez malware pliku. Sprawdzanie wszystkich tych api w r3 i r0 pod kątem istnienia hooku na nich jest dość czasochłonne i czasem nie trywialne. Było by wspaniale gdybyśmy mogli w pewien sposób oszukać hooki malware’u sprawdzające ścieżkę do pliku.
Czy jest to możliwe? Okazuje się, że od samego DeleteFile do NtfsFsdCreate ścieżka wskazująca na plik do usunięcia nie musi wskazywać na plik dokładnie ten, który chcemy usunąć!!!
Dopiero, w NtfsFsdCreate(a dokładnie w NtfsCommonCreate) ścieżka ta ma znaczenie i jest rozwiązywana na konkretne wewnętrzne struktury NTFS’owe.
Co nam to daje?
Wspaniałą możliwość ominięcia masy istniejących hook’ow na api zaprezentowanych powyżej!!!.

[+]Sposób na obejście tego przypadku:
Wystarczy uzyskać bezpośredni dostęp do urządzenia file systemu, a następnie, podmienić w obiekcie sterownika handler(założyć hook...jak kto woli) obsługujący IRP_MJ_CREATE (w naszym przypadku jest to NtfsFsdCreate) na własny. Nasz handler będzie tylko i wyłącznie odpowiedzialny za podmianę ścieżki do pliku, którą wcześniej ustalimy, jako coś ala „turn on trigger”(np. \ice_psuje.exe). Ścieżkę tą, podmienimy na taką by wskazywała ona na plik malware’u, który rzeczywiście jest naszym celem.

[+]Implementacja (inspiracja gmer.sys)

void hook_NtfsFsdCreate(wchar_t* filePath)
{
	HANDLE fileHandle;
	NTSTATUS result;
	IO_STATUS_BLOCK ioBlock;
	DEVICE_OBJECT *device_object;
	void* object = NULL;
	OBJECT_ATTRIBUTES objectAttr;
	UNICODE_STRING uDeviceName;
	wchar_t deviceName[14];

	//switch context to UserMode
	EPROCESS *eproc = IoGetCurrentProcess();
	KeAttachProcess(eproc);

	//initialize file to delete variable
	g_fileToDelete = filePath;
	g_fileToDelete += 6; //take from \??\C:\zlo only \zlo

	//e.g "\??\C:\"
	memset(deviceName,0,sizeof(deviceName));
	wcsncpy(deviceName,filePath,7);
	wcsncpy(g_tmpFile,filePath,7);

	RtlInitUnicodeString(&uDeviceName,deviceName);
	InitializeObjectAttributes(&objectAttr,
								&uDeviceName,
								OBJ_CASE_INSENSITIVE,
								NULL,
								NULL);

	result = ZwOpenFile(&fileHandle,
						SYNCHRONIZE,
						&objectAttr,
						&ioBlock,
						FILE_SHARE_READ,
						FILE_SYNCHRONOUS_IO_NONALERT|FILE_DIRECTORY_FILE);

	if(result != STATUS_SUCCESS)
	{
		DbgPrint("Some problem with open file ;[");
		goto _end;
	}

    if ( !ObReferenceObjectByHandle(fileHandle, 0, 0, 0, &object, 0) )
    {
      device_object = IoGetBaseFileSystemDeviceObject(object);
      ObfDereferenceObject(object);
    }

	hook_it(device_object);

_end:
	KeDetachProcess();}

Myślę, że ta część kodu jest już wam dobrze znana. Nowością może tu być linia gdzie pojawia się zmienna globalna:

	g_fileToDelete = filePath;
	g_fileToDelete += 6; //take from \??\C:\zlo only \zlo

Ustawiamy zmienna globalną g_fileToDelete, którą później będziemy wykorzystywać w hooku, na ścieżkę do pliku, który rzeczywiście chcemy skasować. W lini:

	wcsncpy(g_tmpFile,filePath,7);

gdzie, zmienna g_tmpFile prezentuje się domyślnie tak:

wchar_t *g_tmpFile = L"\\??\\C:\\ice_psuje.exe";

dokonujemy podmiany domyślnej wartości woluminu na tą, na której znajduje się plik naszych zainteresowań.

void hook_it(DEVICE_OBJECT *device_object)
{
	NTSTATUS result;
	OBJECT_ATTRIBUTES fileObj;
	UNICODE_STRING uTmpFile;
	HANDLE fileHandle;
	IO_STATUS_BLOCK ioStatus;
	FILE_BASIC_INFORMATION fileBasicInfo;

	//initialize variables related with fake file
	RtlInitUnicodeString(&uTmpFile,g_tmpFile);

	InitializeObjectAttributes(&fileObj,
								&uTmpFile,
								OBJ_CASE_INSENSITIVE,
								NULL,
								NULL);

	//save original MJ functions
	create  = device_object->DriverObject->MajorFunction[0];

	result = ZwCreateFile(&fileHandle,
						  4,
						  &fileObj,
						  &ioStatus,
						  0,
						  0x80,
						  2,
						  3,
						  0x20,
						  0,
						  0);
	if(result != STATUS_SUCCESS)
		return;

	ZwClose(fileHandle);

	//install hooks
	device_object->DriverObject->MajorFunction[0]    = HookedNtfsFsdCreate;  

	ZwDeleteFile(&fileObj);//launche our hooks

	//restore original MJ functions
	device_object->DriverObject->MajorFunction[0]    = create;

}

W kolejności:

//save original MJ functions
	create  = device_object->DriverObject->MajorFunction[0];

Zachowujemy oryginalny handler IRP_MJ_CREATE, następnie tworzymy plik, który będzie trigerem. Instalujemy nasz hook:

	//install hooks
	device_object->DriverObject->MajorFunction[0]    = HookedNtfsFsdCreate;  

Chcąc skorzystać z dobroci naszego hook’a, wywołujemy ZwDeleteFile na \??\X:\ice_psuje.exe.

//global
wchar_t *g_tmpFileName = L"\\ice_psuje.exe";

//--------
//(...)
NTSTATUS NTAPI
HookedNtfsFsdCreate(PDEVICE_OBJECT DeviceObject,
	   PIRP Irp)
{
	unsigned long proper_file = 0; //whether we get Irp with interesting for us file_object ?
	UNICODE_STRING bfile; //backup file
	UNICODE_STRING uMalwareFile;
	NTSTATUS rez;
	PFILE_OBJECT pFileObject;

	RtlInitUnicodeString(&uMalwareFile,g_fileToDelete);
	pFileObject = Irp->Tail.Overlay.CurrentStackLocation->FileObject;
	if(!pFileObject)
		goto _end;

	if((pFileObject->FileName.Length / 2) != wcslen(g_tmpFileName))
		goto _end;

	if(!_wcsnicmp(g_tmpFileName,
				  (wchar_t*)pFileObject->FileName.Buffer,
				  (pFileObject->FileName.Length / 2)))
	{

		    bfile = pFileObject->FileName;//backup current string
			pFileObject->FileName = uMalwareFile; //hook string value
			proper_file = 1;
	}

_end:

	rez = Call_NtfsFsdCreate(DeviceObject,Irp);
	if(pFileObject)
	{
		if(proper_file)
		{
			pFileObject->FileName = bfile;
		}
	}
	return rez;
}

Wydaje mi się, że po wcześniejszych opisach sprawa jest jasna. Jeżeli do NtfsFsdCreate trafia FILE_OBJECT, którego FileName to „\ice_psuje.exe” następuje podmiana tej ścieżki na ścieżkę podana jako parametr hook_NtfsFsdCreate i zachowaną w:

	//initialize file to delete variable
	g_fileToDelete = filePath;
	g_fileToDelete += 6; //take from \??\C:\zlo only \zlo

Uff w końcu dobrnęliśmy do końca tego skromnego postu . Ma nadzieje, że ktoś dotarł do tego miejsca, znalazł coś ciekawego dla siebie i zostawi jakiś feedback .
Enjoy

[+]Dlaczego warto o nim wspomnieć?
1. Dla zdobycia odpowiedzie na pytania, które tygrysy lubią najbardziej : czyli po co, na co ,dlaczego ,dlaczego tak a nie inaczej
2. Dla zaprezentowania wektora ataku np. na przekladarke.

[+]Jak wywołać bug?
Wystarczy stworzyc pusty plik i nadac mu rozszerzenie .eml (trudno okreslic dla jakich jeszcze rozszerzenie opera tak zareaguje, ze wzgledu na pokazny kod do rewersowania, w celu ustalenia tych danych oraz mala uzytecznosc tego bug’a jak dla mnie ),wrzucic ten plik do katalogu np. apacha’a ( to istotne zeby odwolywac sie do pliku zdalnie) odwolac sie do niego i nastepnie wywolac opcje ‘Zapisz jako’.

[+]Gdzie znajduje sie bug?
Rzućmy okiem na wartosci rejestrow,elementow na stos podczas wystapienia tego bledu.
Opera 10.10b PL

Pointer na unikodowy string leżący na stosie może sugerować nam, że błąd może być związany z wypelnianiem kontrolki trzymajacej opisy typow plikow do jakich opera moze zapisac bierzacy kontent. Zdziwiłem się delikatnie, kiedy na tej samej wersji przegladarki, jedynie z zaladowanym angielskim tlumaczeniem wywolanie bug’a nie udalo sie powtorzyc. Co tu moze byc problemem?!….

[+]Wektor ataku
Wektorem ataku okazują sie tutaj pliki z tlumaczeniami,
($INSTALDIR\locale\[jezyk]\[jezyk])
ktorych nie do końca poprawne zdefiniowanie może spowodować DoS’a ze względu na nie sprawdzanie w kodzie poprawności zawartych tam danych. Taka sytuacja bez naszej ingerencji ma miejsce do Opery 10.10b ze wzgledu na nie poprawnie zdefiniowany plik z tlumaczeniem dla jezyka polskiego.
Odnajdzmy wczesniej prezentowany interesujacy string na screen’e w pliku z tlumaczeniem PL oraz sprobujmy znaleść rożnice w formacie dla pliku z tlumaczeniem ANG.

Baah!!!Jak widać string zawierający tekst, który jest umieszczany pozniej w kontrolce, zawierajacej liste typow plikow mozliwych do zapisu przez opera oraz rozszerzenie pod jakim plik zostanie zapisany w wersji PL nie zawiera znaku ‘|’ co jak okazuje sie jest zrodlem problemu.

[+]Malo bezpiecznie zdefiniowana funkcja
Powróćmy teraz do Olka i przyjrzymy sie miejscu gdzie nastepuje dereferencja pointer’a zerowego:
Analiza kodu dla poprawnie zdefiniowanego parametru:
-1371929526=”Archiwum strony WWW (jeden plik)|*.mht|”

registers:
EAX = 0x1732F8C
ECX = 0x1732FA0
 
entire code:
67ADDA16    8B4424 04       MOV EAX,DWORD PTR SS:[ESP+4] //eax == save_as_struct
67ADDA1A    8D48 14         LEA ECX,DWORD PTR DS:[EAX+14]
67ADDA1D    8B40 2C         MOV EAX,DWORD PTR DS:[EAX+2C]
67ADDA20    57              PUSH EDI
67ADDA21    E8 F842D8FF     CALL Opera_1.67861D1E
67ADDA26    8BC8            MOV ECX,EAX
67ADDA28    83C1 08         ADD ECX,8
67ADDA2B    33C0            XOR EAX,EAX
67ADDA2D    E8 EC42D8FF     CALL Opera_1.67861D1E
>>> 67ADDA32    8B00            MOV EAX,DWORD PTR DS:[EAX] //eax = pointer on string contains file extension (e.g *.mht) or NULL
67ADDA34    8B7C24 0C       MOV EDI,DWORD PTR SS:[ESP+C] //esp+c == buffer_for_copyOf_file_extension
67ADDA38    6A FF           PUSH -1
67ADDA3A    50              PUSH EAX
67ADDA3B    E8 60B3CBFF     CALL Opera_1.67798DA0
67ADDA40    5F              POP EDI
67ADDA41    C3              RETN
 
struct save_as_struct
{
0x1732F8C  /* +0 */  0x00000000
0x1732F90  /* +4 */  0x00000000
0x1732F94  /* +8 */  0x00000000
0x1732F98  /* +C */  0x60D76F01
0x1732F9C  /* +10 */ 0x38000000
0x1732FA0  /* +14 */ 0x4805E967     //ecx pointer
0x1732FA4  /* +18 */ 0x0A000000
0x1732FA8  /* +1C */ 0xC0E59301     //ecx + 0x8  //pointer on array->pointer->string('Archiwum strony WWW (jeden plik)')
0x1732FAC /* +20 */ 0x01000000     //ecx + 0xc // count of elements
0x1732FB0 /* +24 */ 0x0A000000 
0x1732FB4 /* +28 */ 0x00000000 
0x1732FB8 /* +2C */ 0x00000000 
};
 
first call of 67861D1E:
ECX = 0x1732FA0 /* +0x14 */
EAX = 0
67861D1E    3B41 0C         CMP EAX,DWORD PTR DS:[ECX+C] /* eax = 0; ecx + C == count of elements*/
67861D21    73 07           JNB SHORT Opera_1.67861D2A   
67861D23    8B49 08         MOV ECX,DWORD PTR DS:[ECX+8] /* ecx = [ecx + 8]; [ecx+8]==pointer on array->pointer->string */
67861D26    8B0481          MOV EAX,DWORD PTR DS:[ECX+EAX*4] /* eax = pointer->string */
67861D29    C3              RETN
67861D2A    33C0            XOR EAX,EAX
67861D2C    C3              RETN
 
second call of 67861D1E:
ECX = 0x0166C270
EAX = 0
stack view:
0x0166C270 /* +0 */ 0xB832DC67 
0x0166C274 /* +4 */ 0x0A000000 
0x0166C278 /* +8 */ 0xC0DF9301  //pointer on array->pointer->string('*.mht')  
0x0166C27C /* +C */ 0x01000000  // count of elements

Dereferencja null pointer’a dla blednie zdefiniowanego parametru:
-1371929526=”Archiwum strony WWW (jeden plik)|*.mht”

Tak jak pisalem wczesniej nie analizowałem dogłebnie calego procesu parsowania pliku z tlumaczeniem …
Bez doglebnej analizy wczesniej wykonanego kodu przed kodem prezentowanym powyzej, mozemy stwierdzic ze brak znaku ‘|’ na koncu ‘parametru’ -1371929526 powoduje bledny split lancucha znakow i tym samym nie wypelnienie pola struktury gdzie powinien sie znalesc pointer na rozszerzenie pliku pod jakim miala by byc zapisana zawartosc strony.
Całe zło zaczyna sie dziać przy drugi wywołaniu funkcji 67861D1E:

second call of 67861D1E: // for bad parameter
ECX = 0x0166C270
EAX = 0
Stack view:
0x0166C270 /* +0 */0xB832DC67
0x0166C274  /* +4 */0x00000000
0x0166C278  /* +8 */0x00000000  
0x0166C27C /* +C */0x00000000  
67861D1E    3B41 0C         CMP EAX,DWORD PTR DS:[ECX+C] /* eax = 0; ecx + C == count of elements*/
67861D21    73 07           JNB SHORT Opera_1.67861D2A

Warunek skoku zostaje spelniony i mamy skok do instrukcji:

67861D2A    33C0            XOR EAX,EAX
67861D2C    C3               RETN

zerujacej nam eax i wychodzacej z funkcji. Nastepnie bez sprawdzania czy wartosc w eax jest poprawnym wskaznikiem mamy dereferencje:

>>> 67ADDA32    8B00            MOV EAX,DWORD PTR DS:[EAX] //eax = pointer on string contains file extension (e.g *.mht) or NULL

[+]Konkluzja
Tak jak pisałem na początku wspominam o tym bug’u raczej z formie ciekawostki niz jakiegos żalu do twórców opery ze wzgledu na sposob jaki „pozbyli” sie problemu(od wersji 10.10 plik z tlumaczeniem we wspomnianej linijce zawiera na koncu ‘|’ ). Co niektorzy mogą się przyczepic ze mozna przeciez wykonac tutaj sprawdzanie formatu i ewentualnie wyswietlic komunikat ze plik z tlumaczeniem zostal zmodyfikowany lub jest uszkodzony i nalezy go zastapic poprawna wersja,itd….Takie rozwazania i ocene podejscia dev’ow z opery pozostawia wam Drodzy Czytelnicy .

Cała historia zaczyna się od momentu kiedy chciałem przetestować najprostszy w życiu hook na procedure KiSystemService poprzez modyfikacje jej adresu w tablicy IDT. Oto fragment kodu zakładający hook:

void IDTHook()
{
IDTINFO idtInfo;
IDTENTRY *idt_entries;
IDTENTRY *int2e_entry;
DbgPrint("[+] IDTHook");
//pobranie IDTINFO
idtInfo = getIDTInfo();
//pobranie *tablicy IDT
idt_entries = getIDTEntries(&idtInfo);

//zapisanie oryginalnego IDTENTRY_2E
orgIDTEntry_2e = idt_entries[KiSystemService_INDEX];
//zapisanie DWORD'a na potrzeby funkcji hookujacej
orgKiSystemService = MAKELONG(orgIDTEntry_2e.LowOffset,orgIDTEntry_2e.HiOffset);
__asm cli;//wylacz obsluge maskowalnych przerwan
idt_entries[KiSystemService_INDEX].LowOffset = (unsigned short)(&MySystemService);
idt_entries[KiSystemService_INDEX].HiOffset  = (unsigned short)(((unsigned long)(&amp;MySystemService))<<16);
__asm lidt idtInfo;
__asm sti;//wlacz obsluge maskowalnych przerwan

}

‘kod MySystemService przepisany w calosci z „Subverting Windows Kernel”‘

__declspec(naked) MySystemService()
{

__asm{
pushad
pushfd
push fs
mov bx,0x30
mov fs,bx
push ds
push es
//do something

//Finish:
pop es
pop ds
pop fs
popfd
popad

jmp	orgKiSystemService;
}
}

/* __asm { sysenter VPC } */

Bez większego wachania i namysłow postanowiłem przetestować wynikowy driver pod Virtual PC(ver. 6.0.192.0 + additions)[OS: Windows XP SP3 Eng], z którego zwykłem korzystać. Ku mojemu zaskoczeniu (bo liczyłem co najwyżej na BSOD’a ) przy próbie założenia hook’a wystąpił wewnętrzny błąd vpc:

Hym…dziwna kwestia pomyślałem. Między czasie przypomniałem sobie, że przecież system może w ogóle nie korzystać z IDT jeżeli posiadany przez nas procesor dysponuje obsługą instrukcji sysenter/syscall. Rzut okiem pod vpc na wywolanie jednego z najbardziej popularnych native api:
ZwOpenFile, rozwiało moje wątpliwości:

Sam error „wywalony” przez vpc wskazywał na to, że to nic stricte związanego z samym systemem, a raczej z vm, a teraz dodatkowo wiemy, że sens zakładania hook’a na IDT pod vpc jest raczej nie wielki (przez co POWINIEN być nie szkodliwy) . Postanowiłem wykonać test jeszcze raz po odinstalowaniu z systemu additions. Tu ponownie zaskoczenie, bo system zachował się tak jak powinien, czyli:
udało się zainstalować hook’a
oraz żaden z breakpoint’ów(po dłuższej chwili), które założyłem na MySystemService nie został wywołany.
Zobaczmy teraz jak się sprawy maja pod VirtualBoxem.

/* __asm { INT VirtualBox } */

Ver. 3.0.8 r53138 + additions
OS pozostaje bez zmian pod każdą maszynką.
Pierwszą kwestią, którą tutaj sprawdziłem jest sposób przejścia procesu z r3 do r0.

Wyśmienicie! Jak widać na załączonym obrazku pod VBoxem możemy śmiało testować hooki na IDT. Tak mi się bynajmniej wydawało…
Ładuje driver,przekazuje odpowiedni IOCL_code do moje driver’a, który wywoła instalacje hook’a i … :

cała akcja kończy się nie oczekiwanem crash’em VBox’a.
Długo nie myśląc odinstalowalem dodatki z systemu i ponowiłem próbę.
Udało się!Instalacja hook’a przebiegła bez problemowo, ale podczas paru kolejnych prób zdarzał mi się BSOD’nąć system z komunikatem, który jedno znacznie wskazywał, że nastąpiła próba dostępu do stronnicowanego obszaru pamięci.Windbg wskazywał następującą linijke kodu jako przyczyne zła:

idt_entries[KiSystemService_INDEX].LowOffset = (unsigned short)(&MySystemService);

Eeee delikatnie dziwne,,,IDT w obszarze stronnicowanej pamięci o_0?
Delikatnie zmodyfikowałem więc kod instalujący hook, po przez zmapowanie tablicy IDT pod NIEstronnicowany obszar pamieci. Kod prezentuje się teraz następująco:

void IDTHook()
{
IDTINFO idtInfo;
IDTENTRY *idt_entries;
IDTENTRY *int2e_entry;
DbgPrint("[+] IDTHook");
//pobranie IDTINFO
idtInfo = getIDTInfo();
//pobranie *tablicy IDT
idt_entries = getIDTEntries(&idtInfo);

//try to map it
idt_entries = mapMemory(idt_entries,idtInfo.IDTLimit);// NOWA LINIA
//update idtinfo struct
idtInfo.HiIDTbase  = HIWORD(idt_entries);
idtInfo.LowIDTbase = LOWORD(idt_entries);

//zapisanie oryginalnego IDTENTRY_2E
orgIDTEntry_2e = idt_entries[KiSystemService_INDEX];
//zapisanie DWORD'a na potrzeby funkcji hookujacej
orgKiSystemService = MAKELONG(orgIDTEntry_2e.LowOffset,orgIDTEntry_2e.HiOffset);
__asm cli;//wylacz obsluge maskowalnych przerwan
idt_entries[KiSystemService_INDEX].LowOffset = (unsigned short)(&MySystemService);
idt_entries[KiSystemService_INDEX].HiOffset  = (unsigned short)(((unsigned long)(&MySystemService))>>16);
__asm lidt idtInfo;
__asm sti;//wlacz obsluge maskowalnych przerwan

}

Ten prosty zabieg wyeliminował pojawianie się BSOD’ów.

/* __asm { VMware sysenter } */

VMware Workstation
6.5.3 build-185404

Rzut oka na przejście r3 – > r0:

Jak widać użyty jest tu sysenter. Nie będę się rozpisywał przy vmware i od razu powiem, że instalacja hooka przebiega tutaj bez problemowo czy to z zainstalowanymi dodatkami czy bez.

Na podsumowanie sporządziłem następującą tabelkę:

Jak zwykle komentarze i wszelkiego rodzaju sugestie mile widziane .

Bugs in Malware

Z jakich powodów przeniosłem blog na nowy server? Powodów jest kilka, a główny jest to, że posiadanie pełnego dostępu do plików na serwerze daje mi większe możliwości:
- darmowa instalacja dodatkowych pluginów do wordpress’u
napewno tutaj  odczuwalnym dyskomfortem był brak pluginu do wyświetlania fragmentów kodu.

#include <iostream>
int main()
{
  std::cout<<"Hello world!";
  return 0;
}

Nie mogłem się powstrzymać:P

Jeżeli chodzi o jakieś gruntowne zmiany to takowych raczej nie przewiduje,  jedyną kwestią która być może niektórym osobą (a pewnej grupie ludzie zdecydowanie) przypadnie do gustu jest publikowanie postów, które uznam za ciekawe lub tych które będą cieszyły się dużą popularnością , w dwóch wersjach językowych: Polskiej jak i Angielskiej.
Chyba tyle jężeli chodzi o zmiany i “innowacje” .
BTW:Rozpoczyna się delikatnie burzliwy okres: “Rozpoczęcie roku akademickiego” , także będe musiał poświęcić trochę czasu na dogranie pracy z uczelnią i paroma dodatkowymi zajęciami, ale oczywiście jestem przekonany o tym, że znajdzie się również czas na wrzucenie nowego posta .
W najbliższym czasie myślę, że można się spodziewać nagrań video z SecDay2009 jaki i kolejnego postu z cyklu
“Algorytmy (de)szyfrowania wykorzystywane przez twórców trojanów bankowych”.
Stay tuned .

Emocje były wielkie …… ale jak dokładnie było możecie przeczytać poniżej:
Na wstępie powiem, że nie będę w żaden sposób komentował prezentacji Team’u HSPL w składzie (chronologicznie względem kolejności wystąpień):

Mateusz “j00ru” Jurczyk
Adam “pi3″ Zabrocki
Gynvael Coldwind

Żeby nikt nie zarzucał mi, że cukruje kolegą z pracy to tylko powiem, że każda prezentacja była petardą i warto na nie rzucić okiem ..Heheh.
More details below…

/* SecDay 2009 dzień pierwszy */
Jako, że obecnie mieszkam we Wrocławiu to kwestie dotarcia na konferencje pominę ponieważ nie było w niej nic nadzwyczajnego(15min taxi)….taaa to nie to samo co 5h spędzonych w pociągu w drodze na confidence .

Konferencje rozpoczął :
Dariusz Puchalak
prezentując temat:
„Bezpieczeństwo czy wydajność pracy?”
Niestety muszę się przyznać, że delikatnie się spóźniłem na ten wykład(sorry Darek ).
Już parę razy miałem okazje słuchać prezentacji Darka i także tym razem była ona prowadzona na wysokim poziomie. Ze względu na porę dnia długo nie zastanawiałem się
nad propozycją jaką Dariusz umieścił w swoim temacie i wybrałem …..NIEBEZPIECZEŃSTWO.:D.

Przemysław Świercz
Bezpieczeństwo Bluetooth
Na wstępie trzeba wspomnieć, że był to debiut Przemka co moim zdaniem po wysłuchaniu jego prelekcji jest jak najbardziej na plus. Temat myślę, że jak najbardziej na czasie, bo przecież bluetooth można spotkać teraz praktycznie w każdym telefonie komórkowym, większości nowych TV,itd. Prezentacja była mocno techniczna (a takie właśnie uwielbiam) + zabawne anegdoty prowadzącego działające silnie na wyobraźnie .
Jeżeli ktoś jest zainteresowany bezpieczeństwo Bluetooth to myślę, że warto prześledzić tą prezentacje.

/* Przerwa na kafkę i po niej …*/

Mateusz Jurczyk
Bootkit vs Windows
Jako, że j00ru prowadzi własny blog to zachęcam do przeczytania jego relacji z konferencji jak i pobrania materiałów -> j00ru’s blog

/* Przerwa obiadowa */
Mówiąc krótko i kolokwialnie „obiad był bez szału”, także nie mogę tutaj przyznać ani plusa ani minusa, ale na pewno wypadł o wiele lepiej niż tegoroczny podawany na confidence’e.
Małego minusa dam za to, że dwa dni była ta sama potrawa:P,,,,gdzie kucharz „zostawił” fantazję!?

wracamy do prelekcji:

Krzysztof Maćkowiak
„Zarządzanie ryzykiem podstawą profesjonalnego podejścia do bezpieczeństwa informacji i ciągłości działania.”
Prezentacja jak najbardziej wykonana jak i poprowadzona w sposób profesjonalny, chociaż nie interesująca mnie zbytnio ze względu na obszar działań jakie poruszała. Dlatego też 3/4 jej czasu przegadałem z carstein’em o niuansach związanych z pentestingiem .

Grzegorz Błoński
Problem ulotu elektromagnetycznego.
Bardzo interesująca prezentacja, mocno techniczna podczas, której mogliśmy zobaczyć parę narzędzi do monitorowania ulotu elektromagnetycznego stworzonych przez autora przy wykorzystaniu popularnych kart telewizyjnych . Jeżeli byłeś/jesteś fanem serialu MacGyver masz zbędną kartę TV to nie czekaj tylko przeanalizuj powyższą prezentacje i rozpocznij własne badania!

Michał Melewski
Metodyka testów penetracjnych.
Moim zdaniem elegancko wykonana prezentacja, przejrzysta, przedstawiona na luzie, dająca do myślenia jeżeli chodzi o podejście do pentestów. Dzięki za źródło do refleksji .

Leszek Miś
Rootkity w systemie Linux.
Niestety prelegent nie dotarł na konferencje, a szkoda bo z chęcią posłuchałbym jak wygląda kwestia związana z rootkit’ami na linuxach.

Janusz Żmudziński
Monitorowanie bezpieczeństwa jako istotny element skutecznego zarządzania bezpieczeństwem informacji
?

/* SecDay 2009 dzień drugi */
Jako, że miałem przyjemność rozpocząć dzień drugi to przejdę od razu do drugiej prezentacji, a o własnej wspomnę na końcu relacji.

Konrad Zuwała
Solaris jako bezpieczna platforma serwerowa.
Od strony technicznej prezentacja jak najbardziej poprowadzona bardzo dobrze. Przeznaczona raczej dla administratorów i w tym kręgu znalazła ona grono słuchaczy jak i wywołała burzliwą dyskusję.

Błażej Miga
Zagrożenia w Internecie – DNS
Muszę powiedzieć, że na opublikowanie tej prezentacji czekam ponieważ pojawiło się w niej parę smaczków, które z chęcią bym przetestował. Hehe no i pojawił się w niej kod python’owy z wykorzystaniem modułu scapy.. jak widać prelegent wie co dobre;).

/* Dinner */

Jakub Bryl
Testowanie planów ciągłości działania
?

Adam Zabrocki
Unusual bugs
Adam obiecał wystartować z nową stroną/blogiem, a wtedy na pewno będziecie mieli okazje przejrzeć jego materiały .

Gynvael Coldwind
PHP Internals (not another RFI/SQLI)
Relacja Gyn’a + jego materiały. -> LINK

Robert Dąbrowski
Monitoring bezpiecznej sieci – praktyczne wykorzystanie logów.
Przepraszam, ale prezentacje komercyjnych produktów mnie nie interesują. Tu chodzi o research w dobrym klimacie tzw „piwnicznym klimacie”:D!

I tak kończy się lista prelegentów wraz ich tematami, których miałem przyjemność w większości wysłuchać.

Jeżeli chodzi o mój temat to brzmi on następująco:
Bugs in malware
Moim główny zamiarem było uświadomienie słuchaczy o tym, że w wieluuuuu przypadkach tworzony malware NIE jest doskonały, bardzo często tworzą go ludzie, którzy nie mają nawet średnich umiejętności programistycznych, a gruntowne testowanie swojego tworu jest dla nich abstrakcją. Często zdarza mi się spoglądając w kod malware’u pomyśleć o wyrażeniu : tragizm połączony z idiotyzmem. Czy taki obraz złośliwego oprogramowania przedstawiany jest w prasie i mediach? NIE. Oczywiście głównymi hasłami jakie pojawiają się są następujące:
„nowy błyskawicznie rozprzestrzeniający się worm”
„bardzo trudny do usunięcia trojan”
„trudno wykrywalny wirus”
„maszynka do wykradania poufnych danych”
itp.

Taki obraz, będący totalną generalizacją na temat malware’u, który rzekomo jest absolutnie genialny, trudny do usunięcia, napisany przez pr0 cod3r0w miałem na zamiarze usunąć z mapy rzeczywistości słuchaczy, a przynajmniej wzbogacić ją o informacje, które pokazują „troszeczke” inny obraz tych „złośliwych” aplikacji . Czy mi się udało ?;]. Mam taką nadzieję;).

Jeżeli chodzi o moje materiały to możecie je pobrać stąd:

Pełna paczka(prezentacja + filmiki) => Icewall_SecDay_2009.zip

W kwestii wyjaśnienia: Jeden z filmików zbudził delikatne kontrowersje dlatego też został odpowiednio ocenzurowany.

Hiperlinki w ODP jak i w PDF’e są ustawione w sposób relatywny, także można na nie klikać dowoli jeżeli zachowacie następująco strukturę katalogów:

Delephant
GetCodec
Zeus
prezentacja.odp
prezentacja.pdf

PS: Możliwe, że nawet do końca tygodnia pojawi się photo jaki i video relacja z konferencji dla której myśle stworze osobny post. Na video relacji będziecie mogli obejrzeć wszystkie prelekcje ludzi zarówno z HSPL jak i Vexillium. Także bądźcie czujni;),będzie co oglądać.

Pozdrawiam i zapraszam na kolejną edycje SecDay już we wrzesniu, bo warto;).

Oczywiście tradycyjnie zaczniemy od przedstawienia naszego bohatera:
[=]Dane[=]

Antivirus	Version	Last Update	Result
a-squared	4.5.0.24	2009.08.28	Trojan-Spy.Win32.Bancos!IK
AhnLab-V3	5.0.0.2	2009.08.28	-
AntiVir	7.9.1.7	2009.08.28	TR/Spy.Banker.DS.5102592
Antiy-AVL	2.0.3.7	2009.08.24	-
Authentium	5.1.2.4	2009.08.28	-
Avast	4.8.1335.0	2009.08.28	Win32:Spyware-gen
AVG	8.5.0.406	2009.08.28	PSW.Banker5.IQR
BitDefender	7.2	2009.08.28	DeepScan:Generic.Banker.OT.4CC5D1C8
CAT-QuickHeal	10.00	2009.08.28	-
ClamAV	0.94.1	2009.08.28	Trojan.Agent-119128
Comodo	2125	2009.08.28	-
DrWeb	5.0.0.12182	2009.08.28	Trojan.PWS.Banker.based
eSafe	7.0.17.0	2009.08.27	-
eTrust-Vet	31.6.6706	2009.08.28	-
F-Prot	4.5.1.85	2009.08.27	-
F-Secure	8.0.14470.0	2009.08.28	-
Fortinet	3.120.0.0	2009.08.28	W32/Banker.B!tr.pws
GData	19	2009.08.28	DeepScan:Generic.Banker.OT.4CC5D1C8
Ikarus	T3.1.1.68.0	2009.08.28	Trojan-Spy.Win32.Bancos
Jiangmin	11.0.800	2009.08.28	-
K7AntiVirus	7.10.830	2009.08.28	-
Kaspersky	7.0.0.125	2009.08.28	-
McAfee	5723	2009.08.28	PWS-Banker.gen.b
McAfee+Artemis	5723	2009.08.28	Artemis!504F1C591479
McAfee-GW-Edition	6.8.5	2009.08.28	Trojan.Spy.Banker.DS.5102592
Microsoft	1.5005	2009.08.28	TrojanSpy:Win32/Bancos.gen!C
NOD32	4378	2009.08.28	probably a variant of Win32/Spy.Banker.QEO
Norman		2009.08.28	W32/Banker.EKFF
nProtect	2009.1.8.0	2009.08.28	-
Panda	10.0.2.2	2009.08.28	Trj/CI.A
PCTools	4.4.2.0	2009.08.28	-
Prevx	3.0	2009.08.28	-
Rising	21.44.40.00	2009.08.28	Trojan.PSW.Win32.Banker.dnl
Sophos	4.45.0	2009.08.28	Mal/Generic-A
Sunbelt	3.2.1858.2	2009.08.28	-
Symantec	1.4.4.12	2009.08.28	Infostealer.Bancos
TheHacker	6.3.4.3.389	2009.08.27	-
TrendMicro	8.950.0.1094	2009.08.28	-
VBA32	3.12.10.10	2009.08.28	-
ViRobot	2009.8.28.1907	2009.08.28	-
VirusBuster	4.6.5.0	2009.08.28	TrojanSpy.Banker.CDVF
Additional information
File size: 5102592 bytes
MD5   : 504f1c5914799e5122c69620c0b892e2
SHA1  : 32980745998151bda4a9e3bab767201ebc52fc0a
SHA256: 54d974192dd53aba186d56803087224ff8f8b0aba9687604332891842bb5ef58

[=]Prolog[=]
Tak jak pewnie udało wam się zauważyć w poprzednim poście malware ten posiada np. zaszyfrowane ścieżki, do których zostaną wykonana jego kopie. Przykładowy zaszyfrowany ciąg wygląda tak:
GpfSH6zZTMrbRdHp865kP21JPNHqQMvdSrn1R6mWLNDbSdDSJMLkTI19RcbZQM5oN51oRsToOMrXSrn9RcbZQM5iQNfXSbnNQMvaRtTpCp8kPNXb

gdzie po deszyfrowaniu otrzymujemy łańcuch:
C:\Documents and Settings\All Users\Menu Iniciar\Programas\Inicializar\Windows32.exe

W jaki sposób funkcjonuje ten algorytm ? Tego dowiemy się już za chwilę.
Wcześniej jednak sprecyzuje „elementy”, które w tym malware’e wymagają deszyfrowania:

- ścieżki, do który kopiowany jest malware
- tytuły okien IE(malware używa tytułów okien do rozpoznania czy user znajduje się obecnie na stronie, dla której trojan ma przygotowany np. fałszywy panel logowania)
- treść fałszywych komunikatów mówiących o tym, że np. Internet Explorer wykonał
nieprawidłową operacje i zostanie zamknięty.

w niektórych wersjach także:
- login&hasło do serwera ftp/mysql używanego jako drop host
- adresy email na które mają zostać przesłane skradzione dane

Warto tutaj wspomnieć o różnicy, która występuje w podejściu autorów trojana obecnego i tego z poprzedniego postu. Jak pamiętamy tam autor nie dość, że stosował różnego rodzaju klucze xor’ujące to jeszcze zmieniały się w nieznacznym stopniu same procedury szyfrowania. Tutaj spoglądając na wygląd ciągów reprezentujących zaszyfrowane dane:

Można zakładać, że procedura deszyfrująca jest jedna, globalna. Po dokładnej analizie okazuje się, że faktycznie tak jest i nadszedł czas żeby przyjrzeć się jej bliżej.
Oczywiście jej lokalizację można w prosty sposób ustalić po przez przejście do kawałka kodu, który odwołuje się do jednego z zaszyfrowanych ciągów:

Wywołanie funkcji deszyfrującej. Oczywiście argumenty, są przekazywane zgodnie z konwencja __fastcall typową dla Borlanda.

[=]Analiza[=]
Procka deszyfrująca przedstawia się następująco:

gdzie:
ESI – długość zaszyfrowanego ciągu
Local.1 – pointer na zaszyfrowany ciąg
Jak widać procka jest o wiele pokaźniejsza od tych, które mogliśmy obserwować w poprzednim malware’e.
[=]Deszyfrowanie[=]
Bez większe zastanawiania się tworzymy decryptor, który w pythonie przedstawia się następująco:

import sys
#Delephant decryption script 

ascii_table = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz+/"

def decrypt(encrypted):
    decrypted = []
    local_4 = 0
    edi     = 0
    for index in range(0,len(encrypted)):
        pos = ascii_table.find(encrypted[index])
        if pos < 0:
            return "Encrypted string is in unproper format"
        pos = pos + (local_4 << 6)
        local_4 = pos
        edi = edi + 6
        if edi < 8:
            continue
        edi = edi - 8
        local_4 = local_4 % ( 1 << (edi & 0xff ) )
        pos = ( pos >> (edi & 0xff) ) & 0x800000ff
        if pos < 0:
            pos = ( (pos - 1) & 0xffffff00 ) + 1
        decrypted.append( chr(pos) )
    return "".join(decrypted)

if __name__ == "__main__":
    if len(sys.argv) < 2:
        print "Usage: %s encrypted_string" % sys.argv[0]
        sys.exit(0)
    print decrypt(sys.argv[1])

Rezultat deszyfrowania losowo wybranych stringów:

Warto tutaj zauważyć jedną znacząco różnice:

MOV EAX,[Local.5] ; kolejny znak z zaszyfrowanego ciagu
MOV EDX,zloavgtr.00480BAC ; ASCI „0123456789ABCD….”
CALL StrPos
MOV EBX,EAX
DEC EBX

i odpowiednik tego kodu w Python’e:

pos = ascii_table.find(encrypted[index])

Trzeba być tutaj świadomym jednej rzeczy, a mianowicie tego ze StrPos Borlandowy indexuje pozycje znaków w stringu od 1 a find Pythonowy od 0. Dlatego też w kodzie pythona nie pojawia się dekrementacja wartości pozycji znaku do odszyfrowania.

[=]Epilog[=]
Jak można zauważyć, procedura deszyfrująca tego trojana jest objętościowa ok.3 razy większa od tych, z którymi mieliśmy do czynienie w poprzednim sampel’u co jednak nie przeszkodziło nam w stworzeniu python’ego decryptor’a.
Jeżeli chodzi o algorytmy wykorzystywanego przez ten malware’u do „szyfrowania„ skradzionych danych to są to przeważnie:
- URL Encode
- Base64
ze względu na powszechność nie zostały one tutaj opisane.

Na sam koniec dla ciekawych, chcących przeanalizować krok po kroku działanie decryptor’a pare stringów do deszyfracji:

“IKLuS6nlScK”
“IMvcRt9jOUVZRo1fRcDlSd9bT64X851oPMLkOsXX86DlSd9bT65jPMvqPI1l86DXRN1l84HfPsbqRou”
“H65aRtCWIMvZRt9oPNHlSomWK6zo86PXTczo86HfPsbqPI1kRtPXRMLkT6Kk”
“K6zo86PXTczoB21fRcPlScrb86baPMvqQMPfOs7dusyi865dPMvZQM4i86DlRdHX”
“Kt8eOIak84PXTczo86HfPsbqON8WOI1pTM4WSsLkQ64WP64WT65YPMnX86DlSd9bT65jPMvqPIu”
“LNDruN9fRoukBYukBYukBYukBZe”
“K6zo86rlT6bsRo1aPI1JPMTrSc5kvs4WSsLr84D1KbJ3Jo14HI1JHKTLKa5Enq4WP6LsPI1pPN8WKcLZOMHXStHoOMHlB21JRsnfOsbqOMrlSo1nTMKWLczZwY18OM9fR6bqPI1pPNKWGs5oTEDl86Hb85DbPtLoOMxdOI1ERtPXRMLkT6Kk”
“Gc5kOsyWINHX+Y0j84PbQNHl851XSc4WLczZwY0WBI1DQMDoRtDlPdGWIMvqPN9kPNGWHNXmR6zoPN8″

Delphi (tak tak, poczekajcie jeszcze pare lat i będzie wysyp trojanów pisanych w .NET… using System.malwares.bankers; i go go go !!! )

Nasz dzisiejszy „bohater” przedstawia się następująco:
[=]Dane[=]

Antywirus	Wersja	Ostatnia aktualizacja	Wynik
a-squared	4.5.0.24	2009.08.02	Trojan-Banker.Win32.Banker!IK
AhnLab-V3	5.0.0.2	2009.08.01	Win-Trojan/Banker.7315456.D
AntiVir	7.9.0.238	2009.08.02	TR/Agent.GGO.1
Antiy-AVL	2.0.3.7	2009.07.31	-
Authentium	5.1.2.4	2009.08.02	W32/Trojan.BZCX
Avast	4.8.1335.0	2009.08.01	Win32:Banker-CXH
AVG	8.5.0.406	2009.08.02	PSW.Banker4.AJJ
BitDefender	7.2	2009.08.02	Generic.Spy.Bank.ZWQ.720719B9
CAT-QuickHeal	10.00	2009.07.30	-
ClamAV	0.94.1	2009.08.02	-
Comodo	1840	2009.08.02	TrojWare.Win32.Spy.Banker.OHT
DrWeb	5.0.0.12182	2009.08.02	Trojan.PWS.Banker.12795
eSafe	7.0.17.0	2009.07.30	Win32.Banker.cwo
eTrust-Vet	31.6.6650	2009.08.01	-
F-Prot	4.4.4.56	2009.08.02	W32/Trojan.BZCX
F-Secure	8.0.14470.0	2009.08.01	Trojan-Banker.Win32.Banker.fgw
Fortinet	3.120.0.0	2009.08.02	Spy/Banker
GData	19	2009.08.02	Generic.Spy.Bank.ZWQ.720719B9
Ikarus	T3.1.1.64.0	2009.08.02	Trojan-Banker.Win32.Banker
Jiangmin	11.0.800	2009.08.02	-
K7AntiVirus	7.10.808	2009.08.01	-
Kaspersky	7.0.0.125	2009.08.02	Trojan-Banker.Win32.Banker.fgw
McAfee	5695	2009.08.01	PWS-Banker.gen.cb
McAfee+Artemis	5695	2009.08.01	PWS-Banker.gen.cb
McAfee-GW-Edition	6.8.5	2009.08.02	Heuristic.BehavesLike.Win32.Spyware.K
Microsoft	1.4903	2009.08.02	TrojanSpy:Win32/Banker.USW
NOD32	4299	2009.08.02	Win32/Spy.Banker.OHJ
Norman	6.01.09	2009.07.31	W32/Banker.BQZT
nProtect	2009.1.8.0	2009.08.02	-
Panda	10.0.0.14	2009.08.02	Trj/Banker.gen
PCTools	4.4.2.0	2009.08.02	TrojanSpy.Banker.ARXE
Rising	21.40.62.00	2009.08.02	Trojan.Spy.Win32.Banker.c
Sophos	4.44.0	2009.08.02	Mal/DelpBanc-A
Sunbelt	3.2.1858.2	2009.08.02	Bulk Trojan
Symantec	1.4.4.12	2009.08.02	Infostealer.Bancos
TheHacker	6.3.4.3.375	2009.08.01	Trojan/Spy.Banker.cwo
TrendMicro	8.950.0.1094	2009.07.31	-
VBA32	3.12.10.9	2009.08.02	Trojan-Spy.Win32.Banker.cwo
ViRobot	2009.7.31.1863	2009.07.31	-
VirusBuster	4.6.5.0	2009.08.02	TrojanSpy.Banker.ARXE

Dodatkowe informacje
File size: 7319552 bytes
MD5   : d9e6a8e34c8c6f33919c33889c23811c
SHA1  : 38bb2fbb82e419d044a2a9e9199eb948eb891679
SHA256: 9fe271dbe89dd60d072789f49197d217edf75d9ed5a46fc5e94e28c7522341d8
TrID  : File type identification65.9% (.EXE) InstallShield setup (43065/22/16)13.0% (.EXE) Win32 Executable Generic (8527/13/3)11.6% (.DLL) Win32 Dynamic Link Library (generic) (7583/30/2)3.1% (.EXE) Win16/32 Executable Delphi generic (2072/23)
3.0% (.EXE) Generic Win/DOS Executable (2002/3)
ssdeep: 98304:aVwdUDdAVtUSlUTE2PIEH4B4Yo1qIZtDxHw7SbrKD:anAUkQPIYA49m
PEiD  : -
RDS   : NSRL Reference Data Set

Ja kto przeważnie bywa sygnaturki, są bardzo ooooooogggggólne. Jeżeli nawet, któraś z nich wskazuje na jakiś bardziej konkretny typ trojana to analiza techniczna bardzoooooo mija się z rzeczywistością, weźmy chociażby :
Symantec – Infostealer.Bancos
Morał jest taki, że ludki pracujące nad tego typu malware’em, a m.in. są to osoby z brazylijskich slumsów oraz innych biednych krajów A.Pd, (polecam tutaj wystąpienie
Mikko Hypponen : Online Crime and Crime Online
) nie robią sobie urlopów .

[=]Prolog[=]
Jeżeli kiedykolwiek zdarzyło Ci się pisać w BCB/Delphi aplikację z GUI (bo na takich będziemy się skupiać) to możesz podejrzewać, a jeżeli już je reversowałeś to jesteś świadom, że narzut kodu wygenerowanego przez kompilator, który nie specjalnie nas interesuje jest dość spory. Dodatkowo mamy tu do czynienia z budową silnie obiektową (masa metod wirtualnych, delegaty [tak tak, borland dostarcza do tego celu specyfikatora „__closure”],wielodziedziczenie,itp.) przez co nasza analiza jest nieco „utrudniona”(interpretuj. utrudniać: wydłużać czas zabawy ). Dlatego też, pokarze parę narzędzi oraz plugin’ów do nich, które przyspieszą samą analizę kodu jak i pomogą nam na znalezienie tych fragmentów, które zastały napisane przez autora trojana.

[=]Analiza[=]
Na początku naszej analizy zastanówmy się jakie akcje są przeważnie wykonywane podczas początkowego uruchomienia trojana. Z mojego doświadczenia wynika, że są to przeważnie następujące działania :
- kopiowanie własnej instancji do katalogu systemowego
- dodanie wpisu w rejestrze pozwalającego na auto uruchomienie trojana po reboot’e systemu
- rejestracja zainfekowanej maszyny

Ok, na początek tyle ustaleń nam wystarczy teraz pojawia się kwestia jak zlokalizować ten kod?
Oczywiście niektórzy z was mogli pomyśle, od razu o rozwiązaniu w stylu ustawianiu BP na api, które w jakiś sposób są powiązane z wyżej wymienionymi akcjami. Jest to na pewno jakiś sposób, ale w przypadku aplikacji Borlandowskich warto użyć paru dodatkowych narzędzi poza disassambler’em i debugger’em żeby osiągnąć naprawdę interesujące rezultaty, ale o tym za chwilę. Obejrzyjmy wstępnie kod trojana:

Na chwilę obecną powyższy kod nie daje nam zbyt wiele informacji, widać „rzetelne sprawdzanie błędów” , tworzenie mutex’a i wywołanie paru metod na globalnym obiekcie off_500864.Pierwszą rzeczą, która z pewnością ułatwi nam dalsze analizowanie kodu są FLIRT’y(więcej informacji TU), które dostarcza nam IDA Pro w wersji komercyjnej. Trudno mi powiedzieć jak wygląda kwestia z wersją Free, niestety nie testowałem, także jeżeli ktoś z was będzie testował lub już to zrobił to dajcie znać . Załadujmy odpowiednie FLIRT’y i rzućmy okiem na kod po tym zabiegu:


Ahhh….na mój gust kod wygląda już znacznie lepiej .
Jak widać IDA zastąpiła większość wywołań VCL’owych metod sygnaturami przez co kod jest znacznie czytelniejszy. Warto jeszcze tutaj zastosować tryb:
Options->Demangled names
I przy wyborze „Show demangled C++ names as” zaznaczyć radio box „Names” czego rezultatem będzie poniższy wynik:

Wracając do kodu, osoby, które miały styczność czy to z BCB czy Delphi już na pewno rozpoznają ten fragment.Tak tak jest to standardowy kod, którego główny cel możemy określić na:
- automatyczne tworzenie form używanych w projekcie
oraz obsługę komunikatów do nich napływających.

Porównamy teraz kod z pod IDA’y z kodem jednej z moich aplikacji pisanych w RAD Studio 2007( dawne wersje nazywane były Borland C++ Builder):

Tak jak widać kod jest uderzająco podobny, z czego morał taki, że dzięki IDA’e i sygnaturką zaoszczędziliśmy czas na analizowaniu standardowych VCL’owych metod.

Ok, wszystko fajnie, ale dalej nie mamy żadnych szczegółów związanych z naszymi wcześniejszymi ustaleniami. Po listingu z IDA’y możemy stwierdzić, że przy uruchomieniu trojana tworzone są automatycznie 3 formy, co wiąże się z wywołaniem pewnych zdarzeń. Zanim jednak omówimy sobie te zdarzenia przyjrzyjmy się wszystkim formą. Do tego celu oczywiście posłużymy się resource editor’em. Wyróżnie tutaj dwa:

Komercyjny:
PE Explorer: genialny edytor zasobów i nie tylko. Umożliwia podgląd form znajdujących się w zasobach, komponentów znajdujących się na nich (Timerów,Buttonów,Obrazów,…) oraz ich właściwości.

Darmowy:
DFM Editor: autorstwa MiTeC’ka jest darmowym prawie że odpowiednikiem PE Explorer’a, jeżeli chodzi o samo edytowanie zasobów. Jedynym mankamentem tego narzędzia jest brak możliwości podglądu obrazków znajdujących się na formach co w przypadku identyfikacji przeznaczenia formy(np. dzięki umieszczonym bannerą czy imitacją form przeznaczonych do logowania, możemy określić jakich banków klienci są narażeni na atak przez danego trojana już po samym analizowaniu zasobów) jest bardzo użyteczne.
W naszych badaniach identyfikacja przeznaczania danej formy pod kątem konkretnego banku jest zbyteczna ( a nawet z paru względów zabroniona ). Rzućmy okiem do zasobów:

(Niektóre nazwy form były zbyt oczywistymi skrótami nazw banków przez co musiałem je troszeczkę ocenzurować.)

Jak widzimy trojan ten posiada sporą dawkę fałszywych form imitujących panel’e do logowania, wirtualne klawiatury, a skończywszy na oknach prezentujących imitacje crash’u IE czy nawet BSOD’a .
Jest jednak parę form. :
TAup – Application update?
TCMD – Commands ?
TFUNC – Functions ?

które nie posiadają charakterystycznych Bitmap, lecz np. komponenty takie jak :
TTimer
TIdSMTP
TIdMessage

i tym formą się przyjrzymy.
Przeglądając komponenty znajdujące się na wyżej wymienionych formach szybko dochodzimy do wniosku, że tak naprawdę tylko TCMD jest formą, która może nas zainteresować, ponieważ:
TAup – co prawda posiada komponent TTimer lecz nie ma on podczepionego event handler’a.

Czyżby autor trojana doznał chwilowego przebłysku oraz chęci dodania kolejnej funkcjonalności po czym, po krótkie chwili porzucił tą idee, oraz wszelkie elementy z nią związane? Tego się nigdy nie dowiemy.

TFUNC – ta forma jest kompletnie pusta.
Nie mogę tego inaczej skomentować niż jako wyjątkowego przejawu nonszalancji .

TCMD
Rzućmy okiem na najbardziej interesujące nas komponenty oraz ich własności:

object CMD: TCMD
  OnActivate = FormActivate
  OnCreate = FormCreate
  object TPrincipal: TTimer
    OnTimer = TPrincipalTimer
    Left = 8
  end
  object Tcook: TTimer
    Interval = 100
    OnTimer = TcookTimer
    Left = 40
  end
  object Tsite: TTimer
    Enabled = False
    Interval = 50
    OnTimer = TsiteTimer
    Left = 72
  end
  object Tjanela: TTimer ;
            nie wierzcie, że event handler jest ustawiany dynamicznie:P
	To raczej kolejny przejaw wrodzonej rozrzutności autora malware’u.
    Left = 104
  end
  object Taup: TTimer
    Enabled = False
    Interval = 720000
    OnTimer = TaupTimer
    Left = 136
  end
end

Jak widać forma ta posiada obsłużone dwa zdarzenia:

  OnActivate = FormActivate
  OnCreate   = FormCreate

Oba, są idealne do tego żeby podpiąć w ich obsłudze wszystkie 3 wymienione przeze mnie początkowe działania wykonywane przez większość trojanów.
W pozostałych event handler’ach:

TaupTimer
TsiteTimer
TcookTimer
TPrincipalTimer

związanych z eventem OnTimer:
można się raczej spodziewać akcji takich jak:
- aktualizacji trojana
- wysyłania skradzionych danych do twórcy malware’u
- monitorowania aktualnych procesów w systemie (i cykliczne ubijanie np. firewall’a)
czy monitorowania odwiedzanych stron.

Ok., mamy więc ustalone parę procek, których kod chcielibyśmy prześledzić. Nasuwa się pytanie:
W jaki sposób uzyskać ich VirtualAddress?
Odpowiedzią jest:
DeDe
Wszystkie informacje o DeDe jak i sam tool znajdziecie tutaj RCE Tools.

Ładujemy naszego trojana w DeDe i po parunastu sekundach otrzymujemy taki o to rezultat:

Wspaniale! Jak możemy zaobserwować na powyższym screen’e DeDe dostarczyło nam informacji o zdeklarowanych przez użytkownika klasach (np. TCMD), Event handler’ach oraz miejscach ich lokalizacji!
Podsumowując uzyskane informacje mamy:

OnTime:

TaupTimer         = 004FD5C8
TsiteTimer          = 004FD0A0
TcookTimer 	      = 004FC834
TPrincipalTimer = 004FACE4

oraz eventy związane bezpośrednio z formą:

OnActivate = FormActivate =  004F7C44
OnCreate   = FormCreate    =  004FAC44

Oczywiście teraz nasza analiza staje się o wiele wiele prostsza, ponieważ bezpośrednio możemy zająć się interesującymi nas fragmentami kodu bez przedzierania się przez standardowe procedury.
Dla potwierdzenia wcześniejszych założeń związanych z operacjami wykonywanymi na starcie przez trojana, rzućmy okien na kod wykonywany przy event’e OnCreate, czyli:
FormCreate @ 004FAC44:

Mhmm sporo call’i, których IDA nie rozpoznała jako standardowych wywołań, więc najprawdopodobniej, są to pomocnicze metody napisane przez „programistę”. Zanim jednak przejdziemy do ich przeglądania, skorzystamy ponownie z dobrodziejstwa informacji dostarczanych przez DeDe, a mowa tutaj dokładnie o pliku MAP.

Dzięki wyexportowaniu informacji takich jak:

- event handlers
- control references

do pliku map

oraz załadowaniu go do IDA’y: (polecam plugin Fast IDB2Sig and LoadMap) disassemblowany przez nas kod staje się ponownie jeszcze bardziej czytelny:

To co najbardziej rzuca się w oczy to fakt zamiany nazwy call’a i jego komentarza z :

loc_4FACBD:
mov     dl, 1
mov     eax, [ebx+318h] ;
call    unknown_libname_172 ; Delphi2006/BDS2006 Visual Component Librar

na

loc_4FACBD:
mov     dl, 1
mov     eax, [ebx+318h] ; Taup:N.A.
call    SetEnabled      ; ExtCtrls.TTimer.SetEnabled(TTimer;Boolean)

odrazu widać, że jest to fragment kodu aktywujący Timer : Taup.
Ok, przyjrzyjmy się którejś z metod, której sposób działania jest nam jeszcze nie znany. Sprawdźmy jako pierwszą :
sub_483BE8

Ahh jak widać metoda ta wykonuje operacje na rejestrze, a po głębszej analizie okazuje się, że dodaje ona do klucza :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
wartość : Windows32 zawierającą scieżkę do kopi trojana, czyli
sub_483BE8 możemy zaklasyfikować jako :
- dodanie wpisu w rejestrze pozwalającego na auto uruchomienie trojana po reboot’e systemu

Super!!! jedno z założeń odnalezione. Idźmy dalej:
sub_483D78:

Jak widać w najwyżej położonym bloku widocznym na screen’e, zostaje sprawdzona wersja systemu operacyjnego ( Windows XP/NT/98 itd.) i na tej podstawie podejmowane, są działanie takie jak:
deskrypcja stringu
pobranie parametru wywołania aplikacji
oraz wykonanie kopi pliku gdzie parametrami, są rezultaty operacji dwóch poprzednich funkcji…czy coś wam to mówi ?,,,,,a teraz
CopyFile(ParamStr(),Decrypt()) ?
Tak jest! Oczywiście widać tutaj bloki instrukcji odpowiedzialnych za kopiowanie instancji trojana do charakterystycznych katalogów uzależnionych od wersji systemu Windows.
sub_483D78
- kopiowanie własnej instancji do katalogu systemowego

Na tym poprzestaniemy nasze dalsze dochodzenie, bo nie dokładna analiza techniczna była naszym celem, a jedynie przekonanie się o tym jaki potencjał niesie zastosowanie :
- sygnatur IDA’y
- informacji o adresach metod/obiektów uzyskanych dzięki DeDe
oraz pliku MAP

A co z naszym ulubionym Olkiem ? Czyż nie było by miło prowadzić dynamicznej analizy kodu mając do dyspozycji możliwości Olka ,sygnaturki IDA’y i możliwość załadowania pliku MAP ? Oczywiście byłoby, a najlepsze w tym jest to, że da się to osiągnąć!

[=]Olly’s time[=]
Żeby osiągnąć powyższe możliwości wystarczy tak naprawdę jeden plugin:
GoDup

Żeby dostrzec różnice po zastosowaniu kolejnych zabiegów w wykonaniu tego pluginu, ustawmy się na kod handler’a TPricipalTimer @ 004FACE4:

po zastosowaniu sygnatur:

dorzućmy jeszcze informacje z pliku MAP:

Czyż kod nie wygląda piękniej? .