Makrushin
28.04.202508:11
Веб-ханипот, чтобы изучить атакующего
Интересная библиотека, которую разработчик веб-приложения может добавить в свой проект и наблюдать, кто и как пытается проэксплуатировать уязвимости.
Ханипот поднимает API-эндпоинты, которые имитируют разные уязвимости. В результате, если атакующий использует сканер, то получает ложные срабатывания и тратит свое время на их анализ. А владелец веб-приложения получает дополнительное время, чтобы принять меры.
Если пишешь свои веб-приложения на Go/Python/JS и хочешь знать, кто пробует твои проекты на прочность, то подключай эту библиотеку - уверен, что соберешь много инсайтов.
Интересная библиотека, которую разработчик веб-приложения может добавить в свой проект и наблюдать, кто и как пытается проэксплуатировать уязвимости.
Ханипот поднимает API-эндпоинты, которые имитируют разные уязвимости. В результате, если атакующий использует сканер, то получает ложные срабатывания и тратит свое время на их анализ. А владелец веб-приложения получает дополнительное время, чтобы принять меры.
Если пишешь свои веб-приложения на Go/Python/JS и хочешь знать, кто пробует твои проекты на прочность, то подключай эту библиотеку - уверен, что соберешь много инсайтов.
30.03.202508:11
Провинциальный OSINT: определяем место
Обычный пользователь видит просто фото. А что на нем видит OSINT-исследователь?
Фотка сделана на крыше здания, которое расположено где-то на окраине крупного города. Задача: определить страну.
⭐️Задача со звездочкой: определить город.
Обычный пользователь видит просто фото. А что на нем видит OSINT-исследователь?
Фотка сделана на крыше здания, которое расположено где-то на окраине крупного города. Задача: определить страну.
⭐️Задача со звездочкой: определить город.
23.04.202508:11
Глюк-пакеты: как названия пакетов, придуманные ИИ, становятся угрозой
Помним про старые атаки typosquatting, которые актуальны до сих пор. Typosquatting в разработке - это загрузка в репозиторий вредоносного пакета с именем, похожим на название популярного и уже существующего пакета.
В свежей академической статье авторы проверяли гипотезу, что галюцинации пакетов являются распространенным явлением при генерации кода с использованием больших языковых моделей (LLM), и что это явление представляет собой новую угрозу для цепочки поставок в разработке ПО.
Для проверки этой гипотезы исследователи выполнили три задачи:
1. определили частоту, с которой LLM генерируют несуществующие или ошибочные названия пакетов при генерации кода на Python и JavaScript, и то, как настройки модели влияют на возникновение галлюцинаций;
2. определили повторяемость галлюцинаций;
3. выявили семантические особенности сгенерированных пакетов.
Методика исследования состояла из нескольких этапов. Сначала авторы сгенерировали датасет из входных запросов (промптов) для генерации кода. Затем передали этот набор запросов для каждой из 16 выбранных LLM. И уже на сгенерированном коде применили правила для поиска фрагментов кода, в которых производится подключение сторонних пакетов.
Каждый полученный пакет сравнивался с актуальным списком настоящих пакетов. Если этот пакет отсутствовал в списке, то помечался авторами как галлюцинация. Галлюцинаций накопилось аж 205474 штук. Большинство галлюцинированных названий пакетов не были семантически схожи с существующими популярными пакетами. Это значит, что название глюк-пакета было мало похоже на оригинальное название. То есть, эти названия не являются простыми опечатками.
После изучения исследования у меня остался один вопрос: как злоумышленник может эффективно использовать эту особенность ИИ в своих атаках? Очевидная схема: «нагенерировать» с помощью LLM подобные галлюцинации, и использовать полученный словарь для регистрации вредоносных пакетов. Но далеко не факт, что подобные галлюцинации LLM воспроизведет у разработчика. Поэтому злодею остается стрелять «из пушки по воробьям»: регистрировать как можно больше названий, напоминающих названия для легитимных зависимостей.
Помним про старые атаки typosquatting, которые актуальны до сих пор. Typosquatting в разработке - это загрузка в репозиторий вредоносного пакета с именем, похожим на название популярного и уже существующего пакета.
В свежей академической статье авторы проверяли гипотезу, что галюцинации пакетов являются распространенным явлением при генерации кода с использованием больших языковых моделей (LLM), и что это явление представляет собой новую угрозу для цепочки поставок в разработке ПО.
Для проверки этой гипотезы исследователи выполнили три задачи:
1. определили частоту, с которой LLM генерируют несуществующие или ошибочные названия пакетов при генерации кода на Python и JavaScript, и то, как настройки модели влияют на возникновение галлюцинаций;
2. определили повторяемость галлюцинаций;
3. выявили семантические особенности сгенерированных пакетов.
Методика исследования состояла из нескольких этапов. Сначала авторы сгенерировали датасет из входных запросов (промптов) для генерации кода. Затем передали этот набор запросов для каждой из 16 выбранных LLM. И уже на сгенерированном коде применили правила для поиска фрагментов кода, в которых производится подключение сторонних пакетов.
Каждый полученный пакет сравнивался с актуальным списком настоящих пакетов. Если этот пакет отсутствовал в списке, то помечался авторами как галлюцинация. Галлюцинаций накопилось аж 205474 штук. Большинство галлюцинированных названий пакетов не были семантически схожи с существующими популярными пакетами. Это значит, что название глюк-пакета было мало похоже на оригинальное название. То есть, эти названия не являются простыми опечатками.
После изучения исследования у меня остался один вопрос: как злоумышленник может эффективно использовать эту особенность ИИ в своих атаках? Очевидная схема: «нагенерировать» с помощью LLM подобные галлюцинации, и использовать полученный словарь для регистрации вредоносных пакетов. Но далеко не факт, что подобные галлюцинации LLM воспроизведет у разработчика. Поэтому злодею остается стрелять «из пушки по воробьям»: регистрировать как можно больше названий, напоминающих названия для легитимных зависимостей.
20.03.202508:11
Безопасная разработка и какие вызовы несет AI
Дубай. Вечер. Глеб рассказывает кому-то из участников CTO Day, почему он не расстается со своей кепкой, на козырьке которой написано <head>. Можно догадаться, что это намек на фронтендерский бэкграунд Глеба, который уже давно с позиции технического директора смотрит на разработку, катит фичи в продукты, и рассказывает о нюансах управления R&D в своем подскасте.
И вот, спустя год, в гостях у Уставшего техдира мы говорим про безопасность в разработке, про роль AI в этом процессе, чтобы потом поделиться этим мыслями со всеми, кто неравнодушен к созданию продуктов, кибербезопасности и теме ИИ.
⭐ Выпуск доступен на YouTube, ВК, Rutube, Spotify, Apple Podcast, Яндекс.Музыка.
Дубай. Вечер. Глеб рассказывает кому-то из участников CTO Day, почему он не расстается со своей кепкой, на козырьке которой написано <head>. Можно догадаться, что это намек на фронтендерский бэкграунд Глеба, который уже давно с позиции технического директора смотрит на разработку, катит фичи в продукты, и рассказывает о нюансах управления R&D в своем подскасте.
И вот, спустя год, в гостях у Уставшего техдира мы говорим про безопасность в разработке, про роль AI в этом процессе, чтобы потом поделиться этим мыслями со всеми, кто неравнодушен к созданию продуктов, кибербезопасности и теме ИИ.
⭐ Выпуск доступен на YouTube, ВК, Rutube, Spotify, Apple Podcast, Яндекс.Музыка.
转发自:
South HUB
19.04.202512:37
Вашей компании нужен герой — и он уже среди ваших разработчиков!
(#соавтор South HUB, Денис Макрушин.)
Если кто-то до сих пор слышит и соглашается с тезисом «безопасность замедляет разработку и душит инновации», то он плохо осознает с какой скоростью двигается прогресс. Раньше управленец C-level в технологической компании мог надеяться, что его бизнес или продукт не будут интересны кибер-преступникам, и они обойдут его стороной. Теперь же, когда злодеи повсеместно используют автоматизацию и регулярно мониторят возможности запрыгнуть в инфраструктуру компании любого масштаба — нельзя надеяться на «да кому я нужен».
Атаки, утечки и различные кибер-инциденты реально тормозят развитие. Иногда останавливают его полностью. Потому что когда «зашифрован прод», а данные клиентов текут в паблик — это не про развитие. А еще, оказывается, что недостаточно завернуть в свой пайплайн все необходимые security-инструменты. Недостаточно даже их правильно настроить и получать только важные результаты их работы.
Как обычно, секретный соус кибербезопасной компании — в ее людях и культуре. Уязвимость всегда проще и дешевле исправлять, когда она обнаружена в IDE разработчика, а не в проде у клиента. Практики и инструменты ИБ нужно двигать «влево» — ближе к началу жизненного цикла системы. Ближе к тому этапу, на которых рождается идея, гипотеза, бизнес-план, дизайн системы. А для этого, нужно понимать “кибербез” на уровне культуры топ-менеджмента и разработки.
В индустрии есть такое термин: Security-чемпион. Это не всегда выделенная роль. Это может быть сотрудник, который прокачивает себя в вопросах ИБ и приземляет экспертизу в своих повседневных задачах. Например, разработчик или тим лид, который понимает риски некачественного кода. CTO, который не ждет, когда появится CISO и принесет контроли в SDLC. CEO и CPO, которые знают, для чего проводить дополнительные security design review.
Чтобы запустить чемпионскую программу в своих командах разработки, нужно предварительно ответить на ключевые вопросы вопроса:
1. Как я создам внутреннюю мотивацию? Что будет драйвить разработчика развиваться в направлении безопасной разработки?
2. Какой ресурс я выделю для реализации программы? Смогу ли обеспечить реальное влияние security-чемпионов на SDLC-процессы?
3. Как буду постоянно развивать и поддерживать сообщество security-чемпионов?
И как только появятся конкретные ответы на эти вопросы, можно будет приступать к тактике. Кстати, отправной точкой для запуска программы может стать вот этот плейбук, подготовленный моим товарищем и поддержанный сообществом OWASP.
Культивируете ли чемпионов в своих командах?
(#соавтор South HUB, Денис Макрушин.)
Если кто-то до сих пор слышит и соглашается с тезисом «безопасность замедляет разработку и душит инновации», то он плохо осознает с какой скоростью двигается прогресс. Раньше управленец C-level в технологической компании мог надеяться, что его бизнес или продукт не будут интересны кибер-преступникам, и они обойдут его стороной. Теперь же, когда злодеи повсеместно используют автоматизацию и регулярно мониторят возможности запрыгнуть в инфраструктуру компании любого масштаба — нельзя надеяться на «да кому я нужен».
Атаки, утечки и различные кибер-инциденты реально тормозят развитие. Иногда останавливают его полностью. Потому что когда «зашифрован прод», а данные клиентов текут в паблик — это не про развитие. А еще, оказывается, что недостаточно завернуть в свой пайплайн все необходимые security-инструменты. Недостаточно даже их правильно настроить и получать только важные результаты их работы.
Как обычно, секретный соус кибербезопасной компании — в ее людях и культуре. Уязвимость всегда проще и дешевле исправлять, когда она обнаружена в IDE разработчика, а не в проде у клиента. Практики и инструменты ИБ нужно двигать «влево» — ближе к началу жизненного цикла системы. Ближе к тому этапу, на которых рождается идея, гипотеза, бизнес-план, дизайн системы. А для этого, нужно понимать “кибербез” на уровне культуры топ-менеджмента и разработки.
В индустрии есть такое термин: Security-чемпион. Это не всегда выделенная роль. Это может быть сотрудник, который прокачивает себя в вопросах ИБ и приземляет экспертизу в своих повседневных задачах. Например, разработчик или тим лид, который понимает риски некачественного кода. CTO, который не ждет, когда появится CISO и принесет контроли в SDLC. CEO и CPO, которые знают, для чего проводить дополнительные security design review.
Чтобы запустить чемпионскую программу в своих командах разработки, нужно предварительно ответить на ключевые вопросы вопроса:
1. Как я создам внутреннюю мотивацию? Что будет драйвить разработчика развиваться в направлении безопасной разработки?
2. Какой ресурс я выделю для реализации программы? Смогу ли обеспечить реальное влияние security-чемпионов на SDLC-процессы?
3. Как буду постоянно развивать и поддерживать сообщество security-чемпионов?
И как только появятся конкретные ответы на эти вопросы, можно будет приступать к тактике. Кстати, отправной точкой для запуска программы может стать вот этот плейбук, подготовленный моим товарищем и поддержанный сообществом OWASP.
Культивируете ли чемпионов в своих командах?
19.03.202508:13
«Спасаем разработчика» на Кавказе
Мы уже рассказывали про атаки на разработчика и изучали уязвимости платформ разработки. Теперь исследуем методы и инструменты защиты конвейера и придумываем автоматизации, которые можно отдать AI-AppSec-инженеру (это тот, который не просит еду, только GPU-ресурсы).
И повод тоже есть: на Кавказе как раз на мероприятии «Код ИБ» собираются директора ИБ, которые смогут приземлить эти идеи в своем бизнесе.
Мы уже рассказывали про атаки на разработчика и изучали уязвимости платформ разработки. Теперь исследуем методы и инструменты защиты конвейера и придумываем автоматизации, которые можно отдать AI-AppSec-инженеру (это тот, который не просит еду, только GPU-ресурсы).
И повод тоже есть: на Кавказе как раз на мероприятии «Код ИБ» собираются директора ИБ, которые смогут приземлить эти идеи в своем бизнесе.
01.04.202508:11
Правила для выявления атак небезопасной распаковки архивов
Мы изучали уязвимость Zip Slip в Golang, когда атакующий может загрузить специально сформированный архив и выйти за пределы каталога, в который производится распаковка.
Проект Unsafe Unpacking Research собирает сценарии небезопасной распаковки в разных языках программирования и предлагает соответствующие semgrep-правила для их выявления в коде. Возможно, с помощью этих правил, AppSec-инженер, который уже устал находить в своих рабочих проектах тривиальные уязвимости, сможет разбавить рутину трудовых будней своих разработчиков. 👾
Мы изучали уязвимость Zip Slip в Golang, когда атакующий может загрузить специально сформированный архив и выйти за пределы каталога, в который производится распаковка.
Проект Unsafe Unpacking Research собирает сценарии небезопасной распаковки в разных языках программирования и предлагает соответствующие semgrep-правила для их выявления в коде. Возможно, с помощью этих правил, AppSec-инженер, который уже устал находить в своих рабочих проектах тривиальные уязвимости, сможет разбавить рутину трудовых будней своих разработчиков. 👾
显示 1 - 8 共 8
登录以解锁更多功能。