uz
Feedback
Четыре луча

Четыре луча

Kanalga Telegram’da o‘tish

Облучаем экспертизой Заметки Solar 4RAYS c полей о DFIRMA, TH, OffSec Блог: https://rt-solar.ru/solar-4rays/blog/

Ko'proq ko'rsatish
4 027
Obunachilar
-124 soatlar
+97 kun
+1030 kun

Ma'lumot yuklanmoqda...

Obunachilarni jalb qilish
Sen '26
Sentabr '26
+36
1 kanalda
Avgust '26
+24
1 kanalda
Get PRO
Iyul '26
+34
1 kanalda
Get PRO
Iyun '26
+30
1 kanalda
Get PRO
May '26
+42
0 kanalda
Get PRO
Aprel '26
+72
4 kanalda
Get PRO
Mart '26
+103
4 kanalda
Get PRO
Fevral '26
+85
2 kanalda
Get PRO
Yanvar '26
+97
0 kanalda
Get PRO
Dekabr '25
+70
1 kanalda
Get PRO
Noyabr '25
+720
0 kanalda
Get PRO
Oktabr '25
+308
1 kanalda
Get PRO
Sentabr '25
+301
0 kanalda
Get PRO
Avgust '25
+391
0 kanalda
Get PRO
Iyul '25
+342
7 kanalda
Get PRO
Iyun '25
+201
2 kanalda
Get PRO
May '25
+1 240
1 kanalda
Get PRO
Aprel '25
+377
2 kanalda
Get PRO
Mart '25
+464
17 kanalda
Get PRO
Fevral '25
+191
2 kanalda
Get PRO
Yanvar '25
+111
1 kanalda
Get PRO
Dekabr '24
+115
1 kanalda
Get PRO
Noyabr '24
+646
5 kanalda
Sana
Obunachilarni jalb qilish
Esdaliklar
Kanallar
28 Sentabr+2
27 Sentabr+1
26 Sentabr0
25 Sentabr+1
24 Sentabr+4
23 Sentabr+3
22 Sentabr+2
21 Sentabr+3
20 Sentabr0
19 Sentabr+1
18 Sentabr+3
17 Sentabr+2
16 Sentabr0
15 Sentabr+2
14 Sentabr+1
13 Sentabr0
12 Sentabr+1
11 Sentabr0
10 Sentabr+1
09 Sentabr+3
08 Sentabr0
07 Sentabr0
06 Sentabr0
05 Sentabr+2
04 Sentabr0
03 Sentabr+2
02 Sentabr+1
01 Sentabr+1
Kanal postlari
Встретимся на ZeroNights 2026 ⏰ Уже на следующей неделе, 30 сентября, состоится конференция по практическим аспектам информационной безопасности ZeroNights. У нашей команды на конференции будет свой луна-парк стенд с челленджами и мерчем! Если будете на конференции, обязательно заходите на огонёк, а если соберётесь участвовать в челлендже — присмотритесь внимательнее к файлу, прикреплённому к этому посту… 👀 До встречи в Санкт-Петербурге!

