Основы защиты информации. Учебное пособие

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

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

2.2.ОБЗОР МОДЕЛЕЙ РАСПРОСТРАНЕНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Существует довольно много различных моделей распространения программного обеспечения. Рассмотрим характерные особенности наиболее часто используемых моделей.

2.2.1. БЕСПЛАТНЫЕ ПРОГРАММЫ (FREEWARE)

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

Многие бесплатные программы распространяются в исходных текстах. Но следует отличать программы в исходных текстах и бесплатные программы. Коммерческие продукты тоже могут поставляться в исходных текстах.

Нередко наблюдается ситуация, когда программа или библиотека бесплатна для личного использования, но требует лицензии для коммерческого применения.

Встречаются также случаи, когда бесплатное программное обеспечение разрабатывается крупными коммерческими компаниями для упрочнения положения на рынке (например, документы в формате pdf и бесплатная программа для их просмотра Acrobat Reader, дополняющая линейку платных программ для создания документов в формате pdf).

22

2.2.2. ПОЧТИ БЕСПЛАТНЫЕ ПРОГРАММЫ

(CARDWARE, MAILWARE, DONATIONWARE)

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

1)Cardware – каждый пользователь программы, желающий зарегистрироваться, должен послать автору программы почтовую открытку с видом местности, в которой он проживает;

2)Mailware – более современный вариант Cardware, подразумевающий отсылку автору электронного письма. Как правило, в ответ автор присылает регистрационный код, позволяющий работать с программой;

3)Donationware – автор программного обеспечения не требует никакой оплаты, но предлагает всем, кому понравилась программа, пожертвовать произвольную сумму, чтобы поддержать разработку.

2.2.3. ПРОГРАММЫ, ПОКАЗЫВАЮЩИЕ РЕКЛАМУ (ADWARE)

Основная идея заключается в том, что разработчик получает плату за использование программы не от конечного потребителя, которому программа достается бесплатно, а от рекламодателей. Примером такой программы служит программа «Дубль-ГИС».

2.2.4. КОММЕРЧЕСКИЕ ПРОГРАММЫ

Коммерческое программное обеспечение создается с целью извлечения прибыли и распространяется за материальное вознаграждение. Для такого программного обеспечения применяется принцип «деньги – вперед», т. е. пользователь получает программу только после полного внесения оплаты. Многие программы, распространяемые таким способом, являются «коробочными», т. е. похожими на обычный товар, который покупается в магазинах.

К популярным технологическим методам ограничения тиражирования в коммерческих программах относятся различные аппаратные защиты, системы регистрации и активации, проверка лицензии через Интернет при каждом запуске программы и т. д.

23

У коробочной модели распространения есть одна важная особенность: конечный потребитель сможет получить представление о том, что он покупает, только после совершения покупки, и это может отпугнуть покупателей.

2.2.5.ПОЧТИ РАБОТОСПОСОБНЫЕ ПРОГРАММЫ

(DEMOWARE, TRIALWARE, NAGWARE)

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

1)Demoware – в программе присутствуют функциональные ограничения. Например, можно обрабатывать файлы не больше определенного размера, нельзя выполнять сохранение и т. п.;

2)Trialware – подразумевается наличие ограничений по времени использования. Ограничения могут выражаться в виде длительности периода времени, на протяжении которого можно пользоваться программой (например, 30 дней с момента инсталляции), или в виде фиксированной даты истечения тестового периода. Может ограничиваться число запусков программы или число процессов обработки;

3)Nagware – пользователь регулярно извещается о том, что данная версия программы не является полноценной коммерческой версией. Такое извещение может выглядеть как диалоговое окно, появляющееся при запуске программы и с некоторой периодичностью во время работы; дополнительные надписи, выводимые на принтер или экран, и т. п.

2.2.6. УСЛОВНО БЕСПЛАТНЫЕ ПРОГРАММЫ (SHAREWARE)

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

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

24

действии в течение некоторого периода времени, по прошествии которого должно быть принято решение о приобретении программы.

Обычно для превращения ограниченной версии в полнофункциональную не требуется никаких дополнительных файлов – достаточно ввести правильный регистрационный код, полученный от продавца.

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

2.3. МЕТОДЫ ПРОТИВОДЕЙСТВИЯ АТАКАМ НА ПРИЛОЖЕНИЯ

Почему же разработчики создают уязвимые приложения? Основные причины, по которым создаются уязвимые приложения:

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

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

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

Рассмотрим основные типы атак на приложения.

2.3.1. ПЕРЕПОЛНЕНИЕ БУФЕРА

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

25

Одним из наиболее распространенных типов переполнения буфера является переполнение стека. Чтобы понять, как выполняются такие атаки, сначала рассмотрим, как программные приложения хранят в стеке переменные и другие данные. Рассмотрим следующую простейшую программу (рис. 1).

Рис. 1. Пример нормального функционирования стека

Теперь покажем, что будет, если через командную строку параметру argv[1] будет передано более 10 символов (рис. 2).

При выполнении строки

strcpy (buf, input);

приложение пытается сохранить строку

helloaaaaaaaa1066ACB1

в 10-символьный массив buf. Так как входные данные слишком длин-

ные, переписывают другие данные, хранящиеся в стеке, в том числе адрес, используемый программой для возвращения управления методу

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

26

привилегиями, что и исходное приложение, так как операционная система считает, что именно приложение вызвало этот код.

Рис. 2. Атака переполнением буфера, передающая управление по другому адресу

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

Другими распространенными типами переполнения буфера являются:

1)переполнение кучи – действует аналогично переполнению стека;

2)ошибки индексации массива;

3)ошибки в строках форматирования. Строго говоря, это не переполнение буфера, но эти ошибки способны вызвать аналогичные проблемы. Дело в том, что нет универсального способа, позволяюще-

27

го определить, сколько аргументов в действительности передано в функцию, которая принимает переменное число параметров. Наиболее известным примером таких функций являются функции семейства printf(). В последнем случае решение относительно простое: вместо printf(<входные_данные>) следует использовать printf("%s", <входные_данные>);

4) несовпадение размеров буфера при использовании Unicode и ANSI. Это возникает, если программист путает число элементов массива с его размером в байтах.

Более подробно познакомиться с этими типами ошибок можно в книге Майкла Ховарда и Дэвида Лебланка «Защищенный код».

Для борьбы с переполнением буфера необходимо выполнять следующие рекомендации к написанию кода:

1)нужно всегда проверять все входящие данные – всё, что вне функции, следует рассматривать как небезопасное и враждебное;

2)функция всегда должна завершаться корректно, даже если она получит данные, которые никак не ожидала получить;

3)строки должны обрабатываться безопасно:

а) нужно проверять на NULL строку-источник и строку-приемник; б) строка-источник должна заканчиваться символом NULL;

в) длина строки-источника не должна превышать длину буфера, выделенного для строки-приемника.

В качестве резюме: следует помнить, что если хакер имеет возможность писать в память приложения, то он всегда сможет «уронить» приложение или выполнить произвольный код – это лишь вопрос времени!

2.3.2. SQL–ИНЪЕКЦИИ

Атаки такого типа подразумевают вставку SQL-команды в качестве значения параметра запроса к базе данных, в результате чего изменяется логика корректного SQL-выражения. Для примера можно привести следующий код:

string sql = "select * from client where name =

='" + name + "'"

Вэтом примере значение для переменной name предоставляет пользователь. Опасность заключается в том, что он может подставить в пере-

28

менную name другое SQL-выражение. Например, он ввел "Blake". Тогда получится корректная SQL-команда, которая выберет из таблицы client только те строки, которые относятся к Blake:

select * from client where name = 'Blake'

Если пользователь ввел, например, "Blake' or 1=1 ", то получится следующая команда:

select * from client where name = 'Blake' or 1=1 '

Эта команда вернет все строки таблицы client. Такой вариант был бы приемлем, если бы эта таблица не содержала, например, номеров кредитных карт или других важных персональных данных, которые теперь становятся известными тому, кто ввел такие входные данные.

Но это еще не всё. Поскольку многие СУБД позволяют пользователю выполнять более одного SQL-выражения за один раз, то, введя

"Blake'; drop table client; ", в качестве результата полу-

чим запись из таблицы client с именем Blake, а затем удалим таблицу client, так как отправленный на выполнение запрос имеет вид

select * from client where name = = 'Blake'; drop table client; '

Теперь рассмотрим меры противодействия, которые нужно применять для безопасной работы с базой данных. Для начала рассмотрим «полумеры», которые часто применяются как панацея, но не являются хорошей защитой.

Псевдосредство № 1: экранирование кавычек

в вводимых данных

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

string sql = "select * from client where name = '" + + name + "' or age = " + age;

29

Тогда если хакер попытается в качестве имени name ввести что-ни- будь вроде "Michael' or 1=1 ", то одиночная кавычка продублируется, лишив возможности провести атаку, поскольку в этом случае получится следующее SQL-выражение:

select * from client where name = = 'Michael'' or 1=1 ' or age = 35

Но в таком случае хакер может применить тот же прием для поля age, к которому одиночные кавычки не добавляются. Для этого ему достаточно ввести "35; shutdown; ", и сервер остановится.

Еще одним способом скрыть употребление кавычки является функция char(0x27).

Псевдосредство № 2: хранимые процедуры

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

string sql = "exec spGetName '" + name + ...;

В этом случае попытка ввести "Blake' or 1=1 " закончится неудачей, поскольку следующий SQL-запрос некорректен:

exec spGetName 'Blake' or 1=1 '

Однако если ввести "Blake'; drop table client; ", то следующая SQL-команда получит данные о клиенте с именем Blake и удалит таблицу client:

exec spGetName 'Blake'; drop table client; '

Приведем еще один, недопустимый с точки зрения безопасности, пример использования хранимой процедуры:

create procedure spMyProc @input varchar(128) as exec(@input)

Этот код просто выполняет то, что ввел пользователь.

30