Средства взлома 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
Понятные имена файлов позволят быстро просмотреть директории и визуально определить положение специфических файлов. Число 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-функций.
Для запуска 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 и исследовать любые уязвимости.