Adguard ошибка https фильтрации не принимает наш сертификат

Prerequisites

• This site DOES NOT contain sexually explicit material, otherwise use NSFW-specific form;
• Filters were updated before reproducing an issue;
• AdGuard product version is up-to-date;
• Browser version is up-to-date;
• If the site or app is broken, disabling AdGuard protection resolves an issue.

What product do you use?

AdGuard for Android, AdGuard for Windows

AdGuard version

3.6.11

What type of problem have you encountered?

Missed ads or ad leftovers, Website or app doesn’t work properly, Annoyances — pop-ups, cookie warnings, etc.

Which browser(s) do you use?

the problem is with app, not a site

Which device do you use?

Mobile

Where is the problem encountered?

https://tubemate.net

What filters do you have enabled?

AdGuard Base filter, AdGuard Mobile Ads filter, EasyList, List-KR

What Stealth Mode options do you have enabled?

Hide your search queries, Self-destruction of third-party cookies, Remove X-Client-Data header from HTTP requests, Protect from DPI

Add your comment and screenshots

1. Symptoms
   When using some application, inform shown below shows and ads won’t be blocked or cannot use application at all.

For now, 2 applications majorly that I use is the problem.

1. Tubemate :
   https://tubemate.net
2. SPOTV NOW :
   https://play.google.com/store/apps/details?id=kr.co.spotvnow.app&hl=ko&gl=US&referrer=utm_source%3Dgoogle%26utm_medium%3Dorganic%26utm_term%3Dspotvnow&pcampaignid=APPU_1_VuZrZOySGcOK-Qbgg79o

Especially for the second version, I think this app detects adguard and blocks connection itself when using adguard.

1. Screenshots

App does not approve HTTPS certificate

Privacy

• I agree to follow this condition

Автор: 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.

<manifest xmlns:android=»http://schemas.android.com/apk/res/android&quot; package=»com.test.app» platformBuildVersionCode=»25″ platformBuildVersionName=»7.1.1″>

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

<manifest xmlns:android=»http://schemas.android.com/apk/res/android&quot; package=»com.test.app» platformBuildVersionCode=»23″ platformBuildVersionName=»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.

 <?xml version="1.0"  encoding="utf-8"?>
  <network-security-config>
  <base-config>
  <trust-anchors>
  <certificates src="@raw/my_ca"/>
  </trust-anchors>
  </base-config> 
</network-security-config>

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

Техника 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, которая автоматизирует весь вышеупомянутый процесс. Требуется лишь указание целевого пакета, над которым нужно выполнить манипуляции.

 C:  >objection patchapk -s test_app.apk
  No  architecture specified. Determining it using `adb`...
  Detected  target device architecture as: armeabi-v7a
  Github  FridaGadget is v10.6.28, local is v10.6.13. Updating...
  Downloading  armeabi-v7a library to  C:.objectionandroidarmeabi-v7alibfrida-gadget.so.xz...
  Unpacking  C:.objectionandroidarmeabi-v7alibfrida-gadget.so.xz...
  Cleaning up  downloaded archives...
  Using Gadget  version: 10.6.28
  Unpacking  test_app.apk
  App already  has android.permission.INTERNET
  Reading  smali from:  C:Temptmp8dxqks1u.apktempsmalicom/test/app/TestMainActivity.smali
  Injecting  loadLibrary call at line: 10
  Writing  patched smali back to: C:Temptmp8dxqks1u.apktempsmalicom/test/app/TestMainActivity.smali
  Creating  library path: C:Temptmp8dxqks1u.apktemplibarmeabi-v7a
  Copying  Frida gadget to libs path...
  Rebuilding  the APK with the frida-gadget loaded...
  Built new  APK with injected loadLibrary and frida-gadget
  Signing new  APK.
  jar signed.
  Signed the  new APK
  Performing  zipalign
  Zipaling  completed
  Copying  final apk from  C:UserscwassAppDataLocalTemptmp8dxqks1u.apktemp.aligned.objection.apk to  current directory...
Cleaning up  temp files...

После завершения в нашей рабочей директории должен появиться файл «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-приложений и демонстрируют важность наличия нескольких способов проведения подобного рода исследований.

Статья обновлена 18 января 2021
Ознакомление с этой статьей может потребовать от вас базовых знаний о шифровании, протоколе TLS и устройстве HTTPS.

Для начала, приведем диаграмму, которая показывает, как в целом устроена фильтрация HTTPS в AdGuard:

AdGuard копирует свойства TLS-соединения, которые использует ваш браузер:

• AdGuard использует ту же самую версию TLS.
• AdGuard использует те же методы шифрования (ciphers), что и ваш браузер.

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

Как ведет себя AdGuard в случае, если есть сомнения в валидности сертификата?
В случае, если есть какие-то сомнения в валидности сертификата, AdGuard полностью прекращает фильтрацию соединений к этому домену, и отдает это на откуп браузеру.

Известные недостатки

Фильтрация HTTPS в AdGuard имеет некоторые недостатки. Практически все мы планируем устранить в ближайших версиях AdGuard.

Ниже перечислены все известные нам проблемы и сроки их устранения.

Проверка оригинального сертификата

Самым важным недостатком HTTPS фильтрации является то, что она «прячет» оригинальный сертификат вебсайта. Вы просто не можете увидеть реальный сертификат — вместо него вы видите тот, который был сгенерирован AdGuard.

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

Certificate Transparency

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

В нашем случае проблема в том, что браузеры игнорируют заголовок Expect-CT для локальных сертификатов, и проверка на certificate transparency просто не производится при включенном AdGuard. Для того, чтобы получить тот же уровень защиты, мы должны самостоятельно проводить эту проверку на уровне AdGuard.

Что мы хотим сделать:

• Добавить поддержку Certificate Transparency в библиотеку валидации

Срок реализации:

• Ожидаемый срок реализации: третий квартал 2021.

Замечания и пожелания?

Если вы хотите что-то добавить, указать нам на ошибки или несоответствия или задать вопрос, пишите пожалуйста на адрес devteam at adguard.com.