В качестве предварительного замечания напомню, что надлежащее в смысле правильности использование шифрования — это *очень* дорого.

Ну и история: примерно 16-го октября сего года обнаружился нежданчик…

20-го ближе к вечеру (к вопросу о скорости реакции) прилетело оповещение:

(19:04:06) jabber.ru: Сервера jabber.ru и xmpp.ru подверглись MitM атаке со стороны хостинга.

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

Подробности атаки по ссылке: http://notes.valdikss.org.ru/jabber.ru-mitm/

Вопросы можно задать в support@conference.jabber.ru

---

Почему-то на наглицком, что с учётом целевой аудитории скорее странно. Даю в переводе (ручками лень, редактура результатов работы сервиса deepl):

Перехват зашифрованного трафика крупнейшего российского сервиса обмена сообщениями XMPP (Jabber) германскими провайдерами Hetzner и Linode

ValdikSS 21st October 2023 at 2:57pm

TL;DR: обнаружен перехват зашифрованных TLS-соединений протокола обмена мгновенными сообщениями XMPP (Jabber) (атака Man-in-the-Middle) на серверах сервиса jabber.ru (он же xmpp.ru) на хостинг-провайдерах Hetzner и Linode в Германии.

Злоумышленнику удалось издать TLS-сертификатов домена jabber.ru с помощью сервиса Let's Encrypt, которые использовались для подстановки на место сервера jabber.ru прозрачного MiTM-прокси. Атака была обнаружена в результате истечения срока действия одного из сертификатов MiTM, который не был своевременно обновлён.

Признаков взлома сервера или spoofing-атак в сетевом сегменте не обнаружено, скорее наоборот: перенаправление трафика было настроено в сети хостинг-провайдера.

Прослушивание могло продолжаться в общей сложности до 6 месяцев (подтверждено 90 дней). Мы считаем, что это законный перехват, который вынуждены были организовать Hetzner и Linode.

Последнее значимое обновление: 20 октября 2023 г.

Предварительные замечания

oxpa, опытный администратор UNIX, отвечающий за работу старейшего российского XMPP-сервиса jabber.ru, основанного в 2000 году, 16 октября 2023 года был озадачен сообщением об истечении срока действия сеортификата при подключении к сервису. На сервере все сертификаты вроде бы были актуальны, но при подключении к порту 5222 (XMPP STARTTLS) клиенту предъявлялся устаревший сертификат.

В ходе всевозможных проверок программного обеспечения, сети и конфигурации с помощью других специалистов и автора программы ejabberd было обнаружено, что:

• В сетевом трафике используется правильный, непросроченный сертификат;
• Просроченный сертификат отсутствует на сервере;
• Он основан на другом закрытом ключе и никогда не выдавался скриптом выпуска сертификатов acme.sh сервера;
• Входящие TCP-соединения на порт 5222 изменяются: они имеют другой порт источника, номера SEQ/ACK и, похоже, приходят без промежуточных хопов маршрутизации (TTL=64);
• Такое поведение не наблюдается на других портах, не относящихся к порту 5222, например, на порту 5223 XMPP TLS.

Затронутыми машинами являются выделенный сервер на Hetzner и два виртуальных сервера на Linode, расположенные в Германии.

Дамп трафика на порт 5223, все данные в порядке, как и должно быть.

Дамп трафика на порт 5222, соединение перехвачено на уровне приложения (L7), сервер получает от клиента замененное сообщение ClientHello.

Расследование инцидента

Было обнаружено, что соединения по порту 5222 подвергаются атаке Man-in-the-Middle, которая перехватывает зашифрованные сообщения.

Сначала нам предстояло проверить две гипотезы: не взломаны ли серверы и не изменяется ли трафик в результате подмены локальной сети (соседа).

Для сервера мы проверили:

• Все виды журналов;
• Дату модификации исполняемых файлов и библиотек;
• Запущенные процессы, карты памяти и описания "висячих" файлов каждого из них;
• Наличие пользовательских LD_PRELOAD-библиотек для перехвата со статически скомпилированным busybox;
• Наличие модулей взлома на уровне ядра путем дампа памяти ядра с помощью LiME и анализа с помощью volatility.

