OWASP Top 10: A9 Использование компонентов с известными уязвимостями

Что такое компоненты с известными уязвимостями?

Top 10 OWASP описывает термин "компоненты" как очень широкий термин. Это может быть либо полноценная часть программного обеспечения, на которую наша цель полагается от третьей стороны, например, "Это я", которая является службой подтверждения личности, либо это может быть небольшая зависимость в скрипте, который спрятан где-то далеко. Если мы говорим об A9: использовании компонентов с известными уязвимостями, мы часто говорим либо об устаревших частях программного обеспечения, либо о программном обеспечении, которое больше не поддерживается активно. Обычно хорошо поддерживаемое программное обеспечение пытается исправить любые проблемы по мере их возникновения, но часто установка этих обновлений может быть обременительной, и пользователи этого компонента могут неохотно обновляться.

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

Как определить известные уязвимости?

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

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

Чтобы найти эти уязвимости A9: использование компонентов с известными уязвимостями уязвимости мы можем использовать автоматические сканеры, но мы должны быть очень осторожны, чтобы не переступить наши границы, когда мы это делаем. Я всегда предпочитаю просто выполнять пассивное сканирование без пауков или каких-либо запросов, о которых можно говорить. Это означает, что я анализирую только то, что нахожу, пока тестирую вручную. Автоматизированные сканеры необходимо обсудить с клиентом и согласовать, поскольку они могут нанести серьезный ущерб инфраструктуре клиента.

Я ищу любой номер версии программного обеспечения, который я могу найти. Версии Jquery, версии баз данных, баннеры операционной системы, все, что я могу найти. Я буду искать эти номера версий вручную, но во время взлома я также использую прокси MiTM, такой как burp, для автоматического сканирования исходного кода посещаемых мной веб-сайтов. Для поиска устаревшего программного обеспечения доступно несколько плагинов, из которых мой любимый - retireJS.

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

Разработчики должны быть полностью осведомлены обо всех зависимостях, которые они используют, и они должны думать о последствиях использования зависимостей. Кроме того, все зависимости должны быть введены в систему инвентаризации, которая может дать простой обзор всех используемых зависимостей. Все эти действия лучше всего выполнять автоматически, но разработчикам не следует упускать из виду, какие автоматические действия выполняются. Также необходимо будет внедрить сканер уязвимостей, чтобы убедиться, что версии зависимостей являются актуальными, поскольку они могут просматривать Интернет в поисках последних CVE и автоматически сканировать вашу инфраструктуру и зависимости на предмет A9: использование компонентов с известными уязвимостями.

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

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

Все это должно быть описано в плане, который является четким, кратким, одобренным и выполняемым всеми заинтересованными сторонами в организации.

• РУЧНЫЕ ОБНОВЛЕНИЯ

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

• ИСПОЛЬЗУЙТЕ HDIV

HDIV предоставляет нам полезный набор инструментов для веб-безопасности и безопасности API. Их инструменты интегрируются с жизненным циклом разработки программного обеспечения для раннего обнаружения уязвимых фрагментов кода или зависимостей, чтобы их можно было обновлять по мере необходимости. Преимущество этого заключается в защите всего жизненного цикла разработки и раннем выявлении уязвимостей. Управление всеми этими уязвимостями осуществляется с помощью полезной информационной панели, которая содержит результаты всех выполняемых проверок в централизованном хранилище, что упрощает управление.

Более подробную информацию можно найти на веб-сайте HDIV:

https://hdivsecurity.com/owasp-using-components-with-known-vulnerabilities‍

Примеры использования компонентов с известными уязвимостями в мире

Чтобы объяснить серьезность одной из этих уязвимостей, нам нужно взглянуть на это со всех сторон. В конце концов, вы хотите исправить вещи, обнаруженные вашим внутренним сканером. Наилучшей практикой было бы исправить все устаревшие зависимости, но логика подсказывает, что, когда приходит отчет об ошибке, который не оказывает доказуемого влияния на наши инфраструктуры, мы не решаемся выплачивать. В конце концов, какой вред в сохранении устаревшей зависимости, верно? Что ж, будьте уверены, что это определенно может нанести большой вред вашей компании и открывает им путь к A9: использование компонентов с известными уязвимостями! В конце концов, то, что не смог использовать один хакер, может быть использовано другим хакером.

Одним из примеров, который часто встречается в реальных целях, могут быть, например, устаревшие версии JS, уязвимые для XSS. Так стоит ли сообщать об этом? Ну, это зависит. В идеальном мире я бы хотел, чтобы эти отчеты всегда принимались независимо от последствий, потому что то, что может не повредить сейчас, может стать огромным бельмом на глазу позже, когда будет добавлена новая функциональность. При этом, если анализ рисков указывает на то, что проблема не представляет прямой опасности в будущем, можно понять, почему иногда эти сообщения отклоняются. Если никакого воздействия нет и никогда не будет, нет смысла тратить деньги на исправление того, что никому не вредит.

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

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

https://hackerone.com/reports/335339

Как классифицировать уязвимость

В этой теме я хотел рассказать о том, как классифицировать проблему, потому что сначала это может показаться очевидным, но, узнав об этом типе проблемы, вы можете увидеть, как все может усложниться. Например, что, если вы обнаружили XSS от 2015 года в своей цели, потому что они использовали зависимость? Или как насчет SQLi с 2019 года из-за их библиотеки очистки? Можно утверждать, что эти уязвимости принадлежат либо к одному из соответствующих классов (XSS, инъекции), либо к этому типу уязвимости (будучи компонентом с известными уязвимостями). Я думаю, что можно даже классифицировать эти проблемы по обоим типам уязвимостей, а не только по одному. Проблемы, обсуждаемые в 10 лучших уязвимостях OWASP, таких как XSS, XXE и инъекции, обычно в конечном итоге развиваются в компонент с известными уязвимостями, если создаваемый компонент используется повторно. Это может быть не так очевидно, как в приведенных выше примерах, его можно запутать, используя библиотеку jQuery с известной проблемой XSS, но затем не используя затронутую функциональность. Однако позже мы можем решить добавить функциональность, которая зависит от уязвимого кода, но мы можем забыть обновить наш компонент jQuery. Это также можно классифицировать как как XSS, так и как использование компонента с известными уязвимостями.