Сертификаты для wifi android

Данная инструкция написана на примере настройки планшета, работающего под управлением ОС Android 4.0. С некоторыми возможными отличиями она применима также и к другим версиям ОС Android (2.3-3.x, 4.1), работающим на планшетах и смартфонах.

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

I. Установка сертификата безопасности сервера аутентификации

Перед настройкой собственно защищенного соединения wi-fi на ваше устройство необходимо установить сертификат сервера аутентификации сети wi-fi ИТМО, используемый для организации шифрованного канала в процессе аутентификации пользователя (т.е. проверки логина и пароля). Сертификат нужен для того, чтобы у вас, попросту говоря, «не увели пароль».

Сертификат доступен для скачивания по ссылке http://noc.ifmo.ru/root.crt, и должен быть предварительно установлен на клиентском устройстве Android в безопасном хранилище учетных данных.

Android поддерживает зашифрованные сертификаты X.509 в формате DER, сохраненные в файлах с расширением .crt (если файл сертификата имеет расширение .cer, .der или другое, его нужно изменить на расширение .crt).

Установка сертификата безопасности производится из внутренней памяти клиентского устройства Android.

Скопируйте файл сертификата с компьютера в корневой каталог внутренней памяти вашего android-устройства (т.е. не в папку). В разных версиях Android это может быть /mnt/sdcard, /mnt/extcard, /mnt/sdcard-ext и др.

Откройте приложение «Настройки».

Нажмите «Местоположение и защита».

Нажмите «Установить из памяти планшетного ПК».

Нажмите название файла сертификата, который следует установить (отображаются только названия сертификатов, которые еще не установлены).

Введите имя сертификата и нажмите кнопку «ОК».

Если вы еще не установили пароль для хранилища учетных данных на вашем устройстве, появится запрос на ввод и подтверждение пароля. Выполнив необходимые действия, нажмите «ОК». Дополнительную информацию о хранилище учетных данных можно найти в разделе «Настройки местоположения и безопасности».

Теперь можно использовать установленный сертификат при подключении к защищенной Wi-Fi сети ИТМО.

В принципе, на большинстве современных android-устройств сертификат можно установить и непосредственно из системного браузера, скачав его (сертификат) через 2G/3G-подключение по ссылке http://noc.ifmo.ru/root.crt.

II. Настройка подключения wi-fi

В стандартном варианте подключение выглядит так:

Откройте приложение «Настройки».

Нажмите Беспроводные сети -> Настройки Wi-Fi.

Установите флажок Wi-Fi для включения этого вида связи.

Ваше устройство просканирует доступные сети Wi-Fi и покажет названия найденных сетей. Защищенные сети отмечаются значком замка. Если устройство обнаружит сеть, которую вы уже настроили/использовали, оно подключится к ней автоматически. Если нужная сеть для вас новая — ее нужно настроить (см. далее).

Если вы настраиваете подключение, находясь непосредственно в зданиях ИТМО, то вы уже увидите сеть «etherless» в списке доступных.
(Если же вы настраиваете подключение, находясь вне ИТМО, то нажмите «Добавить сеть». Порядок дальнейших действий в появившемся окне настроек аналогичен)

Сделайте «долгое нажатие» на названии «etherless», и вы увидите приглашение «Подключиться к сети»:

Нажав на него, вы попадете в окно настройки подключения:

Вам необходимо произвести следующие настройки:

В нашей сети используется протокол WPA-Enterprise с шифрованием AES, аутентификация EAP/PEAP/MSCHAPv2 (система Android отображает это как «безопасность 802.1x EAP»), логин и пароль для подключения выдаются индивидуально каждому пользователю (на скриншоте ТОЛЬКО в качестве примера указан несуществующий логин wf99u99).

Для настройки ip-параметров не используется протокол DHCP, а каждому пользователю выделяется персональный статический ip-адрес.
Остальные настройки (сетевой шлюз, длина сетевого префикса, DNS-сервера) — см. на скриншотах (сетевая маска 255.255.0.0 соответствует длине сетевого префикса 16).

Прокрутите окно настроек дальше. Поставьте галочку «Дополнительно» и укажите «Настройки прокси-сервера» «Вручную»

