[Из песочницы] Проверка уязвимости Masque в iOS
Недавно опубликована статья, относящаяся к т. н. «Masque» уязвимости в iOS. Выдержка из статьи: «Уязвимость позволяет установить вредоносное приложение поверх уже существующего, причем это новое приложение получит доступ ко всем файлам предыдущего. Это при условии того, что устанавливаемое приложение будет иметь тот же самый идентификатор «bundle identifier», который iOS & OS X используют для идентификации приложений на уровне ОС, например, при доставке им обновлений. Уязвимости подвержены все версии iOS начиная с 7.1.1, включая, последнюю iOS 8.1.1 beta.»
Будучи знакомым с Enterprise сертификатами, мне захотелось непременно опровергнуть/доказать настоящий факт.Итак, что известно про Enterprise лицензию:1. Выдается исключительно компаниям (не частным лицам, подробная информация); 2. Для получения Enterprise лицензии необходимо предоставить в Apple очень серьезный набор документов. Так что указать несуществующую компанию не получится;3. Enterprise лицензии выдаются исключительно для внутреннего использования. То, что таким способом распространяются некоторые приложения — риск компании быть исключенной из iOS Developer Enterprise Program; 4. Установка приложения с сайта возможна через файл манифест и только через HTTPS; 5. При установке приложения, подписанного Enterprise лицензией, пользователю выводится сообщение «Вы действительно хотите установить приложение «App_Name», подписанное сертификатом «Company_Name»?». Где Company_Name берется из сертификата.
Для того чтобы, проверить наличие уязвимости, попробуем пройти путь злоумышленника.
Чтобы подписать приложение, нужно создать Provisioning Profiles:
Следующим шагом указываем App ID:
Но для того, чтобы его указать, необходимо этот App IDсоздать:
На изображении видно, что при создании App ID с идентификатором «bundle identifier», схожим с другим приложением, вызывается ошибка.
Итого: Получить Provisioning Profiles можно только с App ID, который в свою очередь не возможно создать с уже зарегистрированным «bundle identifier». А без Provisioning Profiles мы не сможем подписать приложение.
2 Шаг
Существует еще один способ создания App ID «Wildcard App ID». На сайте компании написано:
This allows you to use a single App ID to match multiple apps. To create a wildcard App ID, enter an asterisk (*) as the last digit in the Bundle ID field.
Создаем свой wildcard App ID, точно такой же, как у приложения, которое хотим подменить, за исключением того, что в место последней части (обычно название приложения) ставим (*).
Далее создаем профиль для нашего нового App ID.
Таким образом, мы получили App ID, создали для него Distribution Provisioning Profiles и смело можем подписывать им наше приложение.
Итак, создадим проект в Xcode и укажем для него следующие параметры:
Проект представляет собой пустое приложение «Single View Application».
Итак, установленная программа на телефоне красуется на рабочем столе:
Подключаем телефон и собираем наше приложение. Напомню, что наше приложение имеет точно такой же App ID, что и у приложения, которое хотим подменить. После сборки приложения ожидаемо получаем такой вот рабочий стол:
Приложение действительно «затерлось». Уязвимость начинает подтверждаться. Теперь интересно, а что с данными? Открываем небезызвестное приложение iTools. Обратите внимание на версию приложения — она поменялась, а вот build остался прежним (в Xcode стоит build==1):
Копируем содержимое и открываем приложение архиватором.
И наблюдаем: все, что было ДО переустановки, осталось на месте!
ДО:
ПОСЛЕ:
В итоге мы получили App ID, создали для него Distribution Provisioning Profiles. Создали простое (пустое) приложение и установили его на телефон. Все данные, которые хранились в приложении, теперь оказались в руках нашего приложения!
Если мы соберем архив и подпишем его созданным профилем, появится возможность распространить приложение через, например, сайт или в почтовой рассылке. Пользователь увидит сообщение «Вы действительно хотите установить приложение «App_Name», подписанное сертификатом «Company_Name»?». Где Company_Name берется из сертификата. Если пользователя не смущает сам факт того, что известное приложение, которое он устанавливал из магазина AppStore, пытается обновиться таким странным способом, да еще и подписано сертификатом какой-то неизвестной ему компании, такой пользователь установит это приложение и отдаст свои данные третьим лицам.
P.S. Что конкретно можно «достать» из приложения таким способом? То же, что и при просмотре тем же iTools, например, но уже удаленно.
В комментариях к статье ожидаю советы по шифрованию важной информации хранимой на телефоне (в песочнице приложения), способы защиты от такого «проникновения» в свои приложения.
