Как в домене установить программу

Осуществлять автоматическую установку приложения можно разными способами:

1. С помощью скриптов ( .vbs, .js )
2. Пакетных файлов (. bat, .com )

Скрипты и пакетные файлы могут запускаться как вручную, так и с помощью различных инструментов:

1. Групповых политик (назначение или публикация приложения, выполнение скрипта во время входа в систему или во время выхода)
2. System Center Configuration Manager

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

Групповые политики (Group Policy) – набор правил, в соответствии с которыми производится настройка рабочей среды Windows. Групповые политики создаются в домене и реплицируются в рамках домена.

Групповые политики поддерживают 2 типа приложений:

1. Приложения, устанавливаемые при помощи WindowsInstaller (. MSIпакеты ).
2. Приложения, устанавливаемые любым другим способом (. ZAPприложения ).

Если с .MSI пакетами все понятно – для автоматической установки необходимо просто указать путь к установочному файлу. Данный файл , как вы понимаете, должен быть в формате .MSI. Для каждого такого файла создается специальный пакет. Это не удобно, если установка приложения требует использовать несколько .MSI пакетов.

Настройка AD GP: Как установить 1С на все ПК домена

В этом случае к нам на помощь приходят . ZAP пакеты.

ZAP пакет – конфигурационный файл, предназначенный для публикации приложений при помощи групповых политик домена Windows (Active Directory).

Минимальная конфигурация . ZAP пакета выглядит следующим образом:

[Application] FriendlyName = «Office 2003 SP 3» SetupCommand = \remote_serverinstallAutoInstallOffice_2003.bat

В качестве устанавливаемого приложения может использоваться любой исполняемый файл (. msi, .exe, .vbs, .js, .bat, .com ).

Более полная конфигурация выгладит следующим образом:

[Application] ; Только параметры FriendlyName и SetupName являются обязательными. ; Oстальные параметры являются необязательными. ; Параметр FriendlyName задает имя приложения, отображающееся ; в расширении «Установка программ», а также в компоненте панели управления ; «Установка и удаление программ». ; Обязательный параметр FriendlyName = «Office 2003» ; Параметр SetupCommand обозначает командную строку, которая ; используется для запуска установки приложения. ; Если это относительный путь, то расположение программы ; установки указывается относительно ZAP-файла. ; Путь необходимо заключить в кавычки, если в нем содержатся пробелы, либо ; если названия файлов или папок имеют длину более восьми символов. ; Также можно использовать полный сетевой путь к программе установки. ; Например: ; SetupCommand = «long foldersetup.exe» /unattend ; Обязательный параметр SetupCommand = setup.exe ; Версия приложения, которая будет отображена в расширении : «Установка программ», а также в компоненте панели управления ; «Установка и удаление программ». ; Необязательный параметр DisplayVersion = 8.0 ; Название компании, являющейся производителем приложения. ; Это название будет отображено в расширении «Установка программ», ; а также в компоненте панели управления ; «Установка и удаление программ». ; Необязательный параметр Publisher = Microsoft ; Адрес в сети Интернет для получения дополнительной ; информации о приложении. Он отображается в расширении ; «Установка программ», а также в компоненте панели управления ; «Установка и удаление программ» ; Необязательный параметр URL = http://www.microsoft.com/office ; Параметр, указывающий язык приложения. ; В нашем примере указан русский язык. ; Необязательный параметр LCID = 1049 ; Архитектура (в нашем случае – Intel). ; Необязательный параметр Architecture = intel ; В разделах [ext] [CLSIDs] и [progIDs] все ; параметры являются необязательными. [ext] ; Расширения файлов, связанные с приложением ; и инициализирующие его автоматическую установку. ; Эти параметры не потребуются, если у Вас нет необходимости ; в автоматической установке приложения. ; Весь раздел является необязательным. ; Примечание. Вы можете указать в начале расширения точку. ; Текст, следующий после первого символа «=», является ; необязательным и будет проигнорирован. ; Символ «=» является обязательным. В случае его отсутствия ; вся строка будет проигнорирована. XLS= [CLSIDs] ; Идентификатор CLSID, который будет использован ; при автоматической установке приложения. ; Весь раздел является необязательным. ; После идентификатора CLSID ставится символ «=», ; затем через запятую перечисляются параметры ; LocalServer32, InprocServer32 и/или InprocHandler32. [progIDs] ; Идентификатор progID, который будет использован ; при автоматической установке приложения. ; Весь раздел является необязательным. ; После идентификатора CLSID ставится символ » http://www.intuit.ru/2010/edi» >

