Исследователь KABA обнаружил 333 выходных ретранслятора Tor, перенаправлявших SSH-соединения через 12 посторонних серверов. Примерно на дюжине проверенных выходов он увидел подмену ключа сервера. Такая схема могла раскрыть пароль пользователя, если тот принял подставной ключ и продолжил вход.
Выходной узел — последняя остановка перед обычным интернет-сервисом. Представьте курьера, который доставляет вас не к нужной двери, а к похожей. SSH проверяет удостоверение принимающего сервера — его криптографический ключ. Если удостоверение не совпало, предупреждение нельзя считать формальностью.
Что установил KABA
В опубликованном 20 октября разборе KABA описал проверку примерно 3000 выходных узлов. На 333 узлах соединения шли через одну инфраструктуру перенаправления. Это около десятой части проверенных ретрансляторов по количеству, а не доказательство перехвата десятой части пользователей или всего трафика Tor. Большинство обнаруженных перенаправлений в его тесте не сопровождалось подменой ключа. Исходный разбор.
В контролируемом тесте исследователь наблюдал попытку проверить права учётной записи и установить вредоносное ПО. Успех заражения зависел от доступных атакующему полномочий; число реально похищенных паролей не опубликовано. Первичный способ проникновения на все серверы остаётся неизвестным. Версия о взломе хостера и предположение о финансовой мотивации не доказаны.
Что подтвердил Tor Project
В сообщении от 5 октября команда Network Health подтвердила поступившие от операторов сведения: Linux-серверы были взломаны, конфигурации Tor изменены, SSH-соединения перехватывались. Некоторые ретрансляторы превращали из промежуточных в выходные. Команда помечала затронутые узлы и исключала их из сети. Уведомление операторам.
По хронологии KABA, 2 октября он сообщил о находке, 4 октября начались отключения и маркировка BadExit, а 5 октября известные ему заражённые серверы остановили. Публичное уведомление Tor датировано 5 октября; даты частного оповещения и публикации нужно различать. Это не гарантия, что за пределами обнаруженной группы не осталось заражённых машин.
Флаг BadExit запрещает использовать ретранслятор для выхода в интернет. Он не удаляет вредоносную программу с сервера. Tor также может целиком исключить узел из списка, которым пользуются клиенты. Правила работы с небезопасными ретрансляторами.
Где действительно нашли Ebury
Оператор Quetzalcoatl подробно описал Ebury 1.8.3 на двух собственных серверах: управляющем узле и VPS с двумя выходными ретрансляторами. Его реконструкция относит вход с уже известным атакующему паролем к 28 августа. Оператор признал повторное использование пароля для SSH, sudo и резервной копии; часть журналов была уничтожена, поэтому отдельные выводы остаются предположениями. Отчёт владельца серверов.
На этих машинах меняли политику разрешённых портов, открывая в том числе почтовые соединения без обязательного TLS и закрывая стандартные порты IMAPS и POP3S. Это создавало возможность собирать незашифрованный трафик, но не устанавливает объём прочитанных писем. Сам по себе номер почтового порта также не доказывает отсутствие шифрования: возможен STARTTLS.
Как перехват превращался в доступ к чужому серверу
Последовательность выглядела так: пользователь направлял SSH через Tor, выходной ретранслятор отправлял соединение к посреднику, тот предъявлял свой ключ. При принятии этого ключа зашифрованное соединение заканчивалось уже у посредника. Получив введённый пароль, он мог отдельно войти на настоящий сервер и передавать команды между двумя соединениями. Шифрование сохранялось на каждом участке, но один из участников был злоумышленником.
Это объясняет и границы риска. Одного попадания на подозрительный выход недостаточно для вывода о краже пароля: нужны подмена конечной стороны и передача ей секрета. Изменение ключа бывает и законным — например, после переустановки сервера, — но проверить причину нужно независимо от подозрительного подключения. Удалить запись из known_hosts и повторить вход без проверки означает убрать сигнал тревоги, а не устранить причину.
При обычной аутентификации по открытому ключу клиент подписывает данные конкретной SSH-сессии. Такую подпись нельзя просто перенести в другое соединение с настоящим сервером. Это не делает подставной сервер доверенным и не исключает другие риски: пользователь может вводить туда команды, пароли sudo или иной конфиденциальный текст. Отдельно нужно контролировать пересылку SSH-агента и не включать её без необходимости.
Какие последствия возможны
| Что удалось атакующему | Что могло оказаться под угрозой | Что нельзя утверждать автоматически |
|---|---|---|
| Перенаправить соединение | Маршрут, метаданные и возможность попытаться подменить сервер. | Что пароль уже украден или SSH расшифрован. |
| Получить пароль действующей учётной записи | Доступные ей файлы, команды и сервисы; повторно использованный пароль на других ресурсах. | Что получены права администратора. |
| Закрепиться в системе с высокими правами | Будущие входы, служебные секреты и связанные системы в пределах доступов сервера. | Что именно так произошло на каждой ВМ или у каждого оператора. |
| Наблюдать почту без TLS | Открытое содержимое и передаваемые учётные данные. | Что корректно проверяемый TLS был взломан или вся переписка прочитана. |
Эта таблица описывает возможные последствия механизма, а не установленный перечень похищенного. Если злоумышленник вошёл в систему, одной смены пароля мало: нужно проверить ключи, действующие сессии, задания, службы и секреты интеграций, к которым учётная запись имела доступ. Делать это следует из доверенной среды с сохранением материалов для расследования.
Кого эта история касается в первую очередь
Наиболее прямой риск — у тех, кто в период обнаруженной кампании входил на обычные SSH-серверы через Tor, принимал незнакомый или изменившийся ключ и использовал пароль. Обычный просмотр HTTPS-сайта с корректной проверкой сертификата — другой сценарий. У onion-сервисов нет выходного ретранслятора: переносить на них этот механизм нельзя, хотя это не исключает независимых ошибок самого сервиса.
С другой крупной новостью дня — PHP2Shell и экстренными отключениями сайтов — этот эпизод технически не связан. Общая тема здесь только одна: безопасность приложения зависит и от инфраструктуры, через которую пользователь к нему подключается.
Что защищает пользователя
| Ситуация | Практический вывод |
|---|---|
| SSH предупреждает о смене ключа | Остановить подключение и сверить отпечаток с администратором по независимому каналу. |
| Первое подключение к серверу | Сохранённого ключа ещё нет: нельзя автоматически доверять предъявленному отпечатку. |
| Вход по ключу | Подмена сервера всё равно недопустима. Парольная схема перехвата не равнозначна извлечению закрытого ключа. |
| Почта или сайт без сквозного шифрования | Выходной узел может видеть открытое содержимое. Требовать TLS и проверять сертификаты. |
Управление выходным ретранслятором само по себе не отменяет проверку сертификатов HTTPS и ключей SSH. Соединения с onion-сервисами не используют обычный выход в интернет. Поэтому вывод «всю сеть Tor расшифровали» не следует из этого инцидента.
Если пароль уже вводили после принятия подозрительного SSH-ключа, следует сменить его с доверенного устройства и проверить целевой сервер. Владельцам заражённых ретрансляторов Tor рекомендует сохранить следы, переустановить систему, заменить идентичность узла и отозвать находившиеся на машине доступы. Удаление одного подозрительного файла не даёт уверенности в восстановлении доверия к серверу.