Совершенствование подсистемы защиты от вредоносного программного обеспечения (разрушающих программных средств) организации (по материалам ООО "СтройСпецКомплект", Краснодарский край, ст. Пластуновская)

По используемым механизмам защиты системы защиты можно классифицировать на:

системы, использующие сложные логические механизмы;

системы, использующие шифрование защищаемого ПО;

комбинированные системы.

Системы первого типа используют различные методы и приёмы, ориентированные на затруднение дизассемблирования, отладки и анализа алгоритма системы защиты и защищаемого ПО. Этот тип системы защиты наименее стоек к атакам, так как для преодоления защиты достаточно проанализировать логику процедур проверки и должным образом их модифицировать.

Более стойкими являются системы второго типа. Для дезактивации таких защит необходимо определение ключа дешифрации ПО. Самыми стойкими к атакам являются комбинированные системы.

Для защиты ПО используется ряд методов, таких как:

Алгоритмы запутывания (обфускация)- используются хаотические переходы в разные части кода, внедрение ложных процедур - «пустышек», холостые циклы, искажение количества реальных параметров процедур ПО, разброс участков кода по разным областям ОЗУ и т.п.

Алгоритмы шифрования данных - программа шифруется, а затем расшифровывается по мере выполнения.

Метод проверки целостности программного кода - проверка на изменения в коде программы;

Эмуляция процессоров - создается виртуальный процессор и/или операционная система (не обязательно существующие) и программа-переводчик из системы команд IBM в систему команд созданного процессора или ОС, после такого перевода ПО может выполняться только при помощи эмулятора, что резко затрудняет исследование алгоритма ПО.

Выполнение на сервере.

По принципу функционирования СЗ можно подразделить на:

упаковщики/шифраторы;

СЗ от несанкционированного копирования;

СЗ от несанкционированного доступа (НСД).

Алгоритмы запутывания (обфускация).

Обфускация ("obfuscation" - запутывание), это один из методов защиты программного кода, который позволяет усложнить процесс реверсивной инженерии кода защищаемого программного продукта.

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

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

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

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

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

Определение. Пусть "TR" будет трансформирующим процессом, тогда при "PR1 =TR=> PR2" программа "PR2" будет представлять собой трансформированный код программы "PR1". Процесс трансформации "TR" будет считаться процессом обфускации если, будут удовлетворены такие требования:

код программы "PR2" в результате трансформации будет существенно отличаться от кода программы "PR1", но при этом он будет выполнять те же функции что и код программы "PR1", а также будет работоспособным.

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

при каждом процессе трансформации одного и того же кода программы "PR1", код программ "PR2" будут различны.

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

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

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

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

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

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

Также на сегодняшний день процесс низкоуровневой обфускации исследован мало.

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

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

Оценка процесса обфускации.

Существует много методов определения эффективности применения того или иного процесса обфускации, к конкретному программному коду.

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

Устойчивость - указывает на степень сложности осуществления реверсивной инженерии над кодом прошедшим процесс обфускации.

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

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

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

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

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

Виды обфускации.

1.Преобразования форматирования, или лексические преобразования.

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

2.Преобразования структур данных.

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

3.Преобразования потока управления программы.

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

4.Преобразования потока данных программы.

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

Обфускация такого вида включает в себя следующие методы:

удаление всех комментариев в коде программы, или изменение их на дезинформирующие;

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

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

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

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

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

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

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

2.По тексту обфусцированной программы установить значение переменной V сложно.

Аналогично определяется непрозрачный предикат - предикат Р считается непрозрачным предикатом, если его результат известен только в процессе обфускации, то есть после осуществления процесса обфускации, определение значения такого предиката становится трудным. Предикат возвращает значения из множества {истина, ложь}.

Обозначим через PT:

непрозрачный предикат, возвращающий всегда истинное значение, через PF;

непрозрачный предикат, возвращающий всегда ложное значение, и через P;

непрозрачный предикат, который может вернуть как истинное, так и ложное значение.

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

{

Int v,a=5,b=6;

v=a+b;

if (b>5) …//всегда истина

…

if (random(1,5)<0) … //всегда ложно

}

Внесение недостижимого кода.

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

Назовем мёртвым такой код, выполнение которого никак не влияет на результат работы программы. Тривиальный пример мертвой инструкции - NOP, инструкция, которая ничего не делает. Менее тривиальный пример - расширение арифметических операций: прибавление, равного нулю слагаемого, умножение на равный единице множитель и т.д. В отличие от недостижимого кода, который не исполняется никогда, мёртвый код может исполняться, поэтому при использовании этого метода нужно учитывать все последствия выполнения вносимого кода. В этом методе также можно использовать непрозрачные предикаты, вставляя в мертвый код условный оператор, проверяющий значение PF. Это комбинирование недостижимого и мёртвого кода, поскольку сама проверка ложного условия является мертвой инструкцией. При этом изменяется как граф потоков управления, так и граф потоков данных.