Сделать запрет на запуск программ пользователя домена

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

Рис. 5.5.

К преимуществам . ZAP пакетов можно отнести возможность установки приложений, запакованный инсталлятором, отличным от Windows Installer ; использование ключей автоустановки; возможность задать для одного опубликованного приложения несколько исполняемых файлов (компонентов). К недостаткам относится невозможность удалить такие пакеты.

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

Типы размещения устанавливаемых пакетов:

1. Назначение. Назначенный пакет будет установлен автоматически.
2. Публикация. Для установки опубликованного приложения необходимо самостоятельно начать процесс, т.е. нажать кнопку «Добавить».

.MSI пакеты можно как назначать, так и публиковать. ZAP пакеты – только публиковать.

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

• Для публикации приложений на пользователя: «Конфигурация пользователя» -> «Конфигурация программ» -> «Установка программ».
• Для публикации приложения на компьютер: «Конфигурация компьютера» -> «Конфигурация программ» -> «Установка программ».

Затем нажать правой кнопкой мыши на пункте » Установка программ » и выбрать «Новый» -> «Пакет».

Указываем путь до пакета и в зависимости от типа пакета либо опубликовываем, либо назначаем приложение .

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

Источник: intuit.ru

Как в домене установить программу

Kaspersky Security Center позволяет устанавливать программы «Лаборатории Касперского» на управляемые устройства с помощью групповых политик Active Directory.

Установка программ с помощью групповых политик Active Directory возможна только из инсталляционных пакетов, в состав которых входит Агент администрирования.

Чтобы установить программу с помощью групповых политик Active Directory:

1. Начните настройку установки программы с помощью мастера удаленной установки.
2. В окне мастера удаленной установки Определение параметров задачи удаленной установки выберите параметр Назначить установку инсталляционного пакета в групповых политиках Active Directory .
3. В окне мастера удаленной установки Выбор учетных записей для доступа к устройствам выберите параметр Учетная запись требуется (Агент администрирования не используется) .
4. Добавьте учетную запись с правами администратора на устройство, на котором установлен Kaspersky Security Center, или учетную запись, входящую в доменную группу Владельцы-создатели групповой политики.
5. Предоставьте разрешения выбранной учетной записи:

1. Перейдите в Панель управления → Администрирование и откройте Управление групповой политикой .
2. Нажмите на узел с нужным доменом.
3. Нажмите на раздел Делегирование .
4. В раскрывающемся списке Права доступа выберите Связанные объекты GPO .
5. Нажмите на кнопку Добавить .
6. В открывшемся окне Выбор пользователя, компьютера или группы выберите необходимую учетную запись.
7. Нажмите на кнопку OK чтобы закрыть окно Выбор пользователя, компьютера или группы .
8. В списке Группы и пользователи выберите только что добавленную учетную запись и нажмите на Дополнительно → Дополнительно .
9. В списке записей разрешений дважды нажмите на только что добавленную учетную запись.
10. Предоставьте следующие разрешения:
11. создание объектов группы;
12. удаление объектов группы;
13. создание объектов контейнера групповой политики;
14. удаление объектов контейнера групповой политики.
15. Нажмите на кнопку ОК , чтобы сохранить изменения.

В результате будет запущен следующий механизм удаленной установки:

1. После запуска задачи в каждом домене, которому принадлежат клиентские устройства из набора, будут созданы следующие объекты:
2. Объект групповой политики (Group policy object, GPO) с именем Kaspersky_AK .
3. Группа безопасности содержит клиентские устройства, на которые распространяется задача. Эта группа безопасности содержит клиентские устройства, на которые распространяется задача. Состав группы безопасности определяет область объект групповой политики (GPO).
4. Kaspersky Security Center устанавливает выбранные программы «Лаборатории Касперского» на клиентские устройства осуществляется непосредственно из сетевой папки общего доступа программы Share. При этом в папке установки Kaspersky Security Center будет создана вложенная вспомогательная папка, содержащая файл с расширением msi для устанавливаемой программы.
5. При добавлении новых устройств в область действия задачи они будут добавлены в группу безопасности после следующего запуска задачи. Если в расписании задачи выбран флажок Запускать пропущенные задачи , устройства будут добавлены в группу безопасности сразу.
6. При удалении устройств из области действия задачи их удаление из группы безопасности произойдет при следующем запуске задачи.
7. При удалении задачи из Active Directory будут удалены объект групповой политики (GPO), ссылка на объект групповой политики (GPO) и группа безопасности, связанная с задачей.

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

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

Доступны следующие варианты использования другой схемы установки через Active Directory:

• Если установку требуется осуществлять непосредственно из папки общего доступа Kaspersky Security Center, в свойствах групповой политики Active Directory следует указать файл с расширением msi, расположенный во вложенной папке exec в папке инсталляционного пакета нужной программы.
• Если инсталляционный пакет нужно разместить на другом сетевом ресурсе, следует скопировать в него все содержимое папки exec, так как помимо файла с расширением msi в ней содержатся конфигурационные файлы, сформированные при создании инсталляционного пакета. Чтобы лицензионный ключ был установлен вместе с программой, в эту папку следует также скопировать файл ключа.

Источник: support.kaspersky.com

Прав достаточно: 8 приемов для обхода групповых политик в домене

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

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

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

Что такое Групповые политики (Group Policy)?

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

Проще говоря, это довольно мощный инструмент для ограничения в действиях обычных пользователей. Существует масса различных политик и прав, с помощью которых можно запретить вызов диспетчера задач или редактора реестра, запретить доступ к меню «Пуск», а также довольно гибко ограничить запуск программного обеспечения (это реализуется с помощью так называемых Software Restriction Policies).

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

Все политики можно разбить на две категории — для компов и для пользователей. Групповые политики доступны как в домене, так и на локальном компе. Если речь идет о локальной машине, то их можно посмотреть через специальную оснастку gpedit.msc (secpol.msc). В данной статье основной акцент сделан именно на доменные групповые политики. Итак, приступим.

Трюк 1. Обходим загрузку политик

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

1. Админ создает объект групповой политики.
2. Привязывает его к каким-то элементам домена.
3. При входе в домен комп отправляет запрос на получение политик и получает их в ответ от домена.
4. При входе пользователя выполняется аналогичный запрос, но уже по пользовательским политикам.

Итак, что мы здесь видим: политики подгружаются на стадии входа в систему. Здесь есть небольшая фича. По умолчанию обновление политик выполняется каждые 5 минут. Но если политики не были получены во время входа в систему, то обновляться они не будут! Вырисовывается элементарный способ, как эту особенность можно использовать:

1. Вынимаем патч-корд из компа.
2. Включаем комп и логинимся под своей учеткой.
3. Подключаем патч-корд обратно.

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

Трюк 2. Как происходит проверка политик?

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

Политики для компа:

• HKEY_LOCAL_MACHINESoftwareMicrosoft WindowsCurrentVersionPolicies
• HKEY_LOCAL_MACHINESoftwarePolicies

Политики для пользователей:

• HKEY_CURENT_USERSoftwareMicrosoft WindowsCurrentVersionPolicies
• HKEY_CURENT_USERSoftwarePolicies

Когда запускается какой-то процесс, то в нем (то есть в userspace’е) производится проверка данных веток реестра (через подгруженную библиотеку advapi.dll) на те или иные ограничения, которые потом кешируются/сохраняются в памяти процесса. Они проверяются, когда пользователь выполняет какое-то действие, например запуск ПО. В чем подвох? В том, что контроль производится из самого процесса.

То есть если процесс «не захочет» проверять политики, то ничто его не заставит их соблюдать. Никакого общего мониторинга не производится! Отсюда вывод: если мы каким-то образом сможем запустить произвольный процесс, то политики нам уже не страшны. Сделать как правило — не проблема. Даже если нет возможности закачать программу на хост, можно выполнить ее удаленно (например, через шару).

Трюк 3. Обходим SRP

Увы, дальше на нашем пути возникает другой механизм ограничений — SRP (Software Restriction Policies). Это группа политик, с помощью которых админ может ограничить список ПО, которое может запускать пользователь, через черный и белый списки.

Blacklist и Whitelist определяются с помощью правил, которые можно задавать несколькими способами: по зонам и по сертификатам (первые два варианта практически не используются), а также по пути до файла и по его хешу. О том, что в системе действуют политики SRP, указывает соответствующий пункт в реестре — HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoft WindowsSafer CodeIdentifiersTransparentEnabled со значением большим 0, который, как уже было сказано выше, проверяется при запуске процесса.

Наша задача, соответственно, отрубить эту проверку внутри запускаемого процесса. Марк Руссинович еще в далеком 2005 году опубликовал пост в блоге об обходе SRP и представил тулзу GPdisable. Она производит DLL-инъекцию в заданный процесс, подгружая специальную DLL’ку.

Когда процесс попытается получить значение ключа реестра HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsSafer CodeIdentifiersTransparentEnabled , то есть будет проверять присутствие политик SRP, данная библиотека перехватит запрос и возвратит STATUS_OBJECT_NAME_NOT_FOUND. Таким образом, процесс думает, что все ОК и SRP политики в системе не действуют.

После покупки компании Sysinternals Майкрософтом GPdisable перестал был официально доступным (но его по-прежнему легко найти в Сети. Есть еще более продвинутые решения. Утилита GPCul8or от Eric’a Rachner’a выполняет аналогичные функции, но доступна в исходниках. Что это нам дает?

Мы можем добавить в GPCul8or любые другие значения реестра винды (DisableTaskMgr, ProxySettingsPerUser к примеру) и таким образом обойти все возможные ограничения политик. Какие именно значения, спросишь ты. Тебе в помощь RegMon от Марка Руссиновича, хотя, по сути — это все значения из ветки Policies. Другой оригинальный способ в своем блоге опубликовал Дидье Стивенс. Используя свою тулзу bpmtk (Basic Process Manipulation Tool Kit), он предложил прямо в памяти процесса изменять значение необходимого для групповой политики ветки реестра.

Трюк 4. Binary planting

Утилита GPdisable состоит из двух файлов:

• gpdisable.exe — инъектирует DLL в процесс;
• gpdisable.dll — специальная DLL для обхода SRP.

Как я уже сказал, если мы можем запустить приложение, то можем легко обойти SRP и другие политики (через GPdisable, bpmtk, GPCul8or — неважно). Однако в реальной системе может оказаться не так уж просто запустить эти приложения. Но мы можем подгрузить DLL (в том числе gpdisable.dll). Тут есть важный нюанс.

Групповые политики при запуске ПО могут проверять и DLL’ки, но при этом достаточно сильно падает производительность системы, потому по умолчанию эта опция отключена. И мы это можем использовать! Очень кстати приходится недавнее исследование от компании Across Security, которое рассказывает о новых (достаточно извращенных, но работающих) методах подгрузки кода в процессы. Прием называется Binary planting (и как его классический пример — dll hijacking), при его изучении у меня возникла мысль: «а почему не использовать его для обхода групповых политик?». Если система разрешает запуск приложений только из белого списка (пускай даже только Word), то этого уже достаточно, чтобы подгрузить нашу полезную DLL для обхода SRP. Итак, попробуем скрестить dll hijacking от парней из Across и GPdisable:

1. Переименовываем gpdisable.dll в ehTrace.dll.
2. Создаем папку с именем куку. (название любое, текст после точки исчезнет).
3. Кидаем ehTrace.dll в только что созданную папку.
4. Заходим в папку и создаем там любой документ в Word, Excel или, к примеру, PDF’ку.
5. Теперь открываем только что созданный файл.
6. Соответствующая программа должна запуститься. И запустить вместе с подгруженной DLL’кой!
7. Все, политики нам не страшны.

Трюк 5. Используем исключения

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

• на программы, запущенные от имени учетной записи SYSTEM;
• драйверы и другие приложения уровня ядра;
• макросы внутри документов Microsoft Office;
• программы, написанные для общей многоязыковой библиотеки времени выполнения (Common Language Runtime).

Итак, процессы от SYSTEM не контролируются. Первый финт ушами: если есть доступ к какому-то ПО, запущенному под такой учеткой, — атакуем. Например, нажимаем Win+U — запускаются «специальные возможности» (лупа и экранная клавиатура). Utilman.exe (процесс «специальных возможностей») при этом запускается от SYSTEM. Далее идем там в «Справку».

Она тоже должна открыться с нужными привилегиями, так как запущена в контексте процесса c правами SYSTEM. Если винда не самая новая (до Vista), то кликаем правой кнопкой на синей верхней панельке «Jump to url», там печатаем «C:» и получаем настоящий встроенный explorer. Если более новая, то можно по правому клику в тексте хелпа просмотреть исходный код (View Source) через блокнот, откуда далее добраться до файлов. Или другой вариант — «добавить» новый принтер, получив опять же доступ к листингу файлов.

Другая интересная категория — макросы внутри документов Microsoft Office. Это страшное дело. Попробуем для начала реализовать запуск ПО. Хотя если запуск заблочен обычными политиками (не SRP), как, например, блокировкой диспетчера задач, то этот обход не сработает. Но нам-то главное — запустить специальный exe’шник. Поэтому в любом документе смело создаем следующий макрос и пробуем запустить его:

Sub GOSHELL()
Shell «C:windowssystem32regedit.exe», vbNormalFocus
End Sub

В результате, как ты можешь догадаться, мы получаем запущенный exe. Хардконный метод предложил опять же Дидье Стивенс. Используя в макросе MS Excel функции VirtualAlloc, WriteProcessMemory и CreateThread, он сумел подгрузить шеллкод из макроса в память процесса. Данный шеллкод подгружает DLL’ку в память процесса, а DLL’ка — не что иное, как cmd.exe. Кстати, ее исходники взяты из проекта ReactOS.

Как я уже сказал, SRP может препятствовать запуску DLL’ек (хотя и не делает этого по умолчанию), но если подгрузку библиотек осуществлять, используя функцию LoadLibraryEx с LOAD_IGNORE_CODE_AUTHZ_LEVEL вместо LoadLibrary, то проверка на принадлежность подгружаемой dll к white-листу не происходит!

Трюк 6. Используем переменные среды

Когда начинаешь мучить групповые политики, то приходит осознание, что для создания защищенной системы потребуется попотеть. Дело трудное и с большим количеством тонкостей. Например, разработчики предлагают админам использовать удобный хинт — указывать переменные среды в качестве путей для ограничений SRP. Да вот здесь проблема. У пользователя, если их жестко не прищучить, есть возможность их переопределять. Указал, например, админ, что из папки %TEMP% можно запускать exe’шники, а юзер взял да и переопределил следующей командой:

И вот так просто получил возможность запускать файлы из корня C:. Кроме того, не стоит забывать про стандартные директории, из которых разрешен запуск exe-файлов:

• %HKEY_LOCAL_MACHINESOFTWAREMicrosoft Windows NTCurrentVersionSystemRoot%
• %HKEY_LOCAL_MACHINESOFTWAREMicrosoft Windows NTCurrentVersionSystemRoot%*.exe
• %HKEY_LOCAL_MACHINESOFTWAREMicrosoft Windows NTCurrentVersionSystemRoot%System32*.exe
• %HKEY_LOCAL_MACHINESOFTWAREMicrosoft WindowsCurrentVersionProgramFilesDir%

Они разрешают запуск ПО только из папки Windows и Program Files для пользователей. У обычного пользователя нет возможности записи в них, но и здесь могут быть проблемы. Так как на самом деле права на запись у пользователя есть — по дефолту в папку C:windowssystem32spoolPrinters и C:windowstemp. Если у пользователя будет возможность писать в какой-то каталог с софтом, то, считай, соответствующие политики SRP уже не сработают. Кстати, для того чтобы на практике поверить, какие у пользователя есть права, поможет тулза — AccessChk от все того же Руссиновича.

Трюк 7. Используем другого пользователя

Есть способ не подпустить подгрузки политик, но для этого трика нам понадобятся логин и пароль другого пользователя. Суть в том, что нам надо войти в систему «еще раз», но не под собой. Тут два варианта:

1. + правый клик на запускаемом файле, далее в контекстном меню выбираем «Run as…».
2. Через консоль набираем команду: runas /noprofile .

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

На нем пользователь test_gpo3 не может запустить regedit из-за политик. Но, запустив под test_gpo2 любой exe’шник (диспетчер задач например), он уже ничем не ограничен и поэтому может запустить regedit. Кроме того, если у нас есть возможность удаленного входа в систему (по RDP, например), то мы можем провести аналогичный финт, но только с одной учеткой (демонстрацию можешь посмотреть в этом видео).

Трюк 8. Вспоминаем про HTA

Последний хинт касается неофициальных исключений, на которые не действуют групповые политики. Вадимc Поданс написал в блоге отличную серию постов, посвещенных SRP-политикам. В частности, он обнаружил отличный путь для их обхода и запуска произвольного кода с использованием приложения HTA (HTML Application).

Итак, последовательность действий:

1. Создаем файлик с примерно таким текстом:
   msgbox «I’m dangerous VB Code. «
2. Сохраняем его с расширением .hta (например, execute_this.hta).
3. Создаем ярлык для него.
4. Открываем ссылку — и hta запускается.

Надо ли говорить, что вместо вызова безобидного MessageBox’а VB-код может сделать в системе что угодно? Политики SRP должны проверять весь код, который может исполняться, в том числе и всевозможные скрипты. Однако из-за тонкостей работы групповых политик данный обход работает. К аналогичным «глюковатым» расширениям помимо HTA Вадимс относит REG, MSC, HTA, CHM.

Точно так же ситуация наблюдается и с com-файлами (в том числе всякими олдскульными ДОС’овскими программами, которые все еще разбросаны в папке винды). Они не учитывают правила групповых политик, так как работают в виртуальной машине DOS.

Групповые политики в тонких клиентах

Хочется еще рассказать про такие системы, как Citrix XenApp. Что это такое? XenApp, если говорить простым языком, это система «доставки» приложений (хотя это только часть функционала). По сути, это что-то типа терминального сервера винды, но когда пользователю доступно только конкретное приложение. В жизни это выглядит так.

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

Так как процесс — на сервере, то, значит, пользователю доступны все ресурсы сервера (с учетом пользовательских прав, конечно). Это не очень хорошо, так как предполагается, что у пользователя должен быть доступ только к запущенной программе, а не к ОС. Что еще хуже, добраться-то до самой ОС — не проблема. Даже если у самого ПО нет возможности по взаимодействию с ОС (нет меню «Открыть», «Сохранить как»), то стандартные возможности винды все еще работают: нажимаем в Citrix-приложении — нам открывается диспетчер задач Citrix-сервера, или правый клик по раскладке клавиатуры, а оттуда в файл справки с возможностью листинга директорий. Лично я столкнулся с групповыми политиками именно в этом контексте — при взломе Citrix.

Наш итог

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

Источник: xakep.ru