Что все-таки случилось с томкатом?

Тут недавно ИБ сообщество встало на уши из-за CVE-2025-24813 - уязвимости с RCE в Apache Tomcat, которая, по всей видимости, должна очень легко эксплуатироваться (ну конечно, сериализация, что же еще).

Честно сказать, я тоже сперва напряглась и даже напрягла друзей (отдельное спасибо Саше за помощь), но оказалось, что в общем паника не особо стоила выеденного яйца, несмотря на 9.8 CVSS.

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

https://digitaldefenders.substack.com/p/cve-2025-24813-one-guard-lies-one

Второй пост за день))

25 апреля пройдет конференция AppSecFest, https://appsecfest.kz/

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

А еще - ребята продлили CFP до 7 апреля, и если вам есть, чем поделиться с коммьюнити разработчиков и AppSec/DevSecOps инженеров, то это очень хорошая площадка для этого!

Тут недавно люди говорили, что любят читать код после работы 🙂

не совсем про уязвимости, но хочу поделиться игрой от PVS-Studio, где нужно найти баги в 10 фрагментах кода (java), на каждый баг и фрагмент кода дается минута. Разминает неплохо)

https://quiz.pvs-studio.com/en/java/tutorial/

А еще у них есть очень крутые разборы уязвимостей, периодически почитываю, бывает интересно (например, https://pvs-studio.com/en/blog/posts/java/1190/ прям хороша)

UPD для шарпа у них тоже есть https://pvs-studio.com/en/blog/quest/csharp/

Пятница - снова хорошее время, чтобы порешать таски.

На этот раз таск очень простой. Если Вы знакомы со Spring Boot 🙂 Ответом на задание будет строка, которая приведет к созданию на сервере, где запущен этот код, директории pwnd. А в понедельник я расскажу, как в 2016-2020 годах массово кошмарили приложения Spring Boot из-за аналогичной уязвимости, но и по сегодняшний день такая уязвимость - совершенно не редкость.

@RequestMapping("/spel")
public class SpelInjectionController {

    @GetMapping("/evaluate")
    public String evaluate(@RequestParam String id) {
        ExpressionParser parser = new SpelExpressionParser();
        StandardEvaluationContext context = new StandardEvaluationContext();
        context.setVariable("runtime", Runtime.getRuntime());

        Object result = parser.parseExpression(id).getValue(context);
        return "Result: " + result;
    }
}

А если эта задача кажется Вам слишком легкой, то попробуйте создать нагрузку в случае, если мы уберем строку context.setVariable("runtime", Runtime.getRuntime()) и пример сразу станет жизненнее;

Spring Expressions Language (SpEL) Injection

Обещанный комментарий к пятничному (одному из самых непопулярных 😒 ) посту.

Приведенный в нем фрагмент кода содержит уязвимость типа SpEL инъекция, которая, как и все инъекции, возникает из-за некорректной работы с пользовательским вводом. В частности, если мы позволяем параметрам, на которые может повлиять пользователь, проинтерпретироваться как SpEL выражение, то пользователь может пробросить нагрузку вида T(java.lang.Runtime).getRuntime().exec('mkdir pwnd') , которая как раз приведет к выполнению команды на бэке приложения.

И вроде бы всегда очевидно, что пользовательский ввод исполнять\интерпретировать нельзя. Однако очень рекомендуется проверить свой код по следующим ключевым словам:
SpelExpressionParser, EvaluationContext, parseExpression, @Value("#{ <expression string> }") или #{ <expression string> }, ${<property>}, T(<javaclass>).

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

Проблема в том, что такая уязвимость случается гораздо чаще, чем может показаться. Началось все еще в 2016, когда вышла cve-2016-4977 - уязвимость, затронувшая массово Spring приложения, и позволявшая исполнять произвольный пользовательский код через один из параметров вью Whitelabel Error Page. И до конца 2024 года число CVE, присвоенных уязвимостям типа SpEL, составляет около 20 штук(это только в продуктах семества Spring, а не в коде использующих его продуктов). Последняя была опубликована в 2024 году, но одна из более интересных, и более критичных, разумеется, это CVE-2022-22980 , оцененная в 9.8

In a wilderness

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

Расклад примерно такой, как на прикрепленной картинке. Вы находитесь в директории, в которой есть непустые сабдиректории и есть несколько файлов. Вопрос: какое действие или команду надо выполнить, чтобы выполненная после нее инструкция "rm *" удалила не только файлы, но и директории с вложенными в них файлами?

Примечательно, что та вещь, о которой идет речь в таске, сработает практически на всех *nix-based системах, но на некоторых запросит согласие пользователя, а на некоторых - нет.

Ответы "удалить заранее" или "переопределить rm" не подходят. Если будет нужна подсказка, дам ее сегодня вечером :)