Клонирование кода.

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

Введение «блока-диспетчера». Данный метод направлен на существенное изменение графа потоков управления программы. Другое распространенное название этого метода - «уплощение», приведение графа к плоскому виду. Метод состоит в том, что управление из одного функционального блока в другой передается не непосредственно, а через введенный в процессе обфускации «диспетчер». При этом граф потоков управления становится плоским. Граф потоков данных также существенно

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

Метод проверки целостности кода программы.

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

1.Обнаружить, что программа была модифицирована,

2.Если это возможно, исправить обнаруженные изменения, в противном случае обеспечить аварийное завершение программы.

В идеальном случае обнаружение изменения в коде и соответствующее этому обнаружению аварийное завершение программы должны быть широко распределены во времени и коде программы, чтобы запутать потенциального атакующего. Очевидно, что код < if (tampered()) i = 1 / 0 > не обеспечивает достаточной защиты в связи с возможностью тривиального обнаружения и устранения.

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

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

2.Исследовать правильность промежуточных результатов, получаемых в программе. Этот подход известен как проверка программы (program verification). Кроме рассматриваемых целей, этот метод также может использоваться для верификации или тестирования программы на этапе разработки и является самым применяемым для решения задачи обнаружения изменений в программе.

Для проверки приложения на неизменность предлагается использовать множество объектов - троек <тестер, интервал, корректор>. Тестером называется подпрограмма, вычисляющая хэш-функцию от некоторого интервала (участка кода) программы и сравнивающая его с оригиналом. В процессе выполнения тестеры запускаются и проверяют правильность интервала, за который они отвечают, путем сравнения оригинального значения хэш-функции и действительного. В случае, если значения не совпадают, программа через некоторое время аварийно завершается. Корректоры необходимы для безопасного хранения оригинальных значений хэш-функции. Корректоры могут быть как константами (т.е. просто массивом байт), так и подпрограммами, конструирующими оригинальное значение. Очевидно, второй подход обеспечивает большую защиту.

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

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

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

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

Один из таких методов, названный забывчивым хэшированием (oblivious hashing). В качестве объекта проверки предлагается использовать не бинарный код, а след выполнения программы (функции, участка программы и т.п.). Программа (функция, участок) представляется в виде последовательности абстрактных машинных инструкций которые обращаются для чтения и записи к участкам памяти , начального состояния памяти , счетчика инструкций C и его начального значения . Следом некоторого участка программы называется пятерка , где - некоторый входной параметр, который влияет на выполнение участка программы. В процессе выполнения участка программы вычисляется хэш-функция от его следа. Поскольку след отражает семантику участка программы, полученное значение хэш - функции по сути является цифровой подписью, выполненной над поведением этого участка. Изменение как кода, так и данных, с которыми оперирует участок, приведет к несовпадению полученного при проверке значения хэш-функции с оригинальным значением, что позволит определить наличие изменений в программе.

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

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

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

Электронная цифровая подпись.

Основные определения, обозначения и алгоритмы.

Для реализации схем электронной цифровой подписи (или просто цифровой подписи) требуются три следующих эффективно функционирующих алгоритма:

Ak - алгоритм генерации секретного и открытого ключей для подписи кода программы, а также проверки подписи, - s и p соответственно;

As - алгоритм генерации (проставления) подписи с использованием секретного ключа s;

Ap - алгоритм проверки (верификации) подписи с использованием открытого ключа p.

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

Таким образом, если Ak - алгоритм генерации ключей, тогда определим значения (s,p)=Ak(б,в) как указанные выше сгенерированные ключи, где б - некоторый параметр безопасности (как правило, длина ключей), а в - параметр, характеризующий случайный характер работы алгоритма Ak при каждом его вызове.

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

Непосредственно процесс подписи осуществляется посредством алгоритма As. В этом случае значениеc=As(m) - есть подпись кода программы m, полученная при помощи алгоритма As и ключа s.

Процесс верификации выполняется следующим образом. Пусть m* и c* - код программы и подпись для этого кода соответственно, Ap - алгоритм верификации. Тогда, выбрав из справочника общедоступный открытый ключ p, можно выполнить алгоритм верификации: b=Ap(m*,c*), где предикат b {true,false}. Если b=true, то код m* действительно соответствует подписи c*, полученной при помощи секретного ключа s, который, в свою очередь, соответствует открытому ключу p, то есть m=m*, c=c* и наоборот еслиb=false, то код программы ложен и (или) код подписан ложным ключом.

