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