Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
#122 22.08.02 18:28
Publisher: dl <Dmitry Leonov>
Отредактировано 31.08.02 04:13 Количество правок: 3
|
#122
,
Начинаем подводить летние итоги. Точнее, то, что осталось в памяти.
Начнем со свеженайденного страшного Windows-бага [ http://www.bugtraq.ru/rsn/archive/2002/08/10.html ], против которого вроде как нет противоядия. Вкратце о сути идеи. Как известно, в Windows любая программа может послать любому окну любое сообщение (на самом деле, с некоторыми оговорками, о которых позже), при этом источник сообщения определить невозможно. Так было заведено давным давно, и даже не с NT 3.5 (3.1 на самом деле), как пишет автор сообщения, а со старого доброго 16-битного Windows - потому как смена этого механизма привела бы к не самым большим, но все же проблемам по переносу старого 16-битного софта под Win32 (если кто не помнит, для перехода индустрии под Win32 потребовался выход Windows'95, до тех же пор многие производители софта особо и не утруждали себя этим переносом).
Итак, схема взлома. Находим подходящий сервис, исполняющийся из-под аккаунта, с бОльшими правами, чем наш текущий, который...
Полный текст
|
|
Продолжая тему интерактивных сервисов... (Updated) 23.08.02 11:08
Автор: Glory <Mr. Glory> Статус: Elderman
Отредактировано 23.08.02 11:23 Количество правок: 4
|
> Вот если б в примере оказался какой-нибудь стандартный сервис, это
> было бы гораздо интереснее.
С правами админа можно вызвать принудительный шатдаун системы, например, кильнув lsass.exe. Или просто вызвать функцию InitiateSystemShutdown(), указав в ней нужное время до останова системы. Тогда winlogon выводит окно в котором пишет, что, мол за такой криминал система будет остановлена через столько-то, и начинает в нем отсчет времени. Теперь два вопроса:
1. Можно ли в принципе что-либо сотворить с этим окном, чтобы воспользоваться обсуждаемой уязвимостью?
2. Можно ли как-нибудь вызвать это окно, сидя под юзером (т.е. вызвать InitiateSystemShutdown()). По умолчанию, юзерам разрешен останов системы.
|
| |
Не понял... Смотри внутри 23.08.02 14:30
Автор: HandleX <Александр М.> Статус: The Elderman
|
2. Можно ли как-нибудь вызвать это окно, сидя под юзером
> (т.е. вызвать InitiateSystemShutdown()). По умолчанию,
> юзерам разрешен останов системы.
^^^^^^^^
Дык если разрешён, то и вызови это окно, не мучайся...
|
| | |
Самому просто в лом проверять. 23.08.02 16:07
Автор: Glory <Mr. Glory> Статус: Elderman
|
> 2. Можно ли как-нибудь вызвать это окно, сидя под юзером
> > (т.е. вызвать InitiateSystemShutdown()). По умолчанию,
> > юзерам разрешен останов системы.
> ^^^^^^^^
>
> Дык если разрешён, то и вызови это окно, не мучайся...
Ну я тоже так подумал, просто спросил для уверенности на 100%. Более интересно то, что с этим окном можно намутить ;-).
|
| | | |
Окно уже есть. 23.08.02 21:50
Автор: Biasha <Бяша> Статус: Member
|
winlogon.exe
Окно: NetDDE Agent
HWND: 00010028
Стиль окна: 04CF0000 WS_CLIPSIBLINGS WS_BORDER WS_DLGFRAME WS_SYSMENU WS_THICKFRAME WS_MINIMIZEBOX WS_MAXIMIZEBOX
Расшир. стиль: 00000108 WS_EX_CONTROLPARENT WS_EX_STATICEDGE WS_EX_APPWINDOW WS_EX_LAYERED WS_EX_LAYOUTRTL
---
Только пока у меня, сходу, ничего не получилось с ним сделать.
В течении месяца займусь этим серьёзно :)
|
|
А куда к этому замечания писать? И кому :)? И вообще, что это такое? :) 23.08.02 02:37
Автор: Biasha <Бяша> Статус: Member
|
|
|
| |
Как несложно заметить, пройдя по ссылке "Полный текст"... 23.08.02 04:02
Автор: dl <Dmitry Leonov>
|
...сие есть заготовка очередного выпуска обзора, кои я еще не оставил надежду более-менее нерегулярно выпускать.
Соответственно, "кому" - мне, "куда" - либо сюда, либо в почту (по вкусу).
Стал выкладывать заранее - во-первых, чтобы перед тем как вывалить это дело в рассылку иметь возможность скорректировать откровенные ляпы, во-вторых, чтоб заставить самого себя покончить с этим выпуском в течение нескольких дней :)
|
| | |
сюда :) 23.08.02 05:16
Автор: Biasha <Бяша> Статус: Member
Отредактировано 23.08.02 05:44 Количество правок: 2
|
Начнем со свеженайденного страшного Windows-бага, против которого вроде как нет противоядия. Вкратце о сути идеи. Как известно, в Windows любая программа может послать любому окну любое сообщение, при этом источник сообщения определить невозможно.
Не любая любому, это только если они на одном десктопе. А десктоп – защищаемый об'єкт – право посылать сообщение окнам на нём нужно ещё иметь.
Так было заведено давным давно, и даже не с NT 3.5 (3.1 на самом деле), как пишет автор сообщения, а со старого доброго 16-битного Windows - потому как смена этого механизма привела бы к не самым большим, но все же проблемам по переносу старого 16-битного софта под Win32
Мало того, это было бы непрактично и неправильно – делать иначе. Почему бы ни дать приложениям, запущенным на одном десктопе, взаимодействовать между собой, используя хоть и не защищённый, но, за счёт этого, эффективный механизм?
(если кто не помнит, для перехода индустрии под Win32 потребовался выход Windows'95, до тех же пор многие производители софта особо и не утруждали себя этим переносом).
Итак, схема взлома. Находим подходящий сервис, исполняющийся из-под системного аккаунта и способный открывать интерактивные окна.
Не совсем корректно. Что такое интерактивные окна? – те, которые видно? Ну так это вовсе не обязательно, можно и скрытому слать. Точнее сказать "находим поток, обрабатывающий оконные сообщения нашего десктопа, и запущенный в процессе, с правами системы". Как частный, более простой для поиска, случай, достаточно найти окно на нашем десктопе, созданное процессом с системным акаунтом. В подавляющем большинстве случаев (возможно всегда, хотя очень сомневаюсь) это будет окно какого-то интерактивного сервиса.
Находим в окне, которое открыл сервис, подходящий элемент управления (edit box) и вставляем туда побольше символов, включающих в том числе внедряемый код (между делом для этого, возможно, придется снять ограничение на количество символов, которые можно вставить в текстовое поле, но и это можно сделать, послав сообщение, так что это непринципиально). В итоге все это хозяйство оказывается где-то в недрах адресного пространства данного приложения. Где именно - можно определить экспериментальным путем, вставив в текст некую сигнатуру и найдя ее с помощью отладчика. Далее внедренный код надо бы как-то выполнить. На помощь приходит еще одно сообщение, WM_TIMER, в качестве одного из параметров которого можно указать адрес callback-функции. Стало быть, посылаем WM_TIMER, передав адрес, находящийся внутри блока наших засланных команд, после чего наш засланный код выполняется с системными правами.
Не обязательно с системными правами. Поток, в контексте которого будет выполнен код (это тот поток, который и обработал WM_TIMER, он же и создал окно), может использовать другие, нежели процесс, права. Например, используя механизм перевоплощения он может ограничить свои права до прав пользователя, на десктопе которого и созданы эти окна.
Из вышесказанного делается вывод о наличии принципиальной уязвимости системы передачи сообщений Windows и затягивается очередная песня про мастдай, потому как MSовцы ничего в ней не хотят менять.
Овцы сделали всё правильно. Десктоп и рабочая станция – защищаемые об'єкты. Чего ещё нужно для полного счастья?
Сразу скажу свое мнение о данной уязвимости. Схема хороша и заслуживает занесения в список проверяемых потенциальных уязвимостей отдельных сервисов, но говорить о жуткой неизлечимой дырке рановато. Конечно, наличие идентификатора источника сообщения могло бы пригодиться при программировании, но и в этом случае его анализ требовал бы усилий со стороны программиста. Полный запрет приема сообщений от сторонних процессов, пожалуй, нереален. Добавление такой возможности в список прав - ну, возможно, и помогло бы, но ведь существуют всякие автоматизаторы, частенько исполняющиеся с системными правами, так что при желании лазейку можно было бы и найти. Кроме того, не забудем о необходимости перетряхивания всего существующего софта, потому как просто так добавить опциональный параметр в оконную функцию вряд ли удастся.
Как я уже писал, параметр уже есть – можно запретить создание интерактивными сервисами окон на видимых десктопах вообще. Но зачем? Чтобы программисты третьих вендоров не писали уязвимый софт? Тогда и NULL в качестве lpSecurityAttributes при создании чего-либо (в том числе и файлов) нужно запретить передавать – чтобы каждый програмист несколько сот раз в день задумался о безопасности. Кому это нужно?
Кроме того, разрешая посылать сообщения другим, возможно и не подозревающим об этом приложениям, Win32 приобретает большую гибкость, большую функциональность. Цена – доверять самому себе (сообщениям своего десктопа и программам на нём запущеным).
Однако ж посмотрим, какие средства у нас есть на руках, чтобы бороться с данной проблемой. Во-первых, писать такие сервисы, открывающие интерактивные окна
Что такое "сервис, открывающий интерактивное окно"? Бывают интерактивные сервисы – те, что запускаются на WinSta0\Default, но что такое "интерактивное окно"?
- в принципе моветон, за который надо бить ногами, потому как есть стандартная схема, обеспечивающая взаимодействие сервиса с пользователем - написание вспомогательной программки, запускающейся с пользовательскими правами и тем или иным способом взаимодействующей с сервисом (хотя, в принципе, тут можно попробовать найти лазейку и встроиться в это взаимодействие).
Есть разница. Это "другое" взаимодействие неизбежно должно осуществляться с помощью защищаемых об'єктов. Поскольку нет иных разделяемых и не защищаемых, кроме GUI'шных, об'єктов, пригодных для взаимодействия через них (по крайней мере, я не знаю, и, кажется, так было где-то написано).
Далее, не совсем верно утверждение, что WM_TIMER не попадает в очередь сообщений и его нет возможности игнорировать - цитируя MSDN, "You can process the message by providing a WM_TIMER case in the window procedure. Otherwise, the default window procedure will call the TimerProc callback function specified in the call to the SetTimer function used to install the timer.".
Попадать в очередь сообщений и в оконную процедуру – не одно и тоже. Из того, что сообщение можно отфильтровать в оконной процедуре, вовсе не следует, что его можно отфильтровать. В MSDN не написано, но DispatchMessage вызывает TimerProc даже если hWnd = NULL. Так что если уж отфильтровывать, то в цикле сообщений, а не в оконной процедуре.
Желающие могут проверить - без какого-никакого цикла обработки сообщений никакой callback от таймера работать не будет, а стало быть, вставить свою обработку таки можно. Другой вопрос, кто этим озаботился :) Наконец, особые параноики наподобие авторов PGP, вообще не используют стандартные классы окон и до кучи используют дополнительный драйвер, защищающий память приложения.
Авторы PGP больше для меня не параноики:). PGP 7.1.1 (corporate desktop) включает интерактивный сервис :). Вот от них не ожидал. Так что PGP не только обеспечивает секретность и аутентичность вашей переписки, но и позволяет получить достойные вас права на локальной машине! :)
Таким образом, из общесистемной проблема все-таки переходит в разряд проблем авторов сервисов, на которых и надо перевести стрелки - в конце концов, и в проблеме постоянно вылезающих buffer overflow можно обвинять создателей C, но это нефункционально :) Вот если б в примере оказался какой-нибудь стандартный сервис, это было бы гораздо интереснее.
В стадии разработки :) Был человек, у которого "планировщик 2К" согрешил. Мне не удалось в ХР найти, но я не очень и искал.
Однако ж ситуация вовсе не безоблачна. Написав этот абзац, полез смотреть, что творится у меня под носом - увы, сходу нашлась пара примеров, Outpost и MDaemon, которые ведут себя так же. К чести Norton Antivirus, тот запускает отдельную программку с пользовательскими правами.
А вот NU2002 – не запускает. А может и запускает – это не показатель см. мою прогу в программинг (она, правда, тоже не всех грешников показывает, но лучше чем просто смотреть на тип сервиса вручную, или на заголовки окон).
Думаю, что можно найти немало других популярных сервисов, которые можно поймать на эту уловку.
Я уже думаю, что трудно найти такие, которых нельзя поймать :)
|
| | | |
сюда :) 23.08.02 06:10
Автор: dl <Dmitry Leonov>
|
> Начнем со свеженайденного страшного Windows-бага,
> против которого вроде как нет противоядия. Вкратце о сути
> идеи. Как известно, в Windows любая программа может послать
> любому окну любое сообщение, при этом источник сообщения
> определить невозможно.
> Не любая любому, это только если они на одном десктопе. А
> десктоп – защищаемый об'єкт – право посылать сообщение
> окнам на нём нужно ещё иметь.
Да, это понятно, я решил не усложнять, потому как обычно все все равно в рамках одного десктопа происходит. А вот в момент описания борьбы - да, согласен, пропустил (да и не программировал я их сам ручками, только описание давно смотрел, а сейчас поленился проштудировать, каюсь).
> Так было заведено давным давно, и даже не с NT 3.5
> (3.1 на самом деле), как пишет автор сообщения, а со
> старого доброго 16-битного Windows - потому как смена этого
> механизма привела бы к не самым большим, но все же
> проблемам по переносу старого 16-битного софта под
> Win32
> Мало того, это было бы непрактично и неправильно – делать
> иначе. Почему бы ни дать приложениям, запущенным на одном
> десктопе, взаимодействовать между собой, используя хоть и
> не защищённый, но, за счёт этого, эффективный механизм?
умгум
> (если кто не помнит, для перехода индустрии под
> Win32 потребовался выход Windows'95, до тех же пор многие
> производители софта особо и не утруждали себя этим
> переносом).
> Итак, схема взлома. Находим подходящий сервис,
> исполняющийся из-под системного аккаунта и способный
> открывать интерактивные окна.
>
> Не совсем корректно. Что такое интерактивные окна? – те,
> которые видно? Ну так это вовсе не обязательно, можно и
> скрытому слать. Точнее сказать "находим поток,
> обрабатывающий оконные сообщения нашего десктопа, и
> запущенный в процессе, с правами системы". Как частный,
> более простой для поиска, случай, достаточно найти окно на
> нашем десктопе, созданное процессом с системным акаунтом. В
> подавляющем большинстве случаев (возможно всегда, хотя
> очень сомневаюсь) это будет окно какого-то интерактивного
> сервиса.
Под интерактивными понимались те, которым можно послать сообщения.
> Находим в окне, которое открыл сервис, подходящий
> элемент управления (edit box) и вставляем туда побольше
> символов, включающих в том числе внедряемый код (между
> делом для этого, возможно, придется снять ограничение на
> количество символов, которые можно вставить в текстовое
> поле, но и это можно сделать, послав сообщение, так что это
> непринципиально). В итоге все это хозяйство оказывается
> где-то в недрах адресного пространства данного приложения.
> Где именно - можно определить экспериментальным путем,
> вставив в текст некую сигнатуру и найдя ее с помощью
> отладчика. Далее внедренный код надо бы как-то выполнить.
> На помощь приходит еще одно сообщение, WM_TIMER, в качестве
> одного из параметров которого можно указать адрес
> callback-функции. Стало быть, посылаем WM_TIMER, передав
> адрес, находящийся внутри блока наших засланных команд,
> после чего наш засланный код выполняется с системными
> правами.
>
> Не обязательно с системными правами. Поток, в контексте
> которого будет выполнен код (это тот поток, который и
> обработал WM_TIMER, он же и создал окно), может
> использовать другие, нежели процесс, права. Например,
> используя механизм перевоплощения он может ограничить свои
> права до прав пользователя, на десктопе которого и созданы
> эти окна.
Ну это уже частности, а текст все-таки популярный. Рассматривается худший случай.
> Из вышесказанного делается вывод о наличии
> принципиальной уязвимости системы передачи сообщений
> Windows и затягивается очередная песня про мастдай, потому
> как MSовцы ничего в ней не хотят менять.
>
> Овцы сделали всё правильно. Десктоп и рабочая станция –
> защищаемые об'єкты. Чего ещё нужно для полного счастья?
Чтоб их начали использовать :)
> Сразу скажу свое мнение о данной уязвимости. Схема
> хороша и заслуживает занесения в список проверяемых
> потенциальных уязвимостей отдельных сервисов, но говорить о
> жуткой неизлечимой дырке рановато. Конечно, наличие
> идентификатора источника сообщения могло бы пригодиться при
> программировании, но и в этом случае его анализ требовал бы
> усилий со стороны программиста. Полный запрет приема
> сообщений от сторонних процессов, пожалуй, нереален.
> Добавление такой возможности в список прав - ну, возможно,
> и помогло бы, но ведь существуют всякие автоматизаторы,
> частенько исполняющиеся с системными правами, так что при
> желании лазейку можно было бы и найти. Кроме того, не
> забудем о необходимости перетряхивания всего существующего
> софта, потому как просто так добавить опциональный параметр
> в оконную функцию вряд ли удастся.
>
> Как я уже писал, параметр уже есть – можно запретить
> создание интерактивными сервисами окон на видимых десктопах
> вообще. Но зачем? Чтобы программисты третьих вендоров не
> писали уязвимый софт? Тогда и NULL в качестве
> lpSecurityAttributes при создании чего-либо (в том числе и
> файлов) нужно запретить передавать – чтобы каждый ещё раз
> задумался о безопасности. Кому это нужно?
> Кроме того, разрешая посылать сообщения другим, возможно и
> не подозревающим об этом приложениям, Win32 приобретает
> большую гибкость, большую функциональность.
Ну, если прикинуть, такая функциональность нужна на самом деле очень небольшому классу программ - типа дающих работать с макросами. Nag screenы гасить удобно, опять же :)
> Однако ж посмотрим, какие средства у нас есть на
> руках, чтобы бороться с данной проблемой. Во-первых, писать
> такие сервисы, открывающие интерактивные окна - в принципе
> моветон, за который надо бить ногами, потому как есть
> стандартная схема, обеспечивающая взаимодействие сервиса с
> пользователем - написание вспомогательной программки,
> запускающейся с пользовательскими правами и тем или иным
> способом взаимодействующей с сервисом (хотя, в принципе,
> тут можно попробовать найти лазейку и встроиться в это
> взаимодействие).
>
> Есть разница. Это «другое» взаимодействие неизбежно должно
> осуществляться с помощью защищаемых об'єктов. Поскольку нет
> иных разделяемых и не защищаемых, кроме GUI'шных, об'єктов,
> пригодных для взаимодействия через них (по крайней мере, я
> не знаю, и, кажется, так было где-то написано).
Это если разработчик не влепил NULL В LPSECURITY_ATTRIBUTES :) А еще делают взаимодействие просто через файлы или реестр. Опять та же картина - возможность прикрыть дырку есть, но фиг кто ей пользуется.
> Далее, не совсем верно утверждение, что WM_TIMER
> не попадает в очередь сообщений и его нет возможности
> игнорировать - цитируя MSDN, "You can process the message
> by providing a WM_TIMER case in the window procedure.
> Otherwise, the default window procedure will call
> the TimerProc callback function specified in the call to
> the SetTimer function used to install the
> timer.".
>
> Попадать в очередь сообщений и в оконную процедуру – не
> одно и тоже. Из того, что сообщение можно отфильтровать в
> оконной процедуре, вовсе не следует, что его можно
> отфильтровать. В MSDN не написано, но DispatchMessage
> вызывает TimerProc даже если hWnd = NULL. Так что если уж
> отфильтровывать, то в цикле сообщений, а не в оконной
> процедуре.
Я, в общем, это и предполагал, но на всякий случай не уточнил, куда именно эту обработку втыкать :)
> Желающие могут проверить - без какого-никакого
> цикла обработки сообщений никакой callback от таймера
> работать не будет, а стало быть, вставить свою обработку
> таки можно. Другой вопрос, кто этим озаботился :) Наконец,
> особые параноики наподобие авторов PGP, вообще не
> используют стандартные классы окон и до кучи используют
> дополнительный драйвер, защищающий память приложения.
>
>
> Авторы PGP больше для меня не параноики:). PGP 7.1.1
> (corporate desktop) включает интерактивный сервис :). Вот
> от них не ожидал. Так что PGP не только обеспечивает
> секретность и аутентичность вашей переписки, но и позволяет
> вам получить достойные права на локальной машине! :)
:)
> Таким образом, из общесистемной проблема все-таки
> переходит в разряд проблем авторов сервисов, на которых и
> надо перевести стрелки - в конце концов, и в проблеме
> постоянно вылезающих buffer overflow можно обвинять
> создателей C, но это нефункционально :) Вот если б в
> примере оказался какой-нибудь стандартный сервис, это было
> бы гораздо интереснее.
>
> В стадии разработки :) Был человек, у которого "планировщик
> 2К" согрешил. Мне не удалось в ХР найти, но я не очень и
> искал.
>
> Однако ж ситуация вовсе не безоблачна. Написав
> этот абзац, полез смотреть, что творится у меня под носом -
> увы, сходу нашлась пара примеров, Outpost и MDaemon,
> которые ведут себя так же. К чести Norton Antivirus, тот
> запускает отдельную программку с пользовательскими правами.
>
>
> А вот NU2002 – не запускает. А может и запускает – это не
> показатель см. мою прогу в программинг (она, правда, тоже
> не всех грешников показывает, но лучше чем просто смотреть
> на тип сервиса вручную, или на заголовки окон).
>
> Думаю, что можно найти немало других популярных
> сервисов, которые можно поймать на эту уловку.
>
> Я уже думаю, что трудно найти такие, которых нельзя поймать
> :)
Вообще же действительно получился новый класс атак типа buffer overflow - вроде и не ОС виновата, но отлавливать такое в разных сервисах будут еще очень долго.
Ну а за замечания спасибо, в релизе учту :)
|
|
|
подробно о проекте
Анализ криптографических сетевых...
