Взлом MAX оказался фейком: в мессенджере опровергли утечку данных

Взлом MAX оказался фейком: в мессенджере опровергли утечку данных

Взлом MAX оказался фейком: в мессенджере опровергли утечку данных

История о «полном взломе» национального мессенджера MAX оказалась фейком. Информацию, которая накануне разошлась по телеграм-каналам, в самой платформе назвали недостоверной и не имеющей отношения к реальности.

Как сообщили ТАСС в пресс-службе MAX, сообщение об утечке данных поступило из анонимного источника и не подтвердилось по итогам проверки. «Информация из анонимного источника — очередной фейк», — подчеркнули представители мессенджера в ответ на запрос агентства.

После появления слухов специалисты центра безопасности MAX провели проверку и не нашли никаких признаков компрометации. В компании отдельно уточнили, что платформа не использует зарубежные сервисы хранения данных, включая Amazon AWS, а все данные пользователей хранятся исключительно на российских серверах.

Кроме того, в MAX не применяется метод хеширования паролей Bcrypt, анализ логов не выявил подозрительной активности, а обращений по этому поводу в программу баг-баунти также не поступало.

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

Платформа просто не хранит информацию в том формате, который был выложен: в MAX отсутствуют сведения о локации, дате рождения, электронной почте, ИНН, СНИЛС и других персональных данных. Более того, в мессенджере нет username и «уровней аккаунта» — пользователей там в принципе не маркируют по каким-либо «уровням».

Напомним, ранее анонимная группа заявила, что якобы в течение года пыталась взломать MAX и смогла скопировать базу из 15-15,4 млн аккаунтов, включая ФИО, логины и номера телефонов. В качестве подтверждения в Сеть была выложена часть якобы похищенных данных.

 

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

В итоге в компании резюмировали коротко и однозначно:

«Данные пользователей MAX надёжно защищены».

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

HTTP/2 Bomb: одна машина может положить сервер за считаные секунды

Эпоха ботнетов для организации мощных DDoS-атак получила ещё одного игрока. Исследователи рассказали о новой технике отказа в обслуживании под названием HTTP/2 Bomb, которая позволяет буквально положить крупный веб-сервер силами всего одной машины.

Самое неприятное — атака работает против стандартных конфигураций популярных серверов, включая NGINX, Apache HTTP Server, Microsoft IIS, Envoy и Cloudflare Pingora.

Метод обнаружили специалисты компании Calif при помощи ИИ-агента Codex от OpenAI. Фактически HTTP/2 Bomb — это комбинация двух известных приёмов: усиления через механизм сжатия заголовков HPACK и удержания ресурсов по схеме Slowloris с использованием особенностей управления потоком в HTTP/2.

На практике злоумышленник заставляет сервер выделять огромные объёмы памяти, после чего блокирует её освобождение. В результате память продолжает расходоваться, а сервер постепенно перестаёт отвечать на запросы.

По данным исследователей, обычный домашний компьютер с каналом 100 Мбит/с способен вывести из строя уязвимый сервер за считаные секунды. Например, Apache httpd и Envoy можно заставить выделить и удерживать 32 Гбайт оперативной памяти примерно за 20 секунд.

Во время испытаний результаты оказались впечатляющими:

  • Envoy 1.37.2 — 32 Гбайт RAM за 10 секунд;
  • Apache httpd 2.4.67 — 32 Гбайт за 18 секунд;
  • NGINX 1.29.7 — 32 Гбайт за 45 секунд;
  • Microsoft IIS на Windows Server 2025 — 64 Гбайт за 45 секунд.

Особую пикантность ситуации добавляет тот факт, что опубликованы уже не только технические детали, но и готовые эксплойты.

Исправления уже доступны для NGINX 1.29.8 и Apache mod_http2 2.0.41. Для Apache проблема зарегистрирована под идентификатором CVE-2026-49975. А вот пользователям IIS, Envoy и Pingora пока остаётся ждать патчей либо временно отключать HTTP/2 и использовать прокси-серверы или файрволы с жёсткими ограничениями на количество заголовков.

RSS: Новости на портале Anti-Malware.ru