И начнем мы с разговора о том, что такое 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, а кто-то в целом считает этот список не самым объективным. Как бы то ни было, на сегодняшний день это один из самых стабильных проектов, который можно использовать в качестве ориентира.
По сути 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 надо либо обновить ядро, либо применить
А для CVE-2022-0185 рекомендуют (в первую очередь, разумеется, патчиться, но если это невозможно) запретить неймспейсы непривилегированных пользователей, то есть
но надо помнить, что такая заплатка может сказаться на работе системы.
Ну и самое вкусное, к чему ведет весь этот разговор, -- обе уязвимости представляют собой большую опасность, если они есть у вас в контейнерах, т.к. могут позволить осуществить так называемый побег из контейнера. И патчить нужно все и желательно как можно быстрее.
На днях вышли 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но надо помнить, что такая заплатка может сказаться на работе системы.
Ну и самое вкусное, к чему ведет весь этот разговор, -- обе уязвимости представляют собой большую опасность, если они есть у вас в контейнерах, т.к. могут позволить осуществить так называемый побег из контейнера. И патчить нужно все и желательно как можно быстрее.
Sysdig
CVE-2022-0185: Detecting and mitigating Linux Kernel vulnerability causing container escape | Sysdig
Linux maintainers and vendors disclosed a heap overflow vulnerability in the Linux Kernel causing DoS, escape container or elevate privileges
Вчера в списках CVE (Common Vulnerabilities and Exposures, глобальный список уязвимостей и других потенциальных дыр, которые официально признаны поставщиком ПО или сообществом) появилась очень интересная запись про CVE-2021-46101. Если Вы используете Windows и пользуетесь гит клиентом на нем, то настоятельно рекомендую обновиться до 2.34.2 или выше.
Уязвимость заключается в том, что при исполнении git pull для обновления локального хранилища напрямую запускается git.cmd и те команды, которые в этом файле прописаны, будут запущены на вашем ПК. То есть для атаки на вас злоумышленнику достаточно либо сделать опасный коммит в этот проект, либо убедить вас сделать пулл с его проекта, где этот git.cmd уже содержит ту нагрузку, которая его интересует.
Пример можно посмотреть вот здесь: https://github.com/0xADY/git_rce
Уязвимость заключается в том, что при исполнении git pull для обновления локального хранилища напрямую запускается git.cmd и те команды, которые в этом файле прописаны, будут запущены на вашем ПК. То есть для атаки на вас злоумышленнику достаточно либо сделать опасный коммит в этот проект, либо убедить вас сделать пулл с его проекта, где этот git.cmd уже содержит ту нагрузку, которая его интересует.
Пример можно посмотреть вот здесь: https://github.com/0xADY/git_rce
🔥1
Всем привет, *это опять то самое утро, когда приходится сообщать плохие новости*
Вчера зарепортили распространение малвари снова через опенсорсные библиотеки. Массовая атака, видимо, готовилась очень долго, и судя по тому, что в некоторые библиотеки был сделан коммит без вредоносной нагрузки - еще даже не достигла пика.
В основном малварь забирает ENV и отправляет на сервер владельца, было также выявлено несколько случаев выполнения произвольных команд. На данный момент достоверно известно, что отправка идет на домен ovz1.j19544519.pr46m.vps.myjino.ru , возможно, есть какие-то еще.
Что мы можем сделать сейчас - во-первых, домен будет заблокирован в рамках корп.сети. Во-вторых, есть смысл посмотреть грепом по телам библиотек (я понимаю, что это странно, но не вижу другого варианта). Например, те же node_modules. Это рекомендуется сделать самим разработчикам - у вас на машинах идет сборка и все это может быть там.
Поражено якобы 35 тысяч библиотек, но эту информацию сейчас перепроверяют. Гитхаб за ночь вычистил большинство, но вы могли "подцепить" ее раньше, т.к. зараженным библиотекам уже по несколько дней.
Вчера зарепортили распространение малвари снова через опенсорсные библиотеки. Массовая атака, видимо, готовилась очень долго, и судя по тому, что в некоторые библиотеки был сделан коммит без вредоносной нагрузки - еще даже не достигла пика.
В основном малварь забирает ENV и отправляет на сервер владельца, было также выявлено несколько случаев выполнения произвольных команд. На данный момент достоверно известно, что отправка идет на домен ovz1.j19544519.pr46m.vps.myjino.ru , возможно, есть какие-то еще.
Что мы можем сделать сейчас - во-первых, домен будет заблокирован в рамках корп.сети. Во-вторых, есть смысл посмотреть грепом по телам библиотек (я понимаю, что это странно, но не вижу другого варианта). Например, те же node_modules. Это рекомендуется сделать самим разработчикам - у вас на машинах идет сборка и все это может быть там.
Поражено якобы 35 тысяч библиотек, но эту информацию сейчас перепроверяют. Гитхаб за ночь вычистил большинство, но вы могли "подцепить" ее раньше, т.к. зараженным библиотекам уже по несколько дней.
оффтоп, но пара мыслей о методологиях моделирования угроз.
STRIDE и DREAD были оба разработаны Майкрософтом. И как мне кажется, должны использоваться вместе. STRIDE позволяет увидеть картину, а что нам вообще угрожает, а когда есть картина, то раскрасить ее по критичности сверху можно DREAD'ом. И эта комбинация как раз и должна использоваться аппсеками. Почему? как раз потому, что аппсек имеет возможность работать с техдолгом, возможность, которой начисто лишен, например, классический ИБ. И последняя буква D в DREAD для классичкеского ИБ неприемлема, а для аппсеков внутри разработки это просто план на будущее устранение.
А вот PASTA подход пытается совмещать все вместе. И это уже штука, более подходящая классическому ИБ, когда живут в режиме "выжить между очередными страшными уязвимостями".
STRIDE и DREAD были оба разработаны Майкрософтом. И как мне кажется, должны использоваться вместе. STRIDE позволяет увидеть картину, а что нам вообще угрожает, а когда есть картина, то раскрасить ее по критичности сверху можно DREAD'ом. И эта комбинация как раз и должна использоваться аппсеками. Почему? как раз потому, что аппсек имеет возможность работать с техдолгом, возможность, которой начисто лишен, например, классический ИБ. И последняя буква D в DREAD для классичкеского ИБ неприемлема, а для аппсеков внутри разработки это просто план на будущее устранение.
А вот PASTA подход пытается совмещать все вместе. И это уже штука, более подходящая классическому ИБ, когда живут в режиме "выжить между очередными страшными уязвимостями".
SSID Confusion Attack
Сегодняшние новости имеют взрывной эффект: исследователи обнаружили (еще в 2023 году, но опубликовали только сейчас) уязвимость не просто ПО, а целого протокола. Причем протокола, на котором работает огромное количество устройств - IEEE 802.11 Wi-Fi standard. Уровень критичности по CVSS v3 - 9.8! и затрагивает уязвимость все операционные системы, работающие с этим протоколом. А это в принципе почти все.
Описание: Суть атаки заключается в том, что сессию клиента специально даунгрейдят на менее защищенный уровень за счет подмены подключенной точки доступа. Это дает злоумышленнику возможность прослушки клиентского трафика. Важная особенность этой атаки - она задевает также некоторые конфигурации VPN, делая эту сеть не такой уж приватной.
Патчи: пока нет.
PoC: детальное описание доступно здесь
Сегодняшние новости имеют взрывной эффект: исследователи обнаружили (еще в 2023 году, но опубликовали только сейчас) уязвимость не просто ПО, а целого протокола. Причем протокола, на котором работает огромное количество устройств - IEEE 802.11 Wi-Fi standard. Уровень критичности по CVSS v3 - 9.8! и затрагивает уязвимость все операционные системы, работающие с этим протоколом. А это в принципе почти все.
Описание: Суть атаки заключается в том, что сессию клиента специально даунгрейдят на менее защищенный уровень за счет подмены подключенной точки доступа. Это дает злоумышленнику возможность прослушки клиентского трафика. Важная особенность этой атаки - она задевает также некоторые конфигурации VPN, делая эту сеть не такой уж приватной.
Патчи: пока нет.
PoC: детальное описание доступно здесь
Top10Vpn
SSID Confusion Attack WiFi Vulnerability (CVE-2023-52424)
This vulnerability exploits a design flaw in the WiFi standard, allowing attackers to trick WiFi clients on any operating system into connecting to a untrusted network.
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
Патч: обновление или выключение символических ссылок
PoC: (будьте осторожны! ) https://github.com/szybnev/git_rce/blob/main/create_poc.sh или
Подробности: https://teletype.in/@szybnev/RCE_git_clone
Появилась информация об уязвимости 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 falsePoC: (будьте осторожны! ) 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
GitHub
git_rce/create_poc.sh at main · szybnev/git_rce
Exploit PoC for CVE-2024-32002. Contribute to szybnev/git_rce development by creating an account on GitHub.
🔥1
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
Вчера появилась статья с разбором 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
https://www.youtube.com/watch?v=MxWD1N0Bmv8
YouTube
Как защитить себя в интернете: кибербезопасность и искусственный интеллект (қазақша субтитрлер)
Почти 15 тысяч кибератак было зарегистрировано в казнете за первые три месяца 2024-го. За аналогичный период прошлого года их было всего 4,3 тысячи. То есть, за год количество кибератак выросло втрое. Такой статистикой недавно поделился ресурс factcheck.kz…
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
На днях вышла информация о 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
GitHub
GitHub - W01fh4cker/CVE-2024-22120-RCE: Time Based SQL Injection in Zabbix Server Audit Log --> RCE
Time Based SQL Injection in Zabbix Server Audit Log --> RCE - W01fh4cker/CVE-2024-22120-RCE
🔥1
Интересная история с уязвимостью в 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
Разработчики, по моему опыту, очень не любят, когда статанализаторы ругаются на небезопасную криптографию. Криптография - вообще штука сложная и не всегда прозрачная для того, кто использует алгоритмы. Видимо, и здесь произошло что-то такое: отсутствие дефолтного пароля у 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
Cycode
Redis or Not - Revealing a Critical Vulnerability in Argo CD Kubernetes Controller - Cycode
Cycode Researchers have uncovered a new vulnerability, CVE-2024-31989, with a critical score of 9.1. The vulnerability affects Kubernetes clusters equipped with Argo CD
Вышел разбор интересной уязвимости MacOS, который круто демонстрирует ситуацию, когда тонкости технической реализации конкретного инструмента могут выстрелить в ногу или даже голову разработчику другого инструмента.
Если коротко: эппловские
Таким образом становится возможна атака логической бомбой - во время установки зараженного pkg в файл .zshenv закидывается нагрузка, а уже при установке следующего pkg, скрипты которого содержат shebang, произойдет исполнение нагруженного кода, причем от рута. PoC и технические детали доступны в этой статье. Обновление до 14.5 Beta 2, 13.6.7 или 12.7.5 защитит Вас от этой уязвимости. Если, конечно, до обновления Вы не устанавливали ничего из pkg с нагрузкой.
А если интересно почитать про то, как неожиданно можно проэксплуатировать свойства вайлдкарда в линуксе - ставьте лайки, расскажу подробнее, если наберем больше 5.
Если коротко: эппловские
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 с нагрузкой.
Scripting OS X
On the Shebang
Every script you want to run from the command line should have a shebang as the first line. Note: I talked about this in my MacSysAdmin talk. I wanted to go into more detail here. You can have scri…
🔥2
Hacktuator
Знаете ли вы, что опубликованный в интернет актуатор в худшей своей конфигурации позволяет злоумышленнику спереть heapdump вашего приложения, в котором, например, есть секреты, сессионные данные пользователей и много всякой-разной служебной информации?
Spring Boot Actuator – это библиотека, которая позволяет мониторить приложение. С её помощью можно посмотреть множество параметров: характеристики системы, на которой работает приложение, какие в приложении создаются бины, различные метрики и т.п. Однако, если это можете увидеть Вы и не совсем корректно настроили, то могут увидеть и другие. Публиковать актуатор в интернет давно считается дурным тоном, однако если зайти на какой-нибудь censys.io, то можно найти кучу сервисов, которые об этом забыли.
Но одно дело не публиковать в Интернет, а второе - забыть про внутреннего злоумышленника и оставить эндпоинты доступными в локальной сети. Признавайтесь, у кого это так?)
В случае, если Ваша компания использует K8s, в целом, стандартные рекомендации по его настройке спасут. Если в файле application.yml прописать следующее:
В случае верной конфигурации после запуска приложения будет доступна, например, следующая точка входа:
:8090/actuator/health - которая предоставляет информацию о состоянии приложения.
Аналогично, info, prometheus, metrics.
Но самое интересное, это порт. Если порт отличается от порта, на котором работает сам сервис, и при этом опубликован только порт сервиса, то
размещение актуатора на другом порту сделает его недоступным вне поды. А это позволяет (без других потенциальных нарушений логики) защититься как от внешнего, так и от внутреннего злоумышленника. По крайней мере, в вопросах актуатора.
Знаете ли вы, что опубликованный в интернет актуатор в худшей своей конфигурации позволяет злоумышленнику спереть 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
Патч: рекомендуется поставить обновления до самой свежей доступной версии по продукту.
С небольшим опозданием рассказываю про новую уязвимость в продуктах 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
Патч: рекомендуется поставить обновления до самой свежей доступной версии по продукту.
Medium
1/6 | How We Hacked Multi-Billion Dollar Companies in 30 Minutes Using a Fake VSCode Extension
30 minutes. 30 minutes is how long it took us to develop, publish, and polish a Visual Studio Code (The most popular IDE on the planet with…
🔥3
regreSSHion: удаленное неаутентифицированное исполнение кода на серверах с OpenSSH
Описание: Сегодня максимально горячий день, потому что уязвимости такого класса выходят редко, прошлый раз был три года назад (Log4j, если кто-то не знал или забыл).
Сегодня днем группа исследователей угроз из Qualys опубликовала статью про уязвимость, получившую название regreSSHion. Статья описывает уязвимость в sshd, OpenSSH сервере, используемом линуксовым семейством операционных систем. Злоумышленник получает неаутетифицированное RCE на сервере с правами sshd. А теперь разберем эту фразу - злоумышленнику не нужно знать креды никакого пользователя, достаточно просто иметь возможность повзаимодействовать с sshd по открытом порту на сервере (многократно, т.к. уязвимость использует ситуацию гонок), и получить возможность исполнять абсолютно любой свой код на сервере с правами sshd. А это права уровня root.
Особенный интерес эта бага вызывает еще и тем, что она уже была, и называется regreSSHion неспроста. В 2006 году ей был присвоен номер CVE-2006-5051 и в том же году на нее был выпущен патч. Но в 2023 году один из коммитов случайно удалил директиву "
Очень подробная статья с кусками кода на С есть здесь.
Уязвимые версии: < 4.4p1, а также 8.5p1 <= и < 9.8p1. OpenBSD не уязвимы к этому багу.
Патч: обновление до 9.8p1 или, если обновление невозможно, установка в конфиге LoginGraceTime на значение 0 (чревато другими проблемами безопасности, но менее критичными)
PoC публиковаться в данной заметке не будет.
Описание: Сегодня максимально горячий день, потому что уязвимости такого класса выходят редко, прошлый раз был три года назад (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 публиковаться в данной заметке не будет.
Qualys
OpenSSH CVE-2024-6387 RCE Vulnerability: Risk & Mitigation | Qualys
CVE-2024-6387 exploit in OpenSSH poses remote unauthenticated code execution risks. Find out which versions are vulnerable and how to protect your systems.
🔥1😱1😢1
На этом фоне, конечно, несколько теряется следующая новость, но все равно опубликую, потому что Supply Chain атаки, по всей видимости, с нами теперь надолго.
На прошлой неделе вышла статья о том, что после выкупа китайской компанией домена
При открытии с телефона сайта, который использует в своей работе polyfill.js запускается своеобразный обфусцированный код, который через фейковый домен с закосом под Google Analytics редиректит пользователя на сайты со спортивными ставками. Автор библиотеки порекомендовал прекратить ее использование.
На прошлой неделе вышла статья о том, что после выкупа китайской компанией домена
cdn.polyfill.io и получения доступа к репозиторию (судя по всему, переданного на платных основах одним из сотрудников Fastly) этой библиотеки, библиотека начала распространять специфический вредоносный код, таргетом которого являются веб-браузеры мобильных телефонов. При открытии с телефона сайта, который использует в своей работе polyfill.js запускается своеобразный обфусцированный код, который через фейковый домен с закосом под Google Analytics редиректит пользователя на сайты со спортивными ставками. Автор библиотеки порекомендовал прекратить ее использование.
Sansec
Polyfill supply chain attack hits 100K+ sites
The new Chinese owner of the popular Polyfill JS project injects malware into more than 100 thousand sites.
🤔1😢1
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
На этой неделе был опубликован патч для Golang библиотеки Fiber, который исправляет уязвимость уровня критичности 10.0 - максимально возможного.
Описание: Session fixation - это уязвимость, которая возникает в том случае, если приложение некорректно контролирует способы создания и управления идентификаторами сессий. Наличие этой уязвимости может привести к тому, что злоумышленник сможет как красть чужие сессии, так и заставлять пользователя с привлечением социальной инженерии совершать какие-то подконтрольные злоумышленнику действия в собственном аккаунте. Так произошло в данном случае: злоумышленник получил возможность создавать свои собственные идентификаторы сессии, которые, при подстановке в правильные запросы, приводили к созданию валидной сессии с таким идентификатором.
Уязвимые версии: <= 2.52.4
Патч: 2.52.5
CVE: CVE-2024-38513
CVSS: 10.0
GitHub
CVE-2024-38513 - GitHub Advisory Database
Session Middleware Token Injection Vulnerability
😱1
Перевалили за 1 биллион
На момент 6 июля 2024 года взломы, информация о которых уже доступна, по объему перевалили за 1 биллион записей.
В 2023 году эта отметка была достигнута к концу октября.
На момент 6 июля 2024 года взломы, информация о которых уже доступна, по объему перевалили за 1 биллион записей.
В 2023 году эта отметка была достигнута к концу октября.
😢2
Cross-Site Request Forgery или зачем нужны CORS'ы
Попалась хорошая статья, рассказывающая про то, как правильно настроить CORS, и самое главное - почему это нужно.
Один из самых популярных вопросов на собеседованиях AppSec инженеров и практически обязательный вопрос в FAANG при собесе на позицию, подразумевающую Security Championship (по слухам от сотрудников на этих позициях).
https://www.devsecurely.com/blog/2024/06/cors-the-ultimate-guide
Попалась хорошая статья, рассказывающая про то, как правильно настроить CORS, и самое главное - почему это нужно.
Один из самых популярных вопросов на собеседованиях AppSec инженеров и практически обязательный вопрос в FAANG при собесе на позицию, подразумевающую Security Championship (по слухам от сотрудников на этих позициях).
https://www.devsecurely.com/blog/2024/06/cors-the-ultimate-guide
Devsecurely
CORS: the ultimate guide | Devsecurely
A simple and concrete guide on the world of CORS. It explain what it is, how it works, and how to set it up to protect your website.
👍2
О том, почему нужно выставлять атрибут 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.
Еще одна отличная статья, на этот раз - про то, как работают браузеры при отрисовке страниц, и почему некоторые на первый взгляд необязательные атрибуты лучше все-таки выставлять.
Уязвимости фронтэнда, на мой взгляд, и так всегда граничат с магией, но вот такие детали о работе браузеров знают не все, поэтому вероятность эксплуатации повышается. Рекомендую к прочтению, особенно с учетом того, что статьи от 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.
Sonarsource
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.
👍1🔥1