Шифрованный перехват: Как jabber.ru стал целью MiTM
Введение
oxpa, опытный администратор UNIX, ответственный за старейший российский сервис XMPP jabber.ru, основанный в 2000 году, столкнулся с сообщением "Срок действия сертификата истек" при подключении к сервису 16 октября 2023 года. Все сертификаты на сервере казались актуальными, однако при подключении к порту 5222 (XMPP STARTTLS) клиенту представлялся устаревший сертификат.
Во время всех видов проверок программного обеспечения, сети и конфигурации с помощью других профессионалов и автора программного обеспечения ejabberd, было обнаружено, что:
Пострадавшие машины представляют собой выделенный сервер на Hetzner и два виртуальных сервера на Linode, все размещены в Германии.
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, все размещены в Германии.
Расследование инцидента
Было очевидно, что соединения на порту 5222 подвергаются атаке Man-in-the-Middle, перехватывающей зашифрованные коммуникации.
Сначала у нас было 2 гипотезы для проверки: были ли серверы взломаны и был ли трафик изменен из-за какого-то вида локального сетевого (соседского) подмены.
Для сервера мы проверили:
Но ничего не выделялось. Мы заметили только необычную запись в журнале ядра на выделенной машине Hetzner, она потеряла физическую сетевую связь в течение 19 секунд 18 июля 2023 года:
[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, так и на машинах Linode VPS.
Примечание о сбросе памяти ядра: Linode VPS работает с ядром, скомпилированным Linode, которое загружается гипервизором и отсутствует в образе VM. Исходный код ядра Linode не распространяется. К счастью, есть встроенная конфигурация сборки в , и ядро собрано с полной картой символов , которая может быть извлечена из и достаточна для анализа дампа.
С точки зрения сети мы проверили:
Никаких признаков перехвата соседями по сетевому сегменту ни на одном из серверов нет, ничего необычного в конфигурации сети нет. Хотя все еще не редкость видеть недостаточную защиту от спуфинга на физических сетях для выделенных серверов, трудно поверить, что такой сложный скрытый спуфинг возможен на виртуальной инфраструктуре.
На машинах 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.
Было очевидно, что соединения на порту 5222 подвергаются атаке Man-in-the-Middle, перехватывающей зашифрованные коммуникации.
Сначала у нас было 2 гипотезы для проверки: были ли серверы взломаны и был ли трафик изменен из-за какого-то вида локального сетевого (соседского) подмены.
Для сервера мы проверили:
- Все виды логов
- Дату изменения исполняемых файлов и библиотек
- Запущенные процессы, таблицы памяти и описания "висячих" файлов каждого из них
- Наличие пользовательских библиотек LD_PRELOAD, перехватывающих статически скомпилированный busybox
- Наличие модулей перехвата на уровне ядра путем дампа памяти ядра с помощью LiME и анализа с помощью volatility
Но ничего не выделялось. Мы заметили только необычную запись в журнале ядра на выделенной машине Hetzner, она потеряла физическую сетевую связь в течение 19 секунд 18 июля 2023 года:
[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, так и на машинах Linode VPS.
Примечание о сбросе памяти ядра: Linode VPS работает с ядром, скомпилированным Linode, которое загружается гипервизором и отсутствует в образе VM. Исходный код ядра Linode не распространяется. К счастью, есть встроенная конфигурация сборки в , и ядро собрано с полной картой символов , которая может быть извлечена из и достаточна для анализа дампа.
С точки зрения сети мы проверили:
- Изменение MAC-адреса шлюза с помощью ARP-спуфинга
- Ответы какого-либо единственного IP-адреса в сегменте L2 несколько раз на запрос ARP
- Наличие неавторизованных правил маршрутизации в таблице маршрутизации (инъекция, например, с помощью ICMP redirect)
- Правила Netfilter
- Наличие трудно обнаруживаемых туннелей, таких как IPsec (ip xfrm)
Никаких признаков перехвата соседями по сетевому сегменту ни на одном из серверов нет, ничего необычного в конфигурации сети нет. Хотя все еще не редкость видеть недостаточную защиту от спуфинга на физических сетях для выделенных серверов, трудно поверить, что такой сложный скрытый спуфинг возможен на виртуальной инфраструктуре.
На машинах 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-домена.
Список неавторизованных сертификатов представлен, с датой выпуска 18 июля 2023 года, совпадающей с потерей сетевого соединения на сервере Hetzner. С 21 июля 2023 года Linode сервера начали обслуживать сертификат 04:b7:85... на порту 5222, подтверждено внешним сканером сети.
После проверки базы данных сертификатов 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-домена.
Список неавторизованных сертификатов представлен, с датой выпуска 18 июля 2023 года, совпадающей с потерей сетевого соединения на сервере Hetzner. С 21 июля 2023 года Linode сервера начали обслуживать сертификат 04:b7:85... на порту 5222, подтверждено внешним сканером сети.
Сеть
Было решено провести дополнительные сетевые тесты 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 или Time-to-Live Exceeded для исходящих пакетов с 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
Было решено провести дополнительные сетевые тесты 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 или Time-to-Live Exceeded для исходящих пакетов с 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 обычно компилируются без поддержки анонимных шифров, и вы не сможете настроить свою службу на использование анонимных шифров, даже если явно разрешите это в файле конфигурации. Проверка около 20 других популярных сервисов XMPP на тот же метод MiTM не выявила аномалий (отсутствует поддержка анонимных NULL шифров).
С помощью скрипта для тестирования SSL/TLS testssl.sh было обнаружено, что перехватывающий прокси принимает соединения с анонимными шифрами на Linode (xmpp.ru) и Hetzner (jabber.ru).
Это редкая (неправильная) конфигурация, которая может быть использована как один из вариантов обнаружения XMPP MiTM. Обычные библиотеки SSL/TLS обычно компилируются без поддержки анонимных шифров, и вы не сможете настроить свою службу на использование анонимных шифров, даже если явно разрешите это в файле конфигурации. Проверка около 20 других популярных сервисов XMPP на тот же метод MiTM не выявила аномалий (отсутствует поддержка анонимных 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 между этими датами следует считать скомпрометированными. Учитывая характер перехвата, злоумышленник мог выполнить любое действие так, как будто оно выполняется с авторизованной учетной записи, не зная пароля учетной записи. Это означает, что злоумышленник мог скачать список учетных записей, всю незашифрованную историю сообщений на сервере, отправлять новые сообщения или изменять их в режиме реального времени.
Шифрованные сообщения "End-to-end", такие как OMEMO, OTR или PGP, защищены от перехвата только в том случае, если обе стороны подтвердили ключи шифрования. Пользователям предлагается проверить свои учетные записи на наличие новых посторонних ключей OMEMO и PGP в хранилище PEP и сменить пароли.
Мы склонны предположить, что это законный перехват, который Hetzner и Linode были вынуждены организовать по требованию немецкой полиции.
Другим возможным, хотя и гораздо более маловероятным сценарием является проникновение во внутренние сети Hetzner и Linode, ориентированное именно на jabber.ru - в это гораздо сложнее поверить, но совсем не исключено.
По состоянию на 20 октября 2023 года мы все еще ждем адекватного ответа от Hetzner и Linode на наши запросы.
Злоумышленнику удалось выпустить несколько 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 между этими датами следует считать скомпрометированными. Учитывая характер перехвата, злоумышленник мог выполнить любое действие так, как будто оно выполняется с авторизованной учетной записи, не зная пароля учетной записи. Это означает, что злоумышленник мог скачать список учетных записей, всю незашифрованную историю сообщений на сервере, отправлять новые сообщения или изменять их в режиме реального времени.
Шифрованные сообщения "End-to-end", такие как OMEMO, OTR или PGP, защищены от перехвата только в том случае, если обе стороны подтвердили ключи шифрования. Пользователям предлагается проверить свои учетные записи на наличие новых посторонних ключей OMEMO и PGP в хранилище PEP и сменить пароли.
Мы склонны предположить, что это законный перехват, который Hetzner и Linode были вынуждены организовать по требованию немецкой полиции.
Другим возможным, хотя и гораздо более маловероятным сценарием является проникновение во внутренние сети Hetzner и Linode, ориентированное именно на jabber.ru - в это гораздо сложнее поверить, но совсем не исключено.
По состоянию на 20 октября 2023 года мы все еще ждем адекватного ответа от Hetzner и Linode на наши запросы.
