Ещё немного про телефоны Xiaomi и борьбу с ними

Честно признаться, у меня не было планов писать и публиковать эту статью, но, после того, как за два месяца увидел в ближнем кругу коллег 5 штук свежеприобретённых телефонов от Xiaomi, и недавнюю статью на Geektimes, рекламирующую управление умным домом от Xiaomi, ко мне пришла совесть и, сцуко, потребовала поделиться знанием с остальными.

Для начала небольшая вводная часть для тех кто не в теме. Есть такая компания Xiaomi, которая делает неплохие по начинке телефоны и заливает в них кастомизированный Android. Бизнес модель, как недавно официально было заявлено — «По сути мы раздаём наши смартфоны, не зарабатывая на этом денег. Нас больше заботят долгосрочные источники дохода. Мы могли бы продать 10 миллиардов смартфонов и не заработать на них ни цента». Источник раз и два.

Заглянув в сентябрьскую статью на Security lab и ещё вот в эту жалобу, у меня лично возникло ощущение, что телефон Xiaomi это что-то типа поводка на котором владельца водит Большой брат (утрирую, конечно же).

Это и стало основным мотивом проведения исследования поведения телефона Xiaomi redmi 3S
с прошивкой MIUI Global 8.1 Стабильная 8.1.1.0 (MALMIDI)

Исследование подопытного кролика и обнаружение проблемы
Беру новенький телефон из коробки. Включаю его и прохожу через мастера начальной настройки, предварительно включив запись трафика на Wi-Fi роутере. Ровно через две секунды, после того как телефон подключился к точке доступа, началось скачивание файла размером около 8Мбайт с одного из серверов Xiaomi. Это был обычный zip архив, внутри которого лежала куча всего и, в том числе, файл AnalyticsCore.apk, упомянутый в статье на SecurityLab.

Дальше — больше. В общей сложности, за всё время наблюдения, я насчитал чуть меньше восьми десятков имён серверов в разных доменах. Сразу оговорюсь, что в этом числе нет серверов Google и Facebook, приложения которых также предустановлены. Просто потому что я их считал отдельно. С ними тоже всё «весело».

Большая часть коннектов к серверам Xiaomi шла через HTTPS, поэтому разобраться в деталях ЧТО именно передаётся напрямую возможности не было. Отключение всевозможных логинов, синхронизаций и т.п. к исчезновению этого трафика не привело.

Дополнительно смущало то, что большей частью запросы были небольшими (объём принятого переданного трафика TCP сессий не превышал 1-2Кб), но, т.к. наши сотовые операторы округляют объём трафика вверх (Например, Tele2 до 150Кб), то, при неудачном совпадении, можно «накачать» таким образом существенные объёмы трафика, а в роуминге неожиданно попасть на деньги.

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

Предварительные условия

Первое что необходимо — это рутовать телефон. Как это делается в случае Xiaomi я здесь описывать не буду, отсылаю желающих пройти этот путь к полной версии этой статьи (ссылка в конце).
Второе — это влить в телефон прошивку через кабель и стереть ВСЕ пользовательские данные.
Третье — телефон НЕ ДОЛЖЕН иметь доступа в интернет после залива свежей прошивки.

Disclamier. Все дальнейшие манипуляции над телефоном Вы делаете на свой страх и риск.
Ответственность за любой результат лежит на том, кто именно делал описываемые ниже действия.

Небольшая техническая вводная часть

Серверы, к которым обращается телефон, в большинстве своём расположены в облаке Amazon, поэтому обращения к ним происходит по именам, которые ресолвятся через round-robin DNS в разные IP адреса из разных подсетей /16. Блокировать их все по подсетям смысла особого нет — так можно половину интернета отфильтровать, что не есть хорошо. Блокировать по именам — хорошо, но не факт, что имена хостов из L3 доменов не генерируются динамически. Идеально было бы прибить все приложения, которые обращаются к серверам Xiaomi, но, как показала практика, глубина их интеграции в Android такова, что после удаления некоторых из них телефон может просто отказаться загружаться.