Примеры схем электронной цифровой подписи. К наиболее известным схемам цифровой подписи с прикладной точки зрения относятся схемы RSA, схемы Рабина-Уильямса, Эль-Гамаля, Шнорра и Фиата-Шамира, а также схема электронной цифровой подписи отечественного стандарта ГОСТ Р 34.10-94.

Рассмотрим несколько подробнее наиболее известные схемы цифровой подписи:

Генерация ключей:(d,(e,n))=Ak(l,b).

Подпись:As:1.md(mod n) c, где c - подпись кода программы m.

Верификация:Ap:1.[c*]e(mod n) m**,

2.если m**=m*, подпись верна.

Подпись Эль-Гамаля: Вход: Числа и , где - простое l-разрядное число, а - первообразный корень по модулю . Секретный ключ , открытый ключ , такой, что , m - подписываемый код программы.

Генерация ключей:(d,(e,g,p))=Ak(l,b).

Подпись:As:1.r gk(mod p), где k RZp-1;

2.находится такое c, что m [kc+dr](mod p-1),

где (c,r) - подпись кода m.

Верификация:Ap:1.если gm*=errc*(mod p), то подпись верна.

Подпись стандарта ГОСТ Р 34.10-94.

Вход: Числа где - простое l-разрядное число, - первообразный корень по модулю а - большой простой делитель . Пусть также . Секретный ключ подписи и открытый ключ .

Генерация ключей:(x,(g,p,q,y))=Ak(l,b).

Подпись Ax:

1.r [gk(mod p)](mod q), где k RZq.

2.s [xr+km)](mod q), где m=h(M) -рассматривается как значение хэш-функции h, соответствующей отечественному стандарту на функцию хэширования сообщений ГОСТ Р 34.11-94. Таким образом, пара (r,s) - есть подпись кода программы M.

Верификация: Ay: 1.v m-1(mod q).

2.u [gsvy-rv(mod p)](mod q);

3.Если u=r, то (r,s) - есть подпись кода программы M, где m=h(M).

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

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

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

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

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

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

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

Угрозами для схем цифровой подписи являются раскрытие схемы или подделка подписи. Определяются следующие типы угроз:

полного раскрытия, когда противник в состоянии вычислить секретный ключ подписи;

универсальной подделки, когда противник находит алгоритм, функционально эквивалентный алгоритму вычисления подписи;

селективной подделки, когда осуществляется подделка подписи для кода программы, выбранного противником априори;

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

Угрозы перечислены в порядке ослабления. Стойкость схемы электронной подписи определяется относительно пары (тип атаки, угроза).

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

Метод эмуляции процессора в защите ПО

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

Почему же, учитывая высокую теоретическую эффективность, данный метод до сих пор не используется повсеместно? Видимо по двум основным причинам. Во-первых, метод имеет особенности, что сужает области его потенциального применения - об этом будет сказано ниже. Во-вторых, и, возможно, это более серьезная причина, сложность (а следовательно и стоимость) реализации метода весьма высока. Если же учесть принципиальную возможность утечки информации о только что созданной системе, которая моментально приведет к ее неэффективности и обесцениванию, становится понятно, почему фирмы-производители защитного ПО не спешат реализовывать этот метод. Стоит, однако, отметить, что с теми или иными вариациями и ограничениями данный метод все же реализован в таких новейших продуктах как StarForce3, NeoGuard, VMProtect и др. Видимо таких продуктов будет становиться все больше и больше, а существующие будут развиваться, т.к. появляющиеся реализации подтверждают высокую эффективность метода, хоть и имеют пока слабые стороны.

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

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

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

Рисунок 5 - Схема работы комплекса

2.4 Выбор комплекса задач автоматизации

ООО «СтройСпецКомплект» дорожит своей репутацией и отношениями с клиентами.

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

Отдел тестирования выполняет следующие задачи:

Верификация функционала и требований.

Проверка граничных значений.

Обработка ошибок.

Эффектные тесты.

Конфигурационное тестирование.

Регрессионное тестирование.

Отдел взаимодействует с отделом разработки и отделом информационных технологий. От отдела разработки получают программы и требования к ним. Затем определяется необходимость выполнения тех или иных типов тестирования. Разрабатываются сценарии тестирования. Проводятся тестовые испытания в соответствии со сценариями. Фиксируются и документируются ошибки. Пишутся отчёты о тестировании. Пишется пользовательская документация. В случае удачного прохождения тестов, пишется выпускная документация. Затем программа вместе с пользовательской и выпускной документацией отправляется в отдел информационных технологий. Отдел информационных технологий внедряет программу клиенту. В случае нахождения клиентом ошибок, сотрудник отдела информационных технологий пишет заявку на обработку ошибки и отправляет её в отдел тестирования. После тестирования ошибки, в случае подтверждения, дефект документируется и отправляется в отдел разработки [2, 56 c.].

