Юрий Шабалин, Стингрей Технолоджиз: Если сторы подключатся к информированию разработчиков об уязвимостях, уровень безопасности мобильных приложений возрастет кратно

Юрий Шабалин, генеральный директор компании «Стингрей Технолоджиз» и автор телеграм-канала «Mobile AppSec World», рассказал порталу Cyber Media о ситуации с мобильными приложениями в России. Поговорили о модерации в сторах, обходе блокировок, мошеннических уловках для загрузки вредоносных приложений, снижении общего уровня защищенности и бдительности пользователей.

CyberMedia: Как в общем виде выглядит процедура модерации приложения перед попаданием в разные сторы? Какие особенности есть у разных платформ?

Юрий Шабалин: Все магазины приложений используют похожий принцип проверки. Но я бы выделил несколько видов модерации.

Стандартная. Разработчик загружает приложение, описывает его функциональность, чем оно будет полезно пользователю, прикладывает скрины интерфейса и т. д. В некоторых магазинах на этом этапе требуется приложить политику конфиденциальности, документы по обработке персональных данных и т. д. Также необходимо описать, какую информацию собирает приложение, как именно и с какой целью. Если оно будет использовать «опасные разрешения», разработчик обязан пояснить, как именно и для чего (например, доступ к контактам пользователя). При стандартной модерации запрашивается разная информация и уточняется, зачем нужны те или иные права.

Функциональная модерация. Некоторые сторы утверждают, что публикуют только полезные для пользователей приложения. Они дополнительно проверяют соответствие заявленного функционала описанию.

У нас есть показательный пример, раскрывающий «эффективность» такой модерации. Мы специально разработали максимально уязвимое приложение, нашпигованное проблемами безопасности и уязвимостями. А еще оно содержало серьезную логическую ошибку и вылетало при попытке регистрации (на самом деле, не специально так получилось). В качестве эксперимента мы выложили наше приложение в шесть публичных сторов. Только один из четырех магазинов указал нам на логическую ошибку, в два других сразу загружалась исправленная версия. После этого мы обновили версию приложения во всех сторах. Фактически только один магазин из четырех действительно запустил приложение, посмотрел на его функционал и проверил, что оно вообще рабочее. Остальные сторы просто опубликовали. Поэтому говорить о функциональной проверке преждевременно, потому что запускать и проверять каждое приложение ни у кого нет возможности и ресурсов.

Собственные проверки сторов. Каждый магазин приложений вправе запустить собственные проверки, которые кажутся ему важными или требуются для соблюдения закона. Например, для загрузки приложения в Huawei AppGallery, чтобы оно стало доступным в регионе КНР, необходимо файл продукта сопроводить отчетом на проведение аудита безопасности. Нигде такого не видел, но это очень интересный ход, который стоило бы взять на вооружение многим магазинам.

Если говорить именно о проверках на безопасность, то можно выделить несколько основных направлений:

Анализ на вирусы. Есть много способов, начиная от загрузки приложения на VirusTotal и проверки сработок от разных инструментов, заканчивая серьезным анализом поведения, когда загружаемые приложения запускаются в специальной «песочнице», где отслеживаются все вызовы к функциям системы, анализируется трафик приложения, его поведение на устройстве и многое другое. И уже на основе этих данных выдается вердикт — делает ли продукт нечто запрещенное, является ли какой-то модификацией вируса или нет.
Анализ на рекламу. Большинство сторов проводит анализ на количество рекламы в приложении. Если ее много, продукт будет запрещен к публикации. К сожалению, я не видел точных рекомендаций, какое количество рекламы допустимо и как не перейти эту грань, но они есть или определяются экспериментальным путем.
Анализ на использование запрещенных методов. Этот пункт относится к Apple AppStore и GooglePlay, которые тщательно следят за используемыми в приложении методами. У операционных систем Android и iOS есть требования по использованию приватных API — нельзя напрямую вызвать какой-то механизм работы операционной системы, который является запрещенным. В случае с Apple, это просто черный список методов. В Android есть белый, серый и черный список методов. В белом — те, что разрешены, в сером — будут запрещены в скором времени, и нужно бы их заменить, в черном — те, использование которых запрещено. И вот на эти API магазины смотрят весьма тщательно.
Проверка на уязвимости. Некоторые магазины заявляют, что проверяют приложения на уязвимости перед их публикацией. К примеру, тот же Google приводит достаточно объемный список проблем безопасности, на которые приложение проверяется перед публикацией. Что, как оказалось, не совсем правда, или просто механизмы не идеальны.

В целом, все правила модерации направлены лишь на одно — обезопасить сам магазин приложений и подтвердить соответствие его требованиям. Никто не будет искать функциональные проблемы или слабости в защите продуктов. Сторы озабочены соблюдением их собственных правил. Но среди отечественных публичных магазинов приложений прослеживается тенденция помочь разработчикам и дать им возможность повлиять на безопасность своих пользователей и приложений.

CyberMedia: Насколько часто магазины приложений обновляют свои алгоритмы модерации?

Юрий Шабалин: Чаще происходят локальные изменения, нацеленные на уточнение уже существующих мер. Если планируется большое изменение или обновление, об этом сообщают заранее и так, чтобы узнало максимальное число заинтересованных лиц. Я могу рассказать о трех подобных событиях:

Отказ Apple от поддержки 32-битной архитектуры и объявление о скором удалении из стора всех приложений, что не соответствуют требованиям. Это изменение коснулось всех приложений на iOS-устройствах. Информация об этом нововведении появилась заблаговременно, поэтому у компаний было минимум полгода, чтобы обновить свои приложения.
Отказ Android от несертифицированных устройств, когда на несертифицированных сборках Android запрещалось устанавливать Google-сервисы. Не совсем про магазины, но тоже значимое событие, которое косвенно относится к теме.
Требование указывать, какие телеметрические данные собирает приложение и обоснование этих действий. Эти изменения и обновления — «гонка вооружения» Apple и Google, которые пытаются переплюнуть друг друга в борьбе за свободу пользователя и приватность его данных. При этом хочу отметить крайне любопытную ситуацию. Уже после введения этого требования в магазине Apple AppStore, Google целый месяц не обновляло свои приложения. Либо они боялись показать, сколько информации собирают, либо спешно «выпиливали» трекеры из приложений.

Периодически магазины вводят новые требования при модерации приложений, но делают это не спонтанно, а заранее, давая возможность разработчикам подготовиться. Причем основной тренд изменений в модерации — контроль за сохранением приватности пользователей как на стороне магазинов, так и на стороне операционных систем.

CyberMedia: Какие уловки используют злоумышленники, чтобы обойти автоматизированные средства проверки и «протащить» вредоносное приложение?

Юрий Шабалин: Способов достаточно много. Какие-то успешно детектируются, но некоторые работают, что подтверждается регулярным появлением различных вирусов в официальных магазинах приложений. Я бы выделил несколько основных уловок злоумышленников.

Определение запуска на эмуляторах. Многие зловредные приложения определяют запуск в среде эмуляции и отказываются работать. Обычные пользователи ничего не заметят, а для приложения это неплохая защита от автоматизированных средств, которые используют эмуляторы для тестирования. Таким нехитрым способом многие из «зловредов» стараются защитить себя от профилирования и отслеживания их действий.

Отложенные действия. Чтобы не быть обнаруженными сразу после установки, опасные приложения сначала ведут себя нейтрально. Стартует зловредный функционал либо по предустановленному триггеру на действия, например, по времени — каждый понедельник в два часа ночи. Или по команде от управляющего сервера (C&C — Command and Control) — приложение периодически обращается к своему «управляющему центру» и выполняет нужные действия. Причем вариантов маскировки управляющих серверов огромное количество. Это может быть аккаунт в соцсети Х, закрытый Telegram-канал, обращение к Telegram-боту, чтение постов на определенной странице в Facebook (признана экстремистской организацией и запрещена на территории РФ) и т. д. Главная цель маскировки — не вызвать подозрений обращением к неизвестному серверу.

