что такое ssl pinning в вк

22.12.202322.09.2023 admin 0 Comments

Безопасность IOS-приложений (часть 36) – Обход certificate pinning при помощи SSL Kill Switch

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

Автор: Prateek Gianchandani

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

По умолчанию при инициации SSL-соединения клиент проверяет, что сертификат сервера:

Хотя, клиент не проверяет, является ли текущий сертификат именно тем, который использует сервер.

Проверка на соответствие между сертификатами на устройстве и на удаленном сервере потенциально является брешью в системе безопасности. Все дело в том, что хранилище сертификатов на устройстве может быть легко скомпрометировано; пользователь может установить небезопасные сертификаты, тем самым ставя себя под угрозу стать жертвой атак типа «человек посередине» (man—in—the—middle attacks). Технология certificate pinning позволяет решить эту проблему. Суть метода заключается в том, что сертификат, соответствующий тому, который использует сервер, жестко зашивается в мобильное приложение. Во время инициации SSL-соединения мобильное приложение игнорирует хранилище на устройстве и соединяется только с теми хостами, сертификат у которых соответствует сертификату, зашитому в приложении. Сия технология также помогает нам сделать хост достоверным при помощи самоподписанного сертификат и не устанавливать дополнительные сертификаты на устройстве.

Технология certificate pinning используется многими популярными приложениями: Twitter, Square и т. д. Вопрос заключается в том, как обойти проверку сертификата на стороне клиента? Важно отметить, что все проверки происходят на стороне клиента, и мы можем, используя различные фреймворки (Mobile Substrate и другие), патчить методы и обходить эти проверки.

На конференции Blackhat была представлена экспериментальная утилита SSL Kill Switch, которая позволяет обходить проверку сертификатов. С полной версией презентации можно ознакомиться здесь. Спустя некоторое время у автора получилось отследить трафик приложений, использующих технологию certificate pinning (например, Twitter), но возникли сложности с отслеживанием трафика у приложения App Store. Далее автор пришел к выводу, что для отслеживания трафика у приложения App Store, необходимо пропатчить более низкоуровневые методы и завершить некоторые процессы. На эту тему была написана довольно интересная статья, с которой я рекомендую вам ознакомиться. Кроме того, обратите внимание, что SSL Kill Switch будет способна отключить стандартную проверку SSL-сертификатов, и вам не нужно будет устанавливать корневой достоверный сертификат, что мы обычно делаем для анализа трафика через протоколы HTTP/HTTPS.

Чтобы проверить, что приложение Twitter использует технологию certificate pinning, установите эту программу и направьте весь трафик с устройства через Burp Proxy. Более подробно об инспектировании трафика через HTTP/HTTPS описано в 11-й статье этого цикла. Если вы поработаете с приложением Twitter, трафик не будет перехватываться Burpsuite.

Чтобы проанализировать трафик приложения Twitter, подключитесь к устройству через ssh и загрузите приложение iOS SSL Kill Switch. Кроме того, установите следующие приложения через Cydia:

Устанавливаем deb-пакет при помощи команды dpkg —i.

Рисунок 1: Установка приложения SSL Kill Switch

После установки сделайте респринг устройства при помощи команды killall —HUP SpringBoard.

Далее зайдите в настройки SSL Kill Switch и включите опцию Disable certificate validation.

Рисунок 2: Отключение проверки сертификата

Теперь трафик приложения Twitter будет проходить через Burp Proxy.

Рисунок 3: Лог Burp Proxy

Рисунок 4: Полный лог устройства

Источник

Универсальный перехват. Как обойти SSLPinning раз и навсегда и читать трафик любого приложения

Содержание статьи

Немного об HTTP и о том, при чем здесь OpenSSL

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

За время своего существования HTTP оброс кучей разных фич и наворотов, устраняющих недостатки его изначальной «вебовой» версии: Cookies для устранения Stateless, Keep-Alive и Long polling для имитации непрерывности соединения, концепция REST, бинарный HTTP/2 с повсеместным сжатием и многое другое. Забегая вперед, отмечу, что HTTP/2 вообще разрабатывался с учетом использования вместе с TLS 1.2+.

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

Параллельно с HTTP шло развитие SSL, а их синтез — HTTPS — постепенно захватывал долю трафика в мировом интернете, пока в один прекрасный момент в конце января 2017 года не превысил половину. Сейчас его доля стремится к 80%. Многие увидели смысл в шифровании данных, а тех, кто не успел, стали поторапливать в том числе и разработчики браузеров. В итоге все снова приняли это (что хорошо!) и начали повсеместно применять в своих приложениях, многие из которых и так уже работали по привычному HTTP.

