none
Information Disclosure / Denial of Service уязвимость в Windows 7 RRS feed

  • Вопрос

  • Хотелось бы узнать мнение специалистов по поводу данной уязвимости, описание ниже,

    подробнее в обсуждении http://exelab.ru/f/index.php?action=vthread&forum=1&topic=18837&page=-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, который всегда был замечательным средством изоляции програм от друг-друга?


    26 июля 2011 г. 1:20

Все ответы

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

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

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


    This posting is provided "AS IS" with no warranties, and confers no rights.
    26 июля 2011 г. 3:35
    Модератор
  • А у меня и при входе от test так же. Т.е. если войти под test и просто запустить taskmgr, то всё будет нормально. А вот если его запустить runas'ом, то будет ровно то же самое - можно будет убить процесс, запущенный от того же админа.

    Имхо, это бага. По крайней мере, серьёзная уязвимость. И о ней надо сообщить в саппорт.

    26 июля 2011 г. 10:38
  • Правила правилами, но эта уязвимость позволяет получить полный доступ к файлам другого пользователя.

    Привожу пост из форума exelab от обнаружившего уязвимость:

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

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

     

    Хотелось бы услышать ответ от представителей компании (вы представитель?). Предлгаю ввязаться в обсуждение в ветке

    От модератора: при открытии ссылки появилось сообщение: Данный веб-узел содержит ссылки на вирусы и другие программы, которые могут раскрыть персональные данные, хранящиеся или вводимые на компьютере, потенциально опасным лицам.

    По этой причине ссылка удалена.

    • Изменено Igor LeykoModerator 26 июля 2011 г. 12:23 ссылка на зараженный сайт
    26 июля 2011 г. 11:30
  •  
    Для демонстрации Denial of Service создайте пользователя test с паролем 1 net user test 1 /add

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

    M:\Users\Игорь>net user test 1 /add
    Системная ошибка 5.

    Отказано в доступе.


    26 июля 2011 г. 12:36
    Модератор
  • Это потому что такие права реально уже есть - ведь все это изначально выполняется под правами этого другого пользователя. Иными словами для получения прав пользователя А требуется сначала получить права пользователя А. Или вы утвердайте что можно получить доступ к зашифрованным данным (к незашифрованным данным доступ можно получить всегда при наличии физического доступа) пользователя X который в данный момент не залогинен?

    Я работаю в Микроософт, но не над Windows и не в поддержке пользователей. Это мое мнение по поводу вашего вопроса. Если вы желайте обсудуть ваш вопрос официально (что вполне разумно) то вам следует обратится в оффициальную поддержку.

     


    This posting is provided "AS IS" with no warranties, and confers no rights.
    26 июля 2011 г. 15:30
    Модератор
  • Как Вы объясните поведение в данной ситуации WinXP, где runas можно использовать для изоляции потенциальноопасных приложений (браузер)? В WinXP все работает предсказуемо, т.е. приложение, запущенное посредством runas от ограниченного пользователя имеет ограниченные права (права этого ограниченного пользователя). В Win7 в этом же сценарии поведение системы отличается: программа, запущенная от ограниченного пользователя имеет права читать файлы и память процессов других пользователей, убивать процессы и прочее.

    Если у Вас есть возможность - привлеките внимание соответствующих специалистов, Вам это проще, наверно, сделать.
    26 июля 2011 г. 23:28
  • Это Вы наверно не от админа пользователя создаете.
    27 июля 2011 г. 1:41
  • Я подозреваю что это было сделано вполне намерено. Если пользователь А запустил процесс под пользователям Б то логично ожидать что данный процесс имеет доступ к ресурсам пользователя А который, собственно, и запустил процесс. Скорее всего в ХП это не работало и поведение было изменено.

    Как я уже упоминал я не слышал чтоб runas использовался с целью изоляции. Если бы все было так просто то наверное никто не выпускал бы специальные "песочницы", нет? В любом случае я не вижу ни Information Disclosure, ни Denial of Service, ни Elevation of privileges так как права/доступ не выше чем у пользователя который собственно и запускает runas. Как справедливо указал Игорь если у пользователя изначаельно нет прав администратора то "атака" захлебывается на первом же шаге.

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

    Оффициальный запрос всегда эффективнее "испорченного телефона", даже если он и внутренний.


    This posting is provided "AS IS" with no warranties, and confers no rights.
    27 июля 2011 г. 1:58
    Модератор
  • Это Вы наверно не от админа пользователя создаете.


    У меня на компьютере один пользователь. Я. И я, естественно, администратор. :)

    К сожалению, Вы некорректно описали процедуру воспроизведения. В частности, в самом начале оказались пропущенными строчки. "В командной строке, запущенной от имени администратора...". Гадать, что еще опущено, подразумевалось, на какие подробности просто не было обращено внимания, мне не хочется. Поэтому я и попросил Вас о точном пошаговом описании, как воспроизвести ситуацию.

    Когда сравниваете с ХР, то не забываете ли Вы, что в ХР у администратора только один набор прав?

    27 июля 2011 г. 6:44
    Модератор
  • Коллеги, как я понимаю, это нюанс работы самой системы безопасности Windows, как таковой. Вот более строгий алгоритм:

    1. Создаём пользователя с правами пользователя (не админа!) в системе. Имя - любое, пароль - любой;

    2. Выходим из системы - завершаем сеансы всех пользователей;

    3. Входим в систему от имени только что созданной тестовой ограниченной учётки;

    4. Запускаем блокнот от имени администратора (ПКМ, логин-пароль), пишем в нём "12345";

    Теперь, насколько я понимаю общую структуру подсистемы безопасности винды, у текущего пользователя без повторного ввода пароля администратора не должно быть возможности закрыть блокнот - система должна отвечать отказом в доступе, поскольку приложение запущено от имени другого юзера, админа с паролем. Так? Неа, не так.

    5. Запускаем taskmgr от test и из него с лёгкостью убиваем блокнот.

    Т.е. по сути, система каким-то макаром "знает", что блокнот был запущен не просто от админа, а из сессии test от имени админа. И поэтому даёт возможность test'у точно так же завершить процесс, который запущен в его сессии. Судя по всему, как-то так, потому что через taskkill убить другие процессы админа, запущенные в его сессии, не получается.

    27 июля 2011 г. 10:02
  • С моей точки зрения вполне логично что можно закрыть процесс запущенный в сессии пользователя, не важно под каким аккаунтом.

    Собственно задачу можно упростить:

    1. Заходим под админом в включенным UAC.

    2. Запускаем блокнот с повышением до администратора.

    3. Нажимаем кнопочку Х, блокнот конечно же закрывается.

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

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

    Еще один интересный вариант: что будет если пользователь с открытым админским окном (которое допустим нельзя закрыть) попробует отлогинится (например для установки апдейтов)? Должно ли "админское" окно автоматом закряться или же с целью предотвращение DOS админсткого окна пользователя отфутболят и сессия продолжит работу пока не придет админ и не введет пароль?


    This posting is provided "AS IS" with no warranties, and confers no rights.
    27 июля 2011 г. 16:24
    Модератор
  • Сами файлы, созданные из одной сессии, отличаются только владельцем - блокнот, запущенный от администратора выставляет владельцем группу Администраторы при сохранении документа.

    Соответственно, можно сделать вывод - все действия, выполняемые в этом окне (и, что самое интересное, выполняемые от имени этого процесса) по умолчанию выполняются от админа. Потому и окно закрывается без ошибок, и сохранить документ в корне системного диска можно - нажатия, клики и диалоговые окна тоже вызываются от priviledged-учётки. Всё это вполне логично.

    Далее. Если запустить в сессии админа блокнот runas /user:test notepad, то этот блокнот будет работать в контексте ограниченного пользователя. Там нельзя ни сохранить файл куда не надо, ни заменить критические системные компоненты. И для сохранения по умолчанию выбирается папка документов юзера test. Т.е. всё окей. Более того, если запустить через runas ещё одну консоль, то ни bcdedit, ни format там не выполняются - система вполне вменяемо сообщает об отказе в доступе. Тоже логично и правильно.

    А вот редактор реестра и диспетчер задач она запустить позволяет. И если в случае с regedit всё ещё относительно неплохо - создавать и менять данные можно только в HKCU (всё верно, раздел-то подгружается test'овский), то taskmgr не только показывает процессы всех пользователей, но и позволяет их убить.

    С запуском всё более-менее ясно - и regedit, и taskmgr переделали, их можно запускать и от имени ограниченной учётной записи. Но вот с какого перепугу он отображает все процессы, когда я явно выполняю команду runas /user:test taskmgr? Ведь если просто войти в систему под test'ом и запустить taskmgr, он отобразит список процессов только текущего пользователя. Откуда эта разница?

    29 июля 2011 г. 9:26