Зачем нужно подписывать скрипты?
Первой и самой главной ошибкой тех кто начинает работать с PowerShell является запуск представленной ниже команды на всех хостах.
Set-ExecutionPolicy Unrestricted
Вроде как удобно, но поверьте последствия могут быть самые разнообразные…
Результатом выставления уровня запуска в режим Unrestricted будет ослабление надежной политики безопасности «по умолчанию» и как возможные последствия – потеря контроля и возможная компроментация учетных записей. Насколько хватит фантазии 
Примечание: Напомню, что по умолчанию высталена безопасная политика Restricted (ничего и никому), об этом я недавно писал, надеюсь что вы это читали, а если не читали то обязательно зайдете.
Перед тем как поступить опрометчиво подумайте стоит ли оно этого…
- Запускаете ли вы скрипты на рабочих станциях? Для каких целей?
- Запускаете ли вы их в контексте пользователей имеющих административные привилегии?
- Если запускаете то подписаны ли они?
Предлагаю рассмотреть следующий сценарий.
- На всех рабочих станциях Execution Policy выставлено в Unrestricted (встречаю довольно часто).
- В контексте пользователя запускается логон-скрипт ан powershell по подключению принтеров и общих папок, копированию некого набора файлов и пр.
Какие минусы?
На первый взгляд все замечательно, все работает, никто не жалуется. Вроде все хорошо т.к. запускаемые скрипты находятся в контролируемой общей папке. Ничего не предвещает проблем, но всегда есть вероятность что они появятся именно в тот момент когда их ожидаешь меньше всего.
Откройте консоль powershell и введите.
Вы получите путь до powershell-профиля пользователя. Редактируем этот файл командой.
Открывается файл powershell-профиля для текущего пользователя. Вводим строку «Write-Host HELLO!«, сохраняем, закрываем. Закрываем консоль powershell, открываем новую. В окне видим надпись HELLO!
Что это может дать?
Первое что приходит в голову – возможность запускать нужные команды в контексте безопасности пользователя профиль которого надо подменить. Например скопировать файлы с жесткого диска пользователя на нужный ресурс (нет у вас доступа и полномочий а инфу стырить хочется…) или загрузить файл и выполнить его.
Примечание: В случае запуска логон-скрипта то что внесено в Powershell-профиль выполнится автоматически.
Подобное возможно в случае если «Мои документы» хранятся в папке права на которую выставлены некорректно или удалось подпихнуть заранее созданный файл профиля пользователю под которым планируется зловредная акция
Вариантов множество… Включите фантазию.
Второй вариант подмены профиля может быть реализован в случае если на хосте предоставлены административные полномочия сторонним лицам (внедренцы, аутсорсеры и пр. практика показывает что это бывает довольно часто). В этом варианте конечно существует масса других способов повышения привилегий, но мы пока рассматриваем только подмену powershell-профиля.
Как бороться.
Прежде всего нужно определиться где и для чего вы будете использовать PowerShell-скрипты.
Мое мнение – PowerShell создан для административных задач и запускать его нужно только на доверенных компьютерах. Все остальные задачи можно решать средствами GPO.
После понимания области применения необходимо настроить политики запуска только для подписанных скриптов т.к. при попытке подмены файла, скрипт заданный в профиле не будет выполняться.
Итог
Вы подписываете скрипты?
Настроены ли ваши политики на использование только подписанных скриптов?
Что вы думаете по поводу вышесказанного?
Похожие статьи
Вы можете оставить комментарий.
ExecutionPolicy,по мне,так – это защита от себя не более того.
1) powershell -noexit -ExecutionPolicy bypass
PS > Get-ExecutionPolicy
Bypass
2)
PS > Get-ExecutionPolicy
Restricted
PS > ‘»Hello»‘ > F:\1.ps1
PS > F:\1.ps1
File F:\1.ps1 cannot be loaded because the execution of scripts is disabled on this system. Please see «get-help about_
signing» for more details.
At line:1 char:9
+ F:\1.ps1 <<< Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process
Execution Policy Change
The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose
you to the security risks described in the about_Execution_Policies help topic. Do you want to change the execution
policy?
[Y] Yes [N] No [S] Suspend [?] Help (default is «Y»):
PS > Get-ExecutionPolicy
Bypass
PS > F:\1.ps1
Hello
3) Copy&Paste,политика не важна.
KazunЦитировать
В случае если ты имеешь привеленгии то да.
Если нет то изменить уровень выполнения никак.
Основная идея – не включать ничего кроме нужного а если уж включил то использовать только подписанные скрипты.
Сергей МариничевЦитировать
На что привилегии? Действия выше,были от обычного
KazunЦитировать
т.е. у вас обычный пользователь может писать в ветку ‘HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell’ ?
Там храниться значение политики. В случае попатки его замены под бесправным пользователем ругается
AuthorizationManager Check Failed.
Это Win7…
ХР-юши под рукой нет, но думаю что результат будет мало отличаться.
Сергей МариничевЦитировать
Я показал,два варианта,где не надо никуда ничего писать.
1) powershell -noexit -ExecutionPolicy bypass
2) Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process
KazunЦитировать
Хм.
В пределах текущей сессии ДА это видно при вызове Get-ExecutionPolicy -List, но в разрезе задачи т.е. при подмене профиля этого не реализовать.
PS за Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process спасибо. Я про скоп процесса и не подумал
Сергей МариничевЦитировать
Скажем,для этого,метода – это будет сложно.Но если самоцель,защитить профайл,это будет,как один из рубежей защиты.Причем,очень не значительный.Есть методы обхода,но все будет зависеть от квалификации администратора и атакующего.Для Xp ситуация осложнится(контроль с сертификатами),но не будем усложнять.Я рад,что появляется больше материала по PowerShell на русском языке.Желаю Вам,развития ресурса и чтоб больше народу приобщалось к PowerShell,за счет посещения вашего ресурса и передачи русскому сообществу информаци.
KazunЦитировать
Спасибо.
По сути своей, ДА, все зависит от квалификации (неломаемых систем нет), но описанная методика не исключена.
Кстати какие могут быть проблемы у XP. Про самоподписанный сертификат понятно, а при сертификате выданном доменным CA?
Сергей МариничевЦитировать