Информационная безопасность IT

Самое неприятное обнаружилось при проверке реальной опасности. Хелме создал поддельный сертификат для платёжного API api.stripe.com и поднял тестовый сервер на собственном компьютере. Утилита curl успешно проверила сертификат, Python установил защищённое соединение, а Node.js подтвердил подлинность сервера. Аналогичные результаты исследователь получил на протестированных системах Linux и macOS.

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

Причина катастрофической слабости ключей оказалась удивительно простой. eMudhra использовала криптографический алгоритм на эллиптической кривой P-384, где закрытый ключ должен быть случайным числом размером около 384 бит. Вместо полноценного случайного значения система создала ключи, содержавшие всего один ненулевой байт. Для восстановления каждого секрета достаточно проверить не более 255 вариантов.

Сам алгоритм P-384 никто не взломал. Ошибка возникла при создании ключей, а внешне сертификаты выглядели совершенно нормально. Их структура соответствовала стандартам, открытые ключи были математически корректными, а обычные проверки не обнаруживали нарушений. Выявить проблему удалось только после анализа криптографической стойкости самих ключевых пар.

Все восемь слабых ключей появились 30 апреля 2025 года. Каждый использовался в двух промежуточных сертификатах, один подписала сама eMudhra, второй в мае 2025 года дополнительно подписала Sectigo. Таким образом, существовало 16 сертификатов с восемью одинаково уязвимыми ключевыми парами. Возможность восстановить закрытые ключи сохранялась около 17 месяцев, причём злоумышленникам не требовалось проникать в инфраструктуру удостоверяющего центра.

Первые защитные меры приняли 17 октября 2026 года после обращения исследователя, обнаружившего проблему. Google заблокировала опасные ключи в Chrome через механизм CRLSet, а Mozilla распространила блокировку через OneCRL. Пользователям с обычными настройками не понадобилось даже перезапускать браузеры. Аналогичную защиту для Android Google начала распространять через сервисы Google Play 19 октября.

Дополнительным барьером стала система Certificate Transparency, которая требует публично регистрировать сертификаты сайтов. Google не обнаружила в журналах ни одного TLS-сертификата, выпущенного шестью проблемными центрами до их блокировки. Поэтому поддельные сертификаты не могли пройти стандартную проверку Chrome, требующую подтверждения регистрации. Однако далеко не все программы используют такой механизм.

Основной риск теперь связан с приложениями, которые проверяют сертификаты иначе, чем современные браузеры. Серверные API, автоматические установщики программ, системы непрерывной сборки и развёртывания CI/CD, облачные инструменты и пакетные менеджеры часто полагаются на локальное хранилище доверия. Многие клиенты по умолчанию не проверяют отзыв сертификатов и не требуют регистрации в публичных журналах. Поэтому формально отозванный сертификат всё ещё может пройти проверку.

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

Отдельную опасность представляют два скомпрометированных центра подписи программного кода. Их ключи позволяют создавать цифровые подписи, которые могут выглядеть действительными для проверяющих систем Windows. При отсутствии проверки отзыва злоумышленники потенциально способны использовать такие подписи для вредоносных программ. Угроза не означает автоматического обхода всех механизмов защиты Windows, но создаёт дополнительную возможность маскировать происхождение исполняемых файлов.

Mozilla 20 октября выпустила Firefox 158.0.1 и обновления веток ESR 115.43.1 и 153.5.1. Дополнительно разработчики подготовили NSS 3.131.1 с удалением доверия к корневому сертификату emSign ECC Root CA - G3. Google также решила исключить соответствующий корневой сертификат из Chrome Root Store. Массовое распространение такого изменения запланировано на 27 октября. Владельцам сайтов, использующим затронутую корневую цепочку, потребуется заменить сертификаты, иначе соединения могут перестать работать.

Cloudflare проверила собственную инфраструктуру и не обнаружила признаков эксплуатации проблемы в своих сервисах. Компания обновила клиенты WARP и Cloudflare Tunnel, а также внедрила дополнительные ограничения в CDN и сервисах Zero Trust. Администраторам рекомендуют обновлять системные наборы сертификатов, библиотеки проверки TLS и контейнерные образы. Проверять необходимо именно приложения, поскольку исправленный браузер не гарантирует безопасность остальных программ на компьютере.

