Защита WWW-сценариев от несанкционированного копирования и модификации

2001 г

Защита WWW-сценариев от несанкционированного копирования и модификации

Александр Аграновский
директор-гл.конструктор ГП КБ Спецвузавтоматика, Ростов-на-Дону
asni@rnd.runnet.ru, +7(8632)932894

Роман Хади
зав. лаб. информационной безопасности ГП КБ Спецвузавтоматика, Ростов-на-Дону
rhady@rsu.ru, +7(8632)932894

"Практическая криптография: алгоритмы и их программирование"

В статье рассматривается один из основных подходов к генерации динамического контента в среде веб-приложений, а именно использование веб-сценариев и CGI, и применительно к ним, методы защиты исходных текстов от несанкционированного копирования и модификации. В качестве основного языка веб-сценариев взят наиболее популярный - язык Perl. Исследованы инструментальные средства сторонних разработчиков (Perl2Exe утилита), встроенные средства кроссплатформенных интерпретаторов языка Perl и общий метод искажения смысловой нагрузки идентификаторов в исходном тексте (source mangling). Представляются исходные тексты с примерами защиты исходных текстов. Для каждого из представленных методов проводится анализ защищенности и методов получения доступа непосредственно к исходным текстам и их модификации.

Время реакции на весьма динамично развивающуюся среду веб-технологий определяет эффективность работы любого Internet-сайта. Современные технологии создания веб-контента в режиме реального времени дали профессиональному веб-мастеру мощнейшие инструменты для управлениями потоками информации в Internet. В условиях постоянного роста производительности, использование языков сценариев или как их еще называют scripting languages или scripts, стало одним из опорных решений фундаментального подхода организации инфраструктуры Internet-сайтов. Мощные, легко осваиваемые специализированные языки программирования, ориентированные на разработчиков веб-сайтов, получили широчайшее распространение. Языки сценариев изначально были ориентированы на быстрое и эффективное решение иных задач, нежели языки программирования системного уровня, поскольку они создавались как логически связующие компоненты к уже готовым программным решениям [1]. Преимущества такого подхода перед традиционным статическим наполнением веб-порталов видны невооруженным взглядом. Это и гибкость построения гипертекстовых переходов, и возможность создания отчетов по записям в базах данных в реальном времени, и генерация комплексных веб-документов из существующих элементарных компонентов [2].

Точно также, как и несколько лет назад в малых интегрированных сетях, в программировании контента публичных серверов существует два подхода. А именно, создание интерпретируемых сценариев и компиляция байт-кода. Первый подход не выходит за рамки CGI-программирования, согласно которого для разработки гипертекстовой страницы нужен только обычный текстовый редактор, а сам гипертекстовый документ должен легко читаться человеком. Второй подход повышает эффективность исполнения программы, а также защищенность кода от доступа и несанкционированных изменений [2]. Реализации интерпретаторов таких языков сценариев, как Perl и Phyton, в целях повышения эффективности перед исполнением сценария проводят предварительную перекомпиляцию в специальный мобильный байт-код. Для языка Perl, у него даже есть собственное название - пи-код (p-code), данное Ларри Уоллом (Larry Wall), создателем Perl. Такой код, будучи сформирован в результате трансляции исходного текста сценария, записывается в память или файл и лишь потом обрабатывается интерпретатором. Для языка Python файлы с байт-кодом (они имеют специальное расширение .pyc) в дальнейшем можно спокойно переносить с платформы на платформу и исполнять с равными правами как, к примеру, на Sun, так и на Intel PC/win32 - мобильность это позволяет.

В конце 90-х годов CGI-программирование, а это автоматизация, гостевые книги, форумы, опросы, списки рассылки, интерфейсы к базам данных и многое другое, стало наиболее популярным и эффективным способом организации интерактивного взаимодействия с пользователями. Как и в любой другой области программирования стали возникать свои вопросы и проблемы. Одним из самых интересных и неоднозначных вопросов был и остается вопрос о защите авторских прав [3]. Он актуален хотя бы потому, что все сценарные языки, такие как Perl, Phyton, JavaScript и всевозможные производные с постфиксом *script (т.е. JavaScript, PerlScript и так далее) являются интерпретируемыми, и ни о каких бинарных кодах и скрытом исходном тексте не может идти и речи. В этом случае исследованию алгоритма работы сценария и использованию его без разрешения авторов не создано никаких препятствий. Программисты, создающие средства веб-автоматизации пытаются решить эту проблему всевозможными способами, прибегая порой к изощренным методикам сокрытия исходных текстов и защиты их от модификации. Собственно говоря, защита от модификации хороша также и как защита, что называется "от дурака", что немаловажно при продаже программного обеспечения не в комплексе, а как отдельной единицы, когда приобретающий программное обеспечение пользователь получает полный доступ не только к конфигурационным файлам, но и к пакету самих сценариев. И при отсутствии у него должной квалификации, внесенные в сценарий изменения могут существенно повлиять на отказоустойчивость и работоспособность всего комплекса. Кроме того, как показывает практика обеспечения информационной безопасности в открытых системах, программное обеспечение веб-серверов зачастую столь несовершенно, что при достаточной сноровке злоумышленник вполне способен получить исходный текст сценариев веб-сервера (классическим примером может послужить инцидент с веб-сервером WebTrends, который позволял получить исходный текст сценариев просто добавив пробел к его имен в строке запроса. Так, запрос по адресу "http://somewhere.in.the.internet.com/cgi-bin/script.pl" запускал script.pl на исполнение, а запрос к "http://somewhere.in.the.internet.com/cgi-bin/script.pl%20" выдавал исходный текст сценария любому неавторизованному пользователю).