Но ничто не выделялось. Мы заметили единственную необычную запись в журнале ядра на выделенной машине Hetzner - 18 июля 2023 года она потеряла физическое сетевое соединение на 19 секунд:

[Tue Jul 18 12:58:29 2023] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Down
[Tue Jul 18 12:58:48 2023] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX

Кроме того, машины Linode используются только как туннель к серверу Hetzner в качестве альтернативного маршрута, и на них работают только базовые сервисы, такие как SSH и NTP.

Тем не менее, мы видим неизмененный пакет ServerHello от сервера Hetzner в туннеле Hetzner↔Linode на машине Linode, о чем предупреждается при его отправке клиенту через сетевой интерфейс Linode. Другими словами, перехват шифрованного соединения одного и того же вида происходит как на выделенной машине Hetzner, так и на VPS-машине Linode.

Со стороны сети мы проверили:

• Был ли изменен MAC-адрес шлюза с помощью ARP-spoofing;
• Отвечает ли какой-либо один IP-адрес в сегменте L2 несколько раз на ARP-запрос;
• присутствуют ли в таблице маршрутизации неавторизованные правила маршрутизации (инжектированные, например, с помощью ICMP-переадресации);
• Правила Netfilter;
• Наличие нетривиальных для обнаружения туннелей, таких как IPsec (ip xfrm).

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

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

На машинах Linode вообще нет соседей, кроме маршрутизатора. Затронутые машины Linode не могут выполнить ARP-обнаружение или пинг соседних IP-адресов в том же сегменте сети, которые прекрасно работают из внешней сети.

"Странно", - подумал я.

Незатронутая (сторонняя) ВМ Linode может пинговать своих соседей. Она подключена к маршрутизатору системы Cisco:

# ip neigh
172.104.234.1 dev eth0 lladdr 00:00:0c:9f:f0:05 REACHABLE

OUI lookup:
00:00:0C Cisco Systems, Inc

Однако затронутые VPS подключены к некоему неопознанному MAC-адресу:

# ip neigh
172.104.226.1 dev eth0 lladdr 90:de:01:49:76:ae REACHABLE

OUI lookup:
(no matches)

Выяснилось, что затронутые ВМ Linode имеют нестандартную настройку сети по сравнению с обычными экземплярами Linode, возможно, они были выделены в отдельную VLAN.

Сертификаты

После проверки открытой базы сертификатов crt.sh были обнаружены неавторизованные сертификаты, которые не были выданы ни одним из серверов jabber.ru.

В службе XMPP используются два подлинных сертификата: один выдан для xmpp.ru, *.xmpp.ru, а другой - для jabber.ru, *.jabber.ru.

Сертификаты, изданные атакующим (злоумышленником) несколько отличаются от обычных сертификатов для этих доменов: либо отсутствует подстановочный знак Subject Alternative Name, либо выпущен один сертификат для jabber.ru, xmpp.ru. Кроме того, конфигурация MiTM на домене xmpp.ru (который указывает на серверы Linode) была несколько неверно настроена: он обслуживает только сертификат xmpp.ru, в то время как оригинальный сервер настроен на обслуживание сертификатов jabber.ru и xmpp.ru в зависимости от запрашиваемого XMPP-домена.

Список левых сертификатов:

Domain	Serial	Not Before	Not After	Used in MiTM
xmpp.ru	03:f3:68:ee:36:30:80:6a:07:81:17:81:04:0c:e3:d9:10:b1	Jul 18 12:49:03 2023 GMT	Oct 16 12:49:02 2023 GMT	+
xmpp.ru	04:9c:2d:af:cc:61:88:d6:67:9f:8b:97:99:ce:ad:c9:b7:e0	Oct 13 11:21:30 2023 GMT	Jan 11 11:21:29 2024 GMT	+
jabber.ru	03:43:75:1f:3d:80:20:7d:11:f5:61:98:5b:87:a7:37:81:c6	Apr 18 10:23:29 2023 GMT	Jul 17 10:23:28 2023 GMT	?
jabber.ru	04:4c:1c:8a:f4:37:a0:5a:dd:83:9c:54:74:89:bd:b9:97:90	Jul 18 12:38:51 2023 GMT	Oct 16 12:38:50 2023 GMT	+
jabber.ru, xmpp.ru	04:d1:d2:5d:09:95:48:9b:d6:14:cc:81:91:df:ac:7f:ec:c6	Apr 25 05:46:23 2023 GMT	Jul 24 05:46:22 2023 GMT	?
jabber.ru, xmpp.ru	04:b7:85:83:9a:fd:df:81:26:48:5b:34:28:08:53:d9:e6:79	Apr 25 06:04:19 2023 GMT	Jul 24 06:04:18 2023 GMT	+

Время выдачи 18 июля 2023 года - это примерно то же самое время, когда сервер Hetzner на несколько секунд потерял связь с сетью.

У нас есть подтверждение от внешнего сетевого сканера, что серверы Linode начали использовать сертификат 04:b7:85... на порту 5222 как минимум с 21 июля 2023 года. К сожалению, этот сканер не обрабатывает диапазоны Hetzner.

Сеть

Мы решили провести дополнительные сетевые тесты Linode VPS извне машины.

Все соседние хосты Linode доступны по 13-му хопу с интернет-соединения моего ноутбука.

# lft -d 22 172.104.226.23
Tracing ............*T
TTL LFT trace to 172-104-226-23.ip.linodeusercontent.com (172.104.226.23):22/tcp
 1  _gateway (192.168.100.1) 31.2ms
…
 9  a23-210-52-59.deploy.static.akamaitechnologies.com (23.210.52.59) 67.0ms
10  10.210.32.1 62.1ms
**  [neglected] no reply packets received from TTL 11
12  10.210.3.93 67.5ms
13  [target open] 172-104-226-23.ip.linodeusercontent.com (172.104.226.23):22 67.4ms

А также перехваченный порт 5222 на сервере dawn.jabber.ru Linode:

# lft -d 5222 dawn.jabber.ru
Tracing ............**.T
TTL LFT trace to dawn.jabber.ru (172.104.226.29):5222/tcp
 1  _gateway (192.168.100.1) 29.3ms
…
 9  a23-210-52-57.deploy.static.akamaitechnologies.com (23.210.52.57) 64.9ms
10  10.210.32.2 64.7ms
**  [neglected] no reply packets received from TTL 11
12  10.210.1.235 60.7ms
13  [target open] dawn.jabber.ru (172.104.226.29):5222 60.2ms

Однако все остальные не взломанные порты, такие как SSH-порт 22, доступны только через дополнительный нераскрытый хоп и теперь достижимы только через хоп 14:

# lft -d 22 dawn.jabber.ru
Tracing ............?*?**.?T
TTL LFT trace to dawn.jabber.ru (172.104.226.29):22/tcp
 1  _gateway (192.168.100.1) 28.8ms
…
 9  a23-210-52-57.deploy.static.akamaitechnologies.com (23.210.52.57) 65.4ms
10  10.210.32.2 66.2ms
**  [neglected] no reply packets received from TTL 11
12  10.210.1.235 61.7ms
**  [neglected] no reply packets received from TTL 13
14  [target open] dawn.jabber.ru (172.104.226.29):22 61.1ms

Это означает, что IP-адрес Linode VM был размещен за дополнительной машиной, которая самостоятельно обрабатывает TCP-порт 5222 и направляет другие порты к реальному адресату.

Изнутри VPS невозможно установить новые соединения с использованием порта источника 5222. Маршрутизатор не отвечает на пакеты, исходящие с этого порта, а также не отправляет ICMP-ошибки или сообщения о превышении времени жизни для исходящих пакетов TTL=0 или TTL=1.

