• Главная
• Контакты
• Нашёл ошибку
• Прислать материал
• Добавить в избранное

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

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

Во-вторых, простота распространения и выполнения сценариев открывает широкие возможности для написания вредоносных сценариев-вирусов, которые могут, например, рассылаться по электронной почте, как широко известный вирус "I Love You".

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

Начиная с версии 2.0, в WSH появилась возможность скрыть от пользователя исходный текст сценария, преобразовав (зашифровав) его с помощью программы Microsoft Script Encoder, которую можно свободно скачать по адресу http://msdn.microsoft.com/scripting/vbscript/download/x86/sce10en.exe.

Программа Script Encoder может применяться для шифрования сценариев JScript (файлы *.js), VBScript (файлы *.vbs) и WS-файлов (расширение wsf), а также сценариев, содержащихся в гипертекстовых файлах HTML.

Замечание 

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

Для запуска программы Script Encoder служит файл screnc.exe; по умолчанию установка исполняемого файла и файла помощи производится в каталог Program Files\Windows Script Encoder. Программа srcenc.exe запускается из командной строки, в качестве ее обязательных параметров указываются имена исходного файла сценария и файла, в котором будет содержаться этот сценарий в зашифрованном виде.

Замечание

В системе зарегистрированы специальные расширения для файлов с зашифрованными сценариями WSH: jse для сценариев JScript и vbe для сценариев VBScript

Рассмотрим пример. Пусть в файле ForEncode.js находится простой JScript-сценарий (листинг 4.1).

/*******************************************************************/

/* Имя: ForEncode.js                                               */

/* Язык: JScript                                                   */

/* Описание: Исходный текст сценария                               */

/*******************************************************************/

WScript.Echo("Привет!");

/*************  Конец *********************************************/

Тогда после выполнения команды

sсrenс ForEncode.js Encoded.jse

создастся файл Encoded.jse, содержащий зашифрованный текст сценария ForEncode.js (листинг 4.2).

#@~^0QEAAA==&CeMCeCeeCeCMeCeMeCeMMCeeCMeCeeCMMeCeCeMeMMCeMeCMeCeMMCeeMMCeMeCMCeMJ@#@&ze,Имя),oWM2UmKNn N/P,~P,PP,~~P,P,P~P~~,P~P,~P,P~~,PP~~,P~P,~,P~,P,ez@#@&JMPЯзык=PB?1Dr2DPP,~P,PP,~~P,P,P~P~~,P~P,~P,P~~,PP~~,P~P,~,P~,P,PP,eJ@#@&Je~Описание),ИсходныйPтекстсценария~,PP,~P,PP,~~P,P,P~P~~,P~P,~P,PM&@#@&zMMCeMeCMCeMCeCeeCeCMeCeMeCeMMCeeCMeCeeCMMeCeCeMeMMCeMeCMeCeMMCeeMMCz@#@&qj1DraYc2m4WvEПривет1"r#I@#@&zMMCeeCMeCeeCM~PКонец,eCeMeMMCeMeCMeCeMMCeeMMCeMeCMCeMCeCeeCeCMeCeMz@#@&KEIAAA==^#~@

Сценарии VBScript, записанные в файлах с расширением vbs, шифруются точно так же:

screnc ForEncode.vbs Encoded.vbe

Исходный сценарий ForEncode.vbs приведен в листинге 4.3, зашифрованный сценарий Encoded.vbe — в листинге 4.4. 

'*******************************************************************

' Имя: ForEncode.vbs                                             

' Язык: VBScript                                                  

' Описание: Исходный текст сценария                              

'*******************************************************************

WScript.Echo "Привет!"

'*************  Конец **********************************************

#@~^xQEAAA==vCeMCeCeeCeCMeCeMeCeMMCeeCMeCeeCMMeCeCeMeMMCeMeCMeCeMMCeeMMCeMeCMCeM@#@&EPИмя),sK.2 mGNR-8kPP,~P,PP,~~P,P,P~P~~,P~P,~P,P~~,PP~~,P~P,~,P~,@#@&BPЯзык=Pj$?1DrwDP~~,PP,~P,PP,~~P,P,P~P~~,P~P,~P,P~~,PP~~,P~P,~,P~,P@#@&B,Описание),Исходный~текстPсценария,P~P,P~~,PP,~P,PP,~~P,P,P~P~~,P@#@&EMeCeMMCeeMMCeMeCMCeMCeCeeCeCMeCeMeCeMMCeeCMeCeeCMMeCeCeMeMMCeMeCMeC@#@& UmDr2DR3m4G,JПриветZr@#@&BeCeCMeCeMeCeM~,КонецPeCMeCeeCMMeCeCeMeMMCeMeCMeCeMMCeeMMCeMeCMCeMCe@#@&PEAAAA==^#~@

Как видно из листингов 4.3 и 4.4, символы кириллицы остаются в зашифрованных сценариях без изменения.

Зашифрованные файлы Encoded.jse и Encoded.vbe можно запускать с помощью cscript.exe или wscript.exe, выполняться они будут точно так же, как и исходные сценарии (рис. 4.1).

Рис. 4.1. Результат выполнения зашифрованного сценария Encoded.jse

Еще одной весьма полезной особенностью сценариев, зашифрованных с помощью Script Encoder, является то, что при запуске такого сценария автоматически производится контроль целостности файла. Например, если в файле Encoded.jse убрать или добавить букву в слово "Привет", то при запуске будет выведено сообщение об ошибке (рис. 4.2) и сценарий выполняться не будет.

Рис. 4.2. Сообщение об ошибке, выводимое при запуске модифицированного файла Encoded.jse