Прокрутите окно настроек еще дальше. Укажите «Настройки IP» «Пользовательские» и введите выданный вам ip-адрес (а НЕ 172.16.99.99, как в примере) и другие настройки — см. скриншот.

Нажмите «Сохранить». Все, подключение к сети wi-fi настроено и уже функционирует:

В дальнейшем при необходимости сетевые настройки для сети Wi-Fi можно изменить:

Нажмите и удерживайте название сети в списке.

В открывшемся диалоговом окне выберите «Изменить сеть».

Внесите необходимые изменения.

При добавлении сети Wi-Fi Android запоминает ее вместе со всеми учетными данными и в дальнейшем подключается автоматически, если она доступна.

Осталось рассмотреть работу с ресурсами Web через прокси — см. далее.

III. Настройки прокси в браузерах

Если вы правильно прописали прокси-сервер в настройках самого подключения Wi-Fi (см. выше), то системный браузер Android уже будет работать через прокси. К сожалению, сторонние программы в Android’е «не обращают внимания» на данные системные настройки.

Некоторые браузеры имеют свои собственные настройки прокси. К примеру, Opera Mobile:

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

IV. Настройки прокси глобально для всей системы

Для автоматической установки прокси-сервера в зависимости от текущего подключения к конкретной сети Wi-Fi удобно использовать дополнительные сервисные программы. Однако, многие из них для установки и полноценной работы требуют прав ROOT.

К примеру, на скриншотах показана одна из самых удобных программ такого рода — ProxyDroid

V. Дополнительная информация

Общие принципы настройки wi-fi подключения для устройств, работающих под управлением операционной системы Android, приведены на сайте Google:

Как установить сертификат trusted CA на Android-устройство?

Я создал свой собственный сертификат CA, и теперь я хочу установить его на своем устройстве Android Froyo (HTC Desire Z), чтобы устройство доверяло моему сертификату.

Android хранит сертификаты CA в своем хранилище ключей Java в /system/etc/security/cacerts.bks . Я скопировал файл на свой компьютер, добавил свой сертификат с помощью portecle 1.5 и подтолкнул его обратно к устройству.

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

моя следующая попытка состояла в том, чтобы установить сертификат с SD-карты, скопировав его и используя соответствующую опцию из меню настроек. Устройство говорит мне, что сертификат был установлен, но, по-видимому, он не доверяет сертификату. Кроме того, когда я пытаюсь скопировать хранилище ключей на свой компьютер, я все еще нахожу оригинальный запас cacerts.bks .

Итак, каков правильный способ установите мой собственный корневой сертификат CA на устройстве Android 2.2 в качестве доверенного сертификата? Есть ли способ сделать это программно?

7 ответов:

до Android KitKat вы должны запустить свое устройство для установки новых сертификатов.

от Android KitKat (4.0) до нуги (7.0) это возможно и легко. Я смог установить Charles Web Debbuging Proxy cert на мое некорневое устройство и успешно нюхать SSL-трафик.

перед Android версии 4.0, с Android версии пряник & Froyo, был один файл только для чтения (/system/etc/security / cacerts.bks), содержащий хранилище доверия со всеми сертификатами CA (‘system’), которым доверяют по умолчанию на Android. Это используют как системные приложения, так и все приложения, разработанные с помощью Android SDK. Используйте эти инструкции по установке сертификатов CAcert на Android Gingerbread, Froyo, .

начиная с Android 4.0 (Android ICS / ‘Ice Cream Sandwich’, Android 4.3 ‘Jelly Bean’ и Android 4.4 ‘KitKat’), система доверяет сертификаты находятся в системном разделе (только для чтения) в папке «/system/etc/security/ » в виде отдельных файлов. Однако теперь пользователи могут легко добавлять свои собственные «пользовательские» сертификаты, которые будут храниться в «/data/misc/keychain/certs-added».

установленные системой сертификаты могут управляться на устройстве Android в разделе «Настройки» — > «Безопасность» — > «сертификаты» — > «Система», тогда как доверенные сертификаты пользователя находятся в разделе «пользователь». При использовании доверенного пользователя сертификаты, Android заставит пользователя устройства Android реализовать дополнительные меры безопасности: использование PIN-кода, шаблона блокировки или пароля для разблокировки устройства являются обязательными при использовании пользовательских сертификатов.

