Сканирование на уязвимости и безопасная разработка. Часть 1

В рамках профессиональной деятельности разработчикам, пентестерам, безопасникам приходится сталкиваться с такими процессами, как Vulnerability Management (VM), (Secure) SDLC.
Под этими словосочетаниями скрываются различные наборы практик и используемых инструментов, которые переплетены между собой, хотя их потребители различаются.

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

Процессы

Процесс Vulnerability Management («управление уязвимостями») предназначен для непрерывного мониторинга защищённости инфраструктуры и патч-менеджмента.
Процесс Secure SDLC («цикл безопасной разработки») предназначен для поддержки защищённости приложения в ходе разработки и эксплуатации.

Схожей частью этих процессов является процесс Vulnerability Assessment — оценки на уязвимости, сканирования на уязвимости.
Основное различие в сканировании в рамках VM и SDLC в том, что в первом случае целью является обнаружить известные уязвимости в стороннем ПО или в конфигурации. Например, устаревшую версию Windows или community-строку по умолчанию для SNMP.
Во втором же случае целью является обнаружить уязвимости не только в сторонних компонентах (зависимостях), но в первую очередь в коде нового продукта.

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

Инфраструктурный же сканер зачастую можно заменить таймером, как выразился avleonov. Смысл в том, что чисто статистически вы можете считать вашу инфраструктуру уязвимой, если вы её не обновляли, скажем, месяц.

Инструменты

Сканирование, как и анализ защищённости, можно выполнять как чёрным ящиком, так и белым ящиком.

Black Box

При blackbox-сканировании инструмент должен уметь работать с сервисом через те же интерфейсы, через которые с ним работают пользователи.

Сканеры инфраструктуры (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose и т.д.) ищут открытые сетевые порты, собирают «баннеры», определяют версии установленного ПО и ищут в своей базе знаний информацию об уязвимостях в этих версиях. Также пытаются обнаружить ошибки конфигурации, такие как пароли по умолчанию или открытый доступ к данным, слабые шифры SSL и т.д.

Сканеры веб-приложений (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, и т.д.) тоже умеют определять известные компоненты и их версии (например, CMS, фреймворки, JS-библиотеки). Основные шаги сканера — это краулинг и фаззинг.
В ходе краулинга сканер собирает информацию о существующих интерфейсах приложения, HTTP-параметрах. В ходе фаззинга во все обнаруженные параметры подставляются мутированные или сгенерированные данные с целью спровоцировать ошибку и обнаружить уязвимость.

Такие сканеры приложений относятся к классам DAST и IAST — соответственно Dynamic и Interactive Application Security Testing.

White Box

При whitebox-сканировании различий больше.
В рамках процесса VM сканерам (Vulners, Incsecurity Couch, Vuls, Tenable Nessus и т.д.) зачастую дают доступ к системам, проводя аутентифицированный скан. Таким образом, сканер может выгрузить установленные версии пакетов и конфигурационные параметры прямо из системы, не угадывая их по баннерам сетевых сервисов.
Скан получается точнее и полнее.

Если же говорить о whitebox-сканировании (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs и т.д.) приложений, то речь обычно идёт о статическом анализе кода и использовании соответствуюбщих инструментов класса SAST — Static Application Security Testing.

Проблемы

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

Выделю 3 основные группы проблем, которые подтверждаются и беседами с инженерами и руководителями служб ИБ в самых разных компаниях.

Проблемы сканирования веб-приложений

1. Сложность внедрения. Сканеры нужно разворачивать, конфигурировать, кастомизировать под каждое приложение, выделять тестовую среду под сканы и внедрять в процесс CI/CD, чтобы это было эффективно. Иначе это будет бесполезная формальная процедура, выдающая разве что ложные срабатывания
2. Длительность сканирования. Сканеры даже в 2019 плохо справляются с дедупликацией интерфейсов и могут сутками сканировать тысячу страниц с 10 параметрами на каждой, считая их разными, хотя отвечает за них один и тот же код. При этом решение о деплое на прод в рамках цикла разработки необходимо принимать быстро
3. Скудные рекомендации. Сканеры выдают достаточно общие рекомендации, и не всегда разработчик может по ним быстро понять, как ему снизить уровень риска, а главное, нужно ли это делать прямо сейчас, или пока не страшно
4. Деструктивное воздействие на приложение. Сканеры вполне могут осуществить DoS-атаку на приложение, а также могут насоздавать большое количество сущностей или изменить существующие (например, создать десятки тысяч комментариев в блоге), так что не стоит бездумно запускать скан в проде
5. Низкое качество обнаружения уязвимостей. Сканеры обычно используют фиксированный массив полезных нагрузок («payloads») и могут легко пропустить уязвимость, которая не укладывается в известный им сценарий поведения приложения
6. Непонимание сканером функций приложения. Сканеры сами по себе не знают, что такое «интернет-банк», «платёж», «комментарий». Для них существуют только ссылки и параметры, так что огромный пласт возможных уязвимостей бизнес-логики остаётся совершенно непокрытым, они не догадаются сделать двойное списание, подглядеть чужие данные по ID или накрутить баланс через округление
7. Непонимание сканером семантики страниц. Сканеры не умеют читать FAQ, не умеют распознавать каптчи, сами по себе они не догадаются, как нужно зарегистрироваться, и что затем нужно перелогиниваться, что нельзя нажимать «logout», и как нужно подписывать запросы при изменении значений параметров. В результате большая часть приложения может остаться вообще не просканированной