Про инъекции

Всем привет! в прошлом посте вы видели небольшой таск про то, как работают вайлдкарды (например, *) и как коварен может быть баш, если их использовать неосмотрительно. Причем в таске мы рассмотрели историю про то, что файл с названием "-rf" при вызове команды "rm *" может привести к неожиданному поведению. Так, для интерпретатора команда в таком раскладе превратится в

rm file1 file2 dir1 dir2 -rf

, а если включить strace, то увидим картину ниже.

И дело даже не в вайлдкардах, а в самих командах, которые могут принимать инструкции через флаги, но при этом обрабатывать имена файлов именно так, как это делает rm на скриншоте - есть "-" в начале? считаем это флагом!

И таких команд довольно много (навскидку: rsync, который вообще может принят команды на выполнение, zip и tar c интересными флагами -Т, scp и его флаг -oProxyCommand... кто хакеры его знает, что еще.) А самое забавное, что такая эксплуатация будет попадать под понятие инъекции, особенно если у пользователя есть вохможность каким-то образом повлиять на имена файлов в директориях, где запускаются какие-то ваши скрипты.

Прежде, чем читать дальше, давайте попробуем ответить для себя на вопрос: а во что вообще можно делать инъекции или про какие типы инъекций вы слышали?

- SQL (а также ORM инъекции, потому что вообще-то ORM тоже надо уметь правильно готовить. Сюда же Hibernate инъекции, LinQ инъекции и многое другое)
- инъекции Javascript и прочие XSS (кстати, в html тоже можно инжектить. И в css. И даже использовать это в атаках)
- инъекции кода - чаще всего реализуются через какой-нибудь рендеринг шаблонов или через локальное подключение файлов (include и еще с десяток методов в php, да и java server pages тоже сюда попадают), или через некорректную десериализацию.
- инъекции OS, не очень удачное название, но речь идет как раз о тех случаях, когда вы можете заставить приложение выполнить или модифицировать какие-то команды баша, как в нашем примере. Или еще чего системное.
- инъекции промтов

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

А пока объявлю, что следующий таск в канале появится в пятницу. А также - что в пятницу проходит appsecfest.kz , где я буду выступать с докладом про то, как случается в жизни - хотели исправить уязвимость, а вышло, что сделали другую. Беда🤷‍♀️
И если вы будете на конфе, буду очень рада вас видеть)

Попалась хорошая статья про то, как вкатиться в код ревью по безопасности.

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

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

https://medium.com/@dub-flow/how-to-get-started-with-secure-code-review-89bcf2eb7ec4

я тут случайно выяснила, что у Semgrep есть своя академия: https://academy.semgrep.dev/

Формат видео мне обычно не заходит. Текст читать проще, да и примеров хочется именно кодом, а не на словах. Но этот курс ведет Tanya Janca (https://shehackspurple.ca/), а она весьма экспертна и харизматична. По итогу мне понравился мини-курс про безопасность API для разработчиков - может, и вам пригодится.

И два оффтоп вопроса к алматинцам:
1. Как к вам одеваться, если вылетать завтра? Вроде прогноз показывает, что тепло, но люди говорят обратное
2. Подъемник на Кок-Тобе работает, не знаете?)

Всем привет! пришла пятница и обещанный таск, который CTF-ерам покажется нереально тривиальным, а остальным может открыть что-то новое. Just have fun.
А я напоминаю, что сегодня мы можем встретиться на конфе appsecfest.kz , меня можно будет найти (теоретически) возле большого зеленого животного.

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

https://www.permit.io/blog/how-to-use-jwts-for-authorization-best-practices-and-common-mistakes

Немного про Keycloak'и

Keycloak - кажется, одно из самых популярных у нас в Казахстане опенсорсных IAM (Identity and Access Management) решений. По крайней мере, мне попадался часто и при пентестах, и в процессе разработки. Но как и любой другой инструмент, он требует осторожности при настройке, а так же имеет ряд своих архитектурных особенностей, которые требуют пристального внимания, чтобы случайно не сделать ваш инстанс и связанное с ним приложение уязвимыми к разного вида атакам. Это тот случай, когда просто поддерживать актуальную версию совсем недостаточно.

