Windows PowerShellПерехват вредоносных программных кодов
Дон Джонс
Помнит ли кто-нибудь времена бета-тестирования Windows Vista и слухов о самых первых версиях новой оболочки командной строки под кодовым названием «Monad»? (Последняя, само собой, теперь известна нам как Windows PowerShell.) В то время многие из крупнейших СМИ сообщали о «первом вирусе для Windows Vista». На
самом деле «вирус» был всего лишь опытно-экспериментальным вредоносным сценарием, атаковавшим «Monad». Для выполнения сценария «Monad» надо было специально настроить – он не работал при параметрах по умолчанию. Более того, к моменту появления этих сообщений корпорация Майкрософт уже объявила о том, что «Monad» не будет поставляться как часть Windows Vista®. В общем, весь этот шум возник из ничего (или, по крайней мере, из сущей мелочи).
Но по мере того, как Windows PowerShellTM становится более популярной (она уже была загружена более миллиона раз), возрастает вероятность ее использования для создания вредоносных сценариев. Возможность использования Windows PowerShell для написания потенциально вредоносного сценария – очевидный факт; любое средство администратора, хоть Windows PowerShell, хоть cmd.exe и VBScript, может быть использовано во вред. Поэтому нельзя автоматически считать, что файлы PS1 безвредны.
К счастью, параметры Windows PowerShell по умолчанию запрещают запуск сценариев, так что вредоносному сценарию для запуска нужна помощь пользователя. В этом месяце я хотел бы предсказать, как он попытается ее получить. Это не критика Windows PowerShell – я думаю, что в Майкрософт успешно справились с созданием оболочки сценариев, избегающей многих факторов риска. Тем не менее, я полагаю, что мой рассказ может помочь читателям быть готовыми к отражению возможных атак.
Безопасная по умолчанию
Стоит отметить, что Windows PowerShell – первый язык, разработанный корпорацией Майкрософт после появления известной инициативы по доверенным вычислениям. Эксперт по безопасности Майкл Говард (Michael Howard) (автор книги Writing Secure Code («Написание безопасного кода»)) работал вместе с группой Windows PowerShell. Он помог обеспечить наивысшую возможную безопасность кода, и, что наиболее важно, установку параметров оболочки по умолчанию на наивысший возможный уровень безопасности.
Для начала стоит кратко напомнить о первоначальных параметрах безопасностиWindows PowerShell. По умолчанию, оболочка не запускает файлы с расширением PS1 двойным щелчком. Это расширение связано с Блокнотом. На практике по умолчанию оболочка вообще не запускает сценарии благодаря встроенной возможности, именуемой политикой выполнения, которая описывает условия, при которых сценарий будет работать. «Заводские» параметры предусматривают установку политики ограниченного выполнения (Restricted), при которой выполнение сценариев запрещено, а оболочку можно использовать лишь интерактивно. Политику выполнения можно изменить, используя командлет Set-ExecutionPolicy или административный шаблон групповой политики (файл ADM) от Майкрософт. (Файл ADM можно загрузить по адресу go.microsoft.com/fwlink/?LinkId=102940.) На рис. 1 показаны возможные политики выполнения.
Рис. 1** Выбор безопасной политики выполнения **(Щелкните изображение, чтобы увеличить его)
Из политики выполнения есть лишь считанные исключения. Если конкретнее, даже если установлена политика Restricted, оболочке позволено импортировать несколько конкретных файлов настройки в формате XML, предоставляемых Майкрософт и устанавливаемых вместе с оболочкой. Эти файлы используются для предоставления специальных функций, таких как расширения для типов Microsoft® .NET Framework и макетов форматирования по умолчанию для большинства типов объектов .NET. Очевидно, что оболочке стоит загружать эти файлы при запуске.
Хотя эти файлы и содержат исполняемый код, они снабжены цифровой подписью Майкрософт. Любые манипуляции с ними делают подпись бесполезной, и в таком случае оболочка не будет импортировать файлы при загрузке. Такая схема делает попытки внедрить в файлы вредоносный программный код не лучшей из идей.
Само собой, при политике выполнения Restricted сценарии профиля Windows PowerShell также не будут выполняться при запуске. Windows PowerShell не создает сценарий профиля по умолчанию, а ищет файлы с определенными именами в четырех определенных местах и, если они найдены, пытается выполнить их при каждом запуске. (Документация, устанавливаемая вместе с Windows PowerShell, предоставляет сведения о именах папок и файлов, используемых для сценариев профиля.) Профиль является основой уязвимости, о которой я собираюсь рассказать.
Изменение политики выполнения
Командлет месяца
К Set-AuthenticodeSignature прилагается Get-AuthenticodeSignature. Данный командлет разработан для изучения сценариев с цифровой подписью и предоставления сведений о подписи. Достаточно нацелить его на нужный файл, и можно будет увидеть, подписан ли файл, с помощью какого сертификата он подписан, цела ли подпись и так далее. Помимо работы со сценариями Windows PowerShell, данный командлет также работает с подписанными исполняемыми файлами:
PS C:\Program Files\Microsoft Office\Office12>
Get-AuthenticodeSignature excel.exe | Format-List *
Применив эту команду, я могу увидеть, был ли исполняемый файл подписан корпорацией Майкрософт с использованием сертификата центра сертификации Майкрософт.
Результаты применения команды (Щелкните изображение, чтобы увеличить его)
Следует особо отметить, что при параметрах по умолчанию Windows PowerShell очень сложно, если вообще возможно, заставить выполнить любой код вообще, а уж тем более вредоносный. Вредоносные сценарии становятся угрозой лишь в случае изменения политики выполнения. Стоит прояснить, что эта статья не является предупреждающим сигналом о дырах в безопасности Windows PowerShell; ее цель – поделиться рекомендациями по укреплению безопасности систем.
Низшей из возможных политик выполнения является политика неограниченного выполнения (Unrestricted), которая позволяет всем сценариям запускаться без ограничений и вопросов – практически та же нежелательная ситуация, что знакома много лет по работе VBScript и пакетных файлов. Установка политики Unrestricted – это приглашение к действию для вредоносных сценариев. Если политика была установлена на Unrestricted, а потом до системы добрался вредоносный сценарий, будьте готовы доказать необходимость такой политики и сознаться в собственном решении, когда будете объяснять, почему вирус стер всю среду!
Следует все же отметить, что Windows PowerShell по-прежнему будет пытаться обнаружить загрузку сценариев из Интернета и предупредить пользователя перед их запуском, даже если установлена политика Unrestricted. Но смысл в том, что установка политики Unrestricted – дурная идея.
Подписывание сценариев
Наиболее безопасная политика выполнения, которая допускает выполнение сценариев – это политика выполнения всех подписанных сценариев (AllSigned). При ее установке выполняются только сценарии с целой цифровой подписью, которая была создана с использованием доверенного сертификата (а не просто любой старой подписью). Для подписывания сценариев необходимо приобрести цифровой сертификат класса III – конкретнее, сертификат для подписывания кода Microsoft Authenticode. Такие сертификаты можно получить от внутренней инфраструктуры открытых ключей (PKI) по месту работы или приобрести в коммерческом центре сертификации вроде CyberTrust, Thawte и VeriSign.
Если необходимо узнать, установлены ли на компьютере какие-то сертификаты, которые можно использовать для подписывания сценариев, следующий командлет покажет это:
Get-ChildItem CERT: -recurse –codeSigningCert
После установки сертификата на компьютере Windows® используйте командлет Set-AuthenticodeSignature для создания и применения цифровой подписи, которая будет выглядеть как набор бессмысленных строк в конце сценария. Некоторые из редакторов сценариев могут предлагать возможность добавления подписи к сценарию, включая удобную возможность автоматически подписывать сценарии при сохранении.
Политика AllSigned является лучшей для рабочей среды. Хотя она и не предотвращает полностью выполнение вредоносных сценариев, она гарантирует, что вредоносный сценарий будет подписан, то есть возможность отследить его автора (предполагая, что система Windows настроена принимать сертификаты только от доверенных центров сертификации, но этот вопрос несколько выходит за рамки статьи). Что любопытно, в Windows Script Host (WSH) 5.6 и более поздние версии можно установить похожий параметр TrustPolicy («Политика доверия»), также требующий цифровых подписей, но мне редко встречались использующие его администраторы.
Кратко обобщаем вышесказанное. При установке политики Restricted невозможно применять как вредоносные, так и полезные сценарии. Если установлена политика выполнения AllSigned, оболочка допускает выполнение подписанных сценариев, что довольно безопасно, поскольку у большинства авторов вредоносных сценариев нет желания прикреплять к своим произведениям подтвержденное, отслеживаемое удостоверение. С другой стороны, политика Unrestricted крайне небезопасна, и при ее использовании можно считать, что поражение вредоносным сценарием – лишь вопрос времени. (Обратите внимание, что я не считаю ее особенной уязвимостью, поскольку она и не претендует на надежное обеспечение безопасности – предполагается, что пользователи, устанавливающие эту политику, должны знать, что делают.)
Прокрадываясь с черного хода
Есть еще одна политика выполнения, требующая подпись от удаленных сценариев (RemoteSigned). Именно ее, как я полагаю, используют сейчас большинство администраторов, просто потому, что она считается более безопасной, чем Unrestricted, и требующей меньше хлопот, чем AllSigned. RemoteSigned не требует подписи от локальных сценариев. Файлы PS1, находящиеся на локальных дисках, будут работать, не будучи подписанными. Удаленные сценарии – в первую очередь, загруженные из Интернета с помошью Internet Explorer® или Outlook® (эти приложения помечают загруженные файлы специальным флагом) – не будут запускаться, если они не подписаны.
Однако параметр RemoteSigned может дать ложное чувство безопасности. Начнем с того, что специальный флаг может запросто оказаться не добавлен к загруженному сценарию. Например, произведенные не корпорацией Майкрософт обозреватели обычно не устанавливают его, как и большинство произведенных сторонними изготовителями клиентов электронной почты. Важно отметить, что без этого флажкаWindows PowerShell считает загруженные сценарии локальными и не требует от них подписи. Тем не менее, я не считаю это существенной уязвимостью. Пользователю необходимо загрузить сценарий, открыть Windows PowerShell и вручную запустить его, чтобы он сработал. Обычно заставить выполнить все эти действия хитростью довольно сложно – администраторы, которые обычно являются единственными пользователями в сети с установленной Windows PowerShell, не должны быть настолько просты.
Однако RemoteSigned предлагает существенный «черный ход», через который может прокрасться вредоносное приложение. Помните сценарии профиля Windows PowerShell? Если они существуют – созданы ли они пользователем или вирусом – они будут исполняться при каждом запуске Windows PowerShell. А при политике выполнения RemoteSigned сценарии профиля (которые являются локальными) не нуждаются в подписи.
Возьмем пример ситуации:
- Некая вредоносная программа пробирается в систему и создает сценарий профиля оболочки либо включает вредоносный код в существующий. Вредоносные программы обычно работают под учетной записью находящегося в системе пользователя, как правило, имеющей полномочия на изменение сценария профиля.
- Пользователь открывает Windows PowerShell, не осознавая, что сценарий профиля был создан или изменен с целью включения вредоносного кода. Код выполняется, и наносится ущерб. Ущерб будет еще хуже в случае наличия у пользователя привычки открывать Windows PowerShell, используя учетные данные администратора, – такая практика обычна, поскольку для выполнения многих задач в оболочке нужны администраторские права.
Таким образом, профиль создает возможность выполнения произвольного и вредоносного кода без ведома пользователя, а политика выполнения RemoteSigned позволяет это.
Защита профиля
Есть лишь один надежный способ защитить профиль: использование политики выполнения AllSigned. Под AllSigned даже сценарии профиля должны иметь цифровую подпись, иначе Windows PowerShell не выполнит их при запуске. Кроме того, если сценарии профиля подписаны, внесение в них вредоносных изменений повредит их цифровые подписи, делая их выполнение невозможным – Windows PowerShell даже предупредит пользователя о проблемах при запуске. На самом деле, AllSigned – это единственная безопасная политика выполнения для рабочих сред, которым необходима возможность выполнять сценарии.
Есть еще один подход, но он более сложен и менее надежен. Можно создать незаполненные файлы сценария профиля взамен каждого из четырех файлов, которые ищет Windows PowerShell. Используйте новую учетную запись пользователя (я назову ее «редактор профилей») для создания этих файлов и установки параметров NTFS, позволяющих только учетной записи редактора профилей изменять их. Другие учетные записи могут иметь лишь право доступа на чтение.
После этого никогда не входите в систему, используя учетную запись редактора профилей, кроме как ради изменения профиля. Такой подход не позволит обычной учетной записи (или записям) пользователя изменять сценарии профиля. Кроме того, любое вредоносное программное обеспечение, запускающееся при входе в систему с нормальной учетной записью, не сможет их изменить. Что будет, если вредоносное ПО запустится в тот момент, когда вход в систему произведен с записью редактора профилей? Учитывая то, что пользователь в этот момент в любом случае будет заниматься правкой сценариев профилей, он должен заметить изменения.
Можно также развернуть собственную сеть безопасности посредством создания сценария профиля для всех пользователей, контролируемого аккуратно выдаваемыми разрешениями для файлов, как я только что описал. Внутри этого сценария напишите код, использующий командлет Get-AuthenticodeSignature для изучения цифровых подписей на прочих профилях, которые ищет оболочка. Это, по сути, позволяет требовать подписи от сценариев профиля, но не от других сценариев.
Однако политика исполнения AllSigned – куда более основательный способ защиты профиля. Я рекомендую устанавливать на каждом компьютере, подключенном к сети, политику выполненияRestricted, предпочтительно применяемую групповой политикой. Это отменяет любые локальные параметры и гарантирует автоматическую установку новых компьютеров домена на запрет выполнения сценариев. Компьютеры, на которых следует допустить выполнение некоторых сценариев, должны иметь альтернативную групповую политику, устанавливающую политику выполнения AllSigned. На каждый сценарий необходимо ставить цифровую подпись, но при этом можно спать спокойно, зная, что в среде исполняются только доверенные сценарии от известных авторов.
Дон Джонс — ведущий специалист по написанию сценариев компании SAPIEN Technologies, соавтор книги «Windows PowerShell: TFM» (изд-во. SAPIEN Press, 2007 г.). С ним можно связаться по адресу www.ScriptingAnswers.com.
© 2008 Корпорация Майкрософт и компания CMP Media, LLC. Все права защищены; полное или частичное воспроизведение без разрешения запрещено.