Здравствуй, codeby!
Тестирование безопасности платформы, на которой развернуто веб-приложение, так же важно, как и тестирование безопасности самого приложения. Вся инфраструктура сильна настолько, насколько сильно ее самое слабое звено. Некоторые ошибки конфигурации платформы могут скомпрометировать веб-приложение так же, как и уязвимое приложение может скомпромитировать сервер.
Например, уязвимость, позволяющая неаутентифицированному пользователю загружать на веб-сервер файлы, может привести к тому, что атакующий загрузит на сервер вредоносный код, который будет выполняться так же, как и код приложения, либо изменить некоторые части приложения, подменив его оригинальные файлы на свои собственные.
Как вы помните, в прошлых статьях мы провели разведку, выявили, из каких элементов состоит инфраструтура приложения и по итогу составили карту архитектуры приложения. Теперь необходимо провести анализ конфигурации и выявить типичные проблемы для тестируемой системы. Сервер аутентификации, сервер баз данных, ПО веб-сервера — любой из элементов системы по возможности должен быть проверен.
Известные уязвимости.
При тестировании методом Black Box анализ уязвимостей сервера может быть затруднительным.
Во-первых, тестирование некоторых уязвимостей может привести к непредсказуемым результатам на сервере или даже сделать продолжение тестирования невозможным, к примеру, в случае успеха тестирования dos-атаки.
Во-вторых, некоторые автоматизированные инструменты для тестирования определяют уязвимости на основе полученой версии веб-сервера. Это может привести как к ложно-положительным, так и к ложно-отрицательным срабатываниям.
С одной стороны — если администратор скрыл версию веб-сервера, сканер уязвимостей не пометит сервер, как уязвимый, даже если он действительно уязвимый. С другой стороны, если поставщик программного обеспечения после патчей безопасности не изменяет информацию о версии, сканер будет находить несуществующие уязвимости. Последний случай весьма распространен, например, в большинстве дистрибутивов Linux, таких как Red Hat, Debian или SuSE.
В-третьих, обычно сканеры обнураживают уязвимости в элементах, которые выставлены наружу, то есть с которыми клиент взаимодействует напрямую, например в веб-сервере. И сканер, как правило, не может найти уязвимости в таких элементах, которые скрыты от прямого воздействия — сервер базы данных или система аутентификации.
В-четвертых, не все поставщики программного обеспечения раскрывают информацию о уязвимостях в своем ПО. Сканеры просто не могут знать об этих уязвимостях, даже если они есть. Как правило, сканеры полезны при тестировании распространенного ПО, такого как веб-сервер Apache, Microsoft IIS или Lotus Domino, и неэффективны при тестировании малоизвестных программных продуктов.
Резюмируя вышесказанное — анализ уязвимостей лучше всего проводить, получив информацию от заказчика о внутреннем устройстве инфраструктуры (методом White box или Grey box). С помощью этой информации тестировщик может получить информацию от самого поставщика ПО и проанализировать, какие уязвимости могут присутствовать в системе и как они могут повлиять на веб-приложение. Если это возможно, тестировщик должен попытаться проэксплуатировать уязвимости, понять их реальное воздействие на приложение и определить, можно ли их закрыть какими-то внешними элементами, например системой обнаружения вторжений. Тестировщик может даже определить, что уязвимости, по сути, нет, если она затрагивает компонент, который в системе не используется.
Инструменты управления.
Любая инфраструктура веб-сервера требует наличия инструментов для конфигурирования сервера, получения обновлений, изменения информации на сайте, управления базами данных и так далее. Средства управления могут отличаться в зависимости от сайта, используемых технологий или используемого программного обеспечения. Например, некоторые веб-серверы управляются с использованием административных интерфейсов, которые сами по себе являются веб-серверами (такими, как веб-сервер iPlanet) или управляются конфигурационными файлами (в случае с Apache) или с использованием инструментов операционной системы (Microsoft IIS). Инструменты управления могут быть встроены в само веб-приложение, что бы управлять контентом на сайте, его дизайном, его пользователями. Часто веб-сайты и серверы управляются с помощью онлайн-инструментов, которые предоставляет хостинг-провайдер.
Стоит отметить, что зачастую различное ПО поставляется сразу готовым для использования «из коробки». Настройки по умолчанию такого ПО могут не подходить для задач, выполняемых приложением. Так же такое ПО «из коробки» может содержать примеры приложений, документацию, тестовые страницы, которые доступны онлайн. Документация раскрывает информацию о компоненте ПО, а тестовые страницы и демо-приложения могут иметь известные уязвимости.
Демо-приложения и тестовые страницы.
Многие веб-серверы и серверы приложений сразу после установки предоставляют демо-приложения или тестовые страницы, которые призваны продемонстрировать правильность работы сервера. Однако демо-приложения могут иметь уязвимости.
Например, CVE-1999-0449 (
CVE-2002-1744 (
CVE-2002-1630 (
И свежий пример - CVE-2019-0186 (
Найти на сервере файлы по умолчанию и демо-приложения можно с помощью сканеров уязвимостей, таких как nikto (
Пример работы сканера:
Как видим, сканер нашел тестовые страницы сервера Oracle 9i и возможно они содержат уязвимости.
На основе изложенного приходим к ряду вопросов, на которые необходимо ответить на текущем этапе тестирования:
- какие из компонентов инфраструктуры могут иметь уязвимости?
- есть ли о уязвимостях данных компонетов информация в открытом доступе?
- можно ли проэксплуатировать эти уязвимости?
- как влияют эти уязвимости на веб-приложение?
- с помощью каких инструментов осуществляется управление компонентами инфраструктуры?
- можно ли получить доступ к этим инструментам онлайн?
- соответствует ли задачам, которые выполняет веб-приложение, конфигурация по умолчанию используемых компонентов?
Исследование расширений файлов.
Для того, что бы понять, какие технологии и языки используются на сервере для выполнения запросов и на основе этого выстроить сценарии атаки, следует определить, какие расширения файлов используются на веб-сервере.
В ходе этого этапа тестирования обратите внимание на то, файлы с какими расширениями имеются на сервере, как сервер обрабатывает запросы к этим файлам. Определите, какие файлы обрабатываются как текстовые, а какие выполняются на стороне сервера. Файлы, которые обрабатываются как текстовые, могут содержать конфиденциальные данные, а выполняемые файлы позволят определить, какие технологии, языки и плагины используются сервером, и дать дополнительную информацию о структуре всего веб-приложения.
Для тестирования можно воспользоваться утилитой dirb. С помощью нее в каждой директории сайта (их мы определили в предыдущих статьях) нужно выполнить поиск файлов по различным расширениям. Обычно это занимает много времени, но может дать очень хорошие результаты.
После того, как все директории будут просканированы, и в директориях будут найдены файлы с разными расширениями, определите, в каких каталогах возможно выполнение скриптов и на каких языках программирования. Так же найдите файлы, в которых раскрывается исходный код, конфигурационные файлы и другие, которые могут содержать важную для тестироващика информацию. Если приложение использует балансировщик нагрузки, то такую проверку нужно выполнить для всех серверов.
Например, выполним поиск файлов с расширением .inc в одной из директорий на тестируемом сайте:
Dirb нашел файл DBconnection.inc и в результате неверной конфигурации сервера мы имеем доступ к содержимому этого файла. Сам файл раскрывает информацию об используемой СУБД и путь до корня сервера:
Поиск на том же сайте по расширению .asp:
Найденый файл detail.asp не выполняется, но раскрывается его исходный код:
Следующие расширения никогда не должны возвращаться веб-сервером, поскольку они могут содержать в себе чувствительную информацию, как в примере выше:
Следующие расширения относятся к файлам, которые либо отображаются браузером, либо выполняются. Иногда они так же могут содержать конфиденциальную информацию и должны бать проверены:
Приведенные список далеко не полон, он слишком большой, что бы приводить его здесь полностью. Чтобы больше узнать о разных расширениях и решить, какие вы будете тестировать, обратитесь к
Отмечу, что часто содержимое файлов при загрузке на сервер проверяется по их расширениям. Это может приводить к непредсказуемым последствиям в случае, когда расширение не соответствует содержимому, или в случае непредвиденных результатов обработки имени файла операционной системой.
На следующем шаге мы выполним поиск бэкапов, забытых файлов, старых версий приложения, найдем все административные интерфейсы и попытаемся подобрать к ним логины и пароли.
Спасибо за внимание, всем пока! )
Тестирование безопасности платформы, на которой развернуто веб-приложение, так же важно, как и тестирование безопасности самого приложения. Вся инфраструктура сильна настолько, насколько сильно ее самое слабое звено. Некоторые ошибки конфигурации платформы могут скомпрометировать веб-приложение так же, как и уязвимое приложение может скомпромитировать сервер.
Например, уязвимость, позволяющая неаутентифицированному пользователю загружать на веб-сервер файлы, может привести к тому, что атакующий загрузит на сервер вредоносный код, который будет выполняться так же, как и код приложения, либо изменить некоторые части приложения, подменив его оригинальные файлы на свои собственные.
Как вы помните, в прошлых статьях мы провели разведку, выявили, из каких элементов состоит инфраструтура приложения и по итогу составили карту архитектуры приложения. Теперь необходимо провести анализ конфигурации и выявить типичные проблемы для тестируемой системы. Сервер аутентификации, сервер баз данных, ПО веб-сервера — любой из элементов системы по возможности должен быть проверен.
Как стать хакером и Как взломать сайт: беглое знакомство с OWASP Testing Guide.
Введение в пентест веб-приложений: Поиск утечек информации с помощью поисковых систем.
Пентест веб-приложений: Определение веб-сервера. Robots.txt. Определение приложений на веб-сервере.
Пентест веб-приложений: Исследование исходного кода веб-страниц. Определение точек входа. Карта приложения.
Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.
Введение в пентест веб-приложений: Поиск утечек информации с помощью поисковых систем.
Пентест веб-приложений: Определение веб-сервера. Robots.txt. Определение приложений на веб-сервере.
Пентест веб-приложений: Исследование исходного кода веб-страниц. Определение точек входа. Карта приложения.
Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.
Известные уязвимости.
При тестировании методом Black Box анализ уязвимостей сервера может быть затруднительным.
Во-первых, тестирование некоторых уязвимостей может привести к непредсказуемым результатам на сервере или даже сделать продолжение тестирования невозможным, к примеру, в случае успеха тестирования dos-атаки.
Во-вторых, некоторые автоматизированные инструменты для тестирования определяют уязвимости на основе полученой версии веб-сервера. Это может привести как к ложно-положительным, так и к ложно-отрицательным срабатываниям.
С одной стороны — если администратор скрыл версию веб-сервера, сканер уязвимостей не пометит сервер, как уязвимый, даже если он действительно уязвимый. С другой стороны, если поставщик программного обеспечения после патчей безопасности не изменяет информацию о версии, сканер будет находить несуществующие уязвимости. Последний случай весьма распространен, например, в большинстве дистрибутивов Linux, таких как Red Hat, Debian или SuSE.
В-третьих, обычно сканеры обнураживают уязвимости в элементах, которые выставлены наружу, то есть с которыми клиент взаимодействует напрямую, например в веб-сервере. И сканер, как правило, не может найти уязвимости в таких элементах, которые скрыты от прямого воздействия — сервер базы данных или система аутентификации.
В-четвертых, не все поставщики программного обеспечения раскрывают информацию о уязвимостях в своем ПО. Сканеры просто не могут знать об этих уязвимостях, даже если они есть. Как правило, сканеры полезны при тестировании распространенного ПО, такого как веб-сервер Apache, Microsoft IIS или Lotus Domino, и неэффективны при тестировании малоизвестных программных продуктов.
Резюмируя вышесказанное — анализ уязвимостей лучше всего проводить, получив информацию от заказчика о внутреннем устройстве инфраструктуры (методом White box или Grey box). С помощью этой информации тестировщик может получить информацию от самого поставщика ПО и проанализировать, какие уязвимости могут присутствовать в системе и как они могут повлиять на веб-приложение. Если это возможно, тестировщик должен попытаться проэксплуатировать уязвимости, понять их реальное воздействие на приложение и определить, можно ли их закрыть какими-то внешними элементами, например системой обнаружения вторжений. Тестировщик может даже определить, что уязвимости, по сути, нет, если она затрагивает компонент, который в системе не используется.
Инструменты управления.
Любая инфраструктура веб-сервера требует наличия инструментов для конфигурирования сервера, получения обновлений, изменения информации на сайте, управления базами данных и так далее. Средства управления могут отличаться в зависимости от сайта, используемых технологий или используемого программного обеспечения. Например, некоторые веб-серверы управляются с использованием административных интерфейсов, которые сами по себе являются веб-серверами (такими, как веб-сервер iPlanet) или управляются конфигурационными файлами (в случае с Apache) или с использованием инструментов операционной системы (Microsoft IIS). Инструменты управления могут быть встроены в само веб-приложение, что бы управлять контентом на сайте, его дизайном, его пользователями. Часто веб-сайты и серверы управляются с помощью онлайн-инструментов, которые предоставляет хостинг-провайдер.
Стоит отметить, что зачастую различное ПО поставляется сразу готовым для использования «из коробки». Настройки по умолчанию такого ПО могут не подходить для задач, выполняемых приложением. Так же такое ПО «из коробки» может содержать примеры приложений, документацию, тестовые страницы, которые доступны онлайн. Документация раскрывает информацию о компоненте ПО, а тестовые страницы и демо-приложения могут иметь известные уязвимости.
Демо-приложения и тестовые страницы.
Многие веб-серверы и серверы приложений сразу после установки предоставляют демо-приложения или тестовые страницы, которые призваны продемонстрировать правильность работы сервера. Однако демо-приложения могут иметь уязвимости.
Например, CVE-1999-0449 (
Ссылка скрыта от гостей
) — демо-приложение Exair в веб-сервере IIS 4 позволяло проводить DOS-атаку на сервер.CVE-2002-1744 (
Ссылка скрыта от гостей
) — файл CodeBrws.asp в IIS 5 был подвержен уязвимости Directory traversal, которая позволяла атакующему просматривать исходные коды и определять существование произвольных файлов с помощью строки "%c0%ae%c0%ae" (.. - dot dot).CVE-2002-1630 (
Ссылка скрыта от гостей
) — демо-страница sendmail.jsp в Oracle 9i Application Server (9iAS) позволяла удаленному пользователю отправлять с сервера произвольные электронные письма.И свежий пример - CVE-2019-0186 (
Ссылка скрыта от гостей
) - Apache Pluto 3.0.0 и 3.0.1 имеет демонстрационный портлет «Chat Room», который подвержен хранимым XSS.Найти на сервере файлы по умолчанию и демо-приложения можно с помощью сканеров уязвимостей, таких как nikto (
Ссылка скрыта от гостей
).Пример работы сканера:
Как видим, сканер нашел тестовые страницы сервера Oracle 9i и возможно они содержат уязвимости.
На основе изложенного приходим к ряду вопросов, на которые необходимо ответить на текущем этапе тестирования:
- какие из компонентов инфраструктуры могут иметь уязвимости?
- есть ли о уязвимостях данных компонетов информация в открытом доступе?
- можно ли проэксплуатировать эти уязвимости?
- как влияют эти уязвимости на веб-приложение?
- с помощью каких инструментов осуществляется управление компонентами инфраструктуры?
- можно ли получить доступ к этим инструментам онлайн?
- соответствует ли задачам, которые выполняет веб-приложение, конфигурация по умолчанию используемых компонентов?
Исследование расширений файлов.
Для того, что бы понять, какие технологии и языки используются на сервере для выполнения запросов и на основе этого выстроить сценарии атаки, следует определить, какие расширения файлов используются на веб-сервере.
В ходе этого этапа тестирования обратите внимание на то, файлы с какими расширениями имеются на сервере, как сервер обрабатывает запросы к этим файлам. Определите, какие файлы обрабатываются как текстовые, а какие выполняются на стороне сервера. Файлы, которые обрабатываются как текстовые, могут содержать конфиденциальные данные, а выполняемые файлы позволят определить, какие технологии, языки и плагины используются сервером, и дать дополнительную информацию о структуре всего веб-приложения.
Для тестирования можно воспользоваться утилитой dirb. С помощью нее в каждой директории сайта (их мы определили в предыдущих статьях) нужно выполнить поиск файлов по различным расширениям. Обычно это занимает много времени, но может дать очень хорошие результаты.
После того, как все директории будут просканированы, и в директориях будут найдены файлы с разными расширениями, определите, в каких каталогах возможно выполнение скриптов и на каких языках программирования. Так же найдите файлы, в которых раскрывается исходный код, конфигурационные файлы и другие, которые могут содержать важную для тестироващика информацию. Если приложение использует балансировщик нагрузки, то такую проверку нужно выполнить для всех серверов.
Например, выполним поиск файлов с расширением .inc в одной из директорий на тестируемом сайте:
Dirb нашел файл DBconnection.inc и в результате неверной конфигурации сервера мы имеем доступ к содержимому этого файла. Сам файл раскрывает информацию об используемой СУБД и путь до корня сервера:
Поиск на том же сайте по расширению .asp:
Найденый файл detail.asp не выполняется, но раскрывается его исходный код:
Следующие расширения никогда не должны возвращаться веб-сервером, поскольку они могут содержать в себе чувствительную информацию, как в примере выше:
Следующие расширения относятся к файлам, которые либо отображаются браузером, либо выполняются. Иногда они так же могут содержать конфиденциальную информацию и должны бать проверены:
Приведенные список далеко не полон, он слишком большой, что бы приводить его здесь полностью. Чтобы больше узнать о разных расширениях и решить, какие вы будете тестировать, обратитесь к
Ссылка скрыта от гостей
.Отмечу, что часто содержимое файлов при загрузке на сервер проверяется по их расширениям. Это может приводить к непредсказуемым последствиям в случае, когда расширение не соответствует содержимому, или в случае непредвиденных результатов обработки имени файла операционной системой.
На следующем шаге мы выполним поиск бэкапов, забытых файлов, старых версий приложения, найдем все административные интерфейсы и попытаемся подобрать к ним логины и пароли.
Спасибо за внимание, всем пока! )
Последнее редактирование:
