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 и статьёй, да и толком почитать по ним нечего.

Introduction to Software Reverse Engineering [To Non-techies]

Как объяснить магию реверса человеку без технического бэкграунда?
Через гены, ноты, чертежи и рецепты.

А если серьезно, то для совсем не-технарей может быть не понятно (да и не интересно), но для людей, далёких от реверса (а может и от разработки), может быть что-то интересное.

Статья проходит по верхам, но сам подход объяснен довольно понятно.

TempleOS Reverse Engineering Introduction

TempleOS - довольно специфичная и самобытная операционная система, написанная Терри Дэвисом. Хоть Терри страдал от шизофрении, в определенных кругах TempleOS считается довольно интересным и самобытным проектом.

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

Это первая статья из серии, ждем остальные.

P.S. А ещё у TempleOS есть вполне действующий форк - ZealOS.

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.
Видео с выступления нет, но есть демо-видео с доклада.

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.

Non-Production Endpoints as an Attack Surface in AWS

Non-Production эндпоинты можно использовать для незаметного перечисления разрешений, что позволяет злоумышеннику, провести разведку без внимания со стороны жертвы. Даже когда они изолированы от ресурсов, злоумышленник все равно может получить потенциальный доступ к информации на уровне учетной записи. Так же злоумышленник может избегать обнаружения используя Non-Production эндпоинты для маскировки событий в CloudTrail.

Это исследование мне немного напоминает метод определения ID бакета (и не только бакета).
В AWS снова ничего страшного не увидели, но всё починили (почти за год).

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

У pwnagotchi появился аналог - Bjorn

Не то, чтобы аналог, схожая прошивка для аналогичной платформы.

Что изветно на текущий момент:
- используется Raspberry Pi Zero с экраном от Waveshare
- снова фигурирует AI (не ясно, для чего, зачем и как)
- liveview веб-интерфейс с настройками
- работа с WiFi, Ethernet, Bluetooth или USB
- поиск уязвимых сервисов
- брутфорс запущенных сервисов (ssh, telnet, sql)
- интеграция с C2C своей разработки (Zombieland)

В общем, много всего, и что-то из этого будет работать.

Проект пока что в разработке, исходников нет. Но вы держитесь.
Но есть фоточки, доска Trello и сабреддит.

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 уже выкатили рекомендации по устранению уязвимостей.

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 уже есть.

У сканера докеров Trivy есть система плагинов. Самих плагинов не много, они не какие-то сверх-полезные, но могут пригодиться. Один из них scan2html, и как можно понять из названия, он генерирует html-репорт из сканирования.

Устанавливаем плагин:

trivy plugin install scan2html 

Сканируем:

trivy scan2html repo https://github.com/aquasecurity/trivy-ci-test --scanners vuln,misconfig,secret result.html

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

Для пользователей kubectl тоже есть плагин - trivy-plugin-kubectl, но у меня нет kubectl, так что ничего сказать не могу.

Давно ничего не было по взлому железок. А тут нашлось не одно видео или запись с блога, а целый Youtube-канал.
И не абы кого, а nmatt0 (в миру Matt Brown), MVH на H1-213.

А ещё у него был доклад про почивший ныне ByteSweep - Automatic Security Analysis of IoT Firmware на Global AppSec DC 2019 и BSidesLV 2019.

ByteSweep закончился, а взлом IoT остаётся.

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

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

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, а не только локально на машине.

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

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 уже есть как источник.

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 найдет lockfile, SBOM и git-каталоги в целевом каталоге для определения зависимостей, чтобы проверить их по базе OSV на наличие известных уязвимостей.

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

Сканирование SBOM

osv-scanner --sbom=cycloned-or-spdx-sbom.json

Сканирование Lockfile

osv-scanner --lockfile=package-lock.json

Сканирование образов Docker

osv-scanner --docker vulnerables/web-dvwa 
osv-scanner --docker vulnerables/web-dvwa --format json

Сканирование образов docker ограничено только Debian based, а так же не сканирует файловую систему контейнера. Есть issue от 2022 года, но всё ещё висит.

Remediation Tools
Функционал Remediation Tools есть в двух форматах: interactive и non-interactive.

Guided Remediation (interactive)

osv-scanner fix -M path/to/package.json -L path/to/package-lock.json

Guided Remediation (non-interactive)

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

osv-scanner хоть и имеет большой объем функционала в экспериментальном статусе, работает довольно быстро. Некоторые ограничения, например сканирование Docker образов можно компенсировать каким-нибудь генератором SBOM (например Syft). У него нет универсальности других сканеров, вроде Trivy, но если есть задача сканировать только на наличие уявзимостей, то osv-scanner хороший вариант.

Репозиторий: github.com/google/osv-scanner
Документация: google.github.io/osv-scanner

Немного сиволапого 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

Итоговый список уязвимостей мы можем скормить vulristics:

python3 vulristics.py --report-type "cve_list" --cve-project-name "test_project" --cve-list-path "/home/the29a/critical_cve_id.list"

На выходе получим отчёт в html.

Не последнюю очередь будет играть и поиск эксплоитов и PoC для уязвимостей. Их лучше искать самостоятельно, так как CISA KEV, NIST и прочие могут отставать от реальности.
Можно использовать osv-scanner, cve-maker или тот же searchsploit.

Спасает ли это от ручного труда?
Увы, нет. Но это можно и нужно автоматизировать.
Решение не идеальное, но вполне упрощает жизнь.

Управление уязвимостями хоть и не самое весёлое занятие (особенно без автоматизации), но довольно полезное. На уровне аналитики оно может дать представление, какие процессы работают плохо или вовсе отсутствуют. Так же не стоит забывать, что это ещё и инвентаризация, без которой обеспечить безопасность довольно сложно.