В то время, как для многих известных уязвимостей легко найти уже написанные эксплойты, другие уязвимости требуют сосредоточенных усилий для разработки собственного эксплойта. Некоторые сканеры (retire.js), помогают в обнаружении, но определение уязвимости требует дополнительных усилий. Многие известные уязвимости незначительны, и основаны на используемых компонентах.
Является ли приложение уязвимым?
Вероятно, приложение можно считать уязвимым, если:
- Если вы не знаете версии всех используемых вами компонентов (как на стороне клиента, так и на стороне сервера). Это включает в себя компоненты, которые вы используете непосредственно, а также вложенные зависимости.
- Если программное обеспечение уязвимо, не поддерживается или устарело. Это включает в себя ОС, веб-сервер / сервер приложений, систему управления базами данных (СУБД), приложения, API и все компоненты, среды выполнения и библиотеки.
- Если вы не сканируете уязвимости регулярно.
- Если вы не исправляете или не обновляете основную платформу, платформы и зависимости своевременно и на основе рисков.
- Если разработчики программного обеспечения не проверяют совместимость обновленных, обновленных или исправленных библиотек.
- Если вы не защищаете конфигурации компонентов (см. А6).
Как предотвратить
Необходимо провести рефакторинг, который затронет следующие пункты:
- Удалите неиспользуемые зависимости, ненужные функции, компоненты, файлы и документацию.
- Постоянно проводите инвентаризацию версий как клиентских, так и серверных компонентов (например, каркасов, библиотек) и их зависимостей, используя соответствующие инструменты (DependencyCheck , retire.js)
- Получайте компоненты только из официальных источников по защищенным ссылкам. Предпочитайте подписанные пакеты, чтобы уменьшить вероятность включения измененного вредоносного компонента.
- Следите за библиотеками и компонентами, которые не поддерживаются или не создают исправлений безопасности для более старых версий.
- Каждая организация должна убедиться, что существует постоянный план мониторинга, сортировки и применения обновлений или изменений конфигурации в течение всего срока службы приложения или портфеля.
Пример сценария атаки
Сценарий № 1. Компоненты обычно работают с теми же привилегиями, что и само приложение, поэтому недостатки в любом компоненте могут привести к серьезным последствиям. Такие недостатки могут быть случайными (например, ошибка кодирования) или преднамеренными (например, бэкдор в компоненте). Вот некоторые обнаруженные уязвимости, которые можно использовать:
CVE-2017-5638 , уязвимость в удаленном выполнении кода в Struts 2, которая позволяет выполнять произвольный код на сервере. В то время как интернет вещей (IoT) часто трудно или невозможно исправить, важность их исправления может быть достаточно серьезной (например, биомедицинские устройства). Существуют автоматизированные инструменты, помогающие злоумышленникам находить непатентованные или неправильно настроенные системы. Например, поисковая система Shodan IoT может помочь вам найти устройства, которые по-прежнему страдают от уязвимости Heartbleed , исправленной в апреле 2014 года.
Полезные ссылки
- https://retirejs.github.io/retire.js/
- https://www.owasp.org/index.php/ASVSV1Architecture
- https://www.owasp.org/index.php/OWASPDependencyCheck
- https://www.owasp.org/index.php/MapApplicationArchitecture_(OTG-INFO-010)
- https://www.owasp.org/index.php/VirtualPatchingBest_Practices
