"Об’єднання ЮГ"

Чтобы продемонстрировать преимущества XSpider, рассмотрим проблему качества определения уязвимостей с двух точек зрения.

Во-первых, выделим три главных типа уязвимостей по источнику их происхождения:

Во-вторых, проанализируем общий процесс определения уязвимостей по стадиям:

Уязвимости разной природы

Это есть, собственно, все уязвимости, которые публикуются в многочисленных специализированных новостных каналах. Источником информации выступают разработчики ПО, независимые эксперты, честолюбивые хакеры. Осмелимся предположить, что любой уважающий себя сканер безопасности содержит в себе полную базу опубликованных уязвимостей и постоянно ее обновляет. Это необходимо. Но не достаточно. Причина проста: наличие еще двух источников уязвимостей, которые могут быть не менее разрушительны для информационной безопасности.

Еще один вопрос заключается в том, как определяются уязвимости из базы данных. Тут возникает два вопроса:

Здесь очень важно не ограничиваться проверкой баннера, который возвращает о себе тот или иной сервис, а использовать более надежный механизм определения версии ПО. XSpider поступает именно так. Кроме того, если имеется такая возможность, он производит непосредственную проверку на наличие уязвимости, имитируя атаку и проверяя реакцию системы. Это самый надежный путь, но ввиду его небезопасности, данная возможность отключаема через настройки.

Следует также отметить, что любая база уязвимостей неполна по определению. Поскольку в существующем софте постоянно обнаруживаются новые уязвимости, мы никогда не можем быть уверены, что в настоящий момент еще неопубликованные уязвимости не могут быть использованы для атаки извне. В этом контексте было бы крайне полезно уметь проверять подобные "несуществующие" уязвимости. XSpider обладает интеллектуальной способностью конструировать возможные атаки "налету", исходя их конфигурации проверяемой системы. Во многих случаях это помогает.

Возможность данных уязвимостей заранее предсказать нельзя. Причина их появления - отклонения ПО от идеальной конфигурации, которые могут вызваны промахами, несогласованностью действий, недостаточной квалификацией персонала и т.д. От того, насколько "дотошно" и "хитро" сканер будет проверять конфигурацию установленного ПО, зависит надежность его диагностик по уязвимостям данного типа.

XSpider делает это настолько подробно, насколько это возможно в рамках разумного времени (хотя имеются и специальные режимы работы, в которых скорость сканирования несколько падает, зато глубина проверок еще более возрастает). См. очень простой, но показательный ПРИМЕР 4.

Как нетрудно догадаться, вариаций уязвимостей на эту тему может быть огромное количество. К счастью, многие (и наиболее часто эксплуатируемые злоумышленниками) из них могут быть классифицированы. Чаще всего атаки производятся через скрипты, размещенные на WEB-серверах. XSpider ищет подобные уязвимости нескольких типов, наиболее распространненные из которых SQL-инъекции, code-инъекции. Важно, что в каждом конкретном случае конструируются и проверяются лишь те атаки, которые применимы к тестируемому узлу. Как показывает статистика, в половине онлайновых баз данных, публикуемых сейчас в Интеренете, XSpider обнаруживает инъекции того или иного рода.

Способности XSpider глубоко анализировать Интернет-сайты позволяют с успехом использовать его для автоматизированных экспресс-penetration-тестов. По соотношению цена/качество это оказывается во многие разы выгоднее заказных работ.

Этапы сканирования

Это самый простой этап в работе сканера, и, казалось бы, обсуждать тут нечего. Тем не менее это не совсем так.

Достаточно вспомнить, что возможный диапазон номеров составляет более 65 тыс. для TCP- и столько же для UPD-портов. Конечно, в XSpider имеется режим, когда проверяются все без исключения порты, но это требует очень большого времени, так что может использоваться далеко не во всех ситуациях. Возникает задача определения оптимального списка портов, которые надо проверять всегда. В XSpider эта задача решена двумя путями.

Во-первых, имеется возможность ведения пользовательских списков портов.
Во-вторых, список портов, используемый XSpider по умолчанию, тщательно составлялся экспертами на основе многолетнего практического опыта. Конечно, если вы поставите сервис на порт 26872, то он не будет автоматически найден (тогда используйте предыдущую возможность или сканируйте весь диапазон). Зато в подавляющем большинстве случаев XSpider с успехом обнаруживает все открытые порты, причем не только те, на которых стандартно работают известные сервисы. Примеры №1 и №2 отчасти иллюстрируют эту возможность. Список проверяемых по умолчанию портов обновляется по мере по мере появления новой информации у экспертов XSpider.

На этом этапе сканирования производится определение конкретного сервиса, установленного на том или ином порту. Крайне важно не ошибиться на этом этапе, поскольку от этого зависит адекватность диагностик об уязвимостях, получаемых на следующем шаге. Если обнаружен порт №110, то это еще не означает, что надо сразу пытаться проверять для него уязвимости POP3-сервиса (даже в том случае, если сервис возвращает баннер о наличии сервиса POP3). Для общей достоверности результатов сканирования принципиально определить не только тип сервиса, но и его версию. Причем вне зависимости от явного ответа сервиса, поскольку часто из соображений безопасности баннеры сервисов подменяются, чтобы запутать потенциальных злоумышленников.

В целом задача возникает весьма непростая. Решить ее на 100% правильно ее еще никто не сумел. XSpider смог максимально приблизиться к оптимальному ее решению за счет целого ряда специальных механизмов.

Во-первых, допускается возможность установки сервисов на нестандартных для них портах.
Во-вторых, проверка сервисов производится в определенном порядке на основе специально разработанных матриц соответствия. Это позволяет при высокой надежности обеспечить хорошую скорость проверки.
Во-третьих, проверки на наличие каждого сервиса специально оптимизированы и в ряде случаев используются дублирующие, подтверждающие проверки.
Во-четвертых, разработаны специальные эвристические алгоритмы подтверждения версий многих сервисов: HTTP, FTP, SMTP, POP3, DNS, SSH. Спицифика работы этих алогиритмов такова, что в случае положительного результата дается 100% гарантия надежности результата. Если эвристическое подтверждение не сработало, то об этом явно выдается предупреждение. В среднем эффективность данных методов больше 95%.
В-пятых, разработаны специальные алгоритмы работы с RPC-сервисами. Более 30 Windows-сервисов и около 200 Unix-сервисов определяются на случайных портах с точностью до конкретного сервиса. Причем делается это оригинальным алгоритмом. Например, в случае Unix-систем качество определения не зависит от доступности информации о port-mapping.

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

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

Оригинальная база некорректных запросов и сетевых пакетов для более надежного определения ряда уязвимостей, в том числе и в неизвестных базе сервисах.
Возможность прямого тестирования на уязвимость ко многим известным DoS-атакам (при необходимости отключается).
Возможность конструирования новых DoS-атак "на лету".
Многочисленные brute-словари, специально оптимизированные для различных сервисов и типов уязвимостей (в том числе для несанкционированного доступа к каталогам).
Определение множества уязвимостей, связанных с ошибками конфигурации, в том числе незащищенными режимами авторизации, особыми случаями раскрытия информации сервисами и т.д.
Глубокий интеллектуальный анализ WEB-сайтов на уязвимости к SQL- и code-инъекциям, XSS, получению файлов. Важно, что при этом исследуются оригинальные скрипты, разработанный для каждого конкретного WEB-приложения.