Компания eMudhra объяснила произошедшее предварительными результатами внутреннего расследования. Во время создания ключей специалисты использовали аппаратные криптографические модули Ultimaco HSM. В сценарий генерации внесли изменения для проверки операций экспорта ключей, после чего программная ошибка привела к появлению дополнительных слабых ключевых пар. Из-за похожих обозначений сотрудники выбрали неправильные ключи для запросов на выпуск сертификатов.

По версии eMudhra, первоначально оборудование создало полноценные криптографические ключи, но при дальнейшей работе сотрудники использовали слабые дубликаты. Ошибочные запросы подписали собственным корневым центром, а затем передали Sectigo для дополнительной подписи. Разработчик считает, что аппаратные модули не были непосредственной причиной проблемы, однако расследование ещё продолжается. Компания также признала несколько человеческих ошибок на разных этапах процедуры.

В ходе разбирательства Mozilla обнаружила ещё одну подозрительную деталь. В мае 2025 года те же промежуточные центры уже фигурировали в инциденте с некорректными подписями списков отозванных сертификатов. Представители eMudhra пояснили, что первоначально такие списки подписывали правильными ключами, а после обнаружения несовпадений повторно подписали ошибочными. Насколько ранний инцидент был связан с нынешним, специалисты продолжают выяснять.

eMudhra утверждает, что семь проблемных промежуточных центров вообще не использовались в рабочей инфраструктуре, а восьмой не выпустил ни одного конечного сертификата. Компания также заявляет, что закрытые ключи корневых центров и остальных промежуточных центров не пострадали. Все восемь скомпрометированных сертификатов отозваны, а Sectigo отдельно отозвала собственные сертификаты с перекрёстной подписью.

Подтверждённых случаев злонамеренного применения восстановленных ключей пока нет. Однако отсутствие записей в публичных журналах не исключает атак на программы, которые не используют Certificate Transparency. Установить, восстанавливал ли кто-нибудь закрытые ключи до публичного раскрытия, практически невозможно. Инцидент показал, что даже правильно работающие криптографические алгоритмы не спасают систему, если удостоверяющий центр допускает ошибку при генерации ключей, а приложения годами продолжают доверять скомпрометированным сертификатам.

https://www.securitylab.ru/news/579028.php

https://xakep.ru/2026/10/21/emudhra-certs/

https://www.opennet.ru/opennews/art.shtml?num=66515

Дыры нашли независимо сразу три команды. Исследователи Calif использовали GPT-5.6 Sol в рамках программы OpenAI Patch the Planet, компания Wiz – Gemini 4 Argon и тот же GPT-5.6 Sol, третьей была команда OpenAI Codex Security. По словам Wiz, один исследователь с ИИ за неделю сделал то, на что раньше у целой команды ушли бы месяцы. Глава Wiz Ами Луттвак назвал находку самой серьезной уязвимостью, когда-либо найденной с помощью ИИ.

Первое сообщение разработчики PHP получили 11 августа. Дальше два месяца шла тихая подготовка: OpenAI собрала коалицию из Google, Microsoft, AWS, Cloudflare и других компаний, подключила американские госструктуры – агентство кибербезопасности CISA и даже "Силы по сверхинтеллекту" при Белом доме. Публичное раскрытие назначили на 22 октября.

20 октября на Hacker News появился пост, который сорвал этот план: две критические дыры в PHP, 10 баллов из 10, раскрытие 22-го. Технических деталей не было, автор сам признал, что доказательств у него нет, кроме "поверьте мне". Но исследователи из watchTowr подтвердили, что утечка настоящая. Разработчики PHP сдвинули выпуск исправлений на 21 октября, а утром того же дня, около 10:30 по Москве, хостинги и Cloudflare зафиксировали первые атаки – больше чем за шесть часов до выхода патча.

Исправленные версии вышли днем 21 октября: 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Для PHP 8.1 и старше официальных исправлений нет, а на таких версиях работает примерно каждый пятый сайт на WordPress и почти каждый четвертый на Joomla. Специалисты Sansec ждали массовых атак уже через 15 минут после выхода патча: по исправлению легко понять, где именно была дыра.

