Remmina: что клиент удалённого доступа собирает о рабочей станции и отправляет разработчикам

Анализ телеметрии, сетевого взаимодействия и механизма установки плагинов

Автор статьи: — Гришаев Юрий, специалист по анализу защищённости веб-приложений и ПО под Windows. Тимлид в АБП2Б. Сертифицированный специалист OSCP+, багхантер.

Remmina — популярный клиент удалённого доступа для Linux, поддерживающий RDP, VNC, SSH и другие протоколы. Он входит в стандартные репозитории многих дистрибутивов и используется для подключения к удалённым серверам и рабочим станциям.

Поводом для исследования стало предупреждение о том, что Remmina передаёт на серверы разработчика отпечаток рабочей станции. Возникли вопросы: какие именно данные собирает приложение, при каких условиях они отправляются и можно ли увидеть их содержимое?

Для проверки были изучены бинарный файл клиента, сетевые запросы и процесс формирования телеметрии в изолированной среде. Все проверки проводились на Remmina 1.4.43 из официального репозитория Arch Linux. Учётные данные в примерах синтетические.

1. С чего начинается проверка

Сначала необходимо определить установленную версию приложения:

pacman -Q remmina

Затем изучим адреса серверов, зашитые в бинарный файл:

strings -n 8 /usr/bin/remmina | grep -oE 'https://[a-z.]*remmina\.org/[a-z_/]+' | sort -u

Среди обнаруженных конечных точек присутствуют handshake, upload_stats, get_list и plugin_download. Это позволяет выделить два направления взаимодействия: передачу информации о системе и работу с каталогом плагинов.

2. Что именно собирает Remmina

Встроенный режим отладки позволяет увидеть отпечаток рабочей станции до его отправки на сервер. Для его просмотра используется сочетание Ctrl+T.

В исследованном сценарии в отпечаток попадают:

• полный список процессов всех пользователей с аргументами командной строки (ps aux);

• все переменные окружения, доступные процессу Remmina;

• IP- и MAC-адреса сетевого интерфейса;

• идентификатор клиента UID, имя пользователя и hostname;

• версия операционной системы и ядра, возраст установки системы;

• окружение рабочего стола, сведения о хранилище паролей и количество профилей подключений.

Для проверки были одновременно запущены xfreerdp с подключением к другой машине и curl с тестовым токеном Bearer. Remmina включила в отпечаток сведения о сервере, домене и логине. Пароль RDP остался замаскированным самим клиентом xfreerdp. В случае curl в отпечаток попали адрес запроса и токен авторизации.

3. Перехват сетевого трафика

Для анализа сетевого взаимодействия использовался Wireshark.
При запуске клиента обнаруживаются обращения к plugins.remmina.org/plugins/get_list и info.remmina.org/info/handshake

Отмечу, что мы видим в «encdata» данные в формате base64, раскодируем их с помощью CyberChef

В результате декодирования видно, что это незашифрованные сведения о системе: имя и версия ядра, содержимое файла /etc/os-release, возраст установки системы, версия Python и список установленных плагинов с их версиями. То есть уже первый запрос при запуске передаёт описание системы в открытом, лишь закодированном Base64, виде.

Следующий запрос при запуске — POST /info/handshake. Это служебный обмен: клиент сообщает серверу свой идентификатор и узнаёт, нужно ли отправлять расширенную статистику.

В ответе на handshake присутствует поле STATS, определяющее дальнейшее поведение клиента.

Если сервер возвращает STATS=0, это означает, что сервер не нуждается в получении debug-данных от клиента. А в случае получения STATS=1 поведение меняется: клиент формирует полный отпечаток рабочей станции и отправляет его POST-запросом на /info/upload_stats. В исследованном сценарии решение о передаче полного отпечатка задавалось ответом сервера.

4. Что уходит при STATS=1

При получении STATS=1 клиент отправляет POST-запрос на /info/upload_stats.

Тело запроса содержит поле encdata. После декодирования Base64 внутри обнаруживается RSA-шифртекст, а не читаемый текст. Для расшифровки необходим соответствующий закрытый ключ, который находится у получателя данных.

5. Как удалось изучить содержимое encdata

Настоящий encdata, перехваченный в сети, расшифровать средствами исследования невозможно: закрытый ключ находится у получателя. Поэтому содержимое проверялось другим способом.

На Kali Linux был поднят изолированный контейнер Podman без доступа к сети с той же версией Remmina 1.4.43. С помощью отладчика был снят отпечаток до шифрования. Затем те же данные были зашифрованы аналогичным способом — RSA-2048, поблочно, — но собственным ключом исследователя.

Важно: настоящий encdata из сети не вскрывался. Это реконструкция на основе данных, перехваченных до шифрования, и собственного ключа. Она показывает состав отправляемой информации, но не является обходом шифрования разработчика.

6. Идентификация рабочей станции

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

• UID — постоянный идентификатор станции, формируемый с использованием имени пользователя и hostname.

• REMMINAVERSION — точная версия клиента.

• SYSTEM — версия ядра, содержимое /etc/os-release и возраст установки системы.

7. Секреты в списке процессов

Remmina включает в телеметрию полный список процессов с аргументами. В командной строке приложений нередко оказываются чувствительные данные.

xfreerdp3 /v:192.168.100.50 /u:administrator /d:CORP /p:**********

