Android ssl pinning disable

Гостевая статья Обход и отключение SSL на Android для выполнения атаки

Пиннинг сертификатов — это дополнительный уровень безопасности для обеспечения защиты. Он гарантирует, что только сертифицированные центры сертификации (Certificate Authorities, CA) могут подписывать сертификаты для вашего домена, а не любой центр сертификации в магазине вашего браузера.

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

При поиске таких строк, как «checkClientTrusted» или «checkServerTrusted», будет показан фрагмент кода с пиннингом.

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

Также, вы можете выполнить статический анализ с помощью фреймворка безопасности, такого как MOBSF, если вы найдете «Файлы сертификатов / ключей, запрограммированные внутри приложения» или «Обнаружено закодированное хранилище ключей», то он имеет SSL pinning.

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

В нашем сценарии мы используем приложение Android, если у вас есть рутированное устройство, то вы можете использовать Xposed Framework модули, доступные для отключения SSL Pinning. Это очень простой и понятный метод.

Но лучший способ — это провести ручную проверку, разобрав apk, где в небольшом исходном коде выполняется проверка пиннинга сертификата.

Поиск в небольшом коде по ключевым словам, таких как «X509TrustManager», «cert», «pinning», чтобы найти, где логин для подключения сертификата — это ключевые слова, такие как «X509TrustManager», «cert», «pinning», и т.д., чтобы найти, где выполняется подключение сертификата.

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

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

Обход сертификата pinning любым из этих способов позволяет эффективно вести человека в средней атаке на приложения, защищенные с помощью HTTPS и SSL, имея возможность перехватывать сеансы и даже видеть имена пользователей и пароли в обычном тексте в таком инструменте, как burp suite или fiddler .

Срок действия сертификата имеет тенденцию к истечению, так как согласно CAB форуму, CA сертификаты не будут выдаваться с максимальным сроком 3 года. Поэтому вам следует запланировать обновление приложения с обновленным сертификатом.

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

Источник

Анализ трафика Android-приложений: обход certificate pinning без реверс-инжиниринга

Иногда нужно исследовать работу бэкенда мобильного приложения. Хорошо, если создатели приложения не заморачивались и все запросы уходят по «голому» HTTP. А что, если приложение для запросов использует HTTPS, и отказывается принимать сертификат вашего корневого удостоверяющего центра, который вы заботливо внедрили в хранилище операционной системы? Конечно, можно поискать запросы в декомпилированом приложении или с помощью реверс-инжиниринга вообще отключить применение шифрования, но хотелось бы способ попроще.

Что такое certificate pinning?

Даже при использовании HTTPS пользователь не защищен от атак «Человек посередине», потому что при инициализации соединения злоумышленник может подменить сертификат сервера на свой. Трафик при этом будет доступен злоумышленнику.

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

Обход certificate pinning

В качестве подопытного выберем приложение Uber. Для анализа HTTP-трафика будем использовать Burp Suite. Также нам понадобится JDK и Android SDK (я использую все последней версии). Из Android SDK нам понадобится только утилита zipalign, так что при желании можно не скачивать весь SDK, а найти ее на просторах интернета.
Заранее облегчим себе жизнь, добавив следующие пути к нужным утилитам в переменную окружения PATH:

Открываем Burp, заходим в Proxy – Options – Add и добавляем Proxy Listener на интерфейсе, который будет доступен подопытному Android-устройству (или эмулятору). На устройстве в свою очередь настраиваем используемую Wi-Fi сеть на использование только что включенного прокси.

Скачаем apk-файл через apkpure.com, установим приложение на устройство и попытаемся войти в свой аккаунт – приложение зависнет на этапе аутентификации.

В логах Burp Suite (вкладка Alerts) при этом мы увидим множественные отчеты о неудачных SSL-рукопожатиях. Обратите внимание на первую строчку – именно через сервер cn-geo1.uber.com в моем случае осуществляется аутентификация, поэтому и не удается войти в приложение.

