SPIKE и BURP в реальном мире компьютерной безопасности, часть 1
Об авторе.
Дон Паркер (Don Parker), GCIA,GCIH, специализируется на обнаружении атак и нештатных ситуациях. Выступает в качестве приглашенного докладчика на различных конференциях, посвященных безопасности. Также публикуется в ряде online и бумажных изданий по компьютерной безопасности. Вы можете связаться с Доном Паркером по адресу dparker@bridonsecurity.com.
Http-прокси и Вы.
Область компьютерной безопасности одна из непрерывно развивающихся областей связанных с компьютерами. Не иссякает поток найденных эксплойтов то к одной то к другой программе. И практически невозможно быть достаточно сведущим во всех областях сетевой безопасности, поэтому, исходя из природы компьютерной безопасности и её многочисленных аспектов, необходимо выбрать собственную нишу и постараться специализироваться в ней. Одна из таких ниш, это безопасность web-приложений в разных формах. Почему я использую выражение «в разных формах»? Потому что не все web-приложения написаны на одном языке, также их нельзя использовать с одними и теми же конфигурационными файлами или одинаковыми бэк-эндами.
Вообще, безопасность web-приложений достаточно интересная область для специализации, в постоянно расширяющимся Интернете всегда будут web-приложения с миллиардами различных применений. И эти приложения естественно разработаны для взаимодействия с потенциальным клиентом. Но нельзя полагать, что если лицо компании в Интернете было создано профессиональными программистами, то оно будет безупречно. Как мы знаем, зачастую получается наоборот, так как невозможно написать идеальный код и это не зависит от используемого языка программирования.
Это приводит нас к одной из граней web-безопасности: очень часто большое число web-приложений написано дома, и говорить в этом случае о гарантиях качества просто не приходится. Программист, работающий в компании, будет счастлив иметь просто вовремя законченный проект, оставляя лишь немного времени для аудита кода. Конечно, есть специализированные инструменты, позволяющие проводить анализ исходного текста, однако множество из них неприменимы из-за большого числа ложных срабатываний, а те, что можно реально использовать почти всегда непомерно дороги.
Даже нам, людям, не имеющим прямого отношения к программированию, я думаю, можно оценить всю сложность написания качественного кода. Это становится особенно актуально, когда речь идёт о программных продуктах масштаба предприятия и тысячах строк кода, из которых они состоят. Однако есть ещё аспект: возможно, у отдельно взятого программиста есть прекрасное понимание жизненного цикла программы, и в то же время у компании в целом может не быть чёткого понимания технического задания, согласно которому пишется код. Хотя это и не критическая составляющая, но она позволит обнаружить некоторые подводные камни в этом вопросе.
И вот программист завершает написание web-приложения которое было ему (или ей) поручено. Сейчас самое время заняться его тестированием и попытаться выявить все недочёты и глюки. Каков же лучший способ это сделать? Хороший вопрос! Это приводит нас обратно к названию этого цикла статей. Тестирование только что написанного приложения лучше всего проводить, используя HTTP прокси. Это превосходный способ взаимодействия с web-приложением при помощи методов, которые нельзя воссоздать при помощи обычной web-сессии. Разработчик может перехватывать запросы клиентской части и изменять каждое поле в этих запросах, чтобы провести стресс-тест.
Ближе к делу!
Надеюсь, вы не заснули до этого момента. Все-таки всегда важно выдать теорию по теме, чтобы лучше понять суть практики. Два HTTP прокси, которые мы рассмотрим и будем использовать это SPIKE и BURP. Первый был написан очень талантливым человеком – Дейвом Эйтелом (Dave Aitel) из компании Immunitysec. Второй, BURP, создан, насколько я знаю, разными людьми. К сожалению, я не мог отыскать список людей участвовавших в его разработке.
Настало время установить SPIKE прокси, который вы наверное уже скачали, пользуясь ссылкой из предыдущего абзаца. Вы обнаружите, что для работы SPIKE потребуется интерпретатор Python. Пожалуйста, зайдите на CPAN и загрузите оттуда исполняемый файл Python. Для этого вам потребуется указать e-mail адрес, только и всего. Сейчас, когда у вас уже установлен Python, необходимо переместить SPIKE в корневую директорию диска c:\. Запустите командную строчку DOS и перейдите в каталог со SPIKE. Еще желательно прочесть README.txt чтобы правильно настроить ваш web-браузер.
Рисунок 1
Рисунок 2
В качестве последнего шага просто запустите runme.bat. Напечатав в строке URL вашего браузера spike/ вы увидите SPIKE. Всё, теперь мы в деле!
Мои поздравления – вы только что установили и настроили HTTP прокси. Хотя, что с ним можно сделать? Очень просто, давайте развлечёмся с web-сервером. В нашем случае, для тестирования, я просто установил Apache на виртуальную машину VMware. Это позволить поиграть с настройками SPIKE, так сказать, в «лабораторных условиях». Никаких дополнительных манипуляций с web-сервером не проводилось. В завершение, я установил на него урезанную версию своего собственного сайта.
Время для веселья.
Где бы вы ни работали, под рукой всегда должен быть какой-нибудь снифер, запущенный в фоне. Так можно будет проверить вывод программ в случае расхождений или появления странных результатов. И наш случай не исключение. Я воспользуюсь TCPDUMP от MicroOLAP, который отлично работает под WindowsXP SP2. К тому же он бесплатен для домашнего использования. Инсталляция этой утилиты была описана в нескольких моих статьях, поэтому я не буду на этом останавливаться. Скажу проще, - распакуйте файл и скопируйте его в корневой каталог вашего диска c:\
Теперь, когда у нас есть работающий снифер, нужно всего-навсего скомандовать ему заносить в лог только пакеты, проходящие между машиной, на которой запущен SPIKE и компьютером с web-сервером Apache. Хотя это скроет часть пакетов, которые атакующий в реальности всё же будет видеть. Позже вы можете запустить tcpdump для сбора только пакетов содержащих в себе 80ый порт. Например, взгляните на нижеприведённый снимок экрана с работой tcpdump:
Рисунок 3
Видно, что я собрал 945 пакетов за одну или две секунды сессии tcpdump. Это фоновая активность на моей машине и она очень хорошо показывает, почему следует намеренно сужать фильтр сбора пакетов, как в тестовых условиях, так и при реальной работе. Как видите, есть достаточное количество вещей, которое необходимо держать в голове, даже чтобы познакомиться с работой HTTP прокси. Хотя ведь всегда нужно сначала сделать «домашнее задание» перед тем как начинать изучать что-то новое. Иначе вы можете легко запутать себя или, что еще хуже, дойти до точки, когда совсем отступитесь от изучения конкретной утилиты. На этом прервёмся, но будьте готовы ко второй части статьи, где процесс изучения использования HTTP прокси будет «быстр и стремителен»!
Увидимся.
www.securitylab.ru