3side кибербезопасности

Обновите PHP - это срочно

Сегодня были выпущенны экстренные обновления для двух критических уязвимостей PHP (CVE-2026-109618 и CVE-2026-109619).

Если вы используете этот язык на вашем сайте, значит вам нужно срочно поставить обновления!
Эты дыры будут использовать в ближайшие часы по всему Интернету.

Безопасные версии:
• 8.5.12
• 8.4.27
• 8.3.36
• 8.2.35

Все версии ниже указанных - уязвимы, если об этом напрямую не указано напрямую вашим вендором.
После обновления до указанных версий обязательно перезапустите PHP-FPM.

Если PHP установлен из репозитория дистрибутива (Ubuntu, Debian и иные), номер безопасной версии может отличаться, ориентируйтесь на обновление пакета безопасности от Ubuntu, Debian или другого дистрибутива.

Как проверить, что из дистрибутива поставилась защищенная версия?
Пример команды для PHP8.5:
apt download php8.5-common
dpkg-deb --fsys-tarfile php8.5-common_*.deb \
| tar -xO ./usr/share/doc/php8.5-common/changelog.Debian.gz \
| zcat | head -80

Если в чейнжлоге пишет про уязвимости CVE-2026-109618 и CVE-2026-109619, то все ок, ставим последнюю версию по чейнжлогу, например так:

sudo apt install -y php8.5 php8.5-cli php8.5-fpm php8.5-common \
php8.5-mysql php8.5-curl php8.5-mbstring php8.5-xml php8.5-zip \
php8.5-gd php8.5-intl php8.5-bcmath

Проверяем, что встала последняя версия, пример:
dpkg -l | grep php8.5-common # должно быть 8.5.4-0ubuntu1.5

Если обновиться сразу не получается - это ОЧЕНЬ плохо, но
• Отключите upload_progress. Задайте session.upload_progress.enabled = 0 в php.ini или в настройках пула FPM, через ini_set() и .user.ini это не сработает. Затем перезапустите все воркеры PHP-FPM.
• Ограничьте размер запросов. Если загрузка файлов не нужна, задайте post_max_size = 8M , если нужна, то 32M , а upload_max_filesize сделайте меньше post_max_size .
• На PHP 8.5 дополнительно задайте fatal_error_backtraces = 0 .

Эти меры снижают риск, но не защищают полностью, поэтому обновиться все равно нужно как можно быстрее.

P.S. Я по одному из наших проектов проверял версию по будильнику из такси, раздавая себе интернет с телефона. Так себе удобство, но как иначе? Зато я уверен.

"США читают ваши ДТП": разбираем новость Mash

ТГ-канал Mash написал, что данные о российских машинах, авариях, штрафах и владельцах, включая чиновников и военных, через компанию Audatex доступны американскому фонду Vista Equity Partners!
Сильное заявление, мы проверили по открытым данным и реестрам.

Цепочка владения полностью подтверждена
По ЕГРЮЛ единственный участник ООО "Аудатэкс" - голландская Audatex Network Services Netherlands B.V. Обе компании перечислены среди дочерних обществ американской группы Solera в её проспекте IPO 2024 года в SEC. Solera была куплена в 2016 году фондом Vista Equity Partners.

Через калькуляторы "Аудатэкса" страховщики, СТО и эксперты считают ремонт по ОСАГО и КАСКО. А платный сервис AudaHistory за 160 рублей показывает по VIN историю расчётов ремонта с 2005 года.

Что не подтверждено
"Данные МВД и ФССП уходят в Audatex". Доказательств этому нет и само собой ФССП заявляет, что Audatex не подключён к межведомственному обмену.
Это максимально логично, ведь российское ООО - разработчик ПО, а не страховщик или госорган.

"Легально трансгранично передаёт". В реестре операторов ПДн РКН у "Аудатэкс" все чисто, никакой трансграничной передачи нет, базы в России. Но насколько это правда, а не ширма? Неизвестно.

Данные текут и в обход
ДТП с 2015 года, ограничения и розыск по VIN любой может посмотреть на сайте Госавтоинспекции. Для этого не нужны ни фонд, ни ЦРУ.

Активно торгуют базами страховщиков на форумах, они появляются в ботах-пробива, и даже в специализированных сервисах для автоподборщиков.