# curl -v -4 --max-time 10 --local-port 5222 ifconfig.co

tcpdump:

23:37:46.116991 IP 172.104.226.29.xmpp-client > 172.64.170.5.http: Flags [S], seq 4385521, win 64240, options [mss 1360,sackOK,TS val 758380820 ecr 0,nop,wscale 7], length 0
23:37:47.135972 IP 172.104.226.29.xmpp-client > 172.64.170.5.http: Flags [S], seq 4385521, win 64240, options [mss 1360,sackOK,TS val 758381839 ecr 0,nop,wscale 7], length 0
23:37:49.189189 IP 172.104.226.29.xmpp-client > 172.64.170.5.http: Flags [S], seq 4385521, win 64240, options [mss 1360,sackOK,TS val 758383892 ecr 0,nop,wscale 7], length 0

Прекращение работы STARTTLS

С помощью скрипта тестирования SSL/TLS testssl.sh было обнаружено, что перехватывающий прокси-сервер принимает соединения с анонимными шифрами как на Linode (xmpp.ru), так и на Hetzner (jabber.ru).

Это редкая ошибка настройки, которая может быть использована в качестве одного из признаков для обнаружения XMPP MiTM. В типовой конфигурации библиотеки SSL/TLS обычно компилируются без поддержки анонимных шифров, вы не сможете настроить свой сервис на использование анонимных шифров, даже если в большинстве случаев явно разрешите это в конфигурационном файле, и это подтверждается тем, что на оригинальном сервере они не настроены.

$ ./testssl.sh --starttls xmpp --xmpphost jabber.ru --standard --openssl-timeout 15 --connect-timeout 15 jabber.ru:5222 

###########################################################
    testssl.sh       3.0.8 from https://testssl.sh/
    (abdd51d 2022-09-28 09:19:37)

      This program is free software. Distribution and
             modification under GPLv2 permitted.
      USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!

       Please file bugs @ https://testssl.sh/bugs/

