Первичные ключи и пробелы

В последние недели большое внимание уделялось раскрытию информации первичные ключи или Китайские первичные ключи (оба инцидента классифицируются как критические пробелы в платформе Android). Несмотря на то, что дело, наконец, прекратилось, мы все еще ждем финальной партии в Лас-Вегасе на конференции Black Hat в Соединенных Штатах, во время которой Джефф Форристал (ученый, обнаруживший один из пробелов, перечисленных выше) объяснит все важные детали (вы никогда не узнаете, если не будет какой-то сюрприз). Несмотря на это, у нас достаточно информации, чтобы оценить влияние этой уязвимости.

Прежде всего, термин «мастер-ключ» несколько вводит в заблуждение; Эта уязвимость на самом деле не связана с шифрованием, но касается скрытия в приложении Android ( apk- файл) двух версий одного и того же ресурса, чтобы частично перекрыть некоторые методы контроля целостности. Однако влияние этой уязвимости является значительным, поскольку это означает, что злоумышленник может «замешать» в файле apk, подписанном доверенной организацией, чтобы включить измененный ресурс, и, таким образом, заменить исходный (наиболее опасный случай можно обработать с помощью измененного файла classes.dex ).


Внедренный classes.dex не мешает процессу проверки.

С точки зрения пользователя это означает, что приложение, опубликованное и подписанное доверенной организацией «FamousCompany (tm)», может добавлять фрагменты вредоносного кода без ведома пользователя, но риск сводится к минимуму благодаря тому, что магазин Google Play не принимает приложения, упакованные в файлы ZIP, в том числе файл упакован дважды, но с определенные отчеты похоже, что некоторые приложения в Google Play упакованы таким образом, возможно, по ошибке (zip-файл такого приложения дважды содержал один и тот же ресурс png). Это означает, однако, что проверки безопасности выполняются только для вновь загруженных приложений и не охватывают весь набор приложений.

Как будто этого было недостаточно, немногие устройства (вероятно, только Samsung Galaxy S4) поддерживают код, который исправляет уязвимость. Это довольно интересно, если принять во внимание тот факт, что многие пользователи загружают приложения из магазинов со сторонними приложениями, которые могут не проверять загруженные файлы apk. Если широко обсуждаемая фрагментация устройства не убивает индустрию разработки приложений, нам интересно, сколько пользователей согласятся, если это приведет к постоянной подверженности таким ошибкам. В любом случае, это еще одна причина, почему исследователи выпустили приложение проверка, если ваше устройство находится в опасности. Продукты «Лаборатории Касперского» активно проверяют с помощью облака Kaspersky Security Network (KSN), нет ли на устройстве приложений, использующих обе уязвимости. В этой ситуации лучший способ защиты от такой неожиданной цепочки событий также состоит в том, чтобы избегать использования сторонних хранилищ и оставлять флажок «Установка из неизвестного источника» не установленным.

Помня обо всем этом, давайте теперь посмотрим на пробелы, чтобы понять, почему и как им удалось проскочить все проверки качества. Каждое приложение Android представляет собой не что иное, как ZIP-сжатый файл, который включает в себя все виды ресурсов: исполняемые файлы, изображения, текстовые данные, данные формата и т. Д. Целостность поддерживается с помощью хеширования (и хеширования) всех подключенных ресурсов к обнаружение любой несанкционированной модификации. Также этот процесс автоматизирован и происходит каждый раз, когда приложение установлено. Пользователи также могут проверить файл apk с помощью команды " jarsigner -verify -verbose ", вывод которой в случае обычного приложения выглядит следующим образом:

stefano @ KL: ~ $ jarsigner -verbose -verify test_app_original.apk sm 804 вт. 09 июля 15:23:20 CEST 2013 res / layout / activity_main.xml sm 564 вт июл 09 15:23:20 CEST 2013 res / menu / main .xml см 1712 вт июл 09 15:23:20 CEST 2013 AndroidManifest.xml см 2596 вт июл 09 15:23:18 CEST 2013 resources.arsc sm 7783 вт июл 09 15:05:48 CEST 2013 res / drawable-hdpi / ic_launcher.png см 3760 вт июл 09 15:05:48 CEST 2013 res / drawable-mdpi / ic_launcher.png см 12356 вт июл 09 15:05:48 CEST 2013 res / drawable-xhdpi / ic_launcher.png см 24780 вт июл 09 15:05:48 CEST 2013 res / drawable-xxhdpi / ic_launcher.png sm 557312 вт июл 09 15:23:20 CEST 2013 classes.dex s 773 июл 09 15:23:20 CEST 2013 META-INF / MANIFEST.MF 806 Вт июл 09 15:23:20 CEST 2013 META-INF / CERT.SF 1203 Вт июл 09 15:23:20 CEST 2013 META-INF / CERT.RSA s = подпись была проверена в манифесте

Например, если мы изменим файл main.xml , процесс проверки завершится неудачно:

stefano @ KL: ~ $ jarsigner -verbose -verify test_app_modified.apk jarsigner: java.lang.SecurityException: ошибка дайджеста SHA1 для res / menu / main.xml

После установки Android выполняет точно такое же действие. Однако оказалось, что в отличие от jarsigner , система не любит необычные случаи, например, когда ZIP-файл содержит несколько повторяющихся элементов. В частности, оказалось, что если в apk был включен ресурс с повторяющимся именем, операционная система проверит только один, но загрузит другой. Смотрите следующий файл apk:

stefano @ KL: ~ $ unzip -l test_app_hacked.apk Архив: modded.apk Длина Дата Время Имя --------- ---------- ----- ---- 449804 2013-07-09 21:24 classes.dex 804 2013-07-09 15:23 res / layout / activity_main.xml 564 2013-07-09 15:23 res / menu / main.xml 1712 2013-07-09 15 : 23 AndroidManifest.xml 2596 2013-07-09 15:23 resources.arsc 7783 2013-07-09 15:05 res / drawable-hdpi / ic_launcher.png 3760 2013-07-09 15:05 res / drawable-mdpi / ic_launcher.png 12356 2013-07-09 15:05 res / drawable-xhdpi / ic_launcher.png 24780 2013-07-09 15:05 res / drawable-xxhdpi / ic_launcher.png 557312 2013-07-09 15:23 классов. dex 773 2013-07-09 15:23 META-INF / MANIFEST.MF 806 2013-07-09 15:23 META-INF / CERT.SF 1203 2013-07-09 15:23 META-INF / CERT.RSA - -------- ------- 1064253 13 файлов

Обратите внимание, что файл classes.dex появился дважды, с более новым элементом, потенциально опасным. Расстраивает, что jarsigner немедленно предупреждает вас, что что-то не так:

stefano @ KL: ~ $ jarsigner -verbose -verify test_app_hacked.apk jarsigner: java.lang.SecurityException: ошибка дайджеста SHA1 для classes.dex

К сожалению, у Android другое мнение на этот счет:

C: \ Users \ Stefano \ Android \ android-sdk \ platform-tools> adb.exe установить D: \ samples \ test_app_hacked.apk 145 КБ / с (444061 байт в 2.978 с) pkg: / data / local / tmp / test_app_hacked .apk Успех

Помните, что стандарт ZIP позволяет многим элементам иметь одинаковые имена файлов. Однако, как он отметил, Saurik Android действительно использует две разные реализации для распаковки файла. Тонких различий между ними достаточно, чтобы процесс проверки буквально игнорировал первую позицию.

Несколько иным, хотя и не менее опасным является второй пробел, известный уже несколько дней. Обнаруженная группой безопасности в Китае, которая называется «Подразделение безопасности Android», эта уязвимость позволяет выполнять те же действия, что и обнаруженная Джеффом Форристалом (то есть вводить и выполнять исполняемый код без обнаружения неточностей путем проверки целостности). Также в этом случае ошибка возникает из-за использования двух разных реализаций для чтения (и распаковки) файла apk. В этом случае, однако, виноват метод обработки поля «Дополнительная длина поля» (часть ZIP-заголовка). Это поле, обычно равное 0, определяет длину некоторых редко используемых метаданных. К сожалению, это значение хранится как целое число без знака (ровно 16-битное). Хотя рассуждения низкого уровня являются общими для рассуждений с точки зрения неподписанных данных, это не относится к таким языкам, как Java. Фактически, Java может быть худшей с точки зрения типов данных без знака: существуют только подписанные данные.

Все те, кто программирует на Java и имеет некоторый опыт в этой области, знают, что обработка двоичных данных заставляет всю программу быть окруженной серией инструкций маскирования ( & 0xffff ) для правильной обработки неподписанных данных. К сожалению, это не относится к библиотеке Java, используемой для анализа дополнительных полей данных. Даже если данные правильно хранятся, каждый раз, когда они к ним обращаются для выполнения, например, вычисления проверки диапазона, они интерпретируются как 16-разрядные целые числа со знаком (младшие значения читаются как отрицательные значения). Эта дихотомия снова приводит к ситуации, когда верификатор видит определенный фрагмент кода, тогда как загрузчик (который правильно обрабатывает это поле как тип без знака) - другой.

Чтобы успокоиться , мы хотели бы сообщить вам, что все эти ошибки были зарегистрированы, и вскоре двоичные ресурсы будут доставлены на ваше устройство (эффективность политики исправлений выходит за рамки этого текста). Однако ограниченное влияние описанных пробелов объясняется тем, что в обоих случаях они были раскрыты ответственным образом. Беспокойство только поднимает вопрос: что произойдет, если их раскрытие не будет таким ответственным образом?