На данный момент компания не имеет системы управления предприятием, однако активно применяет пакет MSOffice. Информационным каналом является электронная почта.

Для автоматизации деятельности ООО «СтройСпецКомплект» был выделен отдел тестирования. Это один из ключевых процессов работы компании. Планируется извлечь выгоду из автоматизации управления отделом тестирования.

Рисунок 7 - Итерационная модель разработки

2.5 Защита экономической информации на предприятии

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

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

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

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

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

Работа по созданию единой системы безопасности включает в себя ряд направлений:

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

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

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

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

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

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

научно-методическая - накопление и распространение передового опыта в области обеспечения безопасности; организация обучения сотрудников других подразделений (в необходимом им объеме);

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



2.6 Классификация вредоносного программного обеспечения (разрушающие ПО)

В ходе исследования организации ООО «СтройСпецКомплект» было обнаружено множество зараженных троянскими вирусами устройств, поэтому было проведено исследование и осуществление классификации троянского вируса.

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

Backdoor - троянские утилиты удаленного администрирования

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

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

Утилиты скрытого управления позволяют делать с компьютером все, что в них заложил автор: принимать или отсылать файлы, запускать и уничтожать их, выводить сообщения, стирать информацию, перезагружать компьютер и т.д. В результате эти троянцы могут быть использованы для обнаружения и передачи конфиденциальной информации, для запуска вирусов, уничтожения данных и т.п. - пораженные компьютеры оказываются открытыми для злоумышленных действий хакеров [3, 88 c.].

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

Отдельно следует отметить группу бэкдоров, способных распространяться по сети и внедряться в другие компьютеры, как это делают компьютерные черви. Отличает такие "троянцы" от червей тот факт, что они распространяются по сети не самопроизвольно (как черви), а только по специальной команде "хозяина", управляющего данной копией троянской программы [11, 58 c.].

Trojan-PSW - воровство паролей.

Данное семейство объединяет троянские программы, "ворующие" различную информацию с зараженного компьютера, обычно - системные пароли (PSW - Password-Stealing-Ware). При запуске PSW-троянцы ищут сиcтемные файлы, хранящие различную конфиденциальную информацию (обычно номера телефонов и пароли доступа к интернету) и отсылают ее по указанному в коде "троянца" электронному адресу или адресам.

Существуют PSW-троянцы, которые сообщают и другую информацию о зараженном компьютере, например, информацию о системе (размер памяти и дискового пространства, версия операционной системы), тип используемого почтового клиента, IP-адрес и т.п. Некоторые троянцы данного типа "воруют" регистрационную информацию к различному программному обеспечению, коды доступа к сетевым играм и прочее.

Trojan-AOL - семейство троянских программ, "ворующих" коды доступа к сети AOL (America Online). Выделены в особую группу по причине своей многочисленности.

Trojan-Clicker - интернет-кликеры

Семейство троянских программ, основная функция которых - организация несанкционированных обращений к интернет-ресурсам (обычно к веб-страницам). Достигается это либо посылкой соответствующих команд браузеру, либо заменой системных файлов, в которых указаны "стандартные" адреса интернет-ресурсов (например, файл hosts в MS Windows).

У злоумышленника могут быть следующие цели для подобных действий:

увеличение посещаемости каких-либо сайтов с целью увеличения показов рекламы;

организация DoS-атаки (Denial of Service) на какой-либо сервер;

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

Trojan-Downloader - доставка прочих вредоносных программ

Троянские программы этого класса предназначены для загрузки и установки на компьютер-жертву новых версий вредоносных программ, установки "троянцев" или рекламных систем. Загруженные из интернета программы затем либо запускаются на выполнение, либо регистрируются "троянцем" на автозагрузку в соответствии с возможностями операционной системы. Данные действия при этом происходят без ведома пользователя.

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

Trojan-Dropper - инсталляторы прочих вредоносных программ.

Троянские программы этого класса написаны в целях скрытной инсталляции других программ и практически всегда используются для "подсовывания" на компьютер-жертву вирусов или других троянских программ.

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

Обычно структура таких программ следующая:

"Основной код" выделяет из своего файла остальные компоненты (файл 1, файл 2,. .), записывает их на диск и открывает их (запускает на выполнение).

