Как реклама приводит к утечке данных

Когда мы используем популярные приложения с хорошими рейтингами, скачанные из официальных магазинов приложений, мы полагаем, что они безопасны. Это отчасти так – обычно приложения разрабатываются с учетом соображений безопасности и проверяются ИБ-специалистами магазина приложений. Однако мы обнаружили, что многие популярные приложения из-за использования при их разработке сторонних пакетов средств разработки ПО (SDK) раскрывают в интернете пользовательские данные. Обычно причиной проблемы являются рекламные SDK-пакеты: они собирают пользовательские данные, чтобы показывать пользователю релевантную рекламу, но зачастую не обеспечивают адекватную защиту этих данных при пересылке их на серверы.

Исследуя безопасность приложений для онлайн-знакомств, мы обнаружили, что некоторые такие приложения передают пользовательские данные по протоколу HTTP. Это стало для нас неожиданностью, поскольку для коммуникации со своими серверами такие приложения используют HTTPS. Оказалось, что наряду с HTTPS-запросами посылались и незашифрованные HTTP-запросы на сторонние серверы. Такие приложения весьма популярны, так что мы решили изучить эти запросы внимательнее.

Одно из проанализированных приложений отправляло POST-запросы на сервер api.quantumgraph[.]com. Таким образом оно посылало незашифрованный JSON-файл на сервер, не связанный с разработчиками приложения. В этом JSON-файле мы обнаружили множество данных о пользователе, в т.ч. данные об устройстве, дату рождения, имя пользователя и GPS-координаты. Более того, JSON-файл содержал подробную информацию об использовании приложения, в т.ч. о профилях, которым пользователь поставил «лайки». Все эти данные в незашифрованном виде отсылались на сторонний сервер. Отправленный объём информации вызывает серьезные опасения, поскольку в приложении используется аналитический модуль qgraph.

Еще два проанализированных нами приложения для онлайн-знакомств делали по сути то же самое – для коммуникаций со своими серверами они использовали протокол HTTPS, но в то же время посылали на сторонний сервер HTTP-запросы с незашифрованными пользовательскими данными. Только этом случае это был другой сервер, принадлежащий не аналитической компании, а рекламной сети, которую используют оба приложения. Еще одно отличие заключалось в том, что GET HTTP-запросы с пользовательскими данными использовались как параметры в URL-ссылке. Но в целом суть неизменна – приложения передавали пользовательские данные на сторонний сервер в незашифрованном виде.

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

Итак, я решил разобраться, что происходит в этих приложениях для онлайн-знакомств, которые приводят к утечке данных из-за использованных при их разработке SDK. В каждом приложении обнаружилось не меньше 40 различных модулей, которые составляли его большую часть. Например, не менее 75% байт-кода Dalvik находилось в сторонних модулях одного из приложений; в другом приложении сторонний код составлял 90%.

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

Получение результатов

Зная о существовании популярных SDK-пакетов, которые вызывают утечку пользовательских данных, а также о том, что практически в каждом приложении используются несколько таких пакетов, мы решили поискать другие подобные приложения и SDK. Для этого мы использовали дампы сетевого трафика из нашей внутренней Android-песочницы. С 2014 г. мы собрали сетевой трафик более 13 миллионов APK-файлов. Наш план прост – установить и запустить приложение, имитируя пользовательскую активность и собирая журналы действий и сетевой трафик. Реальных пользовательских данных нет, но для приложения все выглядит так, как будто реальный пользователь запустил его на реальном устройстве.

В трафике мы искали два самых популярных типа HTTP-запросов – GET и POST. В GET-запросах пользовательские данные обычно входят в параметры URL, а в POST-запросах они находятся не в URL, а в поле Content запроса. Мы искали приложения, передающие незашифрованные пользовательские данные при помощи по крайней мере одного из этих двух типов запросов, хотя во многих случаях приложения передавали пользовательские данные обоими запросами.

Нам удалось обнаружить более 4 миллионов APK, при выполнении которых происходила утечка данных в интернет. В некоторых случаях это происходило из-за ошибок разработчиков, но чаще всего причиной утечек было использование сторонних SDK-пакетов. Для каждого типа запросов (GET и POST) мы определили домены, на которые приложения отсылали пользовательские данные. Затем мы отсортировали эти домены по популярности приложений, т.е. по числу пользователей, у которых эти приложения были установлены. Таким образом мы определили наиболее часто используемые SDK-пакеты, которые раскрывают пользовательские данные. Большинство из них передают сведения об устройстве, но некоторые передают более конфиденциальную информацию, такую как GPS-координаты и личные денные.

