Сбылось одно из самых больших опасений мобильной безопасности. Google на прошлой неделе (6 июня) подтвердил, что киберворам удалось предварительно установить вредоносное ПО в бэкдор платформы Android. Короче говоря, вредоносное ПО, похоже, было благословлено Google в самом глубоком месте Android.
«В контексте приложения Google Play установка означала, что [the malware] не нужно было включать установку из неизвестных источников, и все установки приложений выглядели так, как будто они были установлены из Google Play», — написал в блоге Лукаш Северски из команды безопасности и конфиденциальности Android. «Приложения были загружены с сервера C&C. и связь с C&C была зашифрована с использованием той же специальной процедуры шифрования с использованием двойного XOR и zip. Загруженные и установленные приложения использовали имена пакетов непопулярных приложений, доступных в Google Play. Они не имели никакого отношения к приложениям в Google Play, кроме того же имени пакета».
Корпоративные директора по информационным и информационным технологиям, а также ИТ-директора обнаруживают, что доверять основным компаниям, занимающимся операционными системами для мобильных устройств, — Apple и Google — в их части защиты безопасности сегодня безрассудно. Из-за характера экосистемы Apple (всего один производитель телефонов, что позволяет создать гораздо более закрытую систему) iOS немного более безопасна, но ненамного.
Тем не менее, новое признание Google, безусловно, заставляет Apple выглядеть немного лучше в области безопасности. Проблема не в операционных системах как таковых — и iOS, и Android имеют достаточно безопасный код. Это с приложениями, предлагаемыми предприятиям и потребителям через официально санкционированные хранилища приложений. Специалисты по корпоративной безопасности уже знают, что ни Apple, ни Google не делают слишком много для проверки безопасности приложений. В лучшем случае оба проверяют наличие проблем с политикой и авторскими правами гораздо больше, чем наличие вредоносного ПО.
Но это касается настоящих сторонних приложений. Приложениям, поступающим непосредственно от Apple и Google, можно доверять — по крайней мере, так считалось до раскрытия информации Google.
Инцидент, который признал Google, произошел около двух лет назад, и в сообщении в блоге не было сказано, почему Google не объявил об этом в то время или почему он решил сделать это сейчас. Возможно, Google хотел убедиться, что он достаточно закрыл эту дыру, прежде чем объявить о ней, но два года — это ужасно долгий срок, чтобы знать об этой серьезной дыре и молчать о ней.
Так что же произошло на самом деле? Google получает баллы за публикацию большого количества деталей. Предыстория истории Google началась на год раньше — то есть три года назад — с серии приложений для показа спам-рекламы под названием Triada.
«Основной целью приложений Triada была установка спам-приложений на устройство, на котором отображается реклама», — написал Севьерски. «Создатели Triada собирали доход от рекламы, отображаемой спам-приложениями. Методы, которые использовала Triada, были сложными и необычными для приложений такого типа. были вынуждены адаптироваться, перейдя на бэкдор системного образа».
Затем Севьерски подробно описал методологию приложения: «Первое действие Triada заключалось в установке двоичного файла типа суперпользователя (su). Этот двоичный файл su позволял другим приложениям на устройстве использовать права root. уникален по сравнению с обычными двоичными файлами su, распространенными в других системах Linux.Двоичный файл принимал два пароля: od2gf04pd9 и ac32dorbdq.В зависимости от того, какой из них был предоставлен, двоичный файл либо запускал команду, указанную в качестве аргумента, как root, либо объединял все аргументы, запускал этой конкатенации предшествует sh, а затем запускал их от имени пользователя root. В любом случае приложение должно было знать правильный пароль для запуска команды от имени пользователя root».
Приложение использовало впечатляюще сложную систему для освобождения необходимого пространства, но избегало — насколько это было возможно — удаления всего, что могло бы предупредить ИТ-отдел или потребителя о проблеме. «Наблюдение за весом включало несколько шагов и пыталось освободить место в пользовательском и системном разделах устройства. Используя черный и белый списки приложений, он сначала удалил все приложения из своего черного списка. Если требовалось больше свободного места, он удалит все. другие приложения оставляют только приложения из белого списка. Этот процесс освободил место, гарантируя, что приложения, необходимые для правильной работы телефона, не были удалены». Он также отметил, что «в дополнение к установке приложений, отображающих рекламу, Triada внедрила код в четыре веб-браузера: AOSP (com.android.browser), 360 Secure (com.qihoo.browser), Cheetah (com.ijinshan.browser_fast) и Oupeng (com.oupeng.browser)”.
В этот момент, как писал Севьерски, Google обнаружил попытки вредоносного ПО и смог удалить образцы Triada с помощью Google Play Protect, а также попытался помешать Triada другими способами. Именно тогда Triada нанесла ответный удар примерно летом 2017 года. «Вместо того, чтобы рутировать устройство для получения повышенных привилегий, Triada превратилась в предустановленный бэкдор платформы Android. Изменения в Triada включали дополнительный вызов в функции журнала платформы Android. Благодаря бэкдору функции журнала дополнительный код выполняется каждый раз, когда вызывается метод журнала, то есть каждый раз, когда какое-либо приложение на телефоне пытается что-то записать. Эти попытки журнала происходят много раз в секунду, поэтому дополнительный код [was] бег без остановки. Дополнительный код также выполняется в контексте приложения, регистрирующего сообщение, поэтому Triada может выполнять код в любом контексте приложения. Инфраструктура внедрения кода в ранних версиях Triada работала в версиях Android до Marshmallow. Основной целью функции бэкдора было выполнение кода в контексте другого приложения. Бэкдор пытается выполнить дополнительный код каждый раз, когда приложению нужно что-то зарегистрировать».
Затем вредоносное ПО проявило творческий подход к поиску способов избежать или, по крайней мере, отсрочить обнаружение.
«Каждый файл MMD имел определенное имя файла формата
У вредоносной программы был еще один козырь в рукаве. «Последняя часть головоломки заключалась в том, как бэкдор в функции журнала связывался с установленными приложениями. Это общение послужило поводом для расследования: изменение в Triada показало, что в образе системы был еще один компонент. Приложения могли общаться с бэкдор Triada путем регистрации строки с определенным предопределенным тегом и сообщением. Обратное взаимодействие было более сложным. Бэкдор использовал свойства Java для передачи сообщения в приложение. Эти свойства представляли собой пары ключ-значение, аналогичные системным свойствам Android, но они были привязаны к определенному процессу. Установка одного из этих свойств в контексте одного приложения гарантирует, что другие приложения не увидят это свойство. Несмотря на это, некоторые версии Triada без разбора создавали свойства в каждом отдельном процессе приложения».
В конце поста, который содержит гораздо больше кода и заслуживает внимательного прочтения, Google предлагает некоторые мысли о следующих шагах. Внимательно рассмотрите его предложения и посмотрите, сможете ли вы определить, кто из всего этого выходит безупречным? Из предложений Google: «OEM должны убедиться, что весь сторонний код проверен и может быть отслежен до его источника. Кроме того, любая функциональность, добавленная в образ системы, должна поддерживать только запрошенные функции. Образ системы после добавления стороннего кода. Triada была незаметно включена в образ системы в качестве стороннего кода для дополнительных функций, запрошенных OEM-производителями. Это подчеркивает необходимость тщательной постоянной проверки безопасности образов системы перед продажей устройства пользователям. а также в любое время, когда они обновляются по беспроводной сети (OTA)».
Это справедливо, но кто именно должен проводить эти постоянные проверки безопасности? Конечно, Google не предлагает, чтобы что-то столь важное оставалось в руках OEM-производителей без контроля. Я пришел к выводу, что Google будет добавлять обширные ресурсы в свои собственные группы безопасности, чтобы гарантировать, что ничего подобного не произойдет через контрольные точки OEM.
Существует проблема доверия к Google и Apple, когда речь идет о безопасности мобильных операционных систем и связанных с ними приложений. У OEM-производителей очень низкая рентабельность инвестиций, чтобы оправдать большие инвестиции в безопасность. Деньги должны быть выше Google. Кажется, я не припомню, чтобы у BlackBerry было слишком много таких проблем, и это было потому, что как компания она уделяла приоритетное внимание безопасности. (Хорошо, возможно, стоило уделить немного этого приоритета маркетингу, но я отвлекся.)
Если Google не сделает больше для обеспечения безопасности, ИТ-директорам, директорам по информационной безопасности и ОГО придется либо самим взять на себя эту задачу, либо серьезно задуматься о том, поддержку каких MOS они могут оправдать.
Авторское право © 2019 IDG Communications, Inc.