Как проверить sha256 в android устройствах
Перейти к содержимому

Как проверить sha256 в android устройствах

  • автор:

Освободи свой Android

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

В момент выхода этой статьи я как-то не обратил на неё внимания — тема смартфонов и Андроида мне вообще не очень интересна. Потом, уже через несколько месяцев, я вновь случайно наткнулся на эту статью, вчитался, и проникся идеями, содержащимися в ней. Действительно, почему бы не стать хозяином своему собственному смартфону?

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

Предупреждения

Прочитайте очень внимательно и вдумчиво.

Предупреждение 1

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

Предупреждение 2

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

Начинаем

Итак, мы прочитали статью, а затем вторую статью, прониклись идеями, заложенными в них, и готовы провести практический эксперимент по освобождению своего Андроида (на самом деле эксперимент по освобождению себя от Андроида). С чего же начать?

Кстати, вы заметили, что суть Андроида заложена в самом его названии — это Andro ID, то есть ваш универсальный (в смысле всех аспектов вашей жизни) идентификатор.

Начнём мы с выбора аппарата для экспериментов. Проблема в том, что LineageOS поддерживает очень небольшое количество устройств, причём в основном устаревших. В своей статье fur_habr рекомендует остановиться на Xiaomi Redmi 4(X), Xiaomi Redmi Note 4 или Xiaomi Mi A1. При попытке поинтересоваться у продавцов наличием в продаже этих моделей, я получил в ответ круглые глаза, заверения, что таких древностей у них нет. Интернет только подтвердил диагноз — купить новый аппарат этих моделей практически невозможно, есть какие-то сомнительные предложения (1-2 экземпляра) непонятного происхождения и не факт, что подходящих для наших частот связи. В общем, это не наш путь.

Хорошо, эти аппараты нам не подходят, можно ли найти в списке поддерживаемых LineageOS устройств что-то подходящее? После тщательного просмотра всего списка устройств я не нашёл ни одного (нового, не б/у) смартфона, который можно было бы просто купить в обычном магазине или хотя бы заказать через интернет с быстрой доставкой.

Всё, на этом эксперимент можно было завершать. Как говорится, хороша Маша, да не наша. Но меня уже охватил спортивный азарт и отказываться от Маши не хотелось, поэтому я ещё раз прошерстил список и где-то на четвёртой или пятой итерации обратил внимание на модель Motorola G7. По итогам, это практически единственный актуальный, доступный и подходящий нам аппарат из всего списка LineageOS.

Motorola G7

На тот момент мне было всё равно Motorola это или Rockola (смайл), аппарат выбирался для эксперимента и исключительно по двум критериям — он должен быть новым (зачем нам старый?), не б/у, и присутствовать в списке поддерживаемых LineageOS.

Но в случае с Motorola G7 звёзды прямо сошлись: это свежий (2019 года) аппарат, официально поставляется в Россию, поддерживается LineageOS и, как потом оказалось, он ещё и весьма приличный смартфон и при этом относительно недорого стоит.

Пара слов о цене. Motorola G7 стартовал в апреле 2019 года по цене 20 тыс. рублей, на момент написания статьи его можно свободно купить за 11 тыс. рублей, в интернете есть сообщения, что кому-то удавалось купить его по акции за 9, 8, и даже 6 тыс. рублей (что просто даром).

При этом он имеет на борту 4 ГБ оперативной и 64 ГБ встроенной памяти, NFC, отличный 2270х1080 дисплей 6.2″, лоток на две SIM карты плюс microSD, 2 камеры, сканер отпечатка пальца, USB Type-C, быструю зарядку, 9-й, т. н. «чистый» Android и много чего ещё, см. официальную страницу производителя. Как говорил один известный персонаж, да это просто праздник какой-то!

Немного о модельном ряде. В линейке Moto G7 присутствуют четыре модели: G7 Play, G7 Power, просто G7 без индекса и G7 Plus. Из всех четырёх моделей нашего внимания достойны только две последние, причём G7 Plus более интересный вариант, практически за те же деньги, что и G7. Но в нашем случае критерием выбора является присутствие смартфона в списке поддерживаемых LineageOS, а это только один вариант — Motorola G7.

Покупка и первые впечатления

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

На борту так называемый «практически чистый» 9-й Android с некоторыми фирменными добавлениями и «фишками» от Моторолы. Не знаю, что подразумевали авторы термина «чистый Андроид», но по сути это зонд, принадлежащий компаниям производителям железа и софта (но никак не вам, по крайней мере до тех пор, пока у вас не будет root прав на устройстве), который отправляет каждый ваш чих на их сервера, а через трекеры, встроенные в приложения, и на десятки серверов по всему миру неустановленному кругу третьих лиц (смотри подробности в статьях fur_habr).

Да, картина, прямо скажем, удручающая. Можно ли как-то исправить это положение? Попробуем разобраться и переходим к хирургическим методам. Пациент готов. Ассистент, скальпель!

Шаг 1. Разблокировка загрузчика

Смартфон поставляется с заблокированным загрузчиком. Это означает, что вы не сможете установить на него стороннюю прошивку. Для того, чтобы установить на него LineageOS, вам нужно сначала разблокировать загрузчик.

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

Примечание: здесь и далее речь будет идти о Windows 7 64-bit, если у вас другая операционная система, то действия могут немного отличаться.

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

Также вам нужно скачать и установить Android platform-tools с adb и fastboot. Если вы будете работать не из директории platform-tools, то вам нужно добавить путь к ней в настройках Windows (Компьютер — Свойства — Дополнительные параметры системы — Переменные среды — Path).

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

В меню разработчика (Настройки — Система — Для разработчиков) активируем «Отладку по USB», а в меню Настройки — Система — Для разработчиков — Отладка Android активируем «Android Debug Bridge (ADB)». После этого подключаем смартфон к компьютеру, запускаем окно с командной строкой (cmd) и вводим первую команду:

>adb devices 

Если всё сделано правильно, то в ответ система сообщит о найденном устройстве:

List of devices attached AH418JDANZ device 

Затем вводим команду перезагрузки смартфона в режим бутлоадера:

>adb reboot bootloader 

Далее проверяем видит ли компьютер подсоединённое устройство в этом режиме:

>fastboot devices AH418JDANZ fastboot 

Если всё нормально, то вводим команду на запрос кода для разблокировки:

>fastboot oem get_unlock_data 

В ответ смартфон должен выдать что-то вроде этого:

(bootloader) 93A1958E29857298# (bootloader) 405685468A0468F59638571E31040158805403469# (bootloader) 7035F204E85348570698340A620968E34029663206# (bootloader) 54269720984560184604890000000000 OKAY [ 0.020s] Finished. Total time: 0.022s 

Далее просто склеиваем эту последовательность цифр в одну строку (надписи bootloader, скобки и пробелы удаляем, знаки # оставляем) и получается такая строка:

93A1958E29857298#405685468A0468F59638571E31040158805403469#7035F204E85348570698340A620968E34029663206#54269720984560184604890000000000 

На своей странице по разблокировке Motorola много раз предупреждает о последствиях разблокировки загрузчика (самое невинное из которых это потеря гарантии) — внимательно прочитайте эти предупреждения и ещё раз подумайте готовы ли вы взять на себя ответственность за возможные последствия ваших действий.

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

Фрагмент ответа из письма от сервиса разблокировки Motorola:

Bootloader Unlock Here is the unique code to unlock the bootloader of your Motorola phone. Unlock Code: 42UKUKYULUYDTRETMDFG 

Далее нам нужно в меню разработчика включить функцию разрешения разблокировки загрузчика «Allow OEM Unlock» и ещё раз перезагрузить телефон. Затем подключаемся к смартфону так, как это было описано выше, и вводим команду для разблокировки загрузчика:

>fastboot oem unlock 42UKUKYULUYDTRETMDFG 

Получаем ответ в котором система предупреждает, что все ваши данные будут стёрты, соответственно, если у вас есть ценная информация, то вы должны прервать процесс и скопировать её в безопасное место (а лучше сделать это заранее):

(bootloader) WARNING: This command erases all user data. (bootloader) Please re-run this command to continue. OKAY [ 0.004s] Finished. Total time: 0.006s 

И ещё раз вводим ту же команду:

>fastboot oem unlock 42UKUKYULUYDTRETMDFG 

И вот, наконец, сообщение об успешной разблокировке загрузчика:

(bootloader) Bootloader is unlocked! Rebooting phone OKAY [ 0.680s] Finished. Total time: 0.681s 

На этом первый этап нашего эксперимента можно считать завершённым, перезагружаем смартфон и получаем сообщение о том, что загрузчик разблокирован и безопасность нашего телефона находится под угрозой (ага). Сообщение держится на экране 5 секунд и затем смартфон загружается обычным образом.

Шаг 2. Установка TWRP

Переходим ко второй части марлезонского балета. Для того, чтобы установить LineageOS на смартфон, сначала нужно установить т. н. «кастом рекавери» (custom recovery) для проведения операций по очистке разделов смартфона, загрузки файлов, самой прошивки LineageOS и прочих операций.

С TWRP тоже не всё так просто. Существует официальный сайт на котором присутствуют «официальные» сборки TWRP. Рекомендуется скачивать файлы именно с официального сайта, а не со сторонних ресурсов. Также не рекомендуется пользоваться сторонними сборками, поскольку они могут содержать в себе различные закладки.

В случае с Motorola G7 (о чудо!) существует свежее официальное TWRP, которое специально рассчитано на эту модель и устанавливается на телефон на раз-два, без каких-либо проблем. Значимость этого факта можно оценить, почитав форумы и стенания владельцев многих современных телефонов, например, популярного Samsung Galaxy A10 и всей линейки A20, A30, A40, A50… Этих моделей нет в официальном списке поддерживаемых устройств на сайте TWRP.

Переходим на страницу нашего (воистину) замечательного Motorola G7 и скачиваем последнюю на данный момент сборку TWRP twrp-3.3.1-2-river.img.

В официальной инструкции по установке LineageOS рекомендуется на компьютерах с Windows дополнительно выполнить команду

fastboot set_active a 

и принудительно сделать активным слот A. По их описанию это связано с ошибкой в реализации fastboot в Windows. И вообще, прежде чем что-то делать, настоятельно рекомендую внимательно ознакомиться с официальной инструкцией на этой странице — там всё написано правильно и очень подробно. Правда на английском, но настоящего любителя мобильных коммуникаций это вряд ли остановит (здесь опять запрещённый смайл).

Ответ Motorola G7 на эту команду:

Setting current slot to 'a' (bootloader) Slot already set active OKAY [ 0.001s] Finished. Total time: 0.004s 

Всё, на этом шутки закончились и любое неправильное действие может привести к окирпичиванию вашего драгоценного телефона. Далее действуем очень внимательно и аккуратно.

Вводим команду записи TWRP на устройство:

>fastboot flash boot_a twrp-3.3.1-2-river.img 

Система сообщает что файл не подписан, но процесс завершён успешно.

Sending 'boot_a' (27096 KB) OKAY [ 0.725s] Writing 'boot_a' (bootloader) Image not signed or corrupt OKAY [ 0.145s] Finished. Total time: 0.878s 

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

Шаг 3. Установка LineageOS

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

copy-partitions.zip

На странице официальной инструкции по инсталляции LineageOS на Motorola G7 говорится о возможных проблемах с A/B слотами на некоторых устройствах и рекомендуется перед инсталляцией прошивки LineageOS установить файл copy-partitions.zip. Скачиваем файл и проверяем его целостность с помощью MD5.

Как проверить MD5 в Windows: запускаем командой cmd окно терминала и вводим команду certutil -hashfile copy-partitions.zip MD5. Затем сравниваем полученные значения с кодом на странице загрузки.

LineageOS

Затем с официальной страницы загрузки LineageOS скачиваем файл прошивки последней версии lineage-16.0-20200109-nightly-river-signed.zip. И проверяем значение хеша SHA-256.

Как проверить хеш SHA-256 в Windows: запускаем командой cmd окно терминала и вводим команду certutil -hashfile lineage-16.0-20200108-nightly-river-signed.zip SHA256. Затем сравниваем полученные значения с кодом на странице загрузки.

AddonSU

Если вы хотите получить root права в вашей будущей системе, то можете скачать ещё AddonSU. Из списка нужно выбрать вариант arm64 addonsu-16.0-arm64-signed.zip, скачать его и затем проверить SHA-256 хеш.

Google apps

Ещё вы можете скачать для установки Google apps, но, как справедливо заметила fur_habr в своей статье, тогда вся затея с LineageOS теряет всякий смысл. Поэтому Google apps мы скачивать не будем, а за подробностями я вас отсылаю к статье и комментариям к ней.

Операции в TWRP

Запускаем прописанное на устройство TWRP:

fastboot boot twrp-3.3.1-2-river.img 

Запускается интерфейс нашего «кастом рекавери» и мы можем проводить заключительные действия по инсталляции LineageOS на наш смартфон Motorola G7.

В интерфейсе TWRP выбираем кнопку «Advanced» и далее «ADB Sideload», а на компьютере в командной строке набираем:

>adb sideload copy-partitions.zip 

После успешной загрузки файла система ответит:

Total xfer: 1.00x 

Затем в интерфейсе TWRP выбираем кнопку «Wipe» и далее «Format Data». После завершения процесса возвращаемся в предыдущее меню. Нажимаем на кнопку «Advanced Wipe» и выбираем «System» и «Cache».

Возвращаемся в главное меню и снова выбираем кнопку «Advanced» и далее «ADB Sideload», а на компьютере в командной вводим строке:

>adb sideload lineage-16.0-20200108-nightly-river-signed.zip 

и загружаем прошивку LineageOS в смартфон. Ответ при успешном выполнении операции:

Total xfer: 1.00x 

Если мы хотим установить root на устройство, то далее вводим команду:

adb reboot sideload 
>adb sideload addonsu-16.0-arm64-signed.zip 
Total xfer: 2.08x 

Вот теперь точно всё. Перезагружаем смартфон и нас встречает маленькое чудо — операционная система LineageOS.

Root

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

LineageOS

Да… в упорстве нам не откажешь… И вот, после всех этих титанических усилий мы всё-таки добились своего — установили LineageOS на Motorola G7. И что же мы имеем в итоге?

Это всё тот же 9-й Android и внешне эта система мало чем отличается от того, что было на родной прошивке Motorola G7. Кнопки примерно на тех же местах, функции примерно те же, в общем после смены операционной системы я не испытывал никаких затруднений или неудобств в работе со смартфоном.

Что мы потеряли?

Поскольку мы не стали устанавливать Google сервисы, то мы потеряли все программы, которые зависят от этих сервисов, а также мы лишились уведомлений, которые работают через них (это касается не всех приложений, но многих). В оригинальной статье (https://habr.com/ru/post/465945/) подробно рассматривается этот вопрос и даются рекомендации по установке альтернативных программ для поддержки Google сервисов.

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

Что мы приобрели?

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

Немного технических подробностей. То, что мы имеем сейчас в лице LineageOS уже можно с натяжкой назвать «чистым Андроидом». Это хорошо заметно по логу фаервола. Если в родной, якобы «чистой» прошивке Motorola G7 фаервол просто раскалялся от паразитной активности приложений и сервисов Google и Motorola и десятков трекеров в приложениях, то на LineageOS внутренняя жизнь системы приобрела вменяемый характер.

Система больше не напоминает проходной двор где шарятся все кому не лень, начиная от китайских девелоперов и заканчивая индусскими программистами и маркетологами со всего мира (попутно скачивая ваши приватные данные и протоколируя каждый ваш тап по экрану). Лог фаервола почти пустой и найти в нём можно только те приложения и только по тем адресам и портам которые нужны непосредственно для их работы и которые одобрены мной, как хозяином (!) устройства.

Как это сказалось на расходе батареи и объёме платного трафика я думаю пояснять не нужно. Андроид просто перестал заниматься огромным количеством посторонних дел и растрачивать на это свои ресурсы (перестал обслуживать чужие, прямо противоречащие вашим, интересы).

Есть ли жизнь на LineageOS?

После установки LineageOS и посещения F-Droid я закрыл 95% своих потребностей в программах на Android. Есть набор стандартных «Simple» приложений (часы, калькулятор, блокнот, календарь, файловый менеджер и т. д.), есть проигрыватели аудио и видео (VLC), есть карты, читалки, есть отличный почтовый клиент (K-9), в репозитории F-Droid есть более 2000 приложений на любой вкус, есть даже версия Telegram, работающая без Google сервисов для поклонников этого мессенджера.

Для тех редких случаев когда нужная программа есть только в Google Play, можно воспользоваться альтернативными клиентами Yalp store или Aurora Store.

Телефон звонит, СМС-ки ходят, почта работает, интернет в полном объёме, доступны все сервисы при авторизации через браузер, есть свободное облако, при желании можно поставить Telegram и т. д. и т. п. В общем, на мой взгляд, LineageOS это вариант не для всех и не всегда, но во многих случаях это просто отличное решение.

Выводы

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

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

Что со всем этим делать предлагаю читателям решать самостоятельно.

Послесловие

В общем, я доволен проведённым экспериментом — за это время я узнал много интересного и, как гик, получил огромное удовольствие от тесного общения с классным аппаратом Motorola G7. В результате я получил «чистый» телефон, который просто приятно держать в руках, ощущая себя его хозяином и не опасаясь, что в этот момент он что-то куда-то сливает или делает фотографии.

Пока Motorola G7 остаётся полем для экспериментов и «вторым» телефоном, наряду с моим старым аппаратом, набитым всякой «шнягой» типа Google сервисов и Ватсапа и после использования которого хочется перекреститься и помыть руки (смайл).

И напоследок пара фотографий свободного Motorola G7 с установленной на нём LineageOS.

Как проверить sha256 в android устройствах

Kaspersky Security для мобильных устройств соответствует Общим нормам защиты данных (GDPR).

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

  • Положение о Kaspersky Security Network;
  • Положение об обработке данных для использования Веб-Фильтра;
  • Положение об обработке данных в маркетинговых целях.

Если выбран вариант, при котором Положения принимаются глобально, версии Положений, принимаемые в Kaspersky Security Center, должны совпадать с версиями, уже принятыми пользователями. В противном случае пользователи будут проинформированы об этой проблеме, и им будет предложено принять ту версию Положения, которая соответствует версии, принятой администратором глобально. Статус устройства в плагине Kaspersky Security for Mobile (Devices) изменится на Предупреждение.

Пользователь может в любой момент принять условия Положения или отказаться от них в разделе О приложении в настройках Kaspersky Endpoint Security для Android.

Обмен информацией с Kaspersky Security Network

Для повышения уровня постоянной защиты Kaspersky Endpoint Security для Android использует облачную службу Kaspersky Security Network в работе следующих компонентов:

  • Антивирус. Приложение получает доступ к оперативной базе знаний «Лаборатории Касперского» о репутации файлов и приложений. Проверка производится на угрозы, информация о которых еще не вошла в антивирусные базы, но уже содержится в KSN. Облачная служба Kaspersky Security Network обеспечивает полноценную работу Антивируса и снижает вероятность ложных срабатываний.
  • Веб-Фильтр . Приложение выполняет проверку веб-сайтов перед открытием с учетом данных, полученных от KSN. Также приложение определяет категорию веб-сайта для контроля доступа пользователей в интернет на основе списков разрешенных и запрещенных категорий (например, категория «Общение в сети»).
  • Контроль приложений . Приложение определяет категории для ограничения запуска приложений, которые не удовлетворяют требованиям корпоративной безопасности, на основе списков разрешенных и запрещенных категорий (например, категория «Игры»).

Информация о типах данных, передаваемых в «Лабораторию Касперского» при использовании KSN во время работы компонентов Антивирус и Контроль приложений, приведена в Лицензионном соглашении. Принимая условия Лицензионного соглашения, вы соглашаетесь передавать следующую информацию.

Информация о типах данных, передаваемых в «Лаборатории Касперского» при использовании KSN во время работы Веб-Фильтра, доступна в Положении об обработке данных для использования Веб-Фильтра. Принимая условия этого Положения, вы соглашаетесь передавать перечисленную ниже информацию.

Информация о типах статистических данных, передаваемых в «Лабораторию Касперского» при использовании KSN во время работы мобильного приложения Kaspersky Endpoint Security для Android, приведена в Положении о Kaspersky Security Network. Принимая условия этого Положения, вы соглашаетесь передавать перечисленную ниже информацию.

Предоставление данных в рамках Лицензионного соглашения

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

  • формат данных в запросе к инфраструктуре Правообладателя; IP-адрес (IPv4) веб-службы, на который осуществлялось обращение; размер содержимого запроса к инфраструктуре Правообладателя; идентификатор протокола; код активации ПО; тип сжатия данных; идентификатор ПО; набор идентификаторов ПО, которое может быть активировано на устройстве пользователя; локализация ПО; полная версия ПО; уникальный идентификатор устройства; дата и время на устройстве пользователя; идентификатор установки ПО (PCID); версия ОС, номер сборки ОС, номер обновления ОС, редакция ОС, расширенная информация о редакции ОС; модель устройства; семейство операционной системы; формат данных в запросе к инфраструктуре Правообладателя; тип контрольной суммы обрабатываемого объекта; заголовок лицензии на использование ПО; идентификатор регионального центра активации; дата и время создания лицензионного ключа ПО; идентификатор лицензии ПО; идентификатор информационной модели, примененной при предоставлении лицензии на использование ПО; дата и время истечения срока действия лицензии на использование ПО; текущий статус лицензионного ключа ПО; тип используемой лицензии ПО; тип лицензии, с помощью которой активировано ПО; идентификатор ПО, полученный из лицензии.

Для защиты Компьютера от угроз информационной безопасности Пользователь соглашается периодически предоставлять Правообладателю следующую информацию:

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

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

  • идентификатор ПО, полученный из лицензии; полная версия ПО; идентификатор лицензии ПО; тип используемой лицензии ПО; идентификатор установки ПО (PCID); идентификатор запуска обновления ПО; обрабатываемый веб-адрес.

Правообладатель может также использовать такую информацию для получения статистической информации о распространении и использовании ПО.

Полученная информация защищается «Лабораторией Касперского» в соответствии с установленными законом требованиями. Исходная полученная информация хранится в зашифрованном виде и уничтожается по мере накопления (два раза в год) или по запросу Пользователя. Данные общей статистики хранятся бессрочно.

Предоставление данных в рамках Положения о Kaspersky Security Network

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

Если вы используете лицензию для 5 и более узлов, то при использовании KSN Правообладатель будет получать и обрабатывать следующие данные в автоматическом режиме:

  • идентификатор сработавшей записи в антивирусных базах ПО; временная метка сработавшей записи в антивирусных базах ПО; тип сработавшей записи в антивирусных базах ПО; дата и время выпуска баз ПО; версия ОС, номер сборки ОС, номер обновления ОС, редакция ОС, расширенная информация о редакции ОС; версия пакета обновления ОС; характеристики обнаружения; контрольная сумма (MD5) обрабатываемого объекта; имя обрабатываемого объекта; признак того, что обрабатываемый объект является PE-файлом; контрольная сумма (MD5) маски, по которой была заблокирована веб-служба; контрольная сумма (SHA256) обрабатываемого объекта; размер обрабатываемого объекта; код типа объекта; заключение ПО по обрабатываемому объекту; путь к обрабатываемому объекту; код каталога файлов; версия компонента ПО; версия отправляемой статистики; адрес веб-службы, на который осуществлялось обрабатываемое обращение (веб-адрес, IP); тип клиента, используемого для обращения к веб-службе; IP-адрес (IPv4) веб-службы, на который осуществлялось обращение; IP-адрес (IPv6) веб-службы, на который осуществлялось обращение; веб-адрес источника запроса к веб-службе (referer); обрабатываемый веб-адрес;
  • информация о проверяемых объектах (версия приложения, извлеченная из AndroidManifest.xml; решение ПО по приложению; метод, использованный для получения решения ПО по приложению; название пакета установщика магазина; название пакета (package/bundle) из androidmanifest.xml; категория Google SafetyNet; признак того, что SafetyNet включен на устройстве; значение SHA256 в ответе от Google SafetyNet; APK Signature Scheme для APK-сертификата; код версии установленного ПО; серийный номер сертификата, которым подписан APK; название устанавливаемого APK-файла; путь до устанавливаемого APK-файла; компания, выпустившая сертификат, которым подписан APK-файл; публичный ключ, которым подписан APK-файл; контрольная сумма сертификата, которым подписан APK-файл; дата и время истечения сертификата; дата и время выдачи сертификата; версия отправляемой статистики; алгоритм расчета отпечатка цифрового сертификата; хеш MD5 от установленного APK-файла; Хеш MD5 от DEX-файла, расположенного внутри установленного APK-файла; динамические разрешения, которые есть у приложения; версия стороннего ПО; информация о том, является ли приложение SMS-менеджером по умолчанию; информация о том, есть ли у приложения права администратора устройства; признак того, что приложение находится в системном каталоге; информация о том, использует ли приложение специальные возможности (accessibility));
  • информация обо всех потенциально вредоносных объектах и действиях (содержимое фрагмента в обрабатываемом объекте; дата и время истечения сертификата; дата и время выдачи сертификата; идентификатор ключа из хранилища ключей, используемого для шифрования; протокол, используемый для передачи данных в KSN; порядковый номер фрагмента в обрабатываемом объекте; данные внутреннего журнала, сформированного антивирусным компонентом ПО для обрабатываемого объекта; наименование эмитента сертификата; публичный ключ сертификата; алгоритм вычисления публичного ключа сертификата; серийный номер сертификата; дата и время подписи объекта; имя и параметры владельца сертификата; отпечаток цифрового сертификата проверяемого объекта и алгоритм хеширования; дата и время последней модификации обрабатываемого объекта; дата и время создания обрабатываемого объекта; обрабатываемые объекты или их части; описание обрабатываемого объекта, указанное в его свойствах; формат обрабатываемого объекта; тип контрольной суммы обрабатываемого объекта; контрольная сумма (MD5) обрабатываемого объекта; имя обрабатываемого объекта; контрольная сумма (SHA256) обрабатываемого объекта; размер обрабатываемого объекта; название продавца ПО; заключение ПО по обрабатываемому объекту; версия обрабатываемого объекта; источник заключения по обрабатываемому объекту; контрольная сумма обрабатываемого объекта; имя приложения, частью которого является обрабатываемый объект; путь к обрабатываемому объекту; информация о результатах проверки подписи файла; ключ сеанса входа; алгоритм шифрования ключа сеанса входа; время хранения обрабатываемого объекта; алгоритм расчета отпечатка цифрового сертификата);
  • тип сборки, например, «user» или «eng»; полное имя продукта; производитель продукта / устройства; разрешена ли установка приложений не из Google Play; статус облачной службы по проверке приложений от Google; статус облачной службы по проверке приложений от Google, устанавливаемых через ADB; текущее название или строка «REL» для публичных сборок; инкрементальный номер сборки; строка версии, отображающаяся у пользователя; название устройства пользователя; идентификатор сборки ПО, отображающийся у пользователя; отпечаток прошивки; идентификатор прошивки; признак рутованности устройства; операционная система; название ПО; тип используемой лицензии ПО;
  • информация о качестве работы сервисов KSN (протокол, используемый для передачи данных в KSN; идентификатор службы KSN, к которой обращается ПО; дата и время окончания получения статистик; количество подключений к KSN, взятых из кеша; количество запросов, для которых был найден ответ в локальной базе запросов; количество неуспешных подключений к KSN; количество неуспешных KSN-транзакций; распределение по времени выполнения отмененных запросов к KSN; распределение по времени выполнения неуспешных подключений к KSN; распределение по времени выполнения неуспешных KSN-транзакций; распределение по времени выполнения успешных подключений к KSN; распределение по времени выполнения успешных KSN-транзакций; распределение по времени выполнения успешных запросов к KSN; распределение по времени выполнения запросов к KSN, превысивших ограничение на время ожидания; количество новых подключений к KSN; количество неуспешных запросов к KSN из-за ошибок маршрутизации; количество неуспешных запросов из-за выключенного KSN в параметрах ПО; количество неуспешных запросов к KSN из-за сетевых проблем; количество успешных подключений к KSN; количество успешных KSN-транзакций; количество выполненных запросов к KSN; дата и время начала получения статистики);
  • идентификатор устройства; полная версия ПО; идентификатор обновления ПО; идентификатор установки ПО (PCID); тип установленного ПО;
  • высота экрана устройства; ширина экрана устройства; информация о перекрывающем приложении: хеш MD5 APK-файла; информация о перекрывающем приложении: хеш MD5 файла classes.dex; информация о перекрывающем приложении: имя APK-файла; информация о перекрывающем приложении: путь к APK-файлу без имени файла; высота перекрытия; информация о перекрытом ПО: хеш MD5 APK-файла; информация о перекрытом приложении: хеш MD5 файла classes.dex; информация о перекрытом приложении: имя файла APK; информация о перекрытом приложении: путь к файлу APK без имени файла; информация о перекрытом приложении: название пакета приложения (для перекрытого приложения: если реклама отображается на пустом экране, должно быть значение «launcher»); дата и время перекрытия; информация о перекрывающем приложении: название пакета приложения; ширина перекрытия;
  • параметры используемой точки доступа Wi-Fi (тип обнаруженного устройства; настройки протокола DHCP (контрольные суммы локального IPv6-адреса шлюза, DHCP IPv6, DNS1 IPv6, DNS2 IPv6, контрольная сумма длины префикса сети; контрольная сумма локального адреса IPv6); настройки DHCP (контрольные суммы: локального IP-адреса шлюза, DHCP IP, DNS1 IP, DNS2 IP, маски подсети); признак наличия домена DNS; контрольная сумма выданного локального IP-адреса (IPv6); контрольная сумма выданного локального IP-адреса (IPv4); признак работы устройства от электрической сети; тип аутентификации Wi-Fi сети; список доступных Wi-Fi сетей и их параметры; контрольная сумма (MD5 с модификатором) MAC-адреса точки доступа; контрольная сумма (SHA256 с модификатором) MAC-адреса точки доступа; типы соединений, поддерживаемые точкой доступа Wi-Fi; тип шифрования сети Wi-Fi; локальное время начала и конца подключения к сети Wi-Fi; идентификатор сети Wi-Fi, посчитанный по MAC-адресу точки доступа; идентификатор сети Wi-Fi, посчитанный по её названию; идентификатор сети Wi-Fi, посчитанный по её названию и MAC-адресу точки доступа; уровень сигнала сети Wi-Fi; название Wi-Fi сети; набор протоколов аутентификации, поддерживаемых этой конфигурацией; используемый протокол аутентификации при подключении вида WPA-EAP; используемый протокол внутренней аутентификации; набор групповых шифров, поддерживаемых этой конфигурацией; набор протоколов управления ключами, поддерживаемых этой конфигурацией; итоговая категория публичности сети в ПО; итоговая категория безопасности сети в ПО; набор парных шифров для WPA, поддерживаемых этой конфигурацией; набор протоколов безопасности, поддерживаемых этой конфигурацией);
  • дата и время установки ПО; дата активации ПО; идентификатор компании партнера, у которого был размещен заказ на покупку лицензии на использование ПО; идентификатор ПО, полученный из лицензии; серийный номер лицензионного ключа ПО; локализация ПО; признак участия в KSN; идентификатор ПО, для которого предназначена лицензия; идентификатор лицензии ПО; идентификатор ОС; разрядность операционной системы.

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

Участие в Kaspersky Security Network для обработки статистических данных является добровольным. Вы можете в любой момент отказаться от участия в Kaspersky Security Network.

Предоставление данных в рамках Положения об обработке данных для использования Веб-Фильтра

В соответствии с Положением о Веб-Фильтре, Правообладатель обрабатывает данные в целях обеспечения работы Веб-Фильтра. Заявленная цель включает обнаружение веб-угроз и определение категорий посещаемых веб-сайтов с помощью облачного сервиса Kaspersky Security Network (KSN).

С вашего согласия, следующие данные будут автоматически регулярно отправляться Правообладателю в соответствии с Положением о Веб-Фильтре:

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

Предоставление данных в рамках Положения об обработке данных для маркетинговых целей

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

Google Analytics для Firebase

При использовании ПО следующие данные будут автоматически отправляться на регулярной основе в сервис Google Analytics для Firebase для их обработки для заявленных целей:

  • информация о приложении: версия, идентификатор, название и идентификатор приложения в сервисе Firebase, уникальный идентификатор установки в сервисе Firebase, название магазина, из которого ПО было получено, время первого запуска ПО на устройстве;
  • идентификатор установки приложения на устройство и способ установки на устройство;
  • информация о регионе и языковой локализации;
  • разрешение экрана устройства;
  • информация о получении root -прав пользователем;
  • диагностические данные об устройстве от сервиса SafetyNet Attestation;
  • признак установки Kaspersky Endpoint Security для Android в качестве службы Специальных возможностей;
  • информация о переходах между окнами приложения, продолжительности сессии, начале и окончании сессии работы с экраном, названии экрана;
  • информация о протоколе отправки данных в сервис Firebase, его версии и идентификаторе используемого метода отправки данных;
  • информация о типе и параметрах события, в отношении которого происходит отправка данных;
  • информация о лицензии на приложение, ее наличии, количестве устройств;
  • интервалы обновления антивирусных баз и синхронизации с Сервером администрирования;
  • информация о консоли администрирования (Kaspersky Security Center или сторонние ЕММ-системы);
  • идентификатор Android ID;
  • идентификатор Advertising ID;
  • информация о пользователе: возрастная категория и половая принадлежность пользователя, идентификатор страны проживания, список интересов пользователя;
  • информация о компьютере, на котором установлено ПО: название производителя компьютера, тип компьютера, модель устройства, версия и информация о языковой локализации ОС, информация о первом запущенном приложении за последнюю неделю и ранее. Передача данных в сервис Google Analytics для Firebase осуществляется по защищенному каналу. Информация об условиях обработки данных в сервисе Google Analytics для Firebase доступна по адресу https://firebase.google.com/support/privacy.

При использовании ПО следующие данные будут автоматически отправляться на регулярной основе в сервис SafetyNet Attestation для их обработки для заявленных целей:

  • время проверки устройства;
  • информация о ПО, название и данные о сертификатах ПО;
  • результаты проверки устройства;
  • случайный идентификатор проверки для верификации результатов проверки устройства. Передача данных в сервис SafetyNet Attestation осуществляется по защищенному каналу. Информация об условиях обработки данных в сервисе SafetyNet Attestation доступна по адресу https://policies.google.com/privacy.

Firebase Performance Monitoring

При использовании ПО следующие данные будут автоматически отправляться на регулярной основе в сервис Firebase Performance Monitoring для их обработки для заявленных целей:

  • уникальный идентификатор установки;
  • название пакета приложения;
  • версия установленного ПО;
  • уровень и статус заряда батареи;
  • оператор связи;
  • признак работы ПО в фоновом режиме;
  • регион;
  • IP-адрес;
  • код языка устройства;
  • информация о радио- и интернет-соединении;
  • идентификатор-псевдоним экземпляра ПО;
  • ОЗУ и размер диска;
  • признак того, что на устройстве выполнена процедура рутинга или джейлбрейка;
  • уровень сигнала;
  • продолжительность автоматической трассировки;
  • информация о сети и сопутствующая информация ответа: код ответа, размер полезной нагрузки в байтах, время отклика;
  • описание устройства. Передача данных в сервис Firebase Performance Monitoring осуществляется по защищенному каналу. Информация об условиях обработки данных в сервисе Firebase Performance Monitoring доступна по адресу https://firebase.google.com/support/privacy.

При использовании ПО следующие данные будут автоматически отправляться на регулярной основе в сервис Crashlytics для их обработки для заявленных целей:

  • идентификатор ПО;
  • версия установленного ПО;
  • признак работы ПО в фоновом режиме;
  • архитектура ЦП;
  • уникальный идентификатор события;
  • дата и время события;
  • модель устройства;
  • объем полного и используемого дискового пространства;
  • название и версия ОС;
  • объем полной и используемой оперативной памяти;
  • признак того, что на устройстве выполнена процедура рутинга;
  • ориентация экрана в момент события;
  • производитель продукта / устройства;
  • уникальный идентификатор установки;
  • версия отправляемой статистики;
  • тип исключения ПО;
  • текст сообщения об ошибке;
  • признак того, что исключение ПО вызвано исключением на вложенном уровне;
  • идентификатор потока;
  • признак того, что фрейм стал причиной ошибки ПО;
  • признак того, что выполнение потока привело к неожиданному завершению работы ПО;
  • данные о сигнале, который привел к неожиданному завершению работы ПО: название сигнала, код сигнала, адрес сигнала;
  • для каждого фрейма, ассоциированного с потоком, исключением или ошибкой: имя файла фрейма, номер строки файла фрейма, отладочные символы, адрес и смещение в бинарном образе, отображаемое имя библиотеки, содержащей фрейм, тип фрейма, признак того, что фрейм стал причиной ошибки;
  • идентификатор ОС;
  • идентификатор проблемы, связанной с событием;
  • информация о событиях, предшествующих неожиданному завершению работы ПО: идентификатор события, дата и время события, тип события и значение;
  • значения регистра ЦП;
  • тип события и значение. Передача данных в сервис Crashlytics осуществляется по защищенному каналу. Информация об условиях обработки данных в сервисе Crashlytics доступна по адресу https://firebase.google.com/terms/crashlytics-app-distribution-data-processing-terms.

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

Как получить хэш андроид приложения?

Разбираюсь с SMS Retriever API(https://developers.google.com/identity/sms-retriever/overview). В требованиях к смс сообщению с одноразовым кодом, среди прочего, описано требование, чтобы смс приходило с подписью (подписью является хэш приложения, минимум из 11 символов). В этой же статье написано, что не рекомендуется получать хэш из приложения. Главный вопрос: как можно получить хэш приложения, и может ли он меняться в процессе разных доработок приложения в будущем, или он статический? Пока разбирался с АПИ нашел код который выдаёт хэш, но никак не выходит найти как можно получить такой хэш не через код в приложении. Код который выдаёт нужный хэш:

private static final String TAG = "AppSignatureHelper"; private static final String HASH_TYPE = "SHA-256"; public static final int NUM_HASHED_BYTES = 9; public static final int NUM_BASE64_CHAR = 11; public AppSignatureHelper(Context context) < super(context); >@RequiresApi(api = Build.VERSION_CODES.KITKAT) public ArrayList getAppSignatures() < ArrayListappCodes = new ArrayList<>(); try < // Get all package signatures for the current package String packageName = getPackageName(); PackageManager packageManager = getPackageManager(); Signature[] signatures = packageManager.getPackageInfo(packageName, PackageManager.GET_SIGNATURES).signatures; // For each signature create a compatible hash for (Signature signature : signatures) < String hash = hash(packageName, signature.toCharsString()); if (hash != null) < appCodes.add(String.format("%s", hash)); >> > catch (PackageManager.NameNotFoundException e) < Log.e(TAG, "Unable to find package to obtain hash.", e); >return appCodes; > @RequiresApi(api = Build.VERSION_CODES.KITKAT) private static String hash(String packageName, String signature) < String appInfo = packageName + " " + signature; try < MessageDigest messageDigest = MessageDigest.getInstance(HASH_TYPE); messageDigest.update(appInfo.getBytes(StandardCharsets.UTF_8)); byte[] hashSignature = messageDigest.digest(); // truncated into NUM_HASHED_BYTES hashSignature = Arrays.copyOfRange(hashSignature, 0, NUM_HASHED_BYTES); // encode into Base64 String base64Hash = Base64.encodeToString(hashSignature, Base64.NO_PADDING | Base64.NO_WRAP); base64Hash = base64Hash.substring(0, NUM_BASE64_CHAR); Log.e(TAG, String.format("pkg: %s -- hash: %s", packageName, base64Hash)); return base64Hash; >catch (NoSuchAlgorithmException e) < Log.e(TAG, "hash:NoSuchAlgorithm", e); >return null; > 

Отслеживать

13.7k 12 12 золотых знаков 43 43 серебряных знака 75 75 бронзовых знаков

задан 25 янв 2021 в 17:40

Держи свой трафик в тайне. SSL Pinning — ещё раз о том же самом

Меня зовут Юрий Шабалин, как вы, наверное, уже знаете, я один из основателей компании Стингрей Технолоджиз, разработчика платформы анализа защищенности мобильных приложений iOS и Android.

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

Оглавление

  • Введение
  • Немного про протоколы
    • HTTP
    • HTTPS
      • Описание
      • Шифронаборы
      • TLS handshake (RSA)
      • TLS handshake (DHE/ECDHE)
      • Типы SSL Pinning
        • Certificate Pinning
        • Public key Pinning
        • Android Network Security Config
        • iOS App Transport Security
        • OkHttp
        • Retrofit
        • HttpUrlConnection
        • Volley

        Введение

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

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

        Немного про протоколы

        HTTP

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

        Аббревиатура HTTP расшифровывается как HyperText Transfer Protocol, «протокол передачи гипертекста». В соответствии со спецификацией OSI, HTTP является протоколом прикладного (верхнего, 7-го) уровня. Последняя на данный момент версия протокола, HTTP/2, описана в спецификации RFC 7540. Также готовится к публикации третяя версия протокола (HTTP/3)

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

        Задача, которая традиционно решается с помощью протокола HTTP — обмен данными между пользовательским приложением, осуществляющим доступ к веб-ресурсам (обычно это веб-браузер), и веб-сервером. На данный момент именно благодаря протоколу HTTP обеспечивается работа Всемирной паутины.

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

        Как правило, передача данных по протоколу HTTP осуществляется через TCP/IP-соединения. Серверное программное обеспечение при этом обычно использует TCP-порт 80, но могут быть задействованы и другие порты. Если порт не указан явно, то обычно клиентское программное обеспечение по умолчанию использует именно 80-й порт для открываемых HTTP-соединений.

        За описание протокола HTTP простыми словами спасибо вот этой статье.

        HTTPS

        Описание

        Как известно, протокол HTTP передает данные в открытом виде, то есть любой человек в сети может прослушать трафик и прочитать все сообщения, которыми обмениваются стороны. Для того, чтобы предотвратить возможность чтения и модификации запросов, поверх обычного HTTP добавили SSL и появился протокол HTTPS, где буква S расшифровывается как Secure, то есть безопасный. При HTTPS соединении все данные зашифровываются и расшифровать их могут только те, кому они предназначены (отправляющая и принимающая стороны). Реализовано это с применением SSL/TLS уровней защиты (Secure Sockets Layer / Transport Level Security). Давайте посмотрим, что это такое, и чем они отличаются друг от друга.

        История версий протоколов SSL/TLS

        SSL и TLS — это протоколы для защищенной передачи данных. TLS является прямым продолжением и, если можно так сказать, наследником SSL. Эти протоколы содержат в себе различные шифронаборы (Cipher Suites), которые можно использовать для осуществления операций шифрования, а также разнообразные правила коммуникации и многое другое. Первый протокол появился около 1995 года. От версии к версии он немного трансформировался: в него добавляли новые шифронаборы, убирали устаревшие, исправляли уязвимости и немного меняли сам протокол.

        Шифронаборы

        Что такое шифронаборы и почему они важны для нас?

        Шифронабор — это некоторая строка вида “ TLS_DH_RSA_WITH_AES_256_CBC_SHA256 ”, которая определяет, с использованием каких алгоритмов и по каким правилам будет осуществляться общение клиента и сервера. Давайте разберем по порядку, что за чем следует и что за что отвечает, — понимание этого потребуется нам в дальнейшем.

        • Protocol ( TLS ) – Протокол, по которому осуществляется соединение, а именно TLS или SSL.
        • Key Exchange ( DH ) – Алгоритм, по которому осуществляется обмен ключами. Это может быть RSA / DH (Диффи Хелман) / DHE (эфемерный Диффи Хелман) / ECDH (Диффи Хелман на эллиптических кривых) / ECDHE (эфемерный Диффи Хелман на эллиптических кривых) и другие. Чуть позже мы поймем, зачем я в обязательном порядке отметил эфемерные шифронаборы и дал каждому алгоритму расшифровку.
        • Authentication ( RSA ) – определяет, по какому алгоритму будет проходить аутентификация сторон (RSA / DSA / ECDSA / . )
        • Stream encryption ( AES_256_CBC ) — определяет, по каким протоколам будет осуществляться шифрование потока. При этом указывается длина ключа и режим (RC4_128 / AES_256_CBC / 3DES_EDE_CBC / . )
        • Message Authentication( SHA256 )— определяет, каким алгоритмом будет осуществляться подпись сообщений (MD5 / SHA / SHA256 / . )

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

        Даже некоторые регуляторы и мировые стандарты рекомендуют обращать пристальное внимание на используемую версию протокола и применяемые шифронаборы. Если обратиться к PCI DSS, то можно найти рекомендацию по обязательному отключению SSL/early TLS и использованию “Strong Cryptography“.

        Выдержка из PCI DSS

        При этом, включая только последние версии TLS с правильно настроенными шифронаборами, мы автоматически применяем свойство некоторых алгоритмов — Forward Secrecy (иногда Perfect FS). Его особенность в том, что компрометация сессионных ключей не происходит при компрометации одного из долговременных ключей. Работает эта опция только для эфемерных алгоритмов. То есть, речь идет про шифронаборы, начинающиеся с:

        TLS_DHE_* (EDH) Ephemeral DH

        TLS_ECDHE _* (EECDH) Ephemeral ECDH

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

        TLS handshake (RSA)

        Схематично можно изобразить TLS-рукопожатие (процесс установки защищенного соединения) в виде следующей схемы:

        TLS-рукопожатие (RSA)

        Разберемся простыми словами, что при этом происходит:

        1. Чтобы соединиться с сервером, клиент отправляет ему некоторый Hello-запрос. Условно, он говорит: “Привет сервер, я хотел бы начать с тобой общение“.
        2. На сервере хранится пара ключей: приватный ключ (его никому нельзя передавать, раскрывать, и его компрометация ведет к самым печальным последствиям) и публичный ключ.
          В ответ на запрос клиента, сервер отправляет ему свой сертификат, в котором содержится его публичный ключ.
        3. Клиент на своей стороне вырабатывает предварительный секрет (большое случайное число), шифрует его на публичном ключе сервера, и этот зашифрованный секрет отправляет по сети серверу.
        4. Сервер, используя свой приватный ключ, расшифровывает предварительный секрет, и обе стороны независимо друг от друга вырабатывают Главный секрет, используя криптографическую магию.
        5. После того, как на обеих сторонах имеется одинаковый главный секрет, вырабатываются сеансовые ключи. На их основе уже и происходит шифрование данных. С этого момента защищенное соединение считается установленным и можно начинать передавать данные.

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

        TLS handshake (DHE/ECDHE)

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

        TLS-рукопожатие (DHE/ECDHE)

        И снова разберем, что происходит, и посмотрим на отличия:

        1. В первой части отличий никаких: клиент также отправляет запрос на подключение к серверу.
        2. Затем сервер так же возвращает клиенту свой публичный ключ из пары ключей вместе с сертификатом.
        3. А вот с этого момента применяются свойства эфемерных шифронаборов, а также немного криптографической магии. Вместо генерации предварительного секрета и его шифрования на публичном ключе, клиентская сторона вырабатывает свою пару ключей Диффи Хелмана, и открытый (публичный) ключ отправляет на сервер.
        4. Сервер на своей стороне также генерирует ключи с использованием эфемерного алгоритма и передает сгенерированный публичный ключ на сторону клиента.
        5. Вот тут происходит настоящая криптографическая магия, и на основе всей информации стороны независимо друг от друга могут сгенерировать Предварительный и Главный секреты.
        6. После этого на основе Главного секрета вырабатываются сеансовые ключи и начинается процесс передачи зашифрованных данных.

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

        Подведем итоги. При использовании TLS_DHE/ECDHE_* сессионный ключ не передается по сети. Общий секрет вырабатывается на основе DH с временными ключами, действительными только для текущей сессии.

        К слову, в iOS, при включенном и настроенном App Transport Security, приложение будет использовать PFS по умолчанию. Для детальной настройки реализована возможность управлять этой функцией с помощью ключа NSExceptionRequiresForwardSecrecy в plist файле. Выключение этого режима позволит использовать версии TLS, которые не поддерживают PFS.

        “Man In The Middle”, или “Человек посередине“

        Теперь, когда мы знаем, что такое HTTPS и как работает установка безопасного соединения, можно поговорить и о такой знаменитой атаке, как “Man In The Middle”. В русскоязычной литературе ее называют “Человек посередине“. Это атака на канал связи, при которой злоумышленник находится в одной сети с вами и обладает контролем над точкой доступа, или каким-то образом может перенаправить вас на свой прокси-сервер внутри сети. Злоумышленник для клиента представляется конечным сервером, а для сервера — клиентом. Он стоит “посередине“ между ними и способен читать и модифицировать трафик, проходящий через него. Но как это может быть реализовано? Ведь трафик зашифрован, и просто так прочитать его не получится. Проще всего это показать на небольшой схеме:

        Процесс атаки

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

        1. Приложение обращается к своему серверу через точку доступа, подконтрольную злоумышленнику.
        2. На этой точке доступа развернут Proxy-сервер, через который проходит весь трафик.
        3. При запросе на соединение со своим сервером, Proxy “представляется” конечным адресатом, и в ответ на клиентский SSL-запрос возвращает свой собственный сертификат со своим публичным ключом.
        4. Клиент генерирует и зашифровывает предварительный секрет или генерирует пару ключей и обменивается ими с сервером злоумышленника, а не со своим.
        5. Таким образом, защищенное подключение устанавливается именно со “зловредным“ сервером и он, как принимающая сторона, видит весь трафик.
        6. С другой стороны, Proxy “представляется“ клиентом для целевого сервера и осуществляет с ним обмен данными, фактически, становясь “посредником“ между клиентом и сервером.

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

        Напомним еще раз, что сертификат – это электронный документ, который позволяет проверить аутентичность его предъявителя (пользователя, сервиса, системы). Он обычно содержит публичный ключ владельца, сводную информацию (имя владельца, срок действия и т.д.) и данные о том, кто именно издал этот сертификат.

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

        Давайте рассмотрим на практическом примере, как выглядит сертификат при осуществлении прямого соединения и соединения через Proxy. Для этого воспользуемся браузером и замечательным Proxy-сервером с практически неограниченным функционалом — Burp Suite.

        Для начала, откроем какой-нибудь сайт по протоколу HTTPS и посмотрим на сертификат, который он нам отдаст. Допустим, мы переходим по адресу https://stingray-mobile.ru/ :

        Сертификат сайта при подключении напрямую

        Мы видим, что сертификат имеет три шага, подписан промежуточным центром сертификации R3 (в свою очередь, подписанным корневым центром сертификации ISRG Root X1), выдан сроком на один год для доменного имени stingray-mobile.ru . Вместе с сертификатом к нам доставлен открытый ключ и его отпечаток. Обычно здесь содержится много информации: кому выдан, кем выдан, различные мета-данные самого сертификата и организаций, принимавших участие в его выдаче, и многое другое. Корневой центр сертификации ISRG Root X1 находится в списке доверенных внутри наших операционных систем. Это значит, что сертификаты, выданные данной компанией, валидные, и им можно доверять.

        Теперь откроем наш прокси Burp Suite и пустим трафик от браузера через него. Вот что мы увидим:

        Сертификат сайта при подключении через Proxy

        Изменилось абсолютно всё. Корневой центр сертификации теперь некий “PortSwigger CA“, организация, выпустившая сертификат, теперь тоже “PortSwigger“, изменился открытый ключ. Неизменным осталось только имя сервера — stingray-mobile.ru . При этом, мы полностью увидим все данные, которые мы отправили на сервер и которые получили от него:

        Дамп трафика в открытом виде

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

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

        Другой, более интересный способ заставить пользователя поставить нужный сертификат — прибегнуть к помощи фейковых точек доступа и Captive-порталов. С такими порталами вы наверняка сталкивались при попытке использовать какую-либо публичную сеть. Когда мы нажимаем “подключиться“, открывается страничка с просьбой, например, ввести свой номер телефона и проверочный код из СМС, или посмотреть рекламу, или что угодно еще.

        Как злоумышленник может использовать это для своих целей? Возможен такой сценарий: создается публичная точка доступа с популярным именем, например, METRO_FREE или что-то подобное. Далее, формируется Captive-портал с предупреждением о том, что “мы очень заботимся о вашей безопасности и хотим, чтобы вы всегда оставались защищенными”, ну и так далее. А в конце выводится кнопка, при нажатии на которую на подключившееся устройство скачивается сертификат и запускается мастер установки (для этого в запрос надо включить несколько специальных заголовков). Вот, собственно, и все — сертификат на устройстве, установлен, можно смотреть и слушать трафик!

        Другой важный вопрос: как заставить пользователей подключиться к фейковой точке доступа? Здесь на помощь приходят сами устройства и их способ определения, к какой точке и как подключаться. Выбор сети для подключения внутри телефонов очень прост: точка доступа идентифицируется по SSID (имени сети) и паролю. То есть, телефон видит сеть со знакомым именем и пытается подключиться к ней с сохраненным паролем (если установлен флаг “автоматическое подключение“). Но, если точка открытая и пароля на ней нет, то ее идентификация происходит только по имени сети. Но что делать, если рядом — две точки с одинаковым именем? Здесь главное, что нужно злоумышленнику, — подключиться к той точке, у которой сигнал выше. Для этого он может сделать следующее: купить направленную антенну, какой-нибудь одноплатник вроде raspberry, настроить Captive-портал, пойти в публичное место с открытым Wi-Fi, назвать свою точку доступа аналогично и ловить подключения! И тогда трафик клиентов, установивших сертификат на свой телефон, станет доступен тому самому “человеку посередине“.

        Похоже на сценарий какого-то фильма, далекий от реальности? А вот и нет. Однажды на одной конференции по безопасности в конце второго дня на сцену позвали участника и вручили ему приз — футболку, на которой были напечатаны адрес его электронной почты и пароль от неё. А на другом мероприятии на экран выводились логины и пароли, которые были пойманы в трафике (конечно, на второй день это заметили, и на экране стали выводить всякие неприличные рисунки в ASCII, и этот аттракцион прикрыли).

        А вот и не про конференции. Недавно я обедал в достаточно большом ресторане и подключился к местному Wi-Fi. В ожидании заказа решил проверить, что у них там по адресу маршрутизатора. И каково же было мое удивление, когда перейдя по адресу 192.168.88.1 , я попал в открытую админку роутера Mikrotik. Погуляв по настройкам, выяснил, что на нем не только развернута публичная точка доступа, но и подключено некоторое важное оборудование. А сколько таких вот открытых админок, наверное, только Shodan’у одному известно…

        Так что подобные схемы — это вполне реальная история, и попасть под сниффинг трафика можно достаточно просто (особенно если вы любите посещать конференции).

        Защита канала связи, или SSL Pinning

        В качестве защиты мобильного приложения от подобных атак применяют механизм, который называется SSL Pinning. По поводу него всегда много споров (делать ли его, нужен ли он, как избежать “протухания“ сертификата в приложении и т.д.). Для начала, стоит понять, для чего вашему приложению нужен SSL Pinning. Как правило, есть три типа ответа на этот вопрос:

        1. Для защиты клиента, если он вдруг попал в недоверенную/скомпрометированную сеть, если кто-то пытается прослушать его трафик и т.д.
        2. Для того, чтобы нельзя было проанализировать backend и поискать ошибки, например, в бизнес-логике (классический Security through obscurity)
        3. Для того, чтобы быть уверенными, что запрос приходит от легитимного приложения или, другими словами, для защиты от ботов.

        На мой взгляд, SSL Pinning призван решать одну единственную задачу — защищать клиента. По поводу двух оставшихся пунктов скажу кратко. Да, SSL Pinning может косвенно повлиять на них. То есть поможет и закрыть ваш API, и защитить от ботов (в теории), но это не серебряная пуля, а лишь способ обезопасить ваших клиентов.

        Для того, чтобы избежать копирования ваших приложений и защититься от ботов, лучше всего использовать альтернативные варианты реализации, а не пиннинг. Так, можно применять подпись сообщений, то есть генерировать некоторую уникальную строку, которая бы зависела от состава передаваемой информации в запросе и могла бы высчитываться независимо на клиенте (для подписания) и на сервере (для проверки). Такая подпись сообщений является некоторым аналогом цифровой подписи. Нечто подобное было реализовано у Snapchat и очень долго никто не мог понять, как же генерируется этот токен для подписания. На эту тему вышло даже две статьи (часть первая и часть вторая), где можно попробовать подсмотреть кое-какие подходы. А можно воспользоваться готовыми сервисами, которые есть, например, у Cloudfare, или аналогичными. И тогда никто и ничто, кроме вашего приложения, не сможет подключиться к бэкенду.

        А теперь немного о том, что же собственно такое SSL Pinning, как он устроен и как его применять. Суть этого метода в том, чтобы на этапе SSL Handshake после второго шага, когда сервер присылает нам свой сертификат с открытым ключом, приложение проверяло, что определенные параметры этого сертификата совпадают с тем, что ожидает получить приложение (то есть, некоторые данные, которые “зашиты“ в приложении и которые мы ожидаем получить от своего сервера). Схематично это можно представить в виде небольшой схемы:

        Процесс SSL Pinning

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

        Типы SSL Pinning

        Certificate Pinning

        Первая реализация — это Certificate Pinning. Проверяется непосредственно сам сертификат, включая метаданные (кому он выдан, срок окончания, данные владельца и т.д.). Такая реализация наиболее безопасна, поскольку даже небольшое изменение в сертификате вызовет несоответствие и приведет к невозможности установить соединение.

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

        Public key Pinning

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

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

        Какие сертификаты возможно проверять

        1. Сертификат конечного сервера, с которым осуществляется соединение:
          1. Гарантирует с почти 100% уверенностью, что это ваш сертификат, даже если корневой центр был скомпрометирован;
          2. Если сертификат становится недействительным по какой-либо причине (либо по истечении срока действия, либо при компрометации), то осуществить соединение с сервером не получится, пока не выйдет обновление приложения;
          3. Позволяет использовать самоподписанные сертификаты, что может быть полезно при разработке.
          1. Проверяя промежуточный сертификат, вы доверяете промежуточному центру сертификации;
          2. Пока вы используете того же поставщика сертификатов, любые изменения сертификатов конечного сервера будут работать без обновления приложения.
          1. Проверка корневого сертификата означает, что вы доверяете корневому центру сертификации, а также любым посредникам, использующим данный центр сертификации;
          2. Если корневой сертификат скомпрометирован, то соединение нельзя считать защищенным, и необходимо срочно менять все сертификаты.
          1. Самая надежная проверка с точки зрения безопасности, поскольку проверяются все возможные изменения в любом из сертификатов;
          2. Это самая сложная проверка в поддержке, так как при изменении любого из сертификатов, участвующих в цепочке, необходимо обновлять приложение.

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

          Еще одна интересная техника защиты клиента, которую мы встречали в процессе анализа приложений — это перекладывание ответственности на сторону сервера. Во время работы приложения отправляется запрос с частью сертификата (или с полным сертификатом), который приложение получило на этапе SSL Handshake, и сервер сам определяет, его ли это сертификат. На основе ответа от сервера мобильное приложение показывает пользователю сообщение, что он находится в небезопасной сети. Конечно, такое решение не должно быть единственным, но в качестве дополнительной проверки может пригодиться.

          Еще хочется рассказать об интересном наблюдении из практики, нередко сертификат, с которым будет сравниваться отпечаток сервера, хранится в виде файла на файловой системе (в директории или ресурсах приложения). Мы автоматизировали поиск таких ключей/сертификатов, а после того, как собрали неплохой результат, прогнав через сканер несколько сотен приложений, захотелось посмотреть, а что еще хранят приложения, какие сертификаты или файлы ключей?

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

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

          Найденное хранилище ключей с приватными ключами

          Как проверять

          Android Network Security Config

          Для каждой из возможных библиотек будет своя собственная реализация. Для Android, например, существует встроенный механизм реализации Pinning на уровне системы, а именно конфигурация сетевого взаимодействия (XML-файл, в котором настраиваются параметры сетевой безопасности). Данная настройка задается специальным атрибутом android:networkSecurityConfig в AndroidManifest.xml.

          Network Security Config позволяет достаточно просто подключить механизм Certificate Pinning в приложение. Но при этом стоит учитывать определенные нюансы. Рассмотрим конфигурацию, которая с первого взгляда выглядит, как правильно настроенная, и разберем, как ее можно немного улучшить:

            example.com 7HIpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhJ3Y=   

          Этот пример имеет два небольших недостатка:

          1. Для отпечатка сертификата (pin-set) не установлен срок действия;
          2. Нет резервного сертификата.

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

          Чтобы избежать такой паузы, стоит добавить следующий сертификат в настройках “резервных сертификатов“.

          Вот пример наиболее корректного использования функционала Certificate Pinning:

            example.com 7HIpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhJ3Y= fwza0LRMXouZHRC8Ei+4PyuldPDcf3UKgO/04cDM1oE=   

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

          iOS App Transport Security

          Что касается iOS, то встроенный механизм проверок в AppTransport Security появился только начиная с iOS 14 и очень похож на то, что есть в Android:

          NSAppTransportSecurity NSPinnedDomains example.org NSIncludesSubdomains NSPinnedCAIdentities  SPKI-SHA256-BASE64 r/mIkG3eEpVdm+u/ko/cwxzOMo1bk4TyHIlByibiA5E=     

          В этом примере конфигурации мы указываем, что отпечаток открытого ключа связан с доменом example.org и его поддоменами, например test.example.org . Но вот поддомены третьего уровня и выше уже в эту проверку не попадают (например notinclude.test.example.org ).

          Как и в Android, можно сразу же указать несколько отпечатков, что может быть полезно при ротации сертификатов на сервере:

          NSAppTransportSecurity NSPinnedDomains example.net NSPinnedLeafIdentities  SPKI-SHA256-BASE64 i9HaIScvf6T/skE3/A7QOq5n5cTYs8UHNOEFCnkguSI=  SPKI-SHA256-BASE64 i9HaIScvf6T/skE3/A7QOq5n5cTYs8UHNOEFCnkguSI=     

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

          В нашем инструменте мы не только умеем выявлять отсутствие пиннинга, но и в обязательном порядке анализируем Network Security Config на предмет неправильной конфигурации и соответствия лучшим практикам безопасности:

          Пример найденной небезопасной конфигурации Network Security Config

          И, конечно, конфигурация App Transport Security не остается без внимания:

          Пример найденной небезопасной конфигурации App Transport Security

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

          OkHttp

          При реализации в OkHttp можно воспользоваться классом CertificatePinner.

          CertificatePinner certPinner = new CertificatePinner.Builder() .add("appmattus.com", "sha256/4hw5tz+scE+TW+mlai5YipDfFWn1dqvfLG+nU7tq1V8 https://medium.com/square-corner-blog/vulnerability-in-okhttps-certificate-pinner-2a7326ad073b#.kkns7f3jk">уязвимости, которая исправлена только в версии 2.7.5 и выше 3.2.0. Необходимо убедиться в том, что используемая версия библиотеки не подвержена данной уязвимости.

          Retrofit

          Retrofit применяется поверх OkHttp, поэтому его использование похоже на аналогичные операции с OkHttpClient, как показано в примере выше.

          Retrofit retrofit = new Retrofit.Builder() .baseUrl("https://appmattus.com") .addConverterFactory(GsonConverterFactory.create()) .client(okHttpClient) .build();
          HttpUrlConnection

          Если используется HttpUrlConnection , рекомендуется пересмотреть подход в сторону OkHttp. Версия HttpUrlConnection , встроенная в Android, зафиксирована, поэтому с обновлениями могут возникнуть сложности.

          В документе Android «Security with HTTPS and SSL» предлагаемая реализация основана на pinning сертификатов с помощью собственного TrustManager и SSLSocketFactory . Однако, как и в случае с другими API, в данной рекомендации будут примеры с использованием SPKI.

          private void validatePinning( X509TrustManagerExtensions trustManagerExt, HttpsURLConnection conn, Set validPins) throws SSLException < String certChainMsg = ""; try < MessageDigest md = MessageDigest.getInstance("SHA-256"); ListtrustedChain = trustedChain(trustManagerExt, conn); for (X509Certificate cert : trustedChain) < byte[] publicKey = cert.getPublicKey().getEncoded(); md.update(publicKey, 0, publicKey.length); String pin = Base64.encodeToString(md.digest(), Base64.NO_WRAP); certChainMsg += " sha256/" + pin + " : " + cert.getSubjectDN().toString() + "\n"; if (validPins.contains(pin)) < return; >> > catch (NoSuchAlgorithmException e) < throw new SSLException(e); >throw new SSLPeerUnverifiedException("Certificate pinning " + "failure\n Peer certificate chain:\n" + certChainMsg); > private List trustedChain( X509TrustManagerExtensions trustManagerExt, HttpsURLConnection conn) throws SSLException < Certificate[] serverCerts = conn.getServerCertificates(); X509Certificate[] untrustedCerts = Arrays.copyOf(serverCerts, serverCerts.length, X509Certificate[].class); String host = conn.getURL().getHost(); try < return trustManagerExt.checkServerTrusted(untrustedCerts, "RSA", host); >catch (CertificateException e) < throw new SSLException(e); >>

          Данная имплементация должна быть вызвана следующим образом:

          TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance( TrustManagerFactory.getDefaultAlgorithm()); trustManagerFactory.init((KeyStore) null); // Find first X509TrustManager in the TrustManagerFactory X509TrustManager x509TrustManager = null; for (TrustManager trustManager : trustManagerFactory.getTrustManagers()) < if (trustManager instanceof X509TrustManager) < x509TrustManager = (X509TrustManager) trustManager; break; >> X509TrustManagerExtensions trustManagerExt = new X509TrustManagerExtensions(x509TrustManager); . URL url = new URL("https://www.appmattus.com/"); HttpsURLConnection urlConnection = (HttpsURLConnection) url.openConnection(); urlConnection.connect(); Set validPins = Collections.singleton ("4hw5tz+scE+TW+mlai5YipDfFWn1dqvfLG+nU7tq1V8 anchor" name="Volley" >
          Volley

          Стандартный способ использования библиотеки Volley - это Pinning сертификатов, как описывается в статье «Android Security Tip: Public Key Pinning with Volley Library». Проект Github Public Key Pinning with Android Volley library показывает, как можно настраивать SSLSocketFactory для привязки к SPKI.

          Есть и альтернативный метод, в дополнение к перечисленным выше подходам. Он заключается в использовании класса HostnameVerifier, служащего для проверки того, что имя хоста в URL-адресе соответствует тому, что указано в сертификате.

          Переопределить HostnameVerifier можно следующим образом:

          RequestQueue requestQueue = Volley.newRequestQueue(appContext, new HurlStack() < @Override protected HttpURLConnection createConnection(URL url) throws IOException < HttpURLConnection connection = super.createConnection(url); if (connection instanceof HttpsURLConnection) < HostnameVerifier delegate = urlConnection.getHostnameVerifier(); HostnameVerifier pinningVerifier = new PinningHostnameVerifier(delegate); urlConnection.setHostnameVerifier(pinningVerifier); >return connection; > >); . public static class PinningHostnameVerifier implements HostnameVerifier < private final HostnameVerifier delegate; private PinningHostnameVerifier(HostnameVerifier delegate) < this.delegate = delegate; >@Override public boolean verify(String host, SSLSession sslSession) < if (delegate.verify(host, sslSession)) < try < validatePinning(sslSession.getPeerCertificates(), host, validPins); return true; >catch (SSLException e) < throw new RuntimeException(e); >> return false; > >

          Но не стоит забывать, что SSL Pinning - это не единственное, что может помочь в защите сетевого соединения. Другим немаловажным фактором является создание правильного протокола общения приложения с сервером, например, запрет на общение в открытом виде по HTTP или запрет на передачу чувствительной информации в параметрах GET-запросов. О последней проблеме хотелось бы поговорить чуть более подробно.

          В случае, если чувствительная информация передается в URL-адресах, она может регистрироваться в самых разных местах, включая:

          • Web-сервер;
          • Любые прямые или обратные прокси-серверы между двумя конечными точками;
          • Заголовок Referrer;
          • Логи Web-сервера;
          • История браузера;
          • Кэш браузера.

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

          Найденный пароль, передаваемый в параметрах GET-запроса

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

          Обнаружение уязвимостей отсутствия или некорректной реализации SSL Pinning

          К сожалению, во многих приложениях, которые мы проверяем ежедневно, не реализован SSL Pinning. И это достаточно грустно, учитывая, что для его реализации не нужно так много усилий, как может показаться. А его реализация поможет обеспечить защиту ваших клиентов.

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

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

          Заключение

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

          Реализовывать ли в приложении защиту сетевого соединения? Ответ не для всех разработчиков очевиден. Некоторых останавливает боязнь “протухания“ сертификатов, других - нехватка времени. На мой взгляд, это одна из первых вещей, которые необходимо запланировать к реализации для защиты ваших клиентов. Подумайте о них и не бойтесь реализовывать пиннинг. Даже ситуацию с “протуханием” сертификата можно попробовать обойти различными способами. В конце концов, есть и специальные продукты и решения, которые помогают в настройках, поиске сертификатов и корректности реализации сетевого взаимодействия. Буду рад помочь, если возникнут вопросы по теме!

          Ссылки

          1. Простым языком об HTTP
          2. Network security configuration
          3. A Security Analyst’s Guide to Network Security Configuration in Android P
          4. https://github.com/square/okhttp/wiki/HTTPS#certificate-pinning
          5. Vulnerability in OkHttp’s Certificate Pinner
          6. Picasso 2 OkHttp 3 Downloader
          7. Pinning
          8. Android Security Tip: Public Key Pinning with Volley Library
          9. Public Key Pinning with Android Volley library
          10. Preventing Downgrade Attacks
          11. Identity Pinning: How to configure server certificates for your app
          12. https://habr.com/ru/company/swordfish_security/blog/661345/
          13. HTTP/3
          • безопасность
          • безопасность мобильных приложений
          • mitm
          • ssl
          • tls
          • ssl pinning
          • perfect forward secrecy

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *