Ознакомительная версия.
Применение автоматизированных инструментальных средств для тестирования на проникновение
Автоматизированные инструментальные средства, несмотря на некоторые их недостатки, – широко приветствуемое дополнение при выполнении тестирования на проникновение. Большинство организаций, которые выполняют тестирование на проникновение, полагаются на автоматизированные инструментальные средства вне зависимости от того, являются они купленными за деньги коммерческими, свободно распространяемыми инструментальными средствами или инструментальными средствами, разработанными внутри самой организации. Представьте себе сценарий, согласно которому читателя попросили бы выполнить тестирование на проникновение в удаленную сеть, состоящую из пяти хостов. У читателя есть два варианта действий. Он может протестировать удаленную сеть вручную или в процессе тестирования использовать некоторые из автоматизированных средств, чтобы они помогли ему провести тестирование. Вообразите, насколько неэффективно было бы вручную воспользоваться Telnet, чтобы проверить открытые порты у всех пяти хостов. Очевидно, что читателя следовало бы отнести к несколько странным людям, если он подумал бы решить вручную простую, но очень трудоемкую задачу начального сканирования портов, которая присуща большинству тестов на проникновение. В следующих секциях будет показано, каким образом коммерческие и свободно распространяемые инструментальные средства могут оказаться полезными при тестировании на проникновение.
Тестирование коммерческих инструментальных средств
Давайте рассмотрим первоначальный сценарий, согласно которому читателю следовало бы протестировать на проникновение сеть, состоящую из пяти хостов с IP-адресами от 192.168.0.1 до 192.168.0.5. Это – вся информация, которая была предоставлена читателю. Больше неизвестно никаких данных ни об операционных системах, ни о прослушивающих сеть сервисах. Каким образом автоматизированные коммерческие инструментальные средства смогут помочь повысить эффективность тестирования настолько, насколько это возможно? Для начала читателю следовало бы приобрести лицензии на выбранные инструментальные средства. Вне зависимости от того, был ли выбран сканер Internet Scanner, CyberCop или eEye Retina, процесс получения лицензии имеет много общего. Просто запустите программу, предоставьте ей необходимую информацию, а затем введите диапазон IP-адресов, который читатель желал бы отсканировать. Некоторые коммерческие инструментальные средства предоставляют своему пользователю возможность предварительного выбора типа сканирования, которое он хотел бы выполнить, как это показано на рис. 17.4. На рисунке 17.4 показан экран выбора режимов сканирования сканера Internet Scanner.
Рис. 17.4. Выбор режимов сканирования сканера Internet Scanner
Начиная с этого момента, от читателя требуется просто подождать окончания работы программы: сканирования, анализа его результатов и выдачи отчета. После этого последующие шаги могут различаться. К сожалению, большое число консультантов и консультирующих организаций думают, что следующим логическим шагом является передача своему клиенту отчета вместе со счетом за проведенную работу. Вместо того чтобы просто передать отчет, следовало бы проанализировать его результаты и при необходимости вручную проверить их. Большая заслуга коммерческого инструментария заключается в определении основного направления реальных работ. Например, допустим, что после сканирования коммерческий сканер утверждает, что все пять хостов не защищены от уязвимости showcode.asp информационного сервера Интернет IIS, работающего под управлением Windows NT. Было бы мудрым решением вручную проверить каждый хост и определить, действительно ли они уязвимы так, как это утверждает программа. Сначала читатель должен проверить, что на каждом из хостов установлена операционная система Windows NT и информационный сервер Интернет IIS. Это можно сделать несколькими различными способами (вероятно, их много). Одним из них является использование команды Telnet следующим образом:
telnet www.example.com 80
HEAD / HTTP/1.0<enter><enter>
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Mon, 04 Feb 2002 21:41:17 GMT
Connection: Keep-Alive
Content-Length: 19398
Content-Type: text/html
Cache-control: private...
Инструментарий и ловушки
Изменение баннера HTTP
Простой захват данных заголовка протокола HTTP не всегда эффективен, потому что на большинстве вариантов операционной системы *NIX очень просто изменить текст баннера. При работе под управлением операционных систем компании Microsoft для изменения баннера следует при помощи шестнадцатеричного редактора отредактировать файл W3SCV.DLL и заменить баннер на то же самое число символов. Кроме того, есть множество приложений независимых производителей, которые пытаются скрыть информацию баннера.
Удачей для тех, кто занимается тестированием на проникновение, является наличие многочисленных способов идентифицировать удаленные операционные системы. Такие вещи, как генерируемые Web-сервером ошибочные страницы или даже специфический состав пакетов протокола TCP, могут стать ключом к разгадке типа удаленной операционной системы.
Как читатель может видеть, возвращенная инструментальным средством информация идентифицировала систему как информационный сервер Интернет-компании Microsoft IIS 4.0. Другой способ идентификации выполняющейся на хосте операционной системы заключается в том, чтобы просто обратиться к Netcraft по адресу http://uptime.netcraft.com/up/graph/ и ввести IP-адрес или URL-сайта, о котором идет речь. На рисунке 17.5 показаны результаты работы Netcraft. Как можно видеть, Netcraft идентифицирует удаленную операционную систему и предоставляет другую потенциально ценную информацию о периоде работоспособного состояния машины.
Рис. 17.5. Отчет Netcraft
Путь читатель сделает вид, что он решил использовать метод Telnet на всех пяти хостах. На последнем тестируемом хосте он получит следующую информацию:
telnet www.example.com 80
HEAD / HTTP/1.0<enter><enter>
HTTP/1.1 200 OK
Date: Mon, 04 Feb 2002 21:48:31 GMT
Server: Apache/1.3.19 (Unix) mod_ssl/2.8.4 OpenSSL/0.9.6b
Last-Modified: Tue, 29 Jan 2002 15:13:47 GMT
ETag: “21-1a7a-3c56bc2b”
Accept-Ranges: bytes
Content-Length: 6778
Connection: close
Content-Type: text/html
Создается впечатление, что последней системой является Apache, которая выполняется под управлением одного из вариантов системы UNIX. Сейчас читатель знает, что информация об уязвимости информационного сервера Интернет IIS на пятом хосте неверна. Поэтому нет необходимости тестировать хост дальше. Возможно, что этот хост подвержен уязвимости систем Apache или UNIX и в дальнейшем должен быть исследован более подробно. В этом кроется ключ к разгадке возможной тайны четырех оставшихся хостов. Кажется, что на них установлена операционная система Windows NT с информационным сервером Интернет-версии 4.0. Оставшиеся хосты в дальнейшем должны быть протестированы, чтобы гарантировать фактическое существование уязвимости.
Для завершения рассматриваемого теста без знаний об уязвимости читателю не обойтись. К сожалению, коммерческие инструменты в этом вопросе особенно не помогут. Хотя некоторые из них предоставят ссылки на ресурсы Интернет, воспользовавшись которыми можно прочитать об уязвимости. К счастью, в Интернете можно найти многочисленные ресурсы, которые систематизируют информацию об уязвимости вплоть до того, что приводятся сведения о том, как протестировать интересующую уязвимость. Одним из таких ресурсов является www.securityfocus.com. Запустив поиск на сайте securityfocus.com для «showcode.asp», читатель может найти URL www.securityfocus.com/bid/167, который предоставит ему всю необходимую информацию. Для этого в окне браузера следует ввести следующий URL: www.example.com/msadc/Samples/SELECTOR/showcode.asp?source=/msadc/Samples/../../../../../boot.ini.
В результате в окне браузера читатель должен увидеть содержимое файла BOOT.INI, расположенного при всех инсталляциях операционной системы Windows NT в ее корневой директории. Если файл не отображается, то следует еще раз попытаться воспользоваться той же самой программой использования уязвимости (exploit) для чтения других известных читаемых файлов. После достаточного тестирования уязвимости можно определить, действительно ли хосты уязвимы к просмотру читаемых файлов. Моментальные снимки экранных форм читаемых файлов являются хорошим дополнением к отчету, позволяющим донести до сведения читателя суть вопроса.
Как читатель может увидеть, применение коммерческих сканирующих инструментальных средств может помочь повысить эффективность тестирования хостов на уязвимости. Только представьте себе попытку тестирования хостов без автоматизированного инструментария. В настоящее время база данных CVE содержит около 1604 элементов (по данным на 13 января 2002 года). Поэтому попытка вручную проверить каждую возможную уязвимость превращается в трудновыполнимую задачу, сама мысль о решении которой отпугивает. С помощью автоматизированного инструментария исследователь просто должен проверить результаты их работы и повторно протестировать любые системы, тестирование которых выявляет слишком большое число аномалий. Чрезмерное число аномальных результатов является основанием для того, чтобы заподозрить сканер в неверной работе. Аномальные результаты тестирования и перспектива обязательной ручной перепроверки всех результатов являются причиной использования консультантами более чем одного инструментария сканирования. Обычно они используют коммерческий сканер совместно со свободно распространяемым инструментальным средством.
Ознакомительная версия.