2
👁 Блокчейн и ВПО Использование распределенной инфраструктуры различных криптовалют (от Bitcoin до TON и Polygon) приобретает популярность у вирусописателей разного уровня. Развитие криптовалюты и блокчейн-сетей, поддерживающих смарт-контракты стало новым инструментом в руках атакующих. Мы видим, что злоумышленники постепенно адаптируют этот инструмент для гибкого управления C2-инфраструктурой вредоносного ПО. Еще одним относительно недавним нововведением, заметно поменявшим принципы, по которым устроено современное ВПО, стали децентрализованные DNS- и overlay-сети (например, TON). Злоумышленники теперь могут покупать .ton-домены и использовать их для определения адресов своей инфраструктуры. В некоторых случаях вредоносное ПО реализует даже подключение к самой TON overlay. 💣 Недавно мы обнаружили, что создатели стилера Webrat стали использовать TON DNS. Вредонос научился получать адрес управляющего сервера, используя tonapi. Операторы используют домен .ton для хранения hex-записи строчки IP управляющего сервера. Это затрудняет обнаружение C2-коммуникаций этого ВПО. Подробности мы описали в новой статье у нас в блоге.
1 535
3
💣 Click2Shell Click2Shell — это цепочка уязвимостей в WordPress, которая может привести к удаленному выполнению кода (RCE).
💣 Click2Shell Click2Shell — это цепочка уязвимостей в WordPress, которая может привести к удаленному выполнению кода (RCE). Для успешной атаки злоумышленнику необходимо, чтобы авторизованный администратор открыл специально подготовленную ссылку. 1️⃣ Шаг первый: XSS В ядре WordPress существует уязвимый участок кода: self.view.collection.once( 'query:success', function() { $( 'div[data-slug="' + slug + '"]' ).trigger( 'click' ); }); Этот код позволяет злоумышленнику инициировать установку произвольной темы. Важно, что тема устанавливается без активации и остается неактивной. Параметр slug контролируется злоумышленником. Он получается из аргумента theme в запросе /wp-admin/theme-install.php?theme=THEME_SLUG. Атакующий формирует ссылку вида: /wp-admin/theme-install.php?theme=something_theme"]>>>*/* Вставленная кавычка закрывает селектор атрибута. Дочерние комбинаторы переходят к возвращаемой карточке темы. Завершающий CSS-комментарий нейтрализует фрагмент селектора, который добавляет WordPress. Затем злоумышленник передает эту ссылку администратору. После перехода по ссылке администратором селектор вместо выбора только карточки темы переходит к элементам управления действиями, включая настоящую кнопку «Установить». В результате срабатывает JavaScript-код WordPress, и тема устанавливается автоматически. 2️⃣ Шаг второй: установка произвольной темы Важно, чтобы WordPress мог загрузить functions.php темы во время подготовки предварительного просмотра. Это дает коду темы возможность регистрировать хуки и обработчики, даже если база данных все еще идентифицирует другую тему как активную. Далее нужно выбрать тему, имеющую уязвимость, которую можно поэксплуатировать, например через хуки. Чтобы код темы выполнился, злоумышленнику нужно заставить админа активировать или запустить предпросмотр установленной темы, например через CSRF, фишинг или другую XSS-уязвимость. В обнаруженных эксплойтах фигурирует тема Mobile Repair Zone 2.5.4. Пример RCE можно наблюдать на скриншоте. 👀 Лаба В лабораторной эмуляции есть небольшие сложности. Активная версия Mobile Repair Zone на сегодняшний момент 2.5.5.  поэтому скачиваем: wget https://downloads.wordpress.org/theme/mobile-repair-zone.2.5.4.zip редактируем файл functions.php, так как даже в 2.5.4 есть защита от SSRF-атак, которая помешает сделать локальный запрос.  Меняем: function mobile_repair_zone_plugin_download($url, $path) {     $response = wp_safe_remote_get( $url ); на: function mobile_repair_zone_plugin_download($url, $path) {     $response = wp_remote_get ( $url ); Загружаем плагин руками через webui или через консоль. Далее можно поднимать локальный HTTP и загружать zip-файл с shell-кодом. ✅ Как защищаться: 1. Обновление ядра WordPress. 2. Проверка недавно загруженных тем. 3. Проверка директорий на предмет появления подозрительных файлов. 4. Правила на IDS/WAF, блокирующие запросы с нетипичным slug-значением [^a-zA-Z0-9_-]+
874
4
💣 Ржавый код: почему все переходят на Rust и когда аналитику можно его не реверсить Rust окончательно закрепился в роли главного инструмента для усложнения жизни вирусным аналитикам. Недавно мы столкнулись подтверждением этого тренда: сильно обфусцированным образцом, который при первичном осмотре выглядел как сложная новая вредоносная программа, написанная с нуля на Rust. По характерным признакам мы выявили, что это был знакомый SantaStealer, но слабо верилось, что автор всего за один-два месяца смог полностью его переписать на Rust и настолько тяжело обфусцировать. Да и сама изначальная логика быстрой работы стилера при таком подходе просто ломалась. Реальность оказалась проще: саму малварь никто не переписывал, злоумышленники просто собрали вокруг нее многослойный «бутерброд»: Ядро — классический SantaStealer, заточенный исключительно под быструю кражу данных. Обертка — промежуточная DLL на Rust, маскирующая сигнатуры стилера. Защита — сжатие растовой библиотеки алгоритмом LZMA и финальная упаковка под коммерческий виртуализатор Oreans CodeVirtualizer. Этот случай наглядно иллюстрирует динамику последних лет. Переход малвари на нетипичные компилируемые языки (Rust, Go) наметился еще в районе 2023 года, когда уход от традиционного C/C++ только начинали обсуждать на Reddit и в профильных блогах. Сегодня это мейнстрим. Операторы RansomExx в свое время переписали вымогатель на Rust ради обхода сигнатурных детектов, а авторы бэкдора SysJoker и вовсе свернули кодовые базы на C++ и Go в пользу единого растового билда. Масштаб этой тенденции стал настолько заметным, что этой теме сегодня все чаще посвящают отдельные статьи и аналитические материалы. 💡 Причина такой популярности проста. Злоумышленникам не нужна хваленая безопасность памяти (в малвари повсеместно используют unsafe) и редко критична производительность. Главная цель — намеренное разрушение статического анализа: 1️⃣ Статическая линковка: стандартные библиотеки и рантайм языка намертво зашиваются в бинарник, раздувая его до десятков мегабайт. 2️⃣ Каша в дизассемблере: развитая система типов, сложные абстракции и специфичная обработка паник превращают граф вызовов в IDA Pro или Ghidra в трудночитаемое полотно. 3️⃣ Низкий порог входа: благодаря генеративным нейросетям и публичным шаблонам на GitHub даже начинающим операторам достаточно пары запросов, чтобы собрать рабочий растовый лоадер, завернуть в него чужой стилер и натянуть готовый протектор. Однако Rust и виртуализация бессильны перед динамикой. Как бы глубоко ни прятали логику, процессу все равно нужно взаимодействовать с системой: выделять память, обращаться к файлам браузеров и слать данные на C2. В рантайме такая переусложненная цепочка мгновенно триггерит EDR и песочницы характерными вызовами и другой аномальной активностью. ✅ Как понять, что на реверс Rust-бинарника не стоит тратить время: 1️⃣ В песочнице видны маркеры распаковщика/инжектора. К примеру, если процесс использует VirtualAlloc/NtAllocateVirtualMemory с правами RWX, пишет данные и создает поток — это обычный стейджер. Распутывать растовую инициализацию бессмысленно. В данном случае удобна утилита API Monitor, особенно если полезная нагрузка инжектится через WriteProcessMemory, поскольку программа может сразу перехватить записываемый буфер. 2️⃣ Полезную нагрузку можно забрать из памяти. Снять чистый дамп процесса (через брейкпоинты, pe-sieve, HollowsHunter) получится только в том случае, если под виртуализатором спрятан дроппер, раскручивающий пейлоад в память. Если виртуализирован сам стиллер, сдампить исходный исполняемый код не выйдет — тут придется разбирать байткод ВМ. В нашем случае под защитой был лишь лоадер. 3️⃣ Сетевые и файловые IoC уже зафиксированы. Если инфраструктура C2, извлекаемые пути и ключи реестра перехвачены в динамике, глубокий реверс растовой обертки может не дать ничего нового. Разбирать растовый код до последнего опкода имеет смысл только тогда, когда в него зашита уникальная логика или виртуализирован сам вредоносный функционал. Если же Rust выступает просто упакованным лоадером чужого софта, динамика экономит десятки часов работы.
1 415
5
😳 DFIR diggin’ deeper: неочевидные источники артефактов при расследовании атак Когда стандартный аудит молчит, а инфраструктура уже зашифрована, распутывать инцидент приходится по нетипичным следам. Вот один из примеров. Кейс: Первоначальный доступ через?.. Вводные. Инфраструктура зашифрована. Найдена зараженная система нулевого пациента, но на ней нет внешних сервисов, RDP закрыт, а саму машину перед анализом перезагрузили (цепочки процессов в памяти нет). Зацепка. В журнале трассировки ShutdownPerfDiagLogger.etl (хранит данные о выключении системы) мы обнаружили следы команды реверс-шелла. 👀 Что помогло найти артефакт? С помощью утилиты ETLParser из .etl-файла удалось вытащить Parent PID (ID родительского процесса). Цепочка привела к неожиданному «виновнику» — процесс PostgreSQL. В логах самой СУБД обнаружились: • Типичная RCE-команда через SQL-инъекцию. • Фрагменты эксплойта и следы брутфорса, который шел несколько месяцев. 💡 Финал: откуда пришел атакующий? Поскольку более ранних зараженных машин внутри сети не обнаружили, проверили бэкапы конфигурации шлюза pfSense. Выяснилось, что ранее порт 5432 (PostgreSQL) временно публиковался наружу. Через него злоумышленники пробили базу, получили системные привилегии и начали шифрование. ✅ Главные выводы для форензики: • Не пренебрегайте ETL-журналами Windows — они могут сохранить критические данные (например, Parent PID), которых больше нет ни в одном артефакте после перезагрузки. • Смотрите бэкапы конфигураций сетевых устройств — актуальные настройки могут скрывать следы «временных» брешей, через которые и зашли хакеры. ❤️ А самый главный вывод: копайте глубже! Еще больше примеров неочевидных источников артефактов собрали в новой статье у нас в блоге!
1 572
6
😀 Call for Papers на технострим SOC Forum 2026 еще открыт! Темы: 1️⃣ Offense: актуальные техники атак, этичный хакинг, выявл
😀 Call for Papers на технострим SOC Forum 2026 еще открыт! Темы: 1️⃣ Offense: актуальные техники атак, этичный хакинг, выявление уязвимостей, новые инструменты и наступательные подходы. 2️⃣ Defense: актуальные технологии защиты, обнаружение угроз и реагирование на них, кейсы реальных атак и их разбор, анализ APT-группировок и их инструментов (DFIR, MA, TI, TH, SOC, VM). 3️⃣ Архитектура ИТ и ИБ: построение безопасных систем. 4️⃣ SOC-практикум: для тех, кто хочет обменяться опытом, лайфхаками и рабочими методиками. 😬 В основном на форуме планируют обсуждать ИИ в ИБ. Поэтому если у вас есть что сказать на эту тему — подавайтесь! Тайминг: до 30 минут. Дата и время: 27–28 октября, кластер «Ломоносов». Чтобы подать заявку, выберите трек, зайдите в личный кабинет или зарегистрируйтесь на сайте. Заполните все поля заявки и отправьте ее. Как обычно: чем детальнее описание, тем выше шанс выступить. 📅 Доклады принимаются по 11 сентября включительно. Стать спикером
1 857
7
☀️ Zimbra, все еще скрывающая боль Ранее мы уже рассказывали о расследовании «Zimbra, скрывающая боль». Группировка Shedding Zmiy длительное время имела доступ к почтовой переписке организации, воспользовавшись уязвимостью в популярном почтовом сервере. Судя по всему, что-то похожее происходит вновь: недавно наши сенсоры зафиксировали множество исходящих подключений к серверам gs-netcat с почтовых серверов компаний, в которых ПО Zimbra не обновлялось с 2024 года (!). Всего мы насчитали не менее 67 организаций: • промышленность, производство и инженерия — 18 организаций; • ИТ, телеком и цифровые сервисы — 9; • строительство, недвижимость и строительные материалы — 8; • агропромышленный сектор, производство продуктов и общепит — 8; • транспорт, авиация, логистика и туризм — 7; • розничная торговля и потребительские товары — 5; • медиа и индустрия развлечений — 4; • госсектор, образование и ЖКХ — 3; • здравоохранение — 2; • консалтинг и обслуживание систем безопасности — 2; • поставки нефтепродуктов — 1. Ранее мы встречали gs-netcat в основном в атаках группировок Shedding Zmiy, Lifting Zmiy и Proxy Trickster, но пока у нас нет достаточно данных, чтобы надежно атрибутировать новую волну атак. ✅ Если вы используете Zimbra, примите следующие меры: • проверьте историю исходящих соединений почтового сервера, журналы событий, запущенные процессы и файлы, связанные с gs-netcat. • Обратите внимание на запуск исполняемых файлов из временных и скрытых директорий, переменные GS_ARGS и GSOCKET_ARGS, а также процессы, маскирующиеся под системные. При обнаружении такой активности сохраните артефакты и проведите оценку компрометации всей инфраструктуры. Простого обновления Zimbra или блокировки адресов может оказаться недостаточно, если атакующие уже закрепились на сервере.
2 434
8
💡 Разберёмся с непопулярными артефактами на OffZone 2026 Выбираете, какие выступления посетить на конференции OffZone 2026?
💡 Разберёмся с непопулярными артефактами на OffZone 2026 Выбираете, какие выступления посетить на конференции OffZone 2026? Несём один must-visit! Если вы работаете в цифровой форензике или просто ею интересуетесь, то приходите на доклад нашего эксперта Ивана Сюхина «DFIR, diggin’ deeper: неочевидные источники артефактов в DFIR-расследованиях». Иван расскажет: • что и как добывать из .etl; • почему при наличии времени анализ образов принесет богатые плоды; • какие неочевидные следы атакующих можно найти в error-логах; • чем полезны SSSD-логи... 📅 …И кое-что еще о продвинутых способах цифровой криминалистики. Просыпайтесь в пятницу, 21 августа, пораньше и приходите к 10:00 в Threat Zone!
2 138
9
😀 Admin may cry CVE-2026-41452 — уязвимость, позволяющая перезаписать данные администратора в Krayin CRM ≤2.2.0, ≥2.2.4 Метр
😀 Admin may cry CVE-2026-41452 — уязвимость, позволяющая перезаписать данные администратора в Krayin CRM ≤2.2.0, ≥2.2.4 Метрики: Base Score: 9.8 CRITICAL CWE: CWE-306 Об уязвимости В Krayin CRM используется промежуточное ПО CanInstall для защиты конечных точек установщика, чтобы никто не мог получить к ним доступ после установки системы. Условие проверки для всех конечных точек /install выглядит так: if ($this->isAlreadyInstalled() && ! $request->ajax()) { return redirect()->route('admin.dashboard.index'); } Логика построена на операторе  &&, поэтому защиту можно обойти, если отправить запрос к любой конечной точке /install/ с заголовком X-Requested-With: XMLHttpRequest, который используется в AJAX-запросах. При этом: isAlreadyInstalled() вернет true, так как приложение уже установлено; ! $request->ajax() станет false благодаря добавленному заголовку. В итоге редирект на route('admin.dashboard.index') не сработает. Конечная точка /install/api/admin-config-setup отвечает за настройку учетных данных первого пользователя системы — администратора. Пример эксплойта: POST /install/api/admin-config-setup HTTP/1.1 Host: 192.168.177.165:8021 Content-Type: application/json Accept: application/json X-Requested-With: XMLHttpRequest Content-Length: 69 {"admin":"whatIsIt","email":"AMC@evil.com","password":"WW1337!"} Этот запрос переопределяет учетные данные администратора и дает неавторизованному пользователю доступ к системе с правами администратора. Важно! Это лишь один из возможных векторов атаки. Уязвимость затрагивает весь маршрут /install. Лаба: sudo docker pull webkul/krayin:2.2.0 sudo docker run -p 8021:80 --name krayin-container webkul/krayin:2.2.0 Логин/Пароль: admin@example.com / admin123 ✅ Как защититься: 1) обновиться до актуальной версии; 2) проверить логи на наличие запросов к /install с заголовком X-Requested-With: XMLHttpRequest; 3) ограничить доступ к /install из внешней сети интернет с помощью правил WAF или IDS.
1 904
10
💣 Уязвимости в средствах AI-автоматизации Средства AI-автоматизации всё активнее используются для работы с корпоративными да
💣 Уязвимости в средствах AI-автоматизации Средства AI-автоматизации всё активнее используются для работы с корпоративными данными, API, файловыми системами и другими элементами инфраструктуры. Вместе с расширением их возможностей увеличивается и потенциальная поверхность атаки. В новой статье рассматриваем характерные уязвимости современных средств AI-автоматизации и основные связанные с ними риски. На примерах n8n, OpenClaw, Claude Code, Langflow и Flowise разбираем типовые уязвимости и сценарии атак, а также приводим рекомендации, которые помогут снизить риски при эксплуатации таких решений. 👽 Подробнее читать здесь.
1 839
11
😬 Полиморфизм как сервис и код «на вайбе»: что происходит с современной малварью? Главный тренд последних лет в кибербезопасности — критическое падение порога входа. Доступность специализированных моделей (DarkLLM) привела к появлению vibeware — софта, создаваемого буквально по одному текстовому промпту. Злоумышленникам больше не нужно писать один идеальный бэкдор: проще штамповать тысячи дешевых мутаций под конкретную ОС или платформу. Разобрали на пальцах и примерах из практики: 1️⃣ Как ИИ-код выдает себя излишней «вежливостью», странными эмодзи в консоли и стерильной архитектурой. 2️⃣ Почему C2-трафик, тонущий в обычных обращениях к SaaS-платформам, обходит сетевые фильтры. 3️⃣ Что делать защитникам, когда форма файла больше ничего не говорит об угрозе, а фокус смещается на поведенческий анализ. Полный разбор в новой статье.
2 260
12
👀 Иногда npm install — это начало атаки Вредоносный файл не обязательно выглядит как странный архив с названием virus_final.exe или фишинговое письмо, пришедшее вам на почту. Бывает, что это обычная библиотека, SDK, плагин или консольная утилита, которую разработчик устанавливает привычной командой npm install или pip install. Например, что подозрительного в таком package.json? "scripts": { "fmt": "prettier --write **/*.js", "fmt:check": "prettier --check **/*.js", "postinstall": "node ./install.js", "preinstall": "node setup_bun.js" }, "artifactDownloadUrl": "https://github.com/PostHog/posthog/releases/download/posthog-cli-v0.5.14", "bin": { "posthog-cli": "run-posthog-cli.js" } Неискушенный читатель подумает, что это обычный cli-проект, но именно такой preinstall в одном из пакетов начнёт масштабную supply-chain-кампанию — Shai-Hulud 2.0. Злоумышленники скомпрометировали аккаунты мейнтейнеров и опубликовали троянизированные версии популярных npm-пакетов. Вредоносный код запускался автоматически еще до завершения установки, собирал секреты разработчиков, токены GitHub, npm и облачных сервисов, а затем использовал их для дальнейшего распространения атаки. В результате были затронуты сотни пакетов и тысячи репозиториев. Мы проанализировали сотни тысяч пакетов из npm и PyPI. Десятки тысяч образцов оказались вредоносными или подозрительными. Самая распространенная техника — запуск кода прямо во время установки зависимости. В новой статье собрали большой каталог реальных примеров из npm и PyPI, разобрали повторяющиеся техники и показали, на какие комбинации признаков стоит писать правила детекта. Читайте полный обзор open-source-вредоносов 🫡
2 297
13
wp2shell — разбираем от и до. Это цепочка уязвимостей, которая состоит из таких элементов: 📍 CVE-2026-63030 — уязвимость пут
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/<API> author_exclude=<SQLi> Пример одного из возможных запросов — на скриншоте. 🫡 Как защищаться: 1. Обновиться до версии 7.0.2. 2. Использовать WAF/IDS с настроенными правилами от SQLi. 3. Проверить систему на предмет подозрительных php-файлов. 4. Провести аудит запросов, где в качестве конечной точки или значения параметра выступал /batch/v1. 5. Временно ограничить доступ к /batch/v1 из внешней сети. 🫡 Ловите лабораторную — docker-compose.yml с уязвимым wordpress прикреплен к посту. Запуск docker-compose up.
1 838
14
🎣 По README встречают, по малвари провожают: как раскусить фейковый репозиторий за 10 секунд Злоумышленники вовсю паразитируют на теме блокировок и массовом поиске способов их обхода. Особенно достается популярному локальному tg-ws-proxy и аналогам. В некоторых поисковиках, например Яндексе, оригинальные ссылки временно удаляются и на самом верху выдачи образуется вакуум. Его моментально заполняют свежие вредоносные клоны, которые не успели попасть в бан-листы. 💡 Отдельная ловушка — сторонние зеркала GitHub. Пользователи доверяют им по инерции, но под капотом скачиваемого архива вполне может оказаться вредоносное ПО, которое в свою очередь умеет подчистую пылесосить не только сессии ваших браузеров, но и собирать важные файлы по конкретным расширениям. Внешне подделка выглядит органично: мошенники подчистую копируют оформление README.md, сохраняют оригинальную верстку и даже реквизиты для донатов настоящему автору. Расчет идет исключительно на невнимательность и машинальные действия. Чек-лист: 4 главных маркера фейка, которые выдадут его целиком и полностью 1️⃣ Возраст аккаунта: профиль «разработчика» обычно зарегистрирован пару недель назад. 2️⃣ История коммитов: вместо нормальной истории изменений весь код заливается за один раз через веб-интерфейс с унылой заглушкой Add files via upload. 3️⃣ Мертвая социальная активность: у клонов на счетчиках звезд и форков горят нули, а вкладка Issues (проблемы/обсуждения) часто отключена. 4️⃣ Инструкции: в README прямым текстом просят отключить антивирус или добавить папку в исключения Windows Defender, списывая на «ложное срабатывание из-за функционала». Никогда так не делайте, если не провели аудит кода лично. Подробный разбор этой схемы и полный чек-лист безопасности читайте в нашей новой статье 🫡
1 652
15
Финальный опрос: какой профиль — не фейк?
1 426
16
А тут что скажете?+2
А тут что скажете?
1 430
17
Вопрос тот же: какой репозиторий настоящий?
1 429
18
Так, это было слишком легко. Давайте чуть-чуть посложнее — новые скриншоты. Отвечайте в опросе ниже.+1
Так, это было слишком легко. Давайте чуть-чуть посложнее — новые скриншоты. Отвечайте в опросе ниже.
1 393
19
Какой из репозиториев выше настоящий?
1 589
20
Предлагаем потренироваться — попробуйте раскусить фейковые репозитории и найти настоящие. Начнем прямо сейчас: ловите скриншо+1
Предлагаем потренироваться — попробуйте раскусить фейковые репозитории и найти настоящие. Начнем прямо сейчас: ловите скриншоты из первого задания 🫡
1 780