769
Мир проигравшего киберпанка. Картинки, новости, мануалы, DIY. Для связи: @the29a
Not so (trivy)al. Как использовать trivy на большом скоупе и не поехать кукухой (нет)
- Сынок, ты связался с trivy usage bad practice.
- Мам, я её основал.
Can You Get Root With Only a Cigarette Lighter?
Можно ли получить root используя зажигалку? Да.
Да, выглядит странно, но это не что-то из разряда "Администрирование под Балкофеном". Всё куда проще (и сложнее), зажигалка в данном случае является инструментом для внедрения аппаратных сбоев (оно же Fault Injection). Чаще всего используется специализированное оборудование или самоделки на Raspberry Pico (PicoEMP) или ESP8266 (fault-injector), но автор пошёл более оригинальным путём.
В роли подопытного выступил ноутбук Samsung S3520 с Intel i3-2310M и 1 ГБ DDR3. Провод в роли антенны к пину DQ26, немного магии bit-flipping и root получен.
Довольно весело и интересно, хотя в целом, практическая польза несколько сомнительна. Но может быть актуально для разных консолей вроде Nintendo Switch.
Видео с демонстрацией: DDR3 EMFI Linux LPE
Репозиторий с эксплоитом: dramm_emfi
Bypassing airport security via SQL injection
В конце августа исследователи Сэм Карри и Иэн Кэрролл сообщили, что обнаружили уязвимость, которая позволила им обходить проверки безопасности в аэропортах США и даже летать в кабине пилотов некоторых регулярных рейсов. Контролем безопасности в американских аэропортах занимается занимается один орган, известный как Transportation Security Administration. Помимо обычных проверок рядовых пассажиров, есть программа TSA PreCheck для доверенных пассажиров, а так же упрощенная система прохода, рассчитанная на пилотов и членов экипажей. Экипаж может подать заявку на проверку в программе, который дает им право пропустить очередь. Аналогичная инициатива также существует только для пилотов, которая позволяет проверенным пилотам сидеть в запасном кресле в кабине (откидном кресле) во время полетов, которые им нужно совершить с любой целью.
Для работы с записями в "члены экипажа" обнаружилась отдельная система - FlyCASS, доступная для ряда сторонних организаций, в которой и обнаружилась уязвимость.
Система контроля доступа FlyCASS позволили обойти форму логина с помощью SQL-инъекции. Используя логин ' or '1'='1 и пароль ') OR MD5('1')=MD5('1 исследователи смогли получить доступ к админке и смогли создать новых одобренных пилотов в программе CASS без каких-либо дополнительных проверок
И как часто бывает, у исследователей возникли сложности с раскрытием информации. Предположительно FlyCASS управляется одним человеком. 23 апреля они смогли сообщить о проблеме в Министерство внутренней безопасности (то самое Department of Homeland Security), которое признало ее и подтвердило, что "очень серьезно к ней относится". Впоследствии FlyCASS была отключена в KCM/CASS, и, судя по всему, проблемы были устранены.
После устранения министерство перестало отвечать исследователям на запросы, пресс-служба TSA отрицала уязвимости.
Изюминки добавляет репорт из Joe Sandbox от Алесандро Ортиса, в котором были скриншоты заражения вирусом-вымогателем, датированные 7 февраля этого года. И по описанию похоже на MedusaLocker.
В итоге представитель TSA ответил:
В апреле TSA стало известно о сообщении о том, что была обнаружена уязвимость в сторонней базе данных, содержащей информацию о членах экипажа авиакомпании, и что в результате тестирования уязвимости в список членов экипажа в базе данных было добавлено непроверенное имя. Никакие правительственные данные или системы не были скомпрометированы, и никакие последствия для безопасности на транспорте, связанные с этими действиями, не наблюдаются.
TSA не полагается исключительно на эту базу данных для проверки личности членов экипажа. TSA имеет процедуры для проверки личности членов экипажа, и только проверенным членам экипажа разрешен доступ в защищенную зону в аэропортах. TSA работала с заинтересованными сторонами для смягчения любых выявленных киберуязвимостей.
OSV от Google это не только база уязвимостей, но и сканер к ней - OSV-Scanner
Может сканировать директории с проектом, SBOM (SPDX и CycloneDX), Lockfile, Docker-образы и имеет интеграцию в виде Github Action. Есть и Remediation Tools, но это пока что экспериментальный функционал.
Установить OSV‑Scanner можно из репозиториев (применимо для Arch, Windows, macOS, netBSD) или собрать из исходников:
go install github.com/google/osv-scanner/cmd/osv-scanner@v
osv-scanner -r path/to/your/project
osv-scanner --recursive path/to/your/project
osv-scanner --sbom=cycloned-or-spdx-sbom.json
osv-scanner --lockfile=package-lock.json
osv-scanner --docker vulnerables/web-dvwa
osv-scanner --docker vulnerables/web-dvwa --format json
osv-scanner fix -M path/to/package.json -L path/to/package-lock.json
osv-scanner fix --non-interactive --strategy=in-place -L path/to/package-lock.json
osv-scanner fix --non-interactive --strategy=relock -M path/to/package.json -L path/to/package-lock.json
Purple Team: Detection as Code
Detection as Code - идея витавшая в воздухе, но по сей день не получившая широкого распространения.
Концепция DaC довольно проста - применяем к написанию и управлению правилами обнаружения лучшие практики из мира разработки, добавляем контроль версий, используем CI/CD и радуемся жизни.
Вроде и плюсы достаточно весомые:
- Автоматизация и интеграция
- Гибкость и масштабируемость
- Повышение качества
- Возможность шарить правила\детекты и их контроль версий
Концепция хорошая и интересная, но пока не снискавшая популярности. Каких-то готовых best practices пока нет, а плане софта всё пока крутится вокруг Splunk.
Пара статей на тему:
Splunk: Detection as Code: How To Embed Threat Detection into Code
Medium - Brendan Chamberlain: Practical Detection-as-Code
Github: detection-as-code
Microsoft Windows Endpoint Forensics Readiness Booster
Форензика и защита эндпоинтов на Windows штука не самая запутанная, но без предварительной подготовки превращается в увлекательный заезд на трёх колёсах.
Для такой подготовки используются довольно универсальные подходы, используемые и в мониторинге безопасности, привычно мониторится:
- TaskScheduler (события 106, 107, 140, 141)
- Security Log (события 4698, 4699, 4702)
- Запуск Powershell (события 4103, 4104, 4105, 4106)
- Создание процессов (событие 4688)
- Сетевая активность (событие 5156)
В целом, хоть статья и про предварительную подготовку к расследованию, в рамках мониторинга эти источники логов и события стоит собирать в условном Wazuh, а не только локально на машине.
Давно ничего не было по взлому железок. А тут нашлось не одно видео или запись с блога, а целый mattbrwn/videos">Youtube-канал.
И не абы кого, а nmatt0 (в миру Matt Brown), MVH на H1-213.
А ещё у него был доклад про почивший ныне ByteSweep - Automatic Security Analysis of IoT Firmware на Global AppSec DC 2019 и BSidesLV 2019.
ByteSweep закончился, а взлом IoT остаётся.
У сканера докеров Trivy есть система плагинов. Самих плагинов не много, они не какие-то сверх-полезные, но могут пригодиться. Один из них scan2html, и как можно понять из названия, он генерирует html-репорт из сканирования.
Устанавливаем плагин:
trivy plugin install scan2html
trivy scan2html repo https://github.com/aquasecurity/trivy-ci-test --scanners vuln,misconfig,secret result.html
17 vulnerabilities in Sharp Multi-Function Printers
Давно не было новостей о (не)безопасности из мира оргтехники.
Blackbox-тестирование показало, что 308 моделей МФУ от Sharp содержат более 18 различных уязвимостей, в том числе без присвоенных CVE.
Уязвимости были подтверждены примерно на 15 различных моделях, работающих с последними версиями прошивки (MX-3060N, MX-3061, MX-3070N, MX-3560N, MX-3561, MX-5070V, MX-5071, MX-C3051R MX-C3081R, MX-M365N, MX-M453U, MX-M465N, MX-M5050, MX-M5051, MX-M6051 и MX-M6071).
Физическая безопасность принтеров не анализировалась (как и сами прошивки), так что в теории их может оказаться куда больше.
МФУ работают под управлением Linux и имеют вполне неплохое железо, так что они могут отлично подходить для различных имплантов (даже без сборки прошивки) и перемещения в инфраструктуру.
Информация об уязвимостях была передана в JPCERT 1 июня 2023 года, так что можно надеяться на фиксы.
Сами Sharp уже выкатили рекомендации по устранению уязвимостей.
Non-Production Endpoints as an Attack Surface in AWS
Non-Production эндпоинты можно использовать для незаметного перечисления разрешений, что позволяет злоумышеннику, провести разведку без внимания со стороны жертвы. Даже когда они изолированы от ресурсов, злоумышленник все равно может получить потенциальный доступ к информации на уровне учетной записи. Так же злоумышленник может избегать обнаружения используя Non-Production эндпоинты для маскировки событий в CloudTrail.
Это исследование мне немного напоминает метод определения ID бакета (и не только бакета).
В AWS снова ничего страшного не увидели, но всё починили (почти за год).
Иногда складывается ощущение, что настройка пермишенов в AWS настолько сложна и монструозна, что в самом Amazon с этим бывают сложности.
Bypassing Okta’s Passwordless MFA: Technical Analysis and Detection
Если у Okta не нашли какую-то техническую проблему, то я начинаю беспокоиться. Но всё в порядке, ведь подъехал байпасс MFA Okta.
На этот раз под раздачу попал Okta FastPass. FastPass это многофакторный аутентификатор, который обеспечивает аутентификацию без пароля приложений SAML, WS-Fed и OIDC в Okta. Функционирует как обычный аутентификатор, связанный с устройством, для получения фактора "владения" и совместим с различными операционными системами через приложение Okta Verify.
Okta Verify также поддерживает биометрическую проверку через Face ID или распознавание отпечатков пальцев. Если пользователь включает эту опцию, из аппаратного TPM генерируется дополнительный набор открытых/закрытых ключей, а открытый ключ отправляется на серверы Okta. Эту функцию биометрической проверки Okta называет фактором "проверки пользователя" ("something you are").
Но как показывает практика, TPM не является "серебряной пулей".
Большинство реализаций беспарольных решений MFA с привязкой к устройствам и биометрических решений генерируют криптографические ключи, хранящиеся в TPM. При наличии соответствующего доступа и разрешений эти ключи могут быть использованы не по назначению.
И разумеется, к этому всему уже есть готовый инструмент - okta-terrify, представленный в рамках доклада на BSides Cymru 2024.
Видео с выступления нет, но есть демо-видео с доклада.
Introduction to Software Reverse Engineering [To Non-techies]
Как объяснить магию реверса человеку без технического бэкграунда?
Через гены, ноты, чертежи и рецепты.
А если серьезно, то для совсем не-технарей может быть не понятно (да и не интересно), но для людей, далёких от реверса (а может и от разработки), может быть что-то интересное.
Статья проходит по верхам, но сам подход объяснен довольно понятно.
OWASP Top 10 for Large Language Model Applications
Итак, OWASP Top 10 добрался до LLM и уже существует в версии 1.1.0
Среди примеров уязвимостей - инъекции, утечка данных, неадекватная "песочница", несанкционированное выполнение кода и другие.
Что же у нас в топе:
- LLM01: Prompt Injection
- LLM02: Insecure Output Handling
- LLM03: Training Data Poisoning
- LLM04: Model Denial of Service
- LLM05: Supply Chain Vulnerabilities
- LLM06: Sensitive Information Disclosure
- LLM07: Insecure Plugin Design
- LLM08: Excessive Agency
- LLM09: Overreliance
- LLM10: Model Theft
Почитать можно в PDF:
OWASP Top 10 for LLM Applications
Security & Governance Checklist
В дополнении ко всему OWASP запустили отдельный сайт - genai.owasp.org, где будет актуальная информация и переводы.
Снова кожаные мешки перекладывают свои заботы и задачи безопасности CI на машинное обучение.
RedFlag - инструмент для определения изменений кода с высоким уровнем риска. В качестве AI выступает Claude от Amazon, и интегрируется с Github и Jira (опционально).
Задумка довольно проста: сравниваются ветки (или коммиты, или тэги), полученные коммиты проверяются на наличие прилинкованных задач в Jira, добавляется немного промптов и генерируется репорт.
Можно позапускать ручками, интегрировать в CI/CD или в так называемом Evaluation Mode для оценки производительности.
Выглядит интересно и отчёты довольно неплохие, но несколько сомнительно, как по мне. Пока что вызывает вопросы детекты. А так же стоимость и доступность того же Claude.
Документация: Github: Redflag Wiki
Пример репорта: Redflag Example Report
Статья в блоге авторов: Introducing RedFlag: Using AI to Scale Addepar's Offensive Security Team
Учебный центр Эшелон решили импортозаместить CISSP, и выпустили курс ССК (Сертифицированный специалист по кибербезопасности).
ССК представляют как прямой Российский аналог CISSP. Ранее преподаватели Эшелона с сертификатами CISSP проводили курсы по подготовке и сдаче самого CISSP.
Домены так же схожи:
- Менеджмент информационной безопасности
- Законодательство в области информационной безопасности
- Контроль доступа
- Сетевая безопасность
- Криптография
- Обеспечение непрерывности бизнеса и восстановление после сбоев
- Контроль и мониторинг информационной безопасности
- Разработка безопасного программного обеспечения
И для подготовки и сдачи экзамена не потребуется чемодан денег, онлайн-подготовка к сдаче экзамена и онлайн-экзамен будут бесплатными.
Обладатели CISSP (есть тут такие?) смогут получить сертификат ССК без сдачи экзамена.
Вообще идея хорошая. Хорошо иметь стандартные сертификации для своего рынка. Хотелось бы ещё видеть аналоги курсов и сертификатов от Offensive Security. И возможно даже CEH (но это не точно).
Пресс-релиз
Регистрация на курс подготовки
Примеры вопросов
На днях при использовании ByeDPI начал тормозить Youtube (не только из России ¯\_(ツ)_/¯, как ни странно).
Помогает запуск с опциями:
ciadpi -p 8888 -s1 -q1 -Y -Ar -s5 -o1+s -At -f-1 -r1+s -As -s1 -o1 +s -s-1 -An
Trivy из коробки не умеет в EPSS и даже не планирует.
Плохо, но не ужасно. На помощь нам снова приходит trivy-plugin-vulners-db.
Правда и тут не без проблем. Плагин крутой, но вывод (по крайней мере сейчас) не как на скриншотах. Нам снова потребуется немного магии jq:
cat input.json | jq '.Results[1].Vulnerabilities[].Description |= fromjson'
Немного сиволапого vulnerability management.
Есть у нас условный репорт nmap/nuclei/Defect Dojo с кучей разных CVE. Вроде понятно, что всё надо как-то фиксить. Но возникает вопрос: что нужно фиксить "ещё вчера", а что "не отлично, но и не ужасно" и вообще может подождать? Когда счёт идёт на десятки, ещё пробежаться глазами и определить критичность и приоритет, но когда счёт CVE идёт на сотни, такой процесс может занять очень много времени.
А нам как-то надо отделить уязвимый ssh от бесконечных buffer overflow в vim.
От чего мы можем отталкиваться?
- CVSS с Base Score (Severity). Тут вроде всё просто. Сначала смотрим Critical, потом High и так далее.
- Vector в том же CVSS. Менее понятно, но тоже можно использовать
- Наличие эксплоитов и PoC. Жизнь менее тревожна, когда нет готового эксплоита к сервису, который торчит снаружи.
- Особенности инфраструктуры. Тут уже делает поправки каждый сам.
Что нам может помочь?
- CISA KEV, он же Known Exploited Vulnerabilities Catalog. Звучит здорово и круто, но фактически скорей может использоваться как затычка без иных источников. В списке скорей ради того, чтобы дать знать о такой штуке.
- Defect Dojo. Не решает все задачи, требует напильника, хромает в документации, но жизнь облегчает сильно. Вообще не обязательно он, но из open source других вариантов нет.
- Vulristics. Инструмент позволяющий приоритизировать найденные CVE. Работает с множеством баз уявзимостей, вроде NVD, BDU, vulners. Может генерировать отчёты вроде такого.
Инструменты есть, а что дальше?
Для начала нам нужен список CVE. В случае с условным nuclei мы может погрепать репорт.
Если вы используете Defect Dojo, то можно экспортировать находки в csv и получить список CVE:
csvcut -c vulnerability_ids findings.csv | sort | uniq | sed '/^vulnerability_ids/d' > critical_cve_id.list
python3 vulristics.py --report-type "cve_list" --cve-project-name "test_project" --cve-list-path "/home/the29a/critical_cve_id.list"
Beyond the CVE: Analyzing the Depth of GitHub Security Advisories
С 2017 Github нас радует своим GitHub Security Advisory Database, обогащая информацию по уязвимостям из разных источников и лишь в моменты чтения идентификаторов уставшие глаза безопасника начинают дёргаться.
По данным CVE.org существуют 240830 CVE (у автора статьи цифра 250 000), но далеко не все из них касаются проектов с открытым исходным кодом. Так же стоит учитывать, что GHSA скорей учитывает т.н. экосистемы, (вроде pip, npm и так далее).
GitHub является авторизованным центром нумерации CVE и может назначить CVE рекомендациям по безопасности в рамках своей области действия, но множество уязвимостей остаются без CVE. А так же есть небольшой перекос по покрытию.
Вывод довольно простой: не используйте GHSA в качестве единственного источника о уязвимостях. Лучше использовать osv.dev или vulners, где GHSA уже есть как источник.
🐇 Как часто вас зовут на расследование инцидента?
#forensic #memory_analysis #volatility
У меня такие кейсы на работе бывают. К счастью не инхаус, а консалтинг. И когда они бывают, я если честно теряюсь и не знаю, что делать. Т.к. каждый раз новая инфра, новый неизвестный вектор и всё это очень заряжает сделать свою работу по-красоте))
Так вот, если вы не гигачад форензик, то думаю следующая штука вам понравится:
VolWeb - это платформа, нацеленная на цифровой анализ памяти на наличие чего либо. Данная платформа, как ясно из названия взяла за основу Volatility 3 и возвела его в абсолют сделав к тому же красивый и вполне удобный веб интерфейс.
Как пишет разработчик:
Цель VolWeb — повысить эффективность сбора и анализа памяти, предоставляя централизованное, визуальное и расширенное веб-приложение для реагирования на инциденты и цифровой криминалистики. После того как исследователь получает образ памяти с системы Linux или Windows, доказательства могут быть загружены в VolWeb, что запускает автоматическую обработку и извлечение артефактов с помощью возможностей фреймворка Volatility 3.
Используя облачные технологии хранения, VolWeb также позволяет специалистам по реагированию на инциденты напрямую загружать образы памяти в платформу VolWeb из различных мест с помощью специальных скриптов, интегрированных с платформой и поддерживаемых сообществом. Еще одной целью является предоставление пользователям возможности собирать техническую информацию, такую как индикаторы, которые затем могут быть импортированы в современные платформы CTI, такие как OpenCTI, что позволяет связать команды реагирования на инциденты и CTI после завершения расследования.
Пошаговый процесс создания и запуска фишинговой кампании с целью тестирования и улучшения безопасности организации.
https://blog.onsec.io/from-zero-to-hero-phishing-campaign/
https://blog.onsec.io/from-zero-to-hero-phishing-campaign-part-2/
https://blog.onsec.io/from-zero-to-hero-phishing-company-final/
#phishing #security
"Hold My Beer" said NASA and Fixed Voyager 1 Because We Said They Couldn't
NASA взломали Voyager 1: Твит и новость от NASA.
Немного кликбейтно, но в целом верно.
В конце прошлого года аппарат Voyager 1 перестал отправлять полезные данные на Землю. Как установили инженеры NASA, проблема оказалась в одном из бортовых компьютеров, они же FDS - Flight Data System.
Система Flight Data System является критически важным компонентом миссии Voyager 1, поскольку она обеспечивет сбор и передачу научных данных на протяжении всего полета аппарата. Когда была обнаружена неисправность в одном из модулей FDS, многие подумали, что, возможно, пришло время завершить миссию. Однако, проанализировав ситуацию, инженеры NASA выяснили, что повреждено только около 3% памяти FDS, что означало, что проблема была связана с одним чипом.
Поскольку эта система модульная, существует возможность перенаправить всё с использованием программного обеспечения, обходя неисправный чип и заставляя систему работать на других чипах. Именно это и сделали инженеры, разделив код на отдельные секции и сохранив их в различных местах FDS.
Оригинальные зонды "Вояджер" имели программное обеспечение, написанное на Fortran, что позволяло нескольким командам непосредственно изменять код на лету, фактически изменяя всё внутри зонда. В программировании существует известная команда poke, которая в различных высокоуровневых языках устанавливает значение байта в определённый адрес памяти. В старых компьютерах эта команда использовалась для взлома игр. Команда "Вояджер" использовала команду poke на FDS, чтобы перенаправить все важные функции от неисправного чипа на другие места.
regreSSHion: Remote Unauthenticated Code Execution Vulnerability in OpenSSH server
Qualys обнаружили критическую уязвимость в OpenSSH, позволяющую добиться RCE без аутентификации.
Уязвимость уже получила кодовое имя regreSSHion и СVE: CVE-2024-6387
Уязвимость присутствует в версиях от 8.5p1 до 9.8p1.
Системы OpenBSD не затронуты, так как в 2001 году OpenBSD разработала безопасный механизм, предотвращающий эту уязвимость.
Патч уже выпустили, ждем обновлений - Debian, Ubuntu, RHEL, Fedora, SUSE/openSUSE, Arch.
Возможный workaround:
Параметр "LoginGraceTime=0" в sshd_config.
Но есть и минусы: отключение таймаута упростит DoS при установке большого числа соединений, превышающих лимиты, заданные через параметр MaxStartups.
Qualys так же выпустили подробное описание уязвимости, PoC уже есть.
У pwnagotchi появился аналог - Bjorn
Не то, чтобы аналог, схожая прошивка для аналогичной платформы.
Что изветно на текущий момент:
- используется Raspberry Pi Zero с экраном от Waveshare
- снова фигурирует AI (не ясно, для чего, зачем и как)
- liveview веб-интерфейс с настройками
- работа с WiFi, Ethernet, Bluetooth или USB
- поиск уязвимых сервисов
- брутфорс запущенных сервисов (ssh, telnet, sql)
- интеграция с C2C своей разработки (Zombieland)
В общем, много всего, и что-то из этого будет работать.
Проект пока что в разработке, исходников нет. Но вы держитесь.
Но есть фоточки, доска Trello и сабреддит.
Encryption At Rest: Whose Threat Model Is It Anyway?
Шифрование данных в состоянии покоя в веб-приложении тема не самая простая и дискуссионная. Если с передаваемыми данными (Data in transit) всё относительно понятно: мы их передаём по TLS\SSL или иными спобовами, с используемыми данными (Data in use) всё не совсем понятно, но есть различные SME, FME, VBS, HVCI и прочие штуки.
В случае с данными в состоянии покоя мы могли бы просто использовать полнодисковое шифрование, но и оно защищает не от всех угроз. Особенно если это касается веб-серверов. Размышлениями на эту тему с нами делится Скотт Арчишевски, один из авторов библиотеки CipherSweet.
А на тему Data-at-rest encryption (без привязки к веб-серверам) есть неплохая статья на Arch Wiki.
TempleOS Reverse Engineering Introduction
TempleOS - довольно специфичная и самобытная операционная система, написанная Терри Дэвисом. Хоть Терри страдал от шизофрении, в определенных кругах TempleOS считается довольно интересным и самобытным проектом.
TempleOS имеет частично открытый исходный код, но исходный код ядра и загрузчика недоступен. Николас Старке решил восполнить этот пробел, чтобы почтить память Терри Девиса.
Это первая статья из серии, ждем остальные.
P.S. А ещё у TempleOS есть вполне действующий форк - ZealOS.
Every XSS is a site takeover
Вроде бы и да, но вроде бы и нет. WordPress является самой популярной CMS, и очевидно, что плагинов будет большое количество. Но вот с качеством могут быть проблемы.
Далеко не все считают XSS опасной уязвимостью, однако в WordPress всё устроено несколько иначе.
Wordfence запустили баг-баунти программу, и уязвимости посыпались как из рога изобилия, в том числе и XSS:
CVE-2024-4619 - Elementor - DOM Based - Medium
CVE-2023-6701 - ACF - Stored - Medium
CVE-2023-47777 - WooCommerce - Medium
Yoast SEO <= 20.2 - Stored - Medium
Вроде ничего страшного, но однако это верхушка айсберга, которая может привести к большим проблемам. В том числе и захвату сайта.
А ещё у WordPress вообще довольно странная политика раскрытия уязвимостей и назначения CVE. Где-то что-то есть, но чаще всего ничего нет. Ещё были странные баги в <=6.41, но это не связанно с XSS и статьёй, да и толком почитать по ним нечего.
ML в безопасности CI это может хорошо, но защищать и атаковать самим лучше.
Два awesome-списка.
Для атакующих: Awesome CI/CD Attacks
- Techniques
- Publicly Exposed Sensitive Data
- Initial Code Execution
- Post Exploitation
- Defense Evasion
- Offensive Tools
- Case Studies
Для защищающих: Awesome CI/CD Security
- Book
- Blogs
- Videos
- Repositories
- Playground
- Cases
Интересное исследование от Project Zero в двух частях.
Казалось бы, реестр Windows вещь весьма простая и понятная. Однако и он таит в себе множество различных уязвимостей. За 20-месячный период с мая 2022 года по декабрь 2023 года автор исследования получилось целых 50 CVE.
В ходе исследования было сдано 39 отчетов об ошибках в трекер ошибок Project Zero, которые были исправлены Microsoft как 44 CVE. Причин расхождения между этими цифрами несколько:
- Некоторые отдельные отчеты включали информацию о нескольких проблемах, например issue 2375 была решена четырьмя CVE,
- Некоторые группы отчетов были исправлены одним патчем, например issue 2392 и 2408 как CVE-2023-23420.
- Один отчет об ошибке был закрыт как WontFix и вообще не был рассмотрен в бюллетене по безопасности (issue 2508).
Все отчеты были представлены в соответствии с политикой Project Zero в отношении 90-дневного срока раскрытия информации, и Microsoft во всех случаях успешно уложилась в этот срок. Среднее время от отчета до исправления составило 81 день.
Кроме того, в период с ноября 2023 года по январь 2024 года автор сообщил о 20 проблемах, которые имели незначительное или неясное влияние на безопасность, но он считал, что поставщика всё же следует о них уведомить. Они были отправлены без срока раскрытия и не были опубликованы на трекере Project Zero, но были опубликованы на GitHub Project Zero.
По результатам оценки Microsoft решила исправить 6 из них в бюллетене по безопасности в марте 2024 года, а остальные 14 были закрыты как WontFix с возможностью их устранения в будущей версии Windows.
В общей сложности получилось 50 CVE, которые Microsoft классифицирует как:
- 39x Уязвимость ядра Windows, связанная с повышением привилегий
- 9x Уязвимость ядра Windows, связанная с раскрытием информации
- 1x Уязвимость раскрытия информации в памяти ядра Windows
- 1x Уязвимость ядра Windows, связанная с отказом в обслуживании
Само исследование в двух частях:
The Windows Registry Adventure #1: Introduction and research results
The Windows Registry Adventure #2: A brief history of the feature
❯ docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
c1ec31eb5944: Pull complete
Digest: sha256:266b191e926f65542fa8daaec01a192c4d292bff79426f47300a046e1bc576fd
Status: Downloaded newer image for hello-world:latest
Hello from Docker!
This message shows that your installation appears to be working correctly.
Ложки-то нашлись, а осадок остался!Читать полностью…