Как воруют данные в iOS-приложениях и как этому помешать

Из года в год iOS обходит своего главного соперника на рынке операционных систем, Android, по степени безопасности. Под безопасностью мы имеем в виду то, насколько сложно посторонним людям получить доступ к данным пользователя мобильного устройства. Основная причина устойчивости к атакам системы iOS по сравнению с детищем Энди Рубина — это закрытые код и экосистема и дотошная проверка как программной начинки, так и устройств. А Android со своей идеей опенсорса, тысячами моделей устройств от десятков производителей и актуальными версиями ОС (шестью против трёх на iOS), которые невозможно покрыть единой защитой, остаётся удобной мишенью для мошенников.

Стало быть, iOS безопаснее Android? Взглянем на свежие данные от cvedetails.com о количестве когда-либо найденных уязвимостей у 50 самых популярных операционных систем, браузеров и других продуктов по состоянию на 11 марта 2019 года:

Android — 2146 уязвимостей, 3 место;

iOS — 1514 уязвимостей, 7 место.

Итак, iOS входит в десятку самых уязвимых цифровых продуктов. В сентябре 2017 года Евгений Зобнин, редактор рубрик Unixoid и Mobile в журнале Хакер, уже указывал на минимальный разрыв в количестве уязвимостей у двух систем. Если кратко, то проблема, по его словам, не в самом Android, а в устройствах, которые на нём работают. Выборка из 100 уязвимостей, сделанная Евгением, показывает, что на код ОС приходится чуть меньше трети уязвимостей, а основную опасность несут драйверы процессора Qualcomm (по большей части) и других модулей и компонентов.

…о багах iOS быстро забывают, они просто перестают быть актуальными из-за обновления всех устройств до новой версии ОС. А вот о багах Android помнят долго, ведь уязвимости даже двух- и трёхлетней давности остаются актуальными для миллионов устройств.

Если говорить об уязвимостях, iOS определенно не самая защищенная ОС, а Android не самая дырявая. А вот среднестатистический смартфон на Android — это решето. Все эти модификации, добавленные производителем, баги в фирменных загрузчиках, вечные проблемы с обновлениями — все это сводит на нет старания Google сделать Android безопаснее.

Евгений Зобнин

Но оставим упомянутые 1495 уязвимостей iOS на совести Apple. Мы в Лайв Тайпинг создаём приложения для их устройств и должны сделать всё, что от нас зависит, чтобы личным данным пользователей вашего приложения вместе с вашей и нашей репутацией ничего не угрожало. Как мы это делаем, мы расскажем ниже.

Какие данные считаются личными и не должны попадать третьим лицам

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

Итак, к личным данным относятся:

• токен, с помощью которого делаются запросы к API;
• номер кредитной карты;
• имя и фамилия;
• номер телефона;
• имейл;
• пароль.

Где же хранятся данные и в каком виде?

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

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

Токен хранится в Keychain (в переводе с английского — «связка ключей»). Это зашифрованная база данных для хранения метаданных и конфиденциальной информации от Apple.

Некоторые нюансы разработки

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

В качестве примера мы приведём обработку данных с помощью функции passwordHash:

Эта функция принимает адрес электронной почты и пароль и возвращает хешированную строку. «Соль» — это уникальная строка, которая передаётся хеш-функции вместе с паролем. sha256 () — это метод CryptoSwift, который применяет хеш-код SHA-2 на входной строке.

Таким образом, злоумышленник, скомпрометировавший Keychain, найдет этот хеш. Он может создать таблицу часто используемых паролей и их хешей для сравнения с этим хешем. Если бы пароль пользователя хешировали без «соли», и он существовал в хеш-таблице злоумышленников, то он был бы скомпрометирован.

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

Для взаимодействия с сервером приложение и сервер будут использовать одну «соль». Это позволяет им строить хеши одинаковым образом и сравнивать два хеша для проверки личности.

Взаимодействие приложения напрямую с Keychain осложняется, особенно в Swift. Нужно использовать Apple Security Framework, который преимущественно написан на языке C. К счастью можно избежать использования низкоуровневого API, заимствуя Swift оболочку GenericKeychain от Apple.

Ответственность мобильного разработчика за безопасность данных в том, чтобы все нужные данные хранились в Keychain.

Типы уязвимостей

Третье лицо может получить доступ к данным:

• в момент их передачи;
• подсмотрев или просто зная Apple ID и, соответственно, Keychain. Такая возможность стала реальной благодаря уязвимости, обнаруженной в октябре 2017 года разработчиком Феликсом Краузе. 30 строк кода в приложении воссоздают системное всплывающее окно, запрашивающее Apple ID. Чтобы проверить, запрашивается ли Apple ID системой или приложением, Краузе посоветовал свернуть приложение, и если вместе с ним свернётся и окно, то оно явно преследует нехорошие цели;
• зайдя в Developer Center и iTunes Connect через Apple ID. Но двухфакторная аутентификация требует вводить пароль от Apple ID и четырёхзначный код, что затрудняет несанкционированный доступ к этим службам. Даже получив доступ, злоумышленник сможет управлять приложением (выставлять цены, удалить), а не самими данными.

Атака Man-in-the-middle (MITM)

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

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

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

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

Атака происходит по одной из четырёх техник:

• добавление сертификата в хранилище пользовательских сертификатов в приложении. Это эксплоит (вредоносный код, экспулатирующий уязвимость), когда атакующий внедряет в приложение пользователя сертификат и может встать в зашифрованный канал и воровать данные;
• модификация, когда сертификат вшивается в само приложение. Это можно сделать даже не на стадии разработки, а когда приложение заражено.
• Обход SSL pinning. Все современные приложения используют SSL pinning как панацею от MITM. Смысл в том, что сертификат напрямую вшивается в код, а не хранится в телефоне, где его можно подменить, и обфусцируется, то есть видоизменяется до неузнаваемости. Сертификат сохраненяет работоспособность, но становится недоступным для злоумышленника, даже если тот сделает реверс-инжиниринг. Но SSL pinning можно обойти, если подключиться напрямую к работающему приложению на телефоне, которое хранится в оперативной памяти;
• реверс-инжиниринг приложения и изучение алгоритма верификации сертификата. Бывает так, что механизм проверки сертификата в приложении кастомный или использует какие-то библиотеки. Реверс-инжиниринг помогает изучить исходный код и понять, как библиотека валидирует сертификат, найти уязвимости в валидации и проэксплуатировать их.

Реверс-инжиниринг проводится в две стадии:

1. злоумышленник скачивает приложение, как обычный пользователь, «ревёрсит», находит уязвимости и воспроизводит их на своём устройстве
2. злоумышленник пишет эксплоит и доставляет этот эксплоит в устройство: через вирусы, вредоносные ссылки, скачивания и т. д.

Методы, препятствующие реверс-инжинирингу приложений, описаны в статье «Эффективный способ защиты от пиратства». Несмотря на то, что ей почти семь лет, она рассказывает о фундаментальных и неустаревающих вещах.

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

Как предотвращать перехваты

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

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

• токен, который получает приложение в момент авторизации пользователя;
• зашифрованное соединение на стороне сервера (SSL-сертификат);
• HTTPS-протокол. В HTTPS-канале используется протокол TLS. Разработчики сами не занимаются шифрованием, они просто настраивают HTTPS, а остальную магию делает протокол.

Казалось бы, SSL-сертификат и HTPPS-протокол стали стандартом-де-факто. Но в мае 2018 года дочерняя компания «Ростелекома» Solar Security, создающая продукты и сервисы для защиты информационной безопасности, нашла уязвимости в 16 мобильных приложениях для каршеринга. Причинами возможного похищения аккаунтов и утечки пользовательских данных представители компании назвали слабые алгоритмы хеширования, небезопасную реализацию SSL и использование незащищённого протокола передачи данных HTTP.

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

Touch ID и Face ID

Идентификация по отпечатку пальца и лицу соответственно. Apple утверждает, что возможность совпадения отпечатков пальцев — 1:50000, а параметров лица — 1:1000000. Такая низкая статистика совпадений дополняется ещё и тем, что биометрические данные не хранятся на устройстве в чистом виде — они преобразуются в математическую модель, не поддающуюся расшифровке.

Пароли и отпечатки (вернее, их математические представления) находятся под защитой системы Secure Enclave, и только она имеет к ней доступ. Secure Enclave изолирована от iOS, поэтому данные не будут использованы операционной системой и программами, не попадут на сервера Apple или в хранилище iCloud. В этом владельцев айфонов заверяет официальное описание технологии.

В августе 2017 года, когда iOS 11 находилась на стадии бета-тестирования, специалист по информационной безопасности под псевдонимом xerub опубликовал ключ для дешифровки прошивки сопроцессора Secure Enclave Processor. С помощью этого ключа можно получить доступ к коду ПО, под управлением которого работает система Secure Enclave, но сама система остаётся недоступной. Специалист надеется на то, что обнаруженная уязвимость поспособствует усилению безопасности сопроцессора.

Face ID можно протестировать и проверить только на физическом устройстве. Работу Touch ID можно воссоздать в симуляторе xCode, начиная с девятой версии.

Для идентификации пользователя с помощью Face ID и Touch ID используется Local Authentication framework.

Ещё один нюанс разработки

Импортируем Local Authentication framework:

Создаём новый класс:

Теперь нам понадобится ссылка на LAContext (контекст). Контекст ссылается на контекст аутентификации, который является «представителем» Local Authentication framework.

Также нам понадобится функция, которая поможет узнать, доступен ли биометрический идентификатор на устройстве пользователя:

Затем добавляем функцию, которая произведет идентификацию пользователя, либо же вернет ошибку идентификации:

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

Защита имени и фамилии

В iOS есть два элемента, позволяющие вводить данные: textfield и textview. Чаще всего для ввода пароля, имени и фамилии используется textfield. Он настраивается с помощью некоторых методов: для пароля необходимо выставлять параметр Secure Entry, чтобы перекрывать пароль точками; если важны имя и фамилия, то можно отключить автокоррекцию (отключить поле autocorrectiontype) и система не будет их запоминать и индексириовать.

Размывание экрана приложения при сворачивании

Метод необходим для приложений, которые содержат личные данные пользователей и которые можно тайком подсмотреть. Частный случай — банковские приложения.

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

Итоги

Чтобы данные пользователей вашего приложения оставались в безопасности, мы:

• храним данные в Keychain;
• обрабатываем все разрешения на доступ к контактам, фото и т. п.;
• прописываем адрес сервера, к которому нужно обращаться через HTTPS-протокол;
• настраиваем доступ через Touch ID, Face ID и через код-пароль, хранящийся в Keychain, если палец не считывается;
• предусматриваем безопасный ввод данных через textfield и textview и обрабатываем его по правилам (вводим закрытым без посторонних символов)
• размываем экран с личными данными при сворачивании приложения;
• выкатываем регулярные обновления.

Обновления, касающиеся безопасности, выкатываются в нескольких случаях:

• в приложении обнаружена ошибка, касающаяся безопасности системы;
• если меняется законодательство стран, в которых пользуются приложением;
• если Apple выпускает обновление, затрагивающее политику безопасности приложения.