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

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

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

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

Оба фрагмента кода используют функцию strcpy() для копирования данных в буфер, расположенный в стеке. Применять strcpy() при программировании на C/C++ обычно не рекомендуется, поскольку эта функция не проверяет границы буфера, в который копируются данные. В результате, если программист не позаботится о собственных проверках, может произойти переполнение, при котором данные окажутся за пределами предназначенного для них контейнера. Первый пример не вызовет переполнения буфера, поскольку размер строки test с учётом завершающего нулевого байта равен и всегда будет равен 5, а значит, он меньше десятибайтового буфера, в который выполняется копирование. Во втором случае переполнение буфера может произойти или не произойти в зависимости от размера аргумента командной строки, предоставленного пользователем. Ключевой вопрос здесь состоит в том, управляет ли пользователь входными данными, передаваемыми уязвимой функции. Простейший анализ кода пометил бы строку с strcpy() в обоих примерах как потенциально уязвимую. Однако, чтобы понять, действительно ли существует условие, пригодное для эксплуатации, требуется проследить значения входных данных. Это не означает, что анализ исходного кода не может быть ценным инструментом для исследователей безопасности. Анализ исходного кода следует проводить всякий раз, когда код доступен. Однако в зависимости от вашей роли и точки зрения доступ к сведениям такого уровня нередко отсутствует.

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

Средства анализа исходного кода обычно относятся к одной из трёх категорий: средства проверки во время компиляции, обозреватели исходного кода или автоматизированные средства аудита исходного кода. Средства проверки во время компиляции ищут уязвимости по мере компиляции исходного кода. Обычно они интегрированы с компиляторами, однако пытаются выявлять именно проблемы безопасности, а не неполадки в работе приложения. Параметр компилятора /analyze в Microsoft Visual C++ - пример средства проверки во время компиляции.^[5] Microsoft также предоставляет PREfast for Drivers,^[6] способный выявлять различные классы уязвимостей, характерные для разработки драйверов и способные остаться незамеченными компилятором.

Обозреватели исходного кода - это инструменты, предназначенные для помощи в ручном изучении и анализе исходного кода. Средства этого класса позволяют проверяющему выполнять расширенный поиск по коду, а также перечислять перекрёстные ссылки между различными местами и переходить по ним. Например, с помощью такого инструмента проверяющий может найти все вызовы strcpy(), пытаясь выявить потенциальные уязвимости переполнения буфера. Cscope^[7] и Linux Cross-Reference^[8] - популярные обозреватели исходного кода.

Автоматизированные средства аудита исходного кода предназначены для сканирования исходного кода и автоматического выявления потенциально проблемных участков. Как и большинство средств безопасности, автоматизированные средства аудита исходного кода существуют и в коммерческом, и в бесплатном исполнении. Более того, эти средства обычно ориентированы на конкретные языки программирования, поэтому, если целевая программа создана с использованием разных языков, может потребоваться несколько инструментов. Среди коммерческих предложений существуют продукты таких поставщиков, как Fortify,^[9] Coverity,^[10] KlocWork,^[11] GrammaTech^[12] и других. В таблице 1.1 перечислены некоторые популярные бесплатные инструменты, языки, которые они проверяют, и поддерживаемые ими платформы.

Таблица 1.1. Бесплатные средства аудита исходного кода

Ссылки из таблицы: RATS (Rough Auditing Tool for Security); ITS4; Splint; Flawfinder; Jlint; CodeSpy.

Важно помнить, что никакое средство автоматизации никогда не заменит навыков опытного исследователя безопасности. Такие средства всего лишь упорядочивают непомерно трудную задачу изучения тысяч строк исходного кода и помогают сберечь время и избежать разочарований. Отчёты, создаваемые подобными средствами, всё равно должен проверить опытный аналитик, чтобы выявить ложные срабатывания, а затем разработчики, чтобы фактически внести исправление. Рассмотрим, например, следующий образец вывода, созданного Rough Auditing Tool for Security (RATS) при обработке приведённого ранее в этой главе искусственного примера уязвимого кода. RATS указывает на две потенциальные проблемы безопасности. Он обращает внимание на использование буфера фиксированного размера и на потенциальную небезопасность strcpy(). Однако он не утверждает однозначно, что уязвимость существует. Средство лишь привлекает внимание пользователя к потенциально небезопасным участкам кода и полагается на него в решении вопроса о том, действительно ли код небезопасен.

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

• Охват. Благодаря доступности всего исходного кода его анализ обеспечивает полный охват. На предмет потенциальных уязвимостей можно проверить все возможные пути выполнения кода. Разумеется, это может приводить к ложным срабатываниям, поскольку некоторые пути могут быть недостижимы во время исполнения программы.

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

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

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

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

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

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

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

Фаззинг по большей части является методом полного перебора, и недостаток изящества он компенсирует простотой и эффективностью. В главе 2 «Что такое фаззинг?» мы дадим этому термину определение и подробно его разберём. Если выразиться кратко, фаззинг состоит в том, чтобы обрушить на цель всё что угодно и следить за результатами. Большинство программ рассчитано на работу с определёнными входными данными, но должно быть достаточно устойчивым, чтобы корректно восстанавливаться после получения аномальных входных данных. Рассмотрим простую веб-форму, показанную на рисунке 1.1.

Рисунок 1.1. Простая веб-форма

Разумно предположить, что поле Name должно получать строковое значение, а поле Age - целое число. Что случится, если пользователь случайно перепутает входные значения и введёт строку в поле возраста? Будет ли строковое значение автоматически преобразовано в целое число на основе ASCII-кодов символов? Появится ли сообщение об ошибке? Произойдёт ли аварийное завершение приложения? Фаззинг стремится отвечать на эти вопросы посредством автоматизированного процесса. Исследователю не требуется знать внутреннее устройство приложения, поэтому он проводит тестирование чёрного ящика. Вы стоите в стороне, бросаете в цель камни и ждёте звона разбитого окна. В этом смысле фаззинг относится к категории чёрного ящика. Однако на протяжении книги мы покажем, как сделать фаззинг методом полного перебора более хирургически точным, чтобы камень всякий раз летел прямо в цель; поэтому фаззинг применим и в категории серого ящика.

Тестирование чёрного ящика, хотя оно и не всегда является лучшим подходом, возможно всегда. К его преимуществам относятся следующие:

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

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

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

Несмотря на доступность тестирования чёрного ящика, у него есть некоторые недостатки. К ним относятся следующие:

• Охват. Одна из самых серьёзных трудностей тестирования чёрного ящика - определить, когда следует прекратить проверку и насколько эффективной она была. Подробнее мы рассмотрим эту проблему в главе 23 «Отслеживание работы фаззера».

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

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

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

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

Обратная разработка - хирургически точный метод, в котором применяются такие инструменты, как дизассемблеры, декомпиляторы и отладчики. Дизассемблеры преобразуют нечитаемый машинный код в один из вариантов языка ассемблера, пригодный для восприятия человеком. Существуют различные бесплатные дизассемблеры, но для серьёзной работы по RCE вам, скорее всего, стоит приобрести DataRescue Interactive Disassembler (IDA) Pro,^[16] показанный на рисунке 1.2. IDA - коммерческий дизассемблер, работающий на платформах Windows, UNIX и MacOS и способный анализировать двоичные файлы для широкого спектра архитектур.

Рисунок 1.2. DataRescue IDA Pro

Подобно дизассемблеру, декомпилятор статически анализирует двоичный код и преобразует его в форму, читаемую человеком. Вместо прямого перевода в ассемблерные инструкции декомпилятор пытается получить конструкции языка более высокого уровня, такие как условия и циклы. Декомпиляторы не способны восстановить первоначальный исходный код, поскольку содержавшиеся в нём сведения - комментарии, имена переменных, имена функций и даже базовая структура - не сохраняются при компиляции. Декомпиляторы для языков, компилируемых в машинный код, например C и C++, обычно имеют существенные ограничения и носят преимущественно экспериментальный характер. Boomerang^[17] - пример декомпилятора машинного кода. Декомпиляторы чаще встречаются для языков, компилируемых в некоторую промежуточную форму байт-кода, таких как C#, поскольку в скомпилированном коде сохраняется больше сведений и декомпиляция поэтому обычно успешнее.

В отличие от дизассемблеров и декомпиляторов, отладчики выполняют динамический анализ: открывают целевую программу или присоединяются к ней и следят за её исполнением. Отладчик может показывать содержимое регистров процессора и состояние памяти во время работы приложения. Среди популярных отладчиков для платформы Win32 - OllyDbg,^[18] снимок экрана которого приведён на рисунке 1.3, и Microsoft WinDbg, произносимый как «wind bag».^[19] WinDbg входит в пакет Debugging Tools for Windows^[20] и доступен для бесплатной загрузки с сайта Microsoft. OllyDbg - условно-бесплатный отладчик, разработанный Олегом Ющуком и несколько более удобный для пользователя, чем WinDbg. Оба отладчика позволяют создавать собственные расширения, а для расширения возможностей OllyDbg доступно множество подключаемых модулей сторонних разработчиков.^[21] Для среды UNIX существуют различные отладчики, из которых наиболее популярен и переносим GNU Project Debugger^[22] (GDB). GDB - отладчик командной строки, входящий во многие дистрибутивы UNIX/Linux.

Рисунок 1.3. OllyDbg

Появляется некоторое количество средств, пытающихся автоматизировать процесс RCE с целью выявления потенциальных уязвимостей безопасности в двоичных приложениях. Основные программы представлены как коммерческими, так и бесплатными продуктами и являются либо подключаемыми модулями IDA Pro, либо самостоятельными приложениями. Некоторые из них перечислены в таблице 1.2.

Таблица 1.2. Средства автоматизированного аудита двоичного кода

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

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

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

Недостатки тестирования чёрного ящика включают следующее:

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

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

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

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

Фаззеры также не являются лучшими средствами выявления неудачной логики проектирования. Рассмотрим, например, уязвимость, обнаруженную в Veritas Backup Exec, которая позволяет злоумышленникам удалённо обращаться к реестру сервера Windows для создания, изменения или удаления разделов реестра.^[19] Такой доступ может почти тривиальным образом привести к полной компрометации системы. Эта возможность существует благодаря прослушивающей службе, реализующей интерфейс удалённого вызова процедур (RPC) на конечной точке протокола управления передачей (TCP), которая не требует аутентификации, но принимает команды для манипулирования реестром. Это не было проблемой аутентификации, поскольку по проекту она вообще не требовалась. Скорее, это было неуместное проектное решение, вероятно возникшее из-за неспособности предположить, что злоумышленники захотят потратить время на расшифровку языка описания интерфейсов Microsoft (IDL), применённого для описания целевой процедуры, а затем создать специальную утилиту для взаимодействия с сервером.

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

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

Проблемы повреждения памяти часто приводят к аварийному завершению целевого процесса. Тогда проблему можно распознать по тем же признакам, что и отказ в обслуживании. Однако некоторые проблемы повреждения памяти корректно обрабатываются целевым приложением и никогда не будут распознаны простым фаззером. Рассмотрим, например, уязвимость строки формата, которая может остаться незамеченной, если к целевому процессу не присоединить отладчик. На уровне машинного кода уязвимость строки формата часто сводится к одной нарушающей правила инструкции. Например, на компьютере x86 под управлением Linux признаком атаки на строку формата с %n часто будет сбой на следующей инструкции:

Если фаззер передаёт процессу случайные данные, изредка добавляя запускающие обработку формата символы вроде %n, регистр eax во многих случаях будет содержать не доступный для записи адрес, а какое-либо мусорное слово из стека. Тогда инструкция вызовет сигнал нарушения сегментации SIGSEGV. Если в приложении есть обработчик сигнала SIGSEGV, он может просто завершить этот процесс и создать новый. В некоторых приложениях обработчик сигнала может даже попытаться продолжить исполнение в том же процессе без перезапуска. При уязвимости строки формата это действительно становится возможным, хотя крайне не рекомендуется, поскольку до возникновения сигнала SIGSEGV память могла фактически не быть повреждена. Но что, если наш фаззер этого не обнаружит? Процесс не завершается аварийно, а корректно обрабатывает сбой посредством обработчика сигнала, следовательно, проблемы безопасности нет, верно? Помните, что успешный эксплойт строки формата записывает данные в области памяти, а затем использует эти управляемые участки памяти, чтобы незаметно получить контроль над процессом. Обработчик сигнала не остановит точный эксплойт, поскольку точный эксплойт вообще не вызовет сбоя.

В зависимости от глубины отслеживания цели фаззер может обнаружить такие ситуации, а может и не обнаружить.

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

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

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

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

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

Эта однострочная команда читает случайные данные из устройства Linux urandom, а затем передаёт их на целевой адрес и порт с помощью netcat. Цикл while обеспечивает продолжение процесса, пока пользователь его не прервёт.

Хотите верьте, хотите нет, но в прошлом с помощью этого метода обнаруживали уязвимости, затрагивавшие критически важное программное обеспечение. Какой позор! Трудность по-настоящему случайного фаззинга состоит в восстановлении причины исключения в случае аварийного завершения сервера. Проследить, каким образом 500 000 случайных байтов привели к сбою сервера, бывает мучительно трудно. Чтобы сузить область поиска, следует записывать отправляемый трафик анализатором пакетов. Кроме того, будьте готовы провести немало времени в отладчике и дизассемблере. Отладка разрушения стека таким методом может быть сложной, особенно потому, что стек вызовов будет повреждён. На рисунке 3.1 показан снимок экрана отладчика, присоединённого к корпоративной утилите наблюдения за системой и сетью, которая только что аварийно завершилась под воздействием атаки случайным фаззингом. Можете определить причину сбоя? Вряд ли, если только вы не Нострадамус. Чтобы точно установить причину проблемы, требуется гораздо больше исследований. Обратите внимание, что некоторые данные скрыты ради защиты виновных.

Рисунок 3.1. Что теперь? Дилемма фаззера на основе /dev/urandom

Ручное тестирование протокола, пожалуй, ещё менее сложно, чем метод /dev/urandom. При ручном тестировании протокола никакой автоматизированный фаззер не участвует. Фактически фаззером является сам исследователь. Запустив целевое приложение, исследователь просто вводит неподходящие данные, пытаясь вызвать аварийное завершение сервера или иное нежелательное поведение. Это фаззинг для бедных в самом буквальном смысле, но в прошлом он, безусловно, успешно применялся. Преимущество этого подхода, разумеется, заключается в том, что во время аудита аналитик может опираться на прежний опыт и «внутреннее чутьё». Этот класс фаззинга чаще всего применяется к веб-приложениям.

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

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

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

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

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

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

• FileFuzz^[5] Майкла Саттона. Средство фаззинга форматов файлов для Windows с графическим пользовательским интерфейсом (GUI).

• notSPIKEfile и SPIKEfile^[6] Адама Грина. Средства фаззинга файлов для UNIX: первое не основано на SPIKE, а второе основано.

• PAIMEIfilefuzz^[7] Коди Пирса. Ещё одно средство фаззинга форматов файлов для Windows с GUI, похожее на FileFuzz и построенное поверх каркаса обратной разработки PaiMei. PaiMei подробнее рассматривается далее в книге.

Фаззинг форматов файлов подробнее разбирается в главе 11 «Фаззинг форматов файлов», главе 12 «Фаззинг форматов файлов: автоматизация в UNIX» и главе 13 «Фаззинг форматов файлов: автоматизация в Windows».

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

Преимущества включают следующее:

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

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

К недостаткам фаззинга в памяти относятся следующие:

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

• Воспроизведение. Хотя возникновение исключения может указывать на условие, пригодное для эксплуатации, исследователю всё равно придётся воссоздать исключение удалённо, вне процесса. Это может занять много времени.

• Сложность. Как мы увидим в главе 19 «Фаззинг в памяти» и главе 20 «Фаззинг в памяти: автоматизация», реализовать этот метод фаззинга чрезвычайно сложно.

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

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

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

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

К недостаткам каркасов фаззинга относятся следующие:

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

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

• Время разработки. Проектирование чего-либо полностью универсального и пригодного для повторного использования требует гораздо больше работы, чем создание одноразового приложения для конкретного протокола. Эта работа почти всегда означает более длительную разработку.

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

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

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

Идентификаторы блоков - это значения, определяющие тип данных, представленных в двоичном виде. За ними могут следовать данные переменной или фиксированной длины. В рассмотренном ранее примере AIM заголовок AIM Signon содержал заголовок блока типа информации (0x0001). Это значение определяло тип следовавших данных - в данном случае имя собеседника AOL. С помощью фаззинга можно выявлять другие, возможно недокументированные идентификаторы блоков, которые могут принимать дополнительные типы данных, также пригодные для фаззинга.

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

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

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

Wireshark, ответвление проекта Ethereal,^[4] - популярный анализатор сетевого трафика и средство разбора протоколов с открытым исходным кодом. Хотя это не обязательно библиотека, поверх которой можно что-либо строить, средство, несомненно, пригодится и на этапе исследования, и при отладке создаваемого фаззера. Wireshark предоставляет множество средств разбора с открытым исходным кодом, которые также часто полезны как справочный материал. Захваченный трафик, для которого имеется средство разбора, отображается как последовательность пар «поле - значение», а не как блок необработанных байтов. Прежде чем погружаться в ручной анализ протокола, всегда благоразумно сначала выяснить, что о нём скажет Wireshark. Краткий список доступных средств разбора можно найти в репозитории Subversion Wireshark, а именно в каталоге epan\dissectors.^[5]

libdasm и libdisasm - свободно доступные библиотеки дизассемблера с открытым исходным кодом, которые можно встраивать в собственные средства для получения из двоичных потоков дизассемблированного кода в синтаксисе AT&T и Intel. libdasm написана на C, а libdisasm - на Perl. В libdasm также включён интерфейс Python. Хотя дизассемблер не нужен для генерации сетевого трафика, он важен при автоматизации обнаружения сбоев. Обе библиотеки используются на протяжении книги, в частности в главе 12 «Фаззинг форматов файлов: автоматизация в UNIX», главе 19 «Фаззинг в памяти», главе 20 «Фаззинг в памяти: автоматизация», главе 23 «Отслеживание работы фаззера» и главе 24 «Интеллектуальное обнаружение сбоев».

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

LibPCAP и совместимая с Microsoft Windows библиотека WinPCAP^[11] - свободно доступные высокоуровневые библиотеки с открытым исходным кодом, позволяющие легко создавать средства захвата и анализа сети как для UNIX, так и для Microsoft Windows. На этой библиотеке построено множество средств анализа сетевых протоколов, включая упомянутый выше Wireshark.

Metro Packet Library - библиотека C#, предоставляющая абстрагированный интерфейс для работы с IPv4, TCP, UDP и протоколом управляющих сообщений Интернета (ICMP). Она полезна при создании анализаторов пакетов и средств анализа сети. Библиотека подробнее обсуждается и используется в главе 16 «Фаззинг сетевых протоколов: автоматизация в Windows».

Отладка на платформах UNIX по большей части выполняется с помощью системного вызова ptrace() (трассировка процесса). Процесс может использовать ptrace() для управления состоянием регистров, памятью и исполнением другого процесса, а также для перехвата создаваемых им сигналов. Этот механизм применяется при реализации средств, обсуждаемых в главе 8 «Фаззинг переменных среды и аргументов: автоматизация» и главе 12 «Фаззинг форматов файлов: автоматизация в UNIX».

При создании фаззеров могут пригодиться различные расширения Python. Среди них Pcapy, Scapy и PyDbg. Pcapy^[13] - расширение Python, взаимодействующее с LibPCAP/WinPCAP и позволяющее сценариям Python захватывать сетевой трафик. Scapy^[14] - мощное и простое расширение для манипулирования пакетами, которое можно использовать интерактивно или как библиотеку. Scapy способно как создавать, так и декодировать широкий спектр протоколов. PyDbg^[15] - полноценный 32-разрядный отладчик Microsoft Windows на чистом Python, позволяющий легко и изящно инструментировать процессы. Библиотека PyDbg является подмножеством более крупного каркаса обратной разработки PaiMei,^[16] который используется далее в книге, в том числе в главах 19, 20, 23 и 24.

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

Реализация способа генерации данных - лишь часть решения. Не менее важно определить, какие данные генерировать. Например, представим, что мы создаём фаззер для анализа устойчивости IMAP-сервера. Среди множества команд и конструкций IMAP, которые необходимо изучить, находится запрос продолжения команды (CCR), описанный в следующем фрагменте RFC 3501:^[17]

Согласно RFC, любая команда, оканчивающаяся конструкцией {число}, выделенной в оригинале полужирным, указывает, что оставшиеся число байтов команды продолжаются на следующей строке. Это превосходная цель фаззинга, но какими значениями следует проверять поле? Можно ли проверить все возможные числовые значения? Целевой демон, вероятно, принимает значения вплоть до максимального 32-разрядного целого 0xFFFFFFFF (4 294 967 295). Если фаззер выполняет один тестовый случай в секунду, завершение проверки займёт более 136 лет! Даже если встряхнуть фаззер здоровой дозой кофеина и повысить пропускную способность до 100 тестов в секунду, для завершения потребуется почти 500 дней. При такой скорости протокол IMAP может уйти в отставку раньше, чем закончится тестирование. Ясно, что проверить весь диапазон невозможно и необходимо выбрать интеллектуальное подмножество, или выборку, возможных целых значений.

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

Два крайних граничных тестовых случая, 0 и 0xFFFFFFFF, очевидно подходят для нового улучшенного списка целочисленных тестов. Что ещё можно добавить? Возможно, переданное число используется как параметр размера процедуры выделения памяти. Нередко к указанному размеру добавляется место, например для заголовка, нижнего колонтитула или завершающего байта NULL:

С другой стороны, перед выделением памяти указанное значение размера могут уменьшать. Это может происходить, если целевая программа знает, что не будет копировать все указанные данные в новый буфер. Помня, что целочисленные переполнения, то есть сложение с переходом за верхнюю границу диапазона 32-разрядного целого, и целочисленные выходы за нижнюю границу, то есть вычитание с переходом ниже 0, могут впоследствии привести к проблемам безопасности, благоразумно включить приграничные тестовые случаи: 0xFFFFFFFF-1, 0xFFFFFFFF-2, 0xFFFFFFFF-3, …, а также 1, 2, 3, 4 и так далее.

Аналогично к указанному размеру может применяться множитель. Рассмотрим, например, преобразование переданных данных в Unicode. Для этого указанный размер потребуется умножить на 2. Кроме того, можно добавить два байта, чтобы обеспечить завершение NULL. Например:

Чтобы вызвать целочисленное переполнение в этой и подобных ситуациях, в список также пришлось бы включить следующие приграничные тестовые случаи: 0xFFFFFFFF/2, 0xFFFFFFFF/2-1, 0xFFFFFFFF/2-2 и так далее. А как насчёт граничных случаев около результатов деления на 3? Или на 4? Раз уж мы этим занимаемся, почему бы не включить перечисленные выше приграничные случаи и для 16-разрядных целых (0xFFFF)? А для 8-разрядных (0xFF)? Добавим их в список вместе с некоторыми другими разумными вариантами. Теперь список включает:

• MAX32 - 16 <= MAX32 <= MAX32 + 16

• MAX32 / 2 - 16 <= MAX32 / 2 <= MAX32 / 2 + 16

• MAX32 / 3 - 16 <= MAX32 / 3 <= MAX32 / 3 + 16

• MAX32 / 4 - 16 <= MAX32 / 4 <= MAX32 / 4 + 16

• MAX16 - 16 <= MAX16 <= MAX16 + 16

• MAX16 / 2 - 16 <= MAX16 / 2 <= MAX16 / 2 + 16

• MAX16 / 3 - 16 <= MAX16 / 3 <= MAX16 / 3 + 16

• MAX16 / 4 - 16 <= MAX16 / 4 <= MAX16 / 4 + 16

• MAX8 - 16 <= MAX8 <= MAX8 + 16

• MAX8 / 2 - 16 <= MAX8 / 2 <= MAX8 / 2 + 16

• MAX8 / 3 - 16 <= MAX8 / 3 <= MAX8 / 3 + 16

• MAX8 / 4 - 16 <= MAX8 / 4 <= MAX8 / 4 + 16

Здесь MAX32 обозначает максимальное 32-разрядное целое (0xFFFFFFFF), MAX16 - максимальное 16-разрядное целое (0xFFFF), MAX8 - максимальное 8-разрядное целое (0xFF), а диапазон 16 был произвольно выбран как разумная величина. В зависимости от имеющегося времени и результатов вы можете увеличить этот диапазон. Если целевой протокол содержит сотни целочисленных полей, каждая дополнительная целочисленная эвристика увеличивает общее число тестовых случаев в сто раз.

Относитесь к выбранным целочисленным «эвристикам» с долей скептицизма. Эвристика - всего лишь изысканный способ сказать «обоснованная догадка». Более опытные пользователи могут исследовать целевой двоичный файл в дизассемблере и извлечь потенциально интересные целые значения, изучая перекрёстные ссылки на процедуры выделения памяти и копирования данных. Этот процесс тоже можно автоматизировать; данная идея кратко затрагивается в главе 22 «Автоматизированный разбор протоколов».

Мы рассмотрели диапазон разумно выбранных целых значений, которые стоит включить в данные фаззинга, но как насчёт строк? Начнём с древней классики^[20] - «длинной строки»:

При фаззинге строк следует включать и ряд дополнительных последовательностей символов. Сначала нужно добавить другие символы ASCII, например B. Это важно, в частности, при вызове переполнений кучи в Microsoft Windows из-за разного поведения, когда структуры кучи перезаписываются ASCII-значением A и когда значением B. Ещё одна причина важности этого приёма состоит в том, что, хотите верьте, хотите нет, авторы действительно видели промышленное программное обеспечение, специально ищущее и блокирующее длинные строки из символов A. Очевидно, некоторые поставщики осознали силу AAAAAAAAAAAAAAAAA.

Нужно также включить небуквенно-цифровые символы, в том числе пробелы и табуляции. Такие символы часто используются как разделители и ограничители полей. Случайное включение их в создаваемые фазз-строки повышает вероятность частично воспроизвести фаззируемый протокол и тем самым увеличить объём кода, подвергаемого фаззингу. Рассмотрим, например, сравнительно простой протокол HTTP и следующий список небуквенно-цифровых символов:

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

Первая закономерность, которую можно заметить, - множество строк, разделённых переводами строки, представленными на уровне байтов последовательностью 0x0d 0x0a. В каждой строке дополнительно используются различные символы-разделители. Например, в первой строке видно, что для разделения кода ответа применяются пробел ( ), прямая косая черта (/) и точка (.). На последующих строках часто встречается двоеточие (:), отделяющее директивы, такие как Content-Type, Server и Date, от их значений. Дальнейшее изучение обнаруживает, что для разделения полей также используются запятая (,), знак равенства (=), точка с запятой (;) и дефис (-).