Обычно один (или более) компонентов являются троянскими программами, и как минимум один компонент является "обманкой": программой-шуткой, игрой, картинкой или чем-то подобным. "Обманка" должна отвлечь внимание пользователя и/или продемонстрировать то, что запускаемый файл действительно делает что-то "полезное", в то время как троянская компонента инсталлируется в систему.

В результате использования программ данного класса хакеры достигают двух целей:

скрытная инсталляция троянских программ и/или вирусов;

защита от антивирусных программ, поскольку не все из них в состоянии проверить все компоненты внутри файлов этого типа.

Trojan-Proxy - троянские прокси-сервера.

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

Trojan-Spy - шпионские программы.

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

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

Trojan - прочие троянские программы.

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

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

Rootkit - сокрытие присутствия в операционной системе.

Понятие rootkit пришло из UNIX. Первоначально это понятие использовалось для обозначения набора инструментов, применяемых для получения прав root.

Так как инструменты типа rootkit на сегодняшний день "прижились" и на других ОС (в том числе, на Windows), то следует признать подобное определение rootkit морально устаревшим и не отвечающим реальному положению дел.

Таким образом, rootkit - программный код или техника, направленная на сокрытие присутствия в системе заданных объектов (процессов, файлов, ключей реестра и т.д.).

Для поведения Rootkit в классификации "Лаборатории Касперского" действуют правила поглощения: Rootkit - самое младшее поведение среди вредоносных программ. То есть, если Rootkit-программа имеет троянскую составляющую, то она детектируется как Trojan.

ArcBomb - "бомбы" в архивах.

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

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

Некорректный заголовок архива или испорченные данные в архиве могут привести к сбою в работе конкретного архиватора или алгоритма разархивирования при разборе содержимого архива. Значительных размеров файл, содержащий повторяющиеся данные, позволяет заархивировать такой файл в архив небольшого размера (например, 5ГБ данных упаковываются в 200КБ RAR или в 480КБ ZIP-архив).

Огромное количество одинаковых файлов в архиве также практически не сказывается на размере архива при использовании специальных методов (например, существуют приемы упаковки 10100 одинаковых файлов в 30КБ RAR или 230КБ ZIP-архив) [18, 201 c.].

Trojan-Notifier - оповещение об успешной атаке.

Троянцы данного типа предназначены для сообщения своему "хозяину" о зараженном компьютере. При этом на адрес "хозяина" отправляется информация о компьютере, например, IP-адрес компьютера, номер открытого порта, адрес электронной почты и т.п. Отсылка осуществляется различными способами: электронным письмом, специально оформленным обращением к веб-странице "хозяина", ICQ-сообщением.

Данные троянские программы используются в многокомпонентных троянских наборах для извещения своего "хозяина" об успешной инсталляции троянских компонент в атакуемую систему.

На рисунке 8 показана схема классификации вредоносного программного обеспечения (троянские вирусы)

Рисунок 8 - Классификация троянских программ



3. Реализация разработки подсистемы защиты информации от вредоносного программного обеспечения

3.1 Разработка совершенствования подсистемы защиты информации от вредоносного программного обеспечения

Во время изучения структуры организации ООО «СтройСпецКомплект» были изучены и разработаны средства по совершенствованию подсистемы защиты информации от вредоносного программного обеспечения, а именно

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

Особенности работы антивирусных программ.

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

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

При работе с антивирусными программами необходимо знать некоторые понятия:

Ложное срабатывание - детектирование вируса в незараженном объекте (файле, секторе или системной памяти).

Пропуск вируса - недетектирование вируса в зараженном объекте.

Сканирование по запросу - поиск вирусов по запросу пользователя. В этом режиме антивирусная программа неактивна до тех пор, пока не будет вызвана пользователем из командной строки, командного файла или программы-расписания.

Сканирование налету - постоянная проверка на вирусы объектов, к которым происходит обращение (запуск, открытие, создание и т. п.). В этом режиме антивирус постоянно активен, он присутствует в памяти "резидентно".

Классификация антивирусных программ.

Самыми популярными и эффективными антивирусными программами являются антивирусные сканеры, CRC-сканеры (ревизоры). Существуют также антивирусы блокировщики и иммунизаторы.

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

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

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

Сканеры также делятся на "резидентные" (мониторы), производящие сканирование "на лету", и "нерезидентные", обеспечивающие проверку системы только по запросу. Как правило, "резидентные" сканеры обеспечивают более надежную защиту системы, поскольку они немедленно реагируют на появление вируса, в то время как "нерезидентный" сканер способен опознать вирус только во время своего очередного запуска.