установка сертификатов CAcert в качестве «доверенных пользователей» — сертификаты очень просты. Установка новых сертификатов в качестве «доверенных системе» — сертификаты требуют больше работы (и требует корневого доступа), но он имеет преимущество избежать блокировки экрана Android требование.

Читать еще: Кэширование данных на ssd

начиная с Android N и далее он становится немного сложнее, см. Этот отрывок из Чарльз прокси-сайт:

начиная с Android N, вам нужно добавить конфигурацию в свое приложение, чтобы пусть он доверяет SSL-сертификатам, сгенерированным Charles SSL Proxying. Это означает, что вы можете использовать SSL-прокси только с приложениями, которые вы управление.

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

Добавить файл res / xml / network_security_config.xml для вашего приложения:

затем добавить ссылку на этот файл в манифест вашего приложения выглядит следующим образом:

Я потратил много времени, пытаясь найти ответ на этот вопрос (мне нужен Android, чтобы увидеть сертификаты StartSSL). Вывод: Android 2.1 и 2.2 позволяют импортировать сертификаты, но только для использования с WiFi и VPN. Нет пользовательского интерфейса для обновления списка доверенных корневых сертификатов, но есть обсуждение о добавлении этой функции. Неясно, существует ли надежный обходной путь для ручного обновления и замены cacerts.файл БКС.

подробности и ссылки: http://www.mcbsys.com/techblog/2010/12/android-certificates/. в этом посте, смотрите ссылку на Android ошибка 11231—вы можете добавить свой голос и запрос к этой ошибке.

Если вам нужен сертификат для HTTPS-соединений, вы можете добавить его .файл bks в качестве необработанного ресурса для вашего приложения и расширения DefaultHttpConnection, чтобы ваши сертификаты использовались для HTTPS-соединений.

проводник связан здесь вероятно, ответит на исходный вопрос без необходимости программирования пользовательского соединителя SSL.

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

в основном вам потребуется:

скачать: cacerts.файл bks с вашего телефон.

adb pull / system/etc/security / cacerts.bks cacerts.БКС

скачать .crt-файл из центра сертификации, который вы хотите разрешить.

изменить cacerts.файл bks на вашем компьютере с помощью BouncyCastle Provider

загрузить cacerts.файл bks возвращается на ваш телефон и перезагружается.

то, что я сделал, чтобы иметь возможность использовать сертификаты startssl, было довольно легко. (на моем корневом телефоне)

Я скопировал /system/etc/security / cacerts.БКС на мою почту

пошел portecle.sourceforge.net и запустил portecle прямо с веб-страницы.

открыл мои cacerts.файл bks с моей SD-карты (ничего не введено при запросе пароля)

выберите Импорт в portacle и открыл sub.class1.server.ca.crt, im мой случай он уже имел ca.ЭЛТ, но, возможно, Вам тоже нужно установить это.

сохранил хранилище ключей и скопировал его baxck в /system/etc/security / cacerts.БКС (я сделал резервную копию этого файла, сначала на всякий случай)

перезагрузил мой телефон, и теперь я могу вист мой сайт, который использует сертификат startssl без ошибок.

есть гораздо более простое решение для этого, чем опубликовано здесь или в связанных потоках. Если вы используете webview (как и я), вы можете достичь этого, выполнив в нем функцию JAVASCRIPT. Если вы не используете WebView, вы можете создать скрытый для этой цели. Вот функция, которая работает практически в любом браузере (или webview) для начала установки ca (обычно через общий репозиторий сертификатов ОС, в том числе на дроиде). Он использует хороший трюк с iFrames. Просто передайте url-адрес a .crt файл для этой функции:

трюк iframe работает на дроидах с API 19 и выше, но более старые версии webview не будут работать так. Однако общая идея все еще работает — просто загрузите/откройте файл с помощью webview, а затем позвольте ОС взять на себя. Это может быть более простым и универсальным решением (в реальной java сейчас):

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

вот альтернативное решение, которое фактически добавляет сертификат в список сертификатов по умолчанию: доверие всем сертификатам с помощью HttpClient через HTTPS

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

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.

Читать еще: Как узнать wifi адаптер

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

Подписывайтесь на каналы «SecurityLab» в Telegram и Яндекс.Дзен, чтобы первыми узнавать о новостях и эксклюзивных материалах по информационной безопасности.

