Кажется не так давно это было, примерно в 2015 году, мы начали слышать о хакерах, не использовавших вредоносных программ внутри периметра атакуемой цели. А использовали они то, что было под рукой – это были различные инструменты, находившиеся на целевом сайте. Это оказалось идеальным способом, чтобы сделать свое «грязное дело» не поднимая лишнего «шума».
Этот подход в наше время набрал обороты и стал мейнстримом, в первую очередь из-за обилия готовых инструментариев хакеров, таких как PowerShell Empire.
Мы уже писали о том, как PowerShell, когда он дополняется PowerView, становится мощным поставщиком информации для хакеров (вся эта мудрость собрана в нашей подборке, которую вы должны прочитать как можно скорее).
Безусловно, любой инструмент может использоваться как для хорошего так и для плохого, так что я и не думаю тут намекать, что PowerShell был создан, чтобы облегчить жизнь хакерам.
Но так же, как вы бы не оставили сверхмощный болторез рядом с навесным замком, вы, вероятно, не захотите разрешить, или хотя бы сделать это максимально более трудным для хакеров получить в свои руки PowerShell.
Это в свою очередь поднимает большую тему в мире кибербезопасности: ограничение доступа к приложениям, также известную как белые и черные списки доступа. Общая идея в том, чтобы операционная система знала и строго контролировала какие приложения могут быть запущены пользователем, а какие – нет.
Например, будучи homo blogus, мне, как правило, нужны некоторые основные инструменты и приложения (а также теплое местечко, где могу спать ночью), и я прекрасно могу прожить без оболочки PowerShell, netcat, psexec, и всех других команд, о которых я рассказывал в предыдущих постах. То же самое относится к большинству работников в компаниях, и поэтому квалифицированный ИТ-специалист должен быть в состоянии составить список приложений, которые являются безопасными для использования.
В мире Windows, возможно использовать правила на выполнение приложений с помощью специальных ограничивающих политик использования программ, а в последнее время и AppLocker.
Однако, прежде чем мы перейдем к этим передовым идеям, давайте попробуем два очень простых решения, а затем посмотрим, что с ними не так.
Мы часто думаем о списках доступа ACL Windows, что они используются для управления доступом к читабельному содержимому. Но они также могут быть применены и к исполняемым файлам — то есть.ехе, .vbs, .ps1 и остальным.
Я вернулся в облако Amazon Web Services, где у меня находится домен Windows для мифической и некогда легендарной компании Acme и там проделал работу с ACL, дабы продемонстрировать некоторые ограничения доступа.
PowerShell .exe, любой системный администратор сможет без труда сказать вам, находится в C:\Windows\System32\WindowsPowerShell\v1.0. Я перешел в эту папку, вызвал ее свойства и моментально ограничил права выполнения PowerShell на 2 основные группы: «Администраторов домена» и «Acme-SnowFlakes”, группы опытных пользователей Acme.
Я перезашел на сервер, как Боб, мой амплуа в компании Acme, и попытался вызвать PowerShell. Результаты ниже.
На практике, вы могли бы, наверняка, придумать скрипт — почему бы не использовать PowerShell чтобы автоматизировать этот процесс настройки ACL для всех ноутбуков и серверов в небольших и средних по размеру компаниях.
Это не плохое решение.
Если вам не нравится идея изменения ACL на исполняемых файлах, PowerShell предлагает свои собственные средства ограничения. Как пользователь с админ-правами, можно использовать, все что угодно, но проще всего встроенный командлет Set-ExecutionPolicy.
Это уже не настолько «топорное» решение, как установка ACL. Например, вы сможете ограничить PowerShell для работы только в интерактивном режиме – с помощью параметра Restricted — так что он не будет выполнять PS-скрипты, которые могут содержать вредоносные программы хакеров.
Однако, это также заблокирует и скрипты PowerShell, запускаемые вашими ИТ-специалистами. Чтобы разрешить одобренные скрипты, но отключить скрипты злобных хакеров, используйте параметр RemoteSigned. Теперь PowerShell будет запускать только подписанные скрипты. Администраторам, конечно, придется создать их собственные сценарии и затем подписать их с использованием проверенных учетных данных.
Я не буду вдаваться в подробности, как это сделать, в основном потому, что это так легко обойти. Кое-кто тут в блоге описал аж 15 способов обхода ограничений безопасности в PowerShell.
Самый простой – это с помощью параметра Bypass в самом PowerShell. Да! (см.ниже).
Похоже на дыру в безопасности, а?
Так что в PowerShell есть несколько основных уязвимостей. Это кстати и понятно, так как это, в конце концов, всего лишь программная оболочка.
Но даже подход ограничений на уровне ACL имеет свои фундаментальные проблемы.
Если хакеры ослабят свою философию, то они смогут запросто скачать, скажем, с помощью трояна удаленного доступа (RAT) — их собственную копию PowerShell.ехе. А затем запустить его напрямую, с легкостью избежав ограничений с разрешениями с локальным PowerShell.
Эти основные дыры в безопасности (как и многие другие) всегда сопровождают потребительский класс операционных систем. Это навело исследователей ОС на мысль придумать безопасную операционную систему, которая бы имела достаточно силы, чтобы контролировать то, что может быть запущено.
В мире Windows, эти силы известны как политики ограничения использования программ (SRP) — для ознакомления, посмотрите это — они настраиваются через редактор Групповых политик.
С их помощью вы сможете контролировать, какие приложения могут быть запущены на основании расширения файла, имен путей, и было ли приложение подписано цифровой подписью.
Самый эффективный, хоть и самый болезненный подход, это запретить все, а потом добавлять туда приложения, которые вам действительно нужны. Это известно как внесение в „белый список“.
Мы разберем это более подробно в следующей части.
В любом случае, вам потребуется запустить редактор политик, gpEdit и перейдите к политике Local Computer Policy>Windows Settings>Security Settings>Software Restriction Polices>Security Levels. Если Вы нажмете на “Запретить (Disallowed)”, то вы можете сделать это политикой безопасности по-умолчанию — не запускать любые исполняемые файлы!
Белый список: запретить по-умолчанию, а затем добавить разрешенные приложения в “Дополнительные правила (Additional Rules)”.
Это больше похоже на тактику выжженной земли. На практике, потребуется ввести “дополнительные правила”, чтобы добавить обратно разрешенные приложения (с указанием их наименования и пути). Если вы выходите из оболочки PowerShell, то вы фактически отключаете этот инструмент на месте.
К сожалению, вы не можете подстроить правила политик ограничения использования программ на основании отдельных групп или пользователей. Блин!
И теперь это логично приводит нас к последнему достижению безопасности Microsoft, известному как AppLocker, который имеет свои уникальные особенности, чтобы разрешить открыть приложение. Поговорим об этом в следующий раз.
Этот подход в наше время набрал обороты и стал мейнстримом, в первую очередь из-за обилия готовых инструментариев хакеров, таких как PowerShell Empire.
Мы уже писали о том, как PowerShell, когда он дополняется PowerView, становится мощным поставщиком информации для хакеров (вся эта мудрость собрана в нашей подборке, которую вы должны прочитать как можно скорее).
Безусловно, любой инструмент может использоваться как для хорошего так и для плохого, так что я и не думаю тут намекать, что PowerShell был создан, чтобы облегчить жизнь хакерам.
Но так же, как вы бы не оставили сверхмощный болторез рядом с навесным замком, вы, вероятно, не захотите разрешить, или хотя бы сделать это максимально более трудным для хакеров получить в свои руки PowerShell.
Это в свою очередь поднимает большую тему в мире кибербезопасности: ограничение доступа к приложениям, также известную как белые и черные списки доступа. Общая идея в том, чтобы операционная система знала и строго контролировала какие приложения могут быть запущены пользователем, а какие – нет.
Например, будучи homo blogus, мне, как правило, нужны некоторые основные инструменты и приложения (а также теплое местечко, где могу спать ночью), и я прекрасно могу прожить без оболочки PowerShell, netcat, psexec, и всех других команд, о которых я рассказывал в предыдущих постах. То же самое относится к большинству работников в компаниях, и поэтому квалифицированный ИТ-специалист должен быть в состоянии составить список приложений, которые являются безопасными для использования.
В мире Windows, возможно использовать правила на выполнение приложений с помощью специальных ограничивающих политик использования программ, а в последнее время и AppLocker.
Однако, прежде чем мы перейдем к этим передовым идеям, давайте попробуем два очень простых решения, а затем посмотрим, что с ними не так.
ACL и другие упрощения
Мы часто думаем о списках доступа ACL Windows, что они используются для управления доступом к читабельному содержимому. Но они также могут быть применены и к исполняемым файлам — то есть.ехе, .vbs, .ps1 и остальным.
Я вернулся в облако Amazon Web Services, где у меня находится домен Windows для мифической и некогда легендарной компании Acme и там проделал работу с ACL, дабы продемонстрировать некоторые ограничения доступа.
PowerShell .exe, любой системный администратор сможет без труда сказать вам, находится в C:\Windows\System32\WindowsPowerShell\v1.0. Я перешел в эту папку, вызвал ее свойства и моментально ограничил права выполнения PowerShell на 2 основные группы: «Администраторов домена» и «Acme-SnowFlakes”, группы опытных пользователей Acme.
Я перезашел на сервер, как Боб, мой амплуа в компании Acme, и попытался вызвать PowerShell. Результаты ниже.
На практике, вы могли бы, наверняка, придумать скрипт — почему бы не использовать PowerShell чтобы автоматизировать этот процесс настройки ACL для всех ноутбуков и серверов в небольших и средних по размеру компаниях.
Это не плохое решение.
Если вам не нравится идея изменения ACL на исполняемых файлах, PowerShell предлагает свои собственные средства ограничения. Как пользователь с админ-правами, можно использовать, все что угодно, но проще всего встроенный командлет Set-ExecutionPolicy.
Это уже не настолько «топорное» решение, как установка ACL. Например, вы сможете ограничить PowerShell для работы только в интерактивном режиме – с помощью параметра Restricted — так что он не будет выполнять PS-скрипты, которые могут содержать вредоносные программы хакеров.
Однако, это также заблокирует и скрипты PowerShell, запускаемые вашими ИТ-специалистами. Чтобы разрешить одобренные скрипты, но отключить скрипты злобных хакеров, используйте параметр RemoteSigned. Теперь PowerShell будет запускать только подписанные скрипты. Администраторам, конечно, придется создать их собственные сценарии и затем подписать их с использованием проверенных учетных данных.
Я не буду вдаваться в подробности, как это сделать, в основном потому, что это так легко обойти. Кое-кто тут в блоге описал аж 15 способов обхода ограничений безопасности в PowerShell.
Самый простой – это с помощью параметра Bypass в самом PowerShell. Да! (см.ниже).
Похоже на дыру в безопасности, а?
Так что в PowerShell есть несколько основных уязвимостей. Это кстати и понятно, так как это, в конце концов, всего лишь программная оболочка.
Но даже подход ограничений на уровне ACL имеет свои фундаментальные проблемы.
Если хакеры ослабят свою философию, то они смогут запросто скачать, скажем, с помощью трояна удаленного доступа (RAT) — их собственную копию PowerShell.ехе. А затем запустить его напрямую, с легкостью избежав ограничений с разрешениями с локальным PowerShell.
Политики Ограничения Использования Программ
Эти основные дыры в безопасности (как и многие другие) всегда сопровождают потребительский класс операционных систем. Это навело исследователей ОС на мысль придумать безопасную операционную систему, которая бы имела достаточно силы, чтобы контролировать то, что может быть запущено.
В мире Windows, эти силы известны как политики ограничения использования программ (SRP) — для ознакомления, посмотрите это — они настраиваются через редактор Групповых политик.
С их помощью вы сможете контролировать, какие приложения могут быть запущены на основании расширения файла, имен путей, и было ли приложение подписано цифровой подписью.
Самый эффективный, хоть и самый болезненный подход, это запретить все, а потом добавлять туда приложения, которые вам действительно нужны. Это известно как внесение в „белый список“.
Мы разберем это более подробно в следующей части.
В любом случае, вам потребуется запустить редактор политик, gpEdit и перейдите к политике Local Computer Policy>Windows Settings>Security Settings>Software Restriction Polices>Security Levels. Если Вы нажмете на “Запретить (Disallowed)”, то вы можете сделать это политикой безопасности по-умолчанию — не запускать любые исполняемые файлы!
Белый список: запретить по-умолчанию, а затем добавить разрешенные приложения в “Дополнительные правила (Additional Rules)”.
Это больше похоже на тактику выжженной земли. На практике, потребуется ввести “дополнительные правила”, чтобы добавить обратно разрешенные приложения (с указанием их наименования и пути). Если вы выходите из оболочки PowerShell, то вы фактически отключаете этот инструмент на месте.
К сожалению, вы не можете подстроить правила политик ограничения использования программ на основании отдельных групп или пользователей. Блин!
И теперь это логично приводит нас к последнему достижению безопасности Microsoft, известному как AppLocker, который имеет свои уникальные особенности, чтобы разрешить открыть приложение. Поговорим об этом в следующий раз.