В чем еще может быть проблема
Юрисдикция. Американский CLOUD Act позволяет требовать данные у компаний под контролем США, даже если сервер стоит в другой стране. Локализация решает, где лежат данные, но не решает, кто владеет компанией и данными. То есть фактически данные "защищены" и в "суверенном ЦОД", но в любой момент могут быть запрошены в нарушение 152-ФЗ.

Зависимость от вендора. Все споры по ОСАГО держатся на одном иностранном поставщике! Причем на фактически зарубежном, звучит как проблема.

Итог - Mash прав
Цепочка юрлиц до владения США подтверждается документами.

Тезис «США имеют доступ» и да, и нет, фактов передачи мы не нашли, "на бумаге" этого нет, если не нарушается 152-ФЗ, а ведь у нас же совсем его никто не нарушает, верно?

А вот правильнный и важный вопрос "кто в итоге контролирует данные российского ООО"!

Американцы могут по закону запросить все данные!

А сколько у нас еще таких "наших" компаний, данные которых могут в любой момент запросить из США из наших суверенных ЦОДов?

FirstVDS взломан

Но не по их вине. Оказывается, в современной панели управления хостингом vmmanager 6 была критическая и до жути простая уязвимость!

Она позволяла через ссылку на iso-образ передать еще и команду, которая немедленно выполнялась от имени root на стороне сервера панели.

То есть любой клиент мог в 1 строчку захватить сервер хостера!

Как уязвимость не была найдена ранее в столь популярном и критичном продукте? Неизвестно.

По сообщениям FirstVDS злоумышленники массово собирали пароли, ключи и токены со всех доступных им серверов, хостер уже разослал инструкции потенциально пострадавшим.

Всем остальным хостерам, использующим данную панель, срочно проверить себя на следы компрометации.

Боты пробива — ветряные мельницы

Знаете, всё больше вижу активности вокруг борьбы с ботами пробива, но что произойдёт, если они окончательно уйдут в подполье?

Это урежет лишь массовое использование утечек! У всех, кто их использовал во зло, доступ останется.
Фактически это лишь скроет вершину айсберга и усложнит мониторинг с благими целями.

Конечно, основная проблема тут — источники. Боты ведь только агрегаторы, строятся они на утекших базах. А что у нас утекло и сейчас присутствует на форумах? Кое‑что гораздо страшнее «Додо Пиццы»:

* База «Роспаспорта»
Там 1,2+ млрд строк с данными на декабрь 2021 года. Говорят, там суммарно данные примерно 160 млн граждан России, а именно — документы с фотографиями и адреса!

* Объединённая база «Туроператоры»
Там 126+ млн строк с данными на июнь 2026 года. Говорят, утекло из fstravel.com, tui.ru и samo.ru. Данные о пассажирах, их заказах, визах и подобное.

Если бы подобных утечек не было, то и боты были бы не нужны. Оборотные штрафы введены, но они так и не применяются. А

А уж кто ответит за массовые утечки государственных структур? Ведь именно они опаснее всего!

Подтверждено: вас можно взломать через рекламный баннер. Даже без клика по нему.

Мы тут много писали про израильский "наступательный" кибербез — например, как одна из местных компаний (умышленно или нет) засветила интерфейс управления системой для взлома мессенджеров. Теперь есть история еще фееричнее.

Исследовали из канадской Citizen Lab вчера еще раз технически доказали: шпионское ПО можно доставлять через обычную таргетированную рекламу. Технику назвали AdFection, работает это так: израильская компания Discover-Tech выдавала себя за провайдера интернет-рекламы и покупала показы в Google, Yandex и других сетях. Баннер выглядел совершенно безобидно, но в момент показа незаметно сообщал серверу, кто его видит.

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

Именно так взломали как минимум 45 устройств сотрудников телеканала Al Jazeera, а в реальности - почти наверняка и множество других. За четыре месяца компания попыталась показать свою рекламу почти 4 миллиарда раз. Баннеры появлялись в Viber, Duolingo, Truecaller и на 120 тысячах сайтов, в том числе в сетях НАТО, Еврокомиссии, министерств обороны разных стран и российских госорганов.

Вишенка на торте: Google годами держал эту компанию в списке «сертифицированных» партнёров.

Хотите знать больше?

Традиционно, если этот пост наберет 50 реакций, мы детально и подробно опишем, как все это произошло!

