Недавно опубликована статья, относящаяся к т. н. «Masque» уязвимости в iOS. Выдержка из статьи:
Мне, как человеку, не понаслышке знакомому с 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». На сайте компании написано:
Создаем свой wildcard App ID, точно такой же, как у приложения, которое хотим подменить. В последнию часть 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, например, но уже удаленно.
В комментариях к статье ожидаю советы по шифрованию важной информации, хранимой на телефоне (в песочнице приложения), способы защиты от такого «проникновения» в свои приложения.
«Уязвимость позволяет установить вредоносное приложение поверх уже существующего, причем это новое приложение получит доступ ко всем файлам предыдущего. Это при условии того, что устанавливаемое приложение будет иметь тот же самый идентификатор «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:
Создание Provisioning Profiles
Следующим шагом указываем App ID:
Выбираем App ID
Но, для того чтобы его указать, необходимо этот 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
Создаем свой wildcard App ID, точно такой же, как у приложения, которое хотим подменить. В последнию часть App ID (обычно название приложения) пишем (*).
Создали Wildcard App ID
Далее создаем профиль для нашего нового App ID.
Создание In-House Provisioning Profiles
Таким образом, мы получили App ID, создали для него Distribution Provisioning Profiles, и смело можем подписывать им наше приложение.
Итак, создадим проект в Xcode и укажем для него следующие параметры:
Создаем проект в Xcode
Проект представляет собой пустое приложение «Single View Application».
Итак, установленная программа на телефоне красуется на рабочем столе:
Рабочий стол с приложением которое мы планируем подменить
Подключаем телефон и собираем наше приложение. Напомню, наше приложение имеет точно такой же App ID, что и у приложения, которое хотим подменить. После сборки приложения получаем такой вот рабочий стол:
Рабочий стол, наше приложение успешно заменяет Цель
Приложение действительно «затерлось». Уязвимость начинает подтверждаться. Теперь интересно, а что с данными?
Открываем небезызвестное приложение iTools. Обратите внимание на версию приложения — она поменялась, а вот build остался прежним (в Xcode стоит build==1):
Так выглядит наше приложение в iTools
Копируем содержимое и открываем приложение архиватором.
И наблюдаем: все, что было ДО переустановки, осталось на месте!
ДО:
Структура папок оригинального приложения
ПОСЛЕ:
Структура папок после подмены приложения
В итоге мы получили App ID, создали для него Distribution Provisioning Profiles. Создали простое (пустое) приложение и установили его на телефон. Все данные, которые хранились в приложении, теперь оказались в руках нашего приложения!
Если мы соберем архив и подпишем его созданным профилем, появится возможность распространить приложение через, например, сайт или в почтовой рассылке. Пользователь увидит сообщение «Вы действительно хотите установить приложение «App_Name», подписанное сертификатом «Company_Name»?», при этом Company_Name берется из сертификата. Если пользователя не смущает сам факт того, что известное приложение, которое он устанавливал из магазина AppStore, пытается обновиться таким странным способом, да еще и подписано сертификатом какой-то неизвестной ему компании, такой пользователь установит это приложение и отдаст свои данные третьим лицам.
P.S. Что конкретно можно «достать» из приложения таким способом? То же, что и при просмотре тем же iTools, например, но уже удаленно.
В комментариях к статье ожидаю советы по шифрованию важной информации, хранимой на телефоне (в песочнице приложения), способы защиты от такого «проникновения» в свои приложения.
