Глава 5. Детальное описание некоторых опций.

1. Технология мутации
Мутация позволяет Nikto комбинировать различные тесты или предугадывать поведение сервера. Использование данной технологии приводит к генерации огромного количества запросов к цели. Для выбора конкретного типа мутации укажите его номер.
1. Проверка наличия каждого файла в каждой директории. Выбор этой опции разбивает каждый адрес который есть в базе на файл и директорию. После этого в каждой получившейся директории проверяется наличие каждого файла.
2. Поиск файлов с паролями. Данная опция создаёт список самых распространённых вариантов файлов содержащих пароли с именами типа «pass», «passwd», «password» и расширениями «txt», «pwd», «bak» и т.д.
3. Поиск пользователей Apache (запросы типа /~имя_пользователя). Данный вариант поиска использует небезопасную настройку модуля UserDir, с помощью которых можно раскрыть имена настоящих пользователей системы. Фактически поиск производится по технологии Brute-force.
4. Поиск пользователей cgiwrap (/cgi-bin/cgiwrap/~имя_пользователя). Использование дефекта cgiwrap который позволяет раскрыть реальные имена пользователей. Фактически поиск производится по технологии Brute-force.

2. Выводимая информация
Опции для выводимой информации
1. Показ редиректов. Показывать все запросы при которых сервер отвечает редиректом.
2. Показывать возвращённые сервером cookies.
3. Показывать все запросы с ответом 200 «ОК». Может быть использовано для отладки.
4. Показывать адреса для доступа к которым требуется пройти аутентификацию. Адреса будут показываться
если в заголовке ответа обнаружится надпись «authorization required»
D - отладочная опция. Устанавливает вывод всей отладочной информации — заголовков, содержимого и т.д.
V - показ полной информации о работе Nikto.

3. Настройка сканирования.
Этот параметр может быть использован для уменьшения количества проводимых программой тестов. С помощью него пользователь может исключить некоторые варианты проверок, сделать само сканирование продуктивнее и быстрее. Типы проводимых тестов могут быть определены через опцию -T (-Tuning). Пример когда требуется провести тесты «Удалённое раскрытие файлов» и «Удалённое выполнение команд».
Если в качестве одного из параметров указана буква «x» то выполнятся все типы проверок кроме указанных до неё. В нижеприведённом случае будут проведены все проверки кроме «Удалённое раскрытие файлов» и «Удалённое выполнение команд».
Допустимые значения этой опции таковы:
0. Загрузка файлов. Поиск уязвимостей позволяющих загружать файлы на сервер.
1. Интересные файлы/Взятые из логов запросы. Поиск неизвестных, но подозрительных файлов или способов атак которые были взяты из логов других веб-серверов (если у Вас есть информация по таким запросам то свяжитесь пожалуйста с нами).
2. Небезопасная конфигурация / Стандартные файлы. Поиск стандартных или неправильно настроенных файлов каких-либо приложений. Это может быть документация или ресурсы защищённые паролем.
3. Раскрытие информации. Поиск ресурсов получения дополнительной информации о цели. Это может быть
установочная директория или стандартный аккаунт.
4. Инъективные уязвимости. А именно XSS/script/HTML-инъекции.
5. Удалённый поиск файлов — в пределах корневой веб-директории. Поиск ресурсов позволяющих установит наличие файлов в системе в пределах корневой директории веб-сервера.
6. Отказ в обслуживании. Поиск уязвимостей которые могут привести приложение, веб-сервер или сервер целиком к отказу в обслуживании. (подразумевается не намеренная атака (видимо имеется в виду использование кучи ботов — п.п.)).
7. Удалённый поиск файлов. Поиск уязвимостей которые позволили бы неавторизированному пользователю производить обнаружение различных файлов в пределах всего сервера, а не только в веб-директории как в варианте 5.
8. Выполнение команд / Удалённый шелл. Поиск уязвимостей позволяющих выполнять удалённо команды
системы или разместить шелл.
9. SQL-инъекции. Любые виды атак допускающие выполнение SQL-кода в базе данных приложения.
a - Обход аутентификации. Поиск уязвимостей позволяющих получить доступ к защищённым авторизацией ресурсам.
b - Идентификация программного обеспечения.
c - Удалённое подключение кода. Поиск возможностей при которых в код приложения может быть подключён и выполнен удалённый код.
x – Использовать все виды проверок кроме указанных вместе с этой опцией.

