Проверка подписи Android

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

Как только мы создаем apk для приложения, мы можем распаковать apk и редактировать файлы ресурсов с помощью apktool. Когда мы переупаковываем отредактированный apk, он теряет свою подпись. Я могу отменить unsigned apk, используя jarsigner с моим собственным личным ключом, который я использовал при создании apk. Я нашел приложение с именем zipsigner в playstore, которое можно использовать для подписи такого рода unsigned apk.

Итак, когда этот zipsigner подписывает unsigned apk, подписан ли apk с тем же личным ключом или с другим ключом? Поскольку моя папка META-INF по-прежнему содержит файлы XXX.SF и XXX.RSA, которые содержат информацию о моем личном ключе. Если это с моим же личным ключом, то новый apk будет обновлением для моего приложения или, если это другой ключ, у меня будут два разных приложения с таким же именем.

Из приведенных выше ситуаций есть вероятность того, что вредоносное ПО может быть включено в мой apk при переупаковке. Кажется, есть лазейка в механизме проверки подписи Android, где дайджест сообщений из файлов внутри папки META-INF не включен в файл MANIFEST.MF, а также в файл XXX.SF. Это создает возможность для всех включать вредоносные коды внутри этих папок, переупаковывать apk и увольнять его с помощью приложения zipsigner.

Я искал решение, в котором я могу запретить добавление файлов в папку META-INF, и я нашел его в блоге ниже. Но я не могу понять суть решения. Это похоже на тему исследования, так что в Интернете мало информации. Может кто-то попытаться выяснить решение, указанное в блоге. Ссылка на блог указывается ниже вопроса.

http://blog.trustlook.com/2015/09/09/android-signature-verification-vulnerability-and-exploitation/

Ответ 1

Закрытый ключ никогда часть распределенного APK, если я не понял ваш вопрос. Кто-то, кто подписывается от вашего имени, невозможен, если ваша собственная система не взломана.
Общая ссылка (blog.trustlook.com) рассказывает о том, что Android пропускает проверку файлов с расширением .sf(и файлы со связанными расширениями). Таким образом, вредоносное ПО может скрываться в файле с одним из этих расширений. В исправлении упоминается исправление "системной прошивки" для Android, а не что-то, что можно сделать на уровне приложения. Это означает, что OEM (сам Google или Samsung/другой) должен выпустить обновленную прошивку, чтобы исправить это. Проверьте последние обновления, возможно, они уже исправлены.
По-моему, даже если пользователь борется с APK, это скорее неприятность, чем настоящая атака/угроза. Обратитесь к бумаге Blackhat ниже для более подробной информации - https://www.blackhat.com/docs/ldn-15/materials/london-15-Xiao-What-Can-You-Do-To-An-APK-Without-Its-Private-Key-wp.pdf

Вы также должны прочитать это для возможных способов защиты от несанкционированного доступа APK - https://www.airpair.com/android/posts/adding-tampering-detection-to-your-android-app

Ответ 2

Чтение из других ответов link черная шляпа: проблемы APK

Если вы сохраняете свой секретный ключ в безопасности, тогда вы можете подписывать APK, и только вы сможете опубликовать их в данном магазине.
Дополнительная информация в каталоге META-INF не проверяется и не проверяется. Это позволяет добавлять дополнительные данные в файл jar, который можно использовать для контрабанды информации в APK. Но это не будет использоваться вашим файлом APK и не наносит репутационного ущерба.
Существует слабость в алгоритме тестирования, что означает, что на сервере не проверяется достоверность сертификата, если он подписан сам по себе.

Контрабанда данных

Не проверка файла META-INF является побочным эффектом работы криптокода. Чтобы защитить вещи, вам нужно создать сообщение, которое однозначно описывает сообщение. Это хэш защищенных данных. К сожалению, сертификат не может быть включен в это, поскольку он добавляется после вычисления хэша. Таким образом, обычно есть места, которые можно добавить, не нарушая подпись. Для окон и .exe Отчет Microsoft здесь: MS13-98. В этом случае некоторые установщики использовали непроверенные данные, чтобы выбрать, с чего загружать файлы. Это сделало их уязвимыми.

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

Если вы не полагаетесь на данные, не прошедшие проверку подлинности, в каталоге безопасности, вы не можете быть уязвимы к изменению. Лучше всего не делать этого.

Проблема самоподписывания

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

Есть ли способ переупаковки apk и подписания приложения с тем же закрытым ключом?

Закрытый ключ недоступен в APK, поэтому его нельзя использовать для повторной подписи данных.
Файлы в APK (вне META-INF) не могут быть изменены без изменения их хэша.

всякий раз, когда apk распаковывается, он потеряет свою сигнатурную информацию?

Уничтожение APK не нарушает его подпись, и вы можете повторно упаковать. Вы можете удалить элементы из APK, не нарушая подпись. Однако невозможно изменить ресурсы и код, не нарушая подпись.