Как бы не было странно, им стало предустановленное приложение по обеспечению безопасности – «Guard Provider». Его цель защищать телефон, обнаруживая вредоносное ПО, но на деле, оно как раз и подставляет пользователя под вирусные атаки.
Вредоносное ПО
Мобильные устройства обычно поставляются с предустановленными программами, некоторые из которых полезны, а некоторые вообще не открываются владельцами смартфонов. Тем не менее, пользователи особенно не надеются получить от программ, установленных по умолчанию, реальную помощь в обеспечении конфиденциальности и безопасности данных устройства. Так и произошло с приложением для подключения антивируса – Guard Provider.
Уязвимый к атакам характера сетевой трафик, поступающий в приложение и из него, позволяет атакующему произвести подключение к используемой его целью сети Wi-Fi, и организовать так называемую «атаку посредника» (MiTM). Когда связь тайно ретранслируется и при необходимости изменяется так, что стороны продолжают считать, что коммуникация по-прежнему идет только между двумя устройствами или людьми. Затем, как часть стороннего обновления SDK, он может отключить защиту от вредоносных программ и внедрить любой мошеннический код, который он выберет, для кражи данных, имплантации вымогателей или отслеживания или установки любых других видов вредоносных программ.
Как работает атака
Xiaomi «Guard Provider» – это предустановленное приложение во всех основных телефонах Xiaomi, которое использует несколько сторонних комплектов разработки программного обеспечения (SDK) в качестве части предлагаемой им службы безопасности, включая различные типы защиты, очистки и усиления устройств.
Приложение включает три встроенных антивирусных бренда, которые пользователь может выбрать для защиты своего телефона: Avast, AVL и Tencent. Выбрав приложение, владелец смартфона выбирает одного из этих поставщиков в качестве антивирусного ядра по умолчанию для сканирования своего устройства.
Прежде чем объяснить сценарий потенциальной атаки, важно отметить, что на самом деле есть несколько скрытых недостатков в использовании нескольких SDK в одном приложении. Поскольку все они разделяют контекст приложения и разрешения, эти основные недостатки заключаются в следующем: во-первых, проблема в одном SDK поставит под угрозу защиту всех остальных. Во-вторых, данные частного хранилища одного SDK не могут быть изолированы и, следовательно, могут быть доступны другому SDK.
Итак, когда Avast установлен в качестве сканера безопасности приложения по умолчанию, приложение периодически обновляет свою вирусную базу, загружая APK-файл в личный каталог провайдера. Затем он загружается и выполняется Avast SDK перед сканированием устройства и содержит метку времени, когда файл был загружен. К сожалению, из-за того, что механизм обновления использует незащищенное HTTP-соединение для загрузки этого файла злоумышленник, с помощью атаки MiTM, может определить время обновления Avast и предсказать, каким будет имя APK-файла на диске. С этого момента достаточно просто перехватить ответную часть соединения. Таким же образом, могут быть предотвращены и будущие обновления Avast.
По еще одному сценарию, как только атакующая сторона начнет активно блокировать соединения с сервером Avast, пользователь переключит антивирус по умолчанию на другой, например AVL. Напомним, что антивирусный пакет AVL также является встроенной частью приложения Guard Provider.
После того, как AVL станет антивирусом по умолчанию, он немедленно обновит приложение своей вирусной базой. Это осуществляется путем проверки наличия новых сигнатур вирусов путем запроса файла конфигурации. Этот файл имеет простой текстовый формат с указанием URL, размера и MD5-хеша ZIP-архива с новыми подписями.
Оказывается, что AVL SDK уязвим к другой проблеме безопасности, которая помогает хакеру выполнить второй этап атаки: обход пути во время процесса распаковки. В результате он может использовать созданный архив для перезаписи любого файла в изолированной программной среде приложения, включая файлы, связанные с другим SDK.
Поэтому созданный APK-файл, который добавляется как запись в архив ZIP-подписей, будет успешно перезаписывать ранее загруженное обновление из Avast, поскольку оба компонента антивирусного SDK используют ту же песочницу в соответствующих SDK.
Все, что нужно сделать злоумышленнику – это отключить связь Avast и заблокировать связь AVL, пока пользователь снова не выберет Avast в качестве активного антивируса. Когда это произойдет, созданный вредоносный APK-файл будет загружен и выполнен Avast SDK.
Атака прошла успешно, так как файл подписи предыдущего обновления Avast не был проверен перед загрузкой, а Guard Provider уже проверил его при первой загрузке. Таким образом, предполагается, что нет причин проверять это снова. Таким образом, созданный вредоносный файл может быть загружен и запущен, поскольку он, по сути, крался по спине охранника.
Вопрос остается открытым
В настоящее время доверие пользователя к предустановленным программам производителей смартфонов, особенно когда эти приложения утверждают, что защитят телефон от любой угрозы, весьма логично. Однако уязвимость, обнаруженная в Guard Provider, поднимает тревожный вопрос о том, кто кого охраняет. И хотя острой необходимости в охране нет, очевидно, что когда речь идет о качестве разрабатываемых приложений, даже если они встроены производителем смартфонов, быть слишком осторожными невозможно.
Приведенный выше сценарий атаки также иллюстрирует опасность использования нескольких SDK в одном приложении. Несмотря на то, что незначительные ошибки в каждом отдельном SDK часто могут представлять собой отдельную проблему, когда в одном приложении реализовано несколько SDK, вполне вероятно, что еще более критические уязвимости будут не за горами.