Для, пожалуй, самого популярного в РуНете, да и во всем мире, языка сценариев Perl, одним из вариантов сокрытия исходных текстов стала возможность компилирования исходных текстов в исполняемый бинарный код (формат PE-exe для win32 платформ, ELF для Linux/BSD). Утилиту для компиляции, названную Perl2Exe, с недавних пор предоставляет компания сторонних разработчиков IndigoStar Software. Девизом разработчиков стала рекламная фраза о том, что теперь программист может распространять perl-сценарий в виде exe-файла, не предоставляя исходных текстов [4].

PERL2EXE.
Утилита для преобразования Perl сценариев в исполнимые файлы, не требующие наличия интерпретатора языка Perl. Perl2Exe может сгенерировать модули для Win32 и многих Unix-подобных операционных систем. Perl2Exe также позволяет создавать неконсольные программы, с использованием Perl/Tk.

IndigoSTAR Software, http://www.indigostar.com/perl2exe.htm

Исходя из представленных заявлений, можно было бы предположить, что имеется в виду интеграция непосредственно интерпретатора языка Perl и уже готового пи-кода сценария. То есть, бинарный исполнимый файл ни в коем случае не содержит исходного текста сценария. Однако, на поверку компиляция оказалась даже не компиляцией в пи-код, а именно простым вложением зашифрованного файла с исходным текстом на языке. В процессе исполнения бинарного файла (для платформы win32 это обычный PE-EXE исполнимый файл), исходный текст сценария и требуемые модули языка Perl расшифровываются с помощью инженерного пароля, а затем исполняются. Для этого используется технология "Perl Embedded in C", разработанная Ларри Уоллом, инструментарий для которой распространяется вместе с интерпретаторами языка сценариев Perl бесплатно.

В начале июня этого года среди писем, распространяемых в популярной рассылке BugTraq, посвященной информационной безопасности и, в частности, выявлению фактов уязвимости программного обеспечения можно было встретить письма о безопасности предлагаемого разработчиками IndigoStar Software распространения исходных текстов сценариев в виде бинарных файлов. Несмотря на то, что авторы утилиты Perl2Exe не предоставляют ее исходных текстов, оказалось возможным, исследовав ее программный код, найти инженерный пароль и способ зашифрования исходных текстов. Более того, это оказалось возможно делать в совершенно автоматическом режиме, без участия человека-оператора. Говорить о криптографической стойкости примененного метода бессмысленно, поскольку ключ к шифру находится рядом с самим шифром [5]. Таким образом, чтобы извлечь исходный текст из бинарного файла, достаточно запустить на исполнение специальную утилиту, совершающую обратное преобразование Exe2Perl. Автором одной из таких утилит, с легкостью позволяющей "доставать" исходные тексты, является Четан Ганатра (Chetan Ganatra, ganatras@infotech.icici.com).

Следующим способом сокрытия исходных текстов и их защита от несанкционированной модификации можно указать встроенные средства языка Perl. Это так называемые фильтры исходных текстов или source filters.

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

#!/bin/perl
use DecipherModule;
@*x$]`0uN&k^Zx02jZ^X{.?s!(f;9Q/^A^@~~8H]|,%@^P:q-=
…

Фильтры исходных текстов в частном случае позволяют зашифровать и/или заархивировать часть основного тела сценария так, что сначала будет загружен специальный модуль, который будет расшифровывать остальную часть сценария построчно. Преимущества такого подхода возможно не очевидны на первый взгляд. Для этого необходимо чуть более детально разобраться в достаточно универсальном механизме фильтров исходных текстов. На первый взгляд, этот весьма специфичный инструмент несет в себе возможности и разработки нескольких последних лет в смежных областях программирования и защиты программного обеспечения. Многие технологии защиты программного обеспечения от несанкционированного копирования и использования могут быть с легкостью перенесены на "почву" фильтров исходных текстов и использованы для веб-сценариев. И здесь точно также, как и на платформах с win32 существуют те же проблемы и методы обхода защитных барьеров.

Самым уязвимым в смысле защиты от исследования сценария, является модуль расшифрования основного тела исходного текста. Он может быть написан на самом языке Perl, но тогда достаточно будет исследовать его, что является в общем-то тривиальной задачей, поскольку он не может быть зашифрован. Кроме этого, если алгоритм зашифрования достаточно сложен, расшифровка всего исходного текста может занять долгое время, что неизбежно скажется на эффективности функционирования веб-узла, а это нежелательно ни при каких обстоятельствах. Очевидно, что в этом случае применять шифрование может быть не очень удачным решением. Однако, в качестве расшифровывающего модуля можно использовать своего рода плагин, подлючаемую библиотеку, написанную на любом другом языке и откомпилированную как разделяемый модуль (shared library). Используя специальный набор функций Perl API, данный модуль расшифрует исходный текст гораздо быстрее, чем если бы он сам был написан на языке Perl. Кроме того, такой подход позволяет на полную мощность использовать средства усложнения анализа программного кода, включая такие известные приемы как применение самомодифицирующегося кода, шифрование/расшифрование "на лету", во время исполнения процедур модуля. Встроенные средства Perl API позволяют также определить запущен ли скрипт под отладчиком в целях исследования его кода, а также наличие и количество других фильтров исходных текстов.

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

Исходный текст сценария в открытом виде:

#!/bin/perl
print "Hello, world";
die immediately;

И в зашифрованном виде (после обработки специальной утилитой):

#!/bin/perl
use scripher;
f;9Q/^A^@~Ро$#9Ёфsdjаs2fk58f_!@.?s!(f;9Q/^A^@~

Модуль scripher.pm загружает заранее откомпилированную разделямую библиотеку scripher.so с помощью стандартного модуля интерпретатора DynaLoader.

Scripher.pm
package scripher;
require DynaLoader;
@ISA = qw(DynaLoader);
$VERSION = "0.0.1";
bootstrap scripher $VERSION;
1;

Семикилобайтный модуль с реализованным алгоритмом RC4 и необходимыми средствами обработки исходного текста размещается в том же каталоге, что и зашифрованный файл сценария. Таким образом, для передачи сценария необходимо передать два дополнительных файла (которые являются общими для всех зашифрованных сценариев этого типа), а именно scripher.pm и scripher.so.

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

В качестве дополнительного препятствия к анализу исходного текста сценария можно отметить метод смысловых значений идентификаторов или source mangling. Будучи пропущенным через своего рода конвертер, сценарий приобретает практически нечитаемый и невероятно неудобный для анализа вид.

При использовании source mangling текст такого сценария:

#!/usr/bin/perl
# randomize source file
# lines are output in random order
# reads from from stdin or arg0, writes to stdout or arg1
open (STDIN, $ARGV[0]) if (($ARGV[0] ne "") && ($ARGV[0] ne "-"));
open (STDOUT, ">$ARGV[1]") if ($ARGV[1] ne "");
@list = <STDIN>;
while (@list) {
    $rand = rand (@list);
    print $list[$rand];              # for indexing rand is truncated
    plice @list, $rand, 1;          # delete array element
}

превратится в нечто подобное:

#!/usr/bin/perl
open (STDIN,$ARGV[0])if (($ARGV[0] ne "")&&($ARGV[0] ne "-"));open 
(STDOUT,">$ARGV[1]")if ($ARGV[1] ne "");@110202012_as=<STDIN>;
while(@110202012_as){$qewre7_434=rand(@l110202012_as);print 
$110202012_as[$qewre7_434];splice@110202012_as,$qewre7_434,1;}

Ранее искажение исходных текстов было весьма популярно - достаточно вспомнить распространяемые исходные тексты на языке Паскаль к пакетам Turbo Power для Borland Pascal 7.0. Искаженные подобным образом, они тем не менее оставались годными к компиляции и линковке. Возможно, что с развитием сценарного программирование, source mangling приобретет вторую молодость.

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

Литература:

[1] Остераут Д., "Сценарии: высокоуровневое программирование для XXI века", ОТКРЫТЫЕ СИСТЕМЫ #03/98.
http://www.osp.ru/os/1998/03/12.htm

[2] Храмцов П., "Управление сценариями просмотра Web-страниц", COMPUTERWORLD РОССИЯ #46/96.
http://www.osp.ru/cw/1996/46/34.htm
http://www.citforum.ru/internet/articles/art_1.shtml

[3] Крюков М., Прозоровский В., "Гражданско-правовой статус производителей программ", ОТКРЫТЫЕ СИСТЕМЫ #02/99.
http://www.osp.ru/os/1999/02/14.htm

[4] IndigoStar Software, "Perl2Exe FAQ Page".
http://www.indigostar.com/p2xfaq.htm

[5] Аграновский А.В., Хади Р.А., Ерусалимский Я.М., "Криптография и открытые системы", Телекоммуникации, N1/2000.