FirstVDS взломан

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

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

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

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

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

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

"США читают ваши ДТП": разбираем новость 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-ФЗ, а ведь у нас же совсем его никто не нарушает, верно?

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

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

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

Обновите 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. Я по одному из наших проектов проверял версию по будильнику из такси, раздавая себе интернет с телефона. Так себе удобство, но как иначе? Зато я уверен.

Gitlab - тоже обновлять и срочно

Ночь будет веселой!
Еще один крит уже с оценкой 10.0 в GitLab CVE-2026-110264, выполнение кода без условий и очень просто.

SOC Forum 2026 изнутри

28 октября во второй день мероприятия я присоединюсь к редакции «Киберболоида» в кластере «Ломоносов».

Буду ходить по интересным секциям, ловить интересных спикеров, и напишу для Киберболоида пару обзоров, обязательно поделюсь инсайтами! Возможно даже что-то снимем)

Упор сделаю на визионерскую составляющую и будущее кибербеза.

Также Киберболоид мне обещали показать и дать потыкать их новый дешборд киберугроз, обязательно посмотрю, оценю и покажу!

Ловите меня у стенда редакции, буду рад пообщаться лично)

Антон Бочкарев

Папка освещения SOC-форума

Завтра стартует форум, послезавтра на нем буду я.
А чтоб точно ничего интересного не пропустить, Киберболоид собирает папку каналов, которые будут освещать мероприятие!

Подписывайтесь)
https://t.me/addlist/MxpxSuzywc9mYWRi

Итак, Телеграм весной отбрехались, что уязвимости в стикерах нет (твердо и четко)

Но кажется подьехал долгожданный, но наглядный ответ от исследователя!

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

Читать анонс доклада тут:
https://www.offensivecon.jp/speakers/2026/saifeldeen-aziz.html

Перевод на русский анонса:

В начале этого года компания ZDI обнаружила критическую уязвимость в Telegram с первоначальным показателем CVSS 9,8, который позже был снижен до 7,0. В Telegram утверждали, что меры по устранению уязвимостей на стороне сервера сделали уязвимый код на стороне клиента недоступным. В этом докладе мы представляем результаты нашего независимого годичного исследования Telegram, показывающие, что это предположение неверно. В докладе рассказывается о множестве новых уязвимостей в Telegram, которые можно использовать без дополнительных действий, о множестве способов обхода мер защиты на стороне сервера и клиента в Telegram, а также о примитивах эксплойтов, которые мы разработали.
Мы начали с фаззинга rlottie, библиотеки для рендеринга анимированных стикеров в Telegram, с помощью больших языковых моделей, и обнаружили множество уязвимостей, связанных с повреждением памяти, которые затрагивают клиенты Telegram на iOS, Android и ПК. Неожиданностью стали не только сами ошибки, но и то, насколько сильно модель рисков Telegram зависела от защиты от вредоносных стикеров с помощью проверки на стороне сервера. Затем мы показали, как обнаружили отдельные логические уязвимости в процессах доставки и проверки стикеров в Telegram, и объединили их в цепочку, превратив предположительно недоступную поверхность атаки rlottie в благодатную почву для поиска уязвимостей.
Наконец, мы применили эти уязвимости к Telegram для iOS, чтобы добиться выполнения кода, и изучили ограничения получившегося эксплойта. Даже после того, как мы сообщили о своих выводах, Telegram продолжает полагаться в основном на меры по ограничению доступа, в то время как уязвимый код рендеринга по-прежнему используется в официальных клиентах. Мы оставляем читателей с непростым вопросом: следует ли считать эту модель — возможность нулевого клика, полностью контролируемую поставщиком защищенных сообщений, — мерой по смягчению последствий, архитектурным риском или чем-то вроде бэкдора?

Обновляемая и агрегированная статистика по подтвержденным угрозам от Solar!
Бесплатно, пользуйтесь)

https://kiberboloid.ru/dashboard/

Binance и Polymarket взломаны

