Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Fuzzing исследование уязвимостей методом грубой силы.pdf
Скачиваний:
1127
Добавлен:
13.03.2016
Размер:
5.96 Mб
Скачать

Случаи для изучения

177

мент управления) ListView. Таким образом, когда фаззинг завершен, можно просто щелкнуть по соответствующему запросу в контроле ListView, и отобразятся подробности в виде таблиц в контролях Rich$ TextBox и WebBrowser:

rtbRequestRaw.Text = reqString; rtbResponseRaw.Text = dataReceived; wbrResponse.DocumentText = html;

string path = getPath(reqString);

lvwResponses.Items.Add(lvwResponses.Items.Count.ToString()); lvwResponses.Items[lvwResponses.Items.Count 1].SubItems.Add(status); lvwResponses.Items[lvwResponses.Items.Count – 1].SubItems.Add(reqHost); lvwResponses.Items[lvwResponses.Items.Count – 1].SubItems.Add

(requestString.Substring(0, requestString.IndexOf("\r\n")));

lvwResponses.Refresh();

requestsRaw[lvwResponses.Items.Count – 1] = reqString; responsesRaw[lvwResponses.Items.Count – 1] = dataReceived; responsesHtml[lvwResponses.Items.Count – 1] = html; responsesHost[lvwResponses.Items.Count – 1] = reqHost; responsesPath[lvwResponses.Items.Count – 1] = path;

Как мы уже говорили, WebFuzz не самый простой в обращении сканер уязвимости. Это скорее инструмент, который призван помочь знающе$ му профессионалу в фаззинге определенных фрагментов запроса HTTP. Полный исходный код и двоичный код этой программы доступны на www.fuzzing.org.

Случаи для изучения

Итак, мы теперь понимаем, как и почему построен WebFuzz, пора пе$ рейти к более важным вещам. Посмотрим, как он работает.

Обход каталогов

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

Обратные пути обычно связаны с отсылкой серии последовательностей

../, что позволяет получить доступ к каталогу более высокого уровня.

178

Глава 10. Фаззинг веб<приложений и серверов: автоматизация

Символы обратного пути часто кодированы в URL, чтобы обойти про$ стые фильтры$детекторы. Если к каталогам имеется доступ из броузе$ ра, часто это все, что требуется, хотя в большинстве случаев нужно прибавить и имя существующего файла. При тестировании на атаку обратного пути рекомендуется добавить имя файла, который по умол$ чанию существует на сервере$объекте. Например, для Windows это мо$ гут быть boot.ini или win.ini, поскольку это файлы ASCII, которые лег$ ко распознаются и существуют во всех современных операционных системах Windows.

Рассмотрим для начала простую атаку обратного пути в каталоге в Trend Micro Control Manager1, которая вызвана неверным вводом данных в параметр IMAGE на странице rptserver.asp. Мы будем исполь$ зовать WebFuzz для отсылки get$запроса к странице rptserver.asp, но заменим корректный параметр IMAGE фаззинговой переменной [Tra versal], за которой следует известный файл – в данном случае win.ini. Результаты вы можете видеть на рис. 10.8: действительно, после всего одного обратного пути обнаружен обратный путь в каталоге.

Рис. 10.8. Обратный путь в каталог в Trend Micro Control Manage

1http://www.idefense.com/intelligence/vulnerabilities/display.php?id=352

Случаи для изучения

179

Рис. 10.9. Обратный путь в каталог в Ipswitch Imail Web Calendaring

Рассмотрим иной пример, чуть более сложный. Уязвимость в Ipswitch Imail Web Calendaring1 показала нам, что для того чтобы найти обрат$ ный путь в каталоге, порой нужно отправить запрос к чему$то несуще$ ствующему. В данном случае уязвимость обратного пути в каталоге была обнаружена, когда обратный путь относился к несуществующей странице JSP. Вновь применим WebFuzz (рис. 10.9).

Для тестирования этой уязвимости применим метод GET к серверу, ко$ торый запрашивает несуществующую веб$страницу blah.jsp, после ко$ торой указаны обратный путь и, наконец, обычный файл boot.ini. На рис. 10.9 демонстрируется, что необходимо несколько запросов, но по$ сле пяти… да$да, уязвимость обнаружена.

Переполнение

Несмотря на относительную редкость в мире веб$приложений, перепол$ нения буфера могут в них наблюдаться – как и в консоли или приложе$ ниях GUI, и на тех же основаниях. Это происходит, если вводимые

1http://www.idefense.com/intelligence/vulnerabilities/display.php?id=242

180

Глава 10. Фаззинг веб<приложений и серверов: автоматизация

пользователем данные недостаточно тщательно отфильтрованы, в ре$ зультате чего они достигли слишком большой длины и переполнили буфер фиксированного размера. Переполнения особенно опасны, по$ скольку могут привести к исполнению ненадежного кода. Тем не ме$ нее, при фаззинге самый надежный индикатор ошибки – это тот факт, что приложение упало после запроса, содержащего строку чрезмерной длины. Применив при фаззинге дебаггер к объекту, мы можем опреде$ лить, вызывает ли переполнение только DoS$атаку или же может при$ вести и к выполнению удаленного кода.

Чтобы проиллюстрировать использование WebFuzz для выявления уязвимостей переполнения буфера, используем простой пример. Что может быть проще, чем переполнение на PMSoftware’s Simple Web Server1? В данном случае нам нужно всего лишь отправить длинный запрос GET к серверу. Итак, отправляем следующий запрос, в который входит фаззинговая переменная переполнения:

GET /[Overflow] HTTP/1.1

Сначала выдается только ошибка 404 – Page Not Found (Страница не найдена), но на рис. 10.10 видно, что после десятого запроса WebFuzz перестает получать какие$либо ответы. Почему?

Рис. 10.10. Пример переполнения буфера веб+сервера

1http://secunia.com/advisories/15000/

Случаи для изучения

181

Рис. 10.11. Пример сообщения веб+сервера об ошибке

Ответ становится очевидным при взгляде на сервер, на котором рабо$ тает Simple Web Server, потому что появляется всплывающее окно, приведенное на рис. 10.11.

Это недобрый знак (по крайней мере для Simple Web Server). Когда ок$ но сообщения об ошибке закрывается, то же происходит и с приложе$ нием. Да, мы имеем дело по крайней мере с DoS$атакой. Однако есть ли у нас возможность исполнения кода? Ответ видим рис. 10.12, на ко$ тором примененный дебаггер показывает, что EIP находится под кон$ тролем, а это делает возможным исполнение кода. Если вам не так уж много известно о переполнении буфера, не стоит волноваться. Это луч$ ший из возможных сценариев. Не всегда желанный плод висит на$ столько низко.

Рис. 10.12. Пример переполнения веб+сервера

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]