🔍 Нашли уязвимость — поищите ее в других сервисах
Есть одна вещь, над которой мало кто задумывается после обнаружения очередной уязвимости. Это поиск проблем такого же класса в других сервисах компании.
Ведь зачастую разработчики совершают одни и те же ошибки. Иногда они просто переиспользуют уязвимый код, иногда невнимательно читают документацию. Причины могут быть разные, а результат всегда один: много похожих уязвимостей в совершенно разных приложениях.
Есть несколько вариантов решения такой проблемы:
1️⃣ Организовать ручной поиск. Не требует никаких пререквизитов и прекрасно работает со специфичными для определенного функционала уязвимостями. Например, с Race Condition, Blind XSS или отсутствием рейт-лимитов.
2️⃣ Разобраться в коде и написать новое правило для SAST. Хорошо себя показывает, когда четко понятна ошибка на уровне кода. Таким образом обычно автоматизируют поиск небезопасных конструкций определенного языка или библиотеки: начиная от SQL-инъекций и заканчивая XXE. Здесь на помощь приходит Semgrep с его очень низким порогом входа для написания собственных правил.
3️⃣ Воспользоваться DAST и написать собственный сценарий или шаблон для тестирования. Идеально подходит, если есть простой пейлоад и понятна реакция уязвимого приложения. Например, так можно автоматизировать поиск различных мисконфигов (публично доступный Spring Boot Actuator или Swagger документация). Здесь поможет Nuclei с его шаблонами. Можно также попробовать OWASP ZAP с его скриптами.
Данный подход существенно улучшит ваши процессы и позволит не только находить больше уязвимостей, но и отлавливать их уже на стадии разработки во время написания кода или запуска тестов.
#processes #vulnerabilities #tools
Есть одна вещь, над которой мало кто задумывается после обнаружения очередной уязвимости. Это поиск проблем такого же класса в других сервисах компании.
Ведь зачастую разработчики совершают одни и те же ошибки. Иногда они просто переиспользуют уязвимый код, иногда невнимательно читают документацию. Причины могут быть разные, а результат всегда один: много похожих уязвимостей в совершенно разных приложениях.
Есть несколько вариантов решения такой проблемы:
1️⃣ Организовать ручной поиск. Не требует никаких пререквизитов и прекрасно работает со специфичными для определенного функционала уязвимостями. Например, с Race Condition, Blind XSS или отсутствием рейт-лимитов.
2️⃣ Разобраться в коде и написать новое правило для SAST. Хорошо себя показывает, когда четко понятна ошибка на уровне кода. Таким образом обычно автоматизируют поиск небезопасных конструкций определенного языка или библиотеки: начиная от SQL-инъекций и заканчивая XXE. Здесь на помощь приходит Semgrep с его очень низким порогом входа для написания собственных правил.
3️⃣ Воспользоваться DAST и написать собственный сценарий или шаблон для тестирования. Идеально подходит, если есть простой пейлоад и понятна реакция уязвимого приложения. Например, так можно автоматизировать поиск различных мисконфигов (публично доступный Spring Boot Actuator или Swagger документация). Здесь поможет Nuclei с его шаблонами. Можно также попробовать OWASP ZAP с его скриптами.
Данный подход существенно улучшит ваши процессы и позволит не только находить больше уязвимостей, но и отлавливать их уже на стадии разработки во время написания кода или запуска тестов.
#processes #vulnerabilities #tools
🛠 Инструменты для выявления вредоносных зависимостей
В последнее время наблюдается кратный рост атак на цепочки поставок. Особенно популярны вектора атак через зависимости: dependency confusion, typosquatting, внедрение вредоносных изменений в исходный код библиотек и т.д.
Для борьбы с такого рода угрозами есть несколько интересных инструментов. О них и поговорим:
1️⃣ Packj — инструмент от Ossillate для поиска потенциально опасных конструкций в пакетах NPM, PyPI и RubyGems. Анализирует метаинформацию с целью выявления рискованных атрибутов. Например, релиз новой версии после длительного перерыва или отсутствие публичного репозитория с исходным кодом. Использует Strace и MalOSS для детектирования подозрительного поведения: наличия техник обфускации кода, генерации нового кода во время выполнения и т.д. Также позволяет осуществлять безопасную установку зависимостей в специальном режиме, который блокирует нелегитимную активность.
2️⃣ OSSGadget — обширный набор из 12 инструментов от Microsoft, каждый из которых решает определенную задачу в рамках анализа open-source библиотек. Самый примечательный среди них — oss-detect-backdoor. Он ищет потенциально вредоносные куски кода внутри исследуемого пакета. Поиск осуществляется с помощью регулярных выражений, посвященных 10 различным предметным областям. Например: obfuscation, dependency confusion, code_execution, data_exfiltration и т.д.
3️⃣ Package Analysis — проект от OpenSSF, который позволяет анализировать поведение зависимостей из NPM, PyPI и RubyGems. Запускает установку и импорт исследуемого пакета в изолированном контейнере, где с помощью утилит Strace и Gopacket формируется лог действий: обращение к файлам, подключение к сетевым адресам, выполнение команд. Все это сохраняется в json формате, что позволяет самостоятельно анализировать результаты и выносить вердикт, является ли исследуемый пакет вредоносным или нет.
4️⃣ Package Hunter — инструмент от Gitlab для обнаружения аномального поведения зависимостей. Поддерживает NPM и RubyGems. Осуществляет установку исследуемого пакета в изолируемой среде и мониторит активность с помощью Falco. В отличие от Package Analysis выявляет конкретные аномалии. Например, доступ к файлам с секретами, установка неразрешенного сетевого соединения, запуск исполняемых файлов из черного списка и т.д. За отслеживание подозрительной активности отвечают специальные правила.
Все указанные инструменты достаточно новые, поэтому могут генерировать большое количество ложно-положительных срабатываний. Тем не менее, их можно настроить под себя, отредактировав конфиругационный файл или соответствующие правила.
#tools #dependencies #malware
В последнее время наблюдается кратный рост атак на цепочки поставок. Особенно популярны вектора атак через зависимости: dependency confusion, typosquatting, внедрение вредоносных изменений в исходный код библиотек и т.д.
Для борьбы с такого рода угрозами есть несколько интересных инструментов. О них и поговорим:
1️⃣ Packj — инструмент от Ossillate для поиска потенциально опасных конструкций в пакетах NPM, PyPI и RubyGems. Анализирует метаинформацию с целью выявления рискованных атрибутов. Например, релиз новой версии после длительного перерыва или отсутствие публичного репозитория с исходным кодом. Использует Strace и MalOSS для детектирования подозрительного поведения: наличия техник обфускации кода, генерации нового кода во время выполнения и т.д. Также позволяет осуществлять безопасную установку зависимостей в специальном режиме, который блокирует нелегитимную активность.
2️⃣ OSSGadget — обширный набор из 12 инструментов от Microsoft, каждый из которых решает определенную задачу в рамках анализа open-source библиотек. Самый примечательный среди них — oss-detect-backdoor. Он ищет потенциально вредоносные куски кода внутри исследуемого пакета. Поиск осуществляется с помощью регулярных выражений, посвященных 10 различным предметным областям. Например: obfuscation, dependency confusion, code_execution, data_exfiltration и т.д.
3️⃣ Package Analysis — проект от OpenSSF, который позволяет анализировать поведение зависимостей из NPM, PyPI и RubyGems. Запускает установку и импорт исследуемого пакета в изолированном контейнере, где с помощью утилит Strace и Gopacket формируется лог действий: обращение к файлам, подключение к сетевым адресам, выполнение команд. Все это сохраняется в json формате, что позволяет самостоятельно анализировать результаты и выносить вердикт, является ли исследуемый пакет вредоносным или нет.
4️⃣ Package Hunter — инструмент от Gitlab для обнаружения аномального поведения зависимостей. Поддерживает NPM и RubyGems. Осуществляет установку исследуемого пакета в изолируемой среде и мониторит активность с помощью Falco. В отличие от Package Analysis выявляет конкретные аномалии. Например, доступ к файлам с секретами, установка неразрешенного сетевого соединения, запуск исполняемых файлов из черного списка и т.д. За отслеживание подозрительной активности отвечают специальные правила.
Все указанные инструменты достаточно новые, поэтому могут генерировать большое количество ложно-положительных срабатываний. Тем не менее, их можно настроить под себя, отредактировав конфиругационный файл или соответствующие правила.
#tools #dependencies #malware
💫 Go Vulnerability Management и Govulncheck
Создатели языка Go рассказали о своем новом проекте Go Vulnerability Management и представили govulncheck — утилиту для проверки используемых зависимостей на предмет наличия известных уязвимостей.
В отличие от аналогов она не просто сканирует файл с перечнем всех импортируемых зависимостей, чтобы определить, содержат ли они уязвимости, но и делает дополнительный шаг, проверяя, вызывается уязвимый код или нет. Это позволяет убрать шум из многочисленных нерелеватных уязвимостей и сконцентрироваться на исправлении реальных проблем.
Чтобы реализовать такую киллер-фичу авторам пришлось создать свою собственную базу уязвимостей и организовать процессы таким образом, чтобы для каждой проблемы были отмечены все уязвимые функции.
Ранее такой подход я встречал только у Checkmarx и их инструмента CxSCA (подробнее можно прочитать вот тут). Но теперь эта тема становится все популярнее. Совсем недавно ребята из r2c анонсировали Semgrep Supply Chain с очень похожим функционалом.
Но это все — коммерческие инструменты, а вот govulncheck может использовать абсолютно любой Go разработчик. Это определенно прорыв для всей экосистемы данного языка. Надеюсь, что-то похожее мы скоро увидим и в других экосистемах.
#tools #dependencies #vulnerabilities
Создатели языка Go рассказали о своем новом проекте Go Vulnerability Management и представили govulncheck — утилиту для проверки используемых зависимостей на предмет наличия известных уязвимостей.
В отличие от аналогов она не просто сканирует файл с перечнем всех импортируемых зависимостей, чтобы определить, содержат ли они уязвимости, но и делает дополнительный шаг, проверяя, вызывается уязвимый код или нет. Это позволяет убрать шум из многочисленных нерелеватных уязвимостей и сконцентрироваться на исправлении реальных проблем.
Чтобы реализовать такую киллер-фичу авторам пришлось создать свою собственную базу уязвимостей и организовать процессы таким образом, чтобы для каждой проблемы были отмечены все уязвимые функции.
Ранее такой подход я встречал только у Checkmarx и их инструмента CxSCA (подробнее можно прочитать вот тут). Но теперь эта тема становится все популярнее. Совсем недавно ребята из r2c анонсировали Semgrep Supply Chain с очень похожим функционалом.
Но это все — коммерческие инструменты, а вот govulncheck может использовать абсолютно любой Go разработчик. Это определенно прорыв для всей экосистемы данного языка. Надеюсь, что-то похожее мы скоро увидим и в других экосистемах.
#tools #dependencies #vulnerabilities
🚨 Исправили критическую уязвимость — проверьте логи
Многие думают, что исправление уязвимости - это заключительный этап работы с ней, после которого можно выдохнуть. Но некоторые ошибки безопасности, в особенности высокой степени критичности, требуют дополнительных действий.
Один из важнейших этапов работы с критическими уязвимостями — это поиск следов эксплуатации. Ведь важно не только быстро устранить серьезную проблему, но и убедиться, что вам больше ничего не угрожает.
А для этого необходимо заранее позаботиться о централизованном сборе логов как отдельных приложений, так и инфраструктуры в целом. Причем одного лишь сбора будет недостаточно. Важно сформировать политику логгирования, где будут определены как минимум следующие составляющие:
📌 Типы сохраняемых событий (попытки аутентификации, доступ к чувствительным данным, …)
📌 Набор сохраняемых параметров (дата и время, источник, тип события, …)
📌 Срок хранения (для разного рода событий он может быть разным)
В противном случае может оказаться, что либо нужных логов не будет, либо они будут бесполезны.
#processes #vulnerabilities
Многие думают, что исправление уязвимости - это заключительный этап работы с ней, после которого можно выдохнуть. Но некоторые ошибки безопасности, в особенности высокой степени критичности, требуют дополнительных действий.
Один из важнейших этапов работы с критическими уязвимостями — это поиск следов эксплуатации. Ведь важно не только быстро устранить серьезную проблему, но и убедиться, что вам больше ничего не угрожает.
А для этого необходимо заранее позаботиться о централизованном сборе логов как отдельных приложений, так и инфраструктуры в целом. Причем одного лишь сбора будет недостаточно. Важно сформировать политику логгирования, где будут определены как минимум следующие составляющие:
📌 Типы сохраняемых событий (попытки аутентификации, доступ к чувствительным данным, …)
📌 Набор сохраняемых параметров (дата и время, источник, тип события, …)
📌 Срок хранения (для разного рода событий он может быть разным)
В противном случае может оказаться, что либо нужных логов не будет, либо они будут бесполезны.
#processes #vulnerabilities
🚀 Подборка докладов про запуск баг-баунти программы
В последнее время все больше компаний задумываются над собственной баг-баунти программой. Кто-то уже запустился, а кто-то только планирует.
И тем, и другим будет полезно посмотреть следующие два выступления от первопроходцев баг-баунти в России:
💬 Программа баг-баунти и как её запустить? — доклад QIWI, в котором затрагиваются следующие темы:
- Ценности и преимущества баг-баунти
- Опыт запуска и развития собственной программы
- Усвоенные ошибки
- Подробная статистика за 3.5 года
- Советы по подготовке и запуску
💬 Другая сторона баг-баунти программы — доклад VK, в котором даются ответы следующие на вопросы:
- Как устроен процесс разбора отчетов в VK?
- Что является конечным профитом с баг-баунти?
- Когда баг-баунти начинает приносить пользу?
- Какие процессы находятся под капотом баг-баунти?
Хоть эти доклады от 2018 и 2020 годов, но своей актуальности они не потеряли. Тем более, что с тех пор новых выступлений на эту тему не появилось.
P.S. Ссылки на презентации: QIWI и VK.
#presentations #bugbounty
В последнее время все больше компаний задумываются над собственной баг-баунти программой. Кто-то уже запустился, а кто-то только планирует.
И тем, и другим будет полезно посмотреть следующие два выступления от первопроходцев баг-баунти в России:
💬 Программа баг-баунти и как её запустить? — доклад QIWI, в котором затрагиваются следующие темы:
- Ценности и преимущества баг-баунти
- Опыт запуска и развития собственной программы
- Усвоенные ошибки
- Подробная статистика за 3.5 года
- Советы по подготовке и запуску
💬 Другая сторона баг-баунти программы — доклад VK, в котором даются ответы следующие на вопросы:
- Как устроен процесс разбора отчетов в VK?
- Что является конечным профитом с баг-баунти?
- Когда баг-баунти начинает приносить пользу?
- Какие процессы находятся под капотом баг-баунти?
Хоть эти доклады от 2018 и 2020 годов, но своей актуальности они не потеряли. Тем более, что с тех пор новых выступлений на эту тему не появилось.
P.S. Ссылки на презентации: QIWI и VK.
#presentations #bugbounty