Настройка EAP-TLS на Android

Недавно построил WiFi-сетку с аутентикацией по 802.1x, использующую сертификаты для опознания юзеров. В числе прочего, пришлось настраивать для работы с ней устройства на Android – смартфоны и планшетки. Тут-то и выяснилось, что нормального howto, как это сделать, найти не получается – те, которые были, касались сценариев с паролями, а мне от них-то и хотелось избавиться. Потому и решил свести информацию по вопросу в один пост.

Что такое 802.1x и как его использовать на Windows и Linux, написано предостаточно, поэтому тут будет только про настройку клиента на Android.

Итак, в чём цель? Надо создать сетку с приличным шифрованием и надёжной аутентикацией, при этом требуется, чтобы аутентикация была как можно более удобна для юзера, но при этом защищена от юзера же. То есть я, в качестве админа, не хочу, чтобы юзер мог передать кому другому свой пароль или файл с секретным ключом, или же подключился с устройства, с которого я не хочу позволять ему подключаться – например, личного лэптопа. В общем, мрак и диктатура.

Для этого делаем следующее: на устройство (телефон, планшетку) ставится сертификат с секретным ключом (на каждый девайс – отдельный ключ). Управление ключами в Андроиде весьма примитивно, однако даёт ровно тот минимум, какой нам требуется – даёт импортировать ключ и использовать его, но не извлекать обратно (по крайней мере, без пароля, который мы выдавать не собираемся). Эти ключи и будут выдаваться access point’у в ответ на требование представиться.

Процедурка вся укладывается в 4 шага:

1. Подготовка “credential storage”:
Перед тем, как заводить в девайсину какие-либо секретные ключи, надо подготовить для них хранилище, где ключи будут сохраняться в зашифрованном виде. Шифрование будет происходить на основе пароля, который вводится лишь при создании хранилища. Для использования секретного ключа пароль вводить не нужно – лишь для его экспорта (который к тому же невозможно осуществить через обычный андроидный UI). Посему пароль мы этот оставим у себя, а юзеру выдавать отнюдь не будем. Evil laughter прилагается.

Читать еще: Wifi драйвер для леново

[Update: увы, не выйдет. При выключении девайса пароль уходит, и для использования ключей его придётся вводить заново. У этого есть и хорошие, и плохие стороны:
* Сохранять пароль в тайне от юзера не выйдет — иначе придётся вводить его всякий раз при включении.
* Это значит, что теоретически юзер может скопировать из девайса секретный ключ — что с админской точки зрения плохо. Но, насколько я понимаю, ему для этого требуется рутовый доступ. Получение такого доступа хлопотно, но возможно.
* Хорошая сторона в том, что сам пароль в флэш-памяти не сохраняется — а криптоключи, которые сохраняются, шифруются этим паролем по AES.
* Ну и к тому же, если пароль при включении введён ещё не был, то это даёт защиту от кого-то постороннего, кто попытается использовать ключ, пароля не зная.
]

Пароль можно впоследствии сменить – но лишь при знании нынешнего. Можно и обнулить всё хранилище – при этом пароль уйдёт, и юзер сможет выставить свой, но с ним погибнет безвозвратно также и секретный ключ, прямо как тайна верескового мёда.

Собственно процесс: Settings —> Location and security —> Set password . Ввести пароль дважды. После чего галочка “ Use secure credentials ” включится автоматически.

Чтобы поменять пароль: “ Set password ” повторно.

Чтобы обнулить всё нафиг: “ Clear storage ” там же.

2. Импорт корневого сертификата:
Нужно забросить в девайс файл с расширением .crt ( .cer не принимается) и в формате PEM, также известном как Base-64. Можно это сделать через USB, можно через Bluetooth. Файл должен быть скопирован в директорию /sdcard – та, что видна как корень при подключении девайса через USB или при просмотре файлов через “ My Files ”.

Затем: Settings —> Location and security —> Install encrypted certificates (хоть в данном случае сертификат и не encrypted). Сертификат будет добавлен в список доверяемых, а файл в /sdcard стёрт.

