Опубликован: 20.02.2007 | Уровень: специалист | Доступ: платный
Лекция 8:

Средства взлома Web-приложений Hacking Tools

Аннотация: Название лекции говорит само за себя. Автор описывает много интересных инструментов, которыми пользуются хакеры, а также приёмы работы с ними

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

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

Конечно, этот короткий список не может охватить особенности конфигурации связки Apache/PHP или детали каждой из рекомендованных настроек Internet Information Server (IIS), но он может послужить основой для создания жесткой политики компоновки Web-сервера. Для проверки стратегии компоновки следует также использовать сканер уязвимости.

Сканеры уязвимости Vulnerability Scanners

У Web-серверов - Apache, iPlanet и IIS - много версий и добавлений для обеспечения безопасности. Обычно у сканера уязвимости есть сканирующий аппарат и каталог. Каталог содержит список общих файлов, файлов с описанием известных уязвимостей и наиболее распространенных способов взлома набора серверов. Например, сканер уязвимости ищет резервные файлы (переименованные из default.asp в default.asp.bak) и пытается осуществить взлом, обходя дерево директорий (вроде проверки ..%255c..%255c). Сканирующий аппарат поддерживает логику для чтения каталога методов взлома, посылает запрос Web-серверу и интерпретирует ответ для определения возможных уязвимостей сервера. Эти утилиты направлены на уязвимости, которые легко зафиксировать с использованием конфигурирования системы безопасности хоста, использования заплаток для системы безопасности и очистки корневой директории Web-сервера.

Whisker

Whisker - не самый древний из сканеров уязвимости CGI-интерфейса ( common gateway interface ). Тем не менее, эта программа была первым средством для совместного использования приемов проверки общей уязвимости, интеллектуального сканирования, которое реагирует на ответные HTTP-коды, и уклонения от систем обнаружения вторжений ( IDS ). Преимущества этой программы в том, что она написана в виде простых (правда, не всегда понятных) Perl-скриптов. При необходимости это позволяет отредактировать программу в простом текстовом редакторе для изменения имен пользователей, паролей и уязвимых CGI-скриптов.

Реализация

В списке уязвимостей программы whisker, возможно, что-то устарело, но он также включает проверки для директорий, которые никогда не исчезнут. Проверки /backup/ или /log/ директорий и текстовых файлов sam.txt никогда не устареют. Чтобы запустить whisker для одного хоста или IP-адреса, воспользуйтесь параметром -h. Параметр -H (обратите внимание на регистр) дает возможность задать файл, который содержит список IP-адресов или имен хостов. Также неплохая идея всегда использовать параметр -w для записи результатов каждой проверки, выполненной сканером. Параметр -W выводит все в HTML-формате. Это может выглядеть как ненужные бантики, но в то же время удобно, и демонстрация возможностей заставит притихнуть противников. Базовый вид командной строки whisker выглядит примерно так.

$ whisker.pl -h 192.168.42.27 -w
- whisker / v1.4.0+SSL / rain forest puppy / www.wiretrip.net -
-( Bonus: Parallel support )
- Loaded script database of 2045 lines
= - = - = - = - = - =
= Host: 192.168.42.27
- Cookie: PREF=ID=28bd8b28723a3f00:TM=1014183574:
  LM=1014183574:S=iaEPbCBRdvA
= Server: IIS/5.0
+ 200 OK: GET /robots.txt

Мы пропустили параметр -W, чтобы сделать вывод лучше читаемым на бумаге. После запуска whisker начинает выводить информацию на экран ( stdout в Unix-терминах). Не потеряйте результаты сканирования; вы можете сохранить их в файл. Параметр командной строки -l с именем файла после него, но мы редко это используем. Вместо этого воспользуйтесь преимуществами командной строки Unix.

$ whisker.pl -h 192.168.42.27 -w -W | tee whisker80_192.168.42.27.html.raw
Совет. Команда Unix tee позволяет перенаправить вывод одновременно в файл и на экран. Это позволяет наблюдать за работой программы в режиме реального времени и сохранить информацию. Это понятнее, чем запуск процесса в фоновом режиме, и понятнее, чем использование команды tail -f.

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

Перед тем как начать изменять командную строку для проверки нестандартных Web-сайтов, сосредоточимся на анализе вывода для поиска уязвимых мест. Ниже мы добавили строку .html.raw к нашему выходному файлу, поскольку файл содержит все ответы Web-сервера, включая каждое сообщение "404 Not Found", которое нам не требуется. Ниже приведен пример удаления этих строк.

$ grep -v 404 whisker80_server.html.raw whisker80_server.html

Другими кандидатами на удаление могут быть строки, содержащие числа 400 (bad request), 401 (unauthorized) и 403 (forbidden). Однако нам интересно проанализировать 400 и 401 ошибки. 400 ошибка должна встречаться редко, пока программа просматривает обычные файлы с обычными расширениями. 401 ошибка означает, что файл существует (возможно), но нам необходимо использовать правильное имя пользователя и пароль для доступа к ним - два вывода, которые может сделать для нас программа whisker. 403 ошибка обозначает файлы или директории, к которым нет доступа, поскольку для доступа к ним требуются другие полномочия. Итак, для удаления только 403 и 404 ошибок воспользуемся следующей командой.

$ grep -v 40\[34\] whisker80_server.html.raw whisker80_server.html

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

$ grep -v 40\[0134\] whisker80_server.html.raw whisker80_server.html

Помните, что если даже сканером анализируется только возврат HTTP-кода 200 для любого уязвимого файла, любая информация может быть полезна. Если запрос к директории /.old/ возвращает код возврата 401, то мы знаем, что директория существует. Возможно, мы сможем получить доступ к ее содержимому другими способами.

Другой фокус заставляет whisker продолжать сканирование сайта, даже если стартовая страница требует аутентификации. Иногда администратор может применить управление доступом к директории верхнего уровня, например /admin/ - но может забыть о доступе к директориям или файлам более низкого уровня, таким как /admin/Docs/default.cfg. Таким образом, можно использовать силовой прием для изменения строки в скрипте whisker.pl. Исходная строка и ее новый вид представлены ниже.

if($D{'XXAuth'} ne ""){
    wprint("- Server demands authorization.");
    wprint("- We don't have a login, so skipping host...\n");
    $D{'XXServerInject'}="exit";}

Приравняйте переменную $D{'XXServerInject'} к чему-либо кроме exit. Это заставит whisker проигнорировать тот факт, что он не имеет должных полномочий для тестируемого сайта.

if($D{'XXAuth'} ne ""){
    wprint("- Server demands authorization.");
    wprint("- We don't have a login, so skipping host...\n");
    $D{'XXServerInject'}="foo";}

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

Исходная версия whisker (1.4) не поддерживает протокол SSL (Secure Sockets Layer). В этом нет ничего страшного, поскольку вы можете установить OpenSSL прокси-сервер (см. раздел " OpenSSL " далее в этой лекции). Но прокси не слишком подходящий вариант, если сканируется

более чем один IP-адрес одновременно. Поэтому H. D. Moore модифицировал программу для поддержки Perl SSL-функций.

Примечание. Модуль Net::SSLeay, как и любой другой Perl-модуль, можно найти по адресу: http://www.cpan.org. Инструкция по инсталляции достаточно проста. Обычная последовательность команд perl Makefile.PL, make, make test и make install для любого модуля. Модуль Net::SSLeay требует работающего пакета OpenSSL. В Unix и Cygwin это делается просто.

Для запуска whisker с поддержкой SSL необходимо использовать параметр -x. По умолчанию будет установлен порт 443, но он может быть изменен с помощью параметра -p.

$ whisker.pl -x -h 192.168.42.27 -w -W | 
   tee whisker443_192.168.42.27.html.raw

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

$ whisker.pl -x -H hosts_ssl.txt -w -W | tee whisker443_hosts_ssl.html.raw

Если вы просмотрели все исходные коды whisker, то вы знаете, что он всегда выполняется как CGI-модуль Web-сервера. Настройте Web-сервер, переименуйте в whisker.cgi и поместите программу в директорию /cgi-bin/ сервера. По умолчанию этот модуль ограничивает функциональность программы сканированием только одного хоста, заданием одного порта и принудительного задания типа удаленного сервера. Но если вы разбираетесь в исходном коде, вы сможете привести CGI-версию в нормальное состояние.

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

Наиболее простое средство обеспечения безопасности, и наиболее часто употребляемое начинающими разработчиками скриптов - переименование идентификационной строки Web-сервера. Как администратор, вы никогда не должны полагаться на непонятный прием обеспечения безопасности на вашем IIS 5.0, который представляется как Apache 1.3.22. Однако некоторые утилиты - whisker входит в их число - не могут запустить специальные тесты для IIS, если он определяется как Apache.

Whisker предоставляет возможность принудительно установить тип удаленного сервера с использованием параметра -S (заглавная).

$ whisker.pl -h 192.168.42.27 -w -W -S "IIS/5.0"

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

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

$D{'XXUserAgent'} = "Mozilla/5.0 [en] (Win95; U)";
$D{'XXForce'}=1 if defined($args{f});

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

$D{'XXForceS'}=1 if defined($args{S});

Другое препятствие для любого сканера уязвимостей состоит в работе с сайтами, которые требуют аутентификации. Базовая HTTP-аутентификация очень проста в реализации. Имя пользователя и пароль кодируются в коде base 64, не шифруясь каким-либо надежным алгоритмом. Вдобавок к этому, аутентификационные полномочия передаются в заголовочной информации, передаваемой клиентом (это может быть Web-броузер или аппарат сканирования уязвимостей). Для всех сайтов, которые требуют базовой аутентификации, используйте параметр -a для задания правильных полномочий. Имя пользователя и пароль разделяются двоеточием.

$ whisker.pl -h 192.168.42.27 -w -W -a "grauf:penguin"

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

Если вы желаете проверить вашу IDS-систему на надежность контроля Web-уязвимостей, то набор параметров -I для вас. Каждый из параметров генерирует URL-запрос, который изменяется разными способами с целью ввести в заблуждение IDS-сигнатуры. Для тестирования IDS выполните каждую из 10 проверок (от 0 до 9) по отношению к серверу из вашей сети.

$ whisker.pl -h 192.168.42.27 -w -W -I3

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

Сергей Хлюкин
Сергей Хлюкин
Россия, Москва, Московский Государственный Открытый Университет, 2007
Игорь Касаткин
Игорь Касаткин
Россия, Москва