Кажется этот день станет по настоящему черным для рынка криптовалют.
На момент написания поста с криптобиржи Binance увели более $3,5 млрд, и появились первые подтверждения их взлома. Правда пока отрицают ущерб средствам пользователей, хотя что еще может говорить пресс-служба в такой ситуации?

Параллельно приостановили платежи Polymarket, их взломали из-за атаки на цепочку поставок. Об ущербе пока неизвестно.

Крипторынок уже реагирует и стоимость валют идет вниз.

С интересом ждем возможной аттрибуции злоумышленников и отчета о расследовании после.

Толерантность к чужим взломам

Знаете за сегодня на звонках меня трижды спросили, "у вас наверное заказов то прибавилось".
По мнению моих собеседников на это должно напрямую влиять число последних известных взломов.
А их было много:
- Binance
- Росстат
- Система оповещений в экстренных ситуациях в 2х странах
- Хостинг Beget
- Polymarket
- Биллборды в Египте, демонстрирующие контент 18+

И это только известные случаи за последнюю неделю!

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

Именно поэтому мы никогда не "торговали страхами", как многие коллеги по рыку. А рассказывали честно и обучали.
Сознательные заказчики всегда возвращаются к нам, а паникеры, то есть то нет.

Про инференс и ответственность

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

Первое — это классическая ИБ, пусть с использованием ИИ (как 4sec и множество других продуктов), то есть мы делаем принципиально все то же самое, просто другими методами, на другом технологическом стеке, с другой архитектурой, ML и прочим.

А вторая — это непосредственно безопасность ИИ, и это просто другой мир, и мы вообще не уверены, что это "кибербез" в привычном нам понимании, это именно "безопасность ИИ".

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

А есть еще другой вопрос — кто отвечает за проблемы с ИИ. Вендор ИИ? Очевидно, нет, причем вне зависимости от страны происхождения, это не вопрос "суверенного" ИИ. Пользователь? Кажется, да, но это ломает привычную историю с перекладыванием ответственности.

В общем, чем дальше, тем больше будет проблем.

Sshhole: 10 лет root принимал ЛЮБОЙ пароль длиннее 256 символов

Что известно?
Исследователь ozgun обнаружил, что в OpenSSH на musl-системах аккаунты, у которых в /etc/shadow стоит * (то есть вход по паролю для них запрещён) принимают ЛЮБОЙ пароль длиной длинее 256 символов!

Уязвимы:
Alpine Linux, OpenWrt, Buildroot, Yocto и Docker-образы на их базе.

Условия уязвимости?
sshd собран без PAM (в Alpine это по умолчанию), включён вход по паролю, есть аккаунт с * и хотя бы один аккаунт с реальным паролем.

Особенно весело в официальных облачных образах Alpine для AWS и Azure: там дефолтный пользователь alpine — с * в shadow и беспарольным doas. То есть «любой пароль» — это сразу права root!

Если у вас другие линуксы?
Debian, Ubuntu, Fedora и всё на glibc вы в безопасности.
Как и те, кто ходит через PAM, использует Dropbear или OpenBSD.

Как так вышло?
Цепочка из трёх фиксов иных проблем, создали такую ситуацию.

Почему десять лет никто не замечал?
Классика - дыра живёт на стыке двух компонентов, за которые отвечают разные группы исследователей.

Что делать?
- Обновить OpenSSH до 10.6p2. На Alpine: apk upgrade openssh.
- Не можете обновиться прямо сейчас? Тогда выключите парольную аутентификацию: PasswordAuthentication no, перезапуск sshd.
- Проверьте логи: успешный вход по паролю для аккаунта, у которого пароля нет и быть не должно, гарантированный признак взлома!

Отдельная ирония для любителей «зачем обновляться, и так работает».
Массовым баг стал в 2022-м, когда Alpine 3.16 перевёл root с "!" на "*", чиня совсем другую уязвимость, CVE-2019-5021, где у root в Docker-образах пароля вообще не было.

Исправили пустой пароль - получили любой пароль. Патчинг - это штука тонкая)

Подробнее: sshhole.com