Склад

📸 Хакеры взломали 14 500 камер Dahua всего за 35 дней

ИБ-исследователи обнаружили масштабную кампанию CameraSwarm, в рамках которой хакеры взломали уже 14 530 IP-камер Dahua.

По словам специалистов, атаки длились как минимум 35 дней (с 17 июня по 22 июля 2026 года), и большинство подтвержденных жертв находятся на территории России и Украины.

— Аналитики Hunt.io пишут, что обнаружили вредоносную активность случайно: оператор CameraSwarm оставил без защиты рабочую директорию на HTTP-сервере.

🗄 Источник – линк.

// Не хакинг, а ИБ

• Ну что, борьба с умными камерами Flock в США продолжается. На этот раз вместо вандализма и кражи камер американцы нашли более интересный способ.

• Исследователь Билл Сверинген разработал специальный компьютерный рисунок на пленке, который защищает автомобиль от слежки (на фото).

• Билл даже представил решение на конференции DEF CON в Лас‑Вегасе, где показал Toyota Yaris, обклеенную виниловой пленкой. Для создания рисунка он использовал ИИ модель, которая обучалась на шаблонах, позволяющих избежать детекта.

• В итоге модель смогла обмануть 11 протестированных алгоритмов обнаружения с открытым исходным кодом, а также считыватели номерных знаков Flock и даже нательные камеры Axon, которые использует полиция.

➡ https://techcrunch.com/cameras-from-detecting-you/

• К слову, Билл также разработал футболки и толстовки с узорами, позволяющими обходить алгоритмы обнаружения. Он надеется в конечном итоге выставить на продажу и защитные чехлы для автомобилей с такими же узорами.

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

#Разное #Новости

POST-параметр → exec() → shell: как одна строка кода превращает админку CMS в точку входа на сервер

Представьте: вы администратор CMS, нажимаете кнопку «Обновить ядро», а браузер отправляет POST-запрос с параметром php. Значение этого параметра — путь к PHP-бинарнику — без какой-либо фильтрации конкатенируется в строку и уходит прямиком в exec(). Ни escapeshellarg(), ни allowlist, ни regex. Голый пользовательский ввод в shell-команде. 2026 год на дворе.

Именно это обнаружилось при анализе патча baserCMS 5.2.3. Уязвимости присвоены сразу два CVE — CVE-2026-21861 и CVE-2026-30877 — обе с оценкой CVSS 9.1 (CRITICAL). CISA подтвердила наличие концептуального PoC.

🔎Почему это опаснее, чем кажется?

Типичная реакция: «Атакующий уже админ, что ему ещё нужно?» Ответ кроется в CVSS-флаге Scope: Changed. Администратор CMS управляет контентом — страницами, медиафайлами, плагинами. OS command injection выводит атакующего за рамки приложения на уровень операционной системы:

• Чтение DB-credentials из конфигов CakePHP, SSH-ключей, API-токенов
• Запись PHP-шелла в webroot — сессия протухнет, а шелл останется
• Reverse shell для pivot'а к базе данных, очередям сообщений, внутренним API
• Полный контроль от имени www-data: чтение /etc/passwd, запуск произвольных бинарников

Для атакующего, получившего админ-аккаунт через credential stuffing или фишинг, это мост от «могу редактировать сайт» к «выполняю любые команды на сервере».

➡️Как устроен вектор атаки?

Контроллер PluginsController, метод get_core_update(). Параметр php извлекается из POST-данных и попадает в shell-команду дважды — как путь к бинарнику в начале и как аргумент после --php. Спецсимволы ;, |, &&, обратные кавычки и $() проходят без фильтрации. Подставляем в параметр что-то вроде php;id — и получаем выполнение произвольной команды.

«Но ведь есть CSRF-защита!» — скажете вы. Не поможет. Атакующий с легитимной admin-сессией получает валидный CSRF-токен штатным образом. Запрос формально легитимен: правильный endpoint, правильный метод, валидный токен. Скрытие кнопки обновления в UI бесполезно — endpoint доступен через curl или Burp Repeater.

