Захват Tor-узлов позволил перехватывать SSH-пароли
В начале октября злоумышленники получили контроль более чем над 300 выходными узлами Tor и перенаправляли SSH-подключения на 12 серверов-перехватчиков. На пике 4 октября такие узлы обеспечивали 7,46% выходной ёмкости Tor; Tor Project начал помечать их 4 октября, а к 5 октября они исчезли из консенсуса сети.
Исследователь kaba 2 октября проверил примерно 3 000 выходных узлов Tor и обнаружил 333 узла, перенаправлявших SSH на одну группу серверов. Анализ публичных данных каталогов также выявил 377 реле 59 операторов, у которых с 1 по 4 октября появилась одинаковая политика выхода. Авторы анализа подчёркивают: совпадение политики не доказывает компрометацию каждого реле.
Как работал перехват SSH
Атакующие изменяли файл конфигурации torrc: открывали порт 22 на 342 реле, где он ранее был закрыт, и превращали ещё 24 невыходных реле в выходные. Одновременно на большинстве узлов закрывались зашифрованные почтовые порты IMAPS и POP3S, а открывались POP3 и IMAP.
Клиент Tor выбирает выходное реле, разрешающее нужный порт. Поэтому SSH-соединение через скомпрометированный узел могло попасть не на целевой сервер, а на перехватчик. Тот предъявлял собственный ключ хоста: постоянный пользователь видел предупреждение OpenSSH о смене идентификатора сервера, а новый — обычный запрос на доверие к ключу.
Если пользователь принимал подменённый ключ и вводил пароль, перехватчик получал учётные данные, подключался к настоящему серверу и мог наблюдать команды в рабочей сессии. Прозрачно ретранслировать вход по ключу он не мог: подпись SSH привязана к уникальному идентификатору сессии и не подходит для соединения с реальным сервером.
Реакция сети и связь с Ebury
Tor Project и операторы каталогов присвоили затронутым реле флаги BadExit и MiddleOnly: клиенты Tor больше не должны были выбирать их в качестве выходных узлов. К 17:00 UTC 5 октября реле с политикой атакующих отсутствовали в консенсусе. По данным Tor Metrics, число реле с флагом Exit за два дня сократилось примерно на 370.
Оператор семейства Quetzalcoatl Zimmer сообщил, что два его сервера были заражены Ebury 1.8.3 — бэкдором и похитителем учётных данных для OpenSSH. Он связал компрометацию с повторно использованным паролем, хранившимся в открытом виде, и включённой парольной SSH-аутентификацией на внешнем управляющем сервере. После обнаружения он вывел из эксплуатации все реле и мост семейства и удалил оба сервера.
Что проверить операторам и пользователям
Tor Project рекомендует операторам Linux-реле сверить флаг Exit и политику выхода в Relay Search, проверить torrc и подключаемые файлы на изменения ExitRelay, ExitPolicy, ContactInfo, MyFamily и Nickname. Также следует искать неизвестные NAT-правила для порта 22, процессы, учётные записи, ключи authorized_keys, задания cron и systemd-службы.
Zimmer указал на признаки Ebury: файл /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2 с setuid, ссылку libkeyutils.so.1 на него и поддельный процесс rsyslogd внутри группы ssh.service. При обнаружении импланта Tor Project советует отключить реле, сохранить диск и журналы, переустановить систему, создать новую идентичность реле и сменить все учётные данные.
Пользователям, которые с 1 по 5 октября подключались к SSH через Tor, приняли незнакомый или изменившийся ключ хоста и ввели пароль, следует считать пароль скомпрометированным. Его нужно сменить и проверить сервер. Для бизнеса практический вывод прост: отключать парольный вход по SSH на внешних системах, использовать ключи и не игнорировать предупреждения о смене ключа хоста.