Для начала, два коротких тезиса:
- Во-первых, большая часть обнародованных уязвимостей касается OS X. В iOS все намного спокойнее.
- Во-вторых, все на самом деле достаточно печально.
А теперь подробнее об уязвимостях:
1. Перехват данных, передаваемых через URL-схемы.
В iOS (как, впрочем, и в OS X) приложения могут общаться между собой посредством URL-схем. Как это выглядит:
Для примера, возьмем ситуацию, когда в наш любимый мобильный почтовый клиент БлаБлаПочта приходит e-mail, содержащий в себе какой-нибудь адрес. Наш почтовик достаточно умный, и по нажатию на этот адрес перебрасывает пользователя в, скажем, навигационное приложение БлаБлаКарты. Единственный способ реализовать такой переход в iOS — это вызвать в первом приложении ссылку вида:
blablamaps://55,678+32,432
Система отлавливает вызов такого URL и проверяет, какое из установленных приложений может его обработать. Если такое приложение найдено, то происходит переход, и открывшаяся программа уже сама решает, каким образом поступить с данными (в нашем случае — координатами).
Все веселье начинается, когда не одно, а два приложения заявляют, что работают с URL такого вида. Авторы определили следующие правила поведения операционных систем:
- OSX перебросит пользователя в приложение, которое первым заявило, что оно работает с этой схемой.
- iOS перебросит пользователя в приложение, которое последним заявило, что оно работает с этой схемой.
Любопытный момент заключается в том, что, в отличие от того же Android, пользователю не предоставляется выбор, какое из приложений должно открыться. Нет никаких дополнительных механизмов аутентификации, ничего.
Таким образом, уязвимость эксплуатируется следующим образом:
Мы создаем свое приложение, BlaBlaHijack, в свойствах которого указываем возможность обрабатывать URL-схему blablamaps, и отдаем его пользователю. В отличие от BlaBlaMaps, наша вредоносная программа не откроет карту, а просто перешлет эти координаты на наш сервер.
Та же схема работает с любыми данными, передаваемыми между приложениями — к примеру, токенами, получаемыми при авторизации через Facebook или Twitter.
Слабое звено таких схем обычно заключается в способе передачи атакуемому пользователю вредоносной программы. Что особенно замечательно — Apple не ведет никакого общего каталога URL-схем, поэтому такое приложение спокойно пройдет модерацию и будет доступно для загрузки.
2. Модификация прав доступа keychain на OS X
В отличии от iOS, каждому из свойств, хранимых в Keychain на OS X можно установить дополнительные права доступа (Access Control List), в которых будет перечислено, каким приложениям предоставляется доступ к нему. Проиллюстрируем связанные с этим механизмом уязвимости на очередных представителях семейства BlaBlaSoftware.
Пользователь скачивает из Mac App Store очень популярное приложение, BlaBlaBook — хипстерскую социальную сеть. Как и любое другое порядочное приложение, при вводе авторизационных данных оно пытается сохранить их в Keychain. И здесь вступает в действие еще один механизм — перед тем, как создать новую запись, система проверит, нет ли уже в связке ключей записи с такими параметрами. Это сделано для того, чтобы при обновлении программ пользовательские данные не слетали. Если такая запись найдена, то ее содержимое перезапишется, если нет — то создастся новая. И если во втором случае ACL задает приложение BlaBlaBook, то в первом — ACL не изменится.
Так вот, вернемся к уязвимости. За день до установки BlaBlaBook пользователь скачал себе другое приложение, уже упомянутый нами BlaBlaHijacker. Этот вредонос первым добавил в Keychain запись с такими же параметрами, которые требуются оригинальному приложению, и в ACL добавил себе все права. Таким образом, когда пользователь попытается сохранить свой пароль, доступ к нему будет уже у двух приложений — и BlaBlaBook, и BlaBlaHijacker.
Что интересно, вредоносное приложение не обязательно должно быть установлено первым — у любого стороннего приложения есть возможность удалить определенную запись в Keychain и перезаписать ее своей.
3. Доступ к песочнице
Общеизвестно, что все приложения в OS X работают в рамках своей песочницы и не имеют доступ к другим программам. Эти песочницы представлены в файловой системе папками, названием которых выступает уникальный идентификатор приложения. Mac App Store при проверке всех публикуемых программ проверяет этот ID на уникальность, поэтому, казалось бы, повторений быть не должно.
Сложности вносит возможность включать в оригинальное приложение дополнительные подпрограммы — хелперы, фреймворки, да что угодно, у чего есть свой Bundle ID. Каждая из таких подпрограмм работает в своей песочнице. Уязвимость заключается в том, что Apple не проверяет на уникальность идентификаторы этих хелперов — в следствие чего два разных приложения могут работать в одной и той же песочнице и получить полный доступ к данным друг друга.
Лучше всего эту уязвимость демонстрирует случай с популярным менеджером паролей 1Password и его расширением 1Password Mini.
4. Уязвимости общения через WebSocket
Вкратце говоря, WebSocket — это протокол, с помощью которого сервер может общаться с клиентом. Он интегрирован как часть стандарта HTML5, и позволяет содержимому WebView в браузере обращаться к любому другому приложению в системе, прокидывая данные через определенный TCP порт. И, конечно, какая либо аутентификация отсутствует и в этом случае — этот порт может слушать кто угодно. Расширение в браузере никак не может проверить, с кем конкретно оно общается.
Пример эксплуатации уязвимости — как и в предыдущем случае, 1Password. Его браузерное расширение собирало введенные пользователем в различных формах пароли и номера кредитных карт, и через порт 6263 отправляло их приложению. Дальнейшие действия просты — пишем программу, которая слушает этот же порт, логируем все полученные данные, и собираем неплохую базу. Опять же, все это спокойно проходит проверку в App Store.
Apple в курсе всех упомянутых уязвимостей еще с осени прошлого года — и, по информации из отчета, на исправление этих уязвимостей требуется не меньше полугода.
Еще раз упомяну, что iOS касается только первая из рассмотренных уязвимостей.
Полезные ссылки:
- Оригинальный отчет (обязателен к прочтению, серьезно)
- Обсуждение на форумах 1Password
Комментарии (23)
vsb
18.06.2015 09:01+2Я запустил BlaBlaHijacker и он увёл мои данные. Ой-ой-ой, что-же делать, кого-же винить?
Утрирую, некоторые проблемы, конечно, есть. URL-схемы это дырка by design, удаление ключей без права доступа к ним это дырень (или я что-то не понимаю). Но резервирование порта это уже бред, такого нигде нет и не будет. Приложение должно само аутентифицировать, кому оно шлёт эти данные. Я бы не советовал пользоваться менеджером паролей с такой архитектурой.
Ubuntovod
18.06.2015 11:13«Приложение должно само...» Мы живем не в идеальном мире, увы. Внушить каждому разработчику правила сложнее (да в целом невозможно), чем определить область допустимых действий. Тому же Касперскому и Adobe (к примеру, из другой области) плевать, что официальные деинсталляторы оставляют тонны хвостов в системе. Они не скрываясь гадят на системах рядовых пользователей, закрывают на это глаза — им никто не указ. И если любое популярное приложение начнет издеваться над клиентом (Скайп) — это повлияет на Ваш личный выбор, но не на большинство.
Другой вопрос — когда на уровне ОС есть механизмы принудительного регулирования. Они должны быть.
creker
18.06.2015 13:49когда на уровне ОС есть механизмы принудительного регулирования. Они должны быть.
Они есть — механизмы аутентификации на уровне API. Никто не будет вводить ограничения на сетевой стек, это нереалистично. Максимум это ввод гайдлайнов для разработчиков. Канал данных между приложением и внешним миром это забота разработчика и только разработчика. Это как раз наша с вами реальность.Ubuntovod
18.06.2015 13:54То есть, если разработчик откровенно игнорирует какие-либо правила, но при этом приложение популярно либо отказаться от него нельзя — делать с кривотой ничего не надо? Ладно, пусть хоть на уровне API был бы порядок, так его же нет.
creker
18.06.2015 14:09Есть какие-то правила? Я нигде их не видел. На уровне API порядок есть. Есть сетевой стек, есть технологии шифрования, аутентификации и контроля целостности. Выбирай что хочешь. Единственное, что в этой ситуации можно делать, это вводить ограничения на определенный вид приложений, которые работают с персональными данными. С учетом того, что проблемы защиты канала данных известны с самого дня их появления и Apple явно о них тоже знают, у меня большие сомнения что спустя такое время какие-либо существенные ограничения вдруг появятся.
super-guest
18.06.2015 10:11А вы пользуетесь каким-нибудь менеджером паролей вообще? Каким? Или только штатным?
Goodkat
18.06.2015 19:45mSecure
Несколько лет назад сравнивал 1Password и mSecure для айфона, mSecure на тот момент оказался намного удобнее и функциональнее.
Потом и десктопную версию к нему докупил на какой-то распродаже.
Сейчас лень менять, да и десктопный 1Password денег стоит.
Redgard
18.06.2015 14:00-1Не знаю почему заголовок такой, но iOS это не касается. Добавлю официальный комментарий от 1Password. https://discussions.agilebits.com/discussion/comment/212875/#Comment_212875
YourDestiny Автор
18.06.2015 19:33+1Заголовок такой, потому что рассматриваются не только уязвимости, связанные с Keychain
TimsTims
18.06.2015 14:23-5-в отличие от того же Android, пользователю не предоставляется выбор, какое из приложений должно открыться.
Вот за это я и не люблю ios — нет выбора. Все делается за тебя, ты не можешь это настроить или поменять — только через удаление/переустановку приложения.
greenkaktus
18.06.2015 16:04+2А подскажите пожалуйста, как в Андроиде поменять одно приложение открываемое по ссылке на другое, в настройках нету почему-то.
ArtRoman
19.06.2015 11:46В настройках приложения есть кнопка «Сбросить умолчания», тогда при открытии ссылки система вновь предложит сделать пользователю выбор, если он есть, с возможностью запомнить действие «по умолчанию». Механизм одинаков не только для ссылок, но и для открытия домашнего экрана, например, если приложений несколько.
Goodkat
Ubuntovod
Достаточно по необходимости резервировать порт для одного приложения.
Но меня больше интересует 1Password — софтина для работы с паролями, и нет шифрования на таком уровне? Это уже косяк разработчика, а не ОС.
Goodkat
Как резервировать-то? Из-за одного приложения никто из миллионов пользователей маков больше не сможет использовать этот порт?
И как делать шифрование? Расширение браузера — это javascript-код. Даже если сделать ассиметричное шифрование и расширение обойдётся публичным ключём, то вытащить приватный ключ из программы — не проблема.
Ubuntovod
Я о том, что если приложение призвано работать с приватной информацией, необходимо создать возможность для разработчика защищать канал передачи. На уровне AppStore возможно доработать механизм модерации. Допустим, объявить заранее определенный диапазон портов, который позволено резервировать только специально одобренным приложениям, действительно нуждающимся в защите. Да, это завинчивание гаек — но в таком частном случае оно на руку всем. И Apple как раз может это сделать, если захочет.
vsb
> И как делать шифрование? Расширение браузера — это javascript-код. Даже если сделать ассиметричное шифрование и расширение обойдётся публичным ключём, то вытащить приватный ключ из программы — не проблема.
Если вытащить приватный ключ из программы не проблема, то и вытащить пароли не проблема. В атаке предполагается, что программа может открывать слушающий сокет, но не может получать доступ к данным 1Password.
Кстати слушать сокет может только одна программа. Достаточно запускать 1Password при загрузке системы и отчаянно ругаться, если не удалось забинидиться на сокет. Если есть права — отключать расширение браузера в таком случае, пока пользователь не решит проблему.
kekekeks
Goodkat
Да, останется только защитить доступный всем программам буфер обмена.
Мне кажется, бескостыльный способ — это сделать браузерное расширение частью основной программы, тогда у них будет общая область памяти, примерно как это сделано под iOS. Но тогда это будет не Javascript-расширение, а нативный плагин, и возможно потребует переработки механизма расширений.
Интересно, как обстоят дела в других браузерах и операционных системах.
kekekeks