Недавно опубликовано статья , относящийся к так называемому.
«Маскирующие» уязвимости в iOS. Выдержка из статьи:
«Уязвимость позволяет установить вредоносное приложение поверх существующего, и это новое приложение получит доступ ко всем файлам предыдущего.Как человек, знакомый с сертификатами Enterprise не понаслышке, мне определенно хотелось опровергнуть/доказать этот факт. Итак, что известно о лицензии Enterprise: 1. Выдается исключительно компаниям (не частным лицам, Подробная информация ); 2. Для получения лицензии Enterprise необходимо предоставить Apple очень серьезный пакет документов.При этом предполагается, что устанавливаемое приложение будет иметь тот же «идентификатор пакета», который iOS и OS X используют для идентификации приложений на уровне ОС, например, при доставке для них обновлений.
Это касается всех версий iOS, начиная с 7.1.1, включая последнюю бета-версию iOS 8.1.1».
Так указать несуществующую компанию не получится; 3. Выдаются корпоративные лицензии исключительно для внутреннего использования.
Тот факт, что некоторые приложения распространяются таким образом, рискует исключить компанию из программы iOS Developer Enterprise Program; 4. Установка приложения с сайта возможна через файл манифеста и только по HTTPS; 5. При установке приложения, подписанного лицензией Enterprise, пользователю предлагается сообщение «Вы уверены, что хотите установить приложение «Имя_приложения», подписанное сертификатом «Название_компании»Э», при этом Название_компании берется из сертификата.
Чтобы проверить наличие уязвимости, попробуем проследить путь злоумышленника.
Чтобы подписать приложение, вам необходимо создать Provisioning Profiles: Создание профилей обеспечения 
Следующий шаг — указание App ID: Выберите идентификатор приложения 
Но для того, чтобы указать его, вам необходимо создать этот App ID: Создайте идентификатор приложения 
На изображении показано, что при создании идентификатора приложения с помощью идентификатор «Идентификатор пакета», аналогичный другому приложению, выдает ошибку.
Общий: Вы можете получить профили обеспечения только с идентификатором приложения, который, в свою очередь, не может быть создан с уже зарегистрированным «идентификатором пакета».
А без Provisioning Profiles мы не сможем подписать приложение.
2 шаг Существует еще один способ создать идентификатор приложения «Идентификатор приложения с подстановочным знаком».
На сайте компании написано:
Это позволяет вам использовать один идентификатор приложения для сопоставления нескольких приложений.Создание идентификатора приложения с подстановочным знакомЧтобы создать идентификатор приложения с подстановочным знаком, введите звездочку (*) в качестве последней цифры в поле «Идентификатор пакета».
Мы создаем собственный идентификатор приложения с подстановочными знаками, точно такой же, как у приложения, которое мы хотим заменить.
В последней части App ID (обычно название приложения) пишем (*).
Создан идентификатор приложения с подстановочными знаками 
Далее мы создаем профиль для нашего нового идентификатора приложения.
Создание собственных профилей обеспечения 
Таким образом, мы получили App ID, создали для него Distribution Provisioning Profiles и можем безопасно подписать с его помощью наше приложение.
Итак, создадим проект в Xcode и укажем для него следующие параметры: Создать проект в Xcode 
Проект представляет собой пустое приложение с одним представлением.
Итак, установленная на телефоне программа красуется на рабочем столе: Рабочий стол с приложением, которое планируем заменить 
Подключаем телефон и собираем наше приложение.
Напомню, что наше приложение имеет точно такой же App ID, что и приложение, которое мы хотим заменить.
После сборки приложения мы получаем следующий рабочий стол: Desktop, наше приложение успешно заменяет Target 
Приложение действительно зависло.
Уязвимость начинает подтверждаться.
Теперь мне интересно, а как насчет данных?
Откройте всем известное приложение iTools. Обратите внимание на версию приложения — она изменилась, но сборка осталась прежней (в Xcode — build==1): Вот как выглядит наше приложение в iTools 
Скопируйте содержимое и откройте приложение архиватором.
И наблюдаем: всё, что было ДО переустановки, осталось на месте! ДО : Исходная структура папок приложения 
ПОСЛЕ : Структура папок после замены приложения 
В результате мы получили App ID и создали для него Distribution Provisioning Profiles. Мы создали простое (пустое) приложение и установили его на телефон.
Все данные, которые хранились в приложении, теперь находятся в руках нашего приложения! Если мы соберем архив и подпишем его созданным профилем, то можно будет распространять приложение, например, через сайт или в рассылке.
Пользователь увидит сообщение «Вы уверены, что хотите установить приложение «App_Name», подписанное сертификатом «Company_Name»Э», где Company_Name взято из сертификата.
Если пользователя не смущает тот факт, что известное приложение, которое он установил из AppStore, таким странным образом пытается обновиться, да еще и подписано сертификатом какой-то неизвестной ему компании, такой пользователь установит это приложение и передать его данные третьим лицам.
P.S. Что именно можно «получить» из приложения таким способом? То же, что и при просмотре теми же iTools, например, но удаленно.
В комментариях к статье жду советов по шифрованию важной информации, хранящейся на телефоне (в песочнице приложений), способы защиты от такого «проникновения» в ваши приложения.
Теги: #MASQUE #iOS #уязвимость #информационная безопасность #разработка iOS
-
Тезисы О Взломе Жж И Безопасности В Целом
19 Oct, 24 -
Джо Армстронг Об Инструментах Разработчика
19 Oct, 24 -
Часто Задаваемые Вопросы - 1
19 Oct, 24