В этом примере в отпечаток попали IP-адрес сервера, имя пользователя administrator и домен CORP. Пароль был замаскирован самим клиентом.

curl -H "Authorization: Bearer eyJ..." https://api.example.com

В случае curl токен авторизации оказался виден целиком.

python3 script.py --db-password=...

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

Таким образом, маскировка пароля RDP не защищает секреты, передаваемые через другие инструменты. Токены, пароли БД и ключи, присутствующие в аргументах процессов, могут оказаться в отпечатке.

8. Переменные окружения и идентификация машины

Вторая категория потенциально чувствительных данных — переменные окружения. Remmina включает в отпечаток все переменные окружения процесса. Например:

AWS_ACCESS_KEY_ID=...\nAWS_SECRET_ACCESS_KEY=...\nGITHUB_TOKEN=...\nSLACK_BOT_TOKEN=...\nPGPASSWORD=...

Если такие значения доступны процессу Remmina, они могут попасть в собираемую телеметрию. Дополнительно передаются сетевые сведения о машине:

HOST: 192.168.100.73/24\nMAC: 08:00:27:...\nHOSTNAME: ws-07

При этом блок PROFILES, согласно результатам проверки, содержит только счётчики профилей — без адресов и логинов из сохранённых подключений.

Те же сведения можно увидеть на рабочей Arch-станции в окне отладки Remmina (Ctrl+T). На следующем скриншоте показана реальная рабочая система, а не контейнер из эксперимента.

9. Установка плагинов по команде сервера

При анализе ответов сервера обнаружилась логика обработки двух полей:

• LIST — клиент отображает каталог доступных плагинов.

• PLUGINS — клиент запускает скачивание и установку плагинов.

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

Чтобы проверить, как клиент на это отреагирует, в изолированной среде была выполнена подмена ответов сервера: запросы Remmina шли не на настоящий plugins.remmina.org, а на локальный сервер. С него и пришёл ответ с полем PLUGINS — по сути команда «установить» сторонний плагин.

После этого Remmina самостоятельно распаковала полученные данные и начала установку. Действия в интерфейсе для запуска процесса не потребовались. В системном журнале видно, как клиент создаёт временный файл с присланным плагином и открывает его для проверки подписи. Само появление этого файла означает, что установка уже началась, и запустил её ответ сервера, а не пользователь.

Установка завершилась отказом: тестовый плагин не был подписан доверенным ключом, поэтому клиент отклонил его и удалил.

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

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

10. Подтверждение механизма в бинарном файле

Для дополнительной проверки были изучены строки бинарного файла:

strings -n 8 /usr/bin/remmina | grep -oE 'https://[a-z.]*remmina\\.org/[a-z_/]+' | sort -ustrings /usr/bin/remmina | grep -xE 'PLUGINS|LIST|STATS|signature|selected_plugins|encdata'strings /usr/bin/remmina | grep -iE 'Plugin download|No plugins selected'

Обнаружен адрес plugins.remmina.org/plugins/plugin_download, а также поля PLUGINS, LIST, STATS и строки, связанные с проверкой подписи.

Адрес plugin_download используется обработчиком ответа сервера remmina_plugin_manager_on_response, который анализирует ответ и запускает загрузку при наличии соответствующего поля.

Это подтверждает, что механизм удалённого управления загрузкой плагинов является частью штатного кода исследованной версии клиента.

Что показало исследование

• Исследованная сборка Remmina 1.4.43 из официального репозитория Arch Linux обращается к серверам разработчика и передаёт идентификатор машины и сведения о системе.

• При ответе STATS=1 клиент отправляет полный отпечаток станции, включающий список процессов с аргументами и переменные окружения.

• В отпечаток могут попадать секреты из аргументов процессов и переменных окружения. Пароль RDP в проверенном примере был замаскирован самим клиентом.

• Телеметрия шифруется RSA-ключом получателя. Её состав был подтверждён перехватом до шифрования и реконструкцией на собственном ключе.

• Сервер может инициировать загрузку и попытку установки плагинов без отдельного подтверждения пользователя. Установка ограничена проверкой цифровой подписи.

От анализа к практике: зачем нужны пентесты

Исследование Remmina показывает, почему при проверке безопасности важно изучать не только очевидные функции приложения, но и его поведение в реальных условиях. Передача данных, работа с конфиденциальной информацией и механизмы удалённой загрузки компонентов могут создавать риски, которые сложно заметить при обычном использовании. Подобные задачи лежат и в основе пентестов АБП2Б: проверка защищённости систем помогает выявить потенциальные уязвимости, оценить возможные последствия и определить, насколько инфраструктура готова противостоять реальным атакам.

Итоги и рекомендации

Исследование Remmina 1.4.43 на Arch Linux показало, что клиент может собирать значительно больше информации, чем требуется для непосредственного подключения к удалённым машинам. Наиболее существенный риск связан с включением в отпечаток полного списка процессов и переменных окружения: там могут находиться токены авторизации, пароли баз данных и другие секреты.

Отдельного внимания заслуживает механизм управления плагинами. Сервер способен инициировать их загрузку и попытку установки без отдельного подтверждения пользователя. При этом в эксперименте неподписанный тестовый модуль был отклонён, а выполнение произвольного подписанного плагина не проверялось.

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