Народное голосование

Всем привет, тут началось народное голосование премии:
«Новая элита кибербеза»

Я участвую в номинации ИБ-предприниматель, по результатам народного голосования сформируют шорт-лист, а далее будет оценка жюри, поэтому буду рад поддержке!

Правда нас, ИБ-предпринимателей до 33 лет включительно всего трое, поэтому интересно, как будут выбирать?

Голосовать тут:
https://secpost.ru/rating-eleet

Datasuckers: ломали тех, кто ломается

Была такая группировка в далёком 2011 году — называлась LulzSec. Пора её вспомнить, уж очень похожая вышла ситуация.

Девиз LulzSec был прост: «Мы проорали с вашей безопасности».

Они ломали всех, до кого могли дотянуться, достаточно простыми методами и очень громко об этом заявляли, обязательно публикуя материалы. Целились именно в крупные и известные компании. Тогда СМИ писали о них как о гениях и самой крутой группировке, хотя на деле они лишь собирали низковисящие фрукты.

И вот новоиспечённая группа Datasuckers делала ровным счётом то же самое.

Буквально недавно они взломали TezTour, Dodo Pizza и украинский ATBmarket. После взломов они активно пиарились, общались с аудиторией в комментариях в своём ТГ-канале, выкладывали материалы, включая отчёты по взлому!

Что мы увидели в отчетах?

Работу прокачанной нейронки с поддержкой специалиста уровня junior+ / middle-pentester.

Никаких уязвимостей нулевого дня, редких техник, непубличных эксплойтов, кастомного вредоносного ПО. Буквально, любой пентестер мог это повторить, а при должной удаче и студент с хорошей нейронкой.

По поводу того, где живут участники группы, тут внутри нашей команды мнение разделилось - версии были разные (Украина, Европа, иные страны). Но всегда мелькало и мнение «они просто не думают о последствиях» и могут жить в зоне досягаемости Российского правосудия, что в итоге и оправдалось!

СМИ пишут, что первого их участника уже задержали. Им оказался 19-летний парень из Барнаула. Как именно его нашли - подробно не пишут, но кажется, у него в какой-то момент засветился домашний IP =)

Остальные участники тоже установлены, пишут о гражданах Казахстана и Беларуси.

Вспоминаем и взлом Гемотеста, где злоумышленник транслировал весь взлом в свой личный ТГ-канал, где не скрывал свою личность, буквально записывая кружочки!

Итого

Что LulzSec, что взломщик Гемотеста, что Datasuckers - получили свою минуту славы за взлом того, что получилось сломать, и были арестованы.

Стоило того?

P.S. Пост перевыложили, так как Markdown оказывается на разных устройствах выглядит по разному и поэтому текст с ним получается уродлив! Пока от экспериментов с ним откажемся.

❤️ Что зарезервировать, чтобы пережить потерю ЦОДа: памятка

За неделю из строя вышли три площадки Яндекса: Сасово, Калуга и Владимир. Yandex Cloud перешёл в аварийный режим. К сожалению, быстро восстановить работу проекта в такой ситуации помогает только наличие резерва и/или бэкапов у другого провайдера.
Мы подготовили для вас памятку: Что можно и нужно проверить сейчас, чтобы в случае подобного форс-мажора иметь возможность быстрого восстановление проекта.

Бэкапы должны храниться у другого провайдера или на собственном оборудовании вне основного дата-центра.

➡️Что обязательно нужно сохранить

1. Базы данных

• Полные бэкапы PostgreSQL, MySQL и других используемых СУБД.
• Журналы транзакций (WAL, binlog), если важно восстановление на конкретный момент.
• Конфигурации СУБД, роли, права и расширения.
• Для критичных систем в иделе иметь реплику у независимого провайдера.

Важно: автобэкапы managed-баз не заменяют независимую копию.

2. Файлы и объектные хранилища

• Пользовательские загрузки, документы, медиафайлы.
• Содержимое S3-бакетов и файловых хранилищ.
• Данные с постоянных дисков, которые нельзя воссоздать автоматически.

На резервном хранилище включите версионирование и, по возможности, защиту от удаления (Object Lock).

3. Код и CI/CD

• Git-репозитории, включая историю и теги.
• Конфигурации пайплайнов.
• Настройки CI/CD, раннеров и интеграций.
• Необходимые переменные и секреты — в отдельном защищённом хранилище.

