John Wu (разработчик Magisk, популярного приложения для получения и управления правами суперпользователя в Android) обнаружил, что компания Huawei использовала собственные недокументированные API, чтобы дать пользователям возможность установить сервисы Google на недавно вышедшие смартфоны серии Mate 30.

В результате санкций со стороны США, смартфоны Mate 30 вышли без поддержки приложений и сервисов Google. Очень быстро был обнаружен способ обойти ограничение — достаточно скачать и установить приложение с сайта lzplay.net, после чего следовать содержащимся в нём инструкциям. Это давало доступ ко всем сервисам Google, включая Google Pay.

Джон разобрал приложение с помощью APKTool и обнаружил странные разрешения в AndroidManifest.xml:

<uses-permission android:name="com.huawei.permission.sec.MDM_APP_MANAGEMENT"/>
<uses-permission android:name="com.huawei.permission.sec.MDM_INSTALL_SYS_APP"/>
<uses-permission android:name="com.huawei.permission.sec.MDM_INSTALL_UNDETACHABLE_APP"/>
<uses-permission android:name="com.huawei.systemmanager.permission.ACCESS_INTERFACE"/>

Поиски привели его к документации, относящейся к чему-то под названием Huawei Security Authorization SDK. Оказалось, что Huawei встраивает в Android свой собственный набор API для управления устройствами (MDM, предназначается для корпораций, которым требуется защищать данные на устройствах сотрудников). Android уже имеет в своём составе такие инструменты: API Device Administration и Android Enterprise. Сравнение их с предлагаемыми Huawei показыват, что решение китайской корпорации позволяет более гибко управлять подконтрольными устройствами, но, в целом, все описанные возможности характерны для MDM и не вызывают подозрений.

Однако, внимательные читатели могли заметить, что два разрешения из числа используемых LZPlay не документированы:

<uses-permission android:name="com.huawei.permission.sec.MDM_INSTALL_SYS_APP"/>
<uses-permission android:name="com.huawei.permission.sec.MDM_INSTALL_UNDETACHABLE_APP"/>

Таким образом, в сборках Android, поставляемых Huawei, есть две недокументированные возможности, позволяющие любому доверенному приложению устанавливать системные приложения и неотключаемые приложения. Опытные пользователи Android, конечно, знают, как при разблокированном загрузчике через кастомное рекавери «прошить приложение в системный раздел», чтобы дать ему больше прав. Но наш случай совсем иной:

  1. загрузчик заблокирован и включён режим Android Verified Boot.
  2. Huawei использует для разделов system/vendor/product сжатую файловую систему EROFS, позволяющую только чтение.

Это означает, что системный фреймворк в операционной системе Huawei содержит «бэкдор», который позволяет доверенному приложению пометить обычное приложение как системное, несмотря на то, что это приложение отсутствует в /system.

Согласно документации, сторонние разработчики/компании должны подписать юридические соглашения и отправить их в Huawei, чтобы получить доступ к SDK. Для каждого проекта разработчик отправляет отдельный запрос и обоснование, а также список разрешений, которые он хочет получить. Кроме того, каждый бинарный файл APK изучается специалистами Huawei, только после этого он будет подписан специальным ключом Huawei.

Очевидно, что Huawei осведомлена о приложении LZPlay и явно одобряет его существование. Разработчик этого приложения каким-то образом узнал об этих недокументированных API, подписал юридические соглашения, прошёл все этапы проверки и получил в конце концов подпись Huawei. Единственная цель приложения — установить сервисы Google на устройство, не прошедшее сертификацию Google.

Даже если закрыть глаза на то, что такое поведение явно нарушает все мыслимые условия использования сервисов Google, подобный бэкдор всё равно не должен существовать — хотя бы с точки зрения безопасности. Системные приложения имеют расширенные права лишь по одной причине: они размещены в криптографически верифицированном разделе, доступном только для чтения. Несмотря на то, что сертификат, позволяющий превратить обычное приложение в системное, хранится у доверенной (если вы, конечно, доверяете Huawei) стороны, а также требуется, чтобы пользователь разрешил приложению быть администратором устройства, если приложение размещено в доступном для записи разделе (userdata), оно не должно рассматриваться как системное.

Анализ приложения LZPay затруднён, в связи с тем, что оно обфусцировано/зашифровано с помощью ПО китайского разработчика QiHoo Jiagu. Кроме того, самое интересное — системный фреймворк, а он доступен только на устройствах Huawei, которые у Джона Ву нет. Возможно, если его поковырять, найдутся и другие недокументированные возможности…

Вскоре после публикации статьи, сайт LZPlay был закрыт без объяснения причин. Незамедлительно последовал и ответ Google: смартфоны Mate 30 перестали проходить проверку SafetyNet, что делает невозможным использование Google Pay.

Комментарии (8)


  1. dartraiden Автор
    02.10.2019 21:47
    +2

    Для тех, кто таки не понял всю схему:

    пользователь скачивает и устанавливает приложение (штатно, из недоверенного источника) > назначает его администратором устройства (штатная функция Android) > приложение обладает подписью Huawei, благодаря чему сборка Android от Huawei выдаёт ему недокументированные права, отсутствующие в «чистом» Android > приложение устанавливает сервисы Google в userdata и говорит операционной системе «считай их системными, хоть они и не в /system» > PROFIT.

    Если даже это и не «бэкдор» (хотя, автор исходной статьи употребляет именно такой термин), то всё равно нехорошо пахнет.


    1. AtachiShadow
      02.10.2019 22:54
      +1

      Я бы всё-таки назвал это «бэкдором». Так как, для активации этой нештатной надстройки нужно приложение, которое НЕ требует от вас рут прав, то есть — обычное приложение. Это обычное приложение позволяет любому другому приложению стать системным — то есть это «Повышение привилегий» из терминологии уязвимостей, которое в принципе способно привести к произвольному исполнению кода на уровне рута.
      То есть, на лицо — НАМЕРЕННО реализуемая возможность повышения прав, а раз намеренно, значит «бэкдор».


      1. vm03
        03.10.2019 08:30

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


        приложение устанавливает сервисы Google в userdata и говорит операционной системе «считай их системными, хоть они и не в /system

        При обновлении сервисы гугл, точно так же ставятся в data. Контроль идёт по публичному ключу находящемся в system. Тут в целом такая же ситуация.


        1. screwer
          03.10.2019 16:01

          Зашел написать точно такой же коммент!


        1. AtachiShadow
          03.10.2019 20:34

          Ну есть всё-таки небольшая разница между собранными вместе с прошивкой приложениями (которые имеют рут привилегии) и приложением которое устанавливается после, в live режиме, которое не имея рут привилегий, может "даровать" другим приложениям статус системных.
          То есть, обычно пользователь что-бы установить приложение с системными привилегиями делает рут на телефоне или может даже альт прошивку ставит, а тут просто бери и делай, грубо говоря даже без ведома пользователя. Понятное дело что используется для обхода санкций, но тем неменее API такое может быть использовано и во вред.
          И по поводу сяоми — я же не говорю, что вот это вот бэкдор, а то что в сяоми не бекдор.
          Я же не сранивал одно с другим, а просто написал своё мнение, почему я считаю что это "бэкдор".


  1. 402d
    03.10.2019 09:16

    Где-то в АНБ.
    Нет ну надо же, они совсем обнаглели.
    Добавили свои две строчки к нашему апи.

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


  1. Mykola_Von_Raybokobylko
    03.10.2019 10:15

    Просто красаучеги. Что еще запилили своего особенного интересно. сколько зондов и от кого).


  1. screwer
    03.10.2019 16:00

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

    Это не совсем правда. При обновлении системные приложения помещаются в /data, а старая версия из /system не используется.


    Так что не надо паники, никакой разницы со штатной работой нет.