Современный сайт — система со сложной архитектурой, содержащая в среднем 20 уязвимостей, которые могут быть использованы атакующими. 62% сайтов подвержены уязвимостям со средним или высоким уровнем риска.

На корпоративном сайте или на сайте госведомства необходимо обеспечить защиту от искажения, уничтожения общедоступной информации или блокирования доступа к ней. Чтобы предотвратить такие неправомерные действия, нужно регулярно анализировать защищённость сайтов и контролировать использование средств защиты. Ведь сейчас фактически любое веб-приложение — это открытое окно в системы: банковские, заказа услуг, бронирования, CRM и т. д.

Доля уязвимых сайтов в зависимости от максимальной степени риска уязвимостей по данным Positive Technologies

Контроль защищённости веб-сайтов государственных организаций и операторов ГИС обязателен согласно:

• Постановлению Правительства РФ от 24 ноября 2009 г. № 953 «Об обеспечении доступа к информации о деятельности Правительства Российской Федерации и федеральных органов исполнительной власти».
• Постановлению Правительства РФ от 10 июля 2013 г. № 583 «Об обеспечении доступа к общедоступной информации о деятельности государственных органов и органов местного самоуправления в информационно-телекоммуникационной сети „Интернет“ в форме открытых данных».
• Постановлению Правительства РФ от 8 октября 2014 г. № 1024 г. «О внесении изменений в перечень информации о деятельности федеральных органов исполнительной власти, руководство деятельностью которых осуществляет Правительство Российской Федерации, и подведомственных им федеральных органов исполнительной власти, размещаемой в сети Интернет».
• Приказу ФСБ и ФСТЭК от 31 августа 2010 г. № 416/489 «Об утверждении Требований о защите информации, содержащейся в информационных системах общего пользования».
• Приказу ФСТЭК от 11 февраля 2013 г. № 17 «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах».

Цели тестирования на проникновение

• Составить перечень уязвимостей, которые может использовать злоумышленник, и проверить возможность их реализации.
• Предложить пути устранения выявленных уязвимостей.

Методики тестирования на проникновение

• The Open Web Application Security Project («OWASP») Testing Guide v4;
• Open Source Security Testing Methodology Manual («OSSTMM») v3;
• Technical Guide to Information Security Testing and Assessment (SP 800-115);
• ISACA IS auditing procedure «Security assessment-penetration testing and vulnerability analysis»;
• Penetration Testing Execution Standard («PTES»);
• A Penetration Testing Model («BSI»);
• Payment Card Industry («PCI») Data Security Standard («DSS») Guidance: PCI Information Supplement: Penetration Testing Guidance v3.2 April 2016;
• Federal Risk and Authorization Management Program («FedRAMP»): FedRAMP Penetration Test Guidance 1.0.1.

Что будет сделано

Сбор информации и первичный анализ. Мы используем открытые источники информации, идентифицируем объекты инфраструктуры и окружения и строим дерево вероятных атак.

Тест конфигурации. Мы проверим на уязвимости сетевую инфраструктуру, физический и виртуальный хостинг, систему журналирования.

Тест системы аутентификации. Мы протестируем парольную политику, проверим, насколько правильно она применяется, где и в каком виде хранятся данные учётных записей. Попробуем подобрать логины и пароли.

Тест механизма авторизации. Мы определим роли пользователей, требования разграничения доступа, попробуем повысить привилегии.

Тест механизма управления сессиями. Мы проверим области действия cookies, токены сессий, наличие CSRF уязвимостей.

Проверка альтернативных способов разграничения доступа. Мы определим, используются ли в веб-приложении небезопасные механизмы контроля доступа.

Тест защищённости транспортного уровня. Мы проверим защищённость протоколов взаимодействия клиент-сервер и служб SSL/TLS.

Тест обработки передаваемых данных. Мы проведём фаззинг передаваемых клиентом параметров и проверим возвращаемые данные серверов, протестируем возможность SQL, SMTP, SOAP, LDAP, XPath, Frame инъекций.

Тест механизмов безопасности клиентской части. Мы проверим, как и на каких технологиях построена безопасность клиентской части и оценим уровень защищённости.

Тест логики приложения. Мы определим бизнес-логику работы приложения и возможные векторы атак на неё.

Полный перечень работ зависит от начальных данных и задания на пентест.

Этапы работ

Получаем разрешение на работы

В разрешении заказчик перечисляет все компоненты информационной системы, заявленные как объекты исследования, и указывает узлы или сервисы, которые исключаются из тестирования. Мы совместно с заказчиком пентеста согласовываем дату и время работ, назначаем ответственных лиц и определяем степень осведомлённости исполнителя — Black Box, White Box или Grey Box.

BlackBox. Классическое моделирование действий злоумышленника — у исполнителя нет никакой информации, кроме той, что он может собрать сам в открытых источниках при помощи общедоступных инструментов.

GreyBox. Исполнитель знает лишь о некоторых элементах web-инфраструктуры, всё остальное он должен узнать сам. Такой подход моделирует ситуацию, когда у злоумышленника есть инсайдер внутри СОБИ заказчика.

WhiteBox. Исполнитель может запросить и получить любую информацию о тестируемых системах заказчика. В этом режиме обнаруживается самое большое число уязвимостей.

Атакуем платформу

Мы проверяем:

• оборудование платформы web-сервиса,
• операционные системы,
• вспомогательное ПО,
• архитектуру web-сервиса,
• сетевые сервисы и службы.

Мы отправляем запросы на сетевой узел заказчика и анализируем ответы на них специализированным ПО. Эта активность может быть зафиксирована системами обнаружения и предотвращения вторжений (IPS/IDS). Чтобы исключить блокировку IP-адресов исполнителя, мы рекомендуем включить их в «белые списки» перед началом работ. Данный этап занимает от 2 до 10 дней в зависимости от количества объектов и архитектуры web-сервиса.

Собираем уязвимости

Мы формируем и отправляем заказчику на утверждение перечень потенциальных уязвимостей web-сервиса, доступных сетевых сервисов и служб.

Уязвимости, о которых известно, что их эксплуатация вызовет нарушение в работе сервиса, проверяются в рамках специально созданного тестового стенда или в согласованное время под контролем представителя заказчика. Этап занимает от 4 до 15 дней в зависимости от количества выявленных уязвимостей.

Проверяем перечень уязвимостей

На этом этапе мы подтверждаем наличие потенциальных уязвимостей из утвержденного списка. Данный тип работ может вызвать временное повышение нагрузки на исследуемые объекты. На это время мы рекомендуем обеспечить доступность представителя заказчика для оперативного взаимодействия, если возникнет непредвиденный сбой в работе исследуемых сервисов. Нарушения в работе служб случаются довольно редко, но всё-таки не лишним будет отслеживать состояние объектов во время исследований. Данный этап занимает от 5 до 25 дней.

Анализируем результаты

На этом этапе мы не воздействуем на объекты исследований, а анализируем полученные сведения. Этап занимает от 5 до 20 дней в зависимости от количества выявленных уязвимостей и методов их эксплуатации.

Результаты работ

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