###########################################################

 Using "OpenSSL 1.0.2-bad (1.0.2k-dev)" [~179 ciphers]
 on val:./bin/openssl.Linux.x86_64
 (built: "Sep  1 14:03:44 2022", platform: "linux-x86_64")


 Start 2023-10-18 23:39:14        -->> 116.202.237.43:5222 (jabber.ru) <<--

 rDNS (116.202.237.43):  utro.jabber.ru.
 Service set:            STARTTLS via XMPP (XMPP domain=\'jabber.ru\')

 Testing cipher categories 

 NULL ciphers (no encryption)                  not offered (OK)
 Anonymous NULL Ciphers (no authentication)    offered (NOT ok)    ←←←
…

Мы протестировали около 20 других популярных XMPP-сервисов на тот же метод MiTM с помощью одной и той же команды testssl.sh и не обнаружили никаких аномалий (нет поддержки анонимных NULL-шифров).

Итоги и финал

• Злоумышленнику удалось выпустить несколько SSL/TLS-сертификатов через Let's Encrypt для доменов jabber.ru и xmpp.ru с 18 апреля 2023 года;
• Атака "человек посередине" для расшифровки XMPP-трафика клиентов jabber.ru/xmpp.ru подтверждена как минимум с 21 июля 2023 года по 19 октября 2023 года, возможно (не подтверждено) с 18 апреля 2023 года, затронула 100% соединений с XMPP STARTTLS портом 5222 (не 5223);
• Злоумышленник не успел перевыпустить TLS-сертификат, и MiTM-прокси начал обслуживать просроченный сертификат на порту 5222 для домена jabber.ru (Hetzner);
• Атака MiTM прекратилась вскоре после того, как мы начали расследование и тестирование сети 18 октября 2023 г., а также написали тикеты Хетцнеру и в службу поддержки Linode, однако пассивная прослушка (дополнительный хоп маршрутизации) все еще имеет место, по крайней мере, на одном сервере Linode;
• Ни на одном из серверов не обнаружено признаков взлома;
• И сеть Hetzner, и сеть Linode, похоже, были перенастроены специально для такого рода атак для IP-адресов службы XMPP.

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

Конечные зашифрованные сообщения, такие как OMEMO, OTR или PGP, защищены от перехвата только в том случае, если обе стороны подтвердили ключи шифрования. Пользователям предлагается проверить свои учетные записи на наличие новых несанкционированных ключей OMEMO и PGP в хранилище PEP и сменить пароли.

Мы склонны предположить, что этот беспредел санкционирован властями Германии, который Хетцнер и Linode были вынуждены учинить по требованию немецкой полиции.

Другим возможным, хотя и гораздо более маловероятным сценарием является вторжение во внутренние сети Hetzner и Linode, направленное именно на jabber.ru - в это гораздо сложнее поверить, но полностью исключать этот вариант нельзя.

По состоянию на 20 октября 2023 года мы все еще ждем адекватного ответа от Hetzner и Linode на наши запросы.

Можно ли предотвратить или отследить такую атаку?

Существует несколько признаков, по которым можно обнаружить атаку с первого дня:

• Все выпущенные SSL/TLS-сертификаты регистрируются в открытой базе. Стоит настроить мониторинг базы сертификатов, например с помощью Cert Spotter (исходники на github), который будет уведомлять вас по электронной почте о новых сертификатах, выпущенных для ваших доменных имен;
• Ограничить методы проверки и установить точный идентификатор учетной записи, которая может выпускать новые сертификаты, с помощью расширений записей Certification Authority Authorization (CAA) Record Extensions for Account URI и Automatic Certificate Management Environment (ACME) Method Binding (RFC 8657), чтобы предотвратить выпуск сертификатов для вашего домена с использованием других центров сертификации, учетных записей ACME или методов проверки;
• Отслеживайте изменения сертификатов SSL/TLS на всех ваших сервисах с помощью внешнего сервиса;
• Отслеживать изменения MAC-адреса шлюза по умолчанию;
• "Привязка к каналу" - это функция в XMPP, которая может обнаружить MiTM, даже если перехватчик предъявляет действительный сертификат. Для того чтобы эта функция работала, и клиент, и сервер должны поддерживать механизмы аутентификации SCRAM PLUS. К сожалению, на момент атаки на jabber.ru этот механизм не был активен.

Другие рекомендации от разработчика ACME Хьюго Ландау.

---

Наглядной иллюстрацией рисков вхождения в чужую техносферу.

И справедливости вывода заметки, как раз посвящённой проблеме суверенитета в информационных технологиях о необходимости забивания болта на совместимость с информационной инфраструктурой «партнёров».

Эх, уже принесли пересказ с опеннета… Не буду выдерживать.

Дополнение: помнится некоторое время тому назад аналогичное приключение было у родственного, но стоявшего на более гибких позициях относительно выбора хостинга родственного проекта ГА (ныне — glav.su). Никто не помнит описания, если оно вообще было?

---

Дополнение

3 ноября

С 20 октября 2023 г. мы не получили никакого внятного ответа ни от Hetzner, ни от Linode по поводу данного инцидента. Запросы были отправлены в виде официальных обращений в службу поддержки со всей доказательной информацией, написанных в четкой и понятной форме со следующей формулировкой (фрагмент):

Прошу срочно исследовать сеть с IP-адресом XXX и особенно помещения вашей сети.

Я глубоко убежден, что Ваш маршрутизатор или другое сетевое устройство были перенастроены на перехват соединений с XXX либо злонамеренно (хакерами), либо самим (хостинг-провайдером) в связи с требованиями законодательства.

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

Единственный ответ от Hetzner:

Я ссылаюсь на билет № XXX. К сожалению, здесь мы не можем предложить никаких других решений. Из Вашего ответа я понял, что проблема решена.

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

Спасибо за понимание.

И от Linode:

Здравствуйте,

Благодарим Вас за предоставленные журналы. На данный момент мы не обнаружили никаких противоправных действий, влияющих на ваши услуги, и закрываем этот тикет.

С уважением,

Akamai