Более удобный способ: опубликовать сертификат на каком-нибудь веб-сайте и просто открыть его URL в родном андроидном браузере (для пущей надёжности, использовать известный вебсервис через https или же сугубо внутренний сайт). Тот сразу запросит, добавить ли сертификат в список доверяемых, или нет. Чтобы не набивать URL руками, можно сгенерировать QR-code с ним, и затем просто отсканить его.

3. Импорт сертификата юзера с секретным ключом:
Файл с секретным ключом в формате PKCS#12 и с расширением .p12 кладётся в /sdcard ( .pfx , опять же, игнорируется). Способов создать такой файл множество – не буду их перечислять, но отмечу, что обязательно стоит задать для него одноразовый пароль, шифрующий ключ.
Затем, опять же, Settings —> Location and security —> Install encrypted certificates . На этот раз будет запрошен пароль. Это не тот, что задавался при создании хранилища, а тот, который нужен для расшифровки ключа из файла. После введения пароля, ключ будет дешифрован и сохранён зашифрованным заново – на этот раз, паролем от хранилища. Файл же будет стёрт из /sdcard , что нас вполне устраивает.

Можно также забросить файл .p12 через URL, но я бы не стал – в отличие от сертификатов, расползания ключей, хоть и в шифрованном виде, стоит избегать.

4. Подключение к собственно сети:
После того, как ключ задан, остались лишь настройки WiFi-сети. Ничего секретного в этом этапе нет, можно оставить его юзерам, выслав инструкцию.
Итак: Settings —> Wireless and network —> Wi-Fi settings . Найти сеть в списке, либо, если SSID скрыт, жмякнуть на “ Add Wi-Fi network ”.
Затем:

Сертификаты для wifi android

Вопрос

Is it possible to get certificate authorization for WiFi to work in Android 6.0.1 with Intune and SCCM hybrid?

It’s working perfectly in iOS and Windows Phone without problems.

I’ve searched my way through Google and back without finding any tips :/

Thanks for any directions to get it to work, everything little tip is appreciated.

Best regards
Andreas

Все ответы

Why it cannot work on Android 6.0.1 devices? What issues exactly did you have when configuring this?

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

HAve you tried to configured on the single device or this behave is for all the android devices??

I don’t why it doesn’t work, really. The certificates doesn’t show up in the WiFi settings for the SSID.

It works in Android 4, but with the new certificate stores it doesn’t work at all. Email profile is working great on the same phone. I’ve tried on several new Samsung devices.

I think for this issue you may have to do more testings on other device model, if you get the same issue then you can request a FREE ticket with Microsoft CSS for help.

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

I have exactly the same problem than you on Samsung A3 & A5.

The certificate are not installed in the good store : user certificate / system instead of user certificate /wifi.

If i install the certificate manually the wifi profile works.

Do you find a solution?

I am having exactly the same problem.

Have you been able to find a solution for it deploying certificates to Android devices for WiFi usage?

I am having exactly the same problem.
Have you been able to find a solution for it deploying certificates to Android devices for WiFi usage?

I ended up creating OMA-URI config for Android devices and it solved the issue.
Shared my solution here: https://serverfault.com/questions/845780/

Hope this helps

Изменено Jevgenij Martynenko 21 апреля 2017 г. 15:36

was anyone able to solve this issue? Otherwise I’m going to open a case, because I’ve the same/a similar issue.

The workaround which Jevgenij described I don’t want to, because it should work if Microsoft supports it!

Best Regards
Philipp

Изменено Pippone2810 25 апреля 2017 г. 5:46 edit post (workaround)

It’s now working correctly as we switched over to Intune Standalone, it would probably also work with the hybrid. The solution for us were following:

Create a root certificate
Use two separate SCEP certificates (really important), one for WiFi and one for email.
Just using the Client Authentication option, common name incl. email and UPN as alternative, both keys, both hashes and the root cert, nothing fancy really.
Configure the WiFi-profile to use WPA2 Enterprise with EAP-TLS and the root and WiFi-certificate

This is for regular Android with KNOX enabled, not for Android for Work (this also works great with the Nine email app, not gmail.. so many bugs there).

Everything configures itself, just allow both certs in the phone when the question appears and wait for 1min to several hours. Don’t be in a rush! 🙂

Hope it points someone in the right direction, really frustrating not knowing it needed separate certificates for it to work.

0 0 голоса

Рейтинг статьи