4. Работа с одиночными запросами.
Данный метод был разработан для анализа отдельных запросов, а не полного сканирования. Он может использоваться для подтверждения результатов сканирования. Опция так же позволяет указать большинство параметров нужных для проведения запроса. Обратите внимание на то что большинство опций могут иметь пустое значение или значение по умолчанию. Для удобства некоторые данные запрашиваются в вопросительной форме. В этом случае ответы «Да» и «Нет» заменяются цифрами 1 и 0 соответственно. Вот пример работы с одиночным запросом.





Глава 6. Выводимая информация и отчёты.

1. Форматы экспорта информации.
Nikto сохраняет полученную информацию в трёх основных вариантах: в TXT, CSV и HTML. Вы можете установить нужный Вам формат сохранения данных через опцию -F(Format). Если Вы используйте опцию -F без указания формата то Nikto сохранит полученные данные в формате txt. DTD для вывода данных в XML-формате располагается в директории «docs» (nikto.dtd).

2. Настройка HTML-отчётов.
HTML-отчёты генерируются с помощью файлов-шаблонов располагающихся в папке «templates». Переменные обозначенные как «#имя_переменной» заменяются на их содержимое при генерации отчёта. Файлы «htm_start.tmpl» и «html_end.tmpl» содержат начало и конец генерируемого HTML-отчёта соответственно. Файл «html_summary.tmpl» содержит начальную часть самого отчёта. «htm_host_head» содержит заголовок который уникален для каждого хоста. И шаблоны «htm_host_item.tmpl» и «htm_host_im.tmpl» содержат информацию об
угрозах обнаруженных на хосте и информацию с системными сообщениями соответственно. В этих шаблонах используются все допустимые переменные. В будущем документация будет содержать список допустимых имён переменных и их описание. Информация об авторских правах не может быть удалена из шаблона «htm_end.tmpl», только перенесена в
другую часть шаблонов.

Глава 7. Тестирование и написание собственного кода.

1. Значение полей баз данных.
Почти все записи о проводимых программой тестах содержатся в файле «scan_database.db», но и в других базах имеется подобная информация. Вот описание значений полей этих баз.

(вставляю картинкой т.к. не знаю как сделать таблицу)


2. Проверки устанавливаемые пользователем.
Пользователи могут добавлять и свои тесты в дополнение тем которые уже имеются у Nikto в базах. Для этого Вам нужно поместить синтаксически корректный файл-БД в директорию плагинов (plugins), с именем начинающимся на букву «u», и данные будут автоматически загружаться с остальными проверками указанной после «u» базы. Например, если Вы создадите файл «udb_outdated» то он будет загружен как часть базы «db_outdated». Синтаксис этого файла можно проверить введя параметр «-dbcheck». Для каждого теста требуется указывать уникальный «OSVDB ID». Вы можете указывать 0 т.к. это значение используется для уязвимостей которых нету в базе OSVDB. Было бы неплохо если Вы будете отсылать информацию о новых уязвимостях по адресу «moderators@osvdb.org»
Для поля «TEST ID» лучше указывать уникальные номера от 400000 до 499999 для того что бы Ваши тесты никак не пересекались с тестами Nikto. Имейте в ввиду что номера выше 500000 уже зарезервированы. Пожалуйста помогайте Nikto развиваться отсылая Вашу информацию об уязвимостях или отдельных тестах на sullo@cirt.net.

3. Синтаксис содержимого баз данных.
Базы данных являются CSV-файлами. Значения их полей помещаются в кавычки и разделяются запятыми. Стандартный список полей таков: Test-ID, OSVDB-ID, Tuning Type, URI, HTTP Method, Match 1, Match 1 And, Match 1 Or, Fail 1, Fail 2, Summary, HTTP Data, Headers. Вот пример синтаксически-правильной записи поверки:
“120?,”3092?,”2?,”/manual/”,”GET”,”200?,”",”",”",”",”Web server manual”,”",”"