OpenAI в конце поста спрашивает у отрасли, можно ли государству или провайдеру воспользоваться уязвимостью, чтобы залатать системы, которыми они управляют, но к которым потеряли админский доступ. Компания допускает будущее, где интернет постоянно сканируется на известные дыры, а найденные либо сообщаются владельцам, либо сразу закрываются. На поддержку защитников OpenAI выделила $1 млрд в виде субсидированного доступа к своим моделям.

Вы бы пустили такого робота-латальщика на свой сервер?

P.S. О том, что нейросети уже находят в коде раньше людей, я пишу в канале "сбежавшая нейросеть".

Хорст Фейстель родился в Берлине 30 января 1915 года. В 1934 году транзитом через Швейцарию он эмигрировал в США (не стал ждать повестки в военкомат, в Германии всеобщая воинская повинность была официально введена в 1935 году) где получил степень бакалавра по физике в MIT, а затем магистра в Гарварде.

Во время Второй мировой войны Фейстель, как уроженец Германии, находился под домашним арестом. Американское гражданство он получил только 31 января 1944 года. Уже на следующий день ему дали допуск к работе и он приступил к работе в Air Force Cambridge Research Center — над системами радиолокационного опознавания «свой-чужой».

После войны были лаборатория Линкольна при MIT, MITRE, а в 1968 году — исследовательский центр IBM в Йорктаун-Хайтс. Именно там Фейстель занялся криптографией и вместе с коллегами начал разрабатывать Lucifer.

Что вообще такое «сеть Фейстеля»

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

Блок данных режется пополам — на левую L и правую R части. Дальше несколько раундов подряд повторяется одно и то же:

1. Правая половина R проходит через функцию F вместе с ключом раунда. F может быть сколь угодно сложной и даже необратимой — и это нормально.

2. Результат складывается с левой половиной L по модулю 2 — то есть выполняется операция XOR.

3. Половины меняются местами, и всё повторяется заново.

Гениальность — в одной детали: чтобы расшифровать сообщение, не нужно уметь обращать функцию F. Достаточно прогнать раунды в обратном порядке, используя ключи в обратной последовательности.

Именно поэтому внутрь F можно засунуть довольно сложную начинку — например, нелинейные S-блоки — не боясь, что шифр станет невозможно расшифровать.

Вехи создания

У Lucifer было несколько версий, и Фейстель с коллегами постепенно усложняли конструкцию. Начиналось всё с 48-битного блока и 48-битного ключа, затем появились варианты с другими параметрами. В одной из версий Джона Л. Смита использовались 64-битный ключ и 32-битный блок.

А затем появился Lucifer с 128-битным блоком и 128-битным ключом, построенный уже на сети Фейстеля. Именно эта версия особенно важна для нашей истории: из неё выросла конструкция, которая в итоге привела IBM к DES (созвучно с death, они что там, не крещенные? Так по загробному миру фанатеть...).

То, ради чего вообще статья затевалась

Визуализация данного алгоритма, а точнее упрощенная версия сети Фейстеля представляет собой левую активную панель (где и будем экспериментировать, менять значения) и правую панель, что бы видеть подробно каждый шаг, но в тоже время иметь объективное представление обо всех этапах алгоритма.

Шаг 2 - собственно фиксируем байт, с которым будем работать далее, тут не очень интересно, показывать нечего, жмём Далее

Что еще хочется отметить Я никогда не устану повторять ... если мы говорим именно о защите чувствительной информации криптографией, которая регулируется государством (не важно каким) на данный момент на каждом этапе (создание, доставка на объекты, загрузка ключа) присутствует человеческий фактор. А человек это брешь в любой системе безопасности. Ну если уж не брешь, то слабое место. Anyway двигаемся дальше.

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

Сделка с дьяволом: могло ли АНБ оставить в DES бэкдор?

Ну что, с сетью Фейстеля разобрались и даже немного поиграли. Теперь вернёмся к Lucifer — потому что именно здесь начинается самая интересная часть истории.

В 1973 году американское Национальное бюро стандартов (NBS, ныне NIST) объявило конкурс на единый стандарт шифрования для гражданских ведомств. IBM предложила доработанный Lucifer. Работу над ним возглавили Уолтер Тачмен и Карл Мейер.

И тут в историю вошло АНБ.

АНБ узнало, что Уолтер Тачмен из IBM работает над новой версией Lucifer. Агентство оформило ему допуск к секретной информации (в переводе с бусурманского - к гос. тайне) и подключилось к совместной работе над шифром.

Дальше возник вопрос, который до сих пор делает историю DES такой интересной:

а нельзя ли встроить в шифр секретный вход для тех, кто знает, где его искать?

Бэкдор, которого никто не должен увидеть

На первый взгляд идея кажется вполне реалистичной.

Если ты участвуешь в разработке стандарта, можешь влиять не только на длину ключа, но и на саму конструкцию алгоритма. А в DES особенно подозрительно выглядели S-блоки — таблицы, которые превращают входные данные в выходные и добавляют шифру нелинейность.

АНБ участвовало в их разработке, но принципы проектирования долгое время не раскрывались.

Отсюда и подозрение: а вдруг внутри S-блоков спрятана математическая лазейка?

Такую возможность обсуждали вполне официально. В документах того времени фигурирует понятие trapdoor — условно говоря, секретная дверь, позволяющая обойти обычную защиту алгоритма. Если такая дверь существует, обладателю секретного знания не обязательно знать ключ пользователя. Он получает другой путь к расшифровке.

Но доказательств того, что подобную дверь действительно оставили, найдено не было.

А вот ключ действительно укоротили

Зато здесь никаких теорий заговора не требуется.

В процессе стандартизации АНБ настояло на сокращении длины ключа. Обсуждались разные варианты, а в итоге остановились на 56 битах.

При этом АНБ участвовало и в разработке S-блоков.

Получилась странная комбинация: одну часть защиты сделали слабее, а другую — загадочным образом изменили в закрытом режиме.

В 1977 году DES стал федеральным стандартом США — FIPS PUB 46.

И почти сразу появились вопросы.

«56 бит? Вы серьёзно?»

В том же году Уитфилд Диффи и Мартин Хеллман опубликовали статью с недвусмысленным названием — Exhaustive Cryptanalysis of the NBS Data Encryption Standard.

В рамках теоретического подхода они посчитали стоимость специальной машины для перебора ключей DES и получили оценку около $20 миллионов за систему, способную найти ключ примерно за сутки. Но короткий ключ был не единственной причиной для подозрений.

Оставался вопрос: что именно АНБ сделало с S-блоками?

В 1978 году специальный комитет Сената США расследовал участие АНБ в создании DES. Скрытой математической «двери» в алгоритме не обнаружили. Но выяснилось, что АНБ действительно убедило IBM согласиться на сокращённый ключ и участвовало в разработке S-блоков. То есть подозрения имели под собой почву. Просто доказательств бэкдора не нашли. И на этом историю можно было бы закончить. Но тогда мы не получили бы главный твист.

Тайна, которую скрывали почти 20 лет

В 1990 году Эли Бихам и Ади Шамир опубликовали метод дифференциального криптоанализа — мощный способ атаковать блочные шифры. И тут выяснилось кое-что странное.

DES оказался очень хорошо защищён от этой атаки.

В 1994 году Дон Копперсмит, один из разработчиков DES в IBM, раскрыл причину: IBM знала о дифференциальном криптоанализе ещё с 1974 года — задолго до того, как о нём узнал открытый научный мир. Более того, устойчивость к этой атаке была одним из критериев при проектировании S-блоков и перестановки DES.

То есть те самые загадочные S-блоки, которые подозревали в наличии секретной лазейки, оказались очень хорошо защищены от атаки, о существовании которой разработчики тогда даже не знали.

И вот здесь появляется настоящий вопрос.

Откуда IBM знала об этой атаке в 1974 году?

IBM утверждала, что разработала соответствующие методы самостоятельно. Историки также обсуждали возможность того, что определённые знания пришли от АНБ. Но документального доказательства того, что АНБ передало IBM готовый метод дифференциального криптоанализа, нет. Поэтому здесь заканчиваются факты и начинаются исторические вопросы.

Но парадокс остаётся:

АНБ действительно вмешалось в разработку DES.
АНБ действительно добилось более короткого ключа.
АНБ действительно участвовало в разработке S-блоков.
Но доказательств, что оно оставило бэкдор, нет.

А спустя двадцать лет выяснилось, что S-блоки были спроектированы гораздо умнее, чем могла знать публика.

Диффи и Хеллман всё-таки оказались правы

Оставалась другая проблема — 56-битный ключ. В 1998 году Electronic Frontier Foundation построила специализированную машину Deep Crack менее чем за $250 000.

Она перебирала ключи DES со скоростью около 88 миллиардов ключей в секунду и нашла нужный ключ за 56 часов.

Год спустя EFF вместе с distributed.net сделали это уже за 22 часа 15 минут.

То, что в 1977 году казалось машиной за десятки миллионов долларов, спустя два десятилетия превратилось в относительно доступный специализированный компьютер.

DES было пора на пенсию. Lucifer умер да здавствует... Кхе, кхе

Но сеть Фейстеля никуда не делась

Да, DES устарел, а идея Фейстеля — нет.

На сети Фейстеля или её модификациях построены Blowfish, Twofish, Camellia, KASUMI и другие шифры. Похожие конструкции используются и в форматно-сохраняющем шифровании.

А по другую сторону железного занавеса существовала своя история.

В СССР был создан ГОСТ 28147-89 — блочный шифр с 64-битным блоком, 256-битным ключом и 32 раундами, тоже на сети Фейстеля. Его разработка проходила в закрытой системе советской криптографии, поэтому подробности долго оставались недоступными. Сегодня обновленная версия этого алгоритма в российском стандарте ГОСТ Р 34.12-2015 известен как «Магма».

В 2001 году NIST утвердил новый стандарт — AES. Он уже не использовал сеть Фейстеля, а был построен на другой архитектуре — подстановочно-перестановочной сети, но это уже совсем другая история.

Lucifer умер. DES тоже.

А идея одного немецкого гражданина, эмигрировавшего в США, продолжает жить.

И всё началось с довольно простой мысли: разделить блок пополам, немного покрутить одну половину, смешать её с другой — и повторить.

И в заключении хотелось бы сказать: "Помните алгоритмы шифрования - это всё здорово, но самое главное, берегите себя и своих близких".

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

Звучит сложно? На самом деле всё проще. У одного нашего героя синдром Аспергера, у второго — аутизм, а оба они по-своему гении.

Читайте также:

• От мирового признания до трагедии: две истории, две стороны киберпреступности

• Два юных хакера: один взламывал из любопытства, другой — ради денег

Мальчик, который напугал всех в ЦРУ

Всё, как обычно, идет из детства. Кейн Гэмбл рос в относительно небольшом, но очень унылом за счет своей серости городе Лестер, Англия. В принципе, семья обычная — пара британских работяг с одного из местных заводов (которых в Лестере действительно МНОГО), и одной маленькой светлой точкой в биографии. Мать парня выиграла в лотерею 1997 года довольно много денег — 1,7 миллиона фунтов стерлингов. Деньги были вложены в бизнес, который прогорел и стал причиной не самой здоровой обстановки в семье на годы вперед.

И, казалось бы, в такой среде мог вырасти кто угодно из представителей классической английской уличной преступности (простите мне мою субъективность), но нет, Кейн Гэмбл видел мир не так, как другие парни из не самых благополучных семей. У мальчика было диагностировано расстройство аутистического спектра, что вкупе с не раз упомянутыми обстоятельствами сильно влияло на мировоззрение Кейна. Он видел мир без серой морали, с четким и очень своеобразным делением на добро и зло. А еще он с раннего подросткового возраста увлекался политикой и ненавидел гос. аппарат США за коррумпированность и, это цитата, «расчётливость».

Именно такие взгляды сведут его с D3f4ult — сыном американского чиновника и любителем взламывать сетевой код в онлайн-играх. Парни сойдутся на мысли, что правительству надо шатать нервы и наказывать за излишнюю свободу деятельности. А еще D3f4ult в свое время очень вдохновился расследованием Сноудена на тему прослушки граждан. Именно это и станет поводом ненадолго превратить жизнь одного конкретного человека в ад.

В интернете Кейн Гэмбл называл себя Cracka, а всю свою деятельность в кооперации с D3f4ult помечал как работу группировки C.W.A. (на сленговом языке чернокожих Cracka означает «белый»), что переводится на русский как «Белые с мнением», отсылка на культовый коллектив N.W.A. Идея их группировки была не в деньгах, а в желании как можно сильнее опозорить первых лиц американских спецслужб, и чем публичнее лицо, тем лучше.

Так под их прицел и попал Джон Бреннан, директор ЦРУ на момент описываемых событий. Кейн Гэмбл взломал его почту, аккаунты в мессенджере AOL, а также личный кабинет сотового оператора Verizon. Через цепочку слитых документов нашелся в том числе личный мобильный номер, который завалили сначала просто спам-звонками, а потом и откровенными угрозами вперемешку с отборным (насколько позволяет бедный на это дело английский язык) матом.

Позже через почту найдется доступ к домашней экосистеме Бреннана, где были подключены все устройства его семьи, и уже на них стали приходить угрозы и спам. Разумеется, рядом с этим пошла утечка внутренних рабочих писем с конфиденциальными данными, в том числе и о военных операциях разных временных периодов. Кейн Гэмбл, кстати, не стеснялся делиться в социальных сетях фактом, что у него есть эти данные, ага. Он позже признается, что делал всё это под веществами и не хотел навредить, ему было просто весело кошмарить не просто случайного человека, а директора ЦРУ.

Джон Бреннан, кстати, в ходе этих событий несколько раз менял место жительства, жил под круглосуточным наблюдением вооруженной охраны, и в целом в структуре начался жуткий переполох. Только вот факт — C.W.A., несмотря на угрозы, практически не слили в сеть ничего важного, они просто несколько недель кошмарили человека и его семью, чтобы показать, что неприкасаемых людей не существует.

А потом им надоело, и они перестали это делать. Но история на этом не кончилась. В целом отследить звонки и прочую деятельность было изначально трудно... если бы не пьяный D3f4ult, который случайно проговорился другу, что имеет отношение к развирусившейся истории о взломе директора ЦРУ. За свой длинный язык он получит пять лет тюрьмы и по возвращению вольется в легализованные криптотусовки, да начнет ходить по различным подкастам. Собственно, основываясь на выпуске подкаста Darkest Diaries с ним, и написана большая часть этого текста.

Кейн Гэмбл, естественно, тоже был быстро найден, потому что D3f4ult раскололся. Суд Англии учел диагноз и возраст, поэтому парню дали всего 2 года колонии для несовершеннолетних. По выходу он пропал с радаров и, по слухам, до сих пор работает где-то в сфере информационной безопасности.

Эту программу боялись почти все кто создавал и держал сайты. За ней стоит гений

Адам Мадд рос в гораздо более приличной и нормативной семье, чем Кейн Гэмбл, да и район был значительно благоприятнее, чем промышленный город в Англии. Да вот одна проблема — буллинг со стороны сверстников в школе и колледже. Замкнутого и малообщительного молодого человека не очень уважали, но ценили тот факт, что он никогда не даст сдачи.

Спусковым крючком стала кража. Пришел с деньгами, ушел без, полиция развела руками, и дело в ход не пошло. Зато в отместку пошли на дно около сотни сайтов образовательных учреждений по всей Америке. Адам положил их методом банального DDoS в рамках тестирования своего небольшого проекта под названием... Titanium Stresser.

Адам Мадд разрабатывал программу несколько лет в полном одиночестве и секретности от всех. Если говорить простыми словами, Titanium Stresser — это оружие массового поражения, программа, которая за счет умной DDoS-атаки способна класть на лопатки буквально любой ресурс вне зависимости от объема его защиты. Titanium за счет переброса трафика и пустых запросов в гигантском количестве создавал просто адскую нагрузку на сервера, которую никто не мог выдержать.

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

Помимо прочего, Titanium Stresser умел убивать почтовые ящики спамом наглухо, доксить IP-адреса вплоть до точного расположения сервера по месту жительства и жесточайше брутфорсить пароли.

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

Но, как это обычно бывает, всё сломал один длинный язык нахального школьника. Есть такая идейная группировка борцов с корпорациями под названием Lizard Squad, их особенно не любят геймеры даже в нашей стране, ведь раньше они частенько по причинам «потому что можем» ложили сервера Sony и Microsoft. Да, угадайте, с помощью какого софта они это делали.

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

