Arbitrary JavaScript execution in PDF.js
Вчера появилась статья с разбором CVE-2024-4367 - исполнение произвольного js кода в библиотеке PDF.js.

Описание: для эксплуатации атакующему нужно "скормить" уязвимому сайту вредоносный, специальным образом сформированный, PDF файл. Библиотека pdf.js используется для открытия pdf файлов в браузере Firefox и как известно на сегодняшний день, все версии браузера являются уязвимыми.

Патч: апдейт версии библиотеки PDF.js до 4.2.67 или выше, а также установка апдейтов на обертки, например, react-pdf
Или установка флага isEvalSupported в конфиге библиотеки в значение false

PoC: здесь (не открывайте браузером Firefox, зачем рисковать)

Разбор уязвимости: здесь

#js

Мой хороший товарищ (надеюсь, могу его так называть) Евгений, основатель sys-adm.in и автор проекта OpenBLD дал интервью, в котором порассуждал о кибергигиене и поведении в современной цифровой реальности.
https://www.youtube.com/watch?v=MxWD1N0Bmv8

SQL с потенциальным RCE в Zabbix

На днях вышла информация о CVE-2024-22120 в Zabbix - уязвимость позволяет пользователю с низкими правами выполнять системный код на сервере с Zabbix.

Описание: уязвимость возникает как следствие другой уязвимости - SQL инъекции. Сервер Zabbix может исполнять команды из сконфигурированных скриптов. После выполнения команды создается запись в Audit Log. Недостаточная санитизация одного из полей при этом приводит к слепой, time-based SQL инъекции. Разработчики признали, что инъекция в этой случае гарантировано приводит к повышению привилегий (до админа) и может в определенных конфигурациях приводить к RCE.

CVSS: не присвоено, но сам Zabbix оценил уровень критичности в 9.1 из 10 (вероятно из-за того, что уязвимость в авторизованной зоне, иначе было бы выше)

Патч: в версиях 6.0.28rc1, 6.4.13rc1, 7.0.0beta2

PoC: есть как у самого ⁠Zabbix (невероятно крутой уровень признания проблем), так и у ⁠⁠исследователей

#zabbix

Интересная история с уязвимостью в ArgoCD, о которой стало известно пару дней назад.

Разработчики, по моему опыту, очень не любят, когда статанализаторы ругаются на небезопасную криптографию. Криптография - вообще штука сложная и не всегда прозрачная для того, кто использует алгоритмы. Видимо, и здесь произошло что-то такое: отсутствие дефолтного пароля у Redis + не слишком криптографичная криптография + высокие права у ArgoCD = потенциальная возможность захвата кластера или тотальное раскрытие информации о нем.

Очень подробный разбор от cycode: https://cycode.com/blog/revealing-argo-cd-critical-vulnerability/

позиция argo: https://github.com/argoproj/argo-cd/security/advisories/GHSA-9766-5277-j5hr

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

Если коротко: эппловские Installer.app/PackageKit.framework выполняют скрипты из устанавливаемых .pkg файлов в окружении текущего пользователя от рута (уже интересно звучит, согласитесь). А скрипты эти чаще всего начинаются с shebang (подробнее тут), которые, в свою очередь, имеют хитрое свойство - строка #!/bin/zsh приводит к обращению к файлу .zshenv, будучи запущенной в этом случае от рута.

Таким образом становится возможна атака логической бомбой - во время установки зараженного pkg в файл .zshenv закидывается нагрузка, а уже при установке следующего pkg, скрипты которого содержат shebang, произойдет исполнение нагруженного кода, причем от рута. PoC и технические детали доступны в этой статье. Обновление до 14.5 Beta 2, 13.6.7 или 12.7.5 защитит Вас от этой уязвимости. Если, конечно, до обновления Вы не устанавливали ничего из pkg с нагрузкой.

А если интересно почитать про то, как неожиданно можно проэксплуатировать свойства вайлдкарда в линуксе - ставьте лайки, расскажу подробнее, если наберем больше 5.

Hacktuator

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

Spring Boot Actuator – это библиотека, которая позволяет мониторить приложение. С её помощью можно посмотреть множество параметров: характеристики системы, на которой работает приложение, какие в приложении создаются бины, различные метрики и т.п. Однако, если это можете увидеть Вы и не совсем корректно настроили, то могут увидеть и другие. Публиковать актуатор в интернет давно считается дурным тоном, однако если зайти на какой-нибудь censys.io, то можно найти кучу сервисов, которые об этом забыли.

Но одно дело не публиковать в Интернет, а второе - забыть про внутреннего злоумышленника и оставить эндпоинты доступными в локальной сети. Признавайтесь, у кого это так?)

В случае, если Ваша компания использует K8s, в целом, стандартные рекомендации по его настройке спасут. Если в файле application.yml прописать следующее:

management:
  metrics:
    export:
      prometheus:
        enabled: true
  endpoint:
    metrics:
      enabled: true
    prometheus:
      enabled: true
    health:
      probes:
        enabled: true
  endpoints:
    web:
      exposure:
        include: 'health,info,prometheus,metrics'
  server:
    port: 8090

В случае верной конфигурации после запуска приложения будет доступна, например, следующая точка входа:

:8090/actuator/health - которая предоставляет информацию о состоянии приложения.
Аналогично, info, prometheus, metrics.

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

Некорректный менеджмент доступов в продуктах JetBrains, CVE-2024-37051

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

Описание: из-за отсутствия правильного разграничения прав междут third-party плагинами возможна утечка токенов GitHub. Плагины нападают на плагины, прям как в недавней истории с VSCode.

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

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

Уязвимые версии: все, что до IntelliJ IDEA 2023.1.7, 2023.2.7, 2023.3.7, 2024.1.3, 2024.2 EAP3; Aqua 2024.1.2; CLion 2023.1.7, 2023.2.4, 2023.3.5, 2024.1.3, 2024.2 EAP2; DataGrip 2023.1.3, 2023.2.4, 2023.3.5, 2024.1.4; DataSpell 2023.1.6, 2023.2.7, 2023.3.6, 2024.1.2, 2024.2 EAP1; GoLand 2023.1.6, 2023.2.7, 2023.3.7, 2024.1.3, 2024.2 EAP3; MPS 2023.2.1, 2023.3.1, 2024.1 EAP2; PhpStorm 2023.1.6, 2023.2.6, 2023.3.7, 2024.1.3, 2024.2 EAP3; PyCharm 2023.1.6, 2023.2.7, 2023.3.6, 2024.1.3, 2024.2 EAP2; Rider 2023.1.7, 2023.2.5, 2023.3.6, 2024.1.3; RubyMine 2023.1.7, 2023.2.7, 2023.3.7, 2024.1.3, 2024.2 EAP4; RustRover 2024.1.1; WebStorm 2023.1.6, 2023.2.7, 2023.3.7, 2024.1.4

Патч: рекомендуется поставить обновления до самой свежей доступной версии по продукту.

regreSSHion: удаленное неаутентифицированное исполнение кода на серверах с OpenSSH

Описание: Сегодня максимально горячий день, потому что уязвимости такого класса выходят редко, прошлый раз был три года назад (Log4j, если кто-то не знал или забыл).

Сегодня днем группа исследователей угроз из Qualys опубликовала статью про уязвимость, получившую название regreSSHion. Статья описывает уязвимость в sshd, OpenSSH сервере, используемом линуксовым семейством операционных систем. Злоумышленник получает неаутетифицированное RCE на сервере с правами sshd. А теперь разберем эту фразу - злоумышленнику не нужно знать креды никакого пользователя, достаточно просто иметь возможность повзаимодействовать с sshd по открытом порту на сервере (многократно, т.к. уязвимость использует ситуацию гонок), и получить возможность исполнять абсолютно любой свой код на сервере с правами sshd. А это права уровня root.

Особенный интерес эта бага вызывает еще и тем, что она уже была, и называется regreSSHion неспроста. В 2006 году ей был присвоен номер CVE-2006-5051 и в том же году на нее был выпущен патч. Но в 2023 году один из коммитов случайно удалил директиву "#ifdef DO_LOG_SAFE_IN_SIGHAND" с функции, которая вызывалась хэндлером для SIGALRM. По сути, уязвимость является прямым следствием гонок - для эксплуатации нужно попасть в момент, когда, получив соответствующий сигнал, sshd останется в "подвешенном" состоянии. И доказательства того, что это возможно, не заставили себя ждать - от публикации новости до момента написания этой заметки прошло 5 часов, и за это время в поисковой выдаче гугла появилось около 3 PoC'ов.

Очень подробная статья с кусками кода на С есть здесь.

Уязвимые версии: < 4.4p1, а также 8.5p1 <= и < 9.8p1. OpenBSD не уязвимы к этому багу.
Патч: обновление до 9.8p1 или, если обновление невозможно, установка в конфиге LoginGraceTime на значение 0 (чревато другими проблемами безопасности, но менее критичными)

PoC публиковаться в данной заметке не будет.

На этом фоне, конечно, несколько теряется следующая новость, но все равно опубликую, потому что Supply Chain атаки, по всей видимости, с нами теперь надолго.

На прошлой неделе вышла статья о том, что после выкупа китайской компанией домена cdn.polyfill.io и получения доступа к репозиторию (судя по всему, переданного на платных основах одним из сотрудников Fastly) этой библиотеки, библиотека начала распространять специфический вредоносный код, таргетом которого являются веб-браузеры мобильных телефонов.
При открытии с телефона сайта, который использует в своей работе polyfill.js запускается своеобразный обфусцированный код, который через фейковый домен с закосом под Google Analytics редиректит пользователя на сайты со спортивными ставками. Автор библиотеки порекомендовал прекратить ее использование.

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