4. Плагины.
Плагины для этой программы представляют из себя обычные Perl-скрипты, код в которых написан в соответствии со стандартами Nikto. Все плагины должны быть названы в формате «nikto_name.plugin», где «name» - имя плагина. Файл плагина должен содержать функцию называющуюся как он сам (без окончания «.plugin»). Например в плагине nicto_mycode.plugin» обязательно должна находиться функция «sub nikto_mycode()». Такая функция будет вызываться при загрузке плагина. Все плагины должны быть помещены в соответствующую папку и записаны в файл «nikto_plugin_order.txt» иначе они не будут подключаться.

5. Идентификаторы проверок.
Любой тест, находящийся в базе или в коде, должен иметь уникальный номер. Нумерация для них следующая:
1. 000000 – проверки из файла db_tests
2. 4000000 – пользовательские проверки (файлы udb*)
3. 500000 тесты из файла «db_favicon»
4. 600000 тесты из файла «db_utdated»
5. 700000 тесты из файла «db_realms»
6. 800000 тесты из файла «db_server_msgs»
7. 900000 проверки установленные в коде.
Для каждой новой проверки как можно больше информации должно содержаться в хэше %TESTS и устанавливаться в коде (плагинах).Эти поля должны включать в себя проверочный URI, сообщение об удачном тесте, HTTP-метод и OSVDB ID уязвимости. Без сообщения об успешной проверке результат теста не будет сохраняться в HTML или XML отчёте. Допустимо что не у каждого теста может быть URI, метод или OSVDB ID. Вот пример обозначения проверки в коде:

6. Авторские права.
Предполагается что любой код или информация по тесту отправленные нам не имеют авторского права. Отправляя подобную информацию Вы должны понимать что она будет опубликована под правами Nikto.

Глава 8. Устранение проблем.

1. SOCKS-прокси.
Nikto не поддерживает работу через подобный тип прокси-серверов.

Глава 9. Лицензия.

1. Nikto
Nikto распространяется под GNU General Public License (GPL) и CIRT Inc. является владельцем авторских прав на него.

2. LibWhisker
LibWhisker распространяется под GNU General Public License (GPL) и Rain Forrest Puppy является владельцем авторских прав на него.

3. Базы проверок.
Лицензия разрешает использовать данные базы только вместе с Nikto. Вы не можете использовать их в других программах без предварительного согласования с CIRT Inc.

Глава 10. Авторы.

1. Nikto
Nikto разрабатывается и поддерживается Sullo, CIRT Inc. Весь код принадлежит CIRT Inc, за исключением LibWhisker из rfp.labs (wiretrip.net).

2. Благодарности.
Многие люди помогали в развитии программы — присылали отзывы, исправления, замечания. Сюда мы внесли самых активных помощников.
· Тестирование Nikto 2: Paul Woroshow, Mark G. Spencer, Michel Arboi, Jericho, rfp.
· Jericho (attrition.org/OSVDB/OSF). Поддержка/идеи/тесты/исправления и помощь с номерами уязвимостей в базе OSVDB
· rfp (wiretrip.net) Поддержка по линии LibWhisker.
· Erik Cabetas — множество исправлений и добавлений.
· Jake Kouns — работа с OSVDB/OSF
· Jabra (spl0it.org) — XML DTD, XML-шаблоны и код для работы с ними.
· Stephen Valdez. Эффективная проверка. Мы все благодарны тебе.
· S Saady. Эффективное тестирование.
· Zeno (cgisecurity.com) — создание зеркала Nikto.
· P Eronen (nixu.com). Предоставил множество исправлений кода.
· M Arboi. Создание кода который реализует совместную работу Nikto с Nessus. Сообщения об ошибках.
· T Seyrat. Работа над релизом Nikto для Debian
· J DePriest. Идеи, испарвления.
· P Woroshow. Идеи, исправления.
· fr0stman. Тестирование
· H Heimann. Тестирование.
· Xiola (xiola.net). Веб-дизайн и многое другое.
Этот документ принадлежит CIRT Inc и не может быть переделан без соответствующего разрешения.