В Mozilla публикуют статистику на основе телеметрии Firefox, где видно, какой процент веб-страниц загружают по HTTPS. На сайте LetsEncrypt можно посмотреть графики, основанные на этих данных.

Развитие SSL, а впоследствии и TLS (SSL 3.0+) во многом определялось развитием опенсорсного проекта OpenSSL. Он медленно, но верно впитывал в себя все новые и новые спецификации RFC. Как известно, велосипеды изобретать никто не любит, поэтому библиотека OpenSSL стала де-факто стандартом при имплементации защищенного транспорта для HTTP, и теперь ее следы можно обнаружить в бессчетном количестве софтверных проектов.

Как работает классический HTTPS

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

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

Для проверки используются центры сертификации, которые бывают корневыми и промежуточными. Публичных корневых центров мало, и обо всех них знает каждый клиент SSL/TLS. А промежуточных центров может быть очень много — единственное их отличие от корневых в том, что выпускаемые ими сертификаты подписываются приватным ключом вышестоящего CA. Например, если посмотреть на путь сертификации google.com на рисунке ниже, то корневым будет сертификат, выданный GlobalSign, а промежуточным — Google Internet Authority.

Цепочка сертификатов Google

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

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

Исследуем принципы работы OpenSSL на подопытном приложении

Библиотека OpenSSL «в вакууме» по умолчанию не доверяет никому, а чтобы инициировать процесс появления этого доверия, библиотеке необходимо сообщить о том, кому, собственно, мы намерены доверять. Если рассмотреть пример классического клиента TLS, приведенный в wiki.openssl, то можно там заметить загрузку доверенных сертификатов непосредственно перед осуществлением запроса HTTP:

Кроме функции SSL_CTX_load_verify_locations существует еще несколько похожих способов загрузки проверенных сертификатов внутрь OpenSSL. Наверняка разработчики, которые писали свои клиенты TLS, не стеснялись подсматривать подобные общедоступные примеры.

Попробуем отследить поведение представленного классического клиента TLS на каком-нибудь реальном приложении. Для начала возьмем что-нибудь простое, что могло бы быть связано с TLS, — например, библиотеку OkHttp. Она обеспечивает коммуникации по HTTP/S в бесчисленном количестве современных приложений для Android.

Заранее замечу, что OkHttp написана на Java и работает на JVM, поэтому сама по себе она не интересна, так как является своеобразной оберткой более интересной составляющей — низкоуровневой имплементации OpenSSL для Android. Вот ей-то мы и займемся.

Готовим тестовое приложение

Для начала исследования нужно обзавестись приложением, которое использует логику OkHttp для безопасных запросов. Проще всего его создать с нуля, взяв за основу эталонные примеры кода из интернета. Так же, как это делают сотни и тысячи других разработчиков. 🙂

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

UI подопытного приложения для Android

Совершенно стандартный код, кочующий по Ctrl-C и Ctrl-V из одного проекта в другой, подвергаясь при этом несущественным изменениям. Итак, запускаем новоиспеченное приложение и сразу же заглядываем в разметку его памяти.

Ищем следы OpenSSL в приложениях для Android

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Источник

Все, что необходимо знать о технологии HTTP Public Key Pinning (HPKP)

В ближайшие несколько лет технология привязывания ключей (key pinning) будет главной надеждой в системе безопасности протокола TLS, делая целевые атаки, связанные с Центрами Сертификации, намного более рискованными. Пока мы ждем появления новых систем с встроенным привязыванием ключей, уже сейчас можно воспользоваться технологией HTTP Public Key Pinning (HPKP), позволяющей выполнять привязывание ключей «на коленке».

Главный компонент в протоколе шифрования – идентификация оппонента, а вовсе не сам алгоритм. Даже самое стойкое шифрование бесполезно, если вы общаетесь не с тем, с кем намеревались. В протоколах SSL/TLS идентификация реализована на базе цепочки сертификатов, представляющих собой серию сертификатов стандарта X.509 с публичными ключами. Ваш браузер доверяет набору корневых сертификатов, принадлежащих Центрам Сертификации. Эти центры в свою очередь передают сертификаты веб-сайтам, которые вы посещаете. Когда, например, вы заходите на сайт rlove.org, ваш браузер проверяет цепочку сертификатов, начиная с того, которым владеет сайт rlove.org и далее по цепочке до корневого сертификата. Если ваш браузер доверяет корневому сертификату, вы точно знаете, что общаетесь со мной, а не со злоумышленником.

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

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

