Введение
В первой части этой серии, посвященной атакам с использованием глубоких ссылок в iOS, мы рассмотрим, как распознавать различные типы схем глубоких ссылок, используемых в приложениях для iOS, и выявлять связанные с ними потенциальные уязвимости. В этой части основное внимание будет уделено описанию различных типов схем и объяснению методов их идентификации.
Что Такое Глубокая Ссылка?
Глубокая ссылка в мобильном приложении похожа на специальную ссылку, которая ведет вас непосредственно к определенной части мобильного приложения, а не к веб-сайту. Это означает, что вы можете легко переключаться между приложениями или переходить с веб-сайта в приложение, не нажимая много кнопок. Это позволяет быстрее и проще находить то, что вы ищете в приложении. Просто нажимая на определенные ссылки, т. е. URI (унифицированные идентификаторы ресурсов), пользователи могут беспрепятственно переходить из Safari, Mail, Notes или других приложений для доступа к содержимому вашего приложения.
Существуют различные виды уязвимостей, которые можно найти в Deep link, которые обсуждаются ниже. Чтобы идентифицировать и использовать такие уязвимости, нам сначала нужно понять различные типы схем Deep Links. Давайте сначала пройдемся по ним.
Глубокая Ссылка IOS
В основном для iOS-приложений доступно два типа Deep Link.
URL-схема
Схемы URL-адресов — это способ определить собственный протокол или схему для обработки URL-адресов в вашем приложении. Создав уникальную схему URL-адресов, например 8ksec://, вы можете указать настраиваемое действие, которое будет выполняться, когда пользователь щелкнет ссылку с этой схемой. Например, 8ksec://profile можно использовать для открытия страницы профиля в вашем приложении.
Чтобы указанный выше URI распознавался iOS как ссылка на контент, он должен соответствовать формату схемы URL: схема://ресурс . Поэтому, чтобы эта ссылка работала, вам нужно настроить такие URI, как 8ksec://profile. Как только это будет сделано и ссылка будет нажата, iOS распознает ее как действительную ссылку и предложит пользователю всплывающее окно с запросом разрешения на открытие приложения 8ksec. Схемы URL-адресов также поддерживают параметр запроса, например, если приложение имеет функциональность для перехода к конкретному пользователю, тогда его можно настроить на глубинной ссылке как 8ksec://profile?userID=1337, отформатировав его как схема://ресурс?параметр=значение.
Взяв пример DViA, который является чертовски уязвимым iOS-приложением, мы можем изучить конфигурацию Deep Link, как показано ниже.
Универсальные Ссылки
Универсальные ссылки выглядят как обычные URL-адреса, единственная разница между ними и обычным URL-адресом заключается в том, что универсальные ссылки настраиваются внутри приложения и используются для перехода к определенным компонентам приложения. Предположим, у вас есть приложение 8ksec с универсальной ссылкой, настроенной для URL-адреса https://8ksec.io. Если пользователь нажмет на эту ссылку и на его устройстве установлено приложение 8ksec, ссылка откроет приложение напрямую. Если у пользователя не установлено приложение, вместо этого ссылка откроется в Safari.
В случае универсальных ссылок, когда пользователь устанавливает приложение iOS, система проверяет манифест приложения, чтобы определить связанные с ним домены, в частности домены, начинающиеся с 8ksec, что указывает на то, что домен предназначен для прямых ссылок. Затем система получает доступ к пути /.well-known/apple-app-site-association для каждого соответствующего домена. Этот путь должен содержать предоставленный вами файл JSON, в котором указаны допустимые пути прямых ссылок для этого домена.
Универсальные ссылки были введены в iOS для решения проблем, возникающих со схемами URL. Схемы URL позволяли любому приложению использовать одну и ту же ссылку на контент, даже если она принадлежала другому приложению, что приводило к путанице и потенциальным проблемам безопасности, таким как фишинг. Например, если приложение Reddit имеет URL-схему reddit://, другие приложения могут использовать ту же схему, что приводит к двусмысленности. Однако универсальные ссылки используют ссылки на приложения или URI глубокой ссылки, такие как https://reddit.com , которые должны быть определены в домене приложения в ассоциации сайтов приложений, например https://www.reddit.com/.well-known/apple-app-site-association. App Site Association — это функция iOS, которая позволяет вашему приложению обрабатывать входящие ссылки на контент, связанные с вашим веб-сайтом.
Теперь, когда у нас есть четкое представление о различных типах Deep Links в iOS, мы можем изучить различные векторы атак на iOS Deep Links и продемонстрировать их технически. Чтобы определить уязвимости в Deep Link, мы должны сначала определить схемы Deep Link в приложении iOS. Итак, приступим.
Идентификация Deep Link: Схемы URL
Чтобы идентифицировать схемы Deep Link, первым шагом является извлечение незашифрованного iPA с устройства iOS, что может быть достигнуто с помощью следующих инструментов:
- Unc0ver : приложение для джейлбрейка iOS
- Cydia : используется для установки пакетов на устройство.
- FridaiOSDump : выгружает незашифрованный файл iPA из iOS.
Давайте возьмем пример DVIA-v2 и определим на нем схемы Deep Link. – Загрузите DVIA-v2-swift.ipa отсюда .
Переименуйте файл iPA и разархивируйте его.
Там будет папка с названием Payload. Папка «Полезная нагрузка» в iOS — это каталог, который создается, когда приложение компилируется для распространения через App Store или специальное распространение. Эта папка содержит пакеты, документы, каталог библиотеки и файл plist, содержащий информацию о конфигурации приложения.
Когда в приложении настроена глубокая ссылка, она сохраняется в файле Info.plist, который находится в каталоге Payload. Файл списка свойств (plist) — это тип файла в iOS, в котором хранятся пары «ключ-значение», представляющие различные типы данных конфигурации приложения, включая настройки, предпочтения и информацию о приложении. Файлы Plist могут содержать различные типы информации, такие как настройки приложения, пользовательские настройки и метаданные, что делает их полезным инструментом для управления и хранения данных конфигурации для приложений iOS.
Перейдите в каталог Payload. Там будет еще один подкаталог, сформированный как имя приложения с именем DVIA-v2.app .
Перейдите в DVIA-v2.app и загрузите в список только файлы plist.
Файл Info.plist — это структурированный документ, написанный в формате XML, который содержит пары ключ-значение, представляющие различные атрибуты приложения. Изменяя значения этих ключей, разработчики могут настраивать различные аспекты приложения, такие как его имя и номер версии. - Если мы попытаемся открыть файл plist с помощью обычного текстового редактора или команды cat, мы увидим только закодированные данные, которые выглядят как тарабарщина, как показано на изображении ниже.
Нам нужно изменить формат на XML, используя plutil
И мы можем просмотреть файл plist и определить схемы глубоких ссылок.
Прежде чем определить схемы, давайте сначала разберемся в их структуре. Есть такие компоненты
CFBBundleURLComponents , CFBundleComponentPath и CFBunndleURLComponentQueryItems , отвечающие за содержание и обработку схем прямых ссылок в файле Info.plist. Ключ CFBundleURLComponents используется для определения компонентов схемы URL. Ключ CFBundleURLComponentPath используется для указания пути URL-адреса, а ключ CFBundleURLComponentQueryItems используется для определения любых параметров запроса, которые должны быть включены в URL-адрес. Мы можем увидеть пример ниже.
Давайте изучим файл Info.plist DVIA. Мы уже преобразовали plist в XML с помощью plutil.
Мы можем видеть, что компонент CFBundleURLSchemes содержит два значения dvia и dviaswift , что делает наши схемы глубоких ссылок как dvia:// и dviaswift://
Кроме того, давайте определим схемы глубоких ссылок в другом тестовом приложении под названием OVIA . – Клонируйте репозиторий и создайте iPA из Xcode.
Переименуйте и разархивируйте файл iPA.
Перейдите в каталог Payload и конвертируйте
Откройте файл Info.plist, чтобы определить схемы.
Здесь, в этом приложении, мы видим, что компонент CFBundleURLSchemes содержит одно значение ovia , которое делает наши схемы глубоких ссылок как ovia://
Мы также можем использовать некоторые инструменты, такие как GrapeFruit, для определения схем глубоких ссылок, как показано на изображении ниже. Однако возможности GrapheFruit выходят за рамки этого блога.
Идентификация Deep Link: Универсальные Ссылки
В случае универсальных ссылок они расположены в .entitlements, и каждый домен будет начинаться с ссылок на приложения: и, имея полный доступ к исходному коду приложения, мы можем либо перейти на вкладку «Возможности» и найти параметр с пометкой «Связанные домены» , либо проверьте файл .entitlements на наличие ключа com.apple.developer.associated-domains. Мы возьмем пример телеграммы для этого сканирования, потому что его исходный код доступен на github . - Загрузите репозиторий Telegram-iOS .
Следуйте файлу github README.md, чтобы создать проект Xcode. – Откройте проект и найдите com.apple.developer.associated-domains, там вы можете настроить свои универсальные ссылки.
Или вы можете найти ключевые слова «applinks:» из пакета.
Когда у нас будет скомпилированный файл iPA, будет невозможно найти файл .entitlements, содержащий необходимую информацию. Тем не менее, мы можем использовать инструмент под названием Radare2, который поможет нам найти необходимые данные. Выполняя поиск по ключевому слову PropertyList в двоичных файлах приложения, мы можем извлечь необходимую информацию о ссылках приложения.
Возьмем еще один пример для Reddit.
Ну И Что Дальше?
При выполнении проверки безопасности глубоких ссылок приложения iOS простого сбора схем URL-адресов из файла Info.plist не всегда достаточно. Это связано с тем, что глубинные ссылки могут быть более сложными, чем просто схема, и могут также включать пути и параметры. В результате необходимо идентифицировать полную схему диплинков, включая любые связанные пути и параметры, чтобы правильно определить любые проблемы, которые могут возникнуть в ней. Поэтому при изучении ссылок на контент в приложении iOS важно определить полные схемы ссылок на контент с любыми соответствующими путями и параметрами, если они были настроены в приложении.
Как Мы Тогда Это Определяем?
Это зависит от того, как вам предоставляется возможность протестировать приложение. Обычно вам потребуется протестировать приложение по трем подходам: «белый ящик», «серый ящик» и «черный ящик». Для этого блога давайте объединим черный ящик и серый ящик в один, поскольку нам не будет предоставлен исходный код.
Белый Ящик: Наличие Полного Исходного Кода Приложения Для IOS
Если у вас есть весь исходный код приложения, после определения схемы глубокой ссылки из файла Info.plit вы можете перейти к файлу AppDelegate.swift в корневом каталоге проекта iOS в Xcode. Когда вы создаете новый проект iOS, Xcode автоматически создает для вас файл AppDelegate.swift.
Файл AppDelegate.swift служит основной отправной точкой для приложения и управляет входящими ссылками на контент. В частности, функция application(_:open:options
, включенная в файл AppDelegate.swift, отвечает за обработку глубоких ссылок, открывающих приложение. В рамках этой функции разработчики могут получать информацию из URL-адреса глубокой ссылки, чтобы определить соответствующее действие, например отображение определенного контента или перенаправление пользователя на определенный экран.
Итак, давайте перейдем к коду application(_:open:options в нашем приложении DVIA-v2 и посмотрим, сможем ли мы найти там какую-либо дополнительную информацию.
func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
let splitUrl = url.absoluteString.components(separatedBy: "/phone/call_number/")
if ((Int(splitUrl[1])) != nil){
//Valid URL, since the argument is a number
let alertController = UIAlertController(title: "Success!", message: "Calling \(splitUrl[1]). Ring Ring !!!", preferredStyle: .alert)
let okAction = UIAlertAction(title: "OK", style: UIAlertAction.Style.default, handler: nil)
alertController.addAction(okAction)
window?.rootViewController?.present(alertController, animated: true, completion: nil)
}
return true
}
Как видно из приведенного выше кода, он содержит три аргумента: приложение UIApplication : экземпляр класса UIApplication. – url URL : URL-адрес глубокой ссылки, которая запустила приложение. – options UIApplication.OpenURLOptionsKey : словарь параметров запуска приложения.
Также в приведенном выше коде используется метод components(separatedBy для разделения строки URL-адреса глубокой ссылки на строку /phone/call_number/ и создания массива подстрок. Затем он извлекает второй элемент массива, который, как ожидается, будет номером телефона, что делает наши полные схемы глубоких ссылок такими:
Итак, это подход к идентификации схем глубоких ссылок, когда предоставляется исходный код приложения. Если у вас не установлен Xcode, вы также можете найти и просмотреть файл AppDelegate.swift с помощью терминала.
Черный И Серый Ящик: Наличие Ссылки На IPA Или App Store
При проверке безопасности приложений iOS чаще всего вместо исходного кода приложения получают либо скомпилированный файл iPA, либо ссылку в App Store. В таких случаях невозможно просмотреть исходный код файла AppDelegate.swift или любого другого файла. В этих сценариях требуется другой подход для определения схемы диплинка, который будет объяснен ниже.
Как только мы получим файл iPA, нам нужно переименовать его в zip и декомпилировать с помощью команды unzip для просмотра внутренних компонентов файла iPA, но в случае ссылки в App Store вы можете использовать FridaiOSDump или приложение на основе графического интерфейса под названием iMazing для извлечения незашифрованный файл iPA с устройства iOS.
Предполагая, что в настоящее время у вас есть файл iPA, доступный в вашем текущем каталоге. Мы разархивируем файл iPA и найдем двоичный файл с именем DVIA-v2, который присутствует в каталоге Payload. Этот двоичный файл состоит из большей части написанного исходного кода, который компилируется во время сборки.
Определение Путей Глубоких Ссылок С Помощью Регулярных Выражений
Как упоминалось ранее, весь исходный код скомпилирован в двоичный файл, известный как DVIA-v2. Поскольку мы знаем, что пути диплинков имеют формат /something/something, мы можем сгенерировать список строковых литералов из двоичного файла и применить регулярное выражение для идентификации путей, как показано ниже.
Мы можем заметить, что выходные данные отображают пути глубоких ссылок, которые мы искали, которые отформатированы как /something/something и конкретно включают /phone/call_number/.
Мы можем дополнительно уточнить вывод, исключив или отфильтровав ненужную информацию.
strings DVIA-v2 | grep -E '\/.*\/.*' | grep -v 'https://\|/Users/\|/Volumes/\|http://\|BuildRoot/'
Этот метод не всегда может быть успешным, поскольку он требует определения формата путей глубоких ссылок, но его все же стоит попробовать.
Определение Путей Диплинка С Помощью Frida
В более ранних версиях iOS для обработки схем Deep link использовался application:handleOpenURL, но этот метод не мог определить источник, загрузивший URL-адрес. Чтобы устранить это ограничение, Apple представила application:openURL:sourceApplication:annotation:. Однако оба этих метода устарели, и в настоящее время поддерживается метод application:openURL:options:, который предоставляет информацию об источнике загрузки URL-адреса в параметрах.
Давайте посмотрим на примере, как Фрида может проследить упомянутый метод. Трассировщик будет отслеживать все вызовы методов Objective-C, которые соответствуют шаблону [ application:openURL:], который включает в себя любые методы в классе «application» приложения, в имени которых есть «openURL».
$8kSec: frida-ps -Uai | grep -i dvia
3535 DVIA-v2 com.8ksec.DVIAswiftv2
$8kSec: frida-trace -U -m "*[* application:*openURL:*]" DVIA-v2
Instrumenting...
-[DVIA_v2.AppDelegate application:openURL:options:]: Loaded handler at "/Users/8ksec/__handlers__/DVIA_v2.AppDelegate/application_openURL_options_.js"
Started tracing 1 function. Press Ctrl+C to stop.
/* TID 0x103 */
5489 ms -[DVIA_v2.AppDelegate application:0x102506910 openURL:0x28104eed0 options:0x283a81ac0]
Запустите приведенную выше команду, чтобы открыть схему Deep Link, чтобы активировать обработчики, которые мы отслеживаем с помощью Frida.
Frida зарегистрировала вызов метода, который подтверждает, что мы идентифицировали обработчик схемы URL, используемый приложением iOS.
Чтобы использовать универсальные ссылки в приложении iOS, необходимо реализовать метод application:continueUserActivity:restorationHandler: для обработки входящих ссылок. Сообщение в блоге Grepharder содержит подробное руководство по перехвату универсальных ссылок с помощью Frida's Interceptor. Вы можете найти подробное объяснение здесь. https://gist.githubusercontent.com/...42d2ee6a4f07ebe6a9671c658b/universal_links.js
wget https://gist.githubusercontent.com/...42d2ee6a4f07ebe6a9671c658b/universal_links.js
Для этой демонстрации мы будем использовать приложение Telegram. Перечислите имя приложения и имя пакета, используя Frida
Запустите скачанный выше Frida Script в приложении телеграммы.
Откройте схему Deep Link в приложении iOS. Для демонстрации мы запускаем схемы глубоких ссылок через Notes.
Приведенный выше сценарий покажет, как в приложении вызываются ранее упомянутые методы, и перечислит URL-адрес Deep Link.
Другой метод определения схем прямых ссылок и связанных с ними путей и параметров — использование ассоциации сайта Apple App. Это включает в себя проверку параметров и путей, перечисленных в /.well-known/apple-app-site-association, который содержит все разрешенные или определенные параметры и пути. Например, если вы обнаружили, что схема глубокой ссылки https://www.reddit.com из файла Plist, вы можете перейти на https://www.reddit.com/.well-known/apple-app-site. ассоциация для поиска связанных путей и параметров.
Кроме того, мы также можем идентифицировать схемы глубоких ссылок и связанные с ними пути и параметры из приложений Android. Это проще, чем в приложениях для iOS. Мы можем использовать те же схемы в приложениях iOS, чтобы проверить, настроены они или нет. Чтобы узнать, как идентифицировать схемы глубоких ссылок в приложении для Android, вы можете перейти к другому нашему блогу.
В заключение мы исследовали различные схемы глубоких ссылок и методы идентификации. Двигаясь вперед, мы изучим потенциальные уязвимости и предоставим практические демонстрации того, как их использовать, в следующей части нашей серии статей Attacking iOS Deep Link.
Переведено специально для xss.pro
Автор перевода: yashechka
Источник: https://8ksec.io/ios-deeplink-attacks-part-1-introduction-8ksec-blogs/
В первой части этой серии, посвященной атакам с использованием глубоких ссылок в iOS, мы рассмотрим, как распознавать различные типы схем глубоких ссылок, используемых в приложениях для iOS, и выявлять связанные с ними потенциальные уязвимости. В этой части основное внимание будет уделено описанию различных типов схем и объяснению методов их идентификации.
Что Такое Глубокая Ссылка?
Глубокая ссылка в мобильном приложении похожа на специальную ссылку, которая ведет вас непосредственно к определенной части мобильного приложения, а не к веб-сайту. Это означает, что вы можете легко переключаться между приложениями или переходить с веб-сайта в приложение, не нажимая много кнопок. Это позволяет быстрее и проще находить то, что вы ищете в приложении. Просто нажимая на определенные ссылки, т. е. URI (унифицированные идентификаторы ресурсов), пользователи могут беспрепятственно переходить из Safari, Mail, Notes или других приложений для доступа к содержимому вашего приложения.
Существуют различные виды уязвимостей, которые можно найти в Deep link, которые обсуждаются ниже. Чтобы идентифицировать и использовать такие уязвимости, нам сначала нужно понять различные типы схем Deep Links. Давайте сначала пройдемся по ним.
Глубокая Ссылка IOS
В основном для iOS-приложений доступно два типа Deep Link.
URL-схема
Схемы URL-адресов — это способ определить собственный протокол или схему для обработки URL-адресов в вашем приложении. Создав уникальную схему URL-адресов, например 8ksec://, вы можете указать настраиваемое действие, которое будет выполняться, когда пользователь щелкнет ссылку с этой схемой. Например, 8ksec://profile можно использовать для открытия страницы профиля в вашем приложении.
Чтобы указанный выше URI распознавался iOS как ссылка на контент, он должен соответствовать формату схемы URL: схема://ресурс . Поэтому, чтобы эта ссылка работала, вам нужно настроить такие URI, как 8ksec://profile. Как только это будет сделано и ссылка будет нажата, iOS распознает ее как действительную ссылку и предложит пользователю всплывающее окно с запросом разрешения на открытие приложения 8ksec. Схемы URL-адресов также поддерживают параметр запроса, например, если приложение имеет функциональность для перехода к конкретному пользователю, тогда его можно настроить на глубинной ссылке как 8ksec://profile?userID=1337, отформатировав его как схема://ресурс?параметр=значение.
Взяв пример DViA, который является чертовски уязвимым iOS-приложением, мы можем изучить конфигурацию Deep Link, как показано ниже.
Универсальные Ссылки
Универсальные ссылки выглядят как обычные URL-адреса, единственная разница между ними и обычным URL-адресом заключается в том, что универсальные ссылки настраиваются внутри приложения и используются для перехода к определенным компонентам приложения. Предположим, у вас есть приложение 8ksec с универсальной ссылкой, настроенной для URL-адреса https://8ksec.io. Если пользователь нажмет на эту ссылку и на его устройстве установлено приложение 8ksec, ссылка откроет приложение напрямую. Если у пользователя не установлено приложение, вместо этого ссылка откроется в Safari.
В случае универсальных ссылок, когда пользователь устанавливает приложение iOS, система проверяет манифест приложения, чтобы определить связанные с ним домены, в частности домены, начинающиеся с 8ksec, что указывает на то, что домен предназначен для прямых ссылок. Затем система получает доступ к пути /.well-known/apple-app-site-association для каждого соответствующего домена. Этот путь должен содержать предоставленный вами файл JSON, в котором указаны допустимые пути прямых ссылок для этого домена.
Универсальные ссылки были введены в iOS для решения проблем, возникающих со схемами URL. Схемы URL позволяли любому приложению использовать одну и ту же ссылку на контент, даже если она принадлежала другому приложению, что приводило к путанице и потенциальным проблемам безопасности, таким как фишинг. Например, если приложение Reddit имеет URL-схему reddit://, другие приложения могут использовать ту же схему, что приводит к двусмысленности. Однако универсальные ссылки используют ссылки на приложения или URI глубокой ссылки, такие как https://reddit.com , которые должны быть определены в домене приложения в ассоциации сайтов приложений, например https://www.reddit.com/.well-known/apple-app-site-association. App Site Association — это функция iOS, которая позволяет вашему приложению обрабатывать входящие ссылки на контент, связанные с вашим веб-сайтом.
Теперь, когда у нас есть четкое представление о различных типах Deep Links в iOS, мы можем изучить различные векторы атак на iOS Deep Links и продемонстрировать их технически. Чтобы определить уязвимости в Deep Link, мы должны сначала определить схемы Deep Link в приложении iOS. Итак, приступим.
Идентификация Deep Link: Схемы URL
Чтобы идентифицировать схемы Deep Link, первым шагом является извлечение незашифрованного iPA с устройства iOS, что может быть достигнуто с помощью следующих инструментов:
- Unc0ver : приложение для джейлбрейка iOS
- Cydia : используется для установки пакетов на устройство.
- FridaiOSDump : выгружает незашифрованный файл iPA из iOS.
Давайте возьмем пример DVIA-v2 и определим на нем схемы Deep Link. – Загрузите DVIA-v2-swift.ipa отсюда .
Переименуйте файл iPA и разархивируйте его.
Там будет папка с названием Payload. Папка «Полезная нагрузка» в iOS — это каталог, который создается, когда приложение компилируется для распространения через App Store или специальное распространение. Эта папка содержит пакеты, документы, каталог библиотеки и файл plist, содержащий информацию о конфигурации приложения.
Когда в приложении настроена глубокая ссылка, она сохраняется в файле Info.plist, который находится в каталоге Payload. Файл списка свойств (plist) — это тип файла в iOS, в котором хранятся пары «ключ-значение», представляющие различные типы данных конфигурации приложения, включая настройки, предпочтения и информацию о приложении. Файлы Plist могут содержать различные типы информации, такие как настройки приложения, пользовательские настройки и метаданные, что делает их полезным инструментом для управления и хранения данных конфигурации для приложений iOS.
Перейдите в каталог Payload. Там будет еще один подкаталог, сформированный как имя приложения с именем DVIA-v2.app .
Перейдите в DVIA-v2.app и загрузите в список только файлы plist.
Файл Info.plist — это структурированный документ, написанный в формате XML, который содержит пары ключ-значение, представляющие различные атрибуты приложения. Изменяя значения этих ключей, разработчики могут настраивать различные аспекты приложения, такие как его имя и номер версии. - Если мы попытаемся открыть файл plist с помощью обычного текстового редактора или команды cat, мы увидим только закодированные данные, которые выглядят как тарабарщина, как показано на изображении ниже.
Нам нужно изменить формат на XML, используя plutil
И мы можем просмотреть файл plist и определить схемы глубоких ссылок.
Прежде чем определить схемы, давайте сначала разберемся в их структуре. Есть такие компоненты
CFBBundleURLComponents , CFBundleComponentPath и CFBunndleURLComponentQueryItems , отвечающие за содержание и обработку схем прямых ссылок в файле Info.plist. Ключ CFBundleURLComponents используется для определения компонентов схемы URL. Ключ CFBundleURLComponentPath используется для указания пути URL-адреса, а ключ CFBundleURLComponentQueryItems используется для определения любых параметров запроса, которые должны быть включены в URL-адрес. Мы можем увидеть пример ниже.
Давайте изучим файл Info.plist DVIA. Мы уже преобразовали plist в XML с помощью plutil.
Мы можем видеть, что компонент CFBundleURLSchemes содержит два значения dvia и dviaswift , что делает наши схемы глубоких ссылок как dvia:// и dviaswift://
Кроме того, давайте определим схемы глубоких ссылок в другом тестовом приложении под названием OVIA . – Клонируйте репозиторий и создайте iPA из Xcode.
Переименуйте и разархивируйте файл iPA.
Перейдите в каталог Payload и конвертируйте
Откройте файл Info.plist, чтобы определить схемы.
Здесь, в этом приложении, мы видим, что компонент CFBundleURLSchemes содержит одно значение ovia , которое делает наши схемы глубоких ссылок как ovia://
Мы также можем использовать некоторые инструменты, такие как GrapeFruit, для определения схем глубоких ссылок, как показано на изображении ниже. Однако возможности GrapheFruit выходят за рамки этого блога.
Идентификация Deep Link: Универсальные Ссылки
В случае универсальных ссылок они расположены в .entitlements, и каждый домен будет начинаться с ссылок на приложения: и, имея полный доступ к исходному коду приложения, мы можем либо перейти на вкладку «Возможности» и найти параметр с пометкой «Связанные домены» , либо проверьте файл .entitlements на наличие ключа com.apple.developer.associated-domains. Мы возьмем пример телеграммы для этого сканирования, потому что его исходный код доступен на github . - Загрузите репозиторий Telegram-iOS .
Следуйте файлу github README.md, чтобы создать проект Xcode. – Откройте проект и найдите com.apple.developer.associated-domains, там вы можете настроить свои универсальные ссылки.
Или вы можете найти ключевые слова «applinks:» из пакета.
Когда у нас будет скомпилированный файл iPA, будет невозможно найти файл .entitlements, содержащий необходимую информацию. Тем не менее, мы можем использовать инструмент под названием Radare2, который поможет нам найти необходимые данные. Выполняя поиск по ключевому слову PropertyList в двоичных файлах приложения, мы можем извлечь необходимую информацию о ссылках приложения.
Возьмем еще один пример для Reddit.
Ну И Что Дальше?
При выполнении проверки безопасности глубоких ссылок приложения iOS простого сбора схем URL-адресов из файла Info.plist не всегда достаточно. Это связано с тем, что глубинные ссылки могут быть более сложными, чем просто схема, и могут также включать пути и параметры. В результате необходимо идентифицировать полную схему диплинков, включая любые связанные пути и параметры, чтобы правильно определить любые проблемы, которые могут возникнуть в ней. Поэтому при изучении ссылок на контент в приложении iOS важно определить полные схемы ссылок на контент с любыми соответствующими путями и параметрами, если они были настроены в приложении.
Как Мы Тогда Это Определяем?
Это зависит от того, как вам предоставляется возможность протестировать приложение. Обычно вам потребуется протестировать приложение по трем подходам: «белый ящик», «серый ящик» и «черный ящик». Для этого блога давайте объединим черный ящик и серый ящик в один, поскольку нам не будет предоставлен исходный код.
Белый Ящик: Наличие Полного Исходного Кода Приложения Для IOS
Если у вас есть весь исходный код приложения, после определения схемы глубокой ссылки из файла Info.plit вы можете перейти к файлу AppDelegate.swift в корневом каталоге проекта iOS в Xcode. Когда вы создаете новый проект iOS, Xcode автоматически создает для вас файл AppDelegate.swift.
Файл AppDelegate.swift служит основной отправной точкой для приложения и управляет входящими ссылками на контент. В частности, функция application(_:open:options
, включенная в файл AppDelegate.swift, отвечает за обработку глубоких ссылок, открывающих приложение. В рамках этой функции разработчики могут получать информацию из URL-адреса глубокой ссылки, чтобы определить соответствующее действие, например отображение определенного контента или перенаправление пользователя на определенный экран.Итак, давайте перейдем к коду application(_:open:options
в нашем приложении DVIA-v2 и посмотрим, сможем ли мы найти там какую-либо дополнительную информацию.func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
let splitUrl = url.absoluteString.components(separatedBy: "/phone/call_number/")
if ((Int(splitUrl[1])) != nil){
//Valid URL, since the argument is a number
let alertController = UIAlertController(title: "Success!", message: "Calling \(splitUrl[1]). Ring Ring !!!", preferredStyle: .alert)
let okAction = UIAlertAction(title: "OK", style: UIAlertAction.Style.default, handler: nil)
alertController.addAction(okAction)
window?.rootViewController?.present(alertController, animated: true, completion: nil)
}
return true
}
Как видно из приведенного выше кода, он содержит три аргумента: приложение UIApplication : экземпляр класса UIApplication. – url URL : URL-адрес глубокой ссылки, которая запустила приложение. – options UIApplication.OpenURLOptionsKey : словарь параметров запуска приложения.
Также в приведенном выше коде используется метод components(separatedBy
для разделения строки URL-адреса глубокой ссылки на строку /phone/call_number/ и создания массива подстрок. Затем он извлекает второй элемент массива, который, как ожидается, будет номером телефона, что делает наши полные схемы глубоких ссылок такими:
Итак, это подход к идентификации схем глубоких ссылок, когда предоставляется исходный код приложения. Если у вас не установлен Xcode, вы также можете найти и просмотреть файл AppDelegate.swift с помощью терминала.
Черный И Серый Ящик: Наличие Ссылки На IPA Или App Store
При проверке безопасности приложений iOS чаще всего вместо исходного кода приложения получают либо скомпилированный файл iPA, либо ссылку в App Store. В таких случаях невозможно просмотреть исходный код файла AppDelegate.swift или любого другого файла. В этих сценариях требуется другой подход для определения схемы диплинка, который будет объяснен ниже.
Как только мы получим файл iPA, нам нужно переименовать его в zip и декомпилировать с помощью команды unzip для просмотра внутренних компонентов файла iPA, но в случае ссылки в App Store вы можете использовать FridaiOSDump или приложение на основе графического интерфейса под названием iMazing для извлечения незашифрованный файл iPA с устройства iOS.
Предполагая, что в настоящее время у вас есть файл iPA, доступный в вашем текущем каталоге. Мы разархивируем файл iPA и найдем двоичный файл с именем DVIA-v2, который присутствует в каталоге Payload. Этот двоичный файл состоит из большей части написанного исходного кода, который компилируется во время сборки.
Определение Путей Глубоких Ссылок С Помощью Регулярных Выражений
Как упоминалось ранее, весь исходный код скомпилирован в двоичный файл, известный как DVIA-v2. Поскольку мы знаем, что пути диплинков имеют формат /something/something, мы можем сгенерировать список строковых литералов из двоичного файла и применить регулярное выражение для идентификации путей, как показано ниже.
Мы можем заметить, что выходные данные отображают пути глубоких ссылок, которые мы искали, которые отформатированы как /something/something и конкретно включают /phone/call_number/.
Мы можем дополнительно уточнить вывод, исключив или отфильтровав ненужную информацию.
strings DVIA-v2 | grep -E '\/.*\/.*' | grep -v 'https://\|/Users/\|/Volumes/\|http://\|BuildRoot/'
Этот метод не всегда может быть успешным, поскольку он требует определения формата путей глубоких ссылок, но его все же стоит попробовать.
Определение Путей Диплинка С Помощью Frida
В более ранних версиях iOS для обработки схем Deep link использовался application:handleOpenURL, но этот метод не мог определить источник, загрузивший URL-адрес. Чтобы устранить это ограничение, Apple представила application:openURL:sourceApplication:annotation:. Однако оба этих метода устарели, и в настоящее время поддерживается метод application:openURL:options:, который предоставляет информацию об источнике загрузки URL-адреса в параметрах.
Давайте посмотрим на примере, как Фрида может проследить упомянутый метод. Трассировщик будет отслеживать все вызовы методов Objective-C, которые соответствуют шаблону [ application:openURL:], который включает в себя любые методы в классе «application» приложения, в имени которых есть «openURL».
$8kSec: frida-ps -Uai | grep -i dvia
3535 DVIA-v2 com.8ksec.DVIAswiftv2
$8kSec: frida-trace -U -m "*[* application:*openURL:*]" DVIA-v2
Instrumenting...
-[DVIA_v2.AppDelegate application:openURL:options:]: Loaded handler at "/Users/8ksec/__handlers__/DVIA_v2.AppDelegate/application_openURL_options_.js"
Started tracing 1 function. Press Ctrl+C to stop.
/* TID 0x103 */
5489 ms -[DVIA_v2.AppDelegate application:0x102506910 openURL:0x28104eed0 options:0x283a81ac0]
Запустите приведенную выше команду, чтобы открыть схему Deep Link, чтобы активировать обработчики, которые мы отслеживаем с помощью Frida.
Frida зарегистрировала вызов метода, который подтверждает, что мы идентифицировали обработчик схемы URL, используемый приложением iOS.
Чтобы использовать универсальные ссылки в приложении iOS, необходимо реализовать метод application:continueUserActivity:restorationHandler: для обработки входящих ссылок. Сообщение в блоге Grepharder содержит подробное руководство по перехвату универсальных ссылок с помощью Frida's Interceptor. Вы можете найти подробное объяснение здесь. https://gist.githubusercontent.com/...42d2ee6a4f07ebe6a9671c658b/universal_links.js
wget https://gist.githubusercontent.com/...42d2ee6a4f07ebe6a9671c658b/universal_links.js
Для этой демонстрации мы будем использовать приложение Telegram. Перечислите имя приложения и имя пакета, используя Frida
Запустите скачанный выше Frida Script в приложении телеграммы.
Откройте схему Deep Link в приложении iOS. Для демонстрации мы запускаем схемы глубоких ссылок через Notes.
Приведенный выше сценарий покажет, как в приложении вызываются ранее упомянутые методы, и перечислит URL-адрес Deep Link.
Другой метод определения схем прямых ссылок и связанных с ними путей и параметров — использование ассоциации сайта Apple App. Это включает в себя проверку параметров и путей, перечисленных в /.well-known/apple-app-site-association, который содержит все разрешенные или определенные параметры и пути. Например, если вы обнаружили, что схема глубокой ссылки https://www.reddit.com из файла Plist, вы можете перейти на https://www.reddit.com/.well-known/apple-app-site. ассоциация для поиска связанных путей и параметров.
Кроме того, мы также можем идентифицировать схемы глубоких ссылок и связанные с ними пути и параметры из приложений Android. Это проще, чем в приложениях для iOS. Мы можем использовать те же схемы в приложениях iOS, чтобы проверить, настроены они или нет. Чтобы узнать, как идентифицировать схемы глубоких ссылок в приложении для Android, вы можете перейти к другому нашему блогу.
В заключение мы исследовали различные схемы глубоких ссылок и методы идентификации. Двигаясь вперед, мы изучим потенциальные уязвимости и предоставим практические демонстрации того, как их использовать, в следующей части нашей серии статей Attacking iOS Deep Link.
Переведено специально для xss.pro
Автор перевода: yashechka
Источник: https://8ksec.io/ios-deeplink-attacks-part-1-introduction-8ksec-blogs/
Последнее редактирование: