Comments 31
без сохранения пароля вводить пароль администратора под ограниченным пользовательским сеансом не рекомендуется, <…>, иначе пользователь может запросто перехватить пароль.Я совсем не Windows-админ, поэтому могу ошибаться, но разве UAC-пароль вводится не в специальном режиме «Secure Desktop», для доступа к которому кейлоггеру требуются права администратора?
Вот, например, тут описывается, как сделать такой кейлоггер:
0xpat.github.io/Malware_development_part_7
Вообще нельзя запускать интерактивные программы от админа.
Из любого диалога Open/Save можно запустить cmd.exe
А из того же калькулятора, через окно About — браузер.
Из любого диалога Open/Save можно запустить cmd.exe
А из того же калькулятора, через окно About — браузер.
Это не совсем так, всё зависит от реализации — не в каждой программе есть диалог открытия файлов, а гиперссылка не означает, что браузер запустится с теми же правами, обычно ссылки открываются не конкретным браузером, а системным по умолчанию (другой способ запуска). Попробуйте повысить себе права через калькулятор и у вас ничего не выйдет.
Запускать от админа прогу и надеяться, что её никогда не взломают - ну так себе защита.
Нужно не надеяться, а проверять функционал заранее.
Мсье, вы сейчас ненавязчиво опустили всю многомиллиардную индустрию разработчиков ПО со всеми их отделами качества и тестирования, не говоря уже о подобной ей индустрии поиска и эксплуатации уязвимостей.
Надо им всем сказать чтоб уволили всех нафиг и наняли одного молодого сис. админа с юношеским максимализмом)
Не путайте частный случай запуска посторонней программы и уязвимости в целом.
В частном случае, если вам предоставить программу abcd.exe, вы самолично сможете её проверить и убедиться, что в ней нет проблем и уязвимостей?
Я изначально говорил о возможности запуска произвольной программы из доверенной, а не о всех проблемах и уязвимостях, читайте внимательно. Конечно смогу, и более того, даже если в программе есть диалог открытия файла, его можно обезопасить, запретив вызов контекстного меню для этого пользователя. Администратор не должен разрешать произвольную малоизвестную программу, а только такую, к которой у него есть доверие. А уже доверие складывается из многих факторов, напр. известности производителя программы, количества её пользователей и отзывов, опыта работы самого администратора с этой программой и многих других. В своей работе я в основном использую самописные программы, но ничто не мешает исследовать и другие, а потом решить, стоит ли разрешать их запуск.
Попробуйте повысить себе права через калькулятор и у вас ничего не выйдетУ меня не вышло запустить calculator Win10 с повышенными правами. При запуске через UAC флаг Elevated принудительно сбрасывается. А через RunAs с другим юзером пароль принимается, но ничего не происходит — процесс не создаётся. Видимо это из-за того, что UWP-приложение. Так что пример некорректный.
В линуксах проблему suid-reexec'ов довольно легко решить с помощью запрета определённых системных вызовов.
Например, у того же systemd есть SystemCallFilter, и если в него включить только нужное, то всё ненужное (например, @process,@privileged)само отпадёт.
+sudo на определенную программу с жестко ограниченными параметрами, можно и без ввода пароля пользователем.
sudo не решит проблемы reexec'а. Если в sudo-запущенной программе есть exec или может быть выполнен код пользователя, то это проблема уровня CVE. А методов "подгрузить код" больше, чем кажется. Начиная от вываливания в дебаггеры, и заканчивая всякими неожиданными местами для плагинов, скриптов и т.д. Условный wc/cat это не касается (они вылизаны до невозможности), но у многих других - запросто. Например, казалось бы, невинный less. Но у него можно сохранять в файлы во время пагинации, и если где-то less оказался с sudo, то всё, прощай безопасность.
Не совсем понятна постановка задачи. Что это за повседневная пользовательская задача, для которой нужны именно elevated права? Скорее всего, можно просто дать права на запись в конкретный файл (например, файл конфигурации в Program Files) или ключ реестра, или добавить какие-то права через GPO.
Если речь идёт о единовременном ручном вмешательстве, то техник с правами локального администратора может подключиться удалённо к рабочему столу и запустить нужную программу либо вручную (если у пользователя отсутствуют права администратора, а программа их требует, запрос ввода credentials появится автоматически) либо удалённо с помощью PsExec. Для таких случаев стоит заранее правильно настроить credentials caching.
Честно говоря, в 2021 году уже практически не осталось программ, которыми могут пользоваться не-администраторы и которые не могут быть использованы в ограниченной среде без прав администратора. Во многих случаях нужно просто почитать документацию, возможно, скачать другую версию/другой инсталлятор программы — часто на сайтах производителей есть отдельный раздел для IT.
Если речь идёт о единовременном ручном вмешательстве, то техник с правами локального администратора может подключиться удалённо к рабочему столу и запустить нужную программу либо вручную (если у пользователя отсутствуют права администратора, а программа их требует, запрос ввода credentials появится автоматически) либо удалённо с помощью PsExec. Для таких случаев стоит заранее правильно настроить credentials caching.
Честно говоря, в 2021 году уже практически не осталось программ, которыми могут пользоваться не-администраторы и которые не могут быть использованы в ограниченной среде без прав администратора. Во многих случаях нужно просто почитать документацию, возможно, скачать другую версию/другой инсталлятор программы — часто на сайтах производителей есть отдельный раздел для IT.
Как вариант частичного решения: можно завести отдельную учётку доменного админа, сильно зарезанную в правах (никакого RDP на серверы, прямые запреты на доступ к критичным папкам NTFS на серверах и т.п.). Держать эту учётку отключённой по умолчанию и (авто)отключаемой (скриптами, внутренними правилами). Сделать critical событие в мониторинге на включененную учётку + мониторинг учёток, которые включают эту служебную учётку. Пароли на ней менять раз в месяц или чаще. Ну и, соответственно, для интерактива в пользовательском сеансе для целей повышения прав использовать эту отдельную учётку.
До появления UAC решал эту задачу с помощью Task Scheduler (для запуска ярлыка задачи не требовалось повышенных привилегий).
Правда, аудитом безопасности не заморачивался.
Правда, аудитом безопасности не заморачивался.
Если запускать под учёткой другого пользователя, программа появляется на рабочем этого пользователя и запускающий не может с ней взаимодействовать.
Запускать под другой учеткой не пробовал. Вместо этого поместил ярлык задачи в выделенный каталог на файловом сервере, и предоставил доступ требуемых лиц к ярлыку и каталогу (только на чтение, разумеется).
А, то есть у пользователя были права администратора, но нужно было обойти диалог UAC.
Нет, у пользователя не было прав администратора. Для ярлыка задачи в Task Scheduler они не требовались, в том-то и суть.
По поводу UAC: «До появления UAC решал эту задачу...».
По поводу UAC: «До появления UAC решал эту задачу...».
Непонятно. Задача в поднятии прав? А если запускать с той же учёткой, права будут те же?
Поясняю.
В середине нулевых годов возникла задача: обеспечить рядовому сотруднику возможность перезапускать вручную сервис IIS в любой момент времени.
Для перезапуска сервиса требовались администраторские права, которых у сотрудника не было.
Решение: я как сисадмин создал в планировщике задач task, который перезапускает сервис IIS по требованию (on demand). Затем создал shortcut к этому таску, и разместил его в отдельном каталоге на файловом сервере. Дал сотруднику права read & execute на доступ к этому каталогу и шорткату.
Результат: когда возникала необходимость перезапустить сервис IIS, сотрудник заходил в указанный каталог, и кликал на указанный шорткат. Работало как часы много месяцев, пока не отпала необходимость в перезапуске сервиса.
Итог: таким образом, с помощью Task Scheduler удалось обойти ограничение операционной системы Windows на запуск администраторских задач пользователем без администраторских прав.
В середине нулевых годов возникла задача: обеспечить рядовому сотруднику возможность перезапускать вручную сервис IIS в любой момент времени.
Для перезапуска сервиса требовались администраторские права, которых у сотрудника не было.
Решение: я как сисадмин создал в планировщике задач task, который перезапускает сервис IIS по требованию (on demand). Затем создал shortcut к этому таску, и разместил его в отдельном каталоге на файловом сервере. Дал сотруднику права read & execute на доступ к этому каталогу и шорткату.
Результат: когда возникала необходимость перезапустить сервис IIS, сотрудник заходил в указанный каталог, и кликал на указанный шорткат. Работало как часы много месяцев, пока не отпала необходимость в перезапуске сервиса.
Итог: таким образом, с помощью Task Scheduler удалось обойти ограничение операционной системы Windows на запуск администраторских задач пользователем без администраторских прав.
Понятно. Но автор рассматривает интерактивные сценарии (про не интерактивные у него есть ссылка на решение, в том числе через планировщик), и когда вы написали «я решал эту задачу», это и было непонятно.
Для перезапуска служб не нужны права администратора, с помощью утилиты SubInAcl можно разрешить конкретному пользователю управлять конкретной службой.
Sign up to leave a comment.
Проблема использования RunAs на серверах