runas exe что это

&nbsp &nbsp Команда RunAS используется для запуска приложения под учетной записью пользователя, имя которого передается в качестве параметра командной строки. В Windows 7, и более поздних, данная команда, при стандартных настройках безопасности, не позволяет получить администраторские привилегии, как это происходит в режиме «Запустить от имени Администратора». Для запуска приложения от имени администратора потребуется выполнение некоторых настроек системы. Универсальный способ запуска приложений и командных файлов от имени администратора без запроса системы контроля учетных записей UAC с использованием стандартного Планировщика заданий описан в статье Запуск из командного файла приложений от имени Администратора без запроса UAC.

Формат командной строки RUNAS:

RUNAS [ [/noprofile | /profile] [/env] [/savecred | /netonly] ] /user:имя пользователя программа

RUNAS [ [/noprofile | /profile] [/env] [/savecred] ] /smartcard [/user:имя пользователя] программа

RUNAS /trustlevel:уровень доверия программа

Параметры командной строки:

В системе доступны следующие уровни доверия:
0x20000 (Обычный пользователь)

Для запуска приложений от имени администратора с использованием runas.exe необходимо изменить стандартные настройки безопасности системы:

— включить учетную запись Администратора ( по умолчанию, она отключена);

— задать пароль для пользователя Администратор ;

Для проверки наличия прав администратора использовался командный файл с именем who-admin.bat следующего содержания:

WHOAMI /PRIV | find /i «SeRemoteShutdownPrivilege»

if %ERRORLEVEL% == 0 goto admin

echo NOT have admin rights!

Пароли, запоминаемые при использовании утилиты RUNAS.EXE с параметром /savecred можно изменить или удалить с помощью оснастки управления сохраненными паролями:

При наборе ключевых значений нужно соблюдать регистр символов.

Источник

Описание

Синтаксис

Параметры

Примечания

Примеры использования

После запроса введите пароль администратора.

Чтобы запустить экземпляр оснастки «Управление компьютером», используя учетную запись администратора домена companydomain\domainadmin, введите команду:

После запроса введите пароль соответствующей учетной записи.

Чтобы запустить экземпляр блокнота, используя учетную запись администратора домена user в домене domain.microsoft.com, введите команду:

После запроса введите пароль соответствующей учетной записи.

Чтобы запустить экземпляр окна командной строки, сохраненную консоль MMC, компонент панели управления или программу, которая будет администрировать сервер в другом лесе, введите команду:

В параметре домен\имя_пользователя должен быть указан пользователь с разрешениями, достаточными для администрирования сервера. После запроса введите пароль соответствующей учетной записи.

Источник

Runas

Applies To: Windows Server 2003, Windows Vista, Windows XP, Windows HPC Server 2008 R2, Windows Server 2008, Windows 7, Windows Server 2003 R2, Windows Server 2000, Windows Server 2012, Windows Server 2003 with SP1, Windows 8

Allows a user to run specific tools and programs with different permissions than the user’s current logon provides.

Runas is a command-line tool that is built into Windows Vista. To use runas at the command line, open a command prompt, type runas with the appropriate parameters, and then press ENTER.

In the user interface for Windows Vista, the Run as… command has been changed to Run as administrator. However, you should rarely have to use the Run as administrator command because Windows Vista will automatically prompt you for an administrator password when it is needed.

For examples of how this command can be used, see Examples.

Syntax

Parameters

/profile

Loads the user’s profile. This is the default. This parameter cannot be used with the /netonly parameter.

/no profile

Specifies that the user’s profile is not to be loaded. This allows the application to load more quickly, but it can also cause a malfunction in some applications.

Specifies that the current network environment be used instead of the user’s local environment.

/netonly

Indicates that the user information specified is for remote access only. This parameter cannot be used with the /profile parameter.

/savecred

Indicates if the credentials have been previously saved by this user. This parameter is not available and will be ignored on Windows Vista Home or Windows Vista Starter Editions. This parameter cannot be used with the /smartcard parameter.

/smartcard

Indicates whether the credentials are to be supplied from a smartcard. This parameter cannot be used with the /savecred parameter.

/showtrustlevels

Displays the trust levels that can be used as arguments to /trustlevel.

/trustlevel

Specifies the level of authorization at which the application is to run. Use /showtrustlevels to see the trust levels available.

/user: «

Displays help at the command prompt.

Remarks

Enter the user’s password only when prompted.

It is good practice for administrators to use an account with restrictive permissions to perform routine, nonadministrative tasks, and to use an account with broader permissions only when performing specific administrative tasks. To accomplish this without logging off and back on, log on with a regular user account, and then use the runas command to run the tools that require the broader permissions.

The use of runas is not restricted to administrator accounts, although that is the most common use. Any user with multiple accounts can use runas to run a program, MMC console, or Control Panel item with alternate credentials.

If you want to use the Administrator account on your computer, for the /user: parameter, type one of the following:

If you want to use this command as a domain administrator, type one of the following:

With the runas command, you can run programs (*.exe), saved MMC consoles (*.msc), shortcuts to programs and saved MMC consoles, and Control Panel items. You can run them as an administrator while you are logged on to your computer as a member of another group, such as the Users or Power Users group.

You can use the runas command to start any program, MMC console, or Control Panel item. As long as you provide the appropriate user account and password information, the user account has the ability to log on to the computer, and the program, MMC console, or Control Panel item is available on the system and to the user account.

With the runas command, you can administer a server in another domain or forest (the computer from which you run a tool and the server you administer are in different domains or forests).

If you try to start a program, MMC console, or Control Panel item from a network location using runas, it might fail because the credentials used to connect to the shared network resource are different from the credentials used to start the program. The latter credentials may not be able to gain access to the same shared network resource.

Some items, such as the Printers folder and desktop items, are opened indirectly and cannot be started with the runas command.

If the runas command fails, the Secondary Logon service might not be running or the user account you are using might not be valid. To check the status of the Secondary Logon service, in Computer Management, click Services and Applications, and then click Services. To test the user account, try logging on to the appropriate domain using the account.

Group Policy is not processed for the user whose credentials are supplied to the runas command. This is by design. The runas command can load the user profile of the secondary user whose identity is being used to create the process, and that user profile may contain registry keys and values from previous interactive logons when Group Policy was processed for that user. However, the runas command also contains a /noprofile switch that bypasses the loading of the user profile, so that behavior should not be relied upon. User GPO is only processed for users who log on interactively to their own desktops by using the logon user interface.

Examples

The following command starts an instance of the command prompt as an administrator on the local computer:

When prompted, type the administrator account password.

The following command starts an instance of the Computer Management snap-in using a domain administrator account called contoso\domainadmin:

When prompted, type the domain administrator account password.

The following command starts an instance of Notepad (and a file named my_file.txt) using a domain administrator account called jayj in a domain called domain.contoso.com:

When prompted, type the domain administrator account password.

The following command starts an instance of a command prompt window, saved MMC console, Control Panel item, or program that will administer a server in another forest:

\ must be a user with sufficient permissions to administer the server. When prompted, type the account password.

Источник

RunAs

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

Запись реестра

Remarks

Значение указывает имя пользователя и должно иметь одно из двух значений: имя пользователя, домен * \ имя пользователя или строка «Интерактивный пользователь». Можно также указать строки «NT Authority \ LocalService» (для локальной службы) и «NT Authority \ NetworkService» (для сетевой службы). Кроме того, можно указать строку «NT Authority \ System», если <AppID _ GUID *> ссылается на COM-сервер, который уже запущен или имеет запись в таблице классов. Тем не менее нельзя использовать «систему NT Authority \ » с сервером COM, который еще не запущен. Пароль по умолчанию для «NT Authority \ LocalService», «NT Authority \ NetworkService» и «система NT Authority \ » — «» (пустая строка).

начиная с Windows Vista, больше не требуется пустой пароль для настройки \ параметров запуска от имени «локальная служба nt», «nt authority \ networkservice» и «nt authority \ system».

Классы, настроенные для запуска от имени конкретного пользователя, могут не регистрироваться под другим удостоверением, поэтому вызовы CoRegisterClassObject с этим CLSID завершаются неудачей, если процесс не был запущен com от имени фактического запроса на активацию.

Имя пользователя берется из значения runas в ключе AppID класса. Если имя пользователя — «Интерактивный пользователь», сервер выполняется с удостоверением пользователя, который в данный момент вошел в систему и подключен к интерактивному рабочему столу.

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

Значение runas не используется для серверов, настроенных для запуска в качестве служб. Службы COM, которые должны выполняться под удостоверением, отличным от LocalSystem, должны устанавливать соответствующие имя пользователя и пароль с помощью приложения панели управления «службы» или функций контроллера служб. (Дополнительные сведения об этих функциях см. в разделе службы.)

на сервере Microsoft Windows Server 2003 класс appid явно читается из _ _ \ классов программного обеспечения локального компьютера HKEY \ \ appid, что, в отличие от большинства разделов реестра, не является взаимозаменяемым с _ _ корневым \ идентификатором классов hkey.

Источник

Проблема использования RunAs на серверах

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

Зачем это вообще нужно? Бывают ситуации, когда пользователю с ограниченными правами требуется выполнить программу, которой для выполнения специфической работы требуются повышенные права. Например, программисту нужно предоставить возможность завершать определённые процессы бухгалтерской программы, некоторым пользователям из бухгалтерии требуется возможность переключать ключи безопасности в интерактивном режиме и так далее. Часть этих задач можно выполнять неинтерактивно, при этом несколько страдает удобство, поскольку пользователь не видит интерфейс программы и может разве что получить системное сообщение о завершении работы программы, об этом способе подробно рассказал мой коллега Вадим Стеркин в своём блоге: Как выполнять задачи с полными правами обычным пользователем без ввода пароля администратора. Способ отличный для своих задач, в моей же статье речь пойдёт о рисках и безопасности выполнения интерактивных программ от имени других пользователей, где полной автоматизации достичь нельзя и есть необходимость взаимодействия с интерфейсом.

Самое важное, что должен уяснить администратор — из запущенной программы с повышенными правами не должно быть возможности запустить другую произвольную программу, поскольку права автоматически наследуются. Прежде чем вообще планировать создавать ярлык для запуска, следует самостоятельно убедиться, что в программе нет окон открытия других файлов или запуска справки с собственной программой обработки, где дополнительно можно вызвать диалог открытия других файлов справки, и тому подобные в данном случае уязвимости, которые позволят пользователю запустить произвольную программу с правами администратора. Ещё пример — программа при определённых или редких обстоятельствах открывает логи в блокноте, а уже там есть диалог открытия других файлов, вот и готовая уязвимость. То есть целевая программа должна быть изучена администратором вдоль и поперёк (а ещё лучше — написана самостоятельно), чтобы пользоваться ей было действительно безопасно.

RunAs из коробки

В системе есть родная утилита runas, позволяющая выполнять задачу запуска от другого имени, однако пользоваться ей нужно осторожно и в целях безопасности её нельзя применять для запуска программ с повышенными привилегиями, но можно наоборот — администратору запускать программы с правами обычного пользователя, хотя технически возможны оба варианта. Почему так? Параметр /savecred позволяет сохранить пароль для пользователя, от имени которого запускается программа, в профиле пользователя, который запускает программу. Однако этот же сохранённый пароль RunAs использует и для запуска любых других программ, запуск которых может инициировать пользователь, у которого сохранён пароль.

Рассмотрим это на примере: у нас есть Admin с правами администратора, User1 с необходимостью запуска программы от имени администратора, и все остальные пользователи, которые эту программу запускать не должны, назовём их условно User2, а тестовая программа — калькулятор (calc). Когда администратор хочет запустить программу от имени пользователя для проверки или из планировщика, он может сохранить пароль User1 в своём профиле, выполнив команду «runas /savecred /user:User1 calc», ввести пароль User1 и в дальнейшем для этой команды пароль запрашиваться не будет, но также он не будет запрашиваться и для других программ, помимо калькулятора. При этом User2, который выполнит у себя эту же команду, столкнётся с необходимостью ввода пароля для User1, поскольку в его профиле этот пароль заранее не сохранён. Такой сценарий допустим и безопасен, ведь администратор и так имеет полные права. Однако если мы выполним команду «runas /savecred /user:Admin calc» от имени User1 и введём пароль администратора, User1 сможет запускать любые программы от имени администратора, что полностью разрушает модель безопасности.

Вывод — использовать родной runas в составе системы для повышения прав на постоянной основе (с сохранением пароля) категорически нельзя, эта уязвимость должна быть очевидна каждому сисадмину. Да и без сохранения пароля вводить пароль администратора под ограниченным пользовательским сеансом не рекомендуется, если там заранее не были предприняты меры предосторожности, которые не позволяют запускать произвольные программы (SRP, AppLocker), иначе пользователь может запросто перехватить пароль. А мы переходим к неочевидным уязвимостям.

AdmiLink и его армия

Попыток преодолеть небезопасность стандартного runas предпринято множество, тысячи их. Самые известные — AdmiLink, CPAU, Encrypted RunAs и другие. Всех их объединяет конечный способ запуска, который мы разберём далее. В целом алгоритм работы этих программ такой: берём имя и пароль пользователя, от имени которого будет выполняться запуск целевой программы (как правило с правами администратора), добавляем к нему путь и контрольную сумму исполняемого файла (чтобы его нельзя было подменить на произвольный), и всю эту информацию дико шифруем, чтобы расшифровать могла только авторская программа, и желательно только на том же компьютере. Проблема в том, что вся эта защита не имеет никакого смысла, поскольку имя и пароль администратора можно перехватить тогда, когда он уже будет расшифрован. Дополнительная проблема в том, что авторы этих программ об этом не подозревают и убеждают системных администраторов в безопасности своих разработок:

Так вот, AdmiLink — это очень неплохой «кирпич» в системе защиты, задачей которого является БЕЗОПАСНЫЙ ЗАПУСК программ. Безопасный запуск означает, что:

Пользователь сможет запускать нужную программу с нужными правами.

Пользователь не сможет узнать пароль Администратора через ярлык запуска.

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

Как работает RunAs и аналоги

Этот момент хорошо разобрал Mick Grove в своей статье Capturing credentials from ‘Encrypted RunAs’ software ещё в 2013 году. Он заметил, что любой подобный софт не изобретает велосипед, а использует для запуска программ от имени другого пользователя стандартную функцию CreateProcessWithLogonW, которой в качестве параметров нужно передавать логин и пароль в открытом виде. А это в свою очередь означает, что запросы к функциям можно перехватить и просто прочитать их параметры, получив на руки логин и пароль администратора. Для мониторинга здесь использовалась бесплатная программа API Monitor, и что самое важное, для её запуска не нужны права администратора, она отлично работает в пользовательском пространстве, поскольку обращение к функции CreateProcessWithLogonW происходит именно в контексте пользователя, а уже сама функция осуществляет запуск процесса с заданными учётными данными, что и следует из её названия.

Получение учётных данных администратора происходит по следующей цепочке:

Пользователь с ограниченными правами запускает ярлык, в котором хорошо зашифрованы данные для запуска программы.

RunAs или его аналоги проверяют корректность шифра и целостность программы, затем извлекают данные и в открытом виде передают их функции CreateProcessWithLogonW.

В это же время API-мониторинг перехватывает данные, переданные функции в качестве параметров, чем делает бессмысленным шифрование пароля и полностью компрометирует учётные данные администратора.

Всё пропало?

Какие меры нужно принять, если на вашем сервере использовался такой способ запуска программ для пользователей? В первую очередь нужно поменять пароли администраторов и провести аудит системы, не было ли взлома с использованием этой уязвимости. Если у вас был запрещён запуск всех посторонних программ, это слегка снижает градус проблемы, но только слегка — нужно убедиться, что пользователям не были доступны для записи те папки, из которых им был разрешён запуск программ, а добраться до них можно разными способами: кроме проводника, где доступ к ФС можно ограничить твиками, как минимум в систему встроены командная строка и PowerShell, запретить их запуск ограниченным пользователям тоже нужно было заранее. Имея же учётные данные администратора на руках, пользователь уже не ограничен ничем и все данные на таком сервере следует считать скомпрометированными. Помните, что безопасность сервера это комплексная мера, и она достигается суммой правильно настроенных параметров, многие из которых здесь не упомянуты.

Есть ли альтернативы?

Они как бы и есть, и их как бы нет. На данный момент мне известно об одной — RunAsRob, которая использует другой метод: вместо запуска программы от имени другого пользователя она по заранее сформированному списку разрешённых программ временно выдаёт права администратора запускаемой программе посредством службы, работающей от имени системы. Благодаря такому подходу исключается утечка учётных данных, а разграничивать доступ к целевым программам нужно NTFS-правами. На данный момент я не могу её рекомендовать, так как она платная и глючная, однако за неимением других в крайнем случае можно использовать эту. Для неинтерактивных программ однозначно лучше использовать планировщик с вызовом по событию в журнале.

В вышеупомянутой статье дополнительно указывается Just Enough Administration (JEA), однако моё исследование этого инструмента показало, что им не получится пользоваться полноценно для интерактивного запуска приложений с окнами — так как процессы запускаются от имени другого виртуального администратора, то окна программ не будут видны для текущего пользователя. JEA может помочь в организации запуска автоматических скриптов и просмотра вывода результатов консольных программ, это определённо информативнее планировщика, но для работы с оконными приложениями не годится.

Можно ли запретить в системе мониторинг API для ограниченных пользователей и этим решить проблему перехвата системных функций — на данный момент мне не известно. Если вам есть что добавить к этой статье, оставьте свой комментарий.

P. S. RestAdmin — концепция безопасного Run As Admin (решение было разработано после этой статьи).

Источник