Comments 15
Мне кажется, что сам механизм поднятия привилегий и UAC «поломатые». А что думаете вы?
Я думаю, что они попросту не нужны в плане защиты от повышения привилегий с уровня Normal Integrity да High Integrity. Этот барьер ни в чём не ограничивает пользователя (поскольку пользователь с правами админа может просто нажать «Разрешить» для поднятия привелегий) и он мало в чём ограничивает всякие эксплоиты и вирусы (Normal Integrity вполне достаточно для всяких там спам-ботов, криптовымогателей и т.д.). Вот защита уровня Low Integrity или Untrusted Integrity (применяемая, например, в браузерах) — да, серьёзная штука, поскольку не даёт доступа к файловой системе и всяким разделяемым объектам в памяти. И её Вашим способом не обойти.
Согласен, что защита в виде использования Low IL или Untrusted IL будет работать хорошо. У Майкрософта есть на msdn даже статья о том, как проектировать приложения, которым будет достаточно такого IL.
Но, видимо, из-за большого легаси и обратной совместимости нельзя просто так взять и все запустить на таких низких уровнях.
Но, видимо, из-за большого легаси и обратной совместимости нельзя просто так взять и все запустить на таких низких уровнях.
По поводу реакции со стороны Microsoft: насколько я помню, они изначально обозначили некоторые фичи (UAC или, например, AppLocker) как «не относящиеся к безопасности напрямую» и поэтому обычно отвечают на подобные репорты, что никакого байпасса нет, поскольку это всего лишь защита от дурака. Хотя потом иногда все же фиксят.
Правильно ли я понял, что практический сценарий использования приведенных выше методов может быть следующим:
Злоумышленник изготавливает эксплоит -> доставляет его на компьютер жертвы -> обеспечивает его запуск -> если жертва в группе администраторов, получает возможность полного контроля над операционкой и приложениями.
Злоумышленник изготавливает эксплоит -> доставляет его на компьютер жертвы -> обеспечивает его запуск -> если жертва в группе администраторов, получает возможность полного контроля над операционкой и приложениями.
В общих чертах все так и есть.
Отличная работа!
Запрет в политиках безопасности запуска всех приложений кроме определённых директорий дополняет UAC?
Запрет в политиках безопасности запуска всех приложений кроме определённых директорий дополняет UAC?
Теоретически да. Но это слишком кропотливая работа — некоторые директории оказываются доступными на запись очень неожиданно.
Если знаете вариант, как это дело автоматизировать, было бы хорошо узнать.
Если знаете вариант, как это дело автоматизировать, было бы хорошо узнать.
А режим UAC «Always notify» не помогает? Ну то есть я понимаю, что если уже есть elevated-процесс, то там никаких подтверждений не будет, но этот процесс же ещё надо запустить, и в случае с «Always notify» оно без подтверждения не запускается.
P.S. Я знаю что по умолчанию он не такой, и это большой недостаток =)
P.S. Я знаю что по умолчанию он не такой, и это большой недостаток =)
Вспомнилась статья — Упрощаем запуск приложений в Windows от имени администратора без отключения UAC
Да уже ЭКСПЛОИТ всех эксплоитов:
«пользователь, от которого происходит запуск инициирующей программы, должен входить в группу администраторов ПК.» и Вы хотите сказать что Майкрософт не правы с вопросом «Получается, что для запуска вашего эксплоита нужны права администратора?»
«пользователь, от которого происходит запуск инициирующей программы, должен входить в группу администраторов ПК.» и Вы хотите сказать что Майкрософт не правы с вопросом «Получается, что для запуска вашего эксплоита нужны права администратора?»
Я понимаю ваше недовольство — эксплоит с полноценным поднятием привилегий был бы сильно интереснее.
Я отвечу вам тоже самое, что отвечал и в Майкрософт.
1) MITRE считает UAC Bypass уязвимостью:
https://attack.mitre.org/wiki/Privilege_Escalation
https://attack.mitre.org/wiki/Technique/T1088
2) Запуск «от имени администратора» и «с правами администратора» это два серьезно разных понятия (русскоязычный перевод Windows в этом вопросе плох, потому, что они называют первым то, что является вторым). Если говорить более корректно, то для работы эксплоита не требуется elevated start, а если бы он требовался, то я даже не пытался назвать это эксплоитом.
Позиция Майкрософта в этом вопросе обуславливается тем, что злонамеренный администратор может натворить более страшные вещи. Я вижу разницу между злонамеренным администратором и обычным пользователем, сидящим под аккаунтом администратора и запустившего рандомный файлик из интернета. Мой эксплоит стирает эту разницу.
3) Сейчас можно закидать меня помидорами за то, что я привожу пример, который основывается на большом количестве допущений, но в жизни встречаются ситуации и похуже.
Есть Windows 8.1 с двумя пользователями (это и логически два аккаунта и физически два человека — администратор и пользователь). На компьютере установлен Python (Папка C:\Python27 добавлена в PATH).
Воспользовавшись уязвимостью fsquirt, обычный пользователь может спровоцировать запуск файла от имени пользователя-администратора. Но без обхода UAC смысла в этом мало.
Я отвечу вам тоже самое, что отвечал и в Майкрософт.
1) MITRE считает UAC Bypass уязвимостью:
https://attack.mitre.org/wiki/Privilege_Escalation
https://attack.mitre.org/wiki/Technique/T1088
2) Запуск «от имени администратора» и «с правами администратора» это два серьезно разных понятия (русскоязычный перевод Windows в этом вопросе плох, потому, что они называют первым то, что является вторым). Если говорить более корректно, то для работы эксплоита не требуется elevated start, а если бы он требовался, то я даже не пытался назвать это эксплоитом.
Позиция Майкрософта в этом вопросе обуславливается тем, что злонамеренный администратор может натворить более страшные вещи. Я вижу разницу между злонамеренным администратором и обычным пользователем, сидящим под аккаунтом администратора и запустившего рандомный файлик из интернета. Мой эксплоит стирает эту разницу.
3) Сейчас можно закидать меня помидорами за то, что я привожу пример, который основывается на большом количестве допущений, но в жизни встречаются ситуации и похуже.
Есть Windows 8.1 с двумя пользователями (это и логически два аккаунта и физически два человека — администратор и пользователь). На компьютере установлен Python (Папка C:\Python27 добавлена в PATH).
Воспользовавшись уязвимостью fsquirt, обычный пользователь может спровоцировать запуск файла от имени пользователя-администратора. Но без обхода UAC смысла в этом мало.
Sign up to leave a comment.
UAC Bypass или история о трех эскалациях