Четыре наиболее популярных домена, куда приложения передают пользовательские данные через GET-запросы

mopub.com

Этот домен является частью популярной рекламной сети. Связанный с ним SDK используется двумя приложениями, упомянутыми в начале статьи. Вместе с тем, мы нашли много популярных приложений, разработанных с использованием того же SDK-пакета. Пять из них, по данным Google Play Store, были установлены более 100 миллионов раз, у многих других по миллиону установок и более.

SDK-пакет пересылает в незашифрованном виде следующие данные:</p style=»»>

• информацию об устройстве (имя производителя, модель, разрешение экрана)
• сетевую информацию (MCC, MNC)
• имя пакета приложения
• координаты устройства
• ключевые слова

Самая интересная часть передаваемых данных – это ключевые слова. Они могут различаться в зависимости от того, что хотят передать разработчики приложения. В нашем случае передаваемые данные обычно содержали некоторую личную информацию – имя, дату рождения и пол. Местоположение также должно было устанавливаться приложением, и обычно приложения делятся GPS-координатами с рекламным SDK-пакетом.

Мы нашли несколько разных вариантов этого SDK-пакета. Самый распространенный вариант может использовать протокол HTTPS вместо HTTP, но такая опция должна устанавливаться разработчиками приложения. Как мы выяснили, разработчики чаще всего не утруждали себя этим, оставляя опцию по умолчанию, то есть HTTP.

rayjump.com

Этот домен также является частью популярной рекламной сети. Мы нашли два приложения с числом установок более 500 миллионов, еще несколько были установлены более 100 миллионов раз, и множество других с числом установок более миллиона.

Связанный с доменом SDK-пакет передает следующие данные:</p style=»»>

• информацию об устройстве (имя производителя, модель, разрешение экрана, версию ОС, язык устройства, часовой пояс, IMEI, MAC)
• сетевую информацию (MCC, MNC)
• имя пакета приложения
• координаты устройства

В то время как большая часть этих данных передается в открытом виде в параметрах URL, координаты, IMEI и MAC-адрес кодируются при помощи Base64. Нельзя сказать, что эти данные надежно защищены, но по крайней мере они не передаются в открытом виде. Мы не нашли вариантов этого SDK-пакета, позволяющих использовать протокол HTTPS – во всех версиях жестко заданы URL в формате HTTP.

tapas.net

Еще один популярный рекламный SDK-пакет, который собирает такие же данные:</p style=»»>

• информацию об устройстве (имя производителя, модель)
• код оператора связи
• имя пакета приложения
• координаты устройства

Мы обнаружили семь приложений с более 10 миллионов установок из Google Play Store и множество приложений с меньшим числом установок. В этом SDK-пакете мы также не обнаружили возможность для разработчиков выбрать HTTPS вместо HTTP.

appsgeyser.com

Четвертый рекламный SDK-пакет – appsgeyser. В отличие от других, он по сути является платформой, на основе которой можно создать приложение. Те, кто не хочет заниматься разработкой приложения, могут легко создать его с помощью этого сервиса. Полученное приложение будет включать рекламный SDK-пакет, пересылающий пользовательские данные в HTTP-запросах. Таким образом, эти приложения фактически создаются не разработчиками, а данным сервисом.

SDK-пакет пересылает следующие данные:</p style=»»>

• информацию об устройстве (имя производителя, модель, разрешение экрана, версию ОС, идентификатор android_id)
• сетевую информацию (имя оператора, тип соединения)
• координаты устройства

Мы обнаружили огромное количество приложений, созданных при помощи данной платформы и использующих этот рекламный SDK-пакет. Большинство из них не пользуются заметным спросом – самые популярные имеют десятки тысяч установок. Но число таких приложений действительно очень велико.

Как сообщается на веб-сайте appsgeyser.com, таких приложений более 6 миллионов, общее число установок – почти 2 миллиарда. Количество показов рекламы – почти 200 миллиардов, вероятно все через HTTP.

Четыре наиболее популярных домена, куда приложения пересылают конфиденциальные данные через POST-запросы

ushareit.com

Все приложения, пересылающие незашифрованные данные на этот сервер, созданы одной и той же компанией, так что дело не в стороннем коде. Данные приложения очень популярны – одно из них было установлено из Google Play Store более 500 миллионов раз. Эти приложения собирают большой объем информации об устройстве:</p style=»»>

