Насколько безопасен runastool.exe, существуют ли известные проблемы?

Не знаю, насколько известен этот инструмент, но администратор в нашей организации использует RunAsTool v1.5: https://www.sordum.org/8727/runastool-v1-5/

Ранее я о нем не слышал, на сайте, похоже, предлагается множество бесплатных программ, которые должны предоставить больше контроля над Windows.

Я увидел около 200 комментариев пользователей, так что, думаю, некоторые люди его используют и довольно довольны.

Тем не менее, видят ли более опытные люди здесь какой-либо риск? Были ли какие-либо известные проблемы с безопасностью этого инструмента?

Чтобы работать правильно, RunAsTool необходимо установить на систему Windows, которая имеет учетную запись администратора с паролем. Учетные данные для приложения, такие как имя пользователя и пароль, считываются из зашифрованного файла – вам не о чем беспокоиться, ваш администраторский пароль в безопасности.

Из веб-страницы инструмента.

Это означает, что он сохраняет пароль. Если инструмент может извлечь пароль, то и злоумышленник может это сделать. Тот факт, что авторы говорят вам не волноваться, показывает, что они… не ориентированы на безопасность. Я бы поэтому заподозрил, что инструмент имеет несколько недостатков и проблем с безопасностью.

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

Если вам когда-либо понадобится это программное обеспечение, лучше использовать встроенную функцию Windows UAC. UAC обеспечивает реальную безопасность и не создает дополнительных проблем.

Я верю, что важно оспаривать предположение о том, что отсутствие известных проблем делает программное обеспечение безопасным. Как правило, не считается хорошей политикой безопасности разрешать людям запускать с административными привилегиями любой случайный exe из любого случайного сайта, если только нет известных проблем. “Нет известных проблем” — это состояние по умолчанию, достижимое в полном неведении, и если это лучшее, что можно сказать о конкретном программном обеспечении, то оно находится так далеко от безопасности, насколько это возможно, без активного злонамеренного поведения.

Вопросы, которые вы должны задать поставщику программного обеспечения, критичного для безопасности, конечно, зависят от того, что оно делает, и стандартов вашей организации, но это определенно должно быть больше, чем “У вас есть веб-сайт с положительными комментариями”, который, в принципе, любой может очень легко создать, и “Можете ли вы дать мне случайный исполняемый файл, который вы обещаете, будет делать то, что я хочу, и совершенно не является троянским, но который вы не хотите, чтобы я обратным образом проинженерировал для проверки”.

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

Я скажу это прямо. Невозможно, чтобы RunAsTool выполнял свои функции безопасно, как он это заявляет. “Для работы требуется локальная учетная запись администратора”. Так не бывает. Они сделали это неправильно.

Присоедините отладчик и установите точку останова на CreateUserWithLogonW. Готов поспорить, что вы получите правильный пароль.

Вот как я знаю. Единственный встроенный API, который работает на этом уровне, — это CreateProcessWithLogonW, и он работает только если вы предоставите пароль. Следовательно, они сделали что-то глупое.

Теперь предположим, что они сделали это правильно и нашли способ, который на самом деле безопасен. Зная решение, я понимаю, какие компоненты вовлечены, и это сводится к NtCreateToken. Если бы они сделали это любым способом, который работает, им не потребовался бы пароль администратора для настройки.

Правильный способ №1: создайте новую учетную запись пользователя и дайте ей много привилегий, включая “Действовать как часть операционной системы”, “Создать токен процесса”, “Назначить основной токен” и “Войти как служба”. Создайте службу для инструмента. Установите разрешения на инструмент, чтобы любой пользователь мог его запускать и останавливать. Этот процесс затем проходит через шаги создания токена с правильной сессией и обязательным ACL для сеанса Windows и запускает процесс с этим токеном.

Правильный способ №2: создайте локальную системную службу для инструмента (поверьте мне; учетная запись администратора не сработает; нам нужно “Действовать как часть операционной системы”). Установите разрешения на инструмент, чтобы любой пользователь мог его запускать и останавливать. Этот процесс крадет токен у LSASS.EXE (у него есть привилегия “Создать токен”) и запускает процесс с этим токеном, который проходит через шаги создания токена с правильной сессией и обязательным ACL для сеанса Windows и запускает процесс с этим токеном.

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