Атакуващи са поели контрол над повече от 300 изходни релета (exit relays) в Tor в началото на октомври и са ги използвали за пренасочване на SSH връзки към сървъри, които са крали пароли за вход, установи изследовател.

Изходните релета са последната точка по маршрута във веригата на Tor, където трафикът напуска мрежата към крайната си дестинация. Единствено вход с парола към SSH сървър, осъществен през Tor между 1 и 5 октомври след приемане на хост ключа на прихващащия сървър, би могъл да бъде компрометиран.

Tor Project започна да маркира релетата на 4 октомври, а до 5 октомври нито едно от тях не остана в консенсуса — списъка с релета, които клиентите на Tor използват. В пиковия момент на 4 октомври релетата, прилагащи изходната политика на атакуващия, са съставлявали 7,46% от изходния капацитет на Tor, измерен според тежестта в консенсуса, показва анализ на публични директорийни данни на Tor, публикуван в пощенския списък tor-relays.

Изследователят, който публикува под псевдонима kaba, е сканирал всички приблизително 3000 изходни релета на Tor на 2 октомври и е открил 333, пренасочващи SSH към едни и същи 12 прихващащи сървъра. Анализът на данните от директориите отчита 377 релета, управлявани от 59 оператора, които са преминали към изходната политика на атакуващия между 1 и 4 октомври, което той определя като „съвпадение на политиката, а не доказателство за компрометиране“.

Как превзетите изходни релета са прихващали SSH

Дадено изходно реле пренася трафик само към портовете, които неговата изходна политика разрешава. Атакуващите са пренаписали тази политика в конфигурационните файлове 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 и изпълнение на кодиран с base64 инсталатор на Perl. В капана за кибератаки (honeypot) на kaba инсталаторът е имал същата форма като командата, инсталирала Ebury — задна врата (backdoor), която се укрива в OpenSSH — на един от сървърите на оператор на реле, както е описано по-долу.

SSH вход, базиран на ключ, не е можел да бъде предаван по този начин. Съгласно протокола за автентикация на SSH подписът на клиента включва уникален идентификатор за всяка сесия, така че подпис, създаден за сесията на прихващача, е неизползваем срещу истинския сървър. Прихващачът все пак е можел сам да приеме входа с ключ и да покаже фалшива обвивка (shell), но не е можел да достигне истинския сървър чрез него.

За разлика от това, паролата пътува в криптираната сесия и може да бъде прочетена от сървъра от другия край, който в този случай е бил прихващачът.

Кой е бил засегнат и какво да направите, ако сте сред тях

За да бъде изложен на риск, някой е трябвало да се свърже към 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 октомври те са се свързали с Цимер (Zimmer), който управлява семейството релета 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 октомври.

Ebury и как нападателите са проникнали

Цимер описва своята гледна точка в ретроспективен анализ (post-mortem) в пощенския списък на 7 октомври. Два от неговите сървъри са изпълнявали Ebury версия 1.8.3: сървър за управление в Contabo, който е служил като семеен VPN шлюз и междинен SSH хост (jump host), и FranTech VPS, който той нарича Switzerland2, обслужващ два от изходните възли.

Ebury е задна врата (backdoor) и инструмент за кражба на идентификационни данни за 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 TiB на ден.

Рутинно рестартиране на 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 октомври, не изброява име на сокет за нея.

Марк-Етиен М. Левейе, съавтор на доклада на ESET за Ebury от 2014 г., написал доклада от 2024 г. и напуснал компанията оттогава, отговори, че версия 1.8.3 съществува поне от юни 2026 г., и публикува обновено копие на скрипта, което я обхваща. „Като се има предвид колко сървъри са имали Ebury между 2009 и 2023 г. (400 000!), най-вероятно има и други компрометирани Tor релета“, написа той.

Как е проникнато в хостовете на останалите 58 оператори, е основният отворен въпрос. Анализът на директорийните данни установи, че сред техните релета, регистрирани на 1 октомври, 71 от 101, хоствани във FranTech Solutions (мрежата зад хостинг марката BuyVM), са преминали към политиката на атакуващия, срещу 13 от 9054, хоствани на други места.

Четиридесет релета на 21 оператори са променени в рамките на пет минути и половина на 1 октомври, повечето чрез презареждане на конфигурацията, което анализът тълкува като един злонамерен субект, който вече има достъп до всички 40.

Най-вероятното предположение на Левейе за паролата е влизане от хост, вече изпълняващ Ebury, като компрометиран хостинг доставчик е друга възможност. ESET са виждали доставчици, чиито сървъри за управление са изпълнявали Ebury и чиито виртуални сървъри на клиенти в крайна сметка са се оказали заразени, написа той.

Каба преброи 26 от 27-те компрометирани сървъра извън семейството Quetzalcoatl във FranTech/BuyVM и попита в пощенския списък: „Възможно ли е да са компрометирали тези сървъри на ниво хостинг доставчик?“

Собственият пробив на Quetzalcoatl е преминал през неговия сървър за управление в Contabo, а 225 от неговите 273 засегнати релета са се намирали в други мрежи.

На релетата на Цимер промените в портовете означават, че всяко извличане на поща е могло да се извърши само в чист текст, пише той, а скрит процес на име snf е работил на Switzerland2 през по-голямата част от времевия прозорец. Какво е извършвал той, остава неизвестно.

Какво трябва да проверят операторите на релета

Известието на The Tor Project приканва операторите на Linux релета да проверят в Relay Search за флаг Exit или изходна политика, които не са задали, както и да прегледат torrc и всички включени файлове за променени редове ExitRelay, ExitPolicy, ContactInfo, MyFamily или Nickname.

В него също така се изброяват NAT правила за порт 22, неизвестни слушащи процеси или изходящи връзки, нови потребители, записи в authorized_keys, cron задачи и systemd единици, както и tor бинарен файл, който не преминава проверката на пакета си. Сървърите на Цимер не показват нито един от признаците на ниво хост от този списък, а само променената изходна политика, така че чиста проверка на хоста не изключва наличието на този Ebury.

Признаците на импланта, според публикацията на Цимер, са:

  • Файл: /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2, setuid и непринадлежащ на никой пакет (63 368 байта на неговите сървъри, с хеш, различен на всеки сървър)
  • Символна връзка: libkeyutils.so.1, сочеща към този файл
  • Сокет: абстрактен UNIX сокет @event-0YsOG9WSOE
  • Процес: фалшив /sbin/rsyslogd (по-рано systemd-udevd или arpd), работещ вътре в cgroup на ssh.service
  • IP: 185.225.226[.]62, източникът на влизането на 28 август
  • SSH ключ: RSA SHA256:dvACokMYcXJ2om4wuS+TvdtjrAgPK7rC7ZQHDgvBHzk, използван за влизане в Switzerland2
  • SSH ключове, вградени в импланта: RSA SHA256:KlICz/B59619CpuQdGzgmmvzWBfTMUJ77EwihTYobuo и ED25519 SHA256:OfLY0uF9SwOW9xVjiMXZGDfk6Atmz6CbHy4epknLm8Y
  • Хост ключ на прехващача: ED25519 SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E, засечен при връзката на kaba

Проверете от спасителна система (rescue system) или офлайн дисков образ, ако можете. На работещ сървър влизайте само с ключ. „Никога не въвеждайте парола в сървър, в който се съмнявате, защото Ebury ще я прихване“, написа Цимер.

Стартирайте обвивка (shell) с H=1 I=1 LD_PRELOAD=":" LD_DEBUG=":" bash, за да заобиколите потребителския руткит, преди да изпълните обновения скрипт на Левейе или командите от публикацията на Цимер.

Ако го откриете, стъпките на Tor Project са:

  1. изведете релето офлайн
  2. запазете диска и журналите преди изчистване
  3. преинсталирайте, вместо да почиствате
  4. генерирайте нова идентичност на релето и третирайте старите ключове като откраднати
  5. подменете (ротирайте) всички идентификационни данни, които са били на хоста

Преинсталирането е от значение, тъй като имплантът е оцелял след рестартиране на сървъра на Цимер. Докладвайте на bad-relays@lists.torproject.org, а ако вашият IP адрес е бил блокиран по време на инцидента, пишете на същия адрес, след като хостът ви е чист, за да бъде премахната блокадата, заяви Георг Копен от Tor Project в последващо съобщение.