• имя производителя
• модель устройства
• разрешение экрана
• версию ОС
• язык устройства
• страну
• идентификатор android_id
• IMEI
• IMSI
• MAC-адрес

Эти данные в незашифрованном виде пересылаются на сервер. Кроме того, на сервер загружается список поддерживаемых команд, в который входит и команда на установку приложения. Этот список передается открытым текстом, ответ с сервера также приходит незашифрованным – это означает, что его можно перехватить и изменить. Еще хуже то, что приложение, если оно системное или имеет root-права, может по команде с сервера незаметно скачать и установить произвольное приложение.

Lenovo

Вот еще один пример популярных приложений, которые допускают утечку пользовательских данных не из-за использования стороннего кода, а из-за ошибки разработчиков. Мы обнаружили несколько популярных приложений Lenovo, которые собирают и передают в незашифрованном виде следующие данные об устройстве:</p style=»»>

• IMEI
• версию ОС
• язык
• имя производителя
• модель
• разрешение экрана

Это не очень приватная информация. Однако мы обнаружили несколько приложений Lenovo, которые отсылали в незашифрованном виде более конфиденциальные сведения – GPS-координаты, номер телефона и адрес электронной почты.

Мы сообщили об обнаруженных проблемах в Lenovo, и они все исправили.

Nexage.com

Этот домен используется очень популярным рекламным SDK-пакетом, который, в свою очередь, используется в огромном количестве приложений. Одно из таких приложений установлено более 500 миллионов раз, еще несколько имеют более 100 миллионов установок. Чаще всего этот SDK-пакет используется в игровых приложениях. Интересны две вещи касательно этого SDK-пакета – пересылаемые данные и используемый протокол.

SDK-пакет отсылает на сервер следующие данные:</p style=»»>

• информацию об устройстве (разрешение экрана, объем памяти, уровень звука, уровень зарядки аккумулятора)
• сетевую информацию (имя оператора связи, IP-адрес, тип соединения, уровень сигнала)
• координаты устройства

Также передаются следующие данные о доступных аппаратных средствах:</p style=»»>

• Доступ к фронтальной и задней камерам
• Доступ к NFC
• Доступ к Bluetooth
• Доступ к микрофону
• Доступ к GPS-координатам

SDK-пакет также может пересылать личную информацию – возраст пользователя, уровень дохода, образование, национальность, политические взгляды и т.д. Никакого волшебства тут нет: SDK-пакет может получать эти сведения только от приложений, которые его используют. Мы пока не обнаружили ни одного приложения, которое бы делилось подобными данными с SDK, но считаем, что пользователи должны знать о рисках, связанных с вводом такой информации в приложениях. Приложение может передавать эти данные SDK-пакету, а тот в свою очередь может раскрывать их в интернете.

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

Quantumgraph.com

Еще один SDK-пакет, раскрывающий пользовательские данные, использует домен quantumgraph.com. Это не рекламный, а аналитический SDK-пакет. Мы нашли два приложения, которые были установлены более 10 миллионов раз из Google Play Store, и еще семь приложений с числом установок более миллиона. Более 90% пользователей с этим SDK-пакетом были из Индии.

Этот SDK-пакет отсылает файлы JSON с пользовательскими данными по протоколу HTTP. Пересылаемые данные могут меняться от приложения к приложению, поскольку это аналитический SDK-пакет, который отсылает информацию, предоставленную приложением. В большинстве случаев пересылаемые данные включали:</p style=»»>

• информацию об устройстве
• личную информацию
• координаты устройства
• сведения об использовании приложения

В случае приложения для онлайн-знакомств передавались все сведения о пользовательской активности – лайки, пролистывания и посещения профилей.

В этом SDK-пакете были жестко заданы HTTP URL, но после нашего сообщения разработчики создали версию с HTTPS URL. Однако в большинстве приложений по-прежнему используется старая версия с HTTP.

Другие SDK-пакеты

Конечно, есть и другие SDK-пакеты, которые пересылают пользовательские данные по протоколу HTTP, но они менее популярны и практически идентичны описанным выше. Многие из них раскрывают данные о местонахождении устройства, а некоторые также передают адреса электронной почты и телефонные номера.

Прочие находки

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

Приложения не всегда пересылали учетные данные пользователя – иногда они пересылали учетные данные для своих сервисов (например, баз данных). И это странно – зачем устанавливать ограничение доступа к сервису, если учетные данные передаются в открытом виде и доступны для перехвата. Такие приложения обычно пересылают маркеры аутентификации, но мы также встречали в незашифрованном виде логины и пароли.