Далее. К внешним серверам обращается не один процесс, а многие, при этом задачу усложняет наличие в Android UID sharing, когда под одним UID могут генерировать сетевой трафик разные процессы (приложения). Более того, один из полезных процессов (отвечающий за GPS) надо выпускать во внешний мир, чтобы скачивать небольшие обновления, но при этом он сидел под тем же UID, что и восемь штук процессов, рвущихся к серверам Xiaomi.

Также надо упомянуть про ограниченность инструментария, доступного для решения вышеописанных задач, т.к. большая часть приложений имеющих в названии firewall доступных на Play Market работают через т.н. VPN, т.е. от сливов информации до запуска приложения они не защищают.

Большая часть того, что будет дальше рассказано для профессиональных разработчиков Android есть банальная истина, но всем остальным это позволит понять почему фильтрация построена именно таким образом.

В отличие от обычного Linux, где есть файлы конфигурации и стартовые скрипты, лежащие в /etc, в Android всё сделано несколько иначе. Общее управление сетью осуществляет Connection Manager, который дёргает системный демон netd, который, в свою очередь, вызывает iptables с определёнными параметрами командной строки. Соответственно, вызывать IPtables из скрипта начальной загрузки (init и прочих) особого смысла нет — netd при старте всё равно вызовет iptables, очистит правила и зальёт свои.

Единственный выход оставленный Google — писать необходимые команды конфигурации iptables в скрипте /system/bin/oem-iptables-init.sh. Путь к этому скрипту и его имя жёстко прописаны внутри исходного кода демона netd.

Для фильтрации статических имён хостов можно редактировать файл /etc/hosts, но при этом надо помнить про их количество и возможность их динамической генерации.
Дальше будет рассказ как это всё делалось.

Удаление и заморозка (если нет уверенности) ненужных программ

При помощи бесплатной версии Titanium Backup можно посмотреть соответствие между именем программы, показываемое в системе (Play Market), её кодовым именем (com.google.vending) и, при необходимости, удалить то, что явно не нужно.

Недостаток бесплатной версии — не умеет делать заморозку программ, посему заморозку делаем через ADB shell при помощи package manager. Пример:

root@land:/ # pm disable com.miui.analytics
pm disable com.miui.analytics
Package com.miui.analytics new state: disabled
root@land:/ # pm disable com.miui.systemAdSolution
pm disable com.miui.systemAdSolution
Package com.miui.systemAdSolution new state: disabled
root@land:/ # reboot
reboot

Фильтрация сетевых запросов

Disclamier 2.В данной статье описано КАК можно фильтровать «левую» сетевую активность телефона. Что конкретно фильтровать — каждый волен решать сам.

Делаем всё по шагам:

1. Cамое простое — заполнение файла /etc/hosts записями имён серверов c IP адресом 127.0.0.1. Мой набор серверов лежит на Google Drive в папке Files.

2. пишем команды фильтрация отправки пакетов на подсети /16 и /24 стандартными правилами Netfilter/IPtables в файл oem-iptables-init.sh. Здесь их не описываю, желающие напишут их сами, либо найдут в полной версии статьи.

3. Фильтруем DNS запросы к ненужным нам доменам. Это несколько сложнее, поэтому опишу подробнее.

В составе IPtables, штатно идущем в Android есть модули расширения функционала, которыми мы дальше и воспользуемся. Помня, что DNS запросы отправляет система (UID 0) пишем правило:

$IPTABLES -A oem_out --protocol udp --dport 53 -m owner --uid-owner 0 -m string --algo bm --hex-string '|<b>04</b>6d697569<b>03</b>636f6d|' -m comment --comment "Deny UID 0 DNS queries for miui.com domain" -j DROP
#
$IPTABLES -A oem_out --protocol udp --dport 53 -m owner --uid-owner 0 -j ACCEPT

Первая строчка отфильтрует все UDP пакеты, отправленные системой (UID 0) на 53 UDP порт любого IP адреса и содержащие в себе байты 046d69756903636f6d (запросы к DNS серверу содержащие в себе .miui.com). Код формируется из названия домена, но с заменой кода точки-разделителя (2e) на шестнадцатиричную цифру количества байт, следующих за данным разделителем до следующего разделителя.