Содержимое зашифрованных сценариев с расширениями jse и vbe можно вставлять в WS-файлы внутрь элементов

<script>

language

JScript.Encode

VBScript.Encode

<job id="Encoded">

<runtime>

<description>

Имя: Encoded.wsf

Описание: WS-файл с зашифрованными сценариями

</description>

</runtime>

<script language="VBScript.Encode">

#@~^FgAAAA== Um.bwDR21tK~JПриветeJ/gQAAA==^#~@

</script>

<script language="JScript.Encode">

#@~^FgAAAA== Um.bwDR21tKcJПокаeJbiagUAAA==^#~@

</script>

</job>

<job id="Encoded">

<runtime>

<description>

Имя: Encoded.wsf

Описание: WS-файл с зашифрованными сценариями

</description>

</runtime>

<script language="VBScript.Encode">

WScript.Echo "Привет!"

</script>

<script language="JScript.Encode">

WScript.Echo("Пока!");

</script>

</job>

Однако если попытаться зашифровать исходный файл ForEncode.wsf с помощью команды

screnc ForEncode.wsf Encoded.wsf

то возникнет ошибка, т.к. Script Encoder "не понимает" расширения wsf. Поэтому для шифрования WS-файлов нужно при вызове screnc.exe в командной строке использовать дополнительный ключ:

screnc /е htm ForEncode.wsf Encoded.wsf

Параметр

/е htm

<script>

Описание других ключей программы Script Encoder, которые могут применяться при шифровании сценариев WSH, приведено в табл. 4.1.

Таблица 4.1. Параметры командной строки screnc.exe

Сценарии WSH можно защищать с помощью цифровой подписи, используя которую, можно определить происхождение сценария и гарантировать его целостность, т.е. отсутствие в этом сценарии несанкционированных изменений. Если источник, из которого поступил этот сценарий, является надежным (trusted source), т.е. вы доверяете этому источнику, сценарий можно выполнить. В случае же ненадежности создателя или распространителя сценария можно (при соответствующей настройке политик безопасности Windows) отказаться от его запуска.

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

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

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

? проверка подлинности пользователей Интернета или Web-сервера (пользователи должны иметь возможность доказать свою подлинность тем, с кем они соединяются в компьютерной сети, и должны иметь возможность проверить подлинность других пользователей);

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

? подписание электронных писем (получатель сообщения может проверить, что сообщение не было изменено в процессе доставки и что сообщение пришло именно от отправителя);

? проверка подлинности программного обеспечения, которое загружается из Интернета, устанавливается из локальной сети организации или с компакт-диска (неподписанное программное обеспечение, т.е. не имеющее действительного сертификата издателя, может представлять опасность для компьютера и сохраняемой на нем информации).

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

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

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