Поэтому хочу поделитсья парой ссылок про него.

1. Разумеется, официальная дока про то, как делать безопасно в приложениях и сервисах: https://www.keycloak.org/docs/25.0.6/securing_apps/index.html

2. Официальная дока про то, как конфигурировать: https://www.keycloak.org/docs/25.0.6/server_admin/index.html#mitigating_security_threats

3. И, собственно, про то, как вас будут ломать (а мы же все понимаем, что будут):
часть 1 - https://csacyber.com/blog/pentesting-keycloak-part-1-identifying-misconfiguration-using-risk-management-tools
часть 2 - https://csacyber.com/blog/pentesting-keycloak-part-2

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


4. Про то, что IAM по-своему сложно бороться с гонками: https://www.cyberark.com/resources/threat-research-blog/you-cant-always-win-racing-the-keycloak

https://www.codereviewlab.com/ - а это шикарно, товарищи. Таски небанальные, надо поискать, подумать. В день доступен один таск в бесплатной подписке, да и платная в целом меньше 5000 тенге в месяц. Если кто ищет платформу для своей команды - рекомендую

Критическая уязвимость в Node.js библиотеке (и новая таска!)

Пару дней назад вышла критическая (CVE-2025-47949, CVSS 9.9) уязвимость в библиотеке samlify (Node.js). Это библиотека, реализующая аутентификацию в рамках интеграции с SAML SSO системами. И уязвимость, разумеется, позволяет злоумышленнику аутентифицироваться под кем-то другим, если у него есть хотя бы один валидный ответ на SAML-запрос. Поэтому если вы используете эту версию библиотеки, рекомендую как можно скорее обновиться до версии 2.10.0. Понравился комментарий в коде исправления:

 // something has gone seriously wrong if we are still here

А пока предлагаю решить задачку на этом языке (ну и заодно ее полный аналог на PHP, если он вам ближе). Задачка с библиотекой не связана, вообще никак. И с уязвимостью в ней. Но это уже подсказка 🙂

Вопрос следующий - каким запросом я могу получить всех пользователей, что за уязвимость присутствует в коде и позволяет это сделать, и, главное, как это исправить?

На всякий случай:

Node.js код можно запустить с express (`node index.js`, поднимется на порту 8000)

PHP код - php -S localhost:8000 (ну или любой незанятый порт на ваш вкус)

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

просишь копилота подтюнить текст. Он тебе в ответ: а давай запилим инфографику! ну, давай...

пост не имеет смысловой нагрузки

Про атаки на разработчиков

Вчера с одной из команд говорили про социальную инженерию на разработчиков. Вспомнились кейсы, которые периодически активно обсуждаются в сети - когда на фейковом собеседовании человека просят скачать код с какого-то репозитория и на этом живом коде якобы провести сессию лайф-коддинга, чтобы убедиться в его навыках. Проблема начинается в тот момент, когда проект запускается в IDE и обфусцированный фрагмент одной из библиотек обращается к контрольному центру, чтобы скачать... RAT-файл, ратник, или remote access tool. Иными словами - программку, которая позволит выполнить на ПК жертвы определенные действия. В простом варианте атаки, на самом деле, не нужен даже ратник, потому что у нас и так выполняется код и какие-то доступы у него все равно будут.

И тут важный момент - а как защищаться? Можно поделить защиты на два аспекта.

1. Человек.
Это социальная инженерия, как ни крути. Поэтому то, насколько критично человек относится своим действиям, все еще остается важным. Зачастую разработчики и другие IT специалисты более расслабленно воспринимают стандартные правила кибергигиены, и злоумышленники этим пользуются.

2. Процессы и инструменты.
Докер-образы, плагины для IDE и браузеров, библиотеки в ZIP-архивах... как много всего может попасть к нам из непроверенных источников. Иногда по необходимости, иногда просто из любопытства. И все это нужно воспринимать как потенциально вредоносное, иными словами - ограничивать возможности, запускать все недоверенное в изолированных средах, перепроверять, что все это пришло из официальных источников.
И если говорить именно про эту атаку, то не стоит забывать, что IDE тоже пытается вас защитить (хоть полноценный сендбоксинг в ней и не возможен). Так, для плагинов механизм доверия в большинстве случаев реализован через подписывание, а для проектов есть Workspace Trust / Safe Mode, которые призваны ограничить возможности запускаемого кода, если он пришел из стороннего источника.