> Кроме функции ZwOpenKey есть ещё NtOpenKey и для остальных > аналогично.. Надо перехватывать независимо и те и другие > или есть какой-то более умный способ? А в ядре, Zw - это stub, который вызывает системный сервис (через таблицу системных сервисов), а Nt - собственно функция.
Hi, all.
Требуется написать приложение максимально защищённое от следующего сценария: моё приложение устанавливается и запускается, затем пользователь открывает ie и заходит на страницу с эксплойтом в результате чего в процессе ie незаметно запускается вредоносный код, который атакует мой процесс и используя его делает в системе некоторые операции (по ряду причин, напрямую ему эти опреации делать невозможно или очень неудобно).
Моя программа - это простейшее win32 приложение, оно создаёт несколько окон. Это не COM-сервер, нет никаких объектов DDE, pipe-ов,
сокетов и т.п. Другими словами приложение, скажем так, "минимально
заиинтересовано" в общении со своим программным окружением. Максимум - используются Common Controls (которые требуют всё-таки
проинициализировать COM). Кикие существует способы нетривиальным
образом повлиять на работу этого процесса без вмешательства пользователя, т.е. заставить его выполнять некий внешний алгоритм, в идеале просто запустить из его контекста свой код (всё только из 3-го кольца разумеется и _после того как процесс уже был запущен_ (и он не собирается больше загружать библиотеки), т.е. пропатчить exe-шник и т.п. - отпадает) и какова может быть защита от них. Я вижу следующие:
- загрузить в него dll, используя windows hooks;
- использовать вызов CreateRemoteThread;
- OpenProcess, WriteProcessMemory;
- отправлять его окнам и нитям сообщения (например wm_copydata, затем
wm_timer, или же как ниже);
- эмулируя нажатия клавиш и события мыши, например вызывая
SendInput, сделать что-то "от имени" пользователя;
- использовать средства отладки, встроенные в windows;
- можно даже записать какую-нить гадость в буфер обмена и ждать,
что при вставке наступит переполнение буфера или ещё чего.
А какие ещё у простейшего win32 приложения с оконным интерфейсом уже
есть дыры и как их можно закрыть (допускается даже написание специального драйвера)? (Интересны случаи как когда атакующее приложение выполняется с правами админа, так и без.)
Пропатчить *.exe - тоже можно26.09.06 16:39 Автор: Neznaika <Alex> Статус: Member
Ещё вспомнил! было что-то на тему \Device\PhysicalMemory. Оно доступно из 3-го кольца до win2k3 sp1 и позволяет обращатся к физической памяти. Насколько я понял оно опасно (особенно если текущий пользователь - админ) Как с ним лучше побороться?
Вроде все перечислил. Кроме KnownDlls26.09.06 13:51 Автор: amirul <Serge> Статус: The Elderman
> - загрузить в него dll, используя windows hooks;
Даже не знаю как это ограничить для админа. Наверное только драйвером
> - использовать вызов CreateRemoteThread; > - OpenProcess, WriteProcessMemory; > - использовать средства отладки, встроенные в windows; Эти три способа требуют сначала открыть процесс. Причем если у открывающего процесса есть DebugPrivilege (админский процесс очень легко может ее получить), то права доступа проверяться не будут вообще. Так что здесть тоже только хук на сервис ядра и собственная проверка.
> - отправлять его окнам и нитям сообщения (например > wm_copydata, затем > wm_timer, или же как ниже); > - эмулируя нажатия клавиш и события мыши, например вызывая > SendInput, сделать что-то "от имени" пользователя; > - можно даже записать какую-нить гадость в буфер обмена и > ждать, > что при вставке наступит переполнение буфера или ещё чего. Ну от этих угроз можно избавиться просто аккуратно написав свою WndProc.
> А какие ещё у простейшего win32 приложения с оконным > интерфейсом уже > есть дыры и как их можно закрыть (допускается даже > написание специального драйвера)? (Интересны случаи как Перехват ZwUserSetWindowsHook и запрет установки неизвестных хуков.
Перехват ZwOpenProcess и запрет открытия своего процесса
Аккуратное написание WndProc
> когда атакующее приложение выполняется с правами админа, > так и без.)
PS: Есть еще HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs
Длл-ка, прописанная здесь попадет в любой запускаемый процесс. Список "известных дллок" инициализируется при загрузке, так что до перезагрузки с твоим процессом ничего не случится.
Здесь нужно либо периодически проверять, чтобы в ключ не менялся, либо опять таки перехватывать ZwOpenKey/ZwCreateKey (либо ZwSetValueKey) и не давать создавать новых записей в этом ключе (не забывать о других ControlSet-ах).
А как соотносятся наборы функций Nt* и Zw*26.09.06 15:43 Автор: vasyacoder Статус: Незарегистрированный пользователь
Кроме функции ZwOpenKey есть ещё NtOpenKey и для остальных аналогично.. Надо перехватывать независимо и те и другие или есть какой-то более умный способ?
В юзере - это одно и то же26.09.06 15:53 Автор: amirul <Serge> Статус: The Elderman
> Кроме функции ZwOpenKey есть ещё NtOpenKey и для остальных > аналогично.. Надо перехватывать независимо и те и другие > или есть какой-то более умный способ? А в ядре, Zw - это stub, который вызывает системный сервис (через таблицу системных сервисов), а Nt - собственно функция.
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
