введение

Быстрое развитие и широкое распространение мобильных приложений сделали сторонние SDK важной частью мобильной разработки. Благодаря своим богатым функциям и удобным методам интеграции сторонние SDK предоставляют разработчикам возможность быстро разрабатывать и улучшать функции приложений. Однако из-за природы «черного ящика» и широкого использования сторонних SDK их безопасность привлекла большое внимание. В этой статье основное внимание будет уделено проблемам безопасности сторонних SDK в мобильных приложениях, а также продемонстрированы потенциальные риски безопасности и методы атак на реальных случаях анализа уязвимостей.

Статус безопасности стороннего SDK:

Сторонние SDK, широко используемые в мобильных приложениях, имеют некоторые риски для безопасности. Во-первых, сторонние SDK интегрируются в приложения в виде jar-пакетов или около того библиотек и существуют как черные ящики, поэтому разработчики не могут проверять их безопасность. Во-вторых, из-за его широкого использования, если в SDK существует уязвимость, она затронет многие приложения. Кроме того, интеграция SDK может увеличить поверхность атаки приложения, тем самым увеличивая риск безопасности приложения.

Umeng SDK переопределяет уязвимость:

Уязвимость несанкционированного доступа к Umeng SDK была обнаружена в сентябре 2017 года. Эта уязвимость существует в SDK отправки сообщений Umeng. Злоумышленник может использовать эту уязвимость для вызова неэкспортированных компонентов без разрешения, тем самым добившись вредоносных вызовов к любому компоненту затронутого приложения, уведомления о произвольных ложных сообщениях, удаленного выполнения кода и других атак. Этой уязвимости подвержено около 30 000 приложений, а также более 7 000 приложений-приложений, включая различные типы приложений.

 

Обнаружен бэкдор Baidu SDK

Уязвимость бэкдора Baidu Moplus SDK, обнаруженная Trend Micro в ноябре 2015 года. Эта уязвимость существует в Baidu Moplus SDK. Злоумышленник может использовать эту уязвимость для незаметной установки приложений на устройствах Android с root-доступом, тем самым похищая конфиденциальную информацию пользователя или управляя устройством. Уязвимость затрагивает около 100 миллионов устройств Android и затрагивает тысячи приложений Android.

Риски, связанные с цепочками финансовых поставок, серьезны

Среди них риски безопасности сторонних SDK в цепочке поставок приложений Android особенно серьезны в финансовых приложениях.

Поиск и анализ уязвимостей

основная концепция

 Песочница приложения

Механизм контроля разрешений на базе Linux: после установки приложения назначаются UID и GID, а UID используется для ограничения доступа к файлам. Теоретически приложения не могут получить доступ к частным файлам других приложений. GID используется для ограничения доступа к ресурсам. После того, как приложение подает заявку на получение разрешений, другие UID добавляются в группу пользователей, соответствующую разрешению. Отношения между разрешениями и GID следующие:/data/etc/platform.xml. Необходимые разрешения применяются во время установки/работы. и контролируются системой/пользователем и т. д.

 НАМЕРЕНИЕ

Общие формы IPC в Android: это объект сообщения IPC, используемый для связи между компонентами приложения, одним и тем же процессом/межпроцессным процессом.

, startActivity()/startService()/bindService()/sendBroadcast(), используйте Action или ComponentName для указания целевого компонента и можете переносить дополнительные данные (дополнительно)

Безопасность компонентов

Основные компоненты приложения Android: активность, приемник широковещательной рассылки, поставщик контента и служба. Например: объявлено в файле xml: компонент может быть объявлен как внешний экспорт/частное приложение и может быть защищен с помощью разрешений.

Безопасность экспорта компонентов

Экспорт компонентов. Доступ к экспортированным компонентам может быть получен из любого приложения: android:exported=true, RegisterReceiver(), с помощью Компонент метки будет экспортирован по умолчанию, если android:export=false не установлен. Пример:

<receiver андроид: имя="com.xxx.android.pushservice.PushServiceReceiver" android:process=":xxservice_v1″ >

<intent-filter>

<action android:name=”android.intent.action.BOOT_COMPLETED” />

<action android:name=”android.net.conn.CONNECTIVITY_CHANGE” />

<!– … –>

</intent-filter

</receiver>

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

Методы эксплойта

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

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

ТолкатьSDK-майнинг уязвимостей

Распространение SDK — одна из распространенных функций мобильных приложений, но в ней есть некоторые дыры в безопасности. Обнаружив уязвимости в push SDK, злоумышленники могут обойти ограничения изолированной среды приложения, получить доступ к частным компонентам приложения, рассылать вредоносные уведомления, побуждать пользователей посещать фишинговые веб-сайты и т. д. Конкретные случаи включают уязвимость в push-SDK-A, интегрированном в официальное приложение городского метро. Злоумышленник успешно выводит фишинговое уведомление, создавая вредоносное push-сообщение и экспортируя получатель.

НАЖМИТЕ SDK

Нажмите SDK – A

• Официальная документация помогает разработчикам добавлять экспортированный приемник.
• Конкретные функции экспортированного Ресивера реализованы разработчиками.
• «Поручите» разработчикам оставить проходы для атаки

<receiver android:name=”您自己定义的Receiver” android:enabled=”true”>

<intent-filter>

<action android:name=”cn.xxxxx.android.intent.REGISTRATION” />

<action android:name=”cn.xxxxx.android.intent.MESSAGE_RECEIVED” />

<action android:name=”cn.xxxxx.android.intent.NOTIFICATION_RECEIVED” />

<action android:name=”cn.xxxxx.android.intent.NOTIFICATION_OPENED” />

<action android:name=”cn.xxxxx.android.intent.CONNECTION” />

<category android:name=”您应用的包名” />

</intent-filter

</receiver>

В данном случае это официальное городское приложение для метро, интегрированное в пакет SDK.

• ЭкспортПолучательxxxxxCustomerReceiver
• Проанализируйте входящие данные Intent в xxxxxCustomerReceiver и откройте указанный URL-адрес в приложении.
• POC

Официальное приложение городского метро получает доступ к вредоносным фишинговым страницам

Нажмите SDK – B

• Помогите пользователям добавить экспортированные приемники
• Экспортированный приемник наследует от com.xxx.android.xxxxx..xxxBaseReceiver

<receiver android:name=”com.xxxx.xxdemo.receiver.MessageReceiver”

Android: экспортировано =”истинный” >

<intent-filter>

<action android:name=”com.xxxxx.android.xxxxx.action.PUSH_MESSAGE” />

<action android:name=”com.xxxxx.android.xxxxx.action.FEEDBACK” />

</intent-filter

</receiver>

Нажмите SDK – B

xxxxx.android.xxxxx. Push-сообщение обрабатывается в xxxBaseReceiver. Доставленное сообщение шифруется RSA и расшифровывается локально приложением. После успешного расшифрования оно отображается пользователю. Однако... существует шифрование в SDK, и злоумышленник может вызвать этот метод шифрования для шифрования поддельных сообщений.

XX Credit Card Manager интегрирует push SDK-B и добавляет экспортированный получатель. Злоумышленник вызывает метод шифрования в SDK для создания вредоносного push-сообщения и использует экспортированный получатель для отображения фишингового уведомления. точка зрения:

Сфера влияния

Категория обменаУязвимость SDKкопать

SDK для совместного использования часто используются для реализации функций совместного использования в мобильных приложениях. Однако некоторые SDK для совместного использования имеют уязвимости безопасности. Например, если в определенном совместно используемом SDK-A есть экспортированное действие, злоумышленник может обойти ограничения изолированной среды приложения и получить несанкционированный доступ к любому частному действию. Создав вредоносную входную строку, злоумышленник может вызвать общую уязвимость отказа в обслуживании, что приведет к сбою приложения. Кроме того, некоторые общие SDK могут также вызывать обход блокировки паролей приложений, тем самым обеспечивая доступ к личным данным пользователей.

Поделиться SDK – A

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

XxShareXxXxxxxActivity получает входящую строку от намерения. Без проверки входящая строка сохраняется как ActivityName и вызывает startActivity в текущем контексте приложения, чтобы запустить действие, указанное ActivityName, и т. д.

Эксплуатация уязвимости — общий отказ в обслуживании: когда действие запускается, ему необходимо передать параметры/выполнить некоторые операции инициализации/…, использовать уязвимость SDK для принудительного вызова неэкспортированного действия и неправильную обработку исключений, что приводит к сбою приложения.

Напишите инструменты тестирования и проведите пакетное тестирование на большом количестве приложений.Среди приложений, интегрирующих SDK, эта проблема наблюдается у 90%+.По статистике, среди приложений, интегрирующих SDK, эта проблема наблюдается у 90%+.Большое количество хорошо- Этой уязвимости подвержены приложения известных отечественных производителей.

Эксплуатация уязвимости – обход блокировки пароля приложения: конфиденциальные данные пользователя сохраняются в приложении. При входе в приложение необходимо ввести правильный пароль. Это часто встречается в финансовых приложениях и приложениях для обмена мгновенными сообщениями. Используя эту уязвимость SDK, несанкционированный доступ включает в себя сброс паролей, установка паролей и т. д. Чувствительные функциональные компоненты и компоненты с высокими привилегиями в приложениях не проходят строгую аутентификацию, что приводит к обходу/сбросу блокировки паролей и т. д. Тесты показали, что эта проблема возникает у многих приложений известных производителей, таких как.. .

Эксплуатация уязвимостей. Включение режима отладки без разрешения. Чтобы облегчить обнаружение ошибок в Интернете, многие версии выпуска приложений содержат код отладки, применение переключателей журнала, настройку адресов онлайн-серверов, экспорт пользовательских данных и другие конфиденциальные функции... Функция отладки обычно недоступен в пользовательском интерфейсе. Интуитивно понятный вход, к которому обычные пользователи не могут легко получить доступ. Например, модуль отладки включает в себя конфиденциальные операции и по сути похож на бэкдор. Уязвимость SDK используется для обхода всех неэкспортированных компонентов приложения и обнаружения скрытых функций отладки. Например, в приложении обмена мгновенными сообщениями корпоративного уровня было обнаружено, что существует несколько неэкспортированных компонентов, содержащих функции отладки. Обратный анализ показал, что в пользовательском интерфейсе имеется скрытый вход для входа в отладку. Однако, чтобы запустить компонент отладки через пользовательский интерфейс, вам необходимо ввести пароль: , и аутентификация не является строгой. Эта уязвимость SDK используется для обхода защиты паролем. , включите функцию отладки без разрешения.

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

Сфера влияния

Итог и мысли:

К проблемам безопасности сторонних SDK в мобильных приложениях необходимо относиться серьезно и решать их. Разработчикам следует проверять интегрированные сторонние SDK, чтобы гарантировать их безопасность и надежность. В то же время разработчикам рекомендуется принять следующие меры для повышения безопасности сторонних SDK в мобильных приложениях:

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

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

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

4. Ограничьте разрешения SDK и объем доступа. При интеграции сторонних SDK разработчики должны проверять свои разрешения и предоставлять только необходимые разрешения. Кроме того, ограничьте доступ SDK к частным компонентам вашего приложения, чтобы снизить потенциальные риски безопасности.

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

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