Контроль компонентов

← →
not_dev (2006-01-20 12:39) [0]

Доброе время суток, Мастера.

Интересует организация контроля компонентов а-ля Outpost. Не мог ли бы вы растолковать каким образом он это осуществляет? Перехват чего обычно используется, каким образом отследить изменение памяти чужой программы со стороны агрессора? Я понимаю что вопросов много, но хотя бы наведить на мысль, подтолкните )

--
С уважением, not_dev

← →
Rouse_ © (2006-01-20 13:58) [1]

Ничего не понял. Какие такие компоненты контролирует Outpost?

← →
not_dev (2006-01-20 14:16) [2]

ммм... контроль компонентов сторонних приложений во избежание injectирования и т.д., в аутпосте сделано чтобы модули, находящиеся в контексте ie, к примеру, не могли навредить машине.

← →
Игорь Шевченко © (2006-01-20 15:18) [3]

Rouse_ © (20.01.06 13:58) [1]

Поставь outpost, узнаешь, какие компоненты :)

← →
Игорь Шевченко © (2006-01-20 15:19) [4]

> Перехват чего обычно используется, каким образом отследить
> изменение памяти чужой программы со стороны агрессора?

Обычно используется перехват WriteProcessMemory и CreateRemoteThread, тем более, что Outpost устанваливает свои драйверы ядра, в этом случае задача централизованного перехвата несколько упрощается.

← →
not_dev (2006-01-20 15:38) [5]

можно ли не выходя в ring0 осуществлять более менее нормальный перехват подобных изменений?

по поводу WriteProcessMemory и CreateRemoteThread спасибо. что обычно еще используют агрессоры?

в кратце опиуш проблему. есть клиен-серверное ПО, цель агрессора увеличить возможности и функционал клиента. внедрение происходит по нескольким направлением, непосредственное изменение поведения клиента, вмешательство в передачу данных на сервер и т.д.

← →
Игорь Шевченко © (2006-01-20 15:59) [6]

not_dev (20.01.06 15:38) [5]

> что обычно еще используют агрессоры?

Не могу сказать, сам не агрессор.

> есть клиен-серверное ПО, цель агрессора увеличить возможности
> и функционал клиента. внедрение происходит по нескольким
> направлением, непосредственное изменение поведения клиента,
> вмешательство в передачу данных на сервер и т.д.

Проверка контрольных сумм не спасет ?

← →
not_dev (2006-01-20 17:30) [7]

все что могу и так контролирую на целостность (MD5).

проблема в том что изменения производятся в памяти клиента. а так же за счет перекрытия некоторых WinAPI функций.

к примеру, ряд агрессоров перекрывает QueryPerformanceCounter, изменяя в n-раз результат. что-то приблизительно в таком духе:

library speed; uses windows, myhook; var NextQueryPerformanceCounter: function(var lpPerformancecount: Int64): longbool; stdcall; OldQueryPerformanceCounter: function(var lpPerformancecount: Int64): longbool; stdcall; function myQueryPerformanceCounter(var lpPerformancecount: Int64): longbool; stdcall; begin result:=NextQueryPerformanceCounter(lpPerformancecount); if GetAsyncKeyState(VK_CAPITAL) < 0 then lpPerformancecount := round(lpPerformancecount*1.5); end; begin OldQueryPerformanceCounter := getprocaddress(getmodulehandle("kernel32.dll"),"QueryPerformanceCounter"); HookFkt(@OldQueryPerformanceCounter,@myQueryPerformanceCounter ,@NextQueryPerformanceCounter); end.