Подгружаемый код. Чтобы обойти проверку по коду, зловредные приложения используют технику подгрузки части кода уже после установки. Сигнал к действию — таймер или команда от управляющего сервера. При такой схеме изначально загружаемое приложение не несет негативной активности, работает штатно и легитимно. Но по команде оно может загрузить часть кода с сервера и выполнить его. Такая уловка используется, чтобы расширить функционал, не меняя кода приложения. Сторы стараются детектить такую возможность, но не всегда это удается.

Усложнение анализа кода. Существует как минимум три варианта уловки с усложнением кода. Все они направлены на то, чтобы затруднить анализ приложения и помочь ему «протиснуться» в магазин:

Защита кода пакером. Код внутри собранного файла приложения шифруется и становится доступным только во время исполнения на устройстве. Чтобы добраться до него, потребуется сначала обойти встроенные проверки, а потом получить код из памяти запущенного приложения.
Обфускация кода или строк. Чтобы прочитать код или строки, необходимо выяснить алгоритм, по которому они «скрываются».
Перенос части задач в нативный код. В отличие от кода, полученного через декомпиляцию apk, нативный хуже поддается инструментальному анализу. Именно на это и рассчитывают злоумышленники.

Публикация фальшивых обновлений приложений. При получении доступа к аккаунту разработчика злоумышленники загружают модифицированную версию приложения, добавив определенный функционал. Или размещают новый продукт от имени разработчика, но уже с «начинкой», нужной мошенникам. Доступ к аккаунту получают при помощи фишинга, взлома или банальной покупки.

Бывает, что никакими уловками мошенники не пользуются, а надеются на беспечность и невнимательность пользователей. Недавно я сам столкнулся с таким случаем. Загрузил нужное мне приложение и увидел в рекомендациях другое — «Все банки в одном» со 100 тысячами загрузок. Скачал его, чтобы посмотреть, что же это за зверь. Приложение состояло из одного экрана, на котором нужно было выбрать банк и ввести данные карты. При вводе данных они отправлялись на сервер к злоумышленнику. Вот и весь функционал. Никаких запрещенных функций, зловредного кода или уловок. Простой расчет «на дурачка». А чтобы приложение вышло в топ и попало в рекомендации, достаточно воспользоваться специальными платными сервисами. Но хочу отметить, что, пока я изучал приложение, его убрали из стора и выпустили статью, разоблачающую этот тип «вируса».

Недавно была новость про исследование очередного «зловреда», который сливал контакты пользователя на сервер злоумышленника, изображая из себя новую версию приложения Телеграм. Очень похожий принцип — приложение не делало ничего, только при получении доступа к контактам сразу же передавало их своим создателям. На его этом функциональность заканчивалась.

Так что опасны могут быть не только мобильные продукты с вирусами, но и те, что используют легитимный функционал операционной системы и нацелены на доверчивость пользователей.

CyberMedia: Предусмотрены ли у магазинов приложений механизмы защиты на те случаи, когда злоумышленнику удалось скомпрометировать изначально легитимное приложение?

Юрий Шабалин: Основной механизм всех магазинов — удаление скомпрометированного приложения. У Android есть другой — служба Google Play Protect, которая выполняется на устройстве и периодически анализирует его на наличие нелегитимных и опасных элементов. При обновлении легитимного приложения и получении «полезной нагрузки» пользователь сможет об этом узнать.

Некоторые производители включают в состав своих продуктов антивирусные средства, которые подсвечивают подозрительные активности на устройстве. Но они работают только на официальных сборках Android. Например, на устройствах Huawei, отлученных от сервисов Google, антивирусные средства будут недоступны. Да и в целом, из-за большой фрагментации Android-устройств неясно, что будет с подобным сервисом и не попробуют ли его отключить производители.

CyberMedia: Ряд российских банков и других компаний столкнулись с тем, что их приложения удаляются из ведущих сторов. Многие из них используют технологию WebView, чтобы выпустить свое приложение на тех или иных платформах. На ваш взгляд, какие риски ИБ это может повлечь?

Юрий Шабалин: Это большая проблема, о которой мало кто задумывается со стороны безопасности приложений. Есть банковское приложение, которое разрабатывалось годами, неоднократно проверялось на различных пентестах, изучалось с разных сторон и имело очень хороший уровень защищенности. Но его удаляют из стора. Нужно в кратчайшие сроки обеспечить пользователей каким-то решением, которое пропустят в стор, не заблокируют в течение нескольких дней. Для этого в сжатые сроки разрабатывается новое приложение, фактически пишется с нуля и публикуется под другим именем и от лица другой компании. Кто в такой ситуации будет думать о безопасности? И появляется новый продукт, почти идентичный прежнему, но не настолько безопасный. Проблема особенно актуальна для iOS, потому что сегодня нет другого способа поставить приложение на устройство, кроме как через официальный магазин. Apple обещает сделать альтернативные сторы, но время покажет, как это будет выглядеть. С Android все проще, так как есть и отечественные магазины, в которых остаются прошлые безопасные версии приложений.

Но это не все, есть и другая проблема. Из-за массовых удалений из сторов компании приучили пользователей к тому, что за рандомным приложением, например, «Помощь на дороге», может скрываться переделанный банковский сервис. Такой поведенческий сценарий ослабляет бдительность аудитории. На этом играют злоумышленники, публикуя фейковые приложения под видом переделанных. Только недавно фейки популярных банков выдавали себя за оригинальные и собирали данные пользователей.

Обход блокировок, к которому вынуждены прибегать банки и другие компании, дает возможность пользователям применять привычные сервисы. Но это разрушает установки, которые формировались у них на протяжении многих лет. Раньше твердили, что нельзя загружать приложения из неизвестных источников, что нужно тщательно проверять всю информацию о разработчике. А теперь оказалось, что можно, и это пагубно сказывается на общем уровне защищенности. Но другого выхода пока что нет.

Что касается WebView, то это выход для компаний, чьи приложения заблокированы. Но есть вероятность, что их рано или поздно также начнут блокировать. Риски ИБ с такими приложениями зависят от того, насколько качественно сделан продукт и сколько внимания при разработке уделялось безопасности. Нужно понимать, что нет небезопасных технологий, все дело в их применении. Поэтому нельзя сказать, что приложение, написанное нативно, безопаснее, чем созданное на кроссплатформенном фреймворке или вообще на WebView. Все дело в фокусе на безопасности и умении посмотреть на разрабатываемую функциональность с точки зрения злоумышленника.

CyberMedia: На ваш взгляд, какие процедуры, инструменты и другие меры нужны, чтобы магазин приложений можно было считать «секьюрным»?

Юрий Шабалин: Это сложный вопрос. Магазины приложений стараются обеспечить свою аудиторию качественными сервисами и проверками. Но им не хватает анализа приложений на уязвимости, наличия опции блокировки публикации при выявлении серьезных проблем, а также канала донесения информации до разработчиков. Например, Google заявляет в своей программе, что проводится проверка мобильных продуктов, но делается это крайне посредственно.

В качестве примера приведу недавний случай. Коллеги из Positive Technologies опубликовали информацию о серьезной уязвимости в библиотеке для организации навигации в продукте JetPack Navigation. Это действительно серьезная проблема, которой подвержено много приложений. Но кто о ней узнает? Мы с коллегами постарались донести информацию до компаний, используя публичные ресурсы, Telegram-каналы и блоги. Но это капля в море. Если об этой проблеме мы могли рассказать через магазины приложений, это была бы совсем другая история. Представьте ситуацию:

Разработчик загружает приложение в маркет.
В рамках модерации производится аудит приложения автоматизированными средствами.
Разработчик получает отчет по безопасности его приложения. В нем, в частности, есть информация о новом типе атаки, которой подвержен продукт.
Все компании во время очередного апдейта получают информацию об атаке и смогут принять необходимые меры.
Все нужные люди об этом узнают. Идеальная ситуация.

В некоторых отечественных магазинах такой подход уже реализован, а в других планируется к внедрению в ближайшее время. И это очень круто, что наши сервисы действительно заботятся о безопасности своих пользователей и предоставляют возможности, которые не может обеспечить ни один из зарубежных сторов. Это то, к чему необходимо стремиться: помогать компаниям защищать своих пользователей и сделать нашу цифровую мобильную жизнь безопаснее.