4. Docker-образы и зависимости

• Все образы, которые сейчас используются в production, с точными версиями или digest.
• Собственные базовые образы.
• Критичные пакеты и зависимости, если их повторная загрузка не гарантирована.

5. Конфигурации инфраструктуры

• Terraform, Ansible, Helm charts и values.
• Terraform state.
• Конфигурации Nginx, HAProxy, приложений и балансировщиков.
• Сетевые настройки, правила firewall, маршрутизацию.

6. Секреты, ключи и сертификаты

• Секреты приложений и сервисных аккаунтов.
• Ключи шифрования резервных копий.
• TLS-сертификаты или механизм их автоматического перевыпуска.

7. Очереди, кеши и другие stateful-сервисы

• RabbitMQ, Kafka: конфигурации, топологию, права и критичные данные, если их необходимо сохранить.
• Redis: настройки и резервные копии, если он используется не только как кеш.
• Поисковые индексы и другие хранилища, которые невозможно быстро пересоздать.

8. Внешние интеграции и сетевые соединения

Составьте и сохраните вне основной инфраструктуры список внешних сервисов, с которыми взаимодействуют ваши приложения. С кем интегрированы: внешние API, платёжные системы, партнёры, SaaS-сервисы и другие системы.

Для каждой интеграции зафиксируйте:

- Адреса, порты, протоколы и направления соединений.
- Используемые IP-адреса и правила whitelist.
- VPN-туннели, приватные соединения и маршруты.
- Конфигурации подключений и необходимые сертификаты.
- Контакты технических специалистов и ответственных со стороны партнёров.

Отдельно: если у вас Kubernetes

Для восстановления Kubernetes недостаточно сохранить манифесты приложений.

Проверьте, что у вас есть:

• Описание инфраструктуры: Terraform или другие инструменты для создания нового кластера, сетей, узлов и балансировщиков.
• Бэкапы Persistent Volumes: независимые копии данных, а не только снапшоты дисков текущего облака.
• План развёртывания: порядок восстановления системных компонентов, операторов, баз данных и приложений.

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

➡️Что сделать прямо сейчас, если времени мало?

1. Выгрузить актуальные резервные копии баз и критичных файлов на независимую площадку.
2. Сохранить production-образы и убедиться, что доступны исходный код и конфигурации.
3. Проверить доступность секретов, ключей шифрования, DNS и административных учётных записей.
4. Зафиксировать порядок восстановления и ответственных.
5. Проверить восстановление хотя бы одного критичного сервиса из резервной копии.

Третий удар, массовая миграция, фатальные ошибки.

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

Самая частая из них — опасные настройки фаерволов! При экстренной миграции велик соблазн настроить «так, чтобы как можно быстрее заработало». Но вместе с трафиком от ваших пользователей к вам зайдут и злоумышленники.

Это может стать вторым эффектом от ударов: массовый взлом компаний из‑за экстренной миграции. А дальше — слив данных, шифрование и остановка работы на ещё больший срок.

Будьте осторожны, держите безопасность в фокусе. Если нужно, мы можем помочь и оперативно проверить вашу новую инфраструктуру.

P. S. Последний удар задел частично и нас, но далеко не так серьёзно, как множество бизнесов по всей России.

Рунет: чем централизованнее, тем уязвимее.

Удар по дата‑центру Яндекса побудил многих «околовоенных» экспертов высказаться на темы, близкие к кибербезу.
Давайте мы, как профильный канал, тоже прокомментируем эту тему.

Все мы помним, что Рунет у нас уже много лет суверенен, независим и достаточно централизован.
Он буквально завязан на несколько ключевых провайдеров и их дата‑центры.

Проект централизации первично децентрализованной технологии «Интернет» выполнялся по различным причинам — их мы обсуждать в этом посте не будем. Но фактически успех этого проекта привёл к тому, что буквально на около десятка дата‑центров в европейской части России завязано функционирование примерно всего Рунета.

Поэтому, господа военные эксперты: может, суммарно дата‑центров у нас и сотни по всей стране, может, и очень крупных много. Но вывести из строя нужно гораздо меньше, и они вовсе не на Камчатке. Их нужно питать, обслуживать, обеспечивать логистикой. Они все в полётной доступности средств поражения по вполне прагматичным причинам.