Вторая строчка пропустит все остальные DNS запросы. Комментарии я указал для удобства, чтобы команда iptables -L -v показывала результаты блокировок нагляднее.

4. Для работы Assited GPS необходимо дать возможность доступа к серверам QualComm процессу с UID 1000. Здесь всё сложнее, т.к. прямая фильтрация как в случае DNS серверов сработает — пакеты установления TCP соединения ещё содержат в себе имя хоста, которое обязательно присутствует в HTTP запросе, а пакеты идущие после заголовка HTTP запроса уже могут не содержать в себе имя хоста. Поэтому рисуем вот такой костыль для фильтрации запросов седьмого уровня средствами 3-4 уровня:

# разрешаем инициировать установление TCP соединений на 80 порт всем процессам работающим под UID 1000.
$IPTABLES -A oem_out -m owner --uid-owner 1000 --protocol tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
#проверяем наличие слова xtrapath в пакетах TCP соединений установленных  на 80 порт процессами с UID 1000  и помечаем эти соединения шестнадцатиричным числом 5555.
$IPTABLES -A oem_out -m owner --uid-owner 1000 --protocol tcp --dport 80 -m conntrack --ctstate ESTABLISHED -m string --algo bm --string 'xtrapath' -j CONNMARK --set-xmark 0x5555
# убиваем пакеты всех установленных процессами с UID 1000 TCP соединений не имеющих нашей пометки число 5555
$IPTABLES -A oem_out -m owner --uid-owner 1000 --protocol tcp --dport 80 -m conntrack --ctstate ESTABLISHED -m connmark ! --mark 0x5555 -j DROP

5. Фильтруем доступ в интернет по приложениям (у меня Google Chrome имел UID 10060). Разрешаем выход в интернет Google Chrome и запрещаем всем остальным приложениям.

$IPTABLES -A oem_out -m owner --uid-owner 10060 -m comment --comment "Permit Google Chrome internet access" -j ACCEPT
#
# Block all other processes
#
$IPTABLES -A oem_out -m owner --uid-owner 0-9999 -m comment --comment "Block all other system processes internet access" -j DROP
$IPTABLES -A oem_out -m owner --uid-owner 10000-99999 -m comment --comment "Block all other user processes internet access" -j DROP

Слабым местом этого способа фильтрации является его опора на наличие отметки UID на каждом конкретном пакете при прохождении его через Netfilter/IPtables. Обнаружилось это по непонятным TCP соединениям к серверам Google, пакеты которых не содержали UID. Исследование показало, что эти пакеты инициированы процессом Google Captive portal login. Я решил эту проблему обходным путём — просто выключив эти запросы командами в ADB shell:

root@land:/ # settings put global captive_portal_detection_enabled 0
root@land:/ # reboot

Радует, что (судя по накопленной статистике за несколько суток перехвата Wi-Fi трафика), никаких иных системных процессов отсылающих пакеты без UID в исследовавшемся телефоне нет.

6. Для целей мониторинга работы правил Netfilter/IPtables можно добавить ещё вот такую строчку:

$IPTABLES -A oem_out --source 10.1.30.42 --protocol tcp --jump LOG --log-prefix "IPtables log:" --log-uid

Параметр IP адрес отправителя (--source 10.1.30.42) можно опустить, но в этом случае лог будет завален записями сетевой активности процессов, завёрнутых на адрес 127.0.0.1 файлом hosts. Лог можно читать через команду dmesg (dmesg | grep IPtables) в ADB Shell.

Версию статьи, которая писалась как полная инструкция по решению этой проблемы с Xioami Redmi 3S я выложил на Google Drive. Сюда её выкладывать не рискнул именно из-за объёма.

P.S. Я не разработчик Android-приложений, просто жизнь заставила два месяца поразбираться с сабжевым телефоном. Посему, господа профи, если я где ошибаюсь — поправляйте. Буду признателен.

P.P.S. В качестве средства перехвата использовался Zyxel Keenetic Extra. У него есть возможность перехватывать Wi-Fi трафик и сливать его на флэшку для последующего анализа.

Автор: autuna

Источник