Проблемы сканирования исходного кода

1. Ложные срабатывания. Статический анализ — сложная задача, при решении которой приходится прибегать к множеству компромиссов. Часто приходится жертвовать точностью, и даже дорогие enterprise-сканеры выдают огромное количество ложных срабатываний
2. Сложность внедрения. Для увеличения точности и полноты статического анализа необходимо дорабатывать правила сканирования, и написание этих правил может оказаться слишком трудоёмким. Иногда проще найти все места в коде с каким-то багом и исправить их, чем писать правило для детекта таких случаев
3. Отсутствие поддержки зависимостей. Большие проекты зависят от большого количества библиотек и фреймворков, которые расширяют возможности языка программирования. Если в базе знаний сканера нет информации об опасных местах («sinks») в этих фреймворках, это станет слепым пятном, и сканер просто даже не поймёт код
4. Длительность сканирования. Поиск уязвимостей в коде — это сложная задача и в терминах алгоритмов. Поэтому процесс вполне может затянуться и требовать при этом существенных вычислительных ресурсов
5. Низкое покрытие. Несмотря на потребление ресурсов и длительность сканирования, разработчикам SAST-средств всё равно приходится прибегать к компромиссам и анализировать не все состояния, в которых может находиться программа
6. Воспроизводимость находок. Указание на конкретную строку и стек вызовов, которые приводят к уязвимости — это прекрасно, но на самом деле часто сканер не даёт достаточно информации, чтобы проверить наличие уязвимости извне. Ведь недостаток может быть и в мёртвом коде, который недостижим для атакующего

Проблемы сканирования инфраструктуры

1. Недостаточная инвентаризация. В больших инфраструктурах, особенно разделённых географически, часто труднее всего понять, какие хосты нужно сканировать. Иными словами, задача сканирования плотно связана с задачей asset management
2. Плохая приоритизация. Сетевые сканеры часто выдают много результатов с недостатками, которые на практике не эксплуатируемы, но формально уровень их риска высок. Потребитель получает отчёт, который сложно интерпретировать, и непонятно, что нужно исправлять в первую очередь
3. Скудные рекомендации. В базе знаний сканера зачастую лишь очень общая информация об уязвимости и способах её исправления, так что админам придётся вооружиться гуглом. Ситуация чуть лучше с whitebox-сканерами, которые могут выдавать конкретную команду для исправления
4. Ручная работа. В инфраструктурах может быть много узлов, а значит, потенциально много недостатков, отчёты по которым приходится разбирать и анализировать вручную при каждой итерации
5. Плохое покрытие. Качество сканирования инфраструктуры напрямую зависит от объёма базы знаний об уязвимостях и версиях ПО. При этом, оказывается, даже у лидеров рынка база знаний не всеобъемлющая, и в базах бесплатных решений есть много информации, которой нет у лидеров
6. Проблемы с патчингом. Чаще всего патчинг уязвимостей в инфраструктуре — это обновление пакета или изменение конфигурационного файла. Большая проблема здесь в том, что система, особенно legacy, может непредсказуемо повести себя в результате обновления. По сути придётся проводить интеграционные тесты на живой инфраструктуре в проде

Подходы

Как же быть?
Подробнее о примерах и о том, как бороться со многими из перечисленных проблем, я расскажу в следующих частях, а пока укажу основные направления, в которых можно работать:

1. Агрегация различных инструментов сканирования. При правильном использовании нескольких сканеров можно добиться значительного увеличения базы знаний и качества детекта. Можно найти даже больше уязвимостей, чем суммарно все сканеры, запущенные по отдельности, при этом можно точнее оценивать уровень риска и давать больше рекомендаций
2. Интеграция SAST и DAST. Можно увеличить покрытие DAST и точность SAST за счёт обмена информацией между ними. Из исходников можно получить информацию о существующих роутах, а при помощи DAST можно проверить, видно ли уязвимость извне
3. Machine Learning™. В 2015 году я рассказывал (и ещё) про применение статистики для того, чтобы дать сканерам интуицию хакера, и ускорить их. Это определённо является пищей для развития автоматического анализа защищённости в будущем
4. Интеграция IAST с автотестами и OpenAPI. В рамках CI/CD-pipeline возможно создание процесса сканирования на основе инструментов, работающих в качестве HTTP-прокси, и функциональных тестов, работающих по HTTP. Тесты и контракты OpenAPI/Swagger дадут сканеру недостающую информацию о потоках данных, дадут возможность просканировать приложение в различных состояниях
5. Правильное конфигурирование. Под каждое приложение и инфраструктуру нужно создавать подходящий профиль сканирования, учитывающий количество и характер интерфейсов, используемые технологии
6. Кастомизация сканеров. Зачастую приложение нельзя просканировать без доработки сканера. Пример — платёжный шлюз, в котором каждый запрос должен быть подписан. Без написания коннектора к протоколу шлюза сканеры будут бездумно долбиться запросами с неправильной подписью. Также необходимо писать специализированные сканеры под конкретный вид недостатков, таких как Insecure Direct Object Reference
7. Риск-менеджмент. Использование различных сканеров и интеграция с внешними системами, такими как Asset Management и Threat Management, позволит использовать для оценки уровня риска множество параметров, так что руководство сможет получить адекватную картину о текущем состоянии безопасности разработки или инфраструктуры

Stay tuned and let’s disrupt the vulnerability scanning!

Источник: habr.com