информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Страшный баг в WindowsАтака на Internet
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Ядро Linux избавляется от российских... 
 20 лет Ubuntu 
 Tailscale окончательно забанила... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / hacking
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
В юзере - это одно и то же 26.09.06 15:53  Число просмотров: 2995
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Кроме функции ZwOpenKey есть ещё NtOpenKey и для остальных
> аналогично.. Надо перехватывать независимо и те и другие
> или есть какой-то более умный способ?
А в ядре, Zw - это stub, который вызывает системный сервис (через таблицу системных сервисов), а Nt - собственно функция.

Перехватывать лучше в ядре, ибо никто не сможет запретить процессу злоумышленника вызвать напрямую скажем int 0x2e и открыть процесс в обход любых хуков, поставленных в юзермоде.
Способ известный и давно применяется всеми, кому не лень (впервые предложен, насколько я помню Руссиновичем):
http://www.google.com/search?client=opera&rls=ru&q=keservicedescriptortable+hook&sourceid=opera&ie=utf-8&oe=utf-8
<hacking>
какие существуют общие способы влезть в чужой процесс 26.09.06 12:13  
Автор: vasyacoder Статус: Незарегистрированный пользователь
<"чистая" ссылка>
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
<"чистая" ссылка>
В Win2000/XP/2003 - это делается через "PendingFileRenameOperations".

И после первого же reboot'a - будет выполняться уже не совсем твое приложение, а пропатченное.
ещё я что-то слышал про \Device\PhysicalMemory 26.09.06 15:54  
Автор: vasyacoder Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Ещё вспомнил! было что-то на тему \Device\PhysicalMemory. Оно доступно из 3-го кольца до win2k3 sp1 и позволяет обращатся к физической памяти. Насколько я понял оно опасно (особенно если текущий пользователь - админ) Как с ним лучше побороться?
Вроде все перечислил. Кроме KnownDlls 26.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 - собственно функция.

Перехватывать лучше в ядре, ибо никто не сможет запретить процессу злоумышленника вызвать напрямую скажем int 0x2e и открыть процесс в обход любых хуков, поставленных в юзермоде.
Способ известный и давно применяется всеми, кому не лень (впервые предложен, насколько я помню Руссиновичем):
http://www.google.com/search?client=opera&rls=ru&q=keservicedescriptortable+hook&sourceid=opera&ie=utf-8&oe=utf-8
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach