eXeLab
eXeL@B DVD 2017 !

Видеокурс программиста и крэкера 5D 2O17
(актуальность: ноябрь 2O17)
Свежие инструменты, новые видеоуроки!

  • 400+ видеоуроков
  • 800 инструментов
  • 100+ свежих книг и статей

УЗНАТЬ БОЛЬШЕ >>
Домой | Статьи | RAR-cтатьи | FAQ | Форум | Скачать | Видеокурс
Новичку | Ссылки | Программирование | Интервью | Архив | Связь

Русский / Russian English / Английский

Сейчас на форуме: cevile (+2 невидимых)
 · Начало · Статистика · Регистрация · Поиск · ПРАВИЛА ФОРУМА · Язык · RSS · SVN ·

 eXeL@B —› Основной форум —› Неприятная и трудноустранимая Information Disclosure / Denial of Service уязвимость в Windows 7
. 1 . 2 . >>
Посл.ответ Сообщение
ntldr

Ранг: 322.6 (мудрец)
Статус: Участник

Создано: 24 июля 2011 23:02 New!
· Личное сообщение · #1

С нижеописанной уязвимостью я столкнулся недавно, после чего долго гуглил надеясь что эта багофича и способы ее закрытия уже известны, но не нашел ничего внятного. Теперь пытаюсь решить проблему сам, и заодно выношу её на обсуждение.

Итак, проблема заключается в небезопасных дефолтовых ACL для объектов процесса, токена и потока. В их дефолтовые ACL добавлен SID формата S-1-5-5-0-xxxxx которому разрешены некоторые действия в некоторых случаях ломающие границы системы безопасности и приводящие к раскрытию приватной информации и отказу в обслуживании.
Для демонстрации Denial of Service создайте пользователя test с паролем 1 net user test 1 /add и запустите TaskManager от этого пользователя runas /user:test taskmgr. В окне TaskManager'a вы увидите процессы своего основного пользователя (например explorer.exe) и сможете их убить. Пользователь test не имеет прав администратора, как же получается, что он может убивать процессы других пользователей? Но это ещё полбеды, теперь запустите процесс требующий повышения прав до администратора, например regedit.exe, и он будет успешно убиваться другим пользователем с пониженными правами.
Если вы думаете что это всё, то вы ошибаетесь, дальше - больше. Теперь --> скачаем <-- утилиту Process Hacker 2, извлечем из архива один только файл ProcessHacker.exe (без драйвера) и запустим под пользователем test. И что мы видим? ProcessHacker успешно показывает полную командную строку и переменные окружения всех процессов основного пользователя и других ограниченных пользователей (спасибо хоть что не администраторов), а также легко сканирует их память и показывает хранящиеся там строки. Если завершение процессов можно было как-то терпеть, то это полный ахтунг! Явки, пароли, секретные планы порабощения мира, всё может быть прочитано любой программой запущенной от отдельного пользователя, которого создали для того чтобы предотвратить такой непорядок. Обидно, да?
Теперь с помощью ProcessHacker'а ищем причины этой фигни. Сразу смотрим permissions процессов и видим странный SID формата S-1-5-5-0-xxxxx (разрешены действия Query limited information, Query information, Read memory, Terminate, Syncronize и Read permissions), лезем на вкладку Token и смотрим ACL примари токена, опять видим этот SID (разрешены Assign as primary token, Duplicate, Impersonate, Query, Query source, и Read permissions), получается что загадочный S-1-5-5-0-xxxxx может скопировать себе токен процесса, имперсонироваться и получить доступ к файлам другого пользователя. Замечательно, да? Ну и напоследок смотрим permissions потоков процесса, опять видим наш SID (разрешены Query limited information, Query information, Get context, Syncronize и Read permissions), мда, но ничего хорошего и не ожидалось.
Теперь о том, кто же такой этот S-1-5-5-0-xxxxx. Поиск S-1-5-5- в WDK дал такое описание в ntifs.h (Logon IDs) S-1-5-5-X-Y. Получается что этот SID связал с logon id с которым запущен процесс. Для проверки пробуем сделать Switch user, зайти как test и повторить предыдущие действия. Теперь система безопасности отрабатывает как надо и не дает сделать лишнего. Но это не решает проблему того, что runas страшно небезопасен!

Теперь давайте вместе попробуем ответить на извечные вопросы "кто виноват" и "что делать". Как вернуть в Windows безопасный runas, который всегда был замечательным средством изоляции програм от друг-друга?

| Сообщение посчитали полезным: Vol4ok, RETOR

Enigma

Ранг: 88.3 (постоянный)
Статус: Участник

Создано: 24 июля 2011 23:58 New!
· Личное сообщение · #2

Предположу, что так, впринципе, оно и должно работать. Ведь для того что запустить процесс действительно под другим пользователем, Windows надо как минимум загрузить окружение того пользователя. Т.е. сделать тоже самое что и делает Switch User. А то, с какой скоростью система отрабатывает запуск через RunAs, уже понятно, что окружение другого пользователя винда не загружает..
ntldr

Ранг: 322.6 (мудрец)
Статус: Участник

Создано: 25 июля 2011 00:03 New!
· Личное сообщение · #3

Enigma пишет:
уже понятно, что окружение другого пользователя винда не загружает..

Загружать или не загружать окружение - настраивается ключами runas, по-умолчанию оно загружается. И в Windows XP/2003 runas давал нормальную изоляцию процессов, без таких сюрпризов. Так что эта багофича новая.
Enigma

Ранг: 88.3 (постоянный)
Статус: Участник

Создано: 25 июля 2011 00:10 New!
· Личное сообщение · #4

вот только проверил, да, все работает так как ты написал, на Win 7.

Попробовал на Win Xp SP2, "runas /user:guest taskmgr", тоже самое, видно все процессы администратора, и так же их убить можно... разницы с Win 7 никакой..
ntldr

Ранг: 322.6 (мудрец)
Статус: Участник

Создано: 25 июля 2011 09:24 New!
· Личное сообщение · #5

Enigma пишет:
Попробовал на Win Xp SP2, "runas /user:guest taskmgr", тоже самое, видно все процессы администратора, и так же их убить можно... разницы с Win 7 никакой..

Guest у вас какой-то неправильный. По-умолчанию нельзя сделать runas для guest, так как ему запрещен локальный вход в систему и отсутстует пароль (runas без пароля не делается). Если специально подкрутить настройки и поставить пароль, то таскменеджер видит все процессы (собственно винда не умеет фильтровать выдачу при перечислении процессов, и хз как её этому научить), но ничего не убивает.
Av0id

Ранг: 516.1 (!)
Статус: Участник

Создано: 25 июля 2011 10:33 New!
· Личное сообщение · #6

допустим инжектимся через runas в процесс, созданный системой или админом, повышение привилегий возможно?
Error_Log

Ранг: 228.7 (наставник)
Статус: Участник
malware research

Создано: 25 июля 2011 11:11 New!
· Личное сообщение · #7

Av0id пишет:
допустим инжектимся через runas в процесс, созданный системой или админом, повышение привилегий возможно?

Доступ на запись запрещен. Но имеется доступ на чтение, а это значит что User1 может читать память User2 - в том числе его пароли и прочую security - информацию. Это можно расценивать как уязвимость безопасности системы.
В качестве решения проблемы можно попробовать отказаться от runas, и использовать самописный аналог, который при запуске процесса вырубает Logon SID в токене (LogonUser/CreateRestrictedToken/CreateProcessAsUser). Но, подозреваю, что может отвалиться какая-то часть системного АПИ. Т.е. по-хорошему надо исследовать где и для чего этот самый SID еще используется системой.
reversecode


Ранг: 950.8 (! ! !)
Статус: Участник

Создано: 25 июля 2011 11:26 New!
· Личное сообщение · #8

сдается мне это особенность Desktop версии
есть у кого Server вариант, проверте там
Av0id

Ранг: 516.1 (!)
Статус: Участник

Создано: 25 июля 2011 14:34 · Поправил: Av0id New!
· Личное сообщение · #9

Доступ на запись запрещен

этого в принципе достаточно
ntldr

Ранг: 322.6 (мудрец)
Статус: Участник

Создано: 25 июля 2011 16:29 New!
· Личное сообщение · #10

Av0id пишет:
допустим инжектимся через runas в процесс, созданный системой или админом, повышение привилегий возможно?

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

Error_Log пишет:
В качестве решения проблемы можно попробовать отказаться от runas, и использовать самописный аналог, который при запуске процесса вырубает Logon SID в токене

Но explorer запускающийся от основного пользователя и запущенные им процессы по преждему будут иметь Logon SID. А кто сказал, что експлореру и всякой срани в автозагрузке должно быть разрешено чтение чего угодно?
Вообщем решение уже есть. Я написал простенький драйверок отслеживающий создание процессов и потоков и удаляющий левый SID откуда надо. На первый взгляд это работает, но толком еще не тестировал.

reversecode пишет:
есть у кого Server вариант, проверте там

Проверил на Win2008 R2 SP1 со всем патчами, работает.
Gideon Vi


Ранг: 1043.0 (!!!!)
Статус: Участник

Создано: 25 июля 2011 16:31 New!
· Личное сообщение · #11

ntldr пишет:
Я написал простенький драйверок отслеживающий создание процессов и потоков и удаляющий левый SID откуда надо.


версию под х64 ожидать можно?
Wyfinger

Ранг: 52.1 (постоянный)
Статус: Участник

Создано: 25 июля 2011 16:38 New!
· Личное сообщение · #12

Простите, а что по этому поводу думает Microsoft?
ntldr

Ранг: 322.6 (мудрец)
Статус: Участник

Создано: 25 июля 2011 16:53 New!
· Личное сообщение · #13

Gideon Vi пишет:
версию под х64 ожидать можно?

Сегодня-завтра будет выложена подписанная версия с исходниками.

Wyfinger пишет:
Простите, а что по этому поводу думает Microsoft?

Знать бы как у них спросить...

| Сообщение посчитали полезным: Gideon Vi

ntldr

Ранг: 322.6 (мудрец)
Статус: Участник

Создано: 26 июля 2011 04:25 New!
· Личное сообщение · #14

Выкладываю драйвер решающий проблему.

--> psstrict.zip <--
Wyfinger

Ранг: 52.1 (постоянный)
Статус: Участник

Создано: 26 июля 2011 05:43 · Поправил: Wyfinger New!
· Личное сообщение · #15

ntldr
Спросил здесь.

Надеюсь заметят, подождем ответа.

UPD:
Один из ответов
Ilya Tumanov (MSFT)
Даже если все так, то сценарий сам по себе сомнителен. Ведь пользователь А который использовал runas для запуска от имени пользователя Б и так может убивать процессы пользователя А, видеть их командные строки и т.п. Т.е. если "за рулем" "злодей" без присмотра то ему никакие runas не потребуются, все и так доступно. То же касается "злодейского приложения" который под любым эккаунтом будет иметь слишком много прав.

Кстати, runas скорее является средством для запуска от лица другого пользователя (например с целью получения прав которых у текущего пользователя нет), а не средством изоляции (понижения доступа).

Так же рекомендую посмотреть тут: http://technet.microsoft.com/en-us/library/cc722487.aspx, пункты #1, #3.
ClockMan


Ранг: 471.0 (мудрец)
Статус: Участник
оптимист

Создано: 26 июля 2011 05:47 New!
· Личное сообщение · #16

Enigma пишет:
Попробовал на Win Xp SP2, "runas /user:guest taskmgr", тоже самое, видно все процессы администратора, и так же их убить можно... разницы с Win 7 никакой..

Так там же пишется при создании учётной записи делать полный доступ или огранниченный,если выбираешь огранниченный то нефига ты там неувидешь...
ntldr

Ранг: 322.6 (мудрец)
Статус: Участник

Создано: 26 июля 2011 12:39 New!
· Личное сообщение · #17

Итак, достигнутые результаты:
Удалось украсть токен из уязвимого процесса, имперсонироваться на нем и получить полный доступ к файлам другого пользователя (на чтение и на запись).
Удалось украсть Elevated токен из процесса администратора, удалось имперсонироваться на нем но непонятно что делать дальше, по такому токену винда никуда доступа не дает.
Не удалось сделать CreateProcessAsUser, потому что нужны привилегии SE_ASSIGNPRIMARYTOKEN_NAME и SE_INCREASE_QUOTA_NAME, которых у нас нет.

В аттаче прилагаю эксплоит демонстрирующий доступ к файлам других пользователей.

___ - exploit.zip
ntldr

Ранг: 322.6 (мудрец)
Статус: Участник

Создано: 26 июля 2011 22:35 New!
· Личное сообщение · #18

Wyfinger пишет:
Один из ответовIlya Tumanov (MSFT)Даже если все так, то сценарий сам по себе сомнителен. Ведь пользователь А который использовал runas для запуска от имени пользователя Б и так может убивать процессы пользователя А, видеть их командные строки и т.п. Т.е. если "за рулем" "злодей" без присмотра то ему никакие runas не потребуются, все и так доступно. То же касается "злодейского приложения" который под любым эккаунтом будет иметь слишком много прав.

Сейчас уже не эпоха Windows 9x, где любое приложение могло делать что заблагорассудится. Windows начиная с NT4 позиционируется как многопользовательская ОС имеющая все нужные средства разграничения доступа. А runas может использоваться (и успешно использовался в XP/2003) для изоляции небезопасных сетевых приложений, таких как браузер, что позволяло защититься от большинства атак.
То что я вижу в Windows 7 - это существенная брешь в безопасности системы. Но полагаю что это никогда не будет исправлено, баг объявят фичей, скажут что так надо и забудут.


Похоже что в топике на microsoft.com наметилось непонимание сути уязвимости. Объясняю подробней: допустим у нас в системе есть небезопасное приложение, например браузер, содержащее уязвимости, которое тем не менее нам нужно использовать. Для запуска этого приложения создается аккаунт ограниченного пользователя и запуск производится с помощью runas. Этим мы желаем добиться изоляции уязвимого приложения от остальной системы, чтобы любая атака на него не вышла за пределы ограниченного пользователя. В Windows XP/2003 всё так и работало, а в Windows 7 благодаря вышеописанной уязвимости атакующий может получить доступ к данным основного пользователя и других ограниченных пользователей, от имени которых через runas могут быть запущены другие изолированные приложения, чего не должно быть.

| Сообщение посчитали полезным: Jupiter

Gideon Vi


Ранг: 1043.0 (!!!!)
Статус: Участник

Создано: 27 июля 2011 03:58 New!
· Личное сообщение · #19

ntldr пишет:
Выкладываю драйвер решающий проблему.


привяжи его к какой-нибудь софтине, плз. Так ставить не удобно.
Alchemistry

Ранг: 94.6 (постоянный)
Статус: Участник

Создано: 27 июля 2011 08:52 New!
· Личное сообщение · #20

Разговарить с манагерами и быдлоадминами на technet бесполезно. Они ничего не решают.

Вам сюда secure@microsoft.com
Инструкции здесь http://technet.microsoft.com/ru-ru/security/ff852094.aspx

Максимально подробно изложить проблему, приложить PoC, все писать на английском. Если нет ответа в течение суток продублировать сообщение.
C/Kashmir

Ранг: 3.3 (гость)
Статус: Участник

Создано: 27 июля 2011 09:54 · Поправил: C/Kashmir New!
· Личное сообщение · #21
Archer


Ранг: 1914.6 (!!!!)
Статус: Модератор
retired

Создано: 27 июля 2011 10:33 · Поправил: Модератор New!
· Личное сообщение · #22

Ну автор этого уютного бложика не первый раз смотрит на форум и участников косо https://ssl.exelab.ru/f/index.php?action=vthread&forum=7&topic=18520 Непонятно только, чего он продолжает сюда ходить или почему не может прямо здесь аргументированно отстаивать свою точку зрения.
ntldr

Ранг: 322.6 (мудрец)
Статус: Участник

Создано: 27 июля 2011 11:14 New!
· Личное сообщение · #23

C/Kashmir пишет:
Забавно

Раз забавно, почему бы автору не ответить здесь? Ну так и быть, отвечу ему здесь: Уважаемый автор, в моем посте не было ни слова ни про IE ни про Integrity Level, потому что это ни в малейшей мере к делу не относится. Речь шла о небезопасном runas. Ваше право считать что доступ одного ограниченного пользователя к данным другого, когда это не разрешено явно, - это не уязвимость. Но у меня другое мнение.
По теме: ок, напишу на secure@microsoft.com, и нет смысла дальше толочь воду в ступе. Все что надо я для себя выяснил, воркараунд сделал, а дальше пусть объявляют это хоть багом хоть фичей.
xetis

Ранг: 15.7 (новичок)
Статус: Участник

Создано: 27 июля 2011 11:21 New!
· Личное сообщение · #24

а задать программе Integrity Level нельзя?
ntldr

Ранг: 322.6 (мудрец)
Статус: Участник

Создано: 27 июля 2011 11:40 New!
· Личное сообщение · #25

xetis пишет:
а задать программе Integrity Level нельзя?

Можно. icacls program.exe /setintegritylevel Low, но это не предотвращает чтения папки "мои документы". Integrity Levels это полезный и удобный механизм, но выполняет другую задачу нежели runas.
Установка Low Integrity Level на процессы запускаемые из-под runas частично решает проблему, но только частично, потому что процессы с Low Integrity Level могут получить доступ к данным друг друга, хотя они запущены от разных пользователей.
И процесс с Low Integrity Level отлично убивает explorer, можете сами убедиться.
ntldr

Ранг: 322.6 (мудрец)
Статус: Участник

Создано: 27 июля 2011 13:19 New!
· Личное сообщение · #26

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

З.Ы. свои неполиткорректные высказывания я уже подчистил.
ARCHANGEL


Ранг: 631.8 (!)
Статус: Участник
ALIEN Hack Team

Создано: 27 июля 2011 13:41 · Поправил: ARCHANGEL New!
· Личное сообщение · #27

Ведь пользователь А который использовал runas для запуска от имени пользователя Б и так может убивать процессы пользователя А, видеть их командные строки и т.п. Т.е. если "за рулем" "злодей" без присмотра то ему никакие runas не потребуются, все и так доступно

Какой-то неадекватный коммент. Говорится же именно про то, что "злодей" - процесс, запущенный от имени пользователя Б, который должен быть ограничен в правах. Пользователь А и так имеет/может иметь суперпривилегии, и именно их нужно ограничить за счёт рестрикт токена при runas. Никто не в курсе, у мелкомягких есть что-то типа книги жалоб на таких вот консультантов?

Кажется, ntldr говорил, что это объявят фишкой? Нате, пожалуйста:
Я подозреваю что это было сделано вполне намерено. Если пользователь А запустил процесс под пользователям Б то логично ожидать что данный процесс имеет доступ к ресурсам пользователя А который, собственно, и запустил процесс. Скорее всего в ХП это не работало и поведение было изменено.

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

Ранг: 322.6 (мудрец)
Статус: Участник