Дело в том, что Burp Suite при перехвате HTTPS-соединений (а мы помним, что все соединения устройства проксируются через него) подменяет сертификат веб-сервера на свой, который, естественно, не входит в список доверенных. Чтобы устройство доверяло сертификату, выполняем следующие действия. В Burp заходим в Proxy – Options и нажимаем Import/export CA certificate. Далее в диалоге выбираем Export Certificate. Копируем сертификат на устройство, переходим в Настройки – Безопасность – Установить сертификаты и устанавливаем наш сертификат в качестве сертификата для VPN и приложений.

Опять пытаемся войти в свой аккаунт. Сейчас приложение Uber сообщит нам только о неудачной попытке аутентификации – значит прогресс есть, осталось только обойти certificate pinning.

Откроем приложение в вашем любимом архиваторе как zip-архив. В папке res/raw можно заметить файл с говорящим названием ssl_pinning_certs_bk146.bks.

По его расширению можно понять, что Uber использует хранилище ключей в формате BouncyCastle (BKS). Из-за этого нельзя просто заменить сертификат в приложении. Сначала нужно сгенерировать BKS-хранилище. Для этого качаем jar для работы с BKS.

Теперь генерируем BKS-хранилище, которое будет содержать наш сертификат:

На вопрос о доверии сертификату отвечаем «yes». Опять открываем apk в архиваторе и заменяем оригинальное хранилище на наше (сохраняем при этом оригинальное название).

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

Удаляем из apk папку META-INF со старой подписью приложения и приступаем к генерации новой.
Создаем хранилище ключей и генерируем в нем ключ для подписи apk:

Подписываем только что сгенерированным ключом наш APK:

Теперь осталось выровнять данные в архиве по четырехбайтной границе:

Источник

1mm0rt41PC / disable-android-ssl-pinning.js

This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters

// start with:

// frida -U -l pinning.js -f [APP_ID] —no-pause

Java . perform ( function ( ) <

console . log ( » )

console . log ( ‘===’ )

console . log ( ‘* Injecting hooks into common certificate pinning methods *’ )

console . log ( ‘===’ )

var X509TrustManager = Java . use ( ‘javax.net.ssl.X509TrustManager’ ) ;

var SSLContext = Java . use ( ‘javax.net.ssl.SSLContext’ ) ;

// build fake trust manager

var TrustManager = Java . registerClass ( <

name : ‘com.sensepost.test.TrustManager’ ,

implements : [ X509TrustManager ] ,

methods : <

checkClientTrusted : function ( chain , authType ) <

> ,

checkServerTrusted : function ( chain , authType ) <

> ,

getAcceptedIssuers : function ( ) <

return [ ] ;

>

>

> ) ;

// pass our own custom trust manager through when requested

var TrustManagers = [ TrustManager . $new ( ) ] ;

var SSLContext_init = SSLContext . init . overload (

‘[Ljavax.net.ssl.KeyManager;’ , ‘[Ljavax.net.ssl.TrustManager;’ , ‘java.security.SecureRandom’

) ;

SSLContext_init . implementation = function ( keyManager , trustManager , secureRandom ) <

console . log ( ‘! Intercepted trustmanager request’ ) ;

SSLContext_init . call ( this , keyManager , TrustManagers , secureRandom ) ;

> ;

console . log ( ‘* Setup custom trust manager’ ) ;

// okhttp3

try <

var CertificatePinner = Java . use ( ‘okhttp3.CertificatePinner’ ) ;

CertificatePinner . check . overload ( ‘java.lang.String’ , ‘java.util.List’ ) . implementation = function ( str ) <

console . log ( ‘! Intercepted okhttp3: ‘ + str ) ;

return ;

> ;

console . log ( ‘* Setup okhttp3 pinning’ )

> catch ( err ) <

console . log ( ‘* Unable to hook into okhttp3 pinner’ )

>

// trustkit

try <

var Activity = Java . use ( «com.datatheorem.android.trustkit.pinning.OkHostnameVerifier» ) ;

Activity . verify . overload ( ‘java.lang.String’ , ‘javax.net.ssl.SSLSession’ ) . implementation = function ( str ) <

console . log ( ‘! Intercepted trustkit<1>: ‘ + str ) ;

return true ;

> ;

Activity . verify . overload ( ‘java.lang.String’ , ‘java.security.cert.X509Certificate’ ) . implementation = function ( str ) <

console . log ( ‘! Intercepted trustkit<2>: ‘ + str ) ;

return true ;

> ;

console . log ( ‘* Setup trustkit pinning’ )

> catch ( err ) <

console . log ( ‘* Unable to hook into trustkit pinner’ )

>

// TrustManagerImpl

try <

var TrustManagerImpl = Java . use ( ‘com.android.org.conscrypt.TrustManagerImpl’ ) ;

TrustManagerImpl . verifyChain . implementation = function ( untrustedChain , trustAnchorChain , host , clientAuth , ocspData , tlsSctData ) <

console . log ( ‘! Intercepted TrustManagerImp: ‘ + host ) ;

return untrustedChain ;

>

console . log ( ‘* Setup TrustManagerImpl pinning’ )

> catch ( err ) <

console . log ( ‘* Unable to hook into TrustManagerImpl’ )

>

// Appcelerator

try <

var PinningTrustManager = Java . use ( ‘appcelerator.https.PinningTrustManager’ ) ;

PinningTrustManager . checkServerTrusted . implementation = function ( ) <

console . log ( ‘! Intercepted Appcelerator’ ) ;

>

console . log ( ‘* Setup Appcelerator pinning’ )

> catch ( err ) <

console . log ( ‘* Unable to hook into Appcelerator pinning’ )

>

// ByPass SSL pinning for Android 7+

var array_list = Java . use ( «java.util.ArrayList» ) ;

var ApiClient = Java . use ( ‘com.android.org.conscrypt.TrustManagerImpl’ ) ;

ApiClient . checkTrustedRecursive . implementation = function ( a1 , a2 , a3 , a4 , a5 , a6 ) <

console . log ( ‘Bypassing SSL Pinning’ ) ;

var k = array_list . $new ( ) ;

return k ;

>

// Force mode debug for all webview

var WebView = Java . use ( ‘android.webkit.WebView’ ) ;

WebView . loadUrl . overload ( «java.lang.String» ) . implementation = function ( s ) <

console . log ( ‘Enable webview debug for URL: ‘ + s . toString ( ) ) ;

this . setWebContentsDebuggingEnabled ( true ) ;

this . loadUrl . overload ( «java.lang.String» ) . call ( this , s ) ;

> ;

> ) ;

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

4 метода обхода верификации SSL-сертификатов в Android

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

Автор: Cody Wass

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

• Добавление сертификатов в хранилище достоверных сертификатов.
• Перезапись упакованных сертификатов.
• Использование скрипта Frida для обхода проверок SSL-сертификатов.
• Изменение кода проверки сертификата.

Некоторые из вышеуказанных техник — простые, другие – более сложные в реализации. Мы рассмотрим каждый из этих методов без особого углубления в специфические детали.

Зачем нужна MITM-атака на SSL

Чтобы просматривать и изменять вызовы веб-службы, используемой мобильным приложением, нам понадобится промежуточный прокси сервер для перехвата, созданный при помощи утилит навроде BurpSuite или ZAP. При перехвате SSL-трафика SSL-соединение прерывается на стороне прокси-сервера. Сертификат, отсылаемый прокси-сервером, анализируется мобильным приложением, как если бы прокси был оконечной точкой веб-службы. По умолчанию самоподписанный сертификат, генерируемые утилитами наподобие Burp, не будет принадлежать проверенной достоверной цепочке. Если сертификат нельзя проверить на достоверность, большинство мобильных будут обрывать соединение вместо того, чтобы подключаться и работать в потенциально незащищенном канале. Техники, представленные ниже, предназначены для одной цели – убедить мобильное приложение, что сертификат, отправляемый прокси-сервером, является достоверным.

Техника 1 – Добавление сертификата в хранилище пользовательских сертификатов

Самый простой способ избежать SSL-ошибок – обзавестись валидным и надежным сертификатом. Эта задача решается относительно просто, если вы сможете установить достоверный сертификат на устройство. Если операционная система доверяет вашему центру сертификации, то будет доверять и сертификату, подписанному центром сертификации.

В Android есть два встроенных хранилища сертификатов, которые отслеживают, каким центрам сертификации доверяет операционная система: системное хранилище (хранит предустановленные сертификаты) и пользовательское хранилище (хранит сертификаты, добавленные пользователями).

Выдержка с сайта developer.android.com:

По умолчанию безопасные соединения (использующие протоколы TLS, HTTPS и им подобные) во всех приложениях доверяют предустановленным системным сертификатам. В Android 6.0 (API level 23) и более ранних версиях по умолчанию также считаются достоверными сертификаты, добавленные пользователями. Приложение может настраивать свои собственные соединения на уровне приложения (base-config) и на уровне домена (domain-config).

Сей факт означает, что, если мы имеем дело с приложением, которое работает в Android 6.0 и более ранних версиях, то можно просто добавить сертификат в пользовательское хранилище. Когда приложение пытается проверить достоверность цепочки для нашего сертификата, то обнаружит, что наш центр сертификации связан с достоверным хранилищем и, следовательно, будет доверять нашему сертификату. В более новых версиях приложение не будет доверять хранилищу пользовательских сертификатов. Чтобы решить эту проблему, нужно прописать такой уровень API и версию Android, чтобы приложение стало доверять пользовательским центрам сертификации. Мы будем редактировать атрибут «platformBuildVersionCode» элемента «manifest» в файле AndroidManifest.xml.

В коде выше в строке «platformBuildVersionCode=25» нужно поменять значение 25 на 23, а в строке platformBuildVersionName=»7.1.1″ значение 7.1.1 на 6.0.

После переупаковки приложения с обновленным файлом AndroidManifest.xml, доверие пользовательским центрам сертификации будет восстановлено.

Если требуется запуск на конкретной версии платформы, мы можем определить тэг trust-anchors в файле «/res/xml/network_security_config.xml». Например, следующий файл (https://developer.android.com/training/articles/security-config.html) определяет новый достоверный сертификат, который должен храниться по адресу /res/raw/my_ca.

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

Техника 2 – Перезапись упакованного сертификата

Если после установки сертификата в пользовательское хранилище, изменении в настройках версии Android и успешном прохождении проверок при просмотре других ресурсов, защищенных протоколом SSL, все равно возникают ошибки, значит, разработчики внедрили дополнительные условия, которым должны удовлетворять достоверные центры сертификации. Если не забыли, в предыдущей технике внутри тэга trust-anchors добавлялся новый путь к сертификату. Подобный трюк может использоваться разработчиками для защиты приложений от перехвата SSL.

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

Рисунок 1: Перечень сертификатов, используемых приложением

Если открыть пакет приложения при помощи, например, APK Studio, то можно сразу увидеть перечень привязанных сертификатов. На картинке выше сертификаты находятся в папке «assets». Замена явно бросающегося в глаза сертификата UniversalRootCA позволит нам подсунуть приложению наш сертификат.

Техника 3 – Подключение к функциям через фреймворк Frida

Если установки собственного сертификата недостаточно для успешного перехвата SSL-трафика, скорее всего, в приложении используются техники навроде SSL pinning или дополнительная SSL-валидация. В этом случае нужно блокировать проверки через непосредственное подключение к соответствующим функциям. Ранее эта техника была доступна для реализации только на устройствах с правами суперпользователя. Однако на данный момент при помощи библиотеки Frida Gadget можно работать с приложением и получить доступ к полному функционалу фреймворка Frida без прав суперпользователя.

Если вы уже выполняли пентесты мобильных приложений, то, вероятно, знакомы с этим фреймворком. Описание всей функциональности Frida выходит за рамки этой статьи, но если говорить в общем, то этот фреймворк позволяет изменять логику работы приложения во время выполнения. Обычно Frida работает как отдельное приложение и требует прав суперпользователя на устройстве. Если у нас нет прав суперпользователя, мы можем инжектировать в пакет приложения динамическую библиотеку Frida Gadget, содержащую большую часть функционала фреймворка Frida. Эта библиотека загружается во время выполнения приложения и позволяет вносить изменения в код.
Чтобы загрузить Frida Gadget, нужно распаковать APK, вставить динамическую библиотеку, отредактировать smali-код так, чтобы динамическая библиотека вызывалась самой первой, а затем переупаковать и установить пакет. Весь этот процесс хорошо задокументирован Джоном Козиракисом (John Kozyrakis). Вначале лучше пройти все этапы вручную, чтобы лучше понять, как работает эта технология. Чтобы сэкономить время, существует утилита — Objection, которая автоматизирует весь вышеупомянутый процесс. Требуется лишь указание целевого пакета, над которым нужно выполнить манипуляции.

После завершения в нашей рабочей директории должен появиться файл «test_app.objection.apk». По умолчанию утилита objection добавляет постфикс «.objection» к имени пакета. Далее мы можем установить этот пакет так же, как и любой другой APK, при помощи команды adb install test_app.objection.apk. После того как измененный пакет установлен на целевом устройстве, во время запуска приложение должно встать на паузу на начальном экране. В этот момент мы можем подключиться к серверу Frida, который отслеживает наше устройство:

C:\>frida-ps -U
PID Name
—- ——
6383 Gadget

C:\>frida -U gadget
____
/ _ | Frida 10.3.14 — A world-class dynamic instrumentation framework
| (_| |
> _ | Commands:
/_/ |_| help -> Displays the help system
. . . . object? -> Display information about ‘object’
. . . . exit/quit -> Exit
. . . .
. . . . More info at http://www.frida.re/docs/home/

[Motorola Moto G (5) Plus::gadget]-> Java.available
true

Alternatively, Objection supports interaction with the listening Frida server by using the ‘explore’ command:

C:\>objection explore
___| |_ |_|___ ___| |_|_|___ ___
| . | . | | | -_| _| _| | . | |
|___|___|_| |___|___|_| |_|___|_|_|
|___|(object)inject(ion) v1.2.2

Runtime Mobile Exploration
by: @leonjza from @sensepost

[tab] for command suggestions
com.test.app on (motorola: 7.0) [usb] # android hooking search classes TrustManager
android.security.net.config.RootTrustManager
android.app.trust.ITrustManager$Stub$Proxy
android.app.trust.ITrustManager
android.security.net.config.NetworkSecurityTrustManager
android.security.net.config.RootTrustManagerFactorySpi
android.app.trust.TrustManager
android.app.trust.ITrustManager$Stub
com.android.org.conscrypt.TrustManagerImpl
com.android.org.conscrypt.TrustManagerImpl$ExtendedKeyUsagePKIXCertPathChecker
com.android.org.conscrypt.TrustManagerImpl$TrustAnchorComparator
com.android.org.conscrypt.TrustManagerFactoryImpl
javax.net.ssl.TrustManagerFactory$1
javax.net.ssl.TrustManager
javax.net.ssl.TrustManagerFactory
javax.net.ssl.X509TrustManager
javax.net.ssl.TrustManagerFactorySpi
javax.net.ssl.X509ExtendedTrustManager
[Ljavax.net.ssl.TrustManager;

Теперь вы можете воспользоваться функцией для обхода технологии SSL pinning:

com.test.app on (motorola: 7.0) [usb] # android sslpinning disable
Job: 2f633f86-f252-4a57-958e-6b46ac8d69d1 — Starting
[6b46ac8d69d1] [android-ssl-pinning-bypass] Custom, Empty TrustManager ready
Job: 2f633f86-f252-4a57-958e-6b46ac8d69d1 – Started

Техника 4 – Реверс-инжиниринг кода верификации сертификата

Возможен такой случай, когда разработчик использует собственные SSL-библиотеки вместо системных для верификации сертификата. В этой ситуации нам нужно распаковать пакет, сконвертировать smali-код в Java-код и найти функции, отвечающие за проверку сертификата.

Если использовать «dex2jar», синтаксис будет следующим:

C:\>d2j-dex2jar.bat «C:\test_app.apk»
dex2jar C:\test_app.apk -> .\test_app-dex2jar.jar

Полученный файл .jar должен быть пригоден для открытия в вашей любимой утилите для исследования Java-приложений (например, JD-GUI).

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

Заключение

Техники, описанные в этой статье, позволяют перехватывать SSL-трафик и обходить некоторые наиболее распространенные защиты, используемые разработчиками. Кроме того, я кратко рассказал об утилите Objection и фреймворке Frida. Обход технологии SSL pinning и других защит лишь небольшая часть возможностей, которые позволяют реализовать эти инструменты.

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

Источник