как можно бороться с подобными переопределениями WinAPI? =(

← →
Игорь Шевченко © (2006-01-20 18:58) [8]

> как можно бороться с подобными переопределениями WinAPI?
>

Вот как я боролся с подменой NtQuerySystemInformation

unit CheckNtDll; interface uses Windows, HsNtDef; function RealQueryListInformation (InfoClass: Integer; var rc: NTSTATUS; var ReturnLength: DWORD): Pointer; function IsNtDllHooked: Boolean; implementation uses SysUtils, NtDll, PeImage, NtStatusDefs; {$IFDEF VER140} {$WARN SYMBOL_PLATFORM OFF} {$ENDIF} type TSysCallData = array[0..13] of Byte; TNtQuerySystemInformation = function (SystemInformationClass: LongInt; SystemInformation: Pointer; SystemInformationLength: ULONG; ReturnLength: PDWORD): NTSTATUS; stdcall; var FRealQuerySystemInformation: TNtQuerySystemInformation; function RealQueryListInformation (InfoClass: Integer; var rc: NTSTATUS; var ReturnLength: DWORD): Pointer; var ListSize: Integer; begin ListSize := $400; { ═рўры№э√щ ЁрчьхЁ сєЇхЁр } GetMem(Result, ListSize); rc := FRealQuerySystemInformation(InfoClass, Result, ListSize, @ReturnLength); while rc = STATUS_INFO_LENGTH_MISMATCH do begin FreeMem(Result); ListSize := ListSize * 2; GetMem(Result, ListSize); rc := FRealQuerySystemInformation(InfoClass, Result, ListSize, @ReturnLength); end; if rc <> STATUS_SUCCESS then begin FreeMem(Result); Result := nil; end; end; procedure MakeRealQS (const SysCallData: TSysCallData); var OldProtection: DWORD; FuncPtr: Pointer; begin FuncPtr := VirtualAlloc(nil, $1000, MEM_COMMIT, PAGE_READWRITE); Win32Check(Assigned(FuncPtr)); Move(SysCallData, FuncPtr^, SizeOf(SysCallData)); Win32Check(VirtualProtect(FuncPtr, SizeOf(SysCallData), PAGE_EXECUTE, OldProtection)); @FRealQuerySystemInformation := FuncPtr; end; function IsNtDllCodeHooked (const FileName: string; ProcOffset: ULONG): Boolean; var Image: THSPeImage; SysCall: TSysCallData; SysCall2: TSysCallData; QSPtr: Pointer; begin Image := THSPEImage.Create (FileName); try Move(Image.RVAData[ProcOffset]^, SysCall, SizeOf(SysCall)); finally Image.Free; end; QSPtr := GetProcAddress(GetModuleHandle("ntdll.dll"), "NtQuerySystemInformation"); Move(QSPtr^, SysCall2, SizeOf(SysCall2)); Result := not CompareMem(@SysCall, @SysCall2, SizeOf(SysCall)); if Result then MakeRealQS (SysCall); end; function IsNtDllHooked: Boolean; const SDllPath = "%SystemRoot%\system32\ntdll.dll"; var DllPath: ZString; HFile, HMap: THandle; Map: Pointer; Headers: PImageNtHeaders; QSysInfo: Pointer; begin Result := false; Win32Check( ExpandEnvironmentStringsA(SDllPath, DllPath, SizeOf(DllPath)) <> 0); HFile := CreateFileA(DllPath, GENERIC_READ, FILE_SHARE_READ, nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, INVALID_HANDLE_VALUE); Win32Check(HFile <> INVALID_HANDLE_VALUE); try HMap := CreateFileMappingA(HFile, nil, PAGE_READONLY, 0, 0, nil); Win32Check(HMap <> 0); try Map := MapViewOfFile(HMap, FILE_MAP_READ, 0, 0, 0); Win32Check(Assigned(Map)); try Headers := RtlImageNtHeader(HMODULE(Map)); if Assigned(Headers) then Result := Headers.OptionalHeader.ImageBase <> GetModuleHandle("ntdll.dll"); if not Result then begin QSysInfo := GetProcAddress(GetModuleHandle("ntdll.dll"), "NtQuerySystemInformation"); if Assigned(QSysInfo) then begin Result := (Cardinal(QSysInfo) <= Headers.OptionalHeader.ImageBase) or (Cardinal(QSysInfo) > Headers.OptionalHeader.ImageBase + Headers.OptionalHeader.SizeOfCode); if not Result then Result := IsNtDllCodeHooked(DllPath, ULONG(QSysInfo) - Headers.OptionalHeader.ImageBase); end else Result := true; end; finally UnmapViewOfFile(Map); end; finally CloseHandle(HMap); end; finally CloseHandle(HFile); end; end; initialization finalization if Assigned(FRealQuerySystemInformation) then VirtualFree(@FRealQuerySystemInformation, $1000, MEM_DECOMMIT); end.

Для системных вызовов из NTDLL этот код будет работать, для остальных не всегда, так как не происходит настройка адресов.

По меньшей мере можно попытаться понять, как происходит обнаружение того, что функцию подменили.

← →
not_dev (2006-01-20 19:07) [9]

огромное спасибо! я если честно, сразу рассчитывал на помощь одного из Мастеров. особенно хотелось бы услышать Ms-Rem"a. он на этом верняк собаку съел.

← →
not_dev (2006-01-20 19:10) [10]

данный код, что вы привели по сути позволил бы защититься от тех процессов, которые скрываются подменой NtQuerySystemInformation? я все правильно понимаю?

← →
Игорь Шевченко © (2006-01-20 21:04) [11]

not_dev (20.01.06 19:10) [10]

Да, конечно. Именно для этого он и предназначен. Основная идея в том, чтобы сравнить реальный адрес функции с тем, который должен быть, судя по файлу на диске. Есть более сложный алгоритм, который использует, в частности, Microsoft, с анализом таблиц экспорта и импорта в файлах на диске, эскпорта в своем файле, и импорта в одном из интересующих системных.

← →
not_dev (2006-01-21 04:27) [12]

По поводу более сложного алгоритма. Не видели ли вы где либо реализаций подобного? В чем заключается анализ таблиц экспорта / импорта?

Ваш алгоритм я разобрал до конца, понял принцип, знаю как использовать и как адаптировать под себя с учетом моих потребностей. Но понимаю, что со стороны агрессора не составляет особого труда добиться одинаковых адресов функции (реального и на диске).

Господа, может быть у кого есть еще идеи по поводу контроля компонентов?

← →
not_dev (2006-01-21 15:21) [13]

Игорь Шевченко © (20.01.06 21:04) [11]
Еще один вопросик, вы ведь не только сравниваете адрес в памяти и адрес на диске. Вы ведь еще сравниваете 13 байт API code в памяти и на диске, разве это не гарантирует 100% определение хука?

Не могли бы вы все-таки несколько поподробнее описать алгоритм Microsoft. Какого рода анализ происходит?

Простите за беспокойство.

--
С уважением, not_dev

← →
not_dev (2006-01-21 15:29) [14]

sorry, 14 байт )

> Но понимаю, что со стороны агрессора не составляет особого
> труда добиться одинаковых адресов функции (реального и на
> диске).

Вроде составляет. Системная DLL грузится по заранее определенному адресу, поэтому максимум, что агрессор может сделать, это заменить сам код в загруженной системной DLL, для этого и производится сравнение.

Почему сравнивается такое количество байт, потому что размер сравниваемой функции (NtQuerySystemInformation) как раз составляет именно столько байт, и он, ко всему прочему, является позиционно-независимым кодом, в нем не производится настройка адресов (хотя это в данном случае лишнее, потому что ntdll и kernel32 всегда загружаются по одному и тому же адресу и не могут быть перемещены).

> По поводу более сложного алгоритма. Не видели ли вы где
> либо реализаций подобного? В чем заключается анализ таблиц
> экспорта / импорта?

Анализ таблицы экспорта/импорта нужен для того, чтобы агрессор не смог, подменив функции GetProcAddress/GetModuleHandle/LoadLibrary(Ex) возвращать "правильные" значения адресов, при этом, в реальности, подменяя их.

← →
not_dev (2006-01-23 14:30) [16]

спасибо за разъяснения.

Контроль компонентов Найти похожие ветки