Создано: 27 июля 2011 13:48 New!
· Личное сообщение · #28

Не надо ни на кого жаловаться. В Microsoft работает много людей, и все не обязаны понимать работу системы безопасности и сходу въезжать в суть проблемы. Напишем официально на secure@microsoft.com, а там посмотрим.
ARCHANGEL


Ранг: 631.8 (!)
Статус: Участник
ALIEN Hack Team

Создано: 28 июля 2011 10:39 · Поправил: ARCHANGEL New!
· Личное сообщение · #29

А на форуме мелкомягких Илюха продолжает жечь:
Кстати, тут тоже интересный вопрос: кнопочка Х нажимает от пользователя или админа? Как на счет меню "выход" в самом окне? А комбинация ALT-F4 чья?

Или я не могу понять его глубоких мыслей, или мои представления про Windows в корне неправильны. Товарищи, поправьте меня. При нажатии на кнопочку Х или выборе меню Выхода/нажатии ALT-F4 в окне приложения окно этого приложения получает сообщение WM_CLOSE, управление передаётся каллбэку этого окна (оконной процедуре обработки сообщений) и, как обычно происходит, процесс того же блокнота сам себя завершает посредством вызова системного сервиса ZwTerminateProcess, при этом вызов PsGetCurrentProcessId при, например, перехвате сервиса, это ясно даёт понять. Что ж тут непонятно?

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

Опа! Если раньше он хоть глюк в семёрке называл фичей, то сейчас он runas XP называет глюком, да и более того - приводит пример сценария, которого не было при нормальной работе в ХР. Попробуйте в ХР запустить под учёткой пользователя калькулятор от имени админа. Что он у вас, не закроется потом?

Туманов, ты звезда!

| Сообщение посчитали полезным: ==DJ==[ZLO]

ntldr

Ранг: 322.6 (мудрец)
Статус: Участник

Создано: 28 июля 2011 11:12 New!
· Личное сообщение · #30

Не знаю причем тут какие-то кнопочки, это всё неконкретная демагогия.
Мой тезис: если пользователь A имеет доступ к данным пользователя B, при этом пользователь A не является администратором и разрешение на доступ к данным пользователя B не было дано явно - то это уязвимость. С тезисом согласны? Нет - приводите аргументы.
Теперь разбор нашей ситуации по пунктам:
1 - Пользователь A имеет доступ к данным пользователя B (его домашней директории на чтение и запись и памяти его процессов на чтение).
2 - Пользователь A не является администратором.
3 - Ни пользователь B ни администратор не разрешали пользователю A такой доступ. Использование runas не подразумевает что мы что-либо разрешаем пользователю A, мы просто хотим запустить приложение от пользователя A в его контексте безопасности.
4 - Из пунктов 1-3 делаем вывод что уязвимость налицо. Неважно что такое поведение может быть следствием какой-либо фичи или архитектурной особенности системы, уязвимость от этого не перестанет быть уязвимостью.
Не согласны - приводите аргументы в тезисном формате, без не относящихся к делу предположений и без аналогий. Т.е. "я не согласен с тем-то, потому что...". Именно так должен происходить конструктивный диалог, а не демагогия и словоблудие.

Что из вышесказанного могут попытаться опровергнуть несогласные? Во-первых можно не согласиться с определением уязвимости, т.е. признать что явно не разрешенный доступ пользователя A к данным пользователя B это нормально. Во-вторых можно попытаться доказать что запуск через runas должен давать какие-то дополнительные права пользователю A, если так - то прошу ссылку на сайт MS где документировано такое поведение.
. 1 . 2 . >>
 eXeL@B —› Основной форум —› Неприятная и трудноустранимая Information Disclosure / Denial of Service уязвимость в Windows 7

Оригинальный DVD-ROM: eXeL@B DVD !

Вы находитесь на форуме сайта EXELAB.RU
Проект ReactOS