Привязывание публичных ключей

Технология HTTP Public Key Pinning (HPKP) является наброском IETF-стандарта, реализующего механизм прикрепления публичных ключей через HTTP-заголовок, который заставляет браузеры затребовать сертификат из белого списка для всех последующих соединений с конкретным веб-сайтом. Этот метод серьезно сокращает вероятность осуществления успешной MITM-атаки. Вместо любого корневого сертификата, мы запрашиваем конкретный корневой и промежуточный сертификат или даже точный публичный ключ.

Заголовок, используемый в технологии HPKP, выглядит так:

Public-Key-Pins: pin-sha256=»XXX»; pin-sha256=»YYY»; max-age=ZZZ

где XXX – SHA256-хеш публичного ключа, закодированный в base64, для сертификата из белого списка; YYY – резервная копия того же самого ключа; ZZZ – время жизни (в секундах) для белого списка. Заголовок также может содержать директиву includeSubdomains, предписывающую браузерам применять белый список ко всем хостам данного домена. Директива report-uri предписывает браузерам отправлять отчеты о проверках привязки, завершившихся неудачно.

Вы можете указать столько директив pin-sha256, сколько захотите. В цепочке сертификатов должна быть только одна сигнатура (fingerprint). Кроме того, необходимо указать как минимум одну сигнатуру, которая не входит в текущую цепочку. Другими словами, стандарт предписывает иметь резервную копию привязанного ключа.

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

Генерирование SPKI Fingerprint

Технология HPKP требует SHA256-хеш публичного ключа, закодированный в base64, который вы хотите привязать. Вы можете легко получить ключ либо при помощи запроса на получение сертификата (certificate signing request; CSR), либо из сертификата на базе стандарта X.509. Вам нужен только один ключ.

Генерируем содержимое для директивы pin-sha256 на базе публичного ключа (pub.key):

Генерируем на базе CSR (my.csr):

Генерируем на базе сертификата, закодированного в формате PEM (certificate.pem):

После выполнения команд, показанных выше, получите нечто подобное:

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

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

Установите значение параметра max-age в несколько минут и постепенно увеличивайте до тех пор, пока не добьетесь удовлетворительных результатов.

Используйте заголовок Public-Key-Pins-Report-Only для генерации и отправки отчетов о неудачах на адрес, содержащийся в параметре report-uri, без принудительного привязывания.

Пробуйте различные привязки от разных Центров Сертификации.

При использовании технологии HPKP не требуется специальной поддержки HTTP-сервера; нужно лишь добавить новый заголовок. Настройка для Apache:

Header set Public-Key-Pins «pin-sha256=\»XXX\»; pin-sha256=\»YYY\»; max-age=ZZZ»

Настройка для Nginx:

add_header Public-Key-Pins ‘pin-sha256=»XXX»; pin-sha256=»YYY»; max-age=ZZZ’;

Более общую информацию о конфигурировании протоколов SSL/TLS для Apache и Nginx можно почерпнуть в других моих статьях (ссылка 1, ссылка 2).

Верификация привязанных ключей

Отчет о неудачных проверках

В спецификации заложен механизм отправки отчетов при неудачной проверке ключа. Отчеты отправляются по адресу, указанному в директиве report-uri. Эта возможность полезна не только на этапе отладки, но и при детектировании MITM-атак против ваших пользователей. На самом деле, только само присутствие этой возможности делает технологию Public Key Pinning устойчивой к MITM-атакам.

Отчеты отправляются через HTTP POST следующего JSON-сообщения:

Технология HPKP поддерживается браузерами Chrome 38, Firefox 35 (и более поздних версиях).

Хотя у технологии HPKP есть несколько недостатков, в целом я рекомендую ее к использованию. Самая главная уязвимость заключается в том, что HPKP – это механизм вида trust-on-first-use (доверие при первом использовании). Иными словами, пользователь не сможет узнать о MITM-атаке при первом подключении к сайту. С другой стороны, для повторной MITM-атаки злоумышленнику нужно перехватить все соединения к веб-сайту. Учитывая характер сегодняшних угроз, технология HPKP является вполне приемлемой защитой. Примечательно, что злоумышленник перед тем, как осуществить MITM-атаку, обязан знать, хранятся ли на целевой машине привязанные ключи. Иначе в браузере пользователя появится грозное предупреждение (и, возможно, отправится отчет администратору сайта) об ошибке при верификации.

Источник