Злоумышленники взяли под контроль более 300 выходных узлов Tor в начале октября и использовали их для перенаправления SSH-соединений на серверы, которые крали пароли для входа, обнаружил исследователь. Выходные узлы — это последний этап в цепи Tor, где трафик покидает сеть и направляется к месту назначения. Только вход по паролю на SSH-сервер, выполненный через Tor между 1 и 5 октября после принятия ключевой пары узла перехвата, мог быть перехвачен. Проект Tor начал помечать узлы 4 октября, а к 5 октября ни один из них не остался в консенсусе — списке узлов, который используют клиенты Tor. На пике 4 октября узлы, несущие выходную политику злоумышленника, составляли 7,46% выходной мощности Tor, измеренной по весу консенсуса, согласно анализу общедоступных данных каталога Tor, опубликованному в почтовой рассылке tor-relays. Исследователь, публикующийся под псевдонимом kaba, 2 октября просканировал все примерно 3000 выходных узлов Tor и обнаружил 333 узла, перенаправляющих SSH на те же 12 серверов перехвата. Анализ данных каталога насчитывает 377 узлов, управляемых 59 операторами, которые переключились на выходную политику злоумышленника между 1 и 4 октября, что названо «совпадением политики, а не доказательством компрометации». Выходной узел передает трафик только на порты, разрешенные его выходной политикой. Злоумышленники переписали эту политику в конфигурационных файлах torrc узлов, чтобы разрешить порт 22 (SSH-порт), включив SSH на 342 узлах, которые его блокировали. Еще 24 узла, которые вообще не были выходными, стали выходными. «Похоже, злоумышленник получает доступ к хостам на базе Linux, и когда эти машины работают как невыходные узлы, они редактируют файл torrc и превращают их в выходные узлы, чтобы иметь возможность осуществить SSH-атаку», — написала команда сетевого здоровья Tor Project в своем уведомлении от 5 октября для операторов узлов. Большинство затронутых узлов уже были выходными, показывают данные каталога. То же изменение закрыло порты зашифрованной почты, IMAPS и POP3S, а на большинстве узлов открыло порты для открытого текста, POP3 и IMAP. Клиент Tor выбирает только выходной узел, который разрешает порт назначения, поэтому эти узлы перестали передавать зашифрованную почту и начали передавать SSH, Telnet и, на большинстве из них, почту в открытом тексте. Почему порты зашифрованной почты были закрыты, не видно в данных, говорится в анализе. При открытом порте 22 SSH-соединение через один из этих выходных узлов вместо назначения шло на один из 12 серверов перехвата, обнаружил kaba. Когда сервер перехватывал соединение, он представлял свою собственную ключевую пару. Пользователь, который уже знал ключ реального сервера, видел предупреждение OpenSSH об изменении идентификации удаленного хоста, а пользователь, подключающийся впервые, видел обычный запрос на принятие нового ключа. При сканировании 2 октября около дюжины выходных узлов предоставляли поддельную ключевую пару, а остальные примерно 300 перенаправляли через те же серверы без изменения ключа. Пользователь, принявший ключ и введший пароль, передавал его перехватчику. Перехватчик подключался к реальному серверу, поэтому сеанс работал, и каждая команда могла отслеживаться, а также отдельно входить в систему с украденным паролем для проверки sudo и запуска установщика Perl, закодированного в base64. В ловушке kaba установщик имел ту же форму, что и команда, которая поместила Ebury, бэкдор, скрывающийся в OpenSSH, на один из серверов оператора узла, как описано ниже. Вход по ключу SSH не мог быть передан таким образом. Согласно протоколу аутентификации SSH, подпись клиента включает идентификатор, уникальный для каждого сеанса, поэтому подпись, сделанная для сеанса перехватчика, бесполезна против реального сервера. Перехватчик все еще мог принять вход по ключу и показать поддельный интерфейс командной строки, но не мог связаться с реальным сервером с его помощью. Пароль, напротив, передается внутри зашифрованного сеанса и может быть прочитан сервером на другом конце, которым в данном случае был перехватчик. Чтобы быть подвергнутым риску, кто-то должен был подключиться к SSH-серверу через Tor между 1 и днем 5 октября, попасть на один из захваченных выходных узлов, чтобы соединение было перехвачено, а не передано, принять ключевую пару перехватчика и войти в систему с паролем. Количество жертв неизвестно. Если вы приняли незнакомую или измененную ключевую пару через Tor в этот период, считайте введенный вами пароль украденным, измените его и проверьте этот сервер на наличие признаков Ebury, перечисленных ниже. Клиент OpenSSH, принявший ключ, сохранил его в known_hosts. Сервер, перехвативший соединение kaba, использовал ключ ED25519 с отпечатком SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E, хотя другие серверы перехвата могли использовать разные ключи. Kaba столкнулся с атакой утром 2 октября, когда SSH-соединение через Tor вернуло предупреждение об изменении ключа. Затем он использовал exitmap, инструмент сканирования, который также использует команда сетевого здоровья Tor Project, чтобы открыть SSH-соединение с одного из своих серверов на другой через каждый выходной узел по очереди. Одна сторона проверяла правильность ключевой пары, а другая — исходило ли соединение с выходного узла или с сервера перехвата. Он сообщил результаты команде здоровья тем вечером. Команда здоровья также заметила изменение политики с помощью собственного мониторинга. 4 октября она связалась с Циммером, который управлял семейством узлов Quetzalcoatl, крупнейшей группой затронутых узлов, и Циммер подтвердил, что изменение было не его, попросил пометить узлы как плохие и остановил Tor на сервере, который ими управлял. Директории начали голосовать за флаги BadExit и MiddleOnly для затронутых узлов в 18:00 UTC в тот день, и флаги были в консенсусе к 21:00. BadExit указывает клиентам Tor никогда не использовать узел в качестве выходного. Утром 5 октября автоматический перезапуск прошел через 55 хостов Quetzalcoatl, с той же политикой. Кто его запустил, неизвестно. Директории к тому времени отклоняли затронутые узлы из сети, сообщил Tor Project в своем уведомлении, а два узла, которые Циммер остановил, были отклонены при попытке повторного входа, написал он. К 17:00 UTC 5 октября ни один узел с политикой злоумышленника не был в консенсусе, и ни один не вернулся к 9 октября, показал анализ данных каталога. Сорок один узел, девять из которых принадлежали Quetzalcoatl, все еще публиковали политику в тот момент, но не были перечислены. Количество узлов с флагом Exit в Tor Metrics упало примерно на 370 между 3 и 5 октября, что соответствует количеству затронутых узлов, и не восстановилось к 18 октября. Циммер описал свою сторону в посте-мортеме в списке 7 октября. Два его сервера работали под управлением Ebury версии 1.8.3: сервер управления в Contabo, который служил VPN-шлюзом и SSH-сервером для семьи, и VPS FranTech, который он называет Switzerland2 и на котором работали два выходных узла. Ebury — это бэкдор и похититель учетных данных для OpenSSH, активный с 2009 года, по данным ESET, которая в 2024 году оценила, что он заразил 400 000 серверов, причем более 100 000 оставались зараженными в конце 2023 года. Злоумышленник вошел в сервер управления 28 августа с первой попытки с паролем учетной записи оператора, получил root в течение пяти минут, установил Ebury, а затем через час добрался до Switzerland2 и установил его там. «Первопричина была нашей: один пароль, повторно использованный для входа по SSH, sudo и пароля резервной копии, хранившийся в открытом тексте на обоих серверах, плюс аутентификация по паролю SSH, оставленная включенной на внешнем сервере управления», — написал Циммер. Откуда злоумышленник получил этот пароль, неизвестно. Входы бэкдора Ebury не оставляют следов. 2 октября конфигурационные файлы выходных узлов были переписаны без каких-либо записей в журналах о командах sudo или cron, и два узла публиковали политику злоумышленника в 09:34 UTC. Она оставалась активной около 52 часов на двух узлах, перемещая примерно 3,4 ТБ в день. Обычная перезагрузка 4 октября уничтожила скрытые инструменты злоумышленника, но Ebury вернулся сразу же. «Автономные» мастер-ключи семьи «не были автономными: копии находились в резервной копии рабочей станции на сервере управления, зашифрованные паролем, который злоумышленник уже имел», — написал Циммер. Он вывел из эксплуатации каждый узел и мост в семье и удалил оба сервера. Этот Ebury представляет собой единый файл библиотеки setuid, /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2, с символической ссылкой libkeyutils.so.1, указывающей на него. Упакованная библиотека нетронута, поэтому dpkg -V и debsums ее не обнаруживают, а sshd, sudo и PAM проходят проверки пакетов. Версия 1.8.3 новее, чем общедоступные индикаторы ESET, которые заканчиваются на 1.8.2, а опубликованный ESET скрипт обнаружения, прочитанный 21 октября, не содержит имени сокета для него. Марк-Этьен М. Левелле, соавтор статьи Ebury 2014 года от ESET, написал отчет 2024 года и с тех пор покинул компанию, ответил, что версия 1.8.3 существует как минимум с июня 2026 года, и опубликовал обновленную копию скрипта, которая ее охватывает. «Учитывая, сколько серверов имели Ebury между 2009 и 2023 годами (400 000!), скорее всего, существуют и другие скомпрометированные узлы Tor», — написал он. Как были взломаны хосты остальных 58 операторов, остается главным открытым вопросом. Среди их узлов, перечисленных 1 октября, 71 из 101, размещенных на FranTech Solutions, сети, стоящей за брендом хостинга BuyVM, переключились на политику злоумышленника, по сравнению с 13 из 9 054, размещенных в другом месте, показал анализ данных каталога. Сорок узлов от 21 оператора изменились в течение пяти с половиной минут 1 октября, большинство из них — из-за перезагрузки конфигурации, что анализ интерпретирует как одного злоумышленника, уже имеющего доступ ко всем 40. Лучшее предположение Левелле для пароля — вход с хоста, уже работающего под управлением Ebury, с скомпрометированным хостинг-провайдером как другой возможностью. ESET видел провайдеров, чьи серверы управления работали под управлением Ebury, и чьи виртуальные серверы клиентов оказались заражены, написал он. Каба насчитал 26 из 27 скомпрометированных серверов вне семьи Quetzalcoatl на FranTech/BuyVM и спросил в списке: «Могли ли они скомпрометировать эти серверы на уровне хостера?» Собственная компрометация Quetzalcoatl прошла через ее сервер управления Contabo, и 225 из ее 273 затронутых узлов находились в других сетях. Кто стоит за кампанией, неизвестно, как и то, сколько из затронутых хостов работали под управлением Ebury: Циммер проверил два своих, а данные каталога показывают только политику. Поддельный заглавный CRON-демон и правила NAT, перенаправляющие порт 22, были среди признаков, о которых другие операторы сообщили в Tor Project. На серверах Циммера не было ни того, ни другого, и открытым остается вопрос, разделяют ли случаи одного злоумышленника. На узлах Циммера изменения портов означали, что любое извлечение почты могло происходить только в открытом тексте, написал он, а скрытый процесс с именем snf работал на Switzerland2 большую часть времени. Что он делал, неизвестно. Уведомление Tor Project просит операторов узлов Linux проверить Relay Search на наличие флага Exit или выходной политики, которую они не устанавливали, и просмотреть torrc и любые включенные файлы на наличие измененных строк ExitRelay, ExitPolicy, ContactInfo, MyFamily или Nickname. Оно также перечисляет правила NAT на порту 22, неизвестные прослушивающие процессы или исходящие соединения, новых пользователей, записи authorized_keys, задания cron и юниты systemd, а также бинарный файл tor, который не проходит проверку пакета. Серверы Циммера не показывали никаких признаков на уровне хоста из этого списка, только измененную выходную политику, поэтому проверка чистого хоста не исключает этот Ebury. Признаки импланта, из его поста Циммера: Запуск оболочки с H=1 I=1 LD_PRELOAD=”:” LD_DEBUG=”:” bash для обхода пользовательского руткита перед запуском обновленного скрипта Левелле или команд из поста Циммера. Если вы его найдете, шаги Tor Project: Переустановка важна, потому что имплант пережил перезагрузку на сервере Циммера. Сообщите на bad-relays@lists.torproject.org, и если ваш IP-адрес был заблокирован во время инцидента, напишите по тому же адресу, как только ваш хост будет очищен, чтобы снять блокировку, сказал Георг Коппен из Tor Project в последующем сообщении.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Swati Khandelwal
