1. Для кого этот канал?
Этот канал ориентирован на разработчиков, в основном, начинающих. Или скучающих продолжающих. Однако какие-то вещи, о которых мы будем говорить здесь, могут быть полезны и для других инжинеров (DevOps, QA, архитекторов ...)

2. О чем этот канал?
Будем говорить о вопросах безопасности разработки, которые касаются каждого человека, непосредственно вовлеченного в жизненный цикл ПО. Постараюсь донести простыми словами те понятия, которые используются в среде Application Security, чтобы читатель мог обращать внимание на потенциальные опасные места в своем коде.

3. Какие будут рубрики?
#owasp - статьи про материалы или по материалам Open Web Application Security Project
#vulns - разбор конкретных типов уязвимостей
#задачки - задачки на поиск уязвимостей в коде. Задачки будут разного уровня, но надеюсь, будут интересными
#инструментарий - в этом разделе будем говорить о ПО, которое может помочь инжинеру. В том числе про такое, которое вам навязывает отдел ИБ, не всегда объясняя, зачем оно нужно.

Enjoy! и надеюсь, будет полезно)

И начнем мы с разговора о том, что такое OWASP.
По сути Open Web Application Security Project - это nonprofit организация, основной целью которой является повышение безопасности ПО. В глобальном смысле: они занимаются разработкой инструментов для безопасного SDLC, составлением чек-листов, статей и пособий, которые призваны сделать этот вопрос более открытым и доступным для всех участников процесса разработки. И им это удается весьма эффективно, многие из предложенных ими техник и инструментов стали де факто стандартом в безопасности, причем распространяются они на основе Open Source лицензий, т.е. использовать их может каждый. И контрибьютить тоже.

Одним из известных проектов является OWASP Top10 - топ наиболее распространенных уязвимостей веба, который выходит в среднем раз в 4 года. Выбор топа осуществляется на основе консенсуса между исследователями безопасности, причем входят в их число представители довольно известных организаций: GitLab, Bugcrowd, Oracle, Acunetix и многих других.

Чем этот проект полезен разработчику? Во-первых, считается, что именно с него начинают многие так называемые Security Champions (про них мы обязательно поговорим подобнее) - специалисты разработки, одной из задач которых является акцент на вопросы безопасности продукта. Во-вторых, несмотря на довольно редкое обновление списка, он все равно позволяет отслеживать тренды в этом вопросе. Так, например, еще четыре года назад в списке 17го года самой распространенной и опасной уязвимостью считались инъекции (SQL, RCE и другие). А уже на момент 2021 года первой группой уязвимостей в топе стала Broken Access Control - неверный контроль доступа. Чаще всего под этим термином подразумевают уязвимости типа IDOR - небезопасная прямая ссылка на объект, когда злоумышленник имеет возможность автоматизировать сбор данных, к которым, вообще говоря, по логике не должен иметь доступа. Скорее всего данная тенденция отображает тот факт, что за последние годы злоумышленников все меньше стали интересовать чужие сервера, да и сервера зачастую уже не так беззащитны, как раньше, но зато данные, особенно персональные, платежные и медицинские, довольно сильно выросли в цене.

В ИБ сообществе на самом деле ведется много споров насчет проекта OWASP Top10: кто-то считает, что обновление раз в четыре года является слишком медленным и можно упустить определенные локальные тренды, кто-то говорит о том, что безопасность API давно пора отделить от безопасности Web, а кто-то в целом считает этот список не самым объективным. Как бы то ни было, на сегодняшний день это один из самых стабильных проектов, который можно использовать в качестве ориентира.

Немного не про разработку, но...

На днях вышли PoC'и к двум крупным уязвимостям (CVE-2021-4034 и CVE-2022-0185) в ядре Linux. В обоих случаях уязвимость позволяет поднять привилегии в системе до рута, если у вас уже есть возможность исполнения кода в системе. Например, если через какую-то другую уязвимость удалось добиться RCE (remote code execution), но код, который злоумышленник может выполнять, выполняется от непривилегированного пользователя. В этом случае злоумышленник может воспользоваться одним из двух эксплойтов (опубликованных, кстати, здесь и здесь) и получить на системе рута.

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

Интересная история вышла с CVE-2021-4034: мало того, что про нее в интернетах говорили и писали уже давно, так еще и исправление этой уязвимости в коде библиотеки выглядит крайне мило.

Что делать? патчиться, разумеется. Если вкратце, то у каждой из уязвимостей есть быстрый патч на системе. Так, для устранения CVE-2021-4034 надо либо обновить ядро, либо применить chmod 0755 /usr/bin/pkexec.

А для CVE-2022-0185 рекомендуют (в первую очередь, разумеется, патчиться, но если это невозможно) запретить неймспейсы непривилегированных пользователей, то есть
sysctl -w kernel.unprivileged_userns_clone = 0

но надо помнить, что такая заплатка может сказаться на работе системы.

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

Вчера в списках CVE (Common Vulnerabilities and Exposures, глобальный список уязвимостей и других потенциальных дыр, которые официально признаны поставщиком ПО или сообществом) появилась очень интересная запись про CVE-2021-46101. Если Вы используете Windows и пользуетесь гит клиентом на нем, то настоятельно рекомендую обновиться до 2.34.2 или выше.
Уязвимость заключается в том, что при исполнении git pull для обновления локального хранилища напрямую запускается git.cmd и те команды, которые в этом файле прописаны, будут запущены на вашем ПК. То есть для атаки на вас злоумышленнику достаточно либо сделать опасный коммит в этот проект, либо убедить вас сделать пулл с его проекта, где этот git.cmd уже содержит ту нагрузку, которая его интересует.
Пример можно посмотреть вот здесь: https://github.com/0xADY/git_rce

Всем привет, *это опять то самое утро, когда приходится сообщать плохие новости*

Вчера зарепортили распространение малвари снова через опенсорсные библиотеки. Массовая атака, видимо, готовилась очень долго, и судя по тому, что в некоторые библиотеки был сделан коммит без вредоносной нагрузки - еще даже не достигла пика.

В основном малварь забирает ENV и отправляет на сервер владельца, было также выявлено несколько случаев выполнения произвольных команд. На данный момент достоверно известно, что отправка идет на домен ovz1.j19544519.pr46m.vps.myjino.ru , возможно, есть какие-то еще.

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

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

оффтоп, но пара мыслей о методологиях моделирования угроз.

STRIDE и DREAD были оба разработаны Майкрософтом. И как мне кажется, должны использоваться вместе. STRIDE позволяет увидеть картину, а что нам вообще угрожает, а когда есть картина, то раскрасить ее по критичности сверху можно DREAD'ом. И эта комбинация как раз и должна использоваться аппсеками. Почему? как раз потому, что аппсек имеет возможность работать с техдолгом, возможность, которой начисто лишен, например, классический ИБ. И последняя буква D в DREAD для классичкеского ИБ неприемлема, а для аппсеков внутри разработки это просто план на будущее устранение.

А вот PASTA подход пытается совмещать все вместе. И это уже штука, более подходящая классическому ИБ, когда живут в режиме "выжить между очередными страшными уязвимостями".

SSID Confusion Attack
Сегодняшние новости имеют взрывной эффект: исследователи обнаружили (еще в 2023 году, но опубликовали только сейчас) уязвимость не просто ПО, а целого протокола. Причем протокола, на котором работает огромное количество устройств - IEEE 802.11 Wi-Fi standard. Уровень критичности по CVSS v3 - 9.8! и затрагивает уязвимость все операционные системы, работающие с этим протоколом. А это в принципе почти все.

Описание: Суть атаки заключается в том, что сессию клиента специально даунгрейдят на менее защищенный уровень за счет подмены подключенной точки доступа. Это дает злоумышленнику возможность прослушки клиентского трафика. Важная особенность этой атаки - она задевает также некоторые конфигурации VPN, делая эту сеть не такой уж приватной.

Патчи: пока нет.

PoC: детальное описание доступно здесь

Git under attack!!
Появилась информация об уязвимости CVE-2024-32002 - удаленное исполнение кода в git. CVSS еще не присвоен.

Описание: включенные симлинки в настройках гита позволяют удаленному проекту при клонировании запускать код в вашей операционной системе.

Уязвимые версии: все, что до 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, 2.39.4

Патч: обновление или выключение символических ссылок git config --global core.symlinks false

PoC: (будьте осторожны! ) https://github.com/szybnev/git_rce/blob/main/create_poc.sh или

git clone --recursive git@github.com:szybnev/git_rce.git

- вот так это работает. Но не делайте так)

Подробности: https://teletype.in/@szybnev/RCE_git_clone

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 году эта отметка была достигнута к концу октября.