Вредоносные приложения

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

Раскрываемые данные

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

В большинстве случаев эти приложения раскрывали следующие данные:</p style=»»>

• IMEI – международный идентификатор мобильного устройства, который пользователь никак не может изменить (только поменяв устройство).
• IMSI – уникальный идентификатор SIM-карты. Сменить его можно, только поменяв SIM-карту.
• AndroidID – номер, сгенерированный случайным образом при начальной настройке телефона. Пользователь может изменить его, сбросив настройки к заводским. Начиная с Android 8, сгенерированный случайным образом номер будет присваиваться каждому приложению, пользователю и устройству.
• Информацию об устройстве – имя производителя, модель, разрешение экрана, версию ОС и имя приложения.
• Местонахождение устройства.

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

Почему это опасно

Потому что пересылаемые данные могут быть перехвачены. В незащищенной Wi-Fi сети их может перехватить любой пользователь; владелец сети и сотовый оператор могут узнать о пользователе практически все. Пересылаемые данные проходят через несколько сетевых устройств, на любом из которых они могут быть перехвачены и прочитаны. Зараженным может оказаться даже ваш домашний роутер – есть масса примеров заражения этих устройств вредоносным ПО.

Без шифрования эти данные можно просто извлечь из сетевого трафика. Зная ваши IMSI и IMEI, любой может отследить ваши данные, поступающие из различных источников, а чтобы изменить IMSI и IMEI, вам нужно одновременно сменить SIM-карту и устройство. Знание IMSI и IMEI позволяют злоумышленнику объединить все остальные передаваемые пользовательские данные.

Также пересылаемые по протоколу HTTP данные могут быть изменены. Злоумышленник может, например, подменить рекламу, которая показывается пользователю, или, что хуже, подменить ссылку на приложение. Некоторые рекламные сети продвигают приложения и предлагают пользователям установить их; в таких случаях вмешательство злоумышленника может привести к тому, что вместо запрашиваемого приложения пользователь установит вредоносную программу.

Приложения могут перехватывать HTTP-трафик, чтобы обходить систему разрешений, используемую Android для защиты пользователей от незаявленной активности приложений. Начиная с Android 6, все разрешения делятся на две группы – обычные и представляющие опасность. Если приложению нужны опасные разрешения, оно должно запрашивать их у пользователя во время своего исполнения, а не только перед установкой. Так, чтобы получить доступ к данным о местоположении устройства, приложение должно запросить у пользователя соответствующее разрешение. То же относится к получению доступа к IMEI и IMSI, поскольку это также опасное разрешение.

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

Будущее

Начиная со второй половины 2016 г., все больше приложений переключаются с использования протокола HTTP на HTTPS. Таким образом, процесс идет в правильном направлении, но слишком медленно. По состоянию на январь 2018 г., 63% приложений используют HTTPS, но большинство из них при этом также используют и HTTP. Почти 90% приложений используют HTTP, и многие из них пересылают в незашифрованном виде конфиденциальные данные.

Советы для разработчиков

• Не используйте протокол HTTP. Используя его, вы можете раскрывать пользовательские данные, а это представляет угрозу.
• Назначайте переадресацию 301 для HTTPS-трафика ваших frontend-сервисов.
• Включайте шифрование данных, особенно если используете HTTP. Очень хорошо работает асимметричное шифрование.
• Всегда используйте новейшую версию SDK-пакета, даже если вам придется проводить дополнительное тестирование перед релизом. Это действительно важно, поскольку некоторые проблемы безопасности со временем удается устранить. Во время исследования мы увидели, что во многих приложениях не выполняется обновление сторонних SDK-пакетов и используются устаревшие версии.
• Перед публикацией приложения проверяйте его сетевые коммуникации. Это займет всего несколько минут и позволит вам узнать, не переключается ли использованный SDK-пакет с HTTPS на HTTP-трафик, раскрывая пользовательские данные.

Советы для пользователей

• Проверяйте разрешения приложений. Если вы не понимаете, зачем приложение запрашивает доступ к чему-либо, не давайте разрешения. Большинству приложений не нужен доступ к данным о вашем местонахождении, так что не предоставляйте его.
• Используйте VPN. При использовании VPN-соединения сетевой трафик между вашим устройством и внешними серверами будет шифроваться. За пределами VPN-серверов он по-прежнему не будет шифроваться, но это лучше, чем ничего.