«Спасаем разработчика» на Кавказе

Мы уже рассказывали про атаки на разработчика и изучали уязвимости платформ разработки. Теперь исследуем методы и инструменты защиты конвейера и придумываем автоматизации, которые можно отдать AI-AppSec-инженеру (это тот, который не просит еду, только GPU-ресурсы).

И повод тоже есть: на Кавказе как раз на мероприятии «Код ИБ» собираются директора ИБ, которые смогут приземлить эти идеи в своем бизнесе.

База симуляций атак и правил для их обнаружения

Кто запускал инструменты симуляции атак, тот знает, насколько они бывают полезными для оценки способностей Blue Team. Автор репозитория AttackRuleMap пробует закрыть пробел между сценариями атак инструмента Atomic Red Team и Sigma-правилами для их обнаружения.

Полезная база, которая пригодится аналитику SOC, чтобы не дожидаться, когда к нему прийдет пентестер или Red Team, а самостоятельно оценить свои возможности.

Вашей компании нужен герой — и он уже среди ваших разработчиков!
(#соавтор South HUB, Денис Макрушин.)

Если кто-то до сих пор слышит и соглашается с тезисом «безопасность замедляет разработку и душит инновации», то он плохо осознает с какой скоростью двигается прогресс. Раньше управленец C-level в технологической компании мог надеяться, что его бизнес или продукт не будут интересны кибер-преступникам, и они обойдут его стороной. Теперь же, когда злодеи повсеместно используют автоматизацию и регулярно мониторят возможности запрыгнуть в инфраструктуру компании любого масштаба — нельзя надеяться на «да кому я нужен».

Атаки, утечки и различные кибер-инциденты реально тормозят развитие. Иногда останавливают его полностью. Потому что когда «зашифрован прод», а данные клиентов текут в паблик — это не про развитие. А еще, оказывается, что недостаточно завернуть в свой пайплайн все необходимые security-инструменты. Недостаточно даже их правильно настроить и получать только важные результаты их работы.

Как обычно, секретный соус кибербезопасной компании — в ее людях и культуре. Уязвимость всегда проще и дешевле исправлять, когда она обнаружена в IDE разработчика, а не в проде у клиента. Практики и инструменты ИБ нужно двигать «влево» — ближе к началу жизненного цикла системы. Ближе к тому этапу, на которых рождается идея, гипотеза, бизнес-план, дизайн системы. А для этого, нужно понимать “кибербез” на уровне культуры топ-менеджмента и разработки.

В индустрии есть такое термин: Security-чемпион. Это не всегда выделенная роль. Это может быть сотрудник, который прокачивает себя в вопросах ИБ и приземляет экспертизу в своих повседневных задачах. Например, разработчик или тим лид, который понимает риски некачественного кода. CTO, который не ждет, когда появится CISO и принесет контроли в SDLC. CEO и CPO, которые знают, для чего проводить дополнительные security design review.

Чтобы запустить чемпионскую программу в своих командах разработки, нужно предварительно ответить на ключевые вопросы вопроса:
1. Как я создам внутреннюю мотивацию? Что будет драйвить разработчика развиваться в направлении безопасной разработки?
2. Какой ресурс я выделю для реализации программы? Смогу ли обеспечить реальное влияние security-чемпионов на SDLC-процессы?
3. Как буду постоянно развивать и поддерживать сообщество security-чемпионов?

И как только появятся конкретные ответы на эти вопросы, можно будет приступать к тактике. Кстати, отправной точкой для запуска программы может стать вот этот плейбук, подготовленный моим товарищем и поддержанный сообществом OWASP.

Культивируете ли чемпионов в своих командах?

Глюк-пакеты: как названия пакетов, придуманные ИИ, становятся угрозой

Помним про старые атаки typosquatting, которые актуальны до сих пор. Typosquatting в разработке - это загрузка в репозиторий вредоносного пакета с именем, похожим на название популярного и уже существующего пакета.

В свежей академической статье авторы проверяли гипотезу, что галюцинации пакетов являются распространенным явлением при генерации кода с использованием больших языковых моделей (LLM), и что это явление представляет собой новую угрозу для цепочки поставок в разработке ПО.

Для проверки этой гипотезы исследователи выполнили три задачи:
1. определили частоту, с которой LLM генерируют несуществующие или ошибочные названия пакетов при генерации кода на Python и JavaScript, и то, как настройки модели влияют на возникновение галлюцинаций;
2. определили повторяемость галлюцинаций;
3. выявили семантические особенности сгенерированных пакетов.

Методика исследования состояла из нескольких этапов. Сначала авторы сгенерировали датасет из входных запросов (промптов) для генерации кода. Затем передали этот набор запросов для каждой из 16 выбранных LLM. И уже на сгенерированном коде применили правила для поиска фрагментов кода, в которых производится подключение сторонних пакетов.

Каждый полученный пакет сравнивался с актуальным списком настоящих пакетов. Если этот пакет отсутствовал в списке, то помечался авторами как галлюцинация. Галлюцинаций накопилось аж 205474 штук. Большинство галлюцинированных названий пакетов не были семантически схожи с существующими популярными пакетами. Это значит, что название глюк-пакета было мало похоже на оригинальное название. То есть, эти названия не являются простыми опечатками.

После изучения исследования у меня остался один вопрос: как злоумышленник может эффективно использовать эту особенность ИИ в своих атаках? Очевидная схема: «нагенерировать» с помощью LLM подобные галлюцинации, и использовать полученный словарь для регистрации вредоносных пакетов. Но далеко не факт, что подобные галлюцинации LLM воспроизведет у разработчика. Поэтому злодею остается стрелять «из пушки по воробьям»: регистрировать как можно больше названий, напоминающих названия для легитимных зависимостей.

Продолжаю дежурить в сообществе South HUB, которое объявило месяц безопасности для топ-менеджеров в IT.

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

Веб-ханипот, чтобы изучить атакующего

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

Ханипот поднимает API-эндпоинты, которые имитируют разные уязвимости. В результате, если атакующий использует сканер, то получает ложные срабатывания и тратит свое время на их анализ. А владелец веб-приложения получает дополнительное время, чтобы принять меры.

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

Последняя миля для исследователя

Итог любого исследования - это отчет. Не найденная уязвимость, не новая техника атаки и даже не прототип. Заключительным этапом является опубликованный репорт, и об этом мы говорили в комментариях к посту, из которого родилась статья “Как провести свое первое security-исследование”.

Эта последняя миля иногда составляет более 50% от всего объема исследовательской работы. Нужно не только подготовить отчет, но и доставить его до целевой аудитории. В этот период доставки, ресерчер превращается в героя компьютерной игры Death Stranding и, как курьер, перемещается со своим докладом и материалами между различными регионами и конференциями.

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

Pentest Award - это отраслевая награда для специалистов по тестированию на проникновение, которую ежегодно вручают мои коллеги из компании Авилликс. Основная задача: выделить лучших специалистов и показать их вклад в развитие российского пентеста. Слежу за этим мероприятием уже третий год подряд и вижу, как площадка постепенно набирает свое сообщество и увеличивает количество номинаций в направлении наступательной безопасности. Если ты занимаешься анализом защищенности и нашел что-то нетривиальное, то точно стоит поделиться.

Отмечай это событие точкой на карте своего карьерного пути.

LLM может автономно проводить целевой фишинг

Открытие, которое сейчас мало кого удивит: полностью автоматизированные фишинг-атаки с помощью ИИ так же успешны, как и организованные людьми. За последний год способности LLM в проведении атак значительно улучшились, и это подтверждают новые тесты:

* на фишинговые письма, созданные ИИ, кликнули 54% пользователей из контрольной группы
* на письма, созданные экспертами-людьми, кликнули 54% - ровно столько же пользователей.

Только человек тратил 34 минуты на составление письма, а LLM делала это за 2 минуты и 41 секунду. Экономически эффективно. Даже посчитана точка безубыточности: ИИ-фишинг становится более прибыльным, чем «человеческий», при атаке на группы размером от 2859 до 54123 человек.

Модели стали хитрее, а у атакующего появляются маркетинговые параметры, с которыми можно работать в автоматическом режиме: воронка, A/B-тесты и product-market fit.

Break Glass на PHDays

Break Glass - это механизм, который включается в критических, нестандартных ситуациях. Когда пропал доступ к ключевым ресурсам. Когда требуется оперативное восстановление. Когда случилась авария.

Завтра где-то в Лужниках вместе с Евгением Фрикиным мы посмотрим на фундаментальные недостатки технологии аварийного доступа к инфраструктуре. Рассмотрим идею, как исключить из реализации этого доступа ключевые элементы: пароли и предустановленные учетные записи. Обсудим архитектуру, опубликуем вайтпейпер, поделимся прототипом.

Если завтра ты тоже будешь неподалеку, добавляй доклад в календарь и приходи пообщаться.

Один символ, который ломает код

Видишь что-то подозрительное в этом участке кода?

user = "admin"
if user == "аdmin": 
    grant_access()

Буква “a” - кириллическая, а не латинская.

Это пример homoglyph-атаки - визуального обмана, при котором используются визуально похожие символы (гомоглифы), но из разных кодировок. Часто используется в фишинге для регистрации доменов, реже - для компрометации исходного кода, чтобы ввести в заблуждение код-ревьюверов.

Недавно исследователь провел эксперимент для крупного проекта curl: отправил pull request, в котором помимо основного полезного кода были заменены ASCII-сиволы на их похожие Unicode-альтернативы. Никто из ревьюверов не заметил этих изменений.

С тех пор Github стал подсвечивать измененные символы, но если ревьювишь код, то на всякий случай попроси свою LLM посмотреть его на гомоглифы.

Атака на Dependabot: внедрение вредоносного кода через Github-бота

Есть такой Dependabot - популярный бот на Github, который регулярно проверяет проекты на наличие устаревших зависимостей. Если он находит обновления, то создает pull request (PR), в котором предлагает внести изменения в код для обновления.

Есть разработчики - они обычно настраивают рабочий процесс так, чтобы автоматически объединять все PR от Dependabot. Проверка происходит через переменную github.actor. Если ее значение = dependabot[bot], то происходит слияние кода.

И есть злоумышленники. Они знают, что github.actor не всегда указывает на того, кто изначально создал PR, и существует возможность для атаки confused deputy. Для этого злодей выполняет следующие действия:

* создает форк целевого репозитория, у которого разработчики выставили настройки автоматического приема PR от Dependabot;
* добавляет свой вредоносный код в основную ветку своего форка;
* активирует Dependabot в своем форке и добавляет какую-нибудь устаревшую зависимость, чтобы привлечь внимание бота. Dependabot создает свою ветку обновлений в форке, и поскольку она основана на основной ветке форка, то содержит вредоносный код злодея.
* создает PR в целевом репозитории жертвы, используя ветку бота
* и ничего не получается, ведь в созданном PR значение github.actor (инициатор) все еще принадлежит злодею, поэтому он возвращается к оригинальному PR от Dependabot и комментирует: @dependabot recreate
* Dependabot выполняет команду: пересоздает свою ветку и принудительно отправляет в нее изменения (force-push). Принудительная отправка изменений в ветку повторно запускает процесс слияния в целевом репозитории (репозитории-жертве).

И вот на этом этапе происходит магия: когда Dependabot сам пересоздает и принудительно отправляет изменения, он становится «исполнителем» этого последнего события. Значение github.actor меняется и условие для автослияния выполняется:

if: ${{ github.actor == ‘dependabot[bot]’ }} 

PR с вредоносным кодом оказывается в целевом репозитории.

Нетривиальная атака. Поэтому попадает в коллекцию атак на разработчиков, о которой на следующей неделе расскажу на мероприятии IT IS Conf в Екатеринбурге.

Чтобы не заплыть в аналитике, роадмапах, продуктовых стратегиях, security-исследованиях и докладах собираем палатку, посуду, фонарик, любимый транспорт и выезжаем в оффлайн.

Если где-то поймаю связь и буду мерзнуть ночью, то подготовлю подборку материалов, которые изучим на следующей неделе. Бодрых выходных.

«Секретные» материалы, которые изучим на следующей неделе

Было холодно, поэтому подготовил подборку:

* Применение малых языковых моделей (SLM) для поиска секретов.
Доклад, в котором исследователи достигли точности 86% в задаче обнаружения секретов с помощью Llama 3.2 1B. Интересно изучить методологию и посмотреть бенчмарки.

* А этот пост уже про то, какие секреты удалось найти на Github. Месяц сканирования публичных репозиториев, новые типы секретов (связанные с ИИ-провайдерами) - новые находки старыми способами.

* В контексте архитектуры MCP (Model Context Protocol) секреты имеют новое значение. Можно забирать кейс для личных исследований.

* Велопоходное фото.

#дайджест