Могут ли облачные провайдеры быстренько «переехать» в безопасные дружественные страны?

Конечно, нет. 152‑ФЗ («О персональных данных») жёстко ограничивает в этом, а 187‑ФЗ (регулирующий безопасность критической информационной инфраструктуры) вводит прямо запрет на зарубежные облака и SaaS‑сервисы.

Централизация тут однозначно стреляет нам в ногу: в плане физического поражения инфраструктуры мы стали уязвимее.

В рамках дейтинга будет доступна легализованная услуга "Глаз Государства"!
😂

Клуб ИТ-лидеров Global CIO приглашает вас принять участие в живом разговоре «После атаки: как сохранить работу бизнеса, когда ИТ-инфраструктура частично недоступна» 🗓 9 октября | 11:00–12:30 | онлайн Ламповый формат для своих, без рекламы. Киберустойчивость…

«Может ли взлом быть госизменой?»

Это не тема нашей лекции. Это запрос, который военный связист армии США вбил в Google. Теперь у него будет почти шесть лет, чтобы подумать над ответ.

Что известно?
— Кэмерон Вагениус, 21 год, связист армии США, служил на базе в Южной Корее. В сети — kiberphant0m.
— С апреля 2023 по декабрь 2024 вместе с двумя подельниками взламывал американские технологические и телеком-компании. Жертв минимум десять, среди них AT&T и Verizon. Это часть той самой волны взломов через облако Snowflake, где пострадало больше 165 организаций.
— Данные качали и шантажировали владельцев: заплатите, или выложим на BreachForums и XSS. Всего пытались выбить минимум миллион долларов.
— Задержали его в декабре 2024 в Техасе, рядом с армейской базой. Вину признал. Приговор: 70 месяцев тюрьмы и $294 978 компенсации.

А теперь лучшее из материалов обвинения.
Почти весь ноябрь 2024 он переписывался с адресом, который считал почтой иностранной разведки, и предлагал ей купить украденное. В октябре гуглил «куда дезертировать из армии, чтобы меня не выдали», «американские военные, перебежавшие в Россию» и адрес посольства России в Вашингтоне. Сразу после переписки с «разведкой» появился тот самый запрос про госизмену.

А ещё в ноябре 2024-го, сразу после ареста подельника, он выложил на хакерском форуме «журналы звонков» Трампа и Харрис из AT&T. Не записи разговоров, а кто кому и когда звонил. Были ли они настоящими, так и не подтвердилось.

Армейский связист гуглил план побега от американского правительства в американском Google. Это не opsec, это явка с повинной в рассрочку.

Как ломали?
Никаких zero-day и голливудских сцен. Пароли подбирали перебором по SSH: инструмент для этого Вагениус сам помогал писать. Вся волна Snowflake держалась на украденных учётках к облачным хранилищам, где не было второго фактора. Ни одна из этих компаний не проиграла гениям. Они проиграли перебору паролей и отсутствию MFA.

Что делать?
Включить второй фактор везде, куда можно войти из интернета. Одна эта мера сорвала бы всю схему.

Совместный проект с Ингосстрахом — финалист премии "За вклад в безопасность цифрового будущего"

Наш совместный проект с Ингосстрахом — Кибер-Инго Смарт — стал финалистом в номинации "Лучший проект – сервисы цифрового будущего". Хотим сказать большое спасибо коллегам из Ингоса что поверили в наш общий продукт. Будем делать его еще лучше.

А пока — новый AI-SOC на ИИ-агентах активно пилотируется в нескольких компаниях, мы дорабатываем его. Все идет хорошо, посмотрим что получится на выходе.

Но в любом случае приятно.

Готов ли российский рынок к "дешевым" кибератакам?

Тут на Forbes вышел прекрасный https://www.forbes.ru/mneniya/565994-smesenie-fokusa-kak-zasisat-biznes-v-epohu-desevyh-kiberatak от Алексея Новикова из ПТ. Удивительно — там написано почти все то, о чем мы говорили с начала этого года. Даже на наше исследование ссылаются, что довольно мило. В общем мы согласны почти со всем — кроме ... вывода.

Шикарный технарский обзор на технологию AdInt, я о ней еще постараюсь рассказать на паре конф с упором на практику операторов связи.