В этой статье я подробно расскажу о проблемах, с которыми столкнется каждый системный администратор, использующий в своей работе возможность запуска программ от имени другого пользователя, в большинстве случаев от имени администратора.
Если вы тот самый системный администратор, прочтите внимательно, скорее всего вам нужно срочно сменить пароль.
Почему это вообще необходимо? Бывают ситуации, когда пользователю с ограниченными правами необходимо выполнить программу, требующую повышенных прав для выполнения определенной работы.
Например, программисту необходимо иметь возможность завершать определенные процессы в бухгалтерской программе, некоторым пользователям бухгалтерского учета необходима возможность интерактивного переключения ключей безопасности и так далее.
Некоторые из этих задач можно выполнять в неинтерактивном режиме, но при этом несколько страдает удобство, поскольку пользователь не видит интерфейса программы и может лишь получить системное сообщение о завершении работы программы; мой коллега Вадим Стеркин подробно описал этот метод в своем блоге: Как выполнять задачи с полными правами обычного пользователя без ввода пароля администратора .
Метод отлично подходит для своих задач, но в моей статье мы поговорим о рисках и безопасности запуска интерактивных программ от имени других пользователей, где полной автоматизации добиться невозможно и есть необходимость взаимодействия с интерфейсом.
Самое главное, что должен понимать администратор, это то, что из запущенной программы с повышенными правами не должно быть возможности запустить другую произвольную программу, так как права наследуются автоматически.
Прежде чем даже планировать создание ярлыка для запуска, следует убедиться в том, что программа не имеет окон для открытия других файлов или запуска справки с собственной программой обработки, где можно дополнительно вызвать диалог открытия других файлов справки, и подобные уязвимости в данном случае, которые позволят пользователю запустить произвольную программу с правами администратора.
Другой пример — при определённых или редких обстоятельствах программа открывает логи в Блокноте, а там уже есть диалог открытия других файлов, и это готовая уязвимость.
То есть целевая программа должна быть изучена администратором вдоль и поперек (а еще лучше написана самостоятельно), чтобы ее можно было использовать по-настоящему безопасно.
RunAs из коробки
В системе есть родная утилита под названием runas, которая позволяет выполнить задачу запуска под другим именем, но пользоваться ею нужно осторожно и по соображениям безопасности ее нельзя использовать для запуска программ с повышенными привилегиями, а наоборот, администратором.может запускать программы с обычными правами пользователя, хотя технически возможны оба варианта.
Почему это? Параметр /savecred позволяет сохранить пароль пользователя, под именем которого запускается программа, в профиле пользователя, запускающего программу.
Однако RunAs также использует тот же сохраненный пароль для запуска любых других программ, которые может запускать пользователь, у которого есть сохраненный пароль.
Давайте рассмотрим это на примере: у нас есть Админ с правами администратора, Пользователь1 с необходимостью запускать программу от имени администратора, и все остальные пользователи, которым не следует запускать эту программу, назовем их Пользователь2, а тестовая программа — калькулятор.
(расчет).
Когда администратор хочет запустить программу от имени пользователя для тестирования или из планировщика, он может сохранить пароль User1 в своем профиле, выполнив команду «runas /savecred /user:User1 Calc», ввести пароль User1 и в дальнейшем по этой команде пароль не будет запрошен, но и для других программ, кроме калькулятора, он также не будет запрошен.
В этом случае Пользователь2, выполняющий ту же команду, столкнётся с необходимостью ввести пароль для Пользователя1, так как этот пароль заранее не сохранен в его профиле.
Этот сценарий приемлем и безопасен, поскольку у администратора уже есть полные права.
Однако если мы запустим команду «runas /savecred /user:Admin Calc» от имени пользователя User1 и введем пароль администратора, пользователь User1 сможет запускать любые программы от имени администратора, что полностью нарушает модель безопасности.
Вывод - использовать родные руны в составе системы для повышения прав на постоянной основе (с сохранением пароля) категорически невозможно, эта уязвимость должна быть очевидна каждому системному администратору.
И даже без сохранения пароля вводить пароль администратора под ограниченным сеансом пользователя не рекомендуется, если заранее не приняты меры по предотвращению запуска произвольных программ (SRP, AppLocker), иначе пользователь может легко перехватить пароль.
И переходим к неочевидным уязвимостям.
АдмиЛинк и его армия
Было много попыток преодолеть ненадежность стандартных рун.Наиболее известные — AdmiLink, CPAU, Encrypted RunAs и другие.
Всех их объединяет финальный способ запуска, о котором мы поговорим далее.
В целом алгоритм работы этих программ следующий: берём имя и пароль пользователя, под именем которого будет запускаться целевая программа (обычно с правами администратора), добавляем к нему путь и контрольную сумму исполняемого файла.
(чтобы его нельзя было заменить на произвольный), и вся эта информация дико зашифрованный , чтобы его могла расшифровать только авторская программа и желательно только на этом же компьютере.
Проблема в том, что вся эта защита бессмысленна, поскольку имя и пароль администратора могут быть перехвачены после того, как они уже расшифрованы.
Дополнительная проблема в том, что авторы этих программ не подозревают об этом и убеждают системных администраторов в безопасности своих разработок:
Итак, AdmiLink – это очень хороший «кирпичик» в системе безопасности, задача которого – БЕЗОПАСНЫЙ ЗАПУСК программ.Безопасный запуск означает, что:
Пользователь сможет запустить нужную программу с необходимыми правами.Пользователь не сможет узнать пароль Администратора через ярлык запуска.
Пользователь не сможет запустить не авторизованную Администратором программу, даже заменив в ярлыке исполняемый файл или командную строку.
admilink.ru/admilink.htm#NotProtected
Как работают RunAs и аналоги
Этот момент хорошо обсудил Мик Гроув в своей статье.Получение учетных данных из программного обеспечения «Encrypted RunAs» еще в 2013 году.
Он отметил, что любое подобное программное обеспечение не изобретает велосипед, а использует стандартную функцию CreateProcessWithLogonW для запуска программ от имени другого пользователя, которому логин и пароль необходимо передавать открытым текстом в качестве параметров.
А это, в свою очередь, означает, что запросы к функциям можно перехватить и просто прочитать их параметры, получив логин и пароль администратора.
Здесь для мониторинга использовалась бесплатная программа API-монитор , и самое главное, для ее запуска не нужны права администратора, она отлично работает в пользовательском пространстве, так как функция CreateProcessWithLogonW вызывается в контексте пользователя, а сама функция запускает процесс с заданными учетными данными, как следует из ее названия .
Учетные данные администратора получаются по следующей цепочке:
- Пользователь с ограниченными правами запускает ярлык, в котором хорошо зашифрованы данные для запуска программы.
- RunAs или его аналоги проверяют правильность шифра и целостность программы, затем извлекают данные и передают их в открытом виде в функцию CreateProcessWithLogonW.
- В то же время API-мониторинг перехватывает данные, передаваемые функции в качестве параметров, что делает шифрование паролей бессмысленным и полностью компрометирует учетные данные администратора.
Все потеряно?
Какие меры следует предпринять, если на вашем сервере используется такой способ запуска программ для пользователей? Прежде всего, вам необходимо сменить пароли администратора и провести аудит системы на предмет отсутствия взлома с использованием этой уязвимости.Если у вас запрещен запуск всех сторонних программ, это несколько снижает остроту проблемы, но незначительно – вам нужно убедиться, что папки, из которых разрешен запуск программ, были недоступны для записи пользователям, и вы добраться до них можно разными способами: кроме Проводника, где доступ к файловой системе можно ограничить твиками, в систему встроены как минимум командная строка и PowerShell; пользователям с ограниченными правами также должно было быть заранее запрещено запускать их.
Имея на руках учетные данные администратора, пользователь больше ничем не ограничен и все данные на таком сервере следует считать скомпрометированными.
Помните, что безопасность сервера — это комплексная мера, и она достигается суммой правильно настроенных параметров, многие из которых здесь не упомянуты.
Есть ли альтернативы?
Они как будто существуют, но их не существует. На данный момент я знаю один - RunAsRob , который использует другой метод: вместо запуска программы от имени другого пользователя, используя заранее сформированный список разрешенных программ, он временно предоставляет права администратора запущенной программе через сервис, работающий от имени системы.Благодаря такому подходу исключается утечка учетных данных, а доступ к целевым программам необходимо ограничивать с использованием прав NTFS. На данный момент рекомендовать его не могу, так как он платный и глючный, но за неимением других можно воспользоваться этим в крайнем случае.
Для неинтерактивных программ однозначно лучше использовать планировщик, вызываемый по событию в журнале.
В упомянутой выше статье дополнительно указано Just Enough Administration (JEA), однако мое исследование этого инструмента показало, что его нельзя полноценно использовать для интерактивного запуска приложений с Windows — поскольку процессы запускаются от имени другого виртуального администратора, окна программ не будут работать.
быть видимым для текущего пользователя.
JEA может помочь организовать запуск автоматических скриптов и просмотреть вывод консольных программ; это определенно более информативно, чем планировщик, но для работы с оконными приложениями не подходит. Можно ли запретить мониторинг API в системе для ограниченных пользователей и тем самым решить проблему перехвата системных функций — я на данный момент не знаю.
Если вам есть что добавить к этой статье, пожалуйста, оставьте комментарий.
P.S. RestAdmin — концепция безопасного запуска от имени администратора (решение было разработано после этой статьи).
Теги: #информационная безопасность #Разработка Windows #ИТ-инфраструктура #Windows #Системное администрирование #Программное обеспечение #безопасность #RunAs #AdmiLink #RunAsRob
-
Безногие Амфибиды
19 Oct, 24 -
Уровень Агрегации Базы Данных
19 Oct, 24