👉Что делать прямо сейчас?

Если используете baserCMS — обновляйтесь до 5.2.3 немедленно. Обе уязвимости закрыты в одном релизе. Два CVE, один diff — скорее всего, два разных injection-вектора, найденных при одном аудите.

В полной статье — воспроизводимая цепочка эксплуатации, конкретные правила детектирования для WAF, хоста и SIEM, а также детальный разбор CVSS-вектора. Читайте на форуме.

https://codeby.net/threads/cve-2026-21861-basercms-uyazvimost-os-command-injection-cherez-funktsiyu-obnovleniya-yadra.94977/

🐞 Охотник за эксплойтами - GitHub-репозиторий который автоматически находит PoC для CVE

trickest/cve — это репозиторий, который автоматически собирает общедоступные Proof-of-Concept для известных уязвимостей (CVE). Вместо того чтобы вы часами искали рабочий пример эксплойта, он делает это за вас 24/7.

Проект создан командой Trickest, которая специализируется на автоматизации и создании кастомных рабочих процессов в области кибербезопасности. И этот репозиторий — яркий пример их подхода: взять рутинную, но важную задачу и полностью ее автоматизировать.

👀 Источник

✋ Secure Books

Windows Forensics Analyst Field Guide

Описание:
Книга начинается с подробного описания операционных систем Windows и лежащих в их основе криминалистических артефактов, что поможет вам освоить искусство оптимизации процессов расследования. От использования инструментов с открытым исходным кодом для сбора артефактов до углублённого анализа — вы приобретёте навыки, необходимые для успешной работы в качестве опытного судебного эксперта. По мере изучения материала вы научитесь без труда собирать и анализировать улики, чтобы выявлять суть проблем. Вы также познакомитесь с криминалистической экспертизой памяти, адаптированной для ОС Windows, научитесь расшифровывать закономерности в пользовательских данных, а также регистрировать и распутывать сложные артефакты, такие как электронные письма и данные браузера.

🧷Скачать бесплатно

#OS

CodeMode & Max

🚨 New Gitea RCE (CVE-2026-60004) lets repository writers plant a malicious Git hook and run shell commands as the Gitea service account.

On default-configured instances, outsiders can register, create a repository, and obtain the required write access.

A public PoC is available.

Find details here: https://thehackernews.com/2026/07/new-gitea-rce-lets-repository-writers.html

🛠 Всем привет.
Я тут допилил CLI-движок для LOLCreds на Go. Называется это безобразие CredsHound.

Если коротко, это такая утилита для поиска учетных данных, ключей на хосте, которая работает по концепции Nuclei.

Из коробки она ищет:
- Пароли и API-ключи, забытые в истории терминалов (.bash_history, .zsh_history, ConsoleHost_history.txt).
- Приватные ключи SSH, конфигурации Kubernetes и токены Docker Registry.
- Артефакты Windows: пароли из файлов автоматической установки (Unattended XML), конфиги RDCMan и групповые политики с зашифрованными cpassword.
- Локальные файлы конфигурации БД вроде .pgpass или .my.cnf.

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

📖 Как запустить:

# установка
go install github.com/haxxm0nkey/credshound/cmd/credshound@latest

# запуск
credshound -ut
credshound .

🔗 Где исходники, Билли?
Движок: https://github.com/haxxm0nkey/credshound

Хорошей пятницы вам, держитесь там!

wp2shell — разбираем от и до.

Это цепочка уязвимостей, которая состоит из таких элементов:

📍 CVE-2026-63030 — уязвимость путаницы маршрутизации конечной точки пакетного REST API. CWE-436.

📍 CVE-2026-60137 — уязвимость внедрения SQL-кода (SQL-инъекция). CWE-89.
wp2shell позволяет неавторизованному злоумышленнику выполнить произвольный код (RCE) в СMS Wordpress. Затронутые версии: 6.8.0–6.8.5; 6.9.0–6.9.4; 7.0.0– 7.0.1.

🫡 Об уязвимости:
Уязвимость находится в функции serve_batch_request_v1, которая обрабатывает пакетные запросы к /wp-json/batch/v1.

Функция создает два массива для обработки входящих подзапросов: $requests[] (сами запросы) и $matches[] (найденные для них обработчики).

Если путь одного из подзапросов некорректный (например, http://), функция wp_parse_url() возвращает false. В этом случае в массив $validation[] записывается ошибка (WP_Error), но запись в массив $matches[] не происходит (через continue).

Ниже показали часть уязвимого кода, полный код находится wp-includes/rest-api/class-wp-rest-server.php
foreach ( $batch_request['requests'] as $args ) {
$parsed_url = wp_parse_url( $args['path'] );
if ( false === $parsed_url ) {
$requests[] = new WP_Error( 'parse_path_failed', __( 'Could not parse the path.' ), array( 'status' => 400 ) ); // запись ошибки для http://

continue;
}

$single_request = new WP_REST_Request( $args['method'] ?? 'POST', $parsed_url['path'] );
....

$matches = array();
$validation = array();
$has_error = false;
foreach ( $requests as $single_request ) {
if ( is_wp_error( $single_request ) ) {
$has_error = true;
$validation[] = $single_request;
continue; // пропуск записи в $matches[]
}

Из-за continue массивы $requests и $matches рассинхронизируются по индексам. Это позволяет одному подзапросу получить обработчик, предназначенный для другого.

Сдвиг индексов → Некорректный путь вызывает continue → Массивы $requests и $matches рассинхронизируются → Запросы получают чужие обработчики → Вложенный batch → Запрос /wp/v2/posts выполняется как batch → Внутри снова происходит сдвиг индексов → Запрос к /categories?author_exclude=SLEEP(2) получает обработчик /posts (скриншот) -> SQLi.

Уязвимость SQLi
author_exclude регистрируется как параметр типа array в get_collection_params().
В get_items() он мапится в author_not_in без проверки типа.
Из-за путаницы маршрутов параметр передается как строка.
WP_Query не санитизирует строковые значения. Строка попадает в SQL.

if (is_array($query_vars['author__not_in'])) {
$query_vars['author__not_in'] = array_map('absint', ...); // sanitize
}
$author__not_in = implode(',', (array) $query_vars['author__not_in']);
$where .= " AND post_author NOT IN ($author__not_in) "

🫡 Возможные конечные точки:
Запрос:
– POST /wordpress/batch/v1 + тело запроса
– POST /?rest_route=/batch/v1 + тело запроса
– GET /?_method=POST&rest_route=/batch/v1&validation=normal + тело запроса
SQLi - "path": "/wp/v2/ author_exclude=

Пример одного из возможных запросов — на скриншоте.

🫡 Как защищаться:
1. Обновиться до версии 7.0.2.
2. Использовать WAF/IDS с настроенными правилами от SQLi.
3. Проверить систему на предмет подозрительных php-файлов.
4. Провести аудит запросов, где в качестве конечной точки или значения параметра выступал /batch/v1.
5. Временно ограничить доступ к /batch/v1 из внешней сети.

🫡 Ловите лабораторную — docker-compose.yml с уязвимым wordpress прикреплен к посту.
Запуск docker-compose up.

В AnyDesk нашли уязвимость нулевого дня

Уязвимость CVE-2026-15682 (5.5 Medium) связана с функцией AnyDesk, которая собирает диагностические данные для службы поддержки. Злоумышленник может использовать точку повторного разбора — специальную ссылку в файловой системе Windows — чтобы перенаправить операции записи файлов в другое место.

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

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

#anydesk #уязвимость #cve #zeroday

@ZerodayAlert

Проект GNOME сократит срок раскрытия информации об уязвимостях до 30 дней, начиная с 1 августа. Разработчики ссылаются на растущее число отчётов об уязвимостях, генерируемых искусственным интеллектом.

#ИскИн #разработка #кибербезопасность