Родители Адама Мадда узнали о делах (и финансовом состоянии) сына только в тот момент, когда их дом штурмом брала полиция. И в этой ситуации важно одно: никто не хотел сажать в тюрьму юного гения. Судья зачитывал приговор дрожащим голосом и несколько раз отметил, что это вынужденная мера, а у Адама с его навыками очень светлое будущее, если он применит их в правильное русло. Собственно, после 2 лет тюрьмы (срок сократили из-за синдрома Аспергера и возраста) Адам также ушел в тень, разработка Titanium была свернута, а сам парень, говорят, работает в одной очень крупной IT-компании на должности руководителя отдела безопасности, но не под своим именем.

Мораль такова: цените свои навыки, развивайте и направляйте в правильное русло. А еще никакая болезнь таланту не помеха. Хорошего дня!

Получилось вот это: «Крупный банк вводит комиссию за входящие переводы с 1 сентября». Домен в адресной строке — `novosti-segodnya24.ru`. Внизу тельце новости со ссылкой на «источник, знакомый с ситуацией».

Файл — 80 килобайт, разрешение 900×600. Выглядит как обычный скрин с телефона. На отрисовку ушло меньше секунды, вся возня — минут пять вместе с подбором цветов.

Отдельно отмечу: я не редактировал чужой скриншот. Я нарисовал новый файл с нуля. Дальше это окажется важно.

Шаг 2. Метаданные

Первый совет из любого гайда — посмотреть EXIF.

Смотрю. Результат:

Пусто. Вообще ничего. Ни камеры, ни даты, ни редактора, ни следов обработки.

И вот тут первая ловушка. Обычно пустой EXIF трактуют так: «метаданные вычистили, значит что-то скрывают». А правда скучнее — их там никогда и не было. Файл создан программой, а не камерой. Скрывать было нечего изначально.

Ровно так же выглядят настоящие скриншоты с вашего телефона. Пустой EXIF не улика ни в одну сторону.

Шаг 3. ELA — тот самый «анализ подделок»

Есть популярный метод: пересохранить картинку и посмотреть на разницу в сжатии. Считается, что вставленные куски «светятся» — у них другая история сжатия.

Прогнал. Зона заголовка дала отклонение 0,39, пустой фон — 0,14. Разница есть. Формально — «текст выделяется на фоне, подозрительно».

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

Результат:

Подлинник дал «сигнал подделки» втрое сильнее, чем реальная подделка.

Объяснение простое: ELA реагирует на резкие границы. Любой текст, любая контрастная линия — это резкая граница, и она всегда даёт отклонение при пересжатии. Метод показывает не монтаж, а наличие чётких контуров.

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

Что в итоге сработало

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

Домен. `novosti-segodnya24.ru` — такого издания нет. Проверяется поиском названия и возрастом домена через whois. Скриншот утверждает, что публикация существует по конкретному адресу, — значит, адрес можно открыть.

Отсутствие публикации. Настоящая новость такого масштаба была бы у десятка изданий. Ищется по заголовку в поиске, а не по картинке.

Формулировка. «Источник, знакомый с ситуацией» без имени и должности — способ сказать «мы это не проверяли».

Обратный поиск. Прогон картинки через Яндекс Картинки или Google Lens покажет, всплывала ли она раньше и с какой подписью.

Оговорюсь честно: обратный поиск мой свежесозданный файл не нашёл бы — его в индексе нет, он существует пять минут. Это важный нюанс. Метод отлично работает против старых картинок с новой подписью и бесполезен против только что сделанных. Пустой результат обратного поиска ничего не доказывает.

Главный вывод эксперимента

Я неделю назад сам писал пост про признаки подделки в интерфейсе — шрифты, локализация, порядок времени. Всё это работает, но только когда фейк делали руками поверх настоящего скрина.

Мой фейк такими методами не ловится в принципе. Он не подделка настоящего файла — он новый файл. Искать в нём следы редактирования бессмысленно, потому что редактирования не было.

Отсюда правило, которое я после этого эксперимента ставлю выше всех остальных:

Скриншот доказывает только то, что кто-то нарисовал картинку. Существование публикации проверяется у источника, а не внутри файла.

Если под виральным скрином нет ссылки — это не «пока не нашли ссылку». Это и есть результат проверки.

Разборы схем, инструменты и статьи по кибербезопасности — у меня в канале, там этого добра накопилось прилично!

А теперь вопрос в комментарии: вы когда-нибудь пересылали дальше скриншот, не открыв первоисточник? Я — да, и не раз.