XARA-уязвимости в OS X и iOS
Для начала, два коротких тезиса:
- Во-первых, большая часть обнародованных уязвимостей касается 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 касается только первая из рассмотренных уязвимостей.
Полезные ссылки:
