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, которые призваны ограничить возможности запускаемого кода, если он пришел из стороннего источника.

ну и старый добрый мемчик, чтобы веселее читалось

Что нового в OWASP ASVS 5.0

Если вы забыли, что это, то можно почитать вот тут

В мае вышел новый релиз OWASP ASVS (самый большой за последние пять лет). И, как мне кажется, новая версия стала гораздо удобнее для разработчиков.

Но самое первое, что бросается в глаза, это изменения в области уровней защищенности. Если коротко, ASVS предлагает пачки контролей, соответствующие уровням L1, L2, L3, где L1 - базовая безопасность, а L3 - продвинутый уровень, соответствующий высокой зрелости продукта. Каждый уровень описывается своим набором требований\контролей, которые применяются к коду и, если все требования выполнены, можно считать, что мы соответствуем какому-то уровню.

Так вот. В старой версии ASVS 4.0.3 для соответствия уровню L1 нужно было выполнить 131 условие. В новой - всего 70. И несмотря на кажущееся противоречие (вроде как время идет, средний уровень зрелости должен расти), этот шаг весьма оправдан и является следствием жарких дискуссий. И здесь важно понимать, что высокое количество правил уровня L1, по всей видимости, являлось одной из причин того, что компании, начиная работать с ASVS, либо не доводили до соответствия первому уровню, либо в принципе бросали всю эту затею (все чаще думаю о том, что с безопасностью надо как с аллергеном - сперва малыми дозами, чтобы не вызывало сразу прям отторжения)

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

А вот из реально прикольного - совсем новый раздел про пост-квантовую криптографию и сокращение длины минимально необходимого пароля (прикиньте! но там хитрая формулировка. Раньше было про "минимальную" длину пароля в 12 символов, сейчас стало "минимальная" - 8, а вот рекомендованная - 15. Но вообще, конечно, все уже присматриваются к историям без паролей).

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

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

@RestController
@RequestMapping("/users")
public class UserController {

    @Autowired
    private UserRepository userRepo;

    @PostMapping
    public User createUser(@RequestBody Map<String, Object> payload) {
        User user = new User();
        user.setUsername((String) payload.get("username"));
        user.setPassword((String) payload.get("password"));
        if (payload.containsKey("role")) {
            user.setRole((String) payload.get("role"));
        } else {
            user.setRole("USER");
        }
        return userRepo.save(user);
    }
}

встречается это дело и в других языках, но пример на Java

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

Офигенная диаграмма безопасности для k8s, на которую можно ориентироваться при работе со своими кластерами.

https://kubesec-diagram.github.io/