В Интернете имеются сайты коммерческих центров сертификации, которые выдают сертификаты как организациям, так и частным лицам; одним из самых известных таких центров является VeriSign (http://www.verisign.com). Естественно, большинство услуг центров сертификации являются платными, причем цена на сертификат зависит от цели его приобретения (личный цифровой сертификат для индивидуального распространения программ стоит намного дешевле, чем сертификат для организаций, занимающихся разработкой и продажей программного обеспечения).

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

Наиболее быстрым способом создания собственного цифрового сертификата является использование программы SelfCert.exe, входящей в состав Microsoft Office 2000/ХР. Запустив эту утилиту, мы получим диалоговое окно, позволяющее задать имя создаваемого сертификата (рис. 4.3). В качестве этого имени можно использовать, например, свое имя или название организации. 

Рис. 4.3. Создание нового личного сертификата с помощью SelfCert.exe

Рис. 4.4. Успешное создание личного сертификата "Попов надежный"

Для дальнейших экспериментов нам понадобится создать два сертификата с именами "Попов надежный" и "Попов ненадежный". После нажатия кнопки OK в случае успешного создания сертификата на экран выводится диалоговое окно с информацией об этом (рис. 4.4).

Для того чтобы посмотреть свойства созданных сертификатов, нам потребуется запустить консоль управления Microsoft Management Console (ММС) — инструмент для создания, сохранения и открытия средств администрирования (называемых консолями (Snap-in) ММС), которые управляют оборудованием, программными и сетевыми компонентами операционной системы Windows. Для того чтобы загрузить ММС, нужно выполнить команду

mmc

Рис. 4.5. Новая консоль ММС

Теперь добавим в консоль оснастку Сертификаты (Certificates). Для этого нужно в меню Консоль (Console) выбрать пункт Добавить/удалить оснастку (Add/Remove Snap-in), после чего появится диалоговое окно, показанное на рис. 4.6.

Рис. 4.6. Диалоговое окно добавления/удаления оснасток для консоли ММС

После нажатия кнопки Добавить (Add) выводится список всех имеющихся оснасток (рис. 4.7).

Из этого списка нужно выбрать Сертификаты (Certificates) и нажать кнопку Добавить (Add). После этого в новом диалоговом окне отмечаем, что добавляемая оснастка будет управлять сертификатами для своей учетной записи (рис. 4.8) и нажимаем кнопку Готово (Finish).

Никаких других оснасток в окно консоли мы добавлять не будем, поэтому нажимаем кнопку Закрыть (Close) в списке оснасток и кнопку OK в окне добавления/удаления оснасток. Созданные нами сертификаты будут находиться в разделе Личные\Сертификаты (Personal\Sertificates) (рис. 4.9).

Выделив нужный сертификат в списке и нажав клавишу <Enter>, мы выведем окно с описанием свойств сертификата (рис. 4.10).

Рис. 4.7. Список всех оснасток

Рис. 4.8. Выбор типа сертификатов, которым будет управлять добавляемая оснастка Сертификаты

Рис. 4.9. Расположение личных сертификатов

Рис. 4.10. Свойства сертификата "Попов надежный"

Как мы видим, для обоих новых сертификатов не установлено доверие. Для того чтобы установить доверие к одному из сертификатов ("Попов надежный"), достаточно просто перетащить при помощи мыши этот сертификат в раздел Доверенные корневые центры сертификации | Сертификаты (Trusted Root Certification Authorities) (рис. 4.11).

Замечание

Если при перетаскивании сертификата в новое место держать нажатой клавишу <Ctrl>, то сертификат будет не перемещен, а скопирован.

Рис. 4.11. Сертификаты, к которым установлено доверие

Свойства сертификата "Попов надежный" после установки доверия к нему показаны на рис. 4.12.

Выполним теперь экспорт в файл сертификата "Попов ненадежный" (это понадобится нам в дальнейшем при построении политики ограниченного использования программ). Для этого следует выделить нужный сертификат и выбрать в меню Действие | Все задачи (Action | All Tasks) пункт Экспорт (Export), после чего запустится мастер экспорта сертификатов, в котором нужно согласиться со всеми настройками, предлагаемыми по умолчанию, а в качестве имени экспортируемого файла указать "C:\Script\Попов.cer".

Рис. 4.12. Новые свойства сертификата "Попов надежный" 

Подписать файл со сценарием WSH можно двумя способами. Во-первых, можно использовать программу SignCode.exe, с помощью которой производится подпись любого исполняемого кода. Однако эта программа не является стандартной частью операционной системы Windows, ее нужно устанавливать отдельно. Поэтому далее мы будем рассматривать второй способ подписи сценариев — с помощью метода

SignFile

Scripting.Signer

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

/file

/cert

SignFile

Scripting.Signer

//Создаем объект Scripting.Signer

Signer = WScript.CreateObject("Scripting.Signer");

File = WScript.Arguments.Named("file"); //Имя файла

Cert = WScript.Arguments.Named("cert"); //Название сертификата

Signer.SignFile(File, Cert); //Подписываем файл

Замечание

В методе

SignFile

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

<job>

 <runtime>

  <named name="file" helpstring="Путь к файлу сценария" required="true" type="string"/>

  <named name="cert" helpstring="Имя цифрового сертификата" required="true" type="string"/>

  <description>

  Имя: SignScript.wsf

  Описание: Добавление цифровой подписи к файлам

            со сценариями WSH

  </description>

  <example>

  Пример:

  SignScript.wsf  /file:Signed.wsf /cert:"Попов надежный"

  </example>

 </runtime>

 <script language="JScript">

  var Signer, File, Cert, Store;

  if (!(WScript.Arguments.Named.Exists("cert") && WScript.Arguments.Named.Exists("file"))) {

   WScript.Arguments.ShowUsage();

   WScript.Quit();

  }

  Signer = WScript.CreateObject("Scripting.Signer");

  File = WScript.Arguments.Named("file");

  Cert = WScript.Arguments.Named("cert");

  Store = "";

  Signer.SignFile(File, Cert);

 </script>

</job>

Цифровые подписи добавляются в конец файлов, содержащих сценарии, причем в обычных JScript- и VBScript-файлах подпись находится в блоке комментария, а в WS-файлах — внутри элемента

<signature>

<signature>

В листингах 4.8–4.10 приведены примеры сценариев различных типов, которые были подписаны с использованием сертификата "Попов надежный".

/*******************************************************************/

/* Имя: Signed.js                                                  */

/* Язык: JScript                                                   */

/* Описание: Сценарий с цифровой подписью                          */

/*******************************************************************/

WScript.Echo("Привет!");

// SIG // Begin signature block

// SIG // MIIEMAYJKoZIhvcNAQcCoIIEITCCBB0CAQExDjAMBggq

// SIG // hkiG9w0CBQUAMGYGCisGAQQBgjcCAQSgWDBWMDIGCisG

// SIG // AQQBgjcCAR4wJAIBAQQQEODJBs441BGiowAQS9NQkAIB

// SIG // AAIBAAIBAAIBAAIBADAgMAwGCCqGSIb3DQIFBQAEENmN

// SIG // vsHhmXojm79+NmBDE0qgggJIMIICRDCCAa2gAwIBAgIQ

// SIG // sGqcGTDiWZBINKde3DiDqDANBgkqhkiG9w0BAQQFADAn

// SIG // MSUwIwYDVQQDHhwEHwQ+BD8EPgQyACAEPQQwBDQENQQ2

// SIG // BD0ESwQ5MB4XDTAxMTIzMTIwMDAwMFoXDTA3MTIzMTIw

// SIG // MDAwMFowJzElMCMGA1UEAx4cBB8EPgQ/BD4EMgAgBD0E

// SIG // MAQ0BDUENgQ9BEsEOTCBnzANBgkqhkiG9w0BAQEFAAOB

// SIG // jQAwgYkCgYEAsNlPby/9ax7Ky75RO8xI+jrNU/u842T2

// SIG // 6Md730yxbVD9+54SVNtsCoYOR7OYgQMb9TtiirFpk0bJ

// SIG // PH7WuCjGlrMOhDt86Vq++er67d87p0rytm0R7m1/FOkw

// SIG // GxxjycUEKS2w65FXfdpngRKiu3NIDb6tsupKiHex3XEo

// SIG // 1n0O++kCAwEAAaNxMG8wEwYDVR0lBAwwCgYIKwYBBQUH

// SIG // AwMwWAYDVR0BBFEwT4AQ0LHfQjJYgcR4nBGbd2fwEKEp

// SIG // MCcxJTAjBgNVBAMeHAQfBD4EPwQ+BDIAIAQ9BDAENAQ1

// SIG // BDYEPQRLBDmCELBqnBkw4lmQSDSnXtw4g6gwDQYJKoZI

// SIG // hvcNAQEEBQADgYEAi0hytKDNpUwc8/MpidjPFaE3xu9g

// SIG // SSVXbietJ5kW7uJR1IXAA1CaEHDCe0JIxCdHhfKTcWrK

// SIG // Q4t0mG6fBFO180xKHcyOCpVuFywnkMI8AWKzqNYdaDUZ

// SIG // sNtaw4R4XjX9koovYmfFo4i75A9zd4qXB93AaWUJMEt7

// SIG // g+JQ2Blzn4gxggFSMIIBTgIBATA7MCcxJTAjBgNVBAMe

// SIG // HAQfBD4EPwQ+BDIAIAQ9BDAENAQ1BDYEPQRLBDkCELBq

// SIG // nBkw4lmQSDSnXtw4g6gwDAYIKoZIhvcNAgUFAKBsMBAG

// SIG // CisGAQQBgjcCAQwxAjAAMBkGCSqGSIb3DQEJAzEMBgor

// SIG // BgEEAYI3AgEEMBwGCisGAQQBgjcCAQsxDjAMBgorBgEE

// SIG // AYI3AgEVMB8GCSqGSIb3DQEJBDESBBB3QmVqnKzYLdaa

// SIG // EXTFBkJhMA0GCSqGSIb3DQEBAQUABIGAAMkO/8PM8+Ay

// SIG // zG8FeUtsDIUy56sSmYd9W34axmFbGktiseSshNxemfbv

// SIG // 7TucEbZ40zyMFdpaKDqwwCNf1M3k59eu4jk0wX1v1VBd

// SIG // +mwQ3JNg3WpvAL6OFrAko+ksiZ2ndjKJfJXwDUSITFmy

// SIG // aGrGNkC3RYRhp6dPdL8Tb0PVvcU=

// SIG // End signature block

'*******************************************************************

' Имя: Signed.vbs

' Язык: VBScript

' Описание: Сценарий с цифровой подписью

'*******************************************************************

WScript.Echo "Привет!"

'*************  Конец *********************************************

'' SIG '' Begin signature block

'' SIG '' MIIEMAYJKoZIhvcNAQcCoIIEITCCBB0CAQExDjAMBggq

'' SIG '' hkiG9w0CBQUAMGYGCisGAQQBgjcCAQSgWDBWMDIGCisG

'' SIG '' AQQBgjcCAR4wJAIBAQQQTvApFpkntU2P5azhDxfrqwIB

'' SIG '' AAIBAAIBAAIBAAIBADAgMAwGCCqGSIb3DQIFBQAEELv8

'' SIG '' ImJefHuyhVFY7TYWddigggJIMIICRDCCAa2gAwIBAgIQ

'' SIG '' 75BSQe/4a5lLJ/s5SPVp+zANBgkqhkiG9w0BAQQFADAn

'' SIG '' MSUwIwYDVQQDHhwEHwQ+BD8EPgQyACAEPQQwBDQENQQ2

'' SIG '' BD0ESwQ5MB4XDTAxMTIzMTIwMDAwMFoXDTA3MTIzMTIw

'' SIG '' MDAwMFowJzElMCMGA1UEAx4cBB8EPgQ/BD4EMgAgBD0E

'' SIG '' MAQ0BDUENgQ9BEsEOTCBnzANBgkqhkiG9w0BAQEFAAOB

'' SIG '' jQAwgYkCgYEAsNlPby/9ax7Ky75RO8xI+jrNU/u842T2

'' SIG '' 6Md730yxbVD9+54SVNtsCoYOR7OYgQMb9TtiirFpk0bJ

'' SIG '' PH7WuCjGlrMOhDt86Vq++er67d87p0rytm0R7m1/FOkw

'' SIG '' GxxjycUEKS2w65FXfdpngRKiu3NIDb6tsupKiHex3XEo

'' SIG '' 1n0O++kCAwEAAaNxMG8wEwYDVR0lBAwwCgYIKwYBBQUH

'' SIG '' AwMwWAYDVR0BBFEwT4AQ0LHfQjJYgcR4nBGbd2fwEKEp

'' SIG '' MCcxJTAjBgNVBAMeHAQfBD4EPwQ+BDIAIAQ9BDAENAQ1

'' SIG '' BDYEPQRLBDmCEO+QUkHv+GuZSyf7OUj1afswDQYJKoZI

'' SIG '' hvcNAQEEBQADgYEAe3+Qek5z1V/kzjxcYB4nrGs0jN+5

'' SIG '' uRTY5+PtPyjz85i2y3YbH08HitGUYhZA3ImslbzMOCGg

'' SIG '' vIJAfzvhlIve+kKG5pG9EDFUpJ/eyHEizAmxjSChgZlz

'' SIG '' 2V++7VF6hIevX4VcUKCcCoGXb88Tp/XwY1arFFYzSUZg

'' SIG '' MJl3tYcHVrMxggFSMIIBTgIBATA7MCcxJTAjBgNVBAMe

'' SIG '' HAQfBD4EPwQ+BDIAIAQ9BDAENAQ1BDYEPQRLBDkCEO+Q

'' SIG '' UkHv+GuZSyf7OUj1afswDAYIKoZIhvcNAgUFAKBsMBAG

'' SIG '' CisGAQQBgjcCAQwxAjAAMBkGCSqGSIb3DQEJAzEMBgor

'' SIG '' BgEEAYI3AgEEMBwGCisGAQQBgjcCAQsxDjAMBgorBgEE

'' SIG '' AYI3AgEVMB8GCSqGSIb3DQEJBDESBBDWCooVTqYEryt6

'' SIG '' BNyCqxsxMA0GCSqGSIb3DQEBAQUABIGASPcIufHgECN+

'' SIG '' r9VNOAo4NJnI610cZS73Unu29n27/LISI5zrHqC/AR2n

'' SIG '' ts04Ah3j79usRJEaNJySDdTB3T5CyEue0XBS1FOTj4nt

'' SIG '' kYZBWXVxM0+Z1oGZNCTFJFtqPnEGhI2WwpKMz00luw09

'' SIG '' qnpjkM9dxsgPlumnkf5dpleZtBU=

'' SIG '' End signature block

<job>

<runtime>

<description>

Имя: Signed.wsf

Описание: Сценарий с цифровой подписью

</description>

</runtime>

<script language="JScript">

WScript.Echo("Привет!");

</script>

<signature>

** SIG ** MIIEMAYJKoZIhvcNAQcCoIIEITCCBB0CAQExDjAMBggq

** SIG ** hkiG9w0CBQUAMGYGCisGAQQBgjcCAQSgWDBWMDIGCisG

** SIG ** AQQBgjcCAR4wJAIBAQQQcAVhGs441BGiowAQS9NQkAIB

** SIG ** AAIBAAIBAAIBAAIBADAgMAwGCCqGSIb3DQIFBQAEEANf

** SIG ** TmfjlqP6LHKR3b45MWagggJIMIICRDCCAa2gAwIBAgIQ

** SIG ** 75BSQe/4a5lLJ/s5SPVp+zANBgkqhkiG9w0BAQQFADAn

** SIG ** MSUwIwYDVQQDHhwEHwQ+BD8EPgQyACAEPQQwBDQENQQ2

** SIG ** BD0ESwQ5MB4XDTAxMTIzMTIwMDAwMFoXDTA3MTIzMTIw

** SIG ** MDAwMFowJzElMCMGA1UEAx4cBB8EPgQ/BD4EMgAgBD0E

** SIG ** MAQ0BDUENgQ9BEsEOTCBnzANBgkqhkiG9w0BAQEFAAOB

** SIG ** jQAwgYkCgYEAsNlPby/9ax7Ky75RO8xI+jrNU/u842T2

** SIG ** 6Md730yxbVD9+54SVNtsCoYOR7OYgQMb9TtiirFpk0bJ

** SIG ** PH7WuCjGlrMOhDt86Vq++er67d87p0rytm0R7m1/FOkw

** SIG ** GxxjycUEKS2w65FXfdpngRKiu3NIDb6tsupKiHex3XEo

** SIG ** 1n0O++kCAwEAAaNxMG8wEwYDVR0lBAwwCgYIKwYBBQUH

** SIG ** AwMwWAYDVR0BBFEwT4AQ0LHfQjJYgcR4nBGbd2fwEKEp

** SIG ** MCcxJTAjBgNVBAMeHAQfBD4EPwQ+BDIAIAQ9BDAENAQ1

** SIG ** BDYEPQRLBDmCEO+QUkHv+GuZSyf7OUj1afswDQYJKoZI

** SIG ** hvcNAQEEBQADgYEAe3+Qek5z1V/kzjxcYB4nrGs0jN+5

** SIG ** uRTY5+PtPyjz85i2y3YbH08HitGUYhZA3ImslbzMOCGg

** SIG ** vIJAfzvhlIve+kKG5pG9EDFUpJ/eyHEizAmxjSChgZlz

** SIG ** 2V++7VF6hIevX4VcUKCcCoGXb88Tp/XwY1arFFYzSUZg

** SIG ** MJl3tYcHVrMxggFSMIIBTgIBATA7MCcxJTAjBgNVBAMe

** SIG ** HAQfBD4EPwQ+BDIAIAQ9BDAENAQ1BDYEPQRLBDkCEO+Q

** SIG ** UkHv+GuZSyf7OUj1afswDAYIKoZIhvcNAgUFAKBsMBAG

** SIG ** CisGAQQBgjcCAQwxAjAAMBkGCSqGSIb3DQEJAzEMBgor

** SIG ** BgEEAYI3AgEEMBwGCisGAQQBgjcCAQsxDjAMBgorBgEE

** SIG ** AYI3AgEVMB8GCSqGSIb3DQEJBDESBBC8sjXscmpwRH4l

** SIG ** +m0CC76kMA0GCSqGSIb3DQEBAQUABIGAipV3It04p5Mz

** SIG ** h1Mg/dssx9PjnOTY2AWZjCYnlt8XSaGQTna1P780Krul

** SIG ** uIa3ZNbeqeSELrkZEaQdzhcw6lfUOJxVWOXKdLsss8sM

** SIG ** V9HjQ00ggKeDDtsSC+twoz7TMWqLsvEgHz7ARzL9V6lQ

** SIG ** juR0pw/g4E4cfiBQ7fvtnLh+s9o=

</signature>

</job>

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

Кроме этого, можно самостоятельно из сценария WSH проверить достоверность цифровой подписи, которой снабжен тот или иной файл, и выяснить, входит ли сертификат создателя подписи в число сертификатов, к которым установлено доверие. Для такой проверки служит метод VerifyFile объекта Scripting.Signer. Данный метод имеет два параметра (File и ShowUI), первый из которых задает имя проверяемого файла, а второй является логическим флагом, позволяющим выводить или не выводить на экран диалоговое окно с информацией о состоянии сертификата, при помощи которого была создана цифровая подпись для этого файла. Если цифровая подпись проверяемого сценария является корректной, содержимое файла после создания подписи не изменялось, а к сертификату создателя сценария установлено доверие, то метод VerifyFile возвращает значение true, в противном случае — false.

В качестве примера в листинге 4.11 приведен сценарий Check.js, который проверяет цифровую подпись файла Signed.js.

/*******************************************************************/

/* Имя: Check.js                                                   */

/* Язык: JScript                                                   */

/* Описание: Проверка цифровой подписи файла Signed.js             */

/*******************************************************************/

var Signer, File, ShowUI, FileOK; //Объявляем переменные

//Создаем объект Scripting.Signer

Signer = WScript.CreateObject("Scripting.Signer");

File = "Signed.js";  //Имя проверяемого файла

ShowUI = false;

//Проверяем подпись в файле

FileOK = Signer.VerifyFile(File, ShowUI);

if (FileOK) WScript.Echo("Сценарий "+File+" является надежным.");

else WScript.Echo("Сценарий "+File+" НЕ является надежным.");

/*************  Конец *********************************************/

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

Первый подход может использоваться в операционной системе Windows любой версии, начиная с Windows 95. Смысл здесь состоит в применении специальных параметров системного реестра, которые позволяют:

? запретить выполнение на компьютере сценариев, запускаемых локально или с другой машины;

? задать режим работы WSH, при котором перед запуском всех сценариев проверяется их цифровая подпись и в соответствии с этим принимается решение о возможности выполнения этих сценариев;

? вести в журнале событий аудит успехов и отказов для сценариев WSH.

Второй подход может использоваться только в Windows ХР. Здесь для сценариев WSH, как и для всех других исполняемых программ, может применяться специальная политика ограниченного использования программ (SRP, Software Restriction Policies), с помощью которой можно, например, запретить запуск сценария, имеющего определенное имя или цифровую подпись.

Режим выполнения сценариев WSH зависит от нескольких параметров системного реестра, которые могут быть записаны в двух разделах:

HKLM\Software\Microsoft\Windows Script Host\Settings

или

HKCU\Software\Microsoft\Windows Script Host\Settings

В разделе (А) хранятся установки WSH для всех пользователей, запускающих сценарии на данной машине, а в разделе (Б) — для текущего пользователя, зарегистрированного в системе. При этом строковый параметр

IgnoreUserSettings

IgnoreUserSettings

IgnoreUserSettings

Параметры реестра, определяющие политику безопасности при использовании сценариев WSH, описаны в табл. 4.2.

Таблица 4.2. Параметры реестра для WSH

Устанавливая определенным образом значения параметров системного реестра из табл. 4.2, можно настроить политику безопасности при использовании сценариев WSH для конкретного пользователя или рабочей станции (например, можно разрешить выполнение сценариев только администраторам домена). В сетях Windows NT или на автономной машине для этого используется редактор системной политики (Poledit.exe), а в сетях с установленной службой каталогов Active Directory применяется групповая политика (Group Policy), доступная с помощью оснастки Active Directory — пользователи и компьютеры (Active Directory — users and computers) консоли управления ММС. На автономном компьютере с операционной системой Windows ХР/2000 для настройки политики безопасности WSH можно также изменять локальную групповую политику, которая позволяет задать одинаковые параметры безопасности для всех пользователей данного компьютера.

В любом случае для более удобного и безопасного изменения значений параметров реестра следует применять административные шаблоны (administrative templates) — текстовые файлы с расширением adm, позволяющие создавать удобный пользовательский интерфейс для редактирования заданных параметров системного реестра в редакторе системной политики или при работе с оснасткой Групповая политика (Group Policy) в ММС (пример такого adm-файла, позволяющего блокировать выполнение сценариев WSH, приведен в листинге 4.12).

Замечание

Более подробную информацию о редакторе системной политики Poledit.exe, настройке групповой политики в Windows 2000/ХР и администраторских шаблонах можно найти в справочной системе Windows ХР и документации MSDN.

Как уже было указано в табл. 4.2, за блокировку локальных и удаленных сценариев WSH отвечают соответственно параметры реестра

Enabled

Remote

Enabled

Remote

В листинге 4.12 приведен административный шаблон wsh.adm, с помощью которого можно запрещать/разрешать выполнение локальных или удаленных сценариев. Как мы видим, в административном шаблоне описывается путь к разделу реестра (параметр

KEYNAME

VALUENAME

VALUEON

VALUEOFF

[STRINGS]

Рис. 4.13. Блокировка выполнения сценариев WSH

CLASS MACHINE

  CATEGORY "Локальные и удаленные сценарии WSH"

    POLICY !!LocalEnabledPolicy

      KEYNAME "Software\Microsoft\Windows Script Host\Settings"

        EXPLAIN !!LocalEnabledPolicyHelp

      VALUENAME Enabled

        VALUEON "1" VALUEOFF "0"

    END POLICY

    POLICY !!MachRemotePolicy

      KEYNAME "Software\Microsoft\Windows Script Host\Settings"

        EXPLAIN !!MachRemotePolicyHelp

      VALUENAME Remote

        VALUEON "1" VALUEOFF "0"

    END POLICY

    POLICY !!IgnoreUserSettingsPolicy

      KEYNAME "Software\Microsoft\Windows Script Host\Settings"

        EXPLAIN !!IgnoreUserHelp

      VALUENAME IgnoreUserSettings

        VALUEON "1" VALUEOFF "0"

    END POLICY

  END CATEGORY

CLASS USER

  CATEGORY "Локальные и удаленные сценарии WSH"

    POLICY !!LocalEnabledPolicy

      KEYNAME "Software\Microsoft\Windows Script Host\Settings"

        EXPLAIN !!LocalEnabledPolicyHelp

      VALUENAME Enabled

        VALUEON "1" VALUEOFF "0"

    END POLICY

    POLICY !!MachRemotePolicy

      KEYNAME "Software\Microsoft\Windows Script Host\Settings"

        EXPLAIN !!MachRemotePolicyHelp

      VALUENAME Remote

        VALUEON "1" VALUEOFF "0"

    END POLICY

  END CATEGORY

[STRINGS]

LocalEnabledPolicy="Разрешить локальный WSH"

LocalEnabledPolicyHelp="Если значение равно 1, то локальный WSH разрешен"

MachRemotePolicy="Разрешить удаленный WSH"

MachRemotePolicyHelp="Если значение равно 1, то удаленный WSH разрешен"

IgnoreUserSettingsPolicy="Игнорировать установки пользователя"

IgnoreUserHelp="Должен быть установлен для того, чтобы применять ко всем пользователям политику для машины"

Для применения политик безопасности, которые описаны в шаблоне wsh.adm, к различным пользователям и рабочим станциям, можно воспользоваться либо редактором системной политики Poledit.exe (в сетях Windows NT и на автономных машинах), либо оснасткой Групповая политика (Group Policy) в ММС (в сетях с установленной службой каталогов Active Directory и на автономных машинах).

Рассмотрим сначала вариант, связанный с использованием редактора системной политики Poledit.exe. После запуска этой программы надо добавить wsh.adm в список текущих шаблонов политик. Для этого нужно в меню Параметры (Options) выбрать пункт Шаблон политики (Policy Template) и воспользоваться кнопкой Добавить (Add) в диалоговом окне Параметры шаблона политики (Policy Template Options) (рис. 4.14).

Рис. 4.14. Добавление файла wsh.adm в список текущих шаблонов политик

После подключения шаблона wsh.adm можно создать новую политику (пункт Новая политика (New Policy) в меню Файл (File)) (рис. 4.15).

Рис. 4.15. Создание новой системной политики

В свойствах пользователя и компьютера появится новый раздел Локальные и удаленные сценарии WSH с соответствующими параметрами политики безопасности, которые описаны в wsh.adm (рис. 4.16).

Рис. 4.16. Параметры политики безопасности для WSH, взятые из шаблона wsh.adm

В Windows 2000/ХР, имея соответствующие администраторские права, можно подключить административный шаблон wsh.adm к оснастке Групповая политика (Group Policy) в ММС. Рассмотрим, каким образом это делается для автономного компьютера, не подключенного к сети.

Сначала загрузим ММС, выполнив команду mmc либо в командной строке, либо с помощью пункта Выполнись (Run) меню Пуск (Start). Затем выберем пункт Добавить или удалить оснастку (Add/Remove Snap-in) в меню Консоль (Console) и нажмем кнопку Добавить (Add). В появившемся списке всех имеющихся оснасток нужно выбрать пункт Групповая политика (Group Policy) и нажать кнопку Добавить (Add). После этого запустится мастер групповой политики, в котором нужно указать, что объектом групповой политики является локальный компьютер, и нажать кнопку Готово (Finish) (рис. 4.17).

Рис. 4.17. Мастер групповой политики

Никаких других оснасток в окно консоли мы добавлять не будем, поэтому нажимаем кнопку Закрыть (Close) в списке оснасток и кнопку OK в окне добавления/удаления оснасток. После этого мы можем в окне консоли изменять групповую политику для локального компьютера (рис. 4.18).

Для того чтобы добавить в оснастку нужный нам административный шаблон, следует выделить раздел Конфигурация компьютера | Административные шаблоны (Computer Configuration | Administrative Templates) и в меню Действие (Action) выбрать пункт Добавление/удаление шаблонов (Add/Remove Templates). После этого на экран будет выведено диалоговое окно со списком всех шаблонов, подключенных к оснастке Политика "Локальный компьютер" (Local Computer Policy) (рис. 4.19).

Для добавления нового административного шаблона в этот список нужно нажать кнопку Добавить (Add) и выбрать нужный файл с расширением adm (в нашем случае это wsh.adm). После этого список подключенных шаблонов следует закрыть. В результате в каждом из разделов Конфигурация компьютера | Административные шаблоны (Computer Configuration | Administrative Templates) и Конфигурация пользователя | Административные шаблоны (User Configuration I Administrative Templates) создастся подраздел Локальные и удаленные сценарии WSH (рис. 4.20).

Рис. 4.18. Настройки групповой политики для локального компьютера

Рис. 4.19. Административные шаблоны, подключенные к оснастке Групповая политика

Рис. 4.20. Новый подраздел Локальные и удаленные сценарии WSH

Рис. 4.21. Параметры фильтрации административных шаблонов политик

Для того чтобы описанные в wsh.adm параметры можно было редактировать, нужно выделить подраздел Локальные и удаленные сценарии WSH, выбрать в меню Вид (View) пункт Фильтрация (Filter), снять флажок Показывать только управляемые параметры политики (Show controlled policy parameters only) в диалоговом окне Фильтрация (Filter) и нажать кнопку OK (рис. 4.21).

После этого в подразделе Локальные и удаленные сценарии WSH будут показаны описанные в wsh.adm параметры политики безопасности для WSH (рис. 4.22).

Рис. 4.22. Параметры политики безопасности для WSH, взятые из шаблона wsh.adm

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

Выбрав с помощью нажатия клавиши <Enter> нужный параметр, можно установить его значение (рис. 4.23).

Рис. 4.23. Изменение значения параметра политики безопасности для WSH

Для сценариев WSH можно задать один из трех режимов их выполнения:

1. Режим безопасности отключен. Запускаются все сценарии, вне зависимости от того, имеется ли у этих сценариев цифровая подпись или нет.

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

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

Как следует из табл. 4.2, для установки той или иной политики безопасности служит параметр реестра целого типа

TrustPolicy

Замечание

Для установки политики безопасности WSH с помощью

TrustPolicy

, необходимо, чтобы значением параметра

UseWINSAFER

был 0 (либо этот параметр не был указан совсем).

В качестве примера запустим сценарий Signed.vbs с подписью, основанной на цифровом сертификате "Попов ненадежный". Если

TrustPolicy

Рис. 4.24. Предупреждение о безопасности при запуске ненадежного сценария (

TrustPolicy=1

Рис. 4.25. Отказ при запуске ненадежного сценария (

TrustPolicy=2

Если же установить значение параметра

TrustPolicy

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

LogSecuritySuccesses

LogSecurityFailures

Замечание

Для просмотра журнала событий можно воспользоваться соответствующей оснасткой в ММС или выбрать в меню Пуск (Start) пункт Все программы | Администрирование | Просмотр событий (All Programs | Administrative Tools | Event Viewer). 

Рассмотрим пример. Установим режим безопасности так, чтобы для сценариев WSH велся как аудит успехов (

LogSecuritySuccesses="1"

LogSecurityFailures="1"

Enabled="0"

Рис. 4.26. Информация об отказе для сценария WSH в журнале событий системы

Разрешим теперь выполнение сценариев WSH (

Enabled="1"

TrustPolicy=2

Рис. 4.27. Информация об успехе для сценария WSH в журнале событий системы 

В Windows ХР встроены политики ограниченного использования программ (SRP, Software Restriction Policies), с помощью которых можно управлять возможностью выполнения программного обеспечения на компьютере. Политики SRP могут применяться и к сценариям WSH любого типа, для этого необходимо, чтобы параметр системного реестра

UseWINSAFER

Для применения политик SRP к сценариям WSH на локальной машине необходимо сначала загрузить в ММС оснастку Политика "Локальный компьютер" (Local Computer Policy) (рис. 4.28).

Рис. 4.28. Установка политик SRP с помощью оснастки Политика "Локальный компьютер"

Замечание

Процесс загрузки этой оснастки был подробно описан в разд. "Блокировка локальных и удаленных сценариев WSH. Пример административного шаблона" этой главы, поэтому здесь мы останавливаться на нем не будем.

После этого нужно перейти в раздел Конфигурация компьютера | Конфигурация Windows | Параметры безопасности | Политики ограниченного использования программ | Дополнительные правила (Computer Configuration | Windows Configuration | Security Settings | Software Restriction Policies | Additional Rules).

Создание и изменение дополнительных правил (Additional Rules) в SRP и является механизмом определения политик безопасности для сценариев WSH.

Для того чтобы, пользуясь SRP, запретить выполнение сценариев с определенными именами, нужно создать новое правило для пути (Path Rule), которое позволяет идентифицировать программы по пути к ним. Рассмотрим, например, каким образом можно запретить выполнение всех сценариев, написанных на языке VBScript (т.е. запретить запуск всех файлов с расширением vbs). Для этого нужно, находясь в разделе Дополнительные правила (Additional Rules), выбрать в меню Действие (Action) пункт Создать правило для пути (New Path Rule), после чего на экран будет выведено диалоговое окно, в котором нужно описать создаваемое правило. Здесь в поле Путь (Path) укажем маску "*.vbs" для всех VBScript-сценариев, а в раскрывающемся списке Уровень безопасности (Security level) выберем значение "Не разрешено" ("Disallowed") (рис. 4.29).

Рис. 4.29. Диалоговое окно для создания нового правила для пути

После ввода такого дополнительного правила SRP на машине нельзя будет запускать сценарии с расширением vbs. При попытке выполнения VBScript- сценария будет выведено диалоговое окно с информацией о невозможности его запуска (рис. 4.30).

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

Рис. 4.30. Блокировка сценариев WSH с помощью дополнительных правил SRP 

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

Рис. 4.31. Диалоговое окно для создания нового правила для сертификата

Для этого нужно в разделе Дополнительные правила (Additional rules) создать новое правило для сертификата (Certificate Rule) (пункт Создать правило для сертификата (New Certificate Rule) в меню Действие (Action)). В диалоговом окне Создание правила для сертификата (New Certificate Rule) в качестве имени субъекта сертификата (Certificate subject name) укажем с помощью кнопки Обзор (Browse) файл C:\Script\Попов.cer (процесс создания этого файла описан в разд. "Управление сертификатами с помощью ММС"), а в раскрывающемся списке Уровень безопасности (Security level) выберем значение "Не разрешено" ("Disallowed") — рис. 4.31.

После ввода этого дополнительного правила SRP на машине нельзя будет запускать никакие исполняемые файлы (сценарии WSH в том числе), которые подписаны с использованием сертификата "Попов ненадежный".