Историями про вредоносное ПО для ОС Android никого уже сегодня не удивить, разве только про rootkit-технологии или про новые концепты, заточенные под новое runtime-окружение ART. C вредоносным ПО для iOS противоположная ситуация: о нем если кто и слышал, то, как правило, только в контексте jailbreak. В 2014 году был вообще бум таких программ (AdThief, Unflod, Mekie, AppBuyer, Xsser). Но в этой статье мы поговорим про вредоносное ПО и его возможности для iOS без jailbreak…
Давайте сразу договоримся о начальных условиях, касающихся нашего Apple-устройства:
- Устройство с ОС iOS на борту;
- ОС iOS последней версии;
- Устройство без jailbreak.
Такие жесткие начальные условия заданы специально (чтобы жизнь медом не казалась). Просто если устройство уже имеет jailbreak или атакующий может его спокойно установить из публичных источников, то это неинтересно и сразу game over: пользователь сам себе злобный Буратино. Модель безопасности операционной системы полностью нарушена, и написание вредоносного кода для такого Apple-устройства ничем не будет отличаться в общем случае от написания вредоносного кода для Android, Windows или Mac.
Основные защитные меры, благодаря которым вредоносный код массово не попадает (не попадал) на Apple-устройства:
- Жесткая проверка приложений при поступлении в AppStore;
- Отсутствие возможности динамически подгружать код из внешних источников;
- На устройстве может исполняться только код, подписанный компанией Apple.
Но давайте обо всем по порядку. Сначала разберемся с тем, какой код и благодаря чему можно вообще запускать на неджейлбрейкнутых устройствах.
Во-первых, можно устанавливать приложения из AppStore: они подписаны distribution-сертификатом и могут запускаться на неограниченном количестве устройств, но распространяться могут только через AppStore после тщательной проверки.
Во-вторых, через приложение TestFlight (из AppStore) для тестирования бета-версий приложений. Такая версия приложения подписано distribution-сертификатом с beta entitlement, доступна для 1000 пользователей (привязка по Apple ID, так что устройств может быть больше) и проходит Beta App Review (занимает меньше времени, так что настолько ли он тщателен, как и для AppStore, непонятно...).
В-третьих, естественно, на устройствах можно запускать код, подписанный developer-сертификатом, выданным Apple-разработчику для конкретного устройства (не более 100 заранее оговоренных устройств – необходимо знание UUID) для тестирования на реальных устройствах (Ad Hoc distribution). По таким же правилам играют и сервисы HockeyApp, Ubertesters, Fabric (Crashlytics). При этом, как вы понимаете, проверка кода от Apple отсутствует ;)
В-четвертых, приложения, подписанные enterprise-сертификатом. Такие приложения можно распространять откуда угодно (in-house-распространение) и запускать на неограниченном количестве устройств (ProvisionsAllDevices = true). И проверка кода от Apple также отсутствует!
Что значит распространять приложение откуда угодно? Это значит, что можно выложить приложение на веб-портал (внутренний или в сеть Интернет) и при обращении к нему просто установить на устройство. В картинках для пользователя установка приложения выглядит вот так:
Найти такие приложения в сети Интернет можно по ключевой фразе:
itms-services://?action=downloadmanifest
Как, я думаю, вы уже догадались, суть проблемы в полном доверии к приложениям, подписанным developer- или enterprise-сертификатом. В общем, вся модель безопасности Apple держится на доверии к сертификатам…
Понятное дело, что злоумышленник может так или иначе заполучить данные сертификаты: создать фейковую компанию или компанию-однодневку или просто украсть сертификаты – это уже дело техники и вопрос подготовки к атаке. Apple имеет возможность отзывать enterprise- и developer-сертификаты (использует OSCP), но есть ряд трюков, которые противодействуют этому процессу. И в случае developer-сертификатов это вообще непростая задача для Apple.
Давайте рассмотрим, какие векторы атак теперь открываются перед атакующим (осведомлен – значит защищен) и вообще есть для неджейлбрейкнутых устройств.
1) Вредоносный подарочек. Просто дарят человеку устройство с предустановленным набором (дареному коню в зубы не смотрят) «полезных» программок: от безопасных мессенджеров до редакторов картинок. Для этого, как правило, берется любая хорошо известная программа из AppStore, распаковывается и расшифровывается, в нее вносится дополнительный функционал, подписывается соответствующим сертификатом и устанавливается на устройство. При этом, как вы понимаете, приложение продолжает нормально функционировать и выполнять свои первоначальные функции. Как бы ни был смешон и примитивен данный способ, нам уже известны случаи, когда подобные устройства дарили определенному кругу лиц в России.
2) Через зараженный компьютер. Устройство подключается к зараженному компьютеру, которому доверяет (с которым установлен pairing), и вредоносный код на системе устанавливает вредоносное приложение уже на мобильное устройство (например, с помощью библиотеки libimobiledevice).
3) Пара секунд в чужих руках. Одолжить телефон злоумышленнику/недругу/ревнивой девушке на пару секунд также будет достаточно для установки на телефон вредоносной программы. Злоумышленник заранее размещает свое приложение где-нибудь в Интернете и, пока телефон у него в руках, через Safari заходит по ссылке и устанавливает его, при этом знание никаких паролей не нужно!
4) Сам себе Буратино. Вы сами можете поставить себе приложение из какого-то стороннего источника, например, в стремлении сэкономить на покупке игры в AppStore. Насколько мне известно, так, например, в Китае (Tongbu) любят покупать, ломать игры и потом бесплатно (или дешевле) их распространять, переподписав своим сертификатом.
5) Взломанный разработчик. Вредоносный код может попасть в проект и спокойно распространиться на устройства через те же HockeyApp, Ubertesters, Fabric (Crashlytics), если они, конечно, используются. Ну или злоумышленник просто выкрадет нужные ему сертификаты у разработчика.
6) Инсайдер. Данный пункт актуален только для самих компаний, у которых есть внутренняя разработка и распространение корпоративных приложений. Проблема в том, что разработчик в такой ситуации волен использовать не только разрешенные Apple функции… но об этом чуть дальше.
7) Через уязвимость приложения. Самый красивый и самый сложный вектор атаки одновременно при минимуме подозрений. При этом приложение даже может распространяться через AppStore. Подобный концепт уже описывали в работе “Jekyll on iOS: When Benign Apps Become Evil”.
8) Благодаря уязвимости в iOS. Такое уже ранее находилось, например, исследователем Charlie Miller и позволяло ему динамически подгружать и выполнять неподписанный код на устройстве.
Читатель, знакомый с механизмами безопасности iOS, может отметить, что после попадания приложения на iOS-устройство оно работает в своем собственном, ограниченном, отделенном от всех sandbox…
В принципе, оно действительно так, НО стоит учесть, что загружаемый злоумышленником вредоносный файл по политике Apple никак не проверялся и по факту может использовать больше функционала, чем любое приложение из AppStore. А все благодаря private API! Сама Apple программы с таким функционалом не пропустит, а тут ее никто и не спрашивает.
Итак, приложение, которое было установлено не из AppStore, с точки зрения безопасности может иметь следующие отличия:
- Может использовать private API – дополнительные функциональные возможности;
- Может общаться с окружающими сервисами (типа mach-портов);
- Получает увеличенный attack surface для проведения jailbreak на устройстве.
Итак, как же private API может быть полезен злоумышленнику? С места в карьер:
| Вызов | Описание |
|---|---|
|
Получить текст входящего SMS-сообщения |
|
Зарегистрировать обработчик на входящие SMS-сообщения и звонки |
|
Получить plist-информацию об установленных приложениях |
|
Всплывающее диалоговое окно поверх всех экранов |
|
Получить пользовательский ввод из диалогового окна |
|
Получить список bundle ID установленных приложений |
|
Получить имя программы по bundle ID |
Для общего осознания, сколько всего скрыто и не разрешено обычным разработчикам под iOS, посмотрите проект iOS-Runtime-Headers, который представляет собой сгенерированный в runtime заголовочный файл для iOS. Или проект RuntimeBrowser, который, в принципе, и используется для генерации таких заголовочных файлов, но позволяет сразу работать с вызовами. Стоит отметить, что private API есть как в private frameworks, так и в public frameworks. А также, помимо приватных Objective-C-классов и методов, есть еще и очень интересные С-функции, которые не находит RuntimeBrowser.
Очень показательная картинка:
Все это так или иначе может использовать злоумышленник. При этом его руки также свободны для применения различных техник динамической загрузки кода через NSBundle и dlopen().
Если вы считаете, что все вышеизложенное – лишь идеи и концепции, то спешу вас огорчить… Подобное уже было в боевой среде – например, зловред Wirelurker, который помимо прочего проводил так называемую Masque Attack. Смысл Masque Attack (CVE-2014-4493 и CVE-2014-4494) заключался в том, что вредоносное приложение ставилось поверх оригинального (мессенджера, почты, банк-клиента и т. д., кроме предустановленных iOS-приложений) и получало доступ к его данным.
Рекомендации по безопасности:
- Не устанавливайте приложения со сторонних источников;
- Обновляйте ОС;
- Контролируйте профили на устройстве (Настройки -> Основные -> Профили);
- Храните в безопасности ваши сертификаты (для разработчиков);
- Контролируйте код, который пишут для in-house-распространения (для заказчиков).
P.S. Людям, интересующимся семплами вредоносного кода для iOS, советую обратиться к данному ресурсу: contagiominidump.blogspot.ru/search?q=iOS.
Полезные материалы по теме:
