CC BY
52
производства // Вестник Самар. гос. техн. ун-та. Сер. Технические науки: Научный журнал. - Самара: СамГТУ 2010. - № 7 (28). - С. 26-31.
2. Дорезюк Н.И. Гармонический анализ периодических неоднородно-стей волнового сопротивления коаксиальных кабелей // Электротехническая промышленность. Серия «Кабельная техника». - 1974. - № 6. - С. 18-22.
3. Митрошин В.Н., Митрошин Ю.В. Автоматизация процесса наложения изоляции при непрерывном производстве проводных кабелей связи // Информационные, измерительные и управляющие системы (ИИУС-2010). Материалы Международной научно-технической конференции (Самара, 1721 мая 2010 г.). - Самара: Самар. гос. техн. ун-т, 2010. - С. 36-40.
СИСТЕМАТИЗАЦИЯ ЭТАПОВ ВОЗНИКНОВЕНИЯ И РАЗВИТИЯ ТЕХНОЛОГИИ ФАЗЗИНГА
© Полухин П.В.*
Воронежский государственный университет, г. Воронеж
В статье представлено исследование исторических этапов эволюции технологии фаззинга, раскрыта их характеристика, дана сравнительная оценка достоинств и недостатков, разработанных на каждом из исторических этапов, технологий тестирования.
Особое внимание автором уделено раскрытию сущности и содержанию фаззинга как нового динамически развивающегося механизма тестирования программного обеспечения, проведен анализ современных веб-технологий, используемых при создании динамических приложений, с целью выявлении особенностей, используемых языков программирования и исполняемых платформ. Это позволит установить основные направления и существующие подходов к тестированию уязвимостей.
Процесс тестирования неотъемлемо связан с процессом разработки веб-приложений и адаптирован для каждой из представленных технологий. Тестирование позволяет в первую очередь получить информации о качестве продуктов, оценить эффективность механизмов и алгоритмов, заложенных в само веб-приложение. Однако современные методы тестирования не позволяют в полной мере выявить все дефекты и установить все аспекты корректности функционирования программ, поэтому все существующие методы и алгоритмы тестирования действуют в рамках формального процесса проверки исследуемого приложения. Такой формальный процесс может доказать отсутствие ошибок с точки зрения используемого метода, тем самым не может учесть ошибки самих разработчиков. С данной проблемой ученые и
* Аспирант кафедры Математических методов исследования операций факультета прикладной математики и механики.
исследователи столкнулись еще в конце ХХ века, что заставило их искать новый подход к комплексному анализу приложений на предмет наличия ошибок, которые могут повлечь за собой серьезные уязвимости и нарушить работу приложения. В скоро такой подход был найден и назван тестированием с помощью технологии фаззинг. Процесс эволюции технологии фаз-зинга претерпел ряд очень важных изменений от момента создания первого инструмента на основе данной технологии до внедрения в коммерческую систему. Исторически эволюцию можно представить в виде таблицы. Материалы показывают, что первое упоминание о фаззинге принято относить к 1988 году. Профессор Висконсинского университета Бартон Миллер и его коллеги с 1988 по начало 1990 годов провели ряд исследований и разработали ряд фаззеров, для проверки надежности работы приложений на различных операционных системах семейства UNIX [1-3].
Таблица l
Систематизация историко-логических этапов эволюции фаззинга
Исторический этап Характеристика исторического этапа
Зарождение технологии фаззинга (конец 1980-х -начало 1990-х гг. XX в.) Проводились исследования приложений с операционных системах семейства UNIX. Профессор Висконсинского университета Б. Миллер ввел понятие «фаззинга». Обоснована природа технологии, описаны методы генерации входных данных и передача их в тестируемое приложение. Опубликованы результаты тестирования и рекомендации по тестированию приложений под UNIX.
Тестирование клиент-серверных приложений на платформе Windows (1990-е гг. XX в.) Б. Миллер анализирует механизм обмена данными между сетевыми службами операционной системы Windows. Разработаны механизмы перехвата и прерывания обращений к системным процедурам выделения и освобождения памяти (alloc и malloc).
Разработка фаззера сетевого протокола (2002 гг. - настоящее время) Характеризуется разработкой в университете Оулу под Р. Каксоне-на первого фаззера сетевого протокола - PROTOS. Опубликован список уязвимостей протокола SNMP v1.
Финансовая поддержка Microsoft, создание первого коммерческого фаззера (20022003 гг.) Инвестирование компании Microsoft проекта PROTOS. Создание компании Codenomic, развитие выпуска первого коммерческого фаззера.
Дальнейшее развитие коммерческих фаззеров (2003 гг - настоящее время) Компания Beyond Security занимается разработкой своего фаззера сетевого протокола для платформа Windows и UNIX - beSTORM.
Появление фаззеров с открытым исходным кодом (конец 2003 гг.) Характеризуется появлением первого фаззера, распространяемого по лицензии GNU GPL. Использование блокового подход (за счет изменения длины блока) для тестирования приложений взаимодействующих по сети.
Фаззер браузерного типа (прокси формат) (2003 гг. -настоящее время) Разработка фаззера, работающего по типу прокси, который отслеживает запросы к веб-браузеру, а затем запускает серию тестов на предмет наличия SQL инъекции и XSS.
Фаззеры безопасности открытого проекта безопасности веб-приложений (OWASP) (2004 гг. - настоящее время) Разработка трех фаззеров: JBroFuz, WSFuzz, WebScarab, для тестирования как веб-приложений, функционирующих по протоколу HTTP, так и веб-служб, работающих по протоколу SOAP.
Продолжение табл. 1
Исторический этап Характеристика исторического этапа
Фаззинг ActiveX компонентов (2006 гг. - настоящее время) Н. Мур представил фаззер AxMan в качестве инструмента тестирования ActiveX компонентов, встроенных в веб-приложение и интерпретируемых браузером Internet Explorer.
Результаты исследований были отражены в серии из четырех статей. Первые статьи были посвящены основным этапам фаззинга, которые они применяли для тестирования UNIX систем, а в двух последующих были отражение методы переноса фаззинга в Windows и Mac OS. Однако фаззер Миллера по современным параметрам довольно примитивен.
Выходные данные фаззера «fuzz» представляли собой поток случайных чисел, которые генерировались и отравлялись в тестируемое приложений через стандартные потоки ввода / вывода или как эмуляция ввода через консоль. Эмуляция консольного ввода была реализована с помощью программы под названием ptyjig. Далее осуществлялся мониторинг тестируемой системы, ожидая завершения процесса обработки каждого набора тестов, затем осуществлялся поиск файла дампа памяти в файловой системе. Если такой файл был найден, это свидетельствовала о произошедшей ошибке, в противном случая, ошибки не произошло. Процесс мониторинга также включал механизм тайм-аутов, используемых для выявления входных данных, которые приводили к зависанию тестируемой системы. В процессе аудита были обнаружены ошибки более чем в четверти программ подвергнутых тестированию [2]. Спустя пять лет Б. Миллер опубликовал исследования, в которых он подробно изложил результаты аудита встроенных в UNIX утилит с применением трех новых инструментов - portjig, xwinjig and libjig. Первый из которых - portjig принимает данные через входной поток и перенаправляет их в поток сетевого взаимодействия, что позволило тестировать сетевые службы. Два других инструмента реализовывали механизмы, которые ранее никем не использовались. Второй инструмент - xwinjig, работал по принципу «человек посередине», пересылая тестовые сообщения между сервером и клиентом, функционирующих под управление Windows. Третий инструмент - libjig, разработан для тестирования управления памятью в приложениях путем перехвата вызовов к системным процедурам выделения памяти, таких как alloc и malloc и прерывающий случайным образом запросы на выделение памяти.
Мы считаем, что результаты тестирования с использованием вышеперечисленных инструментов можно разбить на четыре направления. Во-первых, было повторно проведено тестирования утилит командной строки с использованием fuzz и ptyjig, однако было расширено число тестируемых операционных систем с шести до девяти. Интенсивность ошибок и отказов находилась в диапазоне от 6 % до 43 %,для каждой из тестируемых операционных систем, и лишь для двух порог отказов не превысил 15 %. Во-вторых,
последующее тестирование базировалось на portjig, и было направлено на проверку сетевых служб. Третье направление использовало инструмент xwinjig, и должно была обнаружить ошибки в клиент-серверных приложениях Windows. Несмотря на то, что в серверных приложениях ошибок выявлено не было - в клиентских были обнаружены ошибки которые приводили к зависанию и аварийному завершению приложения. Исследуя показатели каждого режима генерации сообщений xwinjig, были получены различные статистические данные. Режим «случайные сообщения» не позволил выявить никаких ошибок, около 58 % ошибок было обнаружено путем комбинации трех оставшихся режимов генерации, из них 26 % были обнаружены при использовании режима «валидные события». Последнее направление тестирования использовало для тестирования инструмент libjig, основанный на механизме прерывания процедуры освобождения памяти malloc. Из 53 протестированных приложений, 25 (что составляет 47 %) из них содержали ошибки и (или) аварийно завершились.
В 1999 году в университете Оулу начали работать над системой тестирования PROTOS - фаззер протокола. В своем диссертационном исследовании один из разработчиков PROTOS - Р. Каксонен, описал методологию, которая называлась мини-моделирование. В основе методологии лежит упрощенное описание взаимодействия протокола и правила синтаксического построения для автоматизированного создания входных данных, почти соответствующие спецификации протокола. Данный подход в настоящее время принято называть - фаззингом основанный на грамматике (grammar based fuzzing). Такой подход позволяет фаззеру в достаточной мере понимать структуру протокола. Вследствие этого, подсистемы PROTOS создавались сначала для анализа спецификации протоколов, а затем создавались пакеты, которые нарушали эти спецификации или, по расчетам, не должны были работать корректно.
В 2002 году компания Microsoft, обеспечила инвестиционную поддержку развития инструмента PROTOS, вследствие чего в 2003 году команда разработчиков PROTOS основала Codenomicon - компанию, основной профиль которой был направлен на разработку коммерческих тестовых систем на основе фаззинга. Продукт до сих пор базируется на системе тестирования, описанной в университете Оулу, однако расширен пользовательским интерфейсом и методом определения ошибок с помощью системы оценки состояния. Параллельно с развитием инструмента PROTOS, компания Beyond Security выпускает свой коммерческий продукт под названием beSTRORM. Данный продукт предназначен для поиска уязвимостей в сетевых протоколах, например HTTP. beSTORM работает на платформах Windows, UNIX и Linux и имеет в составе два отдельных компонента для тестирования и мониторинга.
После появление PROTOS в 2002 году Д. Айтель разработал первый фаззер с открытым исходным кодом под названием SPIKE, распространяв-
шийся по общедоступной лицензии GNU(GPL). В фаззере Айтеля использовал блоковый подход и был предназначен для тестирования приложений взаимодействующих по сети. В SPIKE используется более продвинутый подход, по сравнению с фаззером Б. Миллера. Это выражается в возможности описания блоков данных переменной длины. SPIKE может как генерировать случайные данные, так и использовать библиотеку уже имеющихся значений, а предопределенные функции (Sun RPC и Microsoft RPC) способны создавать типовые протоколы и форматы данных.
В это же время Д. Айтель выпустил фаззер SPIKE proxy - фаззер брау-зерного типа, написанный на Python. Он работает как прокси, отслеживая запросы веб-браузера, а затем позволяет запустить серию заранее подготовленных запросов к веб-сайту на предмет обнаружения таких уязвимостей, как SQL инъекции, переполнение буфера и межсайтовый скриптинг (xss). Большинство инноваций в фаззинге, после выхода SPIKE, воплотились в инструментах для различных направлений фаззинга. Так Михал Залевски в 2004 году особое внимание уделил фаззингу веб-браузеров и выпустил фаззер -mangleme, представляющий собой CGI скрипт, непрерывно генерирующий неправильно построенный веб страницы на html. Компания spydynamics выпустила компонент SPI fuzzer, который является частью приложения Web-Inspector. SPI fuzzer представляет собой простой фаззер с графическим интерфейсом, дающий пользователю полный контроль над формированием и анализом HTTP запросов. Для составления тестов необходимо хорошее понимания протокола HTTP.
Параллельно с выпуском коммерческих продуктов open web application security project(OWASP) выпустил ряд фаззеров с открытым исходным кодом - WebScarab, JBroFuzz и WSFuzzer. Первые два продукта предназначены для тестирования запросов по протоколам HTTP и HTTPS, а третий продукт предназначен для тестирования веб-служб. 2006 получил развитием нового направления - фаззинг ActiveX. Зиммер Д. разработал COMRaider, а Мур Х. - AxMan. Обе программы были предназначены для исследования элементов ActiveX, которые используются в веб-приложениях, при обращении через браузер Internet Explorer.Ошибки в таких приложениях представляют значительную угрозу, так как большинство пользователей используют именно этот браузер.
Таким образом, нами была выявлена значимость фаззинга как нового динамически развивающегося механизма тестирования программного обеспечения, раскрыты историко-логические этапы возникновения и развития технологии фаззинга, обобщены разработки основных мировых научных школ к пониманию природы и внутренних инструментов, основанных на данной технологии. Проведен анализ современных веб-технологий, используемых при создании динамических приложений, с целью выявлении спе-
цифических особенностей используемых языков программирования и исполняемых платформ, с целью выявления основных направлений и подходов к тестированию, используя фаззинг.
Список литературы:
1. Casella G., Fienberg S., Olkin I. The Bayesian Choice / G Casella, S. Fien-berg, I. Olkin. - Springer, 2007. - P. 285-310.
2. Russel S., Norvig P. Artificial Intelligence A Modern Approach / S. Russel, P. Norvig. - Prentice Hall, 2009. - 599 p.
3. Zalewski M. The Tangled Web. A Guide to Securing Modern Web Applications / M. Zalewski. - No starch Press, 2012. - 477 p.
