Утилиты первой категории предоставляют возможность обнаружить ошибки, связанные с безопасностью, во время компиляции приложения. Обычно такие утилиты встраиваются в сам компилятор. Примером может служить опция /analyze для Microsoft Visual C++ Compiler, кроме того Microsoft распространяет ПО PREfast for Drivers, которое позволяет находить характерные для разработки драйверов уязвимости, которые не способен обнаружить компилятор.[7]

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

Инструменты автоматизированного аудита исходного кода, как очевидно из названия, сканируют код приложения и выявляют потенциально опасные места без участия человека. В настоящее время на рынке присутствует большое количество программных решений данного класса. Из наиболее популярных можно отметить Coverity[8] (см. рисунок 1) и HP Fortify среди коммерческих, а также RATS и CodeSpy среди бесплатных.

Рисунок 1. Работа программы Coverity Security Library.

Оценка метода.

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

НЕ нашли? Не то? Что вы ищете?

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

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

Принцип «черного ящика».

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

Ручное тестирование.

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

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

Автоматизированное тестирование (фаззинг).

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

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

Оценка метода.

К преимуществам тестирования по принципу «черного ящика» относят:

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

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

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

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

Двоичный анализ.

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

Рисунок 2. Скриншот из программы IDA Pro.

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

К инструментам, использующимся в процессе двоичного анализа, относятся дизассемблеры, декомпиляторы и отладчики. Дизассемблеры переводят машинный код в список инструкций на языке ассемблера. Наиболее известным продуктом и безусловным лидером в данной категории является разработка наших соотечественников IDA Pro[9].

Декомпиляторы выполняют схожую задачу, однако выделяют в коде более высокоуровневые конструкции, например, ветвления и циклы. Восстановить изначальный код невозможно, ведь в процессе компиляции программы теряется значительная часть информации: названия переменных и функций, комментарии, и даже некоторые методы и структуры, поэтому декомпиляторы чаще используют для языков, которые транслируются в промежуточный байт-код, например, C# или Java. Тем не менее, в последнее время появились подходящие для практического применения декомпиляторы для C и C++,. Примером может служить еще одна отечественная разработка, Hex-Rays Decompiler.

Отладчик – это инструмент динамического анализа. Такая программа позволяет управлять состоянием процесса, создавать точки останова, производить пошаговое выполнение, а также в реальном времени наблюдать содержимое регистров процессора и оперативной памяти. К инструментам данного класса относятся бесплатно распространяемые WinDBG и GDB.

Автоматизированный двоичный анализ.

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

Оценка метода.

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

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

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

Фаззинг. Определение.

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

Впервые работа на данную тему была опубликована в 1988 году профессором Университета штата Висконсин Бартоном Миллером. Он создал простейший фаззер параметров командной строки для программ ОС UNIX. Тем не менее, долгое время технология была неизвестной для большинства специалистов и лишь в последние годы получила значительное распространение. В настоящий момент, фаззинг внедряется в качестве обязательного этапа в процесс разработки программного обеспечения.

Этапы фаззинга.

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

Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5