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

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

В программировании «динамического» контента публичных серверов существует два подхода. А именно, создание интерпретируемых сценариев и компиляция байт-кода. Реализации интерпретаторов таких языков сценариев, как Perl и Phyton, в целях повышения эффективности перед исполнением сценария проводят предварительную перекомпиляцию в специальный мобильный байт-код. Для языка Perl, у него даже есть собственное название - пи-код (p-code), данное Ларри Уоллом (Larry Wall), создателем Perl. Такой код, будучи сформирован в результате трансляции исходного текста сценария, записывается в память или файл и лишь потом обрабатывается интерпретатором. Для языка Python файлы с байт-кодом (они имеют специальное расширение .pyc) в дальнейшем можно спокойно переносить с платформы на платформу и исполнять с равными правами как, к примеру, на Sun, так и на Intel PC/win32 - мобильность это позволяет. В конце 90-х годов CGI-программирование, а это автоматизация, гостевые книги, форумы, опросы, списки рассылки, интерфейсы к базам данных и многое другое, стало наиболее популярным и эффективным способом организации интерактивного взаимодействия с пользователями. Как и в любой другой области программирования стали возникать свои вопросы и проблемы. Одним из самых интересных и неоднозначных вопросов был и остается вопрос о защите авторских прав. Он актуален хотя бы потому, что все сценарные языки, такие как 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" выдавал исходный текст сценария любому неавторизованному пользователю). /* Помимо малосвойственной русской душе проблемы защиты авторских прав, у скриптописцев может быть еще по крайней мере два резона скрывать исходный код. Условно назовем их «стыдливость» и «параноидальность». В первом случае, характерном для программистов-непрофессионалов, человеку может быть стыдно за свой изрядно корявый, по сравнению с профессиональным, код и ему вовсе не хочется, чтобы любопытствующие гуру усмехались над его чудовищной писаниной. Работает – и ладно, нечего проекту под юбку лезть. Или, может, у этого программиста есть манера называть переменные неприличными словами – зачем посторонним смотреть на это и делать о человеке скороспелые выводы? Во втором случае скриптописец, зачастую по совместительству веб-мастер, хозяин проекта и системный администратор, излишне беспокоится о том, что из кода можно понять внутреннее устройство проекта или системы – где расположены базы данных, лог-файлы и прочие подобные вещи. Надо, конечно, быть полным идиотом, чтобы оставить в теле скрипта что-то действительно ценное для злоумышленника, но паранойя она и есть паранойя ;) – прим. ред.*/

Perl2Exe Для, пожалуй, самого популярного языка сценариев Perl, одним из вариантов сокрытия исходных текстов стала возможность компилирования исходных текстов в исполняемый бинарный код (формат PE- exe для win32 платформ, ELF для Linux/BSD). Утилиту для компиляции, названную Perl2Exe, с недавних пор предоставляет компания сторонних разработчиков IndigoStar Software. Девизом разработчиков стала рекламная фраза о том, что теперь программист может распространять perl-сценарий в виде exe-файла, не предоставляя исходных текстов. /* Кстати, опять же, защита интеллектуальной собственности – далеко не единственный резон использовать Perl2Exe. Очень выручает эта утилита в случае, когда администратор предпочитает Perl в качестве языка для написания не очень mission-critical (Perl производительным языком не назовешь) утилиток для своих пользователей. Устанавливать беднягам полный Perl для работы единственной утилиты – кощунство. – прим. ред. */ Исходя из представленных заявлений, можно было бы предположить, что имеется в виду интеграция непосредственно интерпретатора языка Perl и уже готового пи-кода сценария. То есть, бинарный исполнимый файл ни в коем случае не содержит исходного текста сценария. Однако, на поверку компиляция оказалась даже не компиляцией в пи-код, а именно простым вложением зашифрованного файла с исходным текстом на языке. В процессе исполнения бинарного файла (для платформы win32 это обычный PE-EXE исполнимый файл), исходный текст сценария и требуемые модули языка Perl расшифровываются с помощью инженерного пароля, а затем исполняются. Для этого используется технология "Perl Embedded in C", разработанная Ларри Уоллом, инструментарий для которой распространяется вместе с интерпретаторами языка сценариев Perl бесплатно. Среди писем, распространяемых в популярной рассылке BugTraq, посвященной информационной безопасности и, в частности, выявлению фактов уязвимости программного обеспечения можно было встретить письма о безопасности предлагаемого разработчиками IndigoStar Software решения. Несмотря на то, что авторы утилиты Perl2Exe не предоставляют ее исходных текстов, оказалось возможным, исследовав ее программный код, найти инженерный пароль и способ зашифрования исходных текстов. Более того, это оказалось возможно делать в совершенно автоматическом режиме, без участия человека-оператора. Говорить о криптографической стойкости примененного метода бессмысленно, поскольку ключ к шифру находится рядом с самим шифром. Таким образом, чтобы извлечь исходный текст из бинарного файла, достаточно запустить на исполнение специальную утилиту, совершающую обратное преобразование Exe2Perl. Автором одной из таких утилит, с легкостью позволяющей "доставать" исходные тексты, является Четан Ганатра (Chetan Ganatra, ganatras@infotech.icici.com).

source filters Следующим способом сокрытия исходных текстов и их защита от несанкционированной модификации можно указать встроенные средства языка 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 приобретет вторую молодость. Из всего вышесказанного можно сделать очевидный вывод, что каждый раз развитие новой технологии поднимает множество вопросов, касающихся области интеллектуальной собственности, и каждый раз вслед за обострением борьбы за авторские права возникают всевозможные способы их защиты, де юре и де факто, и обхода защитных барьеров.

Александр Аграновский, директор-гл.конструктор ГП КБ Спецвузавтоматика, Ростов-на-Дону Роман Хади, зав. лаб. информационной безопасности ГП КБ Спецвузавтоматика, Ростов-на-Дону



© Сетевые Решения