При генерации фазз-строк важно включать строки разной длины, разделённые различными разделителями полей, подобными показанным выше. Кроме того, важно увеличивать и длину разделителя. Рассмотрим, например, критическую уязвимость обработки заголовков Sendmail^[21] 2003 года. В этом случае для возникновения пригодного к эксплуатации повреждения памяти требовалась длинная строка из символов <>. Рассмотрим также следующий искусственный фрагмент кода с уязвимостью разбора повторяющегося строкового разделителя:

Этот уязвимый анализатор обрабатывает строку, ожидая найти единственный экземпляр символа-разделителя, то есть двоеточия. Если разделитель найден, сохраняется указатель на его индекс в строке. В противном случае переменная length увеличивается на единицу. В конце цикла вычисленное значение length за вычетом единицы для завершающего NULL и ещё одной единицы для найденного разделителя сравнивается с размером целевого символьного буфера, чтобы убедиться в наличии достаточного места для последующего вызова strcpy(). Эта логика правильно обрабатывает ожидаемые строки вроде name:pedram amini. Для такой строки анализатор вычислит length как 16, определит, что места недостаточно, и пропустит strcpy(). А как насчёт строки name::::::::::::::::::::::pedram? Для неё вычисленное значение length равно 10, поэтому условная проверка проходит и выполняется strcpy(). Однако фактическая длина строки, используемой в strcpy(), равна 32, и будет вызвано переполнение стека.

Уязвимости строк формата - сравнительно простой для обнаружения класс ошибок, и создаваемые фаззером данные должны их учитывать. Уязвимость строки формата можно выявить любым маркером формата, например %d, отображающим десятичное число по основанию 10, или %08x, отображающим шестнадцатеричное число по основанию 16. Для фаззинга лучше выбрать маркеры %s или %n, либо оба. Они дают более высокую вероятность вызвать обнаружимую ошибку, например нарушение доступа к памяти. Большинство маркеров строки формата приводит к чтению памяти из стека и вряд ли вызовет сбой нижележащего уязвимого кода. Маркер %s вызывает больше операций чтения памяти, поскольку стек разыменовывается в поиске байта NULL, обозначающего завершение строки. В большинстве случаев маркер %n даёт наибольшую вероятность вызвать сбой. Список эвристик фаззинга должен включать длинные последовательности %s%n.

Ещё одна тонкость, за которой следует следить, - преобразования и трансляции символов, особенно связанные с их расширением. Например, шестнадцатеричные значения 0xFE и 0xFF в UTF16 расширяются до четырёх символов. Недостаточный учёт такого расширения в коде разбора - распространённая область обнаружения уязвимостей.

Преобразования символов также могут быть реализованы неправильно, особенно при обработке редко встречающихся или используемых граничных случаев. Например, Microsoft Internet Explorer был затронут такой проблемой при преобразовании UTF-8 в Unicode.^[23] Суть состояла в том, что при определении размера динамически выделяемой памяти для преобразованного буфера процедура преобразования неправильно учитывала пяти- и шестибайтовые символы UTF-8. Однако собственно процедура копирования данных правильно обрабатывала пяти- и шестибайтовые символы UTF-8, что приводило к переполнению буфера в куче. Список эвристик фаззинга должен включать эти и другие столь же вредоносные последовательности символов.

Уязвимости обхода каталогов затрагивают как сетевые демоны, так и веб-приложения. Распространено ошибочное убеждение, что они ограничены исключительно веб-приложениями. Уязвимости обхода каталогов действительно широко распространены в веб-приложениях, но этот вектор атаки может присутствовать и в проприетарных сетевых протоколах, и в других местах. Согласно статистике Mitre CVE за 2006 год, хотя со временем число уязвимостей обхода каталогов несколько уменьшилось, они остаются пятым по распространённости классом уязвимостей, обнаруживаемых в программных приложениях.^[24] Эта статистика охватывает и веб-приложения, и традиционные клиент-серверные приложения. В Open Source Vulnerability Database (OSVDB) можно увидеть выборку множества уязвимостей обхода каталогов, поднимавших свои уродливые головы на протяжении многих лет.^[25]

Рассмотрим, например, программу резервного копирования Computer Associates BrightStor ARCserve. BrightStor предоставляет специальный интерфейс журналирования по TCP через демон caloggerd. Хотя протокол не документирован, простой анализ пакетов показывает, что имя файла журнала фактически указывается внутри сетевого потока данных. Добавив перед переданным именем файла модификаторы обхода каталогов, злоумышленник может указать произвольный файл, в который будет записано произвольное журнальное сообщение. Поскольку демон журналирования работает с привилегиями суперпользователя, эту уязвимость можно тривиально эксплуатировать. Например, в системах UNIX в файл /etc/passwd можно добавить нового суперпользователя. На момент написания эта проблема оставалась уязвимостью нулевого дня, а её публичное раскрытие было запланировано на июль 2007 года. Список эвристик фаззинга должен включать такие модификаторы обхода каталогов, как ../../ и `....`.

Подобно уязвимостям обхода каталогов, уязвимости внедрения команд обычно связывают с веб-приложениями, а точнее со сценариями CGI. И снова распространено ошибочное мнение, будто этот класс ошибок присущ только веб-приложениям: они могут затрагивать сетевые демоны через документированные и проприетарные протоколы. Любая цель, веб-приложение или сетевой демон, передающая неотфильтрованные либо неправильно отфильтрованные пользовательские данные таким вызовам API, как exec() или system(), потенциально открывает уязвимость внедрения команд. Рассмотрим следующий упрощённый фрагмент кода Python:

В обычных обстоятельствах сервер получает системный путь, определяет список файлов по этому пути и отправляет его клиенту. Однако из-за отсутствия фильтрации входных данных можно указать определённые символы, позволяющие выполнить дополнительные команды. В системах UNIX к ним относятся &&, ; и |. Например, аргумент var/lib ; rm -rf / преобразуется в ls /var/lib ; rm -rf / - команду, способную доставить администратору затронутой системы значительные неприятности. Список эвристик фаззинга также должен включать эти символы.

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

За исключением самых оберегаемых пользователей Windows, каждый когда-либо сталкивался с программой, которой требовались аргументы командной строки. Аргументы командной строки передаются программе и доступны через указатель argv, объявляемый в функции main программ на C. В main также передаётся переменная argc. Она содержит число аргументов, переданных программе, плюс единицу, поскольку имя программы в том виде, в каком она была вызвана, также считается аргументом. Рассмотрим несколько простых примеров.

Если несколько раз запустить программу с разными аргументами, будут получены результаты, показанные на рисунке 7.1.

Рисунок 7.1. Демонстрация хранения аргументов командной строки

Ещё один способ ввести переменные в процесс - использовать переменные среды. Каждый процесс содержит так называемую среду, состоящую из переменных среды. Переменные среды - глобальные значения, определяющие поведение приложений. Пользователь может задавать и отменять их, но обычно стандартные значения устанавливаются при установке пакета программного обеспечения или администратором. Большинство командных интерпретаторов заставляет все новые процессы наследовать текущую среду. Оболочка command.com - пример командного интерпретатора Windows. В системах UNIX обычно имеется несколько командных интерпретаторов, таких как sh, csh, ksh и bash.

К часто используемым переменным среды относятся HOME, PATH, PS1 и USER. Эти значения содержат соответственно домашний каталог пользователя, текущий путь поиска исполняемых файлов, приглашение командной строки и текущее имя пользователя. Данные переменные достаточно стандартны, но многие другие распространённые переменные, в том числе создаваемые поставщиками программного обеспечения, используются только при работе их приложений. Когда приложению требуется узнать определённую переменную, оно просто вызывает функцию getenv, указав имя переменной в качестве аргумента. Хотя процессы Windows имеют среду так же, как приложения UNIX, мы в основном сосредоточимся на UNIX, поскольку в Windows отсутствует понятие приложений setuid, которые непривилегированный пользователь может запустить и которые получают привилегии во время исполнения. На рисунке 7.2 показано, как может выглядеть типичная среда UNIX. Текущую среду оболочки bash можно просмотреть командой set.

Рисунок 7.2. Пример некоторых переменных среды, используемых оболочкой bash

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

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

Другой доступный метод требует отладчика. С помощью GDB можно установить точку останова внутри функции getenv и вывести первый аргумент. Ниже приведён пример автоматизации этого процесса в Solaris 10 посредством сценарных возможностей GDB:

Если использованные в этом сеансе GDB команды вам незнакомы, их можно кратко описать так:

• Команда break устанавливает точку останова на заданной функции или адресе. Здесь она заставляет исполнение программы остановиться внутри вызова getenv.

• Команда commands задаёт действия, выполняемые при достижении точки останова. В данном случае мы предписываем работать без сообщений и вывести значение регистра i0 как строку с помощью x/s. На SPARC регистр i0 содержит первый аргумент вызываемой функции.

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

Этот метод немедленно показывает список из 11 переменных среды, запрашиваемых программой /usr/bin/id. Обратите внимание, что метод должен работать во всех системах, однако потребуется изменить имя разыменовываемого регистра, поскольку разные архитектуры используют для регистров разные мнемоники. Например, на x86 можно выводить $eax, на SPARC - $i0, а на MIPS - $a0.

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

Вспомните, что в предыдущем разделе «Перечисление переменных среды» мы кратко упомянули предварительную загрузку библиотек; она также полезна для автоматизированного фаззинга. Чтобы получить значение переменной среды, программа должна вызвать функцию getenv. Если перехватить getenv и возвращать длинные строки при всех её вызовах, даже не потребуется знать список используемых переменных: можно подвергнуть фаззингу каждую, перехватывая все вызовы getenv. Это очень полезно при быстрой проверке небезопасного использования переменных среды.

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

Следующая тема - предварительная загрузка библиотек. Она предоставляет простой способ перехватывать функции, используя компоновщик операционной системы, чтобы фактически заменять их функциями, предоставленными пользователем. Хотя конкретные детали различаются от системы к системе, общая идея одинакова. Обычно пользователь задаёт определённой переменной среды путь к скомпилированной им библиотеке. Затем библиотека загружается при исполнении программы. Если она содержит символы, дублирующие символы программы, вместо исходных используются библиотечные. Говоря о символах, мы прежде всего имеем в виду функции. Например, если пользователь создаст библиотеку с функцией strcpy и предварительно загрузит её при запуске двоичного файла, тот вызовет пользовательскую версию strcpy вместо системной. У этого есть множество законных применений, например обёртывание вызовов для профилирования и аудита. Есть и применения при поиске уязвимостей. Рассмотрим использование обёртывания или полной замены процедуры getenv, запрашивающей значения переменных среды.

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

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

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

При исполнении /usr/bin/target все вызовы getenv будут использовать нашу изменённую функцию.

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

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

Первым модулем, разработанным после завершения базового механизма и вспомогательных функций, стал фаззер argv[0]. Набор тестов из нескольких двоичных файлов с известными уязвимостями переполнения и строк формата в argv[0], а также нескольких безопасно написанных приложений использовался в разных операционных системах, включая QNX, Linux и AIX. Этот набор помог устранить мелкие ошибки и подтвердить точность результатов.

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

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

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

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

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

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

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

Ниже приведена простая реализация подхода с fork, исполнением и ожиданием:

Следующий фрагмент кода C показывает, как можно создать процесс посредством fork и следить за интересными сигналами, даже если приложение обрабатывает их внутри. Этот сокращённый пример используется и в notSPIKEfile, и в SPIKEfile - двух средствах фаззинга файлов, обсуждаемых в главе 12 «Фаззинг форматов файлов: автоматизация в UNIX».

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

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

При фаззинге веб-приложений узкое место обычно возникает из-за передачи сетевых пакетов от фаззера к цели. Рассмотрим процесс загрузки веб-страницы из удалённого местоположения. Когда вы просматриваете веб-страницу, скорость её отображения определяется скоростью трёх переменных: вашего компьютера, серверов, на которых находится страница, и интернет-соединения между ними. Вы управляете только первой из трёх переменных - локальной машиной. Поэтому при фаззинге веб-приложений важно ускорить сетевой трафик, устранив остальные две переменные. Когда возможно, вместо запуска целевого приложения на удалённом сервере разместите его локально, чтобы пакетам вообще не приходилось проходить через сеть. В большинство настольных операционных систем, таких как Windows XP^[10] или Linux, встроены веб-серверы, поэтому обычно целевое приложение можно установить и настроить на локальной машине.

Приложение виртуальной машины (VM), такое как VMWare^[11] или Microsoft Virtual Machine,^[12] также может быть полезным средством при фаззинге веб-приложений. Целевое веб-приложение можно запустить в экземпляре VM, а фаззер - локально. Такая конфигурация даёт несколько преимуществ, которых нет при локальном запуске целевого приложения. Во-первых, объём потребляемых целью ресурсов лучше контролируется через VM. Это гарантирует, что фаззинг не поглотит все ресурсы машины. Кроме того, сетевой трафик, приводящий к сбоям системы и атакам отказа в обслуживании, не затронет локальную машину с фаззером. В конце концов, именно такие исключения мы пытаемся обнаружить, а сделать это трудно, если машина постоянно зависает.

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

• веб-страницы;

• каталоги;

• методы, поддерживаемые страницами;

• веб-формы;

• пары «имя - значение»;

• скрытые поля;

• заголовки;

• файлы cookie.

Самый простой и наименее эффективный способ выявления перечисленных входных данных состоит в том, чтобы просто просматривать веб-сайт в браузере и изучать исходный код страниц. В исходном коде можно искать входные данные, включённые в веб-формы. Обязательно ищите скрытые поля (input type="hidden"), поскольку ленивые разработчики приложений иногда используют их как средство обеспечения безопасности за счёт сокрытия. Они могут полагать, что вы не станете проверять такие поля, поскольку на странице они не видны непосредственно. Очевидно, это крайне слабая мера контроля, так как скрытые поля всегда можно увидеть в исходном коде страницы.

При выявлении входных данных с помощью веб-браузера вы не сможете увидеть заголовки запросов и ответов. Например, вы не увидите структуру файлов cookie, передаваемых серверу приложений, поскольку они включены в заголовки HTTP и автоматически передаются браузером. Для просмотра необработанных запросов HTTP всегда можно воспользоваться анализатором сетевых протоколов, например Wireshark.^[32]

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

Простой, но мощный веб-паук - утилита wget.^[33] Хотя первоначально она была разработана для операционной системы UNIX, существуют и версии wget для платформы Win32.^[34] Ещё один бесплатный веб-паук, который мы рекомендуем, входит в состав WebScarab.^[35] Проект WebScarab представляет собой набор предоставляемых Open Web Application Security Project (OWASP) инструментов, полезных при анализе веб-приложений. В числе многочисленных утилит WebScarab есть веб-паук, который можно использовать для автоматического выявления URL во всём приложении. Другой полезный инструмент WebScarab - прокси-сервер, удобный при ручном аудите страниц. Если настроить веб-браузер на использование прокси WebScarab, он будет записывать все необработанные запросы и ответы во время просмотра приложения. В него даже входит самый простой веб-фаззер, но в следующей главе мы обсудим, как создать более мощный.

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

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

На рисунке 10.3 показан базовый запрос WebFuzz. Запрос состоит из следующих полей:

• Host. Имя или IP-адрес целевой машины является обязательным полем. Нельзя подвергать веб-приложение фаззингу, не сообщив WebFuzz, куда отправлять запрос. Это поле не подлежит фаззингу.

• Port. Хотя по умолчанию веб-приложения работают на TCP-порту 80, с тем же успехом они могут работать на любом TCP-порту. Веб-приложения, предназначенные для предоставления консоли администрирования через веб-интерфейс, нередко работают на другом порту, чтобы не мешать основному веб-серверу. Как и поле имени узла, поле порта сообщает WebFuzz, куда отправлять запрос, и фаззингу не подлежит.

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

• Request Headers. Здесь начинается самое интересное. При использовании веб-браузера конечный пользователь управляет целевым узлом, портом и URI запроса, но не всеми разнообразными заголовками. Мы намеренно сохранили все компоненты запроса в одном редактируемом текстовом поле, поскольку хотим дать конечному пользователю возможность управлять каждым аспектом запроса. Запрос можно построить вручную, просто введя желаемый запрос в поле Request Headers. Если же вы предпочитаете решение с графическим интерфейсом, заголовки можно также собрать из списка стандартных заголовков в контекстном меню, как показано на рисунке 10.3. Наконец, если требуется базовый запрос веб-страницы по умолчанию, в контекстном меню можно выбрать Default Headers.

Рисунок 10.3. Запрос WebFuzz

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

Статические списки представляют собой фаззинговые переменные, получаемые из заранее определённого списка данных. Примером статического списка могут служить фаззинговые данные для выявления уязвимостей XSS. Составляется заранее определённый список различных входных значений, способных привести к уязвимостям XSS, например <script>alert('XSS')</script>, а затем данные построчно внедряются в запрос. Статические списки намеренно хранятся во внешних текстовых файлах ASCII, чтобы пользователи могли изменять переменные без повторной компиляции приложения.

Генерируемые фаззинговые переменные, напротив, создаются заранее определёнными алгоритмами, которые могут принимать данные от пользователя. Примером генерируемой фаззинговой переменной служит переменная Overflow. Для переполнения пользователь может задать используемый текст, его длину и число повторений. На рисунке 10.4 показано стандартное всплывающее окно, позволяющее изменять входные данные переменной переполнения.

Рисунок 10.4. Фаззинговая переменная Overflow

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

WebFuzz перехватывает и архивирует все полученные ответы в необработанном формате. Сохранение полного необработанного ответа позволяет гибко отображать ответы в различных форматах. В частности, мы даём пользователю возможность показывать необработанные результаты или просматривать HTML в элементе управления веб-браузера. На рисунке 10.5 показан необработанный ответ, а на рисунке 10.6 - те же данные в веб-браузере. Это важно, поскольку признаки существующих уязвимостей могут проявляться в различных формах. Например, заголовки могут содержать код состояния вроде 500 - Internal Error, указывающий на возможный отказ в обслуживании. В другом случае сама веб-страница может показать пользовательское сообщение об ошибке, свидетельствующее о возможности внедрения SQL. Такую ошибку будет легче увидеть после интерпретации HTML браузером.

Рисунок 10.5. Необработанный ответ

Рисунок 10.6. Ответ в формате HTML

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

WebFuzz требует, чтобы пользователь построил необработанный запрос HTTP, но как выявить подходящие запросы для данного веб-приложения? Какие веб-страницы существуют? Какие переменные способны принимать эти страницы и как следует передавать переменные? В предыдущей главе мы обсуждали, как выявлять входные данные вручную или с помощью анализаторов трафика, веб-пауков и прокси. Прежде чем продолжить, мы хотим представить подключаемый модуль веб-браузера, который может пригодиться при работе с WebFuzz, когда требуется выявить необработанный запрос для отдельной веб-страницы. Проект LiveHTTPHeaders^[6] предоставляет удобный инструмент для выявления необработанных запросов HTTP в веб-браузерах на основе Mozilla. На рисунке 10.7 показан использование LiveHTTPHeaders для отображения всех запросов и связанных с ними ответов на боковой панели Firefox. Приятное преимущество этого подхода состоит в том, что запрос можно перехватить, а затем вырезать и вставить непосредственно в WebFuzz, ускорив создание фаззингового запроса. Существуют и другие подключаемые модули браузеров, например Tamper Data^[7] или Firebug,^[8] которые также являются расширениями Firefox, а также Fiddler,^[9] надстройка браузера Internet Explorer, однако благодаря простоте нашим любимым средством остаётся LiveHTTPHeaders.

Рисунок 10.7. LiveHTTPHeaders

Итак, довольно теории; настало время самого интересного. Засучим рукава и создадим фаззер веб-приложений.

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

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

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

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

Обычно обход выполняется отправкой последовательности символов ../, позволяющей перейти в каталог более высокого уровня. Символы обхода также часто кодируют в URL, чтобы обойти базовые фильтры обнаружения. Если просмотр каталогов разрешён, этого может оказаться достаточно, однако обычно требуется также добавить имя существующего файла. При проверке атаки обхода каталогов рекомендуется добавлять имя файла, который по умолчанию существует на целевом сервере. Например, в системе Windows удачным выбором будут boot.ini или win.ini, поскольку это легко узнаваемые при обнаружении файлы ASCII, существующие во всех современных операционных системах Windows.

Начнём с простой атаки обхода каталогов в Trend Micro Control Manager,^[11] вызванной неправильной проверкой входных данных в параметре IMAGE страницы rptserver.asp. Мы воспользуемся WebFuzz для отправки запроса GET странице rptserver.asp, но заменим допустимый параметр IMAGE фаззинговой переменной [Traversal], за которой следует известный файл, в данном случае win.ini. По результатам на рисунке 10.8 видно, что обход каталогов действительно раскрывается уже после одной последовательности обхода.

Рисунок 10.8. Обход каталогов в Trend Micro Control Manager

Попробуем другой пример, но на этот раз немного усложним задачу. Уязвимость в Ipswitch Imail Web Calendaring^[12] показала нам, что иногда для обнаружения обхода каталогов необходимо также запросить то, чего не существует. В данном случае было обнаружено, что уязвимость обхода каталогов возникает при передаче последовательности обхода несуществующей странице JSP. И снова испытаем WebFuzz (см. рисунок 10.9).

Чтобы проверить эту конкретную уязвимость, мы передадим серверу метод GET, запрашивающий несуществующую веб-страницу blah.jsp, затем последовательность обхода и, наконец, распространённый файл boot.ini. Рисунок 10.9 показывает, что требуется несколько запросов, но после пяти последовательностей обхода... как вы уже догадались, уязвимость раскрывается.

Рисунок 10.9. Обход каталогов в Ipswitch Imail Web Calendaring

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

Чтобы показать применение WebFuzz для обнаружения уязвимостей переполнения, воспользуемся простым примером. Что может быть проще, чем переполнение в Simple Web Server компании PMSoftware?^[13] В данном случае достаточно отправить серверу длинный запрос GET. Поэтому мы отправим следующий запрос, включающий фаззинговую переменную переполнения:

Сначала не происходит ничего, кроме ошибки 404 - Page Not Found, но, как видно на рисунке 10.10, после запроса номер 10 WebFuzz больше не получает никаких ответов. Почему?

Рисунок 10.10. Переполнение буфера в Simple Web Server

Ответ вскоре становится очевиден, когда мы смотрим на сервер, где работал Simple Web Server: там появляется всплывающее сообщение, показанное на рисунке 10.11.

Рисунок 10.11. Сообщение Simple Web Server об ошибке

Это недобрый знак, по крайней мере для Simple Web Server. Вместе с закрытием сообщения об ошибке закрывается и приложение. Да, по меньшей мере мы получили атаку DoS. А есть ли также возможность выполнения кода? Ответ содержится на рисунке 10.12, где подключённый отладчик показывает, что регистр EIP находится под нашим управлением, а значит, выполнение кода будет возможно.

Рисунок 10.12. Переполнение в Simple Web Server

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

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

Атака внедрения SQL в поле имени пользователя на экране входа Ipswitch Whatsup Professional (SP1)^[14] позволяла злоумышленникам полностью обходить защиту, изменяя пароль администратора. Но как её обнаружить? С помощью LiveHTTPHeaders легко увидеть, что параметры имени пользователя и пароля передаются странице Login.asp в запросе POST, как показано ниже:

Теперь, когда нам известен правильный формат запроса, можно составить следующий фаззинговый запрос:

Стандартное сообщение об ошибке при неудавшейся попытке входа выглядит так: There was an error while attempting to login: Invalid user name. Однако при запуске WebFuzz мы обнаруживаем, что в некоторых ответах показываются другие сообщения об ошибках, например приведённое на рисунке 10.13. Из содержимого сообщения об ошибке ясно видно, что предоставленные пользователем данные, по-видимому, отправляются в базу данных.

Рисунок 10.13. Сообщение Ipswitch Whatsup Professional (SP1) об ошибке

Однако это не простая атака внедрения SQL. Распространённые приёмы обхода аутентификации, например ' or 1=1,^[15] здесь не работают, поэтому нам придётся составить допустимый запрос UPDATE, чтобы изменить пароль администратора. На этом этапе для целевых атак внедрения SQL, специфичных для данной цели, нужны сведения о схеме базы данных, но где их получить? Быстрый поиск в Google даёт ответ. Во-первых, сама Ipswitch предоставляет схему для загрузки.^[16]

Это замечательно, но составление содержательного запроса всё равно требует некоторых усилий, а мы заняты созданием фаззеров. Не беспокойтесь: Ipswitch любезно предоставляет искомый запрос. База знаний Ipswitch^[17] фактически содержит следующую команду, сбрасывающую пароль пользователя Admin к значению по умолчанию:

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

XSS повсюду. По данным Mitre, в 2006 году XSS были связаны 21,5 процента всех новых уязвимостей,^[18] и долго искать их не приходится. Более того, sla.ckers.org ведёт на своих форумах постоянно растущую «стену позора XSS»,^[19] и огорчительно видеть, сколько крупных корпораций появляется в этом списке.

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

Для рассмотрения примера фаззинга XSS начнём с заведомо уязвимой веб-страницы. SPI Dynamics размещает по адресу http://zero.webappsecurity.com уязвимое веб-приложение, показанное на рисунке 10.14, для проверки WebInspect, своего сканера веб-приложений.

Рисунок 10.14. Приложение SPI Dynamics Free Bank

Стандартная страница входа содержит две веб-формы. Одна представляет собой форму входа, которая отправляет данные странице login1.asp, а другая отправляет данные странице rootlogin.asp. Именно вторая форма содержит уязвимость XSS. Среди полей ввода этой формы содержимое поля txtName, помеченного как Last Name, будет отражено на запрошенной странице rootlogin.asp. Поскольку пользовательские данные отображаются без какой-либо проверки, приложение уязвимо для атаки XSS.

Распространённый способ проверить существование XSS состоит во вводе простого фрагмента кода JavaScript с функцией alert, который создаст всплывающее окно. Это быстрая и грубая проверка, дающая простой визуальный признак, который не оставляет сомнений в возможности внедрения клиентского JavaScript в целевую страницу. Поэтому для проверки страницы на XSS мы отправим следующий запрос:

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

К счастью, поскольку мы способны внедрять код в страницу, у нас есть множество вариантов. А что, если внедрять JavaScript, который при успешном выполнении будет «звонить домой»? Это сработало бы, но можно применить ещё более простой подход. Клиентский сценарий не обязан быть JavaScript: это может быть любой язык сценариев, который способен интерпретировать браузер. Как насчёт HTML? Это клиентский язык сценариев, и чёрные списки с меньшей вероятностью отфильтруют его, чем JavaScript, поэтому в одном отношении он обеспечивает более строгую проверку XSS. Тег HTML IMG предоставляет очень простую возможность «позвонить домой». Всё, что нужно сделать, - с помощью нашего фаззера внедрить тег HTML IMG, запрашивающий вымышленную страницу у локального веб-сервера. Когда фаззинг завершится, мы проверим журналы сервера, и если увидим запрос, вуаля! Мы будем знать, что цель уязвима для XSS. Давайте попробуем. Прежде всего необходимо добавить в WebFuzz подходящую фаззинговую переменную. Именно поэтому WebFuzz был спроектирован так, чтобы загружать фаззинговые переменные из обычных текстовых файлов. Добавлять новые переменные легко, и повторная компиляция приложения не требуется. Для проведения проверки мы добавим следующую строку в файл xssinjection.txt:

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

Рисунок 10.15. Атака межсайтового скриптинга в действии

Что мы увидим, проверив файлы журналов веб-сервера?

Попался! Запись журнала 404 - Page Not Found была создана, когда WebFuzz внедрил запрос изображения в страницу rootlogin.asp; это неопровержимо доказывает, что страница имеет уязвимость XSS.

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

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

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

1. Подготавливает тестовый пример путём мутации или генерации, о чём подробнее будет сказано далее.

2. Запускает целевое приложение и даёт ему команду загрузить тестовый пример.

3. Следит за сбоями целевого приложения, обычно с помощью отладчика.

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

5. Повторяет процесс.

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

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

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

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

У этого подхода к фаззингу есть несколько недостатков. Во-первых, он крайне неэффективен, поэтому фаззинг одного файла может занять некоторое время. Возьмём, например, простой документ Microsoft Word. Даже пустой документ будет иметь размер приблизительно 20 Кбайт. Для однократного фаззинга каждого байта потребуется создать и запустить 20 480 отдельных файлов. При двух секундах на файл работа займёт более 11 часов, и это лишь для проверки одного байтового значения. А как насчёт остальных 254 вариантов? Эту проблему можно отчасти обойти с помощью многопоточного фаззера, но она наглядно показывает неэффективность чистого фаззинга мутациями. Ещё один способ ускорить этот подход - сосредоточиться исключительно на областях файла, которые с большей вероятностью дадут желаемый результат, например на заголовках файла и полей.

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

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

Если для проверки выбран формат файла без общедоступной документации, вам как исследователю придётся дополнительно изучить спецификацию формата, прежде чем создавать шаблон. Это может потребовать обратной разработки с вашей стороны, однако всегда начинайте с доброго друга Google: возможно, кто-то уже выполнил эту работу за вас. Несколько веб-сайтов, например Wotsit's Format,^[3] служат превосходными архивами официальной и неофициальной документации по форматам файлов. Альтернативный, но дополняющий подход состоит в сравнении образцов файлов данного типа для выявления закономерностей и определения некоторых используемых типов данных. Помните, что эффективность интеллектуального фаззинга непосредственно связана с вашим пониманием формата файла и способностью описать его в общем виде используемому фаззеру. Позднее в книге, создавая SPIKEfile в главе 12 «Фаззинг форматов файлов: автоматизация в UNIX», мы покажем пример реализации фаззера интеллектуального полного перебора.

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

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

• отказ в обслуживании, то есть аварийное завершение или зависание;

• проблемы обработки целых чисел;

• простые переполнения стека или кучи;

• логические ошибки;

• форматные строки;

• состояния гонки.

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

Распространённая ошибка, приводящая к бесконечным циклам, - доверие значениям смещений в файлах, которые задают расположение других блоков внутри файла. Если приложение не проверяет, что это смещение направлено вперёд относительно текущего блока, может возникнуть бесконечный цикл, заставляющий приложение снова и снова обрабатывать один и тот же блок или блоки. В прошлом в ClamAV встречалось несколько подобных проблем.^[5]

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

Этот пример демонстрирует типичное целочисленное переполнение, приводящее к повреждению памяти. Если в файле для значения size указано максимальное беззнаковое 32-разрядное целое число (0xFFFFFFFF), то в строке [2] переменной allocation_size из-за циклического перехода целого числа присваивается ноль. В строке [3] код вызывает выделение области памяти нулевого размера. На этом этапе указатель buffer указывает на область памяти недостаточного размера. В строках [4] и [5] приложение выполняет цикл и копирует большой объём данных, ограниченный исходным значением size, в выделенный буфер, что приводит к повреждению памяти.

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

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

Этот код допускает переполнение стека, если значение size является отрицательным числом. Причина в том, что в сравнении в строке [4] и size, определённая в строке [1], и MAX_ITEMS, определённая в строке [0], рассматриваются как знаковые числа, и, например, -1 меньше 512. Позднее, когда size используется как граница копирования в функции из строки [7], это значение рассматривается как беззнаковое. Например, значение -1 теперь интерпретируется как 4294967295. Разумеется, возможность эксплуатации не гарантирована, но во многих случаях в зависимости от реализации функции readx_from_file уязвимость можно будет эксплуатировать, воздействуя на переменные и сохранённые регистры в стеке.

Эти проблемы хорошо изучены и многократно встречались в прошлом. Типичный сценарий выглядит так: выделяется буфер фиксированного размера в стеке или куче. Позднее при копировании в него данных из файла чрезмерного размера проверка границ не выполняется. В некоторых случаях проверку границ пытаются проводить, но делают это неправильно. При копировании память повреждается, что часто приводит к выполнению произвольного кода. Превосходным справочным источником с более подробными сведениями об этих классах уязвимостей служит книга «The Shellcoder's Handbook: Discovering and Exploiting Security Holes».^[6]

В зависимости от устройства формата файла могут возникать эксплуатируемые логические ошибки. Хотя при исследовании уязвимостей форматов файлов мы лично логических ошибок не обнаруживали, идеальным примером этого класса служит уязвимость Microsoft WMF, исправленная в MS06-001.^[7] Уязвимость не была вызвана обычным переполнением. Более того, она вообще не требовала повреждения памяти, но позволяла злоумышленнику непосредственно выполнять предоставленный пользователем позиционно-независимый код.

Хотя уязвимости форматных строк по большей части вымерли, особенно в программах с открытым исходным кодом, упомянуть их стоит. Мы говорим «по большей части вымерли», потому что не все программисты могут быть столь же осведомлены о безопасности, как сотрудники US-CERT, которые для защиты программ рекомендуют «не использовать спецификатор форматной строки %n».^[8]

Но если говорить серьёзно, по личному опыту мы действительно обнаруживали при фаззинге файлов несколько проблем, связанных с форматными строками. Некоторые из них были найдены в продуктах Adobe^[9] и RealNetworks.^[10] Значительная часть интереса при эксплуатации проблем форматных строк связана с возможностью использовать уязвимость для утечки памяти, помогающей эксплуатации. К сожалению, при клиентских атаках с использованием искажённых файлов такая возможность предоставляется редко.

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

Два инструмента, разработанных для демонстрации фаззинга файлов в UNIX, называются SPIKEfile и notSPIKEfile. Как следует из названий, они соответственно основаны на SPIKE^[1] и не основаны на SPIKE. Ниже кратко перечислены некоторые ключевые возможности этих реализаций:

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

• полностью автоматический фаззинг с задаваемой пользователем задержкой перед завершением целевого процесса;

• две отдельные базы эвристик фаззинга для двоичных и печатаемых текстовых типов данных ASCII;

• легко расширяемая база эвристик фаззинга, изначально заполненная значениями, которые, как известно из прошлого опыта, вызывают проблемы.

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

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

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

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

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

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

Тем, кто хочет исследовать подобные логические ошибки, подойдёт перехват функций библиотеки C (LIBC) с наблюдением за небезопасной передачей предоставленных фаззером значений таким вызовам, как open, creat, system и прочим.

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

Обнаружив исключение, хороший фаззер должен сообщить полезные сведения о том, что именно произошло. Как минимум следует сообщить возникший сигнал. В идеальном случае отчёт должен также включать дополнительные сведения, например вызвавшую ошибку инструкцию, состояние регистров процессора и дамп стека. Оба фаззера, реализованные в этой главе, способны создавать такие подробные отчёты. Для получения желаемых низкоуровневых сведений необходимо прибегнуть к помощи системного вызова ptrace. Если мы намерены сообщать пользователю инструкции, нужно также использовать библиотеку для их дизассемблирования. Библиотека должна уметь преобразовывать буфер произвольных данных в строковое представление инструкций x86. Мы выбрали libdisasm,^[2] поскольку она хорошо работает, предоставляет простой интерфейс и, судя по всему, является предпочтительным выбором поисковой системы Google, которая поставила её выше всех остальных. Окончательно решило дело то, что libdisasm содержит примеры, которые мы можем скопировать и вставить, ещё немного облегчив себе жизнь.

Это сердце фаззера форматов файлов: данный компонент определяет, какие искажённые данные использовать и куда их вставлять. Код, выполняющий эту работу в notSPIKEfile, отличается от кода SPIKEfile, поскольку SPIKEfile использует для реализации этих возможностей уже существующий код SPIKE. Однако будьте уверены: они довольно похожи.

Как вы, несомненно, уже догадались, SPIKEfile использует тот же механизм фаззинга, что и SPIKE. Механизму фаззинга требуется шаблон, называемый сценарием SPIKE, который описывает формат файла. Затем SPIKE «интеллектуально» создаёт варианты этого формата, используя сочетания допустимых и недопустимых данных.

В notSPIKEfile механизм фаззинга значительно более ограничен. Пользователь должен предоставить фаззеру допустимый целевой файл. Затем механизм изменяет различные части этого файла, используя базу фаззинговых значений. Эти значения делятся на два типа, называемые двоичными и строковыми. Двоичные значения могут иметь любую длину и любое содержимое, но обычно применяются для представления размеров распространённых целочисленных полей. Строковые значения, как следует из названия, являются обычными строками. Это могут быть длинные или короткие строки, строки со спецификаторами формата и всевозможные другие исключительные значения, например пути к файлам, URL и любые иные особые строки, которые только можно придумать. Полный список значений этих типов приведён в исходном коде SPIKE и notSPIKEfile, а для начала таблица 12.1 предлагает краткий перечень и короткое объяснение нескольких эффективных фаззинговых строк. Этот список далеко не исчерпывающий, но должен дать представление о типах входных данных, которые необходимо учитывать.

Таблица 12.1. Некоторые распространённые фаззинговые строки и их назначение

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

В следующем разделе мы исследуем некоторые наиболее интересные и важные фрагменты кода SPIKEfile и notSPIKEfile.

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

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

Поскольку дочерний процесс использовал запрос PTRACE_TRACEME, фаззер в роли родительского процесса способен получать все сигналы, предназначенные дочернему процессу. Родитель получает сигнал даже при любом вызове семейства функций exec. Цикл родителя прост, но эффективен. Фаззер циклически получает каждый сигнал, предназначенный дочернему процессу. Затем его поведение меняется в зависимости от сигнала и состояния дочернего процесса.

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

Фаззер также проверяет, действительно ли дочерний процесс завершился, что является другой, неинтересной ситуацией. А если программа аварийно завершилась, спросите вы? Разве это не должно очень нас интересовать? Поскольку мы перехватываем все интересные сигналы до фактического завершения приложения, нам известно, что программа завершилась либо естественным образом, либо из-за неинтересного сигнала. Это подчёркивает важность понимания того, какие сигналы интересны именно вам. Некоторые могут считать исключение операций с плавающей запятой интересным, если ищут уязвимости DoS. Других интересуют лишь настоящие проблемы повреждения памяти. Третьи могут искать сигналы прерывания, которые стали признаком повреждения кучи в новых версиях GLIBC. Было показано, что в некоторых обстоятельствах эти проверки повреждения кучи можно обойти и выполнить произвольный код.^[3]

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

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

Таблица 12.2. Интересные сигналы при фаззинге в UNIX

В отличие от таблицы 12.2, таблица 12.3 описывает сигналы, которые часто возникают при фаззинге, но обычно не интересуют исследователя уязвимостей.

Таблица 12.3. Неинтересные сигналы при фаззинге в UNIX

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

Если вы собираетесь использовать SPIKEfile или notSPIKEfile с приложением, которое нельзя запустить непосредственно, придётся тем или иным способом обойти это ограничение. Хорошими примерами таких приложений служат Adobe Acrobat Reader и RealNetworks RealPlayer.

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

Включение собственных копий распространённых совместно используемых библиотек делает продукт более переносимым. Хотя это делается из любезности к пользователю и должно упростить ему работу, для наших целей оно несколько усложняет дело. Например, если указать фаззеру сценарий оболочки, мы подключимся не к фактически работающему двоичному файлу, а к экземпляру оболочки. Это лишит перехват сигналов всякого смысла. Ниже показано, как обойти эту проблему для Acrobat Reader и RealPlayer. Для всех других подобных приложений идея та же.

Для Acrobat сначала нужно просто запустить acroread с параметром -DEBUG. Вы окажетесь в оболочке с правильно настроенной средой, из которой можно непосредственно вызвать настоящий двоичный файл acroread, часто расположенный по пути $PREFIX/Adobe/Acrobat7.0/Reader/intellinux/bin/acroread. Хотя это не документировано и функция справки отсутствует, мы смогли определить эти сведения, просто прочитав сценарий оболочки acroread. Теперь двоичный файл можно без проблем подвергать фаззингу. Этот метод вместе с notSPIKEfile использовался для обнаружения уязвимости переполнения буфера UnixAppOpenFilePerform в Adobe Acrobat Reader.^[4]

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

Для RealPlayer достаточно присвоить переменной среды оболочки HELIX_PATH путь установки RealPlayer. После этого можно непосредственно подвергать фаззингу двоичный файл realplay.bin, входящий в состав RealPlayer. Эти сведения были получены простым чтением файла сценария оболочки realplay. С помощью этого метода и notSPIKEfile была обнаружена уязвимость форматной строки формата RealPix в RealNetworks RealPlayer/HelixPlayer.^[5]

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

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

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

FileFuzz допускает четыре отдельных подхода к мутации файлов: All Bytes, Range, Depth и Match. Их можно разделить на следующие категории:

• двоичные файлы:

• ширина:

• все байты;

• диапазон;

• глубина;

• текстовые файлы ASCII:

• совпадение.

Как видно, FileFuzz способен работать с двоичными и текстовыми форматами ASCII. В двоичных файлах мы используем два отдельных подхода: ширину и глубину. Чтобы объяснить разницу между ними, воспользуемся аналогией с бурением нефтяных скважин. Если вы ищете нефть на большой географической территории, нельзя просто сразу начать бурить. Сначала нужно различными методами выявить места, где с наибольшей вероятностью находится искомое сокровище. Возможно, вы изучаете карты, анализируете горные породы или используете георадар. Независимо от подхода, обнаружив интересные места, можно начать бурить разведочные скважины и выяснять, какие из них наиболее перспективны.

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

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

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

Как правило, нам нужно перезаписать значение. Предположим, мы хотим последовательно перезаписывать значение символами A с шагом 10. В этом случае сначала зададим в поле Find символ =, поскольку он отмечает начало значения. Затем установим Replace в A X 10 X 10. Это создаст 10 изменённых файлов с перезаписанными значениями для каждого найденного символа =. Получившиеся 10 файлов будут содержать от 10 до 100 символов A на месте значения.

После создания фаззинговых файлов их нужно запустить в целевом приложении. Например, если мы изменили файлы *.doc, затем потребуется открыть их в Microsoft Word. Для этого FileFuzz использует функцию CreateProcess() из Windows API, поэтому FileFuzz может запустить приложение, если мы способны определить, как то же приложение запускается из командной строки, включая необходимые передаваемые ему флаги. Позднее в этой главе подробно объясняется, как получить эти сведения.

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

Как упоминалось в предыдущих главах, обнаружение - ключевая составляющая фаззинга. Какой смысл запускать фаззер на ночь, а утром выяснить, что вам действительно удалось вызвать сбой приложения, но вы не представляете, какое из 10 000 входных значений стало причиной? Вы ничуть не ближе к ответу, чем до начала работы. Фаззинг форматов файлов предоставляет множество способов обнаружения исключений, но один выделяется среди остальных. Для начала можно использовать самый примитивный подход и просто наблюдать за фаззингом, выявляя окна ошибок или, возможно, сбой приложения либо системы. Если вы любите смотреть, как сохнет краска, этот подход для вас. Если хочется подняться на ступень выше, можно проверить файлы журналов и определить, возникла ли проблема. Это включает как журналы приложений, так и системные журналы, например поддерживаемые «Просмотром событий» Windows. Недостаток подхода состоит в том, что входные данные, фаззинговый файл, не связаны с результатом, событием журнала. Единственный способ сопоставить их - временные метки, а он в лучшем случае неточен.

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

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

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

Аудит в FileFuzz можно провести вручную, выбрав цель фаззинга и указав, как следует создавать и хранить фаззинговые файлы. Другой вариант - использовать ранее сохранённый аудит, чтобы заполнить все необходимые поля и сразу начать фаззинг. В приложение входит несколько готовых аудитов, доступных в раскрывающемся меню File Types на главном экране. Однако конечные пользователи могут также создавать собственные сохранённые аудиты и добавлять их в раскрывающееся меню без повторной компиляции приложения. Это возможно потому, что меню динамически создаётся во время выполнения путём разбора файла targets.xml. Структура отдельного аудита показана в следующем примере:

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

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

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

Теперь, когда мы познакомились с особенностями фаззинга форматов файлов на платформе Windows, пришло время создать фаззер. Мы разберём ход мыслей при проектировании FileFuzz, а затем в завершение используем его для выявления широко обсуждавшейся уязвимости JPEG в GDI+, описанной в бюллетене безопасности Microsoft MS04-028.

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

Учитывая цели проектирования, мы снова выбрали для разработки платформу .NET. Она позволила с минимальными усилиями создать графическую внешнюю часть, освободив время для сосредоточения на функциональной стороне проекта. Графический интерфейс и все возможности создания файлов были реализованы на C#. Для отладочных возможностей мы перешли на C, поскольку он позволял проще и непосредственнее взаимодействовать с Windows API. Платформа .NET поддерживала такое архитектурное решение, поскольку разрешает проектам содержать несколько языков программирования при условии, что все они совместимы с .NET Framework.

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

Таблица 14.1. Распространённые категории уязвимых приложений и примеры ранее обнаруженных уязвимостей форматов файлов

Ссылки из таблицы: Почтовые серверы; Серверы баз данных; Службы на основе RPC; Службы удалённого доступа; Медиасерверы; Серверы резервного копирования.

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

Для более полного понимания типичных целей мы приведём примеры для каждого из семи уровней, определённых эталонной моделью взаимодействия открытых систем, моделью OSI,^[13] показанной на рисунке 14.1. Хотя модель OSI никогда не была непосредственно реализована в одной сетевой технологии, её широко используют как точку отсчёта при разборе сетевых технологий, чтобы показать положение конкретной функциональности относительно других сетевых уровней. Теоретически фаззинг сетевых протоколов может быть направлен на любой из семи уровней OSI. На практике встречаются фаззеры всех уровней, кроме уровня 1, физического. При описании каждого уровня для наглядности приводится относящаяся к нему историческая уязвимость.

Рисунок 14.1. Модель взаимодействия открытых систем (OSI)

К важным технологиям канального уровня относятся кадры Ethernet и 802.11. Уязвимости уровня 2 интересны потому, что обработка этого низкоуровневого сетевого уровня часто реализована в ядре операционной системы. Пример недавней уязвимости уровня 2 был обозначен Mitre как CVE-2006-3507.^[14] В этой уязвимости злоумышленник может скомпрометировать систему Mac OS с поддержкой беспроводной сети AirPort из-за нескольких переполнений буфера в стеке. Переполнения возникают в контексте ядра и, хотя эксплуатация нетривиальна, могут использоваться для полной компрометации затронутой системы. Интересное требование состоит в том, что злоумышленник должен находиться в зоне действия выбранной беспроводной сети. Если вы подключены к общедоступной беспроводной сети в кафе и ваша система Mac OS выходит из строя, возможно, разумно оглядеть помещение и взять в заложники для допроса ближайшего посетителя с ноутбуком.

Уровень 3, сетевой уровень, включает IP и Internet Control Message Protocol (ICMP). Хотя наиболее распространённые реализации TCP/IP за долгие годы были хорошо проверены, уязвимости на этом уровне всё ещё встречаются. Стоит также упомянуть, что Windows Vista содержит полностью переписанный сетевой стек, а значит, может быть хорошей целью фаззинга. Недавняя уязвимость TCP/IP описана в MS06-032 «Vulnerability in TCP/IP Could Allow Remote Code Execution».^[16] Она проявляется в ядре из-за неправильного разбора параметров маршрутизации от источника в IP версии 4. Неправильная обработка приводит к переполнению буфера, которое удалённые злоумышленники могут эксплуатировать для получения доступа на уровне ядра.

На один уровень выше расположен уровень 4, транспортный, включающий TCP и UDP. Как уже упоминалось, большинство реализаций TCP/IP хорошо проверены, но в прошлом проблемы встречались и на этом уровне. Прекрасный пример уязвимости здесь - старая атака «winnuke», использовавшая внеполосные пакеты TCP.^[17] Пожалуй, winnuke была самой простой из когда-либо существовавших удалённых атак DoS на ядро. Для удалённого аварийного завершения затронутой системы требовалось лишь передать пакет TCP с установленным указателем срочности. Этот указатель легко установить через любой API сокетов, просто указав, что пакет содержит внеполосные данные.

На сеансовом уровне, уровне 5 модели OSI, расположены два особенно проблемных протокола, оба реализующие удалённые вызовы процедур. Это DCE/RPC (MSRPC компании Microsoft) и ONC RPC, также известный как Sun RPC. Эти два протокола являются реализациями соответственно для систем Windows и UNIX. В прошлом через эти технологии было раскрыто множество критических уязвимостей. Одна из наиболее значительных была исправлена в бюллетене безопасности Microsoft MS04-011^[18] и использовалась червём Sasser^[19] для распространения в реальных системах. Уязвимость находилась в двоичном файле lsass.exe, который предоставлял конечные точки RPC, зарегистрированные по умолчанию во всех современных версиях операционной системы Windows. В частности, уязвимость возникала из-за переполнения буфера в функции DsRolerUpgradeDownlevelServer и могла эксплуатироваться удалённо.

Хорошим примером технологии уровня 6, прекрасно подходящей для фаззинга, является XDR, eXternal Data Representation, используемое в Sun RPC. Среди обнаруженных в прошлом уязвимостей XDR особенно хорошим примером служит целочисленное переполнение xdr_array, найденное Нилом Мехтой (Neel Mehta).^[20] В основе открытия лежало злоупотребление целочисленным переполнением. Если злоумышленник задавал большое число элементов массива, мог выделяться буфер недостаточного размера, в который затем выполнялась запись и который переполнялся. Злоумышленники могут использовать это повреждение памяти для компрометации нижележащей системы.

Уровень 7, прикладной, является уровнем OSI, о котором чаще всего думают и который чаще всего выбирают целью при фаззинге сетевых протоколов. Здесь находятся распространённые протоколы FTP, SMTP, HTTP, DNS и множество других стандартизованных и проприетарных протоколов. Исторически на этом уровне обнаружено больше уязвимостей, чем на любом другом. Уровень 7 чаще всего подвергается фаззингу, поскольку для распространённых протоколов существует множество различных реализаций.

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

Доступные методы фаззинга по большей части совпадают с методами, представленными в главе 11 «Фаззинг форматов файлов». На высоком уровне к фаззингу форматов файлов и сетевому фаззингу можно подходить методом полного перебора либо интеллектуальным методом. Однако при применении к сетевому фаззингу эти подходы имеют несколько различий.

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

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

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

При фаззинге простого сетевого протокола, например управляющего канала FTP, интеллектуальный фаззинг часто является лучшим решением. Простая грамматика, описывающая каждую команду протокола (USER, PASS, CWD и так далее), и описания типов данных каждого аргумента команд позволяют провести довольно полную проверку. Разработку фаззера на основе генерации можно вести поверх существующей основы, например PEACH,^[21] либо с нуля. В последнем случае создаётся фаззер конкретного протокола, который по большей части нельзя перенастроить для других протоколов. При таком подходе любые соображения универсальной архитектуры отбрасываются, что упрощает проектирование и реализацию.

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

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

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

Хотя нам неизвестны общедоступные инструменты фаззинга, использующие этот подход, таким способом было создано несколько эксплойтов. Один из примеров - эксплойт OpenSSH sshutuptheo,^[22] написанный GOBBLES для эксплуатации целочисленного переполнения до аутентификации в популярном сервере SSH.

Этот подход особенно выгоден для сложных протоколов вроде SSH. Однако разработчик должен учитывать все ограничения клиента, которые повлияют на покрытие кода. Например, если выбран SSH, а клиент поддерживает только SSH версии 1, особенности SSH версии 2 вообще не получат покрытия. Другой недостаток, разумеется, состоит в том, что для покрытия множества тестовых примеров допустимый клиент может потребовать значительных изменений.

Обнаружение сбоев является критически важной частью процесса фаззинга, поэтому глава 24 «Интеллектуальное обнаружение сбоев» целиком посвящена его обсуждению. Хотя совершенные методы обнаружения сбоев будут рассмотрены лишь в той главе, познакомимся с некоторыми базовыми приёмами применительно к фаззингу сетевых протоколов. Сложность обнаружения сбоев при сетевом фаззинге полностью зависит от цели. Например, рассмотрим сетевой демон, который после любого сбоя аварийно завершается и перестаёт принимать соединения. Очевидно, с точки зрения простейшего обнаружения сбоев это превосходное поведение. Когда сервер прекращает работу, просто предположите, что его вывел из строя последний тестовый пример. Фаззер может сделать это полностью самостоятельно без помощи программного агента или ручной проверки целевого узла.

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

При наличии локального доступа к машине самый простой способ следить за исключениями - подключить отладчик к процессу. Отладчик способен обнаружить возникновение исключения, позволяя пользователю определить дальнейшие действия. Для этой задачи подходят Ollydbg, Windbg, IDA и GDB. Проблемой становится сопоставление поведения с вызвавшим его тестовым примером или последовательностью тестов.

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

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

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

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

• целевая программа должна широко использоваться;

• целевую программу должно быть легко получить в виде демонстрационной или оценочной версии;

• целевая программа должна использовать общедоступный либо тривиальный для обратной разработки протокол.

Возможностей много, но для этого примера мы выберем Novell NetMail,^[2] корпоративную систему электронной почты и календарей, реализующую несколько документированных протоколов и отвечающую всем нашим требованиям. В частности, целью будет NetMail Networked Messaging Application Protocol (NMAP). Этот NMAP не следует путать с Nmap,^[3] повсеместно используемым средством сканирования и разведки сети. Что именно представляет собой NetMail NMAP? Мы не знали этого навскидку, но, к счастью, Novell охотно делится следующим определением:

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

Novell любезно предлагает на своём веб-сайте^[5] бесплатные 90-дневные оценочные версии NetMail, поэтому целевую программу достаточно легко загрузить и установить в лабораторной среде. После установки мы обновляем её исправлениями, предоставленными Novell. Это критически важный шаг, гарантирующий, что мы не обнаружим повторно старые ошибки, если вообще что-либо найдём. Очень неприятно через неделю аудита понять, что вы пропустили этот шаг. Далее необходимо подробно изучить протокол NMAP.

Прежде чем описывать протокол NMAP для SPIKE, нам, очевидно, нужно самим его понять. Существует ряд подходов к этому этапу. Возможно, самый очевидный - наблюдать за допустимым трафиком NMAP в лабораторной среде. На самом деле этот подход немного сложнее, чем можно предположить. При работе со сложными корпоративными программами иногда трудно создать именно тот трафик, который вы ищете. Другой подход - опереться на работу других. Никогда не повредит спросить Google, что известно окружающим о данном протоколе. Кроме того, всегда полезно проверить, существует ли декодер протокола в открытом анализаторе трафика Wireshark, ранее называвшемся Ethereal. Перейдите в репозиторий Subversion Wireshark, а именно в каталог epan\dissectors,^[6] и посмотрите, удастся ли найти ваш протокол.

Ещё один, реже всего доступный способ - просто обратиться к самому демону NMAP и посмотреть, предоставит ли он какие-либо сведения. Для этого сначала нужно определить порты, по которым приложение обменивается данными с клиентами. Если предположить, что документация прямо не сообщила о привязке NMAP к TCP-порту 689, это можно выяснить вручную с помощью Microsoft TCPView,^[7] ранее принадлежавшего Sysinternals. Простого запуска TCPView достаточно, чтобы сразу увидеть: nmapd.exe прослушивает TCP-порт 689. К демону можно подключиться базовым средством TCP-соединений, например netcat,^[8] или даже командой Windows telnet. Сделав смелое предположение, мы отправляем команду HELP и, к нашему приятному удивлению, получаем список команд, которые принимает демон.

Неплохо для нескольких минут работы. Развивая успех с собранными сведениями, загружаем двоичный файл nmapd.exe в любимый дизассемблер IDA Pro. Нажимаем Shift+F12 для просмотра базы строк, показанной на рисунке 15.1. Затем находим то, что похоже на ответ справки и начинается с текста ASCII 1000. Теперь сортируем базу строк по содержимому, а не по адресу, и прокручиваем до строк, начинающихся с 1000. Здесь мы находим все команды, поддерживаемые сервером NMAP, и их ожидаемый синтаксис.

Рисунок 15.1. Список строк, найденных в исполняемом файле nmapd.exe

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

• <argument> - обязательный аргумент; если он не указан, команда завершится ошибкой;

• [argument] - необязательный аргумент;

• {CONSTANT1|CONSTANT2|CONSTANT3} - обязательный аргумент, который для успешного выполнения команды должен быть выбран из набора постоянных строк; возможные значения разделены вертикальной чертой |.

Кроме того, любая строка вне угловых скобок должна рассматриваться как буквальная, а внутри угловых скобок - как переменная. Те же правила применяются к командам с вложенным описанием синтаксиса. Например, команда PASS описана так:

Прототип указывает, что после команды всегда следует буквальная строка SYS или USER. Поскольку переменная Username находится в угловых скобках после буквальной строки USER, она обязательна, но только при выборе USER. Если выбрано SYS, аргумент Username не требуется. Наконец, переменная Password всегда обязательна как последний аргумент команды. Протокол команды PASS, вероятно, является самым сложным в этом протоколе, что не слишком впечатляет. Как оказалось, мы выбрали очень дружелюбный протокол для фаззинга.

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

Предположив, что нас интересуют состояния после аутентификации, необходимо определить способ успешного входа. Мы видим несколько вариантов. Пользователь может войти, отдельно отправив команды USER, а затем PASS, как в протоколе FTP. Другой вариант - указать имя пользователя внутри команды PASS. Третий тип аутентификации позволяет другим агентам NMAP проходить проверку с директивой SYS вместо USER в команде PASS.

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

Вооружившись этими базовыми сведениями о протоколе NMAP, теперь можно приступить к созданию фаззера NMAP в SPIKE.

В главе 21 «Основы фаззинга» SPIKE кратко рассматривается среди других доступных основ фаззинга, но здесь мы изучим его подробно. Поскольку для фаззинга протокола будет применяться SPIKE, важно познакомиться с его механизмом фаззинга и универсальным сценарным построчным фаззером TCP.

SPIKE работает, последовательно перебирая переменные и фаззинговые строки. Представляйте переменные как поля протокола: имена пользователей, пароли, команды и так далее. Эти переменные и их расположение в потоке данных специфичны для каждой цели. Фаззинговые строки являются библиотекой различных строк и двоичных данных, способных вызвать сбой; элементы библиотеки тщательно выбраны на основе прошлого опыта с конкретными последовательностями, вызывавшими проблемы в других программах. Например, рассмотрим самую простую фаззинговую строку: строку ASCII из 64 000 последовательных символов A. Она может заменить переменную имени пользователя в протоколе, чтобы вызвать переполнение буфера до аутентификации. Помните, что термин фаззинговая «строка» несколько вводит в заблуждение. Фаззинговая строка может иметь любой тип данных, даже быть, например, массивом двоичных данных в кодировке XDR.

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

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

Реализация языка сценариев позволяет автору сценария непосредственно вызывать функции API SPIKE. Чтобы дать базовое представление о написании сценария, перечислим некоторые функции, которые вам, скорее всего, придётся вызывать:

• s_string(char * instring) добавляет в SPIKE фиксированную строку. Она никогда не изменяется.

• s_string_variable(unsigned char *variable) добавляет в SPIKE строковую переменную. При обработке соответствующей переменной эта строка заменяется фаззинговыми строками.

• s_binary(char * instring) добавляет в SPIKE двоичные данные. Они никогда не изменяются.

• s_xdr_string(unsigned char *astring) добавляет в SPIKE строку в стиле XDR. Она включает четырёхбайтовую метку длины и дополняется нулями до размера, кратного четырём. Строка никогда не изменяется.

• s_int_variable(int defaultvalue, int type) добавляет в SPIKE целое число.

В вызовах s_int_variable() значение type может быть одним из следующих:

• Binary Big Endian: целое с наиболее значимым байтом первым (MSB), 4 байта;

• ASCII: знаковое десятичное число в формате ASCII;

• One byte: однобайтовое целое;

• Binary Little Endian Half Word: целое с наименее значимым байтом первым (LSB), 2 байта;

• Binary Big Endian Half Word: целое MSB, 2 байта;

• Zero X ASCII Hex: шестнадцатеричное число ASCII с префиксом 0x;

• ASCII Hex: шестнадцатеричное число в формате ASCII;

• ASCII Unsigned: беззнаковое десятичное число в формате ASCII;

• Intel Endian Word: целое LSB, 4 байта.

Поскольку при использовании SPIKE как узла сценариев препроцессор C не применяется, нам нужно знать числовые значения типов. В следующем фрагменте из SPIKE/SPIKE/include/listener.h показаны их определения:

Обсуждённых возможностей SPIKE достаточно для разработки фаззера NMAP. Однако рассмотрим главный вклад SPIKE в область фаззинга: блочное представление протокола.

Хотя мы выбрали для работы простой текстовый протокол, SPIKE поддерживает и более сложные протоколы благодаря блочному фаззингу. Оно позволяет динамически создавать пакеты с допустимыми длинами полей. Рассмотрим, например, протокол со структурой пакета, в которой перед полем имени пользователя стоит длина указанного имени. Нам хотелось бы, чтобы фаззер автоматически обновлял поле длины при фаззинге имени пользователя. Это гарантирует правильную передачу фаззинговых строк анализатору имени. Функции s_block_start() и s_block_end() позволяют моделировать такие протоколы и объявлены следующим образом:

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

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

SPIKE включает небольшую коллекцию готовых фаззеров конкретных протоколов:

• фаззер HTTP;

• фаззер Microsoft RPC;

• фаззер X11;

• фаззер Citrix;

• фаззер Sun RPC.

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

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

• CIFS;

• FTP;

• H.323;

• IMAP;

• Oracle;

• Microsoft SQL;

• PPTP;

• SMTP;

• SSL;

• POP3.

Как уже упоминалось, в SPIKE есть несколько универсальных фаззеров, принимающих сценарии на вход:

• фаззер прослушивания TCP, то есть клиентской стороны;

• фаззеры отправки TCP/UDP;

• фаззер отправки TCP со строковой буферизацией.

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

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

• Составленные наборы тестов. И PROTOS Test Suite,^[6] и его коммерческий родственник Codenomicon^[7] жёстко задают структуру пакетов данных для фаззинга. Создание таких наборов - трудоёмкая задача, поскольку требует анализа спецификации протокола и последующей разработки, возможно, тысяч жёстко заданных тестовых примеров.

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

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

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

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

Помимо перехвата данных, хотя это и не строго необходимо, мы хотим, чтобы ProtoFuzz представлял содержимое перехваченных пакетов в удобном для восприятия виде. Это поможет пользователю выявлять области пакета, подходящие для фаззинга. Данные сетевого пакета являются всего лишь последовательностью байтов по определённому шаблону. Для отображения данных в удобочитаемом виде нужна библиотека перехвата, способная понимать структуру пакета и разделять её на различные заголовки протоколов и сегменты данных, составляющие поток. Большинство знакомо с форматом представления Wireshark, поэтому возьмём его за основу. На рисунке 16.1 показан простой пакет TCP, перехваченный Wireshark.

Рисунок 16.1. Wireshark разбирает пакет поддержания соединения AIM

На этом снимке экрана Wireshark данные разделены на три области. Верхняя содержит список отдельных перехваченных пакетов. Выбор одного из них загружает содержимое пакета в две нижние области. Средняя показывает разбор пакета на отдельные поля. В данном случае видно, что Wireshark знаком с протоколом AOL Instant Messenger, поскольку успешно декодировал весь сегмент данных пакета TCP. Наконец, в нижней области показаны необработанные шестнадцатеричные байты и байты ASCII выбранного пакета.

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

• [XX], полный перебор. Байты в квадратных скобках подвергаются фаззингу всеми возможными байтовыми значениями. Поэтому один байт проверяется 256 раз, а значение слова, два байта, 65 536 раз.

• <XX>, строки. Байты также можно подвергать фаззингу шестнадцатеричными представлениями заранее определённых строк переменной длины из управляемого пользователем текстового файла Strings.txt. Такой фаззинг обычно выполняется в областях данных пакетов, а не в полях заголовков, которым требуется определённая структура.

Следующий шаблон показывает пакет TCP с фаззинговыми переменными полного перебора и строк:

Библиотеки протоколов обычно применяют один из двух подходов к отправке данных. Во-первых, они могут иметь ряд функций, позволяющих задавать определённые сведения, например целевые IP- и MAC-адреса. Однако основная часть структуры пакета строится автоматически по соответствующему RFC. Пример такого класса .NET Framework - HttpRequest. Он разрешает определять такие свойства, как метод и URL, но большинство заголовков HTTP и все заголовки Ethernet, TCP и IP создаются автоматически. Альтернативный подход - создать необработанный пакет данных, в котором отдельные байты задаются явно, а программист должен сам обеспечить соответствие пакета структуре из надлежащего RFC. Хотя второй подход требует от исследователя больше работы, более детальный контроль позволит подвергать фаззингу как заголовки протокола, так и сегменты данных.

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

Многие библиотеки перехвата пакетов требуют специального драйвера протокола. Выбранная для ProtoFuzz библиотека Metro Packet Library^[8] включает ndisprot.inf, пример драйвера протокола Network Driver Interface Specification (NDIS), предоставленный Microsoft в составе Driver Development Kit. Фактически NDIS является API сетевых адаптеров, предоставляющим приложениям возможность отправлять и принимать необработанные пакеты Ethernet. Перед использованием ProtoFuzz драйвер необходимо вручную установить и запустить, что можно сделать из командной строки командой net start ndisprot. Один из недостатков библиотеки, требующей такого специального драйвера, состоит в том, что драйвер может поддерживать не все типы сетевых адаптеров. Например, драйвер Metro не работает с беспроводным адаптером.

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

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

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

• Доступ ко всем уровням протокола. Некоторые сетевые фаззеры сосредоточены на данных пакета, а не на самих заголовках протокола. ProtoFuzz должен уметь подвергать фаззингу любую часть пакета: от заголовка Ethernet до данных TCP/UDP.

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

Как и в случае с FileFuzz, нашим инструментом фаззинга форматов файлов в Windows, для создания этого сетевого фаззера с графическим интерфейсом мы обратились к C# и Microsoft .NET Framework. Платформа .NET берёт на себя значительную часть тяжёлой работы при разработке графических приложений, позволяя сосредоточиться на бизнес-логике приложения или, в нашем случае, на логике разрушения бизнеса. Приложения .NET требуют предварительной установки .NET Framework. Однако рост распространённости приложений на .NET превращает это в небольшое неудобство, поскольку в большинстве систем библиотека уже установлена.

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

Выбор разработки ProtoFuzz на платформе Windows автоматически ограничивает варианты. Обычно предпочтительной библиотекой для Microsoft Windows была бы WinPcap,^[9] превосходная библиотека перехвата пакетов, появившаяся, когда Пьеро Виано (Piero Viano) перенёс libpcap в Windows в рамках своей дипломной работы. WinPcap уже много лет развивается как открытый проект и потому превратился в сильную кодовую базу с поддержкой большинства основных протоколов. Более того, она является обязательным компонентом многих коммерческих и открытых приложений, которым требуется работа с пакетами данных, например Wireshark, ранее Ethereal, и Core Impact.^[10] На веб-сайте WinPcap перечислено более 100 инструментов, использующих библиотеку для перехвата пакетов, и это лишь те, о которых известно разработчикам!

Хотя WinPcap рассматривалась для ProtoFuzz, выбор C# в качестве языка разработки осложнил работу с популярной библиотекой. WinPcap написана на C; предпринималось несколько попыток написать оболочки, упрощающие применение WinPcap из приложения C#, но нам ещё не встречался комплексный проект, включающий все возможности WinPcap. Для проекта также рассматривалась PacketX,^[11] библиотека классов COM, предоставляющая оболочку WinPcap, но в конечном счёте от неё отказались, поскольку она является коммерческой, а при написании книги мы стремились по возможности использовать свободно распространяемые библиотеки.

После долгих поисков мы с радостью наткнулись на Metro Packet Library. Хотя она не столь мощна, как WinPcap, библиотека целиком написана на C#, поставляется с хорошими учебными материалами и документацией и более чем подходила для базового фаззера, который мы хотели создать. Единственная слабость Metro - ограниченные возможности разбора. В ней есть классы для распознавания всех высокоуровневых заголовков пакетов: Ethernet, TCP, UDP, ICMP, IPv4 и Address Resolution Protocol (ARP), но пока нет классов, способных понимать данные пакетов ниже этих заголовков. С учётом скромных целей ProtoFuzz это снова не представляло серьёзной проблемы, а поскольку Metro является открытым проектом, мы всегда можем расширить существующие классы, разработав необходимую функциональность.

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

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

• Обновление страниц HTML. В этом сценарии фаззинговые веб-страницы создаются веб-сервером и содержат средство регулярного обновления. Это можно реализовать разными способами, например тегом META с HTTP-EQUIV для обновления или клиентским сценарием. При обновлении выдаётся новая версия страницы с новым фаззинговым содержимым. Например, Mangleme,^[4] утилита фаззинга для обнаружения дефектов разбора HTML в веб-браузерах, включает следующую строку в часть HEAD каждой фаззинговой страницы:

Этот тег немедленно обновляет страницу mangleme и перенаправляет на mangle.cgi, где веб-браузер ожидает новую искажённую страницу. Похожую задачу выполняет следующий клиентский JavaScript, обновляющий страницу через 2000 миллисекунд:

• Загрузка страниц. Фаззинг можно выполнять исключительно на стороне клиента, непосредственно загружая фаззинговую страницу в веб-браузер. С помощью параметров командной строки целевому браузеру можно приказать открыть фаззинговую страницу, находящуюся на локальной машине. Например, следующая команда непосредственно откроет файл fuzz.html в Internet Explorer:

• Выбор отдельных объектов браузера целью. В некоторых ситуациях браузерный фаззинг можно проводить вообще без запуска браузера. Это возможно, когда нашей целью является объект браузера, а браузер служит лишь средством доступа к нему. Например, можно подвергать фаззингу элемент управления ActiveX, к которому способен удалённо обратиться вредоносный веб-сайт, если объект помечен как «безопасный для сценариев». В такой ситуации для определения уязвимости не требуется запускать элемент ActiveX из браузера. COMRaider,^[5] созданный Дэвидом Циммером (David Zimmer), использует этот подход к элементам ActiveX.

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

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

Пример такой уязвимости - CVE-2003-0113,^[6] вошедшая в бюллетень безопасности Microsoft MS03-015.^[7] Йоуко Пюннёнен (Jouko Pynnönen) обнаружил, что из-за неправильной проверки границ в urlmon.dll длинные значения заголовков Content-type и Content-encoding^[8] могут привести к переполнению буфера в стеке. Было установлено, что этому типу атаки подвержены многочисленные версии Internet Explorer 5.x и 6.x.

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

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

HTML имеет относительно простую структуру. Существует несколько стандартов HTML, и для обозначения применяемого стандарта правильно сформированная веб-страница должна начинаться с объявления типа документа (Document Type Declaration, DTD). Например, следующее DTD сообщает браузеру, что страница должна соответствовать HTML 4.01:

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

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

Mangleme был создан для обнаружения уязвимостей в интерпретации веб-браузерами искажённых тегов HTML и привёл к обнаружению CVE-2004-1050,^[9] исправленной в бюллетене безопасности Microsoft MS04-040.^[10] Нед и Беренд-Ян Вевер (Ned and Berend-Jan Wever) с помощью mangleme обнаружили, что чрезмерно длинные атрибуты SRC или NAME в элементах IFRAME, FRAME и EMBED способны привести к переполнению буфера в куче. Впоследствии они опубликовали полный общедоступный код эксплойта^[11] для этой проблемы. Другие утилиты фаззинга структуры HTML в веб-браузерах включают DOM-Hanoi^[12] и Hamachi,^[13] разработанные Х. Д. Муром и Авивом Раффом (Aviv Raff).

XML - универсальный язык разметки, производный от Standardized General Markup Language (SGML) и широко используемый для передачи данных по HTTP. Были разработаны стандартизованные реализации XML, определяющие тысячи форматов данных, например RSS, Application Vulnerability Description Language (AVDL), Scalable Vector Graphics (SVG) и так далее. Как и HTML, современные веб-браузеры способны разбирать и интерпретировать элементы XML и связанные с ними атрибуты и содержимое. Поэтому неожиданные данные, встреченные браузером при интерпретации элементов, могут привести к необработанному исключению. Vector Markup Language (VML) - спецификация XML для определения векторной графики. В библиотеках Internet Explorer и Outlook были обнаружены уязвимости, вызванные неспособностью обрабатывать определённые искажённые теги VML. 19 сентября 2006 года Microsoft выпустила рекомендацию по безопасности 925568,^[14] подробно описав переполнение буфера в стеке механизма отображения векторной графики (vgx.dll), способное привести к удалённому выполнению кода. Рекомендация появилась после свидетельств активной эксплуатации, заставивших Microsoft семь дней спустя выпустить внеплановое исправление.^[15] Позднее в той же библиотеке было раскрыто целочисленное переполнение, исправленное в январе 2007 года.^[16]

Элементы управления ActiveX представляют собой проприетарную технологию Microsoft на основе COM, предоставляющую многократно используемые программные компоненты.^[17] Веб-разработчики часто встраивают элементы ActiveX для расширенной функциональности, обычно недоступной веб-приложению. Главный недостаток ActiveX состоит в том, что проприетарная природа ограничивает применение браузером Internet Explorer и операционной системой Windows. Тем не менее элементы ActiveX широко используются на многих веб-сайтах. Они обладают огромными возможностями и после признания доверенными получают полный доступ к операционной системе, поэтому их никогда не следует запускать, если они не поступили из доверенного источника.

Многочисленные уязвимости обнаруживались в элементах ActiveX, входящих в операционную систему Windows или сторонние пакеты программ. Если такие элементы помечены как «безопасные для инициализации» и «безопасные для сценариев», к ним может обратиться удалённый веб-сервер и использовать для компрометации целевой машины.^[18] Возникает опасная ситуация: пользователь может первоначально установить элемент ActiveX из доверенного источника, но если позднее в нём обнаружится уязвимость, например переполнение буфера, тот же доверенный элемент сможет использовать вредоносный веб-сайт.

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

Рисунок 17.1. COMRaider

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

AxMan^[19] - ещё один свободно доступный фаззер ActiveX. AxMan был создан Х. Д. Муром и использовался для обнаружения большинства уязвимостей ActiveX, опубликованных во время «Месяца ошибок браузеров» в июле 2006 года.^[20]

CSSDIE^[21] - фаззер CSS, созданный Х. Д. Муром, Мэттом Мёрфи (Matt Murphy), Авивом Раффом и Тьерри Цоллером (Thierry Zoller) и использованный во время «Месяца ошибок браузеров» для выявления проблемы повреждения памяти браузера Opera.^[22] Было обнаружено, что присваивание свойству CSS background элемента DHTML чрезмерно длинного URL приводит к клиентскому отказу в обслуживании с аварийным завершением браузера.

Другие проблемы CSS приводили к разнообразным уязвимостям, например CVE-2005-4089, исправленной в MS06-021,^[23] которая позволяла злоумышленнику обходить междоменные ограничения Internet Explorer. Это было возможно потому, что сайты могли использовать директиву @import для загрузки файлов из других доменов, не являвшихся правильными файлами CSS. Матан Гиллон (Matan Gillon) из hacker.co.il продемонстрировал использование уязвимости для просмотра результатов Google Desktop Search (GDS) другого человека.^[24] Хотя атака больше не работает из-за изменений Google, она стала превосходным примером сочетания простой уязвимости Internet Explorer с возможностями другого приложения, в данном случае GDS, для относительно сложной атаки. В CSS формат элемента определяется внутри фигурных скобок, а свойство и значение разделяются двоеточием. Например, тег ссылки можно определить как a {color: white}. Когда директивой @import импортировался файл, не являвшийся CSS, Internet Explorer пытался интерпретировать его как CSS, и всё содержимое после открывающей фигурной скобки можно было затем получить через свойство cssText. Матан смог использовать атаку для кражи уникального ключа GDS посетителя веб-страницы: сначала он импортировал страницу Google News как файл CSS с запросом }{. Результаты запроса попадали в свойство cssText, откуда можно было получить уникальный ключ GDS пользователя. После этого злоумышленник мог другой директивой @import импортировать результаты из локального GDS пользователя и на этот раз просматривать локальный индекс GDS.

Веб-браузеры используют разные языки клиентских сценариев для создания динамического содержимого веб-страниц. Хотя наиболее распространён JavaScript, существуют и другие, например VBScript, JScript^[25] и ECMAScript.^[26] Мир языков клиентских сценариев кровосмесителен: многие языки производны друг от друга. Например, ECMAScript является лишь стандартизованной версией JavaScript, а JScript - просто реализация JavaScript компании Microsoft. Эти языки предоставляют веб-сайтам мощные возможности, но также породили множество проблем безопасности.

Эксплойты с клиентскими языками сценариев обычно не эксплуатируют уязвимости самих механизмов сценариев, а лишь используют язык для обращения к другому уязвимому компоненту, например элементу ActiveX. Однако это не означает, что уязвимостей механизмов сценариев не существует. Проблемы повреждения памяти относительно обычны; пример - нулевая ссылка, вызываемая в Internet Explorer перебором собственной функции с помощью JavaScript.^[27] Во время «Месяца ошибок браузеров» эта уязвимость демонстрировалась одной строкой JavaScript:

Уязвимость механизма JavaScript Firefox, обнаруженная Azafran, приводила к утечке информации, позволявшей вредоносному веб-сайту удалённо получать содержимое произвольной памяти кучи.^[28] Уязвимость была вызвана обработкой лямбда-выражений функцией replace(). Хотя злоумышленник не управлял получаемой памятью, в ней могли находиться конфиденциальные сведения, например пароли.

Рисунок 17.2. Заполнение кучи SkyLined в действии в Heap Vis для OllyDbg

Хотя Adobe Flash Player является сторонним дополнением веб-браузера, а не встроенной функцией, он получил настолько широкое распространение, что сегодня в большинстве браузеров установлена та или иная версия Flash Player. Двоичные файлы Flash обычно имеют расширение .swf и могут открываться самостоятельно, но чаще встраиваются как объекты веб-страниц, загружаемые браузером и затем запускаемые во Flash Player. Из-за двоичной природы файлов Flash при фаззинге можно применить один из двух альтернативных подходов. Заведомо исправный файл .swf можно подвергнуть фаззингу, как описано в главах 11 «Фаззинг форматов файлов», 12 «Фаззинг форматов файлов: автоматизация в UNIX» и 13 «Фаззинг форматов файлов: автоматизация в Windows», где подробно рассматриваются методы фаззинга форматов файлов. В ноябре 2005 года eEye раскрыла подробности уязвимости доступа к памяти в Macromedia Flash 6 и 7. Хотя неизвестно, как именно она была обнаружена, вероятным подходом представляется фаззинг.

Другой вариант - программировать файлы Flash с помощью ActionScript, языка сценариев Flash для управления данными и содержимым во время выполнения.^[32] Затем фаззинг можно использовать для мутации различных методов ActionScript до компиляции двоичных файлов Flash. В октябре 2006 года Rapid7 выпустила бюллетень безопасности с описанием того, как метод XML.addRequestHeader() позволял добавлять произвольные заголовки HTTP в запрос объекта Flash.^[33] Это, в свою очередь, можно было использовать для выполнения произвольных запросов HTTP методом разделения запросов HTTP.

Иногда к уязвимостям приводит сам URL. После выпуска MS06-042^[34] eEye обнаружила, что недавно выпущенные исправления этого бюллетеня также внесли уязвимость переполнения кучи. Было установлено, что при передаче Internet Explorer чрезмерно длинного URL и указании целевым веб-сайтом кодирования GZIP или deflate могло возникнуть переполнение, когда вызов lstrcpynA() пытался скопировать URL длиной до 2084 байтов в буфер размером 260 байтов.^[35] Для атаки с этой уязвимостью требовалось лишь заставить пользователя уязвимой версии Internet Explorer щёлкнуть предоставленный URL.

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

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

Самого раннего предка COM можно проследить до Dynamic Data Exchange (DDE), технологии, до сих пор используемой в операционной системе Windows. DDE можно увидеть в действии в расширениях файлов оболочки, программе просмотра ClipBook (NetDDE) и Microsoft Hearts (также NetDDE). В 1991 году Microsoft представила Object Linking and Embedding (OLE). В то время как DDE ограничена чистым обменом данными, OLE способна встраивать типы документов друг в друга. Взаимодействие клиента и сервера OLE происходит внутри системных библиотек посредством таблиц виртуальных функций (VTBL).

За появлением COM последовала OLE, а позднее выпуск OLE 2, нового поколения OLE, построенного поверх COM вместо VTBL. В 1996 году эта технология была переименована в ActiveX. Позднее в том же году Microsoft выпустила Distributed COM (DCOM) как расширение COM и ответ на Common Object Request Broker Architecture^[1] (CORBA). Distributed Computing Environment/Remote Procedure Calls^[2] (DCE/RPC) является механизмом RPC, лежащим в основе DCOM. Добавление DCOM ещё больше расширило гибкость COM, поскольку позволяет разработчикам программного обеспечения предоставлять функциональность через такие среды, как Интернет, не предоставляя доступа к лежащему в основе коду.

Самым недавним событием в истории COM стало появление COM+, выпущенной вместе с операционной системой Windows 2000. COM+ предоставляет дополнительное преимущество «ферм компонентов», управляемых с помощью Microsoft Transaction Server, входящего в комплект Windows 2000. Подобно DCOM, компоненты COM+ также могут быть распределёнными и дополнительно допускают повторное использование без необходимости выгружать компонент из памяти.

Архитектура COM определяет как объекты, так и интерфейсы. Объект, такой как элемент управления ActiveX, описывает свою функциональность, определяя и реализуя интерфейс. Затем программное обеспечение может запросить объект COM, чтобы определить, какие интерфейсы и функциональность он может предоставлять. Каждому объекту COM назначается уникальный 128-битный идентификатор, известный как идентификатор класса (CLSID). Кроме того, каждому интерфейсу COM также назначается уникальный 128-битный идентификатор, известный как идентификатор интерфейса (IID). Примерами интерфейсов COM являются IStream, IDispatch и IObjectSafety. Эти и все прочие интерфейсы являются производными от базового интерфейса, известного как IUnknown.

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

• 000208D5-0000-0000-C000-000000000046

• Excel.Application

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

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

Microsoft Internet Explorer является единственным браузером, который изначально поддерживает ActiveX и реализует стандартную объектную модель документа (DOM) для обработки создания экземпляров, параметров и вызова методов. Для справки и демонстрации ниже приведены следующие примеры.

Помимо загрузки элементов управления непосредственно в браузере, элемент управления ActiveX можно загрузить и взаимодействовать с ним напрямую как со стандартным объектом COM. Непосредственная загрузка элемента управления может быть выгодна для нашего фаззера, поскольку устраняет промежуточные шаги создания и загрузки браузерного кода в Internet Explorer.

Программирование Microsoft COM и её внутреннее устройство представляют собой обширную тему, которой посвящены целые книги. Дополнительные сведения о COM можно найти на веб-сайте Microsoft COM^[3], где приведён обзор высокого уровня, и в статье MSDN «The Component Object Model: A Technical Overview»^[4], где приведён обзор низкого уровня.

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

Для разработки фаззера ActiveX подходит ряд языков. Это очевидно из того, что при реализации различных существующих сегодня фаззеров ActiveX используется множество языков программирования. COMRaider^[5] в основном построен на Visual Basic с небольшими вкраплениями C++. AxMan^[6] разработан как гибрид C++, JavaScript и HTML. Мы строим свой фаззер по тому же общему подходу, который применён в обоих этих фаззерах:

• перечислить все загружаемые элементы управления ActiveX;

• перечислить доступные методы и свойства каждого элемента управления ActiveX;

• разобрать библиотеку типов, чтобы определить типы параметров методов;

• сгенерировать тестовые случаи фаззинга;

• выполнить тестовые случаи фаззинга, одновременно отслеживая аномалии.

В отличие от наших предшественников, мы реализовали свой фаззер целиком на одном языке, Python. Поначалу выбор языка может показаться вам странным и даже неосуществимым. Однако разработка на Python действительно возможна, поскольку современные дистрибутивы включают ряд модулей, предоставляющих доступ к лежащему в основе Windows API. Среди различных модулей, на которые мы полагаемся при взаимодействии с COM, находятся win32api, win32com, pythoncom и win32con. Если вас интересуют дополнительные подробности программирования на Python в среде Windows, обратитесь к книге с подходящим названием «Python Programming on Win32»^[7], написанной Марком Хаммондом, непосредственным разработчиком ряда модулей, которые мы используем, чтобы связать Python с миром COM. На рисунках 18.1 и 18.2 приведены снимки экранов обозревателей COM и библиотек типов PythonWin соответственно, показывающие высокоуровневый доступ к низкоуровневой информации COM.

Рисунок 18.1. Обозреватель COM в PythonWin

Рисунок 18.2. Обозреватель библиотек типов в PythonWin

В качестве программного примера рассмотрим следующий фрагмент, который создаст экземпляр Microsoft Excel и сделает его видимым, установив логическое свойство Visible:

Далее мы сразу перейдём к дополнительным примерам, рассмотрев, как перечислить все загружаемые элементы управления ActiveX. Фрагменты кода, представленные в оставшейся части этой главы, являются выдержками из полнофункционального фаззера COM, доступного для загрузки с официального веб-сайта этой книги (http://www.fuzzing.org).

Наша первая задача разработки заключается в перечислении всех объектов COM, доступных в целевой системе. Полный список объектов COM опубликован в реестре Windows^[8] в разделе HKEY_LOCAL_MACHINE (HKLM) и подразделе SOFTWARE\Classes. Получить доступ к этому разделу можно с помощью стандартного API доступа к реестру Windows:^[9]

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

В совокупности эти фрагменты создают список кортежей, описывающих каждый доступный в системе объект COM. Тестирование безопасности объектов COM обычно ограничено элементами управления, доступными Internet Explorer. Причина в том, что самым популярным методом эксплуатации ActiveX с большим отрывом является размещение злоумышленником вредоносного веб-сайта и принуждение пользователей, у которых установлен уязвимый компонент, посетить эту страницу. Поскольку в Internet Explorer доступны лишь некоторые из этих элементов управления, наша вторая задача заключается в удалении недоступных из списка. Internet Explorer загрузит элемент управления ActiveX без предупреждения, если выполнен любой из следующих трёх критериев:^[10]

• в реестре Windows элемент управления помечен как «Safe for Scripting»;

• в реестре Windows элемент управления помечен как «Safe for Initialization»;

• элемент управления реализует COM-интерфейс IObjectSafety.

Реестр Windows содержит раздел Component Categories, в котором перечислены подразделы для каждой категории, реализованной установленными компонентами. Две нужные нам категории называются CATID_SafeForScripting и CATID_SafeForInitializing. Следующие процедуры определят, помечен ли заданный CLSID в реестре как доступный в Internet Explorer:

Помимо реестра, элемент управления ActiveX может пометить себя безопасным для Internet Explorer, реализовав интерфейс IObjectSafety. Чтобы определить, реализует ли данный элемент управления ActiveX интерфейс IObjectSafety, сначала необходимо создать его экземпляр, а затем выполнить запрос. Следующая процедура определит, реализует ли данный элемент управления интерфейс IObjectSafety и, следовательно, доступен ли он Internet Explorer:

Чтобы завершить формирование списка загружаемых элементов управления ActiveX, мы должны учесть последнее обстоятельство. Microsoft предоставляет механизм установки бита блокировки,^[11] то есть предотвращения загрузки отдельных CLSID в Internet Explorer, с помощью раздела реестра HKLM\Software\Microsoft\Internet Explorer\ActiveX Compatibility\<CLSID of ActiveX Control>. Каждый CLSID, для которого в этом расположении реестра существует запись, необходимо удалить из нашего списка. Следующую функцию можно использовать, чтобы определить, был ли заданный CLSID отключён таким способом:

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

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

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

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

Таблица 18.1. Преобразование VARIANT в PythonCOM

Модуль pythoncom предоставляет процедуру LoadTypeLib() для разбора библиотеки типов непосредственно из двоичного объекта COM. Всё, что нам необходимо знать о свойствах и методах объекта COM, доступно через загруженную библиотеку типов. В качестве примера пройдём по библиотеке типов элемента управления Adobe Acrobat PDF, ранее показанного на рисунке 18.2. Этот элемент управления ActiveX входит в комплект Adobe Acrobat Reader и доступен Internet Explorer, поскольку помечен как безопасный и для сценариев, и для инициализации. Следующий фрагмент демонстрирует загрузку библиотеки типов для этого кода и дополнительно применяет небольшую хитрость Python, чтобы создать отображение имён VARIANT:

Сгенерированное отображение имён VARIANT используется исключительно в демонстрационных целях, как мы увидим позднее. Библиотека типов может определять несколько типов, а их количество для перебора можно получить вызовом GetTypeInfoCount(). В нашем примере присутствуют три типа, показанные в первом столбце рисунка 18.2. Следующий пример показывает, как перебрать различные типы и вывести их имена:

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

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

В этом случае переменная атрибута cFuncs указывает число методов, определённых в этом типе. Методы перечисляются с пропуском тех, для которых установлен wFuncFlags. Этот флаг указывает, что метод ограничен, то есть недоступен, и потому не является хорошим кандидатом для фаззинга. Процедура GetNames() возвращает имя метода, а также имена каждого из его параметров. Имя метода выводится, после чего выполняется обход оставшейся части списка, names[1:], для доступа к параметрам. Описание функции, первоначально возвращённое вызовом GetFuncDesc(), содержит список типов VARIANT для каждого параметра, или аргумента. Тип VARIANT представлен целым числом, которое мы преобразуем в имя посредством индексирования ранее сгенерированного отображения VARIANT.

Ниже приведён конечный результат выполнения этого сценария против этого сценария на интерфейсе IAcroAXDocShim элемента управления ActiveX Adobe Acrobat PDF:

В выведенных результатах видно, что в этом типе определено 39 методов, или функций, и ни одного свойства. Список параметров и типов каждого метода был успешно перечислен и отображён. Эти сведения критически важны при разработке интеллектуального фаззера, их следует использовать при создании тестовых случаев, чтобы каждый параметр фаззился соответствующим образом. Например, рассмотрим фаззинг короткого целого (VT_I2) в сравнении с длинным целым (VT_I4). Вместо того чтобы считать оба этих типа обобщённым целым, можно сэкономить драгоценное время, фаззя короткое целое в допустимом диапазоне от 0 до 0xFFFF (65 535), а не в допустимом диапазоне полноразмерного целого, длинного, который простирается от 0 до 0xFFFFFFFF (4 294 967 295).

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

В главе 6, «Автоматизация и генерация данных», рассматривалась важность выбора осмысленных фаззинговых значений строк и целых чисел. Выбранные эвристики фаззинга были предназначены для максимального повышения вероятности вызвать ошибку. Большинство фаззеров и тестовых случаев, описанных в этой книге, фактически предназначены для выявления низкоуровневых дефектов, таких как переполнения буфера, а не логических проблем, таких как доступ к ограниченным ресурсам. Модификаторы обхода каталогов являются примером эвристики, нацеленной на обнаружение таких уязвимостей безопасности. При поиске нарушений поведения во время фаззинга элементов управления ActiveX требуется дополнительная осмотрительность, поскольку исследователи часто обнаруживают элементы управления, которые попросту никогда не должны были быть доступны через Internet Explorer.

Рассмотрим, например, уязвимость раскрытия небезопасного метода элемента управления ActiveX WinZip FileView.^[12] В данном случае элемент управления ActiveX с ProgID WZFILEVIEW.FileViewCtrl.61 распространялся как безопасный для сценариев, позволяя вредоносному веб-сайту загружать элемент управления в браузер и использовать предоставляемую им функциональность. В частности, методы ExeCmdForAllSelected и ExeCmdForFolder позволяют вызывающей стороне копировать, перемещать, удалять и исполнять файлы из произвольных расположений, включая сетевые общие ресурсы, каталоги FTP и веб-каталоги. Это предоставляет злоумышленникам тривиальный вектор для загрузки и запуска произвольного исполняемого файла без какого-либо предупреждения посредством простого размещения вредоносного веб-сайта. WinZip выпустила исправление этой проблемы, удалив параметр безопасности для сценариев и дополнительно установив бит блокировки для конкретного элемента управления.

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

После создания подходящего списка фаззинговых данных следующий шаг заключается в создании ряда тестовых случаев. Один подход к выполнению этой задачи состоит в построении страницы HTML, которая встраивает целевой элемент управления ActiveX любым из ранее перечисленных методов, а затем вызывает целевой метод с фаззинговыми параметрами. Для каждого теста можно создать отдельный файл, после чего загружать отдельные тестовые случаи в Internet Explorer. В качестве альтернативы целевой элемент управления можно загрузить и тестировать непосредственно. Продолжая предыдущие примеры, следующий фрагмент Python создаст экземпляр элемента управления ActiveX Adobe Acrobat PDF и обратится к двум его предоставляемым методам:

Первая строка этого фрагмента отвечает собственно за создание экземпляра объекта COM Adobe, доступного через переменную с именем adobe. После создания взаимодействовать с объектом можно совершенно естественным образом. Вторая строка выводит результаты вызова процедуры GetVersions(), а третья заставляет элемент управления загрузить файл PDF в средство просмотра Acrobat Reader. Расширить этот пример для фаззинга других методов, параметров и элементов управления совсем несложно.

Оставшейся частью головоломки является функция мониторинга фаззера. Помимо модулей COM для Python, мы используем библиотеку обратной разработки PaiMei^[13] для реализации фаззингового монитора на основе отладчика. Эта библиотека широко используется в последующих главах, где рассматривается более подробно. По существу, создаётся облегчённый отладчик, оборачивающий выполнение целевых элементов управления ActiveX. В случае обнаружения низкоуровневой уязвимости, такой как переполнение буфера, задействуется отладчик и записываются подробности дефекта. Библиотека PaiMei также предоставляет функциональность перехвата вызовов API. Эта возможность используется для мониторинга поведенческих проблем. Наблюдая за аргументами вызовов библиотек Microsoft, таких как CreateFile()^[14] и CreateProcess(),^[15] мы можем определить, получил ли целевой элемент управления ActiveX успешный доступ к ресурсу, к которому не должен был обращаться. Рассмотрение подробностей функциональности перехвата API оставлено читателю в качестве упражнения.

В качестве последнего замечания стоит исследовать имена предоставляемых свойств и методов с помощью простых поисков по регулярным выражениям. Если вам встретятся методы с такими именами, как GetURL(), DownloadFile(), Execute() и так далее, возможно, вы захотите сразу уделить им личное внимание.

На этом этапе мы обсудили основы организации памяти Windows, составили список требований, выбрали язык разработки, рассмотрели основы модуля ctypes и немного поэкспериментировали с основами API отладки Windows. Остаётся несколько нерешённых вопросов:

• Как реализовать нашу потребность «подключаться» к целевому процессу в конкретных точках?

• Как обрабатывать снимки процесса и восстановления?

• Как находить и изменять целевое пространство памяти?

• Как выбирать точки подключения?

Как мы уже упоминали в этой главе, при выбранном подходе подключение к процессу можно реализовать с помощью точек останова отладчика. На заданной платформе поддерживаются два типа точек останова: аппаратные и программные. Совместимые с 80x86 процессоры поддерживают до четырёх аппаратных точек останова. Каждую из них можно настроить на срабатывание при чтении, записи или исполнении любого диапазона длиной один, два или четыре байта. Для установки аппаратных точек останова необходимо изменить контекст целевого процесса, манипулируя отладочными регистрами с DR0 по DR3 и DR7. Первые четыре регистра содержат адрес аппаратной точки останова. Регистр DR7 содержит флаги, указывающие, какие точки останова активны, для какого диапазона и какого типа доступа, чтения, записи или исполнения. Аппаратные точки останова неинтрузивны и не изменяют код. Программные точки останова, напротив, должны изменять целевой процесс и реализуются однобайтной инструкцией INT3, представленной в шестнадцатеричном виде как 0xCC.

Для выполнения нашей задачи можно было бы использовать как аппаратные, так и программные точки останова. Поскольку в какой-то момент нам может потребоваться более четырёх точек подключения, мы решаем использовать программные точки останова. Чтобы хорошо понять процесс, давайте пройдём необходимые шаги установки программной точки останова в вымышленной программе по адресу 0xDEADBEEF. Сначала наш отладчик должен прочитать и сохранить исходный байт по целевому адресу с помощью упомянутого ранее вызова API ReadProcessMemory, как показано на рисунке 20.3.

Рисунок 20.3. Сохранение исходного байта по адресу точки останова

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

Рисунок 20.4. Запись кода операции INT3

Но что случилось с нашими прежними инструкциями? Вставленный 0xCC дизассемблируется как однобайтная инструкция INT3. Второй байт инструкции mov edi, edi (0xFF), объединённый с байтом, ранее представлявшим push ebp (0x55), и первым байтом инструкции mov ebp, esp (0x8B), дизассемблируются как инструкция call [ebp-75]. Оставшийся байт 0xEC дизассемблируется как однобайтная инструкция in al, dx. Теперь, когда исполнение достигнет адреса 0xDEADBEEF, инструкция INT3 вызовет событие отладки EXCEPTION_DEBUG_EVENT с кодом исключения EXCEPTION_BREAKPOINT, которое наш отладчик перехватит в цикле событий отладки, помните Агнес? Состояние процесса в этот момент показано на рисунке 20.5.

Рисунок 20.5. Перехвачено EXCEPTION_BREAKPOINT

Итак, теперь мы успешно вставили и перехватили программную точку останова, но это лишь половина дела. Обратите внимание, что наши исходные инструкции всё ещё отсутствуют. Кроме того, указатель инструкций, EIP, который сообщает ЦП, откуда извлечь, декодировать и исполнить следующую инструкцию, находится по адресу 0xDEADBEF0, а не 0xDEADBEEF. Причина в том, что единственная инструкция INT 3, вставленная нами по адресу 0xDEADBEEF, была успешно исполнена, в результате чего EIP обновился до 0xDEADBEEF+1. Прежде чем продолжить, нам придётся исправить значение EIP и восстановить исходный байт по адресу 0xDEADBEEF, как показано на рисунке 20.6.

Рисунок 20.6. Корректировка EIP

Восстановление байта по адресу 0xDEADBEEF является уже знакомой нам задачей. Однако изменение значения указателя инструкций, регистра EIP, это совсем другая история. Ранее в этой главе мы упоминали, что контекст потока содержит различные зависящие от процессора данные регистров, такие как указатель инструкций EIP, который сейчас нас интересует. Получить контекст любого заданного потока можно вызовом API GetThreadContext(),^[10] передав ему дескриптор текущего потока и указатель на структуру CONTEXT. Затем мы можем изменить содержимое структуры CONTEXT и вызвать API SetThreadContext(),^[11] снова передав дескриптор текущего потока для изменения контекста:

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

Чтобы ответить на этот вопрос, сначала следует рассмотреть другой: что изменяется во время работы процесса? Очень многое. Создаются и уничтожаются новые потоки. Открываются и закрываются дескрипторы файлов, сокетов, окон и других элементов. Память выделяется и освобождается, из неё читают и в неё записывают. Различные регистры в контекстах отдельных потоков крайне изменчивы и постоянно меняются. Мы могли бы выполнить задачу с помощью технологии виртуальных машин, такой как VMWare,^[12] которая позволяет делать и восстанавливать полные снимки системы. Однако этот процесс мучительно медленен и требует взаимодействия между гостевой системой виртуальной машины и некоторой формой посредника на узле виртуальной машины. Вместо этого мы заимствуем ранее обсуждавшийся метод^[13] и «жульничаем», занимаясь только контекстами потоков и изменениями памяти. Процесс создания снимка будет состоять из двух шагов.

На первом шаге мы сохраняем контекст каждого потока внутри целевого процесса. Мы уже видели, насколько легко получать и задавать контексты отдельных потоков. Теперь этот код необходимо обернуть логикой, отвечающей за перечисление системных потоков, которые принадлежат целевому процессу. Для этого мы полагаемся на Tool Help Functions.^[14] Сначала получаем список всех системных потоков, указав флаг TH32CS_SNAPTHREAD:

Далее мы получаем из списка первую запись потока. Однако до этого обязательное требование API Thread32First() состоит в инициализации переменной dwSize внутри структуры записи потока. API Thread32First() мы передаём ранее сделанный снимок и указатель на структуру записи потока:

Наконец, перебираем потоки в поисках принадлежащих идентификатору процесса (pid) нашей цели. Если такие есть, получаем дескриптор потока с помощью API OpenThread(), получаем контекст, как прежде, и добавляем его в список:

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

На втором шаге мы сохраняем содержимое каждого изменяемого блока памяти. Вспомните из предыдущей главы, что каждый процесс на 32-битной платформе Windows x86 «видит» собственное пространство памяти объёмом 4 Гбайт. Из этих 4 Гбайт обычно нижняя половина зарезервирована для использования нашим процессом (0x0000000-0x7FFFFFFF). Это пространство памяти далее разделено на отдельные страницы, обычно размером 4096 байт. Наконец, разрешения памяти с наименьшей гранулярностью применяются к каждой отдельной странице. Вместо хранения содержимого каждой отдельно используемой страницы памяти мы экономим время и ресурсы, ограничивая снимок страницами, которые считаем изменяемыми. Мы игнорируем все страницы с ограничительными разрешениями, предотвращающими запись. Сюда входят страницы, помеченные как:

• PAGE_READONLY

• PAGE_EXECUTE_READ

• PAGE_GUARD

• PAGE_NOACCESS

Мы также хотим игнорировать страницы, принадлежащие исполняемым образам, поскольку они вряд ли изменятся. Для прохода по всем доступным страницам памяти требуется простой цикл вокруг процедуры API VirtualQueryEx(),^[15] предоставляющей сведения о страницах в указанном диапазоне виртуальных адресов:

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

Если нам встречается блок памяти, который мы хотим включить в снимок, мы читаем его содержимое с помощью API ReadProcessMemory()^[16] и сохраняем необработанные данные, а также сведения о памяти в списке снимка. Наконец, увеличиваем курсор сканирования памяти и продолжаем:

Возможно, вы сразу заметили изъян в нашей методологии. Что, если во время создания снимка заданная страница помечена как PAGE_READONLY, но позднее изменяется на доступную для записи и модифицируется? Хорошее замечание, ответ состоит в том, что мы упускаем такие случаи. Мы никогда не обещали, что подход будет совершенным! Фактически воспользуемся этой возможностью, чтобы снова подчеркнуть экспериментальный характер предмета. Для любознательных читателей одним потенциальным решением этого недостатка является «подключение» к различным функциям, изменяющим разрешения памяти, и изменение нашего мониторинга на основании наблюдаемых изменений.

В совокупности два наших шага предоставляют необходимые элементы для создания и восстановления снимков конкретного процесса.

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

Чтобы хорошо это почувствовать, позднее мы пошагово рассмотрим пример.

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

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

Написанный на Python antiparser представляет собой API, предназначенный для помощи в создании случайных данных специально для построения фаззеров. Этот каркас можно использовать для разработки фаззеров, работающих на нескольких платформах, поскольку он зависит исключительно от наличия интерпретатора Python. Использование каркаса довольно прямолинейно. Сначала необходимо создать экземпляр класса antiparser, этот класс служит контейнером. Далее antiparser предоставляет ряд типов фаззинга, экземпляры которых можно создавать и добавлять в контейнер. К доступным типам фаззинга относятся следующие:

• apChar(): восьмибитный символ C.

• apCString(): строка в стиле C, то есть массив символов, завершающийся нулевым байтом.

• apKeywords(): список значений, каждое из которых связано с разделителем, блоком данных и ограничителем.

• apLong(): 32-битное целое C.

• apShort(): 16-битное целое C.

• apString(): строка свободной формы.

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

antiparser распространяет пример сценария evilftpclient.py, использующий тип данных apKeywords(). Давайте исследуем части сценария, чтобы лучше понять, как выглядит разработка на этом каркасе. Следующая выдержка кода Python показывает относящиеся к делу части evilftpclient.py, отвечающие за тестирование демона FTP на уязвимости строки формата при разборе аргументов команд FTP. Например, в этой выдержке не показана функциональность аутентификации с целевым демоном FTP. Полный листинг см. в исходном коде.

Код начинается с импорта всех доступных типов данных и классов из каркаса antiparser, определения списка команд FTP, символа-разделителя аргумента команды, пробела, и последовательности завершения команды, возврата каретки, за которым следует новая строка. Затем каждая перечисленная команда FTP перебирается и тестируется отдельно, начиная с создания экземпляра нового класса-контейнера antiparser. Далее вступает в действие тип данных apKeywords(). В качестве ключевых слов, в данном случае ключевого слова, указывается список, определяющий один элемент, текущую тестируемую команду. Затем определяются соответствующие символы разделения команды и аргумента и завершения команды. Содержимое данных созданного объекта apKeyword() устанавливается в последовательность токенов строки формата. Если целевой сервер FTP предоставляет уязвимость строки формата при разборе аргументов команд, это содержимое данных наверняка её вызовет.

Следующие два вызова, setMode(‘incremental’) и setMaxSize(65536), указывают, что при перестановке блок данных должен последовательно расти до максимального значения 65 336. Однако в данном конкретном случае эти два вызова несущественны, поскольку фаззер не перебирает множество тестовых случаев или перестановок вызовом ap.permute(). Вместо этого каждая команда тестируется с единственным блоком данных.

Оставшиеся строки кода в основном говорят сами за себя. Единственный тип данных, apKeywords(), добавляется в контейнер antiparser, и создаётся сокет. После установления соединения тестовый случай создаётся вызовом ap.getPayload() и передаётся посредством sock.sendTCP().

Очевидно, что antiparser имеет ряд ограничений. Примерный фаззер FTP можно легко воспроизвести на чистом Python без помощи каркаса. Соотношение кода, специфичного для каркаса, и обобщённого кода при разработке фаззеров на antiparser значительно ниже, чем у других каркасов. В каркасе также отсутствуют многие желательные средства автоматизации, перечисленные в предыдущем разделе, например возможность автоматически вычислять и представлять распространённый формат протокола TLV. В качестве последнего замечания, документация этого каркаса скудна и, к сожалению, по состоянию на версию 2.0, выпущенную в августе 2005 года, доступен лишь один пример. Хотя этот каркас прост и предоставляет некоторые преимущества при создании простых фаззеров, для выполнения сложных задач он непригоден.

Написанный на C Диего Бауче, Dfuz является активно сопровождаемым и часто обновляемым каркасом фаззинга. Этот каркас использовался для выявления различных уязвимостей, затрагивающих таких поставщиков, как Microsoft, Ipswitch и RealNetworks. Исходный код открыт и доступен для загрузки, но ограничительная лицензия запрещает любое дублирование или изменение без явного разрешения автора. В зависимости от ваших потребностей эта ограниченная лицензия может отвратить вас от использования каркаса. Мотивирующим фактором такой жёсткой лицензии, по-видимому, является недовольство автора качеством собственного кода, согласно файлу README. Возможно, стоит попробовать связаться с ним напрямую, если вы хотите повторно использовать части его кода. Dfuz был спроектирован для работы в UNIX/Linux и предоставляет специализированный язык для разработки новых фаззеров. Этот каркас не является самым продвинутым из разобранных в данной главе. Однако простой и интуитивный проект делает его хорошим практическим примером проектирования каркаса, поэтому давайте исследуем его подробно.

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

Переменные определяются простым префиксом var, а ссылаться на них из других мест можно, добавляя к имени переменной знак доллара, $, как в Perl или PHP. Создание фаззера целиком самодостаточно. Это означает, что, в отличие, например, от antiparser, построение фаззера поверх этого каркаса выполняется полностью на его специализированном языке сценариев.

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

• %attach(): ожидать нажатия клавиши Enter или Return. Это полезно для приостановки фаззера ради выполнения другой задачи. Например, если ваша цель фаззинга порождает новый поток для обработки входящих соединений и вы хотите присоединить отладчик к этому новому потоку, вставьте вызов %attach() после установления первоначального соединения, затем найдите целевой поток и присоединитесь к нему.

• %length() или %calc(): вычислить и вставить размер переданного аргумента в двоичном формате. Например, %length(“AAAA”) вставит в двоичный поток двоичное значение 0x04. Размер вывода по умолчанию для этих функций равен 32 битам, но его можно изменить на 8 бит вызовом %length:uint8() или на 16 бит вызовом %length:uint16().

• %put:<size>(number): вставить указанное число в двоичный поток. Размер можно указать как byte, word или dword, являющиеся псевдонимами uint8, uint16 и uint32 соответственно.

• %random:<size>(): создать и вставить случайное двоичное значение указанного размера. Подобно %put(), размер можно указать как byte, word или dword, являющиеся псевдонимами uint8, uint16 и uint32 соответственно.

• %random:data(<length>,<type>): создать и вставить случайные данные. length указывает число создаваемых байтов. type указывает вид создаваемых случайных данных и может иметь значение ascii, alphanum, plain или graph.

• %dec2str(num): преобразовать десятичное число в строку и вставить её в двоичный поток. Например, %dec2str(123) создаёт 123.

• %fry(): случайным образом изменить ранее определённые данные. Например, правило “AAAA”,%fry() приведёт к замене случайного числа символов строки “AAAA” случайным байтовым значением.

• %str2bin(): разбирает различные шестнадцатеричные представления строк в их необработанное значение. Например, 4141, 41 41 и 41-41 будут преобразованы в AA.

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

Списки объявляются ключевым словом list, за которым следуют имя списка, ключевое слово begin, список значений данных, разделённых новыми строками, и, наконец, завершающее ключевое слово end. Список можно использовать для определения и индексирования последовательности данных. Например:

Подобно переменным, на списки можно ссылаться из других мест, добавляя к имени списка знак доллара ($). Синтаксисом, сходным с другими языками сценариев, такими как Perl и PHP, элемент списка можно индексировать посредством квадратных скобок: $my_list[1]. Поддерживаются также случайные индексы внутри списка посредством ключевого слова rand: $my_list[rand].

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

• keep_connecting: продолжать фаззинг цели, даже если соединение установить невозможно.

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

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

• tcp: указать, что соединения сокетов следует устанавливать по TCP.

• udp: указать, что соединения сокетов следует устанавливать по UDP.

• client_side: указать, что механизм будет фаззить сервер и тем самым действовать как клиент.

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

• use_stdout: создавать данные в стандартный вывод, консоль, а не подключённому через сокет партнёру. Этот параметр необходимо сочетать со значением узла “stdout”.

Чтобы облегчить бремя воспроизведения часто фаззимых протоколов, Dfuz умеет эмулировать протоколы FTP, POP3, Telnet и Server Message Block (SMB). Эта функциональность предоставляется посредством таких функций, как ftp:user(), ftp:pass(), ftp:mkd(), pop3:user(), pop3:pass(), pop3:dele(), telnet:user(), telnet:pass(), smb:setup() и так далее. Полный список см. в документации Dfuz.

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

Первая директива указывает, что механизм должен подключиться по TCP-порту 21. Поскольку параметры не указаны, по умолчанию он ведёт себя как клиент. Директивы peer read и peer write указывают механизму, когда соответственно следует читать данные из цели фаззинга и записывать их в неё. В данном конкретном файле правил функциональность протокола FTP используется для аутентификации с целевым сервером FTP. Далее команда Change Working Directory (CWD) вручную строится и передаётся серверу. Команде CWD передаётся 1024 случайных байта буквенно-цифровых данных, за которыми следует завершающая новая строка (0x0a). Наконец, соединение закрывается. Последняя директива repeat указывает, что блок чтения и записи партнёра следует выполнить 1024 раза. Для каждого тестового случая Dfuz установит аутентифицированное соединение с сервером FTP, выдаст команду CWD со случайной буквенно-цифровой строкой длиной 1024 байта в качестве аргумента и разорвёт соединение.

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

SPIKE, написанный Дейвом Айтелом, вероятно, является самым широко используемым и известным каркасом фаззинга. SPIKE написан на C и предоставляет API для быстрой и эффективной разработки фаззеров сетевых протоколов. SPIKE имеет открытый исходный код и выпущен под гибкой лицензией GNU General Public License (GPL).^[7] Такое благоприятное лицензирование позволило создать SPIKEfile, перепрофилированную версию каркаса, предназначенную специально для фаззинга форматов файлов, см. главу 12, «Фаззинг форматов файлов: автоматизация в UNIX». SPIKE использует новый метод представления и последующего фаззинга сетевых протоколов. Структуры данных протокола разбиваются и представляются в виде блоков, также называемых SPIKE, содержащих и двоичные данные, и размер блока. Блочное представление протокола позволяет абстрагированно строить различные уровни протокола с автоматическим вычислением размеров.

Чтобы лучше понять блочную концепцию, рассмотрим следующий простой пример из технического документа «The Advantages of Block-Based Protocol Analysis for Security Testing»:^[8]

Этот базовый сценарий SPIKE, сценарии SPIKE пишутся на C, определяет блок с именем somepacketdata, помещает в него четыре байта 0x01020304 и добавляет перед блоком его длину. В данном случае длина блока будет вычислена как 4 и сохранена как слово в порядке от старшего байта к младшему. Обратите внимание, что перед большей частью API SPIKE стоит префикс s_ или spike_. API s_binary() используется для добавления двоичных данных в блок и весьма либерален к формату аргумента, позволяя обрабатывать широкий спектр скопированных и вставленных входных данных, таких как строка 4141 \x41 0x41 41 00 41 00. Несмотря на простоту, этот пример демонстрирует основы и общий подход к построению SPIKE. Поскольку SPIKE позволяет встраивать блоки внутрь других блоков, произвольно сложные протоколы легко разбиваются на мельчайшие атомы. Расширим предыдущий пример:

В этом примере определены два блока, somepacketdata и innerdata. Второй содержится внутри первого, и перед каждым отдельным блоком помещено значение размера. Новый определённый блок innerdata начинается со статического двухбайтного значения (0x0001), за которым следуют четырёхбайтное переменное целое со значением по умолчанию 0x02 и, наконец, строковая переменная со значением по умолчанию SELECT. API s_binary_bigendian_word_variable() и s_string_variable() будут перебирать предопределённые наборы соответственно целых и строковых переменных, эвристик атаки, которые, как ранее было известно, выявляли уязвимости безопасности. SPIKE начнёт с перебора возможных мутаций переменной-слова, после чего перейдёт к мутации строковой переменной. Истинная мощь этого каркаса состоит в том, что SPIKE автоматически обновляет значения каждого поля размера по мере выполнения различных мутаций. Чтобы исследовать или расширить текущий список фаззинговых переменных, загляните в SPIKE/src/spike.c. Версия 2.9 каркаса содержит список почти из 700 эвристик, вызывающих ошибки.

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

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

В зависимости от ваших индивидуальных потребностей одним из главных недостатков каркаса SPIKE является отсутствие поддержки Microsoft Windows, поскольку SPIKE был предназначен для работы в среде UNIX, хотя существуют противоречивые сообщения о запуске SPIKE на платформе Windows через Cygwin.^[9] Другим фактором, который следует учесть, является то, что даже незначительные изменения каркаса, такие как добавление новых фаззинговых строк, требуют повторной компиляции. В качестве последнего негативного замечания, повторное использование кода между разработанными фаззерами требует ручного копирования и вставки. Новые элементы, такие как фаззер адресов электронной почты, невозможно просто определить, а позднее глобально использовать по ссылке во всём каркасе.

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

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

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

Преобразователи изменяют данные определённым образом. Примерами преобразователей могут быть кодировщик base64, gzip и кодирование HTML. Преобразователи также можно соединять в цепочки и связывать с генератором. Например, созданный адрес электронной почты можно передать через преобразователь URL-кодирования, а затем снова через преобразователь gzip. Абстрагирование преобразования данных в отдельный объект позволяет легко повторно использовать код в реализованных фаззерах. После реализации заданного преобразования его можно прозрачно повторно использовать во всех разрабатываемых в будущем фаззерах.

Издатели реализуют форму транспорта созданных данных через протокол. Примерами являются файловые издатели и издатели TCP. И снова абстрагирование этой концепции в отдельный объект способствует повторному использованию кода. Хотя в текущей версии Peach это невозможно, конечная цель издателей заключается в возможности прозрачного взаимодействия с любым издателем. Рассмотрим, например, что вы создаёте генератор изображений GIF. Этот генератор должен уметь публиковать данные в файл или отправлять их в веб-форму простой заменой указанного издателя.

Группы содержат один или несколько генераторов и являются механизмом перебора значений, которые способен создавать генератор. Peach включает несколько стандартных реализаций групп. Дополнительный компонент, объект Script, представляет собой простую абстракцию для сокращения объёма избыточного кода, необходимого для реализации циклического перебора данных посредством вызовов group.next() и protocol.step().

В качестве полного, но простого примера рассмотрим следующий фаззер Peach, предназначенный для перебора пароля пользователя FTP по файлу словаря:

Фаззер начинает с импорта различных компонентов каркаса Peach. Далее создаются новые блок и группа. Блок определяется для передачи имени пользователя, а затем команды пароля. Следующий элемент блока импортирует словарь потенциальных паролей. Именно этот элемент блока будет перебираться во время фаззинга. Последний элемент блока завершает команду пароля и выдаёт команду FTP quit для отключения от сервера. Определяется новый протокол, расширяющий уже доступный протокол FTP. Наконец, создаётся объект сценария, организующий цикл соединений и итераций по словарю. Первая мысль, которая может прийти в голову после просмотра этого сценария, заключается в том, что взаимодействие с каркасом не очень интуитивно. Это справедливая критика и, вероятно, самый большой недостаток Peach.

Разработка первого фаззера в Peach определённо займёт у вас больше времени, чем разработка первого фаззера в Autodafé или Dfuz.

Архитектура Peach позволяет исследователю сосредоточиться на отдельных подкомпонентах заданного протокола, позднее связав их для создания полного фаззера. Этот подход к разработке фаззеров, хотя, вероятно, и не столь быстр, как блочный подход, определённо больше всех прочих каркасов фаззинга способствует повторному использованию кода. Например, если для тестирования антивирусного решения необходимо разработать преобразователь gzip, он становится доступным в библиотеке для прозрачного последующего использования при тестировании способности сервера HTTP обрабатывать сжатые данные. Это прекрасная грань Peach. Чем больше вы его используете, тем умнее он становится. Благодаря реализации целиком на Python фаззер Peach можно запускать в любой среде с подходящей установкой Python. Кроме того, используя существующие интерфейсы, такие как Python, Microsoft COM^[11] или пакеты Microsoft .NET, Peach позволяет напрямую фаззить элементы управления ActiveX и управляемый код. Также предоставлены примеры прямого фаззинга DLL Microsoft Windows и встраивания Peach в код C/C++ для создания инструментированных клиентов и серверов.

Peach активно разрабатывается, и на момент публикации последней доступной версией является 0.5, выпущенная в апреле 2006 года. Хотя теоретически Peach весьма продвинут, к сожалению, он не имеет подробной документации и не используется широко. Отсутствие справочных материалов приводит к существенной кривой обучения, которая может отвратить вас от рассмотрения этого каркаса. Автор Peach представил несколько новых идей и создал прочное основание для расширения. В качестве последнего замечания, был объявлен перенос каркаса Peach на Ruby, хотя на момент написания дополнительные подробности отсутствовали.

General Purpose Fuzzer (GPF), выпущенный Джаредом ДеМоттом из Applied Security, назван как игра слов с широко известным термином general protection fault. GPF активно сопровождается, доступен с открытым исходным кодом под лицензией GPL и разработан для работы на платформе UNIX. Как следует из названия, GPF спроектирован как обобщённый фаззер; в отличие от SPIKE, он способен создавать бесконечное число мутаций. Это не значит, что генерационные фаззеры превосходят эвристические, поскольку обе методологии имеют плюсы и минусы. Главное преимущество GPF над другими каркасами, перечисленными в этом разделе, заключается в низком пороге запуска работающего фаззера. GPF предоставляет функциональность посредством ряда режимов, включая PureFuzz, Convert, GPF, основной режим, Pattern Fuzz и SuperGPF.

PureFuzz является простым в использовании чисто случайным фаззером, похожим на подключение /dev/urandom к сокету. Хотя создаваемое пространство входных данных неинтеллектуально и бесконечно, этот метод ранее обнаруживал уязвимости даже в распространённом корпоративном программном обеспечении. Главное преимущество PureFuzz над сочетанием netcat и /dev/urandom состоит в том, что PureFuzz предоставляет параметр начального значения, позволяющий воспроизводить псевдослучайный поток. Кроме того, если PureFuzz достигает успеха, конкретные пакеты, отвечающие за возникновение исключения, можно точно определить посредством параметра диапазона.

Convert является утилитой GPF, способной преобразовывать файлы libpcap, например созданные Ethereal^[14] и Wireshark,^[15] в файл GPF. Эта утилита снимает часть утомительной работы на начальных этапах моделирования протокола, преобразуя двоичный формат pcap, захват пакетов, в удобочитаемый и готовый к изменению текстовый формат.

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

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

Pattern Fuzz (PF) является самым примечательным режимом GPF благодаря способности автоматически разбивать на токены и фаззить обнаруженные части протоколов с обычным текстом. PF исследует целевые протоколы на распространённые границы ASCII и ограничители полей и автоматически фаззит их согласно набору внутренних правил. Внутренние правила определяются в коде C с названием tokAids. Механизм мутации ASCII определён как tokAid (normal_ascii), существуют и некоторые другие, например DNS. Для точного и интеллектуального моделирования и фаззинга специализированного двоичного протокола необходимо написать и скомпилировать tokAid.

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

И снова мы приводим пример сценария GPF для сравнения с ранее показанными фаззерами FTP:

Самым большим препятствием при работе с GPF является его сложность. Кривая обучения, необходимая для начала работы с GPF, значительна. Моделирование проприетарных двоичных протоколов с помощью tokAids не столь просто, как другие альтернативы, например блочный подход SPIKE, и, кроме того, требует компиляции для использования. Наконец, сильная зависимость от параметров командной строки приводит к таким громоздким командам, как следующая:

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

Проще всего Autodafé можно описать как следующее поколение SPIKE, которое можно использовать для фаззинга как сетевых протоколов, так и форматов файлов. Autodafé выпущен Мартином Вуаньу под гибкой GNU GPL и предназначен для работы на платформах UNIX. Подобно SPIKE, основной механизм фаззинга Autodafé применяет блочный подход к моделированию протоколов. Следующая выдержка из технического документа «Autodafé, an Act of Software Torture»^[17] демонстрирует блочный язык Autodafé и покажется знакомой пользователям SPIKE:

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

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

После запуска против целевого веб-сервера этот сценарий сначала переберёт ряд мутаций команд HTTP, а затем ряд мутаций аргумента команды. Предположим, что Autodafé содержит библиотеку замен фаззинговых строк из 500 записей. Общее число тестовых случаев, необходимое для завершения этого аудита, равно 500, умноженным на число переменных для фаззинга, всего 1000 тестовых случаев. В большинстве реальных ситуаций библиотека замен будет как минимум вдвое больше, а переменных для фаззинга могут быть сотни. Autodafé применяет интересный метод под названием Markers Technique, чтобы назначить каждой фаззинговой переменной вес. Autodafé определяет маркер как данные, строковые или числовые, которыми может управлять пользователь, или фаззер. Применённые веса используются для определения порядка обработки фаззинговых переменных с сосредоточением на тех, которые вероятнее приведут к обнаружению уязвимостей безопасности.

Для выполнения этой задачи Autodafé включает компонент отладчика под названием adbg. Технологии отладки традиционно использовались рядом с фаззерами и даже включались в конкретные инструменты фаззинга, такие как FileFuzz, см. главу 13, «Фаззинг форматов файлов: автоматизация в Windows», но Autodafé является первым каркасом фаззинга, явно включающим отладчик. Компонент отладчика используется Autodafé для установки точек останова на распространённых опасных API, таких как strcpy(), известный как источник переполнений буфера, и fprintf(), известный как источник уязвимостей строки формата. Фаззер передаёт тестовые случаи одновременно цели и отладчику. Затем отладчик отслеживает вызовы опасных API в поисках строк, происходящих из фаззера.

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

Autodafé включает несколько дополнительных инструментов, помогающих быстро и эффективно разрабатывать фаззеры. Первый инструмент, PDML2AD, может разбирать экспортированные Ethereal и Wireshark XML-файлы пакетных данных (PDML) в блочный язык Autodafé. Если ваш целевой протокол входит в число более чем 750 протоколов, распознаваемых этими популярными сетевыми анализаторами, основную часть утомительного блочного моделирования можно выполнить автоматически. Даже если целевой протокол не распознан, PDML2AD всё равно способен предоставить несколько сокращений пути, поскольку автоматически обнаружит поля обычного текста и создаст соответствующие вызовы hex(), string() и так далее. Второй инструмент, TXT2AD, представляет собой простой сценарий оболочки, преобразующий текстовый файл в сценарий Autodafé. Третий и последний инструмент, ADC, является компилятором Autodafé. ADC полезен при разработке сложных сценариев Autodafé, поскольку способен обнаруживать распространённые ошибки, такие как неправильные имена функций и незакрытые блоки.

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

В предыдущем разделе обсуждалась хорошая выборка доступных сейчас каркасов фаззинга. Более полный перечень см. на сопутствующем веб-сайте книги по адресу http://www.fuzzing.org. Мы рекомендуем вам загрузить отдельные пакеты каркасов и исследовать полную документацию и различные примеры. Ни один каркас не выделяется как лучший в своём классе, способный справиться с любой поставленной задачей лучше остальных. Вместо этого конкретный каркас может быть более применим в зависимости от конкретной цели, задач, сроков, бюджета и других факторов. Знакомство с несколькими каркасами предоставит группе тестирования гибкость для применения лучшего инструмента к каждой заданной работе.

Хотя большинство протоколов и форматов файлов можно легко описать как минимум в одном общедоступном каркасе фаззинга, будут случаи, когда не применим ни один из них. При аудите специализированного программного обеспечения или протокола решение создать новый фаззер для конкретной цели может дать лучшие результаты и сэкономить время на протяжении всего аудита. В этом разделе мы обсуждаем формат файла Adobe Macromedia Shockwave Flash^[18] (SWF) как реальную цель фаззинга и приводим части специализированного тестового решения.

Уязвимости безопасности в Shockwave Flash обычно имеют высокое воздействие, поскольку какая-либо версия Flash Player установлена почти на каждом настольном компьютере планеты. Фактически современные операционные системы Microsoft Windows по умолчанию поставляются с функциональной версией Flash Player. Разбор каждой подробности полномасштабного аудита SWF далеко выходит за рамки этой главы, поэтому обсуждаются лишь самые относящиеся к делу и интересные части. Дополнительные сведения, актуальные результаты и листинги кода^[19] см. на официальном веб-сайте книги по адресу http://www.fuzzing.org.

Несколько факторов делают SWF прекрасным кандидатом для специализированного решения фаззинга. Во-первых, структура формата файла SWF полностью документирована в справочнике разработчика Adobe под названием «Macromedia Flash (SWF) and Flash Video (FLV) File Format Specification».^[20] При написании этой работы использовалась версия документа 8. Если вы не проводите аудит формата файла с открытым исходным кодом или разработанного внутри организации, столь подробная документация обычно недоступна, что может ограничить тестирование более общими подходами. В данном конкретном случае мы определённо воспользуемся каждой подробностью, предоставленной Adobe и Macromedia. Исследование спецификации показывает, что формат файла SWF в основном разбирается как поток битов, а не с типичной гранулярностью на уровне байтов, с которой разбирается большинство файлов и протоколов. Поскольку SWF обычно передаются через Веб, вероятной мотивацией выбора разбора на уровне битов является минимизация размера. Это добавляет нашему фаззеру уровень сложности и даёт дополнительную причину создать специализированное решение, поскольку ни один из исследованных в этой главе каркасов фаззинга не поддерживает битовые типы.

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

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

• magic. Состоит из трёх байтов и для любого допустимого файла SWF должно иметь значение “FWS”.

• version. Состоит из одного байта, представляющего числовую версию Flash, создавшую файл.

• length. Четырёхбайтное значение, указывающее размер всего файла SWF.

• rect. Это поле разделено на пять компонентов:

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

• xmin, xmax, ymin и ymax. Эти поля представляют экранные координаты, по которым следует отрисовать содержимое Flash. Обратите внимание, что эти поля представляют не пиксели, а twips, единицу измерения Flash, равную 1/20 «логического пикселя».

В поле rect мы начинаем видеть сложность этого формата файла. Если значение поля nbits равно 3, общая длина части rect заголовка равна 5 + 3 + 3 + 3 + 3 = 17 бит. Если значение поля nbits равно 4, общая длина части rect заголовка равна 5 + 4 + 4 + 4 + 4 = 21 бит. Представить эту структуру с помощью одного из доступных каркасов фаззинга непросто. Последние два поля заголовка представляют скорость воспроизведения кадров и общее число кадров в файле SWF.

За заголовком следует ряд тегов, определяющих содержимое и поведение файла Flash. Первый тег, FileAttributes, был представлен во Flash версии 8 и является обязательным тегом, служащим двум целям. Во-первых, тег указывает, содержит ли файл SWF различные свойства, такие как заголовок и описание. Эти сведения не используются внутри, а предоставляются для справки внешним процессам, таким как поисковые системы. Во-вторых, тег указывает, должен ли Flash Player предоставить файлу SWF доступ к локальным или сетевым файлам. Каждый файл SWF имеет переменное число оставшихся тегов, относящихся к одной из двух категорий: теги определения и управления. Теги определения задают такое содержимое, как фигуры, кнопки и звук. Теги управления определяют такие понятия, как размещение и движение. Flash Player обрабатывает теги до встречи тега ShowFrame, в этот момент содержимое отрисовывается на экране. Файл SWF завершается обязательным тегом End.

Существует ряд доступных тегов на выбор, каждый состоит из двухбайтного заголовка тега, за которым следуют данные. В зависимости от длины данных тег можно определить как длинный или короткий. Если длина данных меньше 63 бит, тег считается коротким и определяется так: [десятибитный идентификатор тега] [шестибитная длина данных] [данные]. Если блок данных больше, тег считается длинным и определяется с дополнительным четырёхбайтным полем в заголовке, указывающим длину данных: [десятибитный идентификатор тега] [111111] [четырёхбайтная длина данных] [данные]. И снова мы видим, что сложность формата SWF плохо поддаётся моделированию в любом из вышеупомянутых каркасов фаззинга.

Дальше всё становится только хуже. Каждый тег имеет собственный набор полей. Некоторые содержат необработанные данные, другие состоят из базовых типов SWF с названием структуры (struct или structs). Каждая структура состоит из набора определённых полей, которые могут включать и необработанные данные, и даже другие структуры! И всё по-прежнему становится лишь хуже. Группы полей как внутри тегов, так и внутри структур могут быть определены или не определены в зависимости от значения другого поля внутри того же тега или структуры. Даже объяснение может запутать, поэтому давайте начнём строить снизу вверх, а затем покажем несколько примеров, чтобы всё объяснить лучше.

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

Базовый класс bit_field определяет ширину поля (width), максимальное число, которое способно представлять поле (max_num), значение поля (value), порядок битов поля (endian), флаг, указывающий, можно ли изменять значение поля (static), и, наконец, используемый внутри индекс (s_index). Класс bit_field дополнительно определяет ряд полезных функций:

• Процедура flatten() преобразует и возвращает ограниченную байтами последовательность необработанных байтов из поля.

• Процедура to_binary() может преобразовать числовое значение в строку битов.

• Процедура to_decimal() выполняет обратное действие, преобразуя строку битов в числовое значение.

• Процедура randomize() обновляет значение поля до случайного значения в допустимом диапазоне поля.

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

При построении сложного типа из строительного блока bit_field последние две процедуры можно вызывать для мутации созданной структуры данных. Затем структуру данных можно обойти и записать в файл посредством рекурсивного вызова процедур flatten() каждого отдельного компонента.

Используя эти базовые типы, теперь мы можем начать определять более простые структуры SWF, такие как RECT и RGB. Следующие выдержки кода показывают определения этих классов, наследующих от не показанного базового класса, определение базового класса см. по адресу http://www.fuzzing.org:

Эта выдержка также показывает простое сокращение, обнаруженное и согласованное во время разработки. Для упрощения фаззинга все поля переменной ширины определяются с максимальной длиной. Чтобы представлять структуры с зависимыми полями, из класса bit_field был выведен новый примитив dependent_bit_field, как показано здесь:

Этот расширенный класс задаёт индекс поля и значение, которые следует исследовать до создания и возврата данных. Если соответствующее поле, на которое ссылается dep, не содержит значения из списка vals, данные не возвращаются. Структура MATRIX демонстрирует использование нового определённого примитива:

Из этой выдержки видно, что поле NScaleBits внутри структуры MATRIX определено как поле шириной пять бит со значением по умолчанию 31, включаемое в структуру только в том случае, если значение поля с индексом 0 (HasScale) равно 1. Поля ScaleX, ScaleY, skew1 и skew2 также зависят от поля HasScale. Иными словами, если HasScale равно 1, эти поля допустимы. В противном случае они не должны быть определены. Подобным образом поле NRotateBits зависит от значения поля с индексом 4 (HasRotate). На момент написания в этой нотации было точно определено более 200 структур SWF.^[21]

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

Процедура flatten() базового класса тега автоматически вычисляет длину части данных и создаёт правильный короткий или длинный заголовок. На момент написания на этом каркасе было точно определено более 50 тегов SWF. Ниже приведено несколько примеров простой и средней сложности:

Представлено много сведений, поэтому давайте подведём итог. Чтобы правильно смоделировать произвольный SWF, мы начали с самого базового примитива bit_field. Из него вывели примитивы для байтов, слов, двойных и четверных слов. Также из bit_field мы вывели dependent_bit_field, из которого далее вывели зависимые байты, слова, двойные и четверные слова. Эти типы вместе с новым базовым классом образуют основу структур SWF. Базовый класс тегов выводится из базового класса структур и вместе со структурами и примитивами образует теги SWF. Дополнительное пояснение даёт связь, изображённая на рисунке 21.1.

Рисунок 21.1. Связь компонентов фаззера SWF

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

Вскоре после преодоления первой трудности, успешного представления базовых структур SWF, мы встречаем следующую. Спецификация SWF гласит, что теги могут зависеть только от ранее определённых тегов. При фаззинге тега с несколькими зависимостями сначала необходимо успешно разобрать все зависимости, иначе целевой тег никогда не будет достигнут. Угадывание допустимых значений полей является кропотливым процессом, но существует хитрая альтернатива. Используя Google SOAP API,^[22] мы можем искать в Вебе файлы SWF по ключевому слову filetype:swf. Пишется простой сценарий, последовательно выполняющий поиск filetype:swf, b filetype:swf и так далее до z filetype:swf. Сценарий разбирает возвращённые результаты, ищет и загружает обнаруженные файлы SWF. Файлы именуются по хешу MD5, чтобы предотвратить хранение дубликатов.

Паук собрал приблизительно 10 000 уникальных файлов SWF, занимающих более 3 Гбайт. Исследование поля версии в заголовке SWF позволяет получить статистическую выборку распределения, показанную в таблице 21.1.

Таблица 21.1. Распределение версий собранных пауком Flash SWF

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

Каркас обратной разработки PaiMei^[23] используется для облегчения создания экземпляров отдельных тестовых случаев и их мониторинга. PaiMei представляет собой набор классов на чистом Python, предназначенных для помощи в разработке инструментов автоматизации обратной разработки. Использование каркаса подробнее описано в главе 23. Фактический процесс тестирования сходен с применяемым обобщённым PaiMei FileFuzz и выглядит следующим образом:

1. Загрузить тестовый случай SWF в Flash Player под управлением сценарного отладчика PaiMei PyDbg.

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

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

4. Если за это время ошибка не обнаружена, закрыть экземпляр Flash Player.

5. Перейти к следующему тестовому случаю.

Для более эффективного тестирования можно изменить частоту кадров в заголовке SWF со значения по умолчанию 0x000C на максимальное 0xFFFF. Тем самым мы позволяем обработать более крупные части файла SWF за пять секунд, отведённых каждому тестовому случаю. Метод просмотра файлов SWF по умолчанию заключается в их загрузке в веб-браузер, такой как Microsoft Internet Explorer или Mozilla Firefox. Хотя этот подход приемлем в данном конкретном случае, альтернативным методом, оказывающимся удобным, особенно для фаззинга ActionScript,^[24] является использование SAFlashPlayer.exe. Этот небольшой автономный проигрыватель распространяется с Macromedia Studio.^[25]

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

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

Sulley является каркасом разработки фаззеров и фаззингового тестирования, состоящим из нескольких расширяемых компонентов. Sulley, по нашему скромному мнению, превосходит возможности большинства ранее опубликованных технологий фаззинга, как коммерческих, так и общедоступных. Цель каркаса состоит в упрощении не только представления данных, но также их передачи и мониторинга цели. Sulley ласково назван в честь существа из «Корпорации монстров»^[26], потому что, ну, он пушистый. Последнюю версию Sulley можно загрузить по адресу http://www.fuzzing.org/sulley.

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

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

1. Представление данных. Это первый шаг при использовании любого фаззера. Запустите цель и немного воздействуйте на несколько интерфейсов, одновременно перехватывая пакеты. Разбейте протокол на отдельные запросы и представьте их в Sulley в виде блоков.

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

3. Посмертный анализ. Просмотрите созданные данные и результаты мониторинга. Воспроизведите отдельные тестовые случаи.

Загрузив последнюю версию пакета Sulley с http://www.fuzzing.org, распакуйте его в выбранный каталог. Структура каталогов сравнительно сложна, поэтому давайте посмотрим, как всё организовано.

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

• archived_fuzzies: каталог свободной формы, организованный по имени цели фаззинга, для хранения архивных фаззеров и данных, созданных сеансами фаззинга.

• trend_server_protect_5168: этот завершённый фаззинг упоминается в пошаговом руководстве далее в документе.

• trillian_jabber: ещё один завершённый фаззинг, упоминаемый в документации.

• audits: записанные PCAP, корзины аварий, покрытие кода и графики анализа для активных сеансов фаззинга следует сохранять в этом каталоге. После завершения записанные данные следует перемещать в archived_fuzzies.

• docs: документация и созданные справочники API Epydoc.

• requests: библиотека запросов Sulley. Каждая цель должна получить собственный файл, в котором можно хранить несколько запросов.

• __REQUESTS__.html: этот файл содержит описания сохранённых категорий запросов и перечисляет отдельные типы. Сохраняйте алфавитный порядок.

• http.py: различные запросы фаззинга веб-серверов.

• trend.py: содержит запросы, связанные с полным пошаговым руководством по фаззингу, обсуждаемым далее в документе.

• sulley: каркас фаззера. Если вы не хотите расширять каркас, вам не потребуется трогать эти файлы.

• legos: определённые пользователем сложные примитивы.

• ber.py: примитивы ASN.1/BER.

• dcerpc.py: примитивы Microsoft RPC NDR.

• misc.py: различные неклассифицированные сложные примитивы, такие как адреса электронной почты и имена узлов.

• xdr.py: типы XDR.

• pgraph: библиотека абстракции графов Python. Используется при построении сеансов.

• utils: различные вспомогательные процедуры.

• dcerpc.py: вспомогательные процедуры Microsoft RPC, например для привязки к интерфейсу и создания запроса.

• misc.py: различные неклассифицированные процедуры, например CRC-16 и процедуры манипулирования UUID.

• scada.py: вспомогательные процедуры для SCADA, включая кодировщик блоков DNP3.

• __init__.py: здесь определены различные псевдонимы s_, используемые при создании запросов.

• blocks.py: здесь определены блоки и вспомогательные средства блоков.

• pedrpc.py: этот файл определяет классы клиента и сервера, используемые Sulley для взаимодействия между различными агентами и главным фаззером.

• primitives.py: здесь определены различные примитивы фаззера, включая статические, случайные, строки и целые числа.

• sessions.py: функциональность построения и исполнения сеанса.

• sex.py: специализированный класс Sulley для обработки исключений.

• unit_tests: каркас модульного тестирования Sulley.

• utils: различные автономные утилиты.

• crashbin_explorer.py: утилита командной строки для исследования результатов, сохранённых в сериализованных файлах корзины аварий.

• pcap_cleaner.py: утилита командной строки для очистки каталога PCAP от всех записей, не связанных с дефектом.

• network_monitor.py: управляемый PedRPC агент мониторинга сети.

• process_monitor.py: управляемый PedRPC агент мониторинга цели на основе отладчика.

• unit_test.py: каркас модульного тестирования Sulley.

• vmcontrol.py: управляемый PedRPC агент управления VMWare.

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

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

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

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

И снова ничего очевидного может не выделяться, но мы знаем, что влияем на это конкретное нарушение доступа, поскольку неправильно разыменовываемый регистр ECX содержит строку ASCII “&;tg”. Возможно, проблема расширения строки? Мы можем просматривать места аварий графически, что добавляет ещё одно измерение, отображая известные пути исполнения, с помощью ключа командной строки -g. Следующий созданный граф, рисунок 21.4, снова получен при реальном аудите анализатора Jabber в Trillian:

Рисунок 21.4. Графическое исследование корзины аварий Sulley

Мы видим, что, хотя обнаружены четыре разных места аварии, источник проблемы, по-видимому, один. Дальнейшее исследование показывает, что это действительно так. Конкретный дефект существует в подсистеме обмена сообщениями Rendezvous/Extensible Messaging and Presence Protocol (XMPP). Trillian находит находящихся поблизости пользователей посредством _presence службы mDNS, многоадресной DNS, на UDP-порту 5353. После регистрации пользователя через mDNS обмен сообщениями выполняется посредством XMPP по TCP-порту 5298. В plugins\rendezvous.dll к полученным сообщениям применяется следующая логика:

Длина предоставленной строки сообщения вычисляется, и для хранения копии сообщения выделяется буфер кучи размером длина + 128, который затем передаётся через expatxml.xmlComposeString(), функцию, вызываемую со следующим прототипом:

Процедура xmlComposeString() вызывает expatxml.19002420(), которая, среди прочего, кодирует для HTML символы &, > и < как &, > и < соответственно. Это поведение видно в следующем фрагменте дизассемблированного кода:

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

Каждый из дефектов, обнаруженных Sulley, был следствием этой логической ошибки. Отслеживание мест и путей дефектов позволило нам быстро выдвинуть предположение, что за них отвечает один источник. Последним шагом, который мы можем захотеть выполнить, является удаление всех файлов PCAP, не содержащих сведений о дефекте. Утилита pcap_cleaner.py написана именно для этой задачи:

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

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

Первый обсуждаемый нами основанный на эвристиках метод разбора реализован в частным образом разработанном^[6] механизме фаззинга с подходящим названием ProxyFuzzer. В типичной сетевой модели клиент-сервер между клиентом и сервером происходит прямое взаимодействие, как показано на рисунке 22.1.

Рисунок 22.1. Типичный путь взаимодействия клиент-сервер

Как следует из названия, прокси-фаззер должен разорвать соединение между клиентом и сервером, чтобы расположиться в качестве ретранслятора. Для эффективного выполнения этой задачи и клиент, и сервер необходимо вручную настроить^[7] искать друг друга по адресу прокси. Иными словами, клиент видит прокси как сервер, а сервер видит прокси как клиент. Новая сетевая схема со вставленным фаззером показана на рисунке 22.2.

Рисунок 22.2. Прозрачный встроенный прокси

Сплошные соединительные линии между узлами на рисунке 22.2 представляют исходные неизменённые данные, которые на этом этапе просто перенаправлены через прокси. В режиме по умолчанию ProxyFuzzer вслепую ретранслирует полученный трафик на обоих концах, одновременно записывая транзакции в формате, подходящем для программного изменения или повторного воспроизведения. Это само по себе удобная возможность, поскольку позволяет исследователям пропустить промежуточные шаги, связанные с созданием и изменением файлов необработанного захвата пакетов (PCAP). В качестве отступления, изменение и повторное воспроизведение записанных транзакций является превосходным ручным подходом к обратной разработке неизвестных протоколов и методом, хорошо реализованным в Protocol Debugger (PDB) от Matasano.^[8]

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

Рисунок 22.3. Автономная встроенная мутация

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

Сейчас разрабатываются усовершенствования, призванные сделать ProxyFuzzer «умнее». Для помощи в автоматизированном обнаружении полей и последующей мутации рассматривались дополнительные эвристики. Текущий анализатор трафика способен изолировать поля обычного текста от остальной части двоичного протокола. Выявленные поля обычного текста следует обрабатывать дополнительно, ища распространённые разделители и ограничители полей, такие как пробелы, двоеточия и так далее. Кроме того, необработанные байты перед обнаруженными строками можно исследовать в поисках спецификаций длины и типа строки, то есть полей TLV. Возможные префиксы длины затем можно проверить перекрёстным исследованием ряда пакетов. Необработанные байты после строк также можно изучать для выявления дополнения статических полей. IP-адреса и клиента, и сервера часто появляются внутри потока данных, за пределами заголовков TCP/IP. Поскольку эти сведения известны, механизм анализа может сканировать сетевые данные в поисках и необработанного, и ASCII-представления.

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

Рисунок 22.4. Иерархический разбор протокола

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

Человек, а возможно, даже дельфин, может легко бегло взглянуть на эти три транзакции и быстро сделать обоснованные догадки о конкретике протокола. Давайте посмотрим, что способен выявить улучшенный автоматический анализ, исследуя только первую транзакцию. Сначала быстро обнаруживается и закрепляется поле четырёхбайтного IP-адреса (0a 0a 00 01 = частный IP-адрес 10.10.0.1). Далее обнаруживаются четыре строки ASCII: user, pedram, code rev 254 и END. Байтовые значения перед каждой строкой сканируются в поисках допустимого однобайтного значения длины, затем двухбайтного, трёхбайтного и, наконец, четырёхбайтного. Теперь процедура анализа может предположить, что протокол начинается с двух строк переменной длины, перед которыми стоит двухбайтная длина, а далее следует IP-адрес подключающегося клиента. Сканирование следующей строки в поисках префикса длины не даёт результатов. Предположив, что следующее поле ASCII имеет статический размер, механизм ищет и находит четыре завершающих нулевых байта. Следующее поле предположительно является полем ASCII статического размера 10 байт. Последняя строка, END, не содержит префикса длины, и за ней не следует дополнение. Предполагается, что это поле ASCII статического размера три байта.

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

• Двухбайтная длина строки, за которой следует строка.

• Двухбайтная длина строки, за которой следует строка.

• Четырёхбайтный IP-адрес клиента.

• Поле ASCII статической длины 10 байт с нулевым дополнением.

• Неизвестное двоичное поле статической или переменной длины.

• Поле ASCII статической длины три байта.

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

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

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

Реализация для подтверждения концепции отладчика обратной связи фаззера, отслеживающего цель, была разработана чуть более чем за пару часов с помощью компонента PyDbg каркаса обратной разработки PaiMei.^[9] Соответствующий исходный код ищите на http://www.fuzzing.org.

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

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

Рис. 23.1. Простой граф вызовов

Большинство узлов на рис. 23.1 содержат метку с префиксом sub_, за которым следует восьмизначное шестнадцатеричное число, представляющее адрес подпрограммы в памяти. Это соглашение об именовании используется дизассемблером DataRescue Interactive Disassembler Pro (IDA Pro)^[4] для автоматического создания имен функций без символьной информации. Другие движки дизассемблирования используют похожие схемы именования. При анализе двоичных приложений с закрытым исходным кодом отсутствие символьной информации приводит к тому, что большинство функций получают имена в таком виде. Два узла на рис. 23.1 все же имеют символьные имена и были обозначены соответствующим образом: snprintf() и recv(). Беглого взгляда на этот граф вызовов достаточно, чтобы сразу определить, что безымянные подпрограммы sub_00000110() и sub_00000330() отвечают за обработку сетевых данных из-за их связи с recv().

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

• Начало функции.

• Цель инструкции перехода.

• Инструкция после инструкции перехода.

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

• Инструкция перехода.

• Инструкция возврата.

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

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

Рис. 23.2. Дизассемблированный статический листинг sub_00000010

Разбиение статического листинга на базовые блоки - простая задача, если следовать правилам, изложенным ранее. Первый базовый блок начинается в верхней части функции по адресу 0x00000010 и заканчивается первой инструкцией перехода по адресу 0x00000025. Следующая инструкция после перехода по адресу 0x0000002B, а также цель перехода по адресу 0x00000050 отмечают начало новых базовых блоков. После разбиения на базовые блоки CFG подпрограммы, показанной на рис. 23.2, выглядит так, как на рис. 23.3.

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

Рис. 23.3. Граф потока управления sub_00000010

Для реализации собственного инструмента покрытия кода можно использовать несколько подходов. Если вы уже прочитали предыдущие главы, возможно, первый пришедший вам в голову подход - применить отладчик с функцией трассировки для отслеживания и регистрации каждой выполняемой инструкции. Именно этот подход использует OllyDbg для реализации функций "debug\trace into" и "debug\trace over". Мы могли бы воспроизвести эту функциональность на основе той же библиотеки PyDbg, которую использовали в главе 20 "Фаззинг в памяти: автоматизация", применив следующую логику:

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

2. Зарегистрировать обработчик одиночного шага и установить флаг одиночного шага.

3. В обработчике одиночного шага зарегистрировать адрес текущей инструкции и снова установить флаг одиночного шага.

4. Продолжать до завершения процесса или сбоя.

Этот упрощенный подход можно реализовать поверх PyDbg менее чем в 50 строках Python. Однако он не является предпочтительным, поскольку инструментирование каждой инструкции внутри процесса с помощью отладчика вносит очень большую задержку, которая во многих случаях делает этот подход непригодным. Если вы не верите, попробуйте сами с соответствующим кодом, приведенным на боковой панели и также доступным в Интернете по адресу http://www.fuzzing.org. Более того, простое определение и регистрация выполненных инструкций охватывают лишь один аспект нашей общей цели. Для создания более качественных отчетов нам нужна дополнительная информация о нашей цели.

Мы реализуем средство отслеживания фаззера с помощью трехэтапного подхода:

• Сначала мы статически профилируем нашу цель.

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

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

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

• Сколько инструкций находится в нашей цели?

• Сколько функций?

• Сколько базовых блоков?

• Какие инструкции внутри нашей цели относятся к стандартным вспомогательным библиотекам?

• Какие инструкции внутри нашей цели написали наши разработчики?

• Из каких строк исходного кода была получена каждая отдельная инструкция?

• Какие инструкции и данные достижимы и могут находиться под влиянием сетевых данных или данных файла?

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

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

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

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

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

2. Зарегистрировать обработчик точки останова.

3. Установить точку останова в начале каждого базового блока.

4. В обработчике точки останова зарегистрировать адрес текущей инструкции и при необходимости восстановить точку останова.

5. Продолжать до завершения процесса или сбоя.

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

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

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

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

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

• Какие области кода отвечают за обработку наших входных данных?

• Какой процент нашей цели мы покрыли?

• Какой путь выполнения привел к конкретному сбою?

• Какие логические решения внутри нашей цели не были задействованы?

• Какие логические решения внутри нашей цели непосредственно зависят от предоставленных данных?

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

Рис. 23.4. Неудачное диалоговое окно перед эксплуатацией, снижающее степень серьезности

Библиотека PyDbg, с которой мы работали ранее, фактически является подкомпонентом более крупного каркаса обратного проектирования под названием PaiMei. PaiMei - активно разрабатываемый каркас обратного проектирования с открытым исходным кодом на Python, свободно доступный для загрузки.^[9] По существу, PaiMei можно считать швейцарским армейским ножом специалиста по обратному проектированию; он может помочь в различных сложных задачах фаззинга, таких как интеллектуальное обнаружение и обработка исключений - тема, которую мы подробно рассматриваем в главе 24 "Интеллектуальное обнаружение сбоев".

В комплекте каркаса уже имеется инструмент покрытия кода под названием PAIMEIpstalker (также называемый Process Stalker или PStalker). Хотя в готовом виде этот инструмент может не создавать именно те отчеты, которые вам нужны, каркас и входящие в его комплект приложения имеют открытый исходный код, поэтому их можно изменять в соответствии с любыми конкретными потребностями данного проекта. Каркас разбит на следующие основные компоненты:

• PyDbg. Класс чистой абстракции отладки win32 на Python.

• pGRAPH. Уровень абстракции графа с отдельными классами для узлов, ребер и кластеров.

• PIDA. Построенный поверх pGRAPH, PIDA призван предоставить абстрактный и постоянный интерфейс к двоичным файлам (DLL и EXE) с отдельными классами для представления функций, базовых блоков и инструкций. Конечным результатом является создание переносимого файла, который после загрузки позволяет произвольно перемещаться по всему исходному двоичному файлу.

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

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

• Utilities. Набор утилит для выполнения различных повторяющихся задач. Нас интересует конкретный класс утилит, process_stalker.py, написанный для предоставления абстрактного интерфейса к функциям покрытия кода.

• Console. Подключаемое приложение WxPython для быстрого и эффективного создания пользовательских интерфейсов GUI для недавно созданных инструментов. Именно через него мы взаимодействуем с модулем покрытия кода pstalker.

• Scripts. Отдельные сценарии для выполнения различных задач; один очень важный пример - сценарий IDA Python pida_dump.py, который запускается из IDA Pro для создания файлов .PIDA.

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

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

Рис. 23.5. Модуль PaiMei PStalker

Столбец Data Sources предоставляет функции, необходимые для создания и управления целями, за которыми будет вестись наблюдение, а также для загрузки соответствующих модулей PIDA. В столбце Data Exploration отображаются результаты каждого отдельного запуска покрытия кода, или наблюдения. Наконец, в столбце Data Capture указываются параметры конфигурации времени выполнения и целевой исполняемый файл. Общий рабочий процесс, связанный с этим инструментом, выглядит следующим образом (подробности далее):

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

• Выбрать тег для наблюдения.

• Загрузить модули PIDA для каждого файла .DLL и кода .EXE, для которых требуется информация о покрытии.

• Запустить целевой процесс.

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

• Настроить параметры покрытия кода и подключиться к выбранной цели.

• Взаимодействовать с целью, пока записывается покрытие кода.

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

• Загрузить зарегистрированные попадания, чтобы начать изучение записанных данных.

Онлайновая документация^[10] PaiMei содержит полнометражный видеоролик, демонстрирующий использование модуля PStalker. Если вы никогда его не видели, сейчас самое время посмотреть его, прежде чем продолжать.

После установления соединения всей консоли с MySQL через меню Connections выберите кнопку Retrieve Target List, чтобы заполнить дерево проводника источников данных. При первом запуске приложения этот список будет пуст. Новые цели можно создавать из контекстного меню корневого узла с меткой Available Targets. Используйте контекстное меню отдельных целей, чтобы удалить отдельную цель, добавить тег под целью и загрузить попадания из всех тегов под целью на панель исследования данных. Контекстное меню отдельных тегов предоставляет ряд функций:

• Load hits. Очистить панель исследования данных и загрузить попадания, связанные с выбранным тегом.

• Append hits. Добавить попадания, связанные с выбранным тегом, после всех существующих данных, уже находящихся на панели исследования.

• Export to IDA. Экспортировать попадания под выбранным тегом в виде сценария IDC, пригодного для импорта в IDA с целью выделения функций и блоков, в которые произошли попадания.

• Sync with uDraw. Синхронизировать панель исследования данных через общее для консоли соединение uDraw. Для этой функции очень полезны два монитора.

• Use for stalking. Сохранять все попадания, зарегистрированные на этапе захвата данных, в выбранном теге. Перед подключением к процессу необходимо выбрать тег для наблюдения.

• Filter tag. Не регистрировать в будущих сеансах наблюдения попадания в какие-либо узлы или базовые блоки под выбранным тегом. Для фильтрации можно отметить несколько тегов.

• Clear tag. Сохранить тег, но удалить все хранящиеся под ним попадания. PStalker не может вести наблюдение с записью в тег, который уже содержит данные. Чтобы перезаписать содержимое тега, сначала его необходимо очистить.

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

• Target/tag properties. Изменить имя тега, просмотреть или изменить примечания к тегу либо изменить имя цели.

• Delete tag. Удалить тег и все хранящиеся под ним попадания.

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

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

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

Щелкните кнопку Retrieve List, чтобы отобразить актуальный список процессов, в котором более новые процессы перечислены внизу. Выберите целевой процесс для подключения либо найдите целевой процесс для загрузки и выберите желаемую глубину покрытия. Выберите Functions, чтобы наблюдать и отслеживать, какие функции выполняются внутри целевого процесса, или Basic Blocks, чтобы более тщательно исследовать отдельные выполняемые базовые блоки.

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

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

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

У этого инструмента есть одно основное ограничение, о котором вам следует знать. В частности, инструмент зависит от статического анализа целевых двоичных файлов, предоставляемого IDA Pro компании DataRescue; поэтому инструмент даст сбой, когда IDA Pro допускает ошибки. Например, если данные ошибочно представлены как код, при установке PStalker точек останова на этих данных могут произойти неприятности. Это наиболее частая причина сбоя. Отключение параметра ядра анализа Make final pass в IDA Pro до автоматического анализа отключит агрессивную логику, которая допускает ошибки такого рода. Однако общий анализ также пострадает. Кроме того, в настоящее время невозможно трассировать упакованный или самомодифицирующийся код.

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

Все данные о целях и покрытии кода хранятся на сервере базы данных MySQL. Информация распределена по трем таблицам: cc_hits, cc_tags и cc_targets. Как показано в следующей структуре таблицы SQL, база данных cc_targets содержит простой список имен целей, автоматически создаваемый уникальный числовой идентификатор и текстовое поле для хранения любых относящихся к цели примечаний:

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

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

Поля таблицы cc_hits разбираются следующим образом:

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

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

• timestamp. Здесь хранится число секунд с начала эпохи UNIX (1 января 1970 года, 00:00:00 GMT) - формат, который легко преобразовать в другие представления.

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

• tid. В этом поле хранится идентификатор потока, отвечавшего за выполнение блока кода по адресу eip. Идентификатор потока назначается ОС Windows и сохраняется, чтобы различать блоки кода, выполненные разными потоками многопоточного приложения.

• eax, ebx, ecx, edx, edi, esi, ebp и esp. Эти поля содержат числовые значения каждого из восьми регистров общего назначения в момент выполнения. Для каждого из регистров общего назначения и сохраненных смещений стека существует поле deref, содержащее ASCII-данные по конкретному регистру, рассматриваемому как указатель. В конце строки ASCII-данных находится тег - один из (stack), (heap) или (global), представляющий место, где были найдены данные, полученные разыменованием. Обозначение N/A используется в случаях, когда разыменование невозможно, поскольку соответствующий регистр не содержал адреса, пригодного для разыменования.

• esp_4, esp_8, esp_c и esp_10. Эти поля содержат числовые значения по соответствующим смещениям стека (esp_4 = [esp+4], esp_8 = [esp+8] и так далее).

• is_function. Это логическое поле, в котором значение 1 означает, что блок данных с попаданием (по адресу eip) является началом функции.

• module. В этом поле хранится имя модуля, в котором произошло попадание.

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

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

В практическом разборе конкретного случая мы применим инструмент покрытия кода PStalker, чтобы определить относительную полноту аудита с фаззингом. Наше целевое программное обеспечение - Gizmo Project,^[11] комплекс для связи через VoIP, обмена мгновенными сообщениями (IM) и телефонии. На рис. 23.6 приведен снабженный комментариями снимок экрана с веб-сайта Gizmo Project, подробно показывающий основные функции инструмента.

Gizmo реализует впечатляющее число функций, которые входят в число причин его стремительно растущей популярности. Многие считают Gizmo возможным "убийцей" Skype,^[12] и от повсеместно распространенного Skype он отличается тем, что построен на открытых стандартах VoIP, таких как Session Initiation Protocol (SIP - RFC 3261), а не реализует закрытую проприетарную систему. Это решение позволяет Gizmo взаимодействовать с другими решениями, совместимыми с SIP. Оно также позволяет нам тестировать Gizmo стандартными инструментами проверки безопасности VoIP. Теперь, когда прицел наведен на целевое программное обеспечение, мы должны выбрать целевой протокол и подходящий фаззер.

Рис. 23.6. Список функций Gizmo Project

Мы будем проверять способность Gizmo обрабатывать некорректно сформированные пакеты SIP. Хотя можно было бы выбрать в качестве цели несколько протоколов VoIP, SIP - хороший выбор, поскольку большая часть телефонной связи VoIP начинается с согласования сигнализации через этот протокол. Кроме того, уже существует несколько свободных фаззеров SIP. Для нашего теста мы будем использовать свободно распространяемый фаззер SIP, выпущенный кафедрой электротехники и информационной инженерии Университета Оулу, под названием PROTOS Test-Suite: c07-sip.^[13] Набор тестов PROTOS содержит 4527 отдельных тестовых случаев, распространяемых в одном файле Java JAR. Хотя этот набор тестов ограничен проверкой только сообщений INVITE, он прекрасно подходит для наших нужд. Одна из причин выбора этого фаззера состоит в том, что группа, отвечающая за его разработку, выпустила коммерческую версию через компанию Codenomicon.^[14] Коммерческая версия набора тестов SIP исследует протокол SIP глубже и включает 31 971 отдельный тестовый случай.

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

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

Ваши результаты могут отличаться, но мы обнаружили, что лучше всего работают следующие параметры (при этом обязательным является только параметр touri):

Параметр задержки в две секунды дает Gizmo время освободить ресурсы, обновить GUI и иным образом восстановиться между тестовыми случаями. Параметр validcase указывает PROTOS проверять после каждого тестового случая и до продолжения, что допустимый обмен данными по-прежнему возможен. Этот примитивный метод позволяет фаззеру обнаружить, что с целью что-то пошло не так, и прекратить тестирование. В нашей ситуации это важный фактор, потому что Gizmo действительно дает сбой! К счастью для Gizmo, уязвимость срабатывает из-за разыменования нулевого указателя и потому не может быть эксплуатирована. Тем не менее проблема существует (подсказка: она возникает в пределах первых 250 тестовых случаев). Загрузите набор тестов и выясните сами.

Параметры touri и dport были получены посредством изучения пакетов, проходивших к порту 5060 или от него (стандартный порт SIP) во время запуска Gizmo. На рис. 23.7 показан соответствующий фрагмент с выделенными интересующими значениями.

Число 17476624642 - фактический телефонный номер, назначенный нашей учетной записи Gizmo, а порт 64064, по-видимому, является стандартным клиентским портом SIP для Gizmo. Наша стратегия готова. Целевое программное обеспечение, протокол и фаззер выбраны, а параметры фаззера определены. Теперь пора перейти к тактической части разбора конкретного случая.

Рис. 23.7. Декодированный захват пакета SIP при запуске Gizmo

Мы подвергаем фаззингу SIP, поэтому нас интересует именно код обработки SIP. К счастью для нас, код легко изолировать, поскольку имя библиотеки SIPPhoneAPI.dll сразу выделяется как наша цель. Первым делом загрузите библиотеку в IDA Pro и запустите сценарий pida_dump.py, чтобы создать SIPPhoneAPI.pida. Поскольку нас интересует только отслеживание покрытия кода, указание "basic blocks" в качестве глубины анализа для сценария pida_dump.py повысит производительность. Далее запустим PaiMei и последовательно выполним необходимые предварительные действия, чтобы привести покрытие кода в рабочее состояние. Дополнительные сведения о конкретном использовании PaiMei приведены в онлайновой документации.^[15] Первый этап, показанный на рис. 23.8, - создать цель, которую мы называем "Gizmo", и добавить тег с именем "Idle". Мы используем тег "Idle" для записи покрытия кода внутри Gizmo в состоянии "покоя". Это необязательный этап, но, поскольку для записи можно указать несколько тегов и, кроме того, выбирать отдельные теги для фильтрации, максимально возможная детализация никогда не повредит. Затем тег "Idle" необходимо выбрать для "Stalking", как показано на рис. 23.9, а файл PIDA SIPPhoneAPI необходимо загрузить, как показано на рис. 23.10.

После настройки источников данных и выбора тега мы выбираем целевой процесс и параметры захвата, после чего начинаем записывать покрытие кода. На рис. 23.11 показаны настроенные параметры, которые мы будем использовать. Кнопка Refresh Process List получает список выполняющихся в настоящее время процессов. В нашем примере мы решаем подключиться к уже выполняющемуся экземпляру Gizmo, а не загружать новый экземпляр с самого запуска.

Рис. 23.8. Создание цели и тега PaiMei PStalker

Рис. 23.9. Выбор тега "Idle" для наблюдения

Рис. 23.10. Загруженный модуль PIDA SIPPhoneAPI

В разделе Coverage Depth мы выбираем Basic Blocks, чтобы получить наиболее детализированный уровень покрытия кода. Как вы ранее видели на рис. 23.10, наша целевая библиотека содержит чуть менее 25 000 функций и более чем в четыре раза больше базовых блоков. Поэтому, если для нас важна скорость, мы можем пожертвовать детализацией ради повышения производительности, выбрав вместо этого Functions в качестве глубины покрытия.

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

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

Рис. 23.11. Параметры захвата покрытия кода

После щелчка по "Start Stalking" инструмент покрытия кода подключается к Gizmo и начинает отслеживать выполнение. Если вас интересуют конкретные подробности того, как процесс протекает за кулисами, обратитесь к документации PaiMei. После активации сообщения журнала, указывающие действия и ход работы PStalker, записываются на панель журнала. Следующий фрагмент примера демонстрирует успешный запуск:

Теперь мы можем активировать фаззер и отслеживать код, выполняемый во время простоя. Чтобы продолжить, мы ждем, пока список точек останова с попаданиями не начнет сходить на нет, что указывает на исчерпание кода в библиотеке SIP, который выполняется, пока Gizmo бездействует. Затем мы создаем новый тег и выбираем его в качестве активного через меню правой кнопки мыши, выбрав Use for Stalking. Наконец, мы щелкаем правой кнопкой мыши по созданному ранее тегу "Idle" и выбираем Filter Tag. В результате все базовые блоки, выполнявшиеся в состоянии простоя, фактически игнорируются. Теперь можно запустить фаззер и наблюдать за его работой. На рис. 23.12 показано покрытие кода, наблюдаемое в ответ на все 4527 тестовых случаев PROTOS.

Рис. 23.12. Результаты покрытия кода

В заключение: набор тестов PROTOS смог достичь лишь примерно 6 процентов функций и 9 процентов базовых блоков внутри библиотеки SIPPhoneAPI. Для бесплатного набора тестов это неплохо, но результат показывает, почему запуск одного набора тестов не равнозначен комплексному аудиту. После выполнения набора тестов мы не проверили большую часть кода, и маловероятно, что мы всесторонне проверили функциональность внутри того кода, которого все же достигли. Однако эти результаты покрытия можно улучшить, добавив механизм перезапуска процесса между короткими интервалами тестовых случаев. Причина состоит в том, что, хотя Gizmo успешно отвечает на допустимые тестовые случаи, которые мы поручили PROTOS вставлять между некорректно сформированными тестами, спустя некоторое время Gizmo все же перестает работать правильно, и покрытие кода страдает. Перезапуск процесса сбрасывает внутреннее состояние и восстанавливает полную функциональность, позволяя нам точнее и тщательнее исследовать цель.

Учитывая, что PROTOS содержит лишь 1/7 числа тестовых случаев своей коммерческой сестры, можно ли ожидать от коммерческой версии семикратного увеличения покрытия кода? Вероятно, нет. Хотя ожидается увеличение покрытия кода, между числом тестовых случаев и полученным объемом задействованного кода не существует постоянного или предсказуемого соотношения. Точными могут быть только эмпирические результаты.

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

Традиционно фаззинг проводился не слишком научным образом. Часто исследователи безопасности и инженеры QA на скорую руку собирают примитивные сценарии для создания некорректно сформированных данных, позволяют своему творению выполняться произвольный период времени и на этом заканчивают. С недавним распространением коммерческих решений для фаззинга вы встретите организации, которые делают еще один шаг к научному тестированию: используют исчерпывающий список тестовых случаев, разработанный коммерческим поставщиком, таким как Codenomicon. Исследователям безопасности, которые просто ищут уязвимости, чтобы сообщить о них или продать, часто нет необходимости развивать процесс дальше. При нынешнем состоянии безопасности программного обеспечения существующих методологий достаточно для создания бесконечного длинного списка ошибок и уязвимостей. Однако по мере роста зрелости и осведомленности как в безопасной разработке, так и в тестировании возникнет потребность в более научном подходе. Разработчики программ и группы QA, заинтересованные в обнаружении всех уязвимостей, а не только низко висящих плодов, будут больше заботиться о применении более научного подхода к фаззингу. Отслеживание фаззера - необходимый шаг в этом направлении.

Продолжая использовать тот же пример, что и на протяжении всей главы, рассмотрим различные стороны, участвующие в разработке последнего выпуска софтфона VoIP, и преимущества, которые они могут получить от отслеживания фаззера. Для менеджера продукта знание конкретных областей проверенного кода позволяет точнее и с большей уверенностью определить уровень тестирования, которому подвергся их продукт. Например, рассмотрим следующее утверждение: "Последний выпуск нашего софтфона VoIP прошел 45 000 вредоносных тестовых случаев". Никаких доказательств в подтверждение этого заявления не предоставляется. Возможно, из 45 000 вредоносных случаев только 5000 охватывали функции, предоставляемые целевым софтфоном. Также возможно, что весь набор тестов задействовал лишь 10 процентов доступных функций, предоставляемых целевым софтфоном. Кто знает, возможно, тестовые случаи написали по-настоящему блестящие инженеры и они покрыли всю кодовую базу. Последний вариант был бы замечательным, но, опять же, без анализа покрытия кода невозможно определить достоверность первоначального заявления. Объединение средства отслеживания фаззера с тем же набором тестов могло бы привести к следующему, более содержательному утверждению: "Последний выпуск нашего софтфона VoIP прошел 45 000 вредоносных тестовых случаев с исчерпывающей проверкой более 90 процентов нашей кодовой базы".

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

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

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

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

Нынешнее требование перечислить местоположения всех базовых блоков и функций внутри цели представляет собой кропотливый и подверженный ошибкам процесс. Одно из решений этой проблемы - перечислять базовые блоки во время выполнения. Согласно руководству разработчика программного обеспечения для архитектуры Intel IA-32,^[16] тому 3B,^[17] разделу 18.5.2, процессоры Pentium 4 и Xeon на аппаратном уровне поддерживают "одиночный шаг по переходам":

Использование этой функции позволяет разработать инструмент, способный трассировать целевой процесс на уровне базовых блоков без необходимости какого-либо априорного анализа. Также достигается выигрыш в скорости выполнения, поскольку больше не требуется устанавливать программные точки останова на каждом отдельном базовом блоке при запуске. Однако помните, что статический анализ и перечисление базовых блоков по-прежнему необходимы для определения полного масштаба кодовой базы и заявлений о проценте покрытия. Кроме того, хотя при таком подходе начало трассировки может быть быстрее, в долгосрочной перспективе он, вероятно, не будет быстрее описанного ранее метода. Причины - невозможность прекратить отслеживание уже выполненных блоков, а также невозможность трассировать только конкретную модель. Тем не менее это интересный и мощный метод. Развивая показанный ранее в этой главе пошаговый исполнитель PyDbg, рабочий пошаговый исполнитель уровня переходов можно найти в записи блога "Branch Tracing with Intel MSR Registers"^[18] на OpenRCE. Подробное исследование этого подхода оставлено читателю в качестве упражнения.

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

Рис. 23.13. Пример графа потока управления

Анализ покрытия кода может показать, что серия тестовых случаев задействовала все четыре блока A, B, C и D. Были ли задействованы все пути? Если да, какие пути задействовал каждый отдельный тестовый случай? Ответы на эти вопросы требуют покрытия путей - метода, который позволяет дополнительно выяснить, какие из следующих возможных сочетаний путей были покрыты:

• A -> B -> D

• A -> B -> C -> D

• A -> C -> D

Если, например, были задействованы только первый и третий пути в этом списке, анализ покрытия кода показал бы 100-процентное покрытие. Покрытие путей, напротив, показало бы, что покрыты лишь 66 процентов возможных путей. Эта дополнительная информация может позволить аналитику дополнительно настроить и улучшить список тестовых случаев.

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

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

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

• Чтение данных с адреса, с которого их не следует читать.

• Запись данных по адресу, по которому их не следует записывать.

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

Эта искусственная функция принимает целочисленный и строковый аргументы, объявляет три локальные переменные, а затем копирует предоставленную строку в объявленный стековый буфер без учета размера исходной строки или буфера назначения. При вызове функции taboo() ее аргументы помещаются в стек в обратном порядке. Полученная ассемблерная инструкция CALL неявно помещает в стек адрес текущей инструкции (хранящийся в регистре EIP). Именно так ЦП узнает, куда передать управление обратно после завершения выполнения вызванной функции. Обычно затем пролог функции помещает в стек текущий указатель кадра (хранящийся в регистре EBP). Наконец, для трех объявленных локальных переменных выделяется место путем вычитания общего размера переменных из указателя стека (хранящегося в регистре ESP). Полученный стековый кадр выглядит в точности так, как показано на рис. 24.1.

Как показано на рис. 24.1, вспомните, что стек растет "вниз", от старших адресов к младшим. Однако запись данных происходит в противоположном направлении, "вверх". Если длина строки arg2 превышает 16 байт (объявленный размер buf), strcpy() продолжит копирование за конец пространства, выделенного для buf, перезаписывая локальную целочисленную переменную x, затем сохраненный указатель кадра, затем сохраненный адрес возврата, затем первый аргумент и так далее. Если предположить, что arg2 - длинная строка из символов A, сохраненный EIP будет перезаписан значением 0x41414141 (0x41 - шестнадцатеричное значение ASCII-символа A).

Рис. 24.1. Пример компоновки стека

Когда функция taboo() завершает выполнение, ассемблерная инструкция RETN восстанавливает перезаписанный сохраненный EIP и передает управление тем инструкциям, которые обнаружатся по адресу 0x41414141. В зависимости от содержимого памяти по адресу 0x41414141 возможны несколько разных сценариев. В большинстве случаев на этот конкретный адрес не будет отображено ни одной допустимой страницы памяти, и когда ЦП попытается прочитать следующую инструкцию по недоступному для чтения адресу 0x41414141, будет создано исключение ACCESS_VIOLATION. Обратите внимание: в этом конкретном примере, если длина arg2 превышает 16 байт, но меньше или равна 20 байтам, исключение не возникнет.

Если по этому адресу находятся допустимые данные, но не исполняемый код, а лежащий в основе процессор поддерживает разрешения страниц, запрещающие выполнение (nonexecutable, NX^[1]), то, когда ЦП попытается выполнять код по неисполняемому адресу 0x41414141, снова будет создано исключение ACCESS_VIOLATION. Что интереснее всего, если по адресу находится допустимый исполняемый код, исключение создано не будет. Это ключевой момент, к которому мы вернемся далее в главе. Этот пример демонстрирует одну из самых прямолинейных форм перехвата потока управления.

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

Эта функция принимает целочисленный и строковый аргументы, объявляет три локальные переменные и устанавливает целочисленную переменную x как указатель на y. Затем функция продолжает печатать из buf переменное число шестнадцатеричных байтов, заданное целочисленным аргументом arg1. Поскольку проверка разумности аргумента, используемого в качестве условия завершения цикла, не выполняется, значение больше 16 заставит процедуру printf() обратиться к данным и вывести их, хотя делать этого ей не следует.

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

Далее выполняется неограниченное копирование строки, как и в предыдущем примере. Однако если предположить, что arg2 содержит только 20 символов A (на четыре байта больше размера buf), будет перезаписана лишь локальная переменная-указатель x. В такой ситуации переполнение стека не приведет к недопустимой передаче выполнения, как прежде. Однако во время вызова printf(), когда перезаписанная переменная разыменовывается как указатель, при попытке чтения по адресу 0x41414141, вероятно, возникнет ACCESS_VIOLATION.

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

Согласно прототипу API syslog(), ожидается форматная строка, за которой следует переменное число аргументов форматной строки. При прямой передаче пользовательской строки, содержащейся в аргументе message, функции syslog() все маркеры форматной строки, содержащиеся в аргументе, будут разобраны, а соответствующий аргумент форматной строки будет разыменован. Поскольку таких аргументов форматной строки не существует, будут использованы любые значения, которые в данный момент находятся в стеке функции. Например, если аргумент содержит %s%s%s%s%s, из стека читаются пять адресов и каждый разыменовывается как указатель на строку, пока не встретится нулевой байт. Передача достаточного числа маркеров форматной строки %s обычно приводит к тому, что недопустимый указатель рассматривается как строка, а это приводит к ACCESS_VIOLATION. В некоторых случаях указатель будет указывать на допустимую адресуемую память, но содержимое памяти не будет завершено NULL, из-за чего функция при поиске байта NULL прочитает данные за концом страницы. Обратите внимание: в зависимости от среды и числа предоставленных маркеров форматной строки нарушение может не возникнуть. И снова эта ключевая концепция рассматривается далее в главе.

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

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

В качестве более реалистичного примера записи в место, куда записывать не следует, рассмотрим следующий фрагмент кода и упрощенный пример, демонстрирующие раскрытие типичной уязвимости переполнения кучи:^[2]

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

Рис. 24.2. Двусвязный список фрагментов кучи

При достижении вызова strcpy() выделенный буфер, на который ссылается A, переполняется, поскольку не может вместить длинную предоставленную строку из символов P. Поскольку переполняемый буфер хранится не в стеке, возможности затереть сохраненный адрес возврата нет. Так в чем же проблема? В следующей строке кода вызов free(B) должен удалить B из цепочки и соединить A и C друг с другом. Это выполняется посредством следующей базовой логики:

Поскольку прямой и обратный указатели хранятся в начале каждого фрагмента кучи, переполнение в результате вызова strcpy() перезапишет значения этих указателей во фрагменте B значением 0x50505050 (0x50 - шестнадцатеричное значение ASCII-символа P). На уровне ассемблера это может превратиться как в недопустимые попытки записи, так и в недопустимые попытки чтения.

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

Рассмотрим, например, различные ситуации, в которых четыре байта предоставленных фаззером данных используются при разыменовании памяти. Классическая строка символов A приводит к разыменованию адреса памяти 0x41414141. Хотя в большинстве случаев на этот конкретный адрес не отображены допустимые страницы памяти, что приводит к ожидаемому нами ACCESS_VIOLATION, будут случаи, когда адрес действительно допустим и потому событие исключения не создается. Хотя, по всей вероятности, наш фаззер сделал достаточно, чтобы вызвать исключение еще дальше по ходу выполнения, мы хотели бы узнавать о неполадках как можно раньше. Если бы у вас была возможность выбрать четыре байта, используемые как недопустимый адрес памяти, что бы вы выбрали? Хорошо работает выбор адреса в адресном пространстве ядра (обычно 0x80000000-0xFFFFFFFF), поскольку пространство ядра никогда не доступно из пользовательского режима.

Рассмотрим другой пример - случай уязвимости форматной строки. Мы видели: если предоставить недостаточное число маркеров %s, последующие разыменования указателей стека могут не вызвать никаких недопустимых обращений к памяти. Первым побуждением могло бы быть решить проблему, просто увеличив число маркеров %s, используемых в различных запросах фаззинга. Однако дальнейший анализ показал бы, что другие факторы, такие как установленные ограничения длины строки, могут сделать это решение бесполезным. Как обойти эту проблему более изящно? Вспомним: ключ к эксплуатации уязвимостей форматной строки - возможность записывать в стек с помощью маркера форматной строки %n и его производных. Маркер форматной строки %n записывает по соответствующему указателю стека число символов, которые должна была вывести форматная строка. Предоставив несколько маркеров %n вместо маркеров %s, мы с большей вероятностью можем вызвать сбой при ограничении более короткой входной строки. Сочетание перемежающихся маркеров %n%s, вероятно, будет самым разумным выбором с учетом ситуаций, когда маркер %n может быть отфильтрован или отключен (дополнительные сведения см. в главе 6 "Автоматизация и создание данных").

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

Недостаток отслеживания цели с помощью отладчика состоит в том, что, поскольку большинство отладчиков предназначены для интерактивного использования, об автоматическом извлечении полезной информации из самого отладчика и программном управлении им не может быть и речи. Меньше всего мы хотим вручную проверять наш фаззер и перезапускать процесс всякий раз, когда отладчик обнаруживает исключение. К счастью, мы снова можем воспользоваться помощью представленного ранее каркаса обратного проектирования PaiMei.^[4] С помощью этого каркаса мы можем спроектировать систему фаззинга и отслеживания из двух частей, показанную на рис. 24.3. Следует отметить, что этот каркас обратного проектирования в настоящее время предназначен исключительно для использования на платформе Windows и что, как и в остальной части книги, в этом разделе мы сосредоточены на архитектуре Intel IA-32.

Рис. 24.3. Архитектура фаззера и средства отслеживания

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

Возможно, это выглядит не слишком внушительно, но, следуя девизу каркаса PaiMei "коротко и ясно", этот фрагмент Python на самом деле делает очень многое. Возможно, вы узнаете первые две строки из предыдущих глав: они импортируют необходимую функциональность и определения из библиотеки отладчика Windows PyDbg.^[5] Однако следующий импорт библиотеки мы еще не встречали. Модуль PaiMei.utils^[6] содержит различные вспомогательные библиотеки обратного проектирования. В данном случае мы будем использовать модуль crash_binning, который объясняется далее. Если немного спуститься, вы найдете бесконечный цикл while. Цикл начинается с создания экземпляра класса PyDbg и регистрации функции av_handler() в качестве обработчика обратного вызова для обработки событий исключения ACCESS_VIOLATION. Всякий раз, когда происходит недопустимое обращение к памяти, как в любом из упомянутых ранее примеров, будет вызвана эта зарегистрированная функция. Затем отладчик загружает целевую программу со всеми необязательными аргументами. В этот момент необходимо подать фаззеру сигнал по обратному каналу, сообщив ему, что наша цель готова принять запрос фаззинга. В последней строке цикла отладчик позволяет отлаживаемой программе выполняться с помощью метода-члена run() (псевдонима debug_event_loop()).

В оставшихся строках нашей программы находится определение процедуры av_handler(). Как и любой зарегистрированный обратный вызов события, наша функция принимает один аргумент - текущий экземпляр объекта отладчика PyDbg. Функция начинается с создания экземпляра упомянутой ранее утилиты PaiMei crash_binning. Эта утилита существует для упрощения процесса сбора различных полезных атрибутов состояния текущего потока, который в данном случае вызвал обрабатываемое нами исключение ACCESS_VIOLATION. Следующая информация прозрачно записывается в следующей строке во время вызова record_crash():

• Адрес исключения. Адрес, по которому возникло исключение; в данном случае адрес инструкции, вызвавшей ACCESS_VIOLATION.

• Нарушение при записи. Флаг, который в установленном состоянии указывает, что исключение возникло во время попытки записи в ячейку памяти. В противном случае исключение возникло во время попытки чтения из ячейки памяти.

• Адрес нарушения. Адрес, по которому была предпринята попытка чтения или записи, приведшая к созданию исключения.

• Идентификатор потока нарушения. Числовой идентификатор потока, в котором возникло исключение. Первые четыре атрибута в совокупности позволяют делать такие утверждения: "В потоке 1234 ассемблерная инструкция по адресу 0xDEADBEEF не смогла прочитать данные по адресу 0xC0CAC01A и вызвала завершение приложения".

• Контекст. Сохраненные значения регистров ЦП в момент возникновения исключения.

• Дизассемблированное представление. Дизассемблированное представление инструкции, вызвавшей исключение.

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

• Раскрутка стека. Стек вызовов нарушившего потока в момент возникновения исключения. Хотя эта информация не всегда доступна на 32-битных платформах Windows, когда она доступна, то показывает аналитикам, как программа попала в текущее место. Альтернатива исследованию раскрутки стека - упреждающая запись действий цели, как обсуждалось в главе 23 "Отслеживание фаззера".

• Раскрутка SEH. Цепочка структурированных обработчиков исключений (Structured Exception Handler, SEH) в момент возникновения исключения. В зависимости от того, обрабатываем ли мы исключения первого шанса (подробнее об этом далее), аналитик может исследовать эту цепочку и увидеть, какие функции были зарегистрированы изнутри самой цели для обработки исключений.

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

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

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

Ради краткости в предыдущий фрагмент включен лишь частичный дамп контекста. В каждом из показанных случаев исключение возникло из-за попытки чтения с недопустимого адреса памяти (не показан). Обоснованная догадка, основанная исключительно на входных данных фаззинга, заставляет нас полагать, что лежащая в основе проблема вызвана либо неправильной способностью разбирать длинные строки, либо уязвимостью форматной строки. Заметив, что нарушение произошло по одному и тому же адресу при выполнении инструкции REP SCASB, мы подозреваем, что этот шаблон может присутствовать во многих из 1000 случаев. После нескольких беглых проверок наше подозрение подтверждается. Рассмотрим подробнее. Ассемблерная инструкция IA-32 SCASB сканирует строку в поисках байта, хранящегося в первом регистре AL (первом байте EAX). В каждом из показанных случаев AL=0. Префикс инструкции REP циклически повторяет инструкцию с префиксом и уменьшает регистр ECX, пока ECX не станет равен 0. В каждом из показанных случаев ECX имеет большое значение. Это типичный ассемблерный шаблон, используемый при определении длины строк. По-видимому, многие наши сбои происходят во время сканирования строки в поисках завершающего нулевого байта.

Как досадно. У нас есть 1000 тестовых случаев, которые, как мы знаем, приводят к проблеме, но значительная их часть, по-видимому, возникает в одном и том же месте или рядом с ним. Ручное отсеивание элементов списка - задача не для человека (хотя, возможно, она подойдет стажеру). Есть ли способ лучше? Конечно есть, иначе мы бы с самого начала не повели вас по этому пути.

Как можно предположить по названию, утилита сортировки сбоев PaiMei делает больше, чем просто отображает сведения о текущем контексте. Утилита в основном предназначена для использования как постоянный контейнер, хранящий относящуюся к делу контекстную информацию о многих и многих сбоях. Вызовы метода-члена record_crash() создают новую запись во внутренне поддерживаемом и организованном списке. Каждая созданная запись содержит собственные уникальные относящиеся к делу контекстные метаданные. Такой способ организации позволяет преобразовать предыдущее утверждение "1000 из 50 000 тестовых случаев приводят к исключению" в более полезное: "из 50 000 тестовых случаев 650 привели к исключению по адресу 0x00112233, 300 привели к исключению по адресу 0x11335577, 20 привели к исключению по адресу 0x22446688" и так далее. Изменения исходного сценария просты и показаны здесь полужирным в оригинале:

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

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

Рис. 24.4. Концепция каталогизации раскрутки стека при сортировке сбоев

Круглые точки данных на рис. 24.4 представляют прежние категории адресов исключений. Точки данных в прямоугольниках представляют адреса из раскрутки стека. Добавив точки данных раскрутки стека в наше представление, мы можем начать видеть пути, ведущие к различным адресам сбоев. По существу, мы способны улучшить наше последнее утверждение "из 50 000 тестовых случаев 650 привели к исключению по адресу 0x00112233, 300 привели к исключению по адресу 0x11335577" и так далее до утверждения "из 50 000 тестовых случаев 650 привели к исключению по адресу 0x00112233, из которых 400 прошли по пути x, y, z, а 250 - по пути a, b, z". Что важнее, анализ такого представления может позволить определить лежащий в основе источник повторяющихся сбоев. В нашей текущей ситуации основная масса захваченных исключений произошла по адресам 0x00112233 и 0x11335577. К обеим этим точкам ведут сотни путей, но ради краткости показаны лишь несколько. Все пути в этой ветви графа проходят через процедуру logger(). Может ли она быть источником основной массы наших проблем? Возможно, внутри этой процедуры существует уязвимость форматной строки. Поскольку эта процедура вызывается из многочисленных мест внутри нашего сервера IMAP, логично, что передача форматной строки нескольким командам IMAP могла привести к одной и той же проблеме. Хотя ответ может дать только более глубокий анализ, преимущества автоматизации анализа до вмешательства человека видны сразу. И снова изменения, необходимые для реализации этой дополнительной функциональности, оставлены читателю в качестве упражнения.