Яндекс - 69,9% поискового рынка РФ, 110+ млн пользователей в месяц, десятки сервисов: поиск, браузер, карты, маркет, такси, музыка, почта, диск, алиса, еда, погода, кинопоиск, плюс... Если у вас андроид - Яндекс.Поиск и Яндекс.Браузер почти наверняка стоят с завода. На Samsung, Xiaomi, Honor, Realme...
Мы взяли два APK Яндекса и отреверсили их.
Там прям плохо. Настолько, что MAX и РУСТОР на их фоне выглядит как детский сад.
В одну статью все это не влезает, придется разделить на несколько, а конкретно на 3.
Кстати подарочек - нейросеть от яндекса для т9 в виде GGUF.
Что там было
- Аудио-претриггер буфер - микрофон пишет звук до того как вы сказали Алиса, и этот кусок звука улетает на сервер. При этом размер окна управляется с сервера - может быть 3 секунды, а может и больше.
- WiFi-сканирование - Яндекс сканирует все точки вокруг, собирает BSSID/SSID/RSSI и шлёт на свой сервер для геолокации.
- Платёжные данные (PAN + CVV) до токенизации - до того как карта затокенизируется, PAN и CVV уходят на mobpayment.yandex.net.
- 94 JavaScript Bridge метода - 17 addJavascriptInterface() мостов. XSS на любом поддомене yandex.ru = компрометация устройства.
- Адресная книга в реальном времени - ContentObserver на всё устройство, любые изменения контактов улетают на сервер.
- Logcat эксфильтрация с AES шифрованием - костыльный код.
- Remote config (70+ флагов) - сервер может включить сохранение карт, форсировать Алису, отложить запрос разрешений на 3 года.
АУДИО-СЛЕЖКА PRE-TRIGGER БУФЕР
Голосовой помощник Алиса работает так: микрофон пишет звук постоянно, но не отправляет его пока не услышит «Алиса». Когда вы говорите «Алиса» - вы уже сказали это слово. То что было до слова «Алиса» - попадает в буфер.И Яндекс этот буфер забирает на свои сервера.
Называется pre-trigger buffer. Кольцевой буфер куда микрофон пишет звук непрерывно. Когда wake word срабатывает - приложение вычитывает буфер и отправляет всё что было ДО ключевого слова вместе с командой.
Казалось бы ну ладно, что с того, может быть это для дебага или серверной валидации, только вот почему то ( а почему нам ответят в коментариях разработчики яндекса на что я очень надеюсь ) размер этого окна не фиксирован. Он управляется с сервера через параметры HasPreroll, buffer-size-ms, loggingSoundLengthBeforeTriggerMs. по умолчанию оно стоит 3 секунды, если бы так и было я бы не добваил пункт в статью... только вот его можно регулировать с сервера, сервер может выставить любое. Или вообще выключить pre-trigger.
Буфер по умолчанию 48000 сэмплов (3с)
Смотрим utw.java:42 - там конфигурация буфера Алисы. 48000 семплов при 16kHz = 3 секунды. Это дефолт.
В BaseAudioSource.java:303 создаётся объект захвата с микрофона. audioSource = 1 = MIC, 16kHz, моно, 16 бит.
BaseAudioSource.java:345-367. Работает пока сервис жив. Читает пачки звука, пробрасывает подписчикам.
Куда улетает аудио
Для контекста
Разумеется без pre-trigger буфера современный голосовой помощник не может нормально работать - ему нужно слышать контекст до команды. Но моя претензия не к этому, а вот к чему:- Размер буфера управляется с сервера - а не фиксирован кодом. Сервер Яндекса в любой момент может выставить 30 секунд, минуту, сколько угодно.
- Pre-trigger включает биометрию - голосовой отпечаток строится в том числе по pre-trigger контенту.
- Пользователю не сообщается что pre-trigger активен, какого он размера, и что запись уже идёт.
- Наверное вы даже не знали что pre-trigger там вообще существует.
WIFI FINGERPRINTING
Яндекс сканирует все WiFi точки рядом, собирает MAC роутера, имя сети, силу сигнала и отправляет на сервер. У Яндекса есть база расположения WiFi точек - зная какие рядом, вычисляет ваши координаты с точностью до 10-50 метров. Работает внутри зданий, где GPS не ловит. Заходите в торговый центр - Яндекс знает в какой вы магазин зашли.
Куда шлётся
BuildConfig.java - основной endpoint: https://startup.mobile.yandex.net. Резервные: startup-mobile.ap.yandex-net.ru, startup.mobile.webvisor.com.G2.java - SynchronizedDataCache с именем "wifi". Данные кэшируются и отправляются пачками.
Для контекста
В пользовательском соглашении (ToS) всё это официально прописано - мол, это нужно для обучения их алгоритмов, ( на деле для рекламы ). Да и не стоит забвать Google занимается ровно тем же самым. Становится ли от этого легче? Вообще ни капельки.Решать тут вам, но я думаю у вас есть право знать что делает приложение на вашем телефоне ( не стоит забывать что ваша геолокация моментально уходит сторонним компаниям, а базы данных сливают до сих пор ) .
ПЛАТЁЖНЫЕ ДАННЫЕ (PAN + CVV) ДО ТОКЕНИЗАЦИИ
Когда вы вводите карту в приложении Яндекса, PAN (номер карты) и CVV летят на сервер до токенизации. Но не волнуйтесь, это абсолютно легально и соответствует PCI DSS. Яндекс же сертифицирован, все под контролем - примерно так же, как в 2023 году под полным контролем находился их исходный код до того, как утек на торренты.АРХИТЕКТУРА БЕЗОПАСНОСТИ
Проблема в том что весь цивилизованный мир уже давно использует архитектуру на порядок элегантнее и безопаснее:
- Client-side токенизация (iFrames / Hosted Fields, как у Stripe Elements или Braintree): Данные карты вообще не касаются ваших серверов. Поля ввода физически изолированы на стороне провайдера, приложение видит только готовый токен. Поверхность атаки на вашей стороне = ноль. Радиус поражения при взломе бэкенда = ноль.
- Device-level токенизация (Apple Pay / Google Pay / EMVCo): Пользователь вообще не светит картой. Девайс генерирует одноразовую криптограмму на уровне железа (Secure Enclave). Даже если хакер перехватит этот токен по пути, он будет абсолютно бесполезен для любых других транзакций.
- И, для сравнения, Server-side токенизация (как у Яндекса): Данные карты послушно летят через твой бэкенд, API-гейтвей, балансировщики, проходят через SIEM, ELK-stack и вообще через всё, что может в один прекрасный момент упасть с ошибкой и радостно плюнуть {pan, cvv} в файлик с логами.
Какие есть риски?
- Логи. Сервер упал с 500-й ошибкой ровно в момент передачи карты? Поздравляю, {pan: "4276..., cvn: "123"} уже в логе. А лог читают 150 человек. Откуда мы это знаем? из 7e0ac90b489baee8a823381792ec67d465488fef
- Промежуточные сервера. startup.mobile.yandex.net - это не крепость, это обычный бэкенд с кучей эндпоинтов, аналитикой, экспериментами.
- Инсайдер. Охранять один микросервис легко. Охранять всю инфраструктуру приложения, через которую транзитом проходят PAN+CVV - нужно, чтобы 100500 разработчиков, devops'ов и тестировщиков были в PCI DSS scope.
Для контекста
Юридически легально. Есть сертификат, есть изолированный CDE-контур.Но архитектурно это код образца 2012 года. Stripe, Braintree, Adyen уже 10 лет назад доказали, что можно сделать так, чтобы сервер приложения вообще не видел карту.
Если mobpayment.yandex.net взломают - всё, данные утекли. Яндекс взламывали. VK взламывали. АНБ взламывали
VPN DETECTION
За это их уже забуллили все, но грех упуститьПриложение проверяет наличие интерфейса tun0 (стандартное имя для VPN). Если найден - блокирует авторизацию.
Думаю не секрет что Яндекс заставляет отключать VPN и светить реальный IP, потому что полностью прогнулся под требования Роскомнадзора и Кремля по тотальной слежке и цензуре.
DNS HARDCODED
Приложение использует 77.88.8.8 и 77.88.8.1 в обход системного DNS, VPN DNS, DoH и Tor. Это DNS Яндекса. Даже если вы настроили Cloudflare DoH или используете Tor - Яндекс делает запросы к своим DNS напрямую.
Проще говоря, они видят абсолютно все домены куда вы ходите, и есть огромная вероятность, что вся эта «история браузинга» по первому требованию улетает прямо в нужные руки - ну а выводы делайте сами.
NATIVE SURVEILLANCE ENGINE
Самое сладкое разработчики спрятали в native-библиотеке libquarkenstein_daemons.so.
Внутри зашито всё: пайплайны записи аудио с микрофона (с прямой отправкой на сервера), манипуляции с процессами в обход security-модели Android, нативная геолокация и шифрование. Это полноценный движок слежки, заботливо упакованный в один тяжело читаемый файл (в котором, кстати, по классике забыли затереть внутренние debug-пути сборки, денис опять ты?) вообщем это я так, чтобы вы не забывали о том что выйдет 2/3 часть, новости есть тут.
JAVASCRIPT BRIDGE
21 addJavascriptInterface() мостов. 94 @JavascriptInterface метода. Файл assets/api.js - 30+ функций.
Для контекста
Любая XSS-уязвимость на поддоменах yandex.ru - это мгновенный билет к контролю над вашим устройством. Злоумышленникам нет смысла пробивать лбом неприступные главные серверы с их WAF и круглосуточным мониторингом. Достаточно найти одну незапертую форточку на заднем дворе экосистемы.XSS - неизбежнен:
- Кладбище поддоменов: У IT-гигантов их сотни, если не тысячи. От заброшенных промо-акций пятилетней давности до дев-песочниц, где выполнение пользовательского кода - это вообще основная функция.
- Человеческий фактор: В инфраструктуре такого колоссального размера забытого, устаревшего или криво написанного кода невозможно избежать ( без формальной верификации ) . Уязвимый эндпоинт, позволяющий исполнить произвольный веб-скрипт, появится со стопроцентной вероятностью ( или уже тихо существует и ждет своего часа, без намека ).
- Слепой Фейсконтроль" Как только хакерский скрипт запускается на таком уязвимом поддомене, мобильное приложение видит знакомое окончание .yandex.ru и после чего радостно распахивает перед ним все 94 JS-моста, пропуская веб-пейлоад прямиком к нативным функциям.
КОНТАКТЫ
Приложение читает полную адресную книгу (имена, телефоны, email, почтовые адреса, организации, фото), а также журнал звонков. Установлен ContentObserver на ContactsContract.Contacts.CONTENT_URI - любое добавление, удаление или изменение контакта вызывает перечитывание данных. Контактные данные сериализуются через protobuf и отправляются на сервер Яндекса через HTTP POST (с OAuth-авторизацией).VoIP / мессенджеры
Читает не только обычные телефоны, но и номера из WhatsApp, Telegram, Viber через фильтр MIME-типов phone_v2, viber, telegram, whatsapp.
Отправка на сервер
Ссобирает все контактные данные в UploadContactsRequest - протобаф-структуру с полями:
- ContactInfo (ID контакта, id, lookup, displayname, account_type, account_name, times_contacted, timestamps)
- PhoneInfo (номер, тип, приложение-источник)
- LookupInfo (lookup-ключи)
ПАССИВНАЯ ГЕОЛОКАЦИЯ + СОТОВЫЕ ВЫШКИ
Приложение регистрирует пассивного провайдера геолокации - это позволяет перехватывать координаты, полученные другими приложениями на устройстве. Дополнительно собираются данные о сотовых вышках: MCC, MNC, Cell ID, LAC/TAC, что позволяет триангулировать положение устройства с точностью до 100-500 метров даже в помещениях. Пассивный провайдер доставляет обновления от любого приложения, уже имеющего координаты.
LOGCAT ЭКСФИЛЬТРАЦИЯ
Под капотом дёргается Runtime.getRuntime().exec("logcat -d") - попытка снять полный дамп системных логов. Дальше всё это пакуется, шифруется AES и летит к ним на сервер.
Для контекста
В теории, Logcat - это проходной двор, куда пишут логи вообще все приложухи на телефоне. То есть Яндекс должен пылесосить логи вашего банка, VPN, секретных чатов, историю URL-ов и крашиситуация тут прям как с RuStore, повторяться не буду. Звучит страшно, но по факту это так только для юзеров старых ОС (ну или если вы сидите с кастомным рутом и выдаете права направо и налево).
Современный Android давно прикрыл эту лавочку на уровне песочницы: без системных привилегий (READ_LOGS) приложение может читать только свои собственные логи. Так что на актуальных прошивках Яндекс через этот логкат успешно соберет данные только о том, как забаговал сам Яндекс.
Если бы в Яндексе работали тру-профи, они бы изначально на уровне кода ограничили сбор логов только своим приложением. А попытка тянуть logcat -d целиком, в расчете на то, что «ОС сама обрежет лишнее» - это просто наглядный показатель того, как там пишется архитектура
APP INVENTORY
Приложение собирает список ( про то как он обходит ограничение андроид и тд ниже ) установленных пакетов на устройстве через два механизма: PackageManager.getInstalledApplications() и, как fallback, Runtime.getRuntime().exec("pm list packages"). Список приложений позволяет идентифицировать банки, VPN, мессенджеры, магазины, антивирусы и другие приложения пользователя.Основной метод: getInstalledApplications()
Собирает все packageName установленных приложений.
Fallback: shell-команда
Резервный механизм при TransactionTooLargeException или DeadObjectException:
Парсит вывод package:com.example.app, извлекая имена пакетов.
Детектор контент-блокеров
После сбора всех пакетов v000.x() проверяет каждый на наличие meta-data:
- "com.samsung.android.sbrowser.contentBlocker.interfaceVersion" - если "API_1.0", проверяется ContentProvider
- Для подходящих приложений собирается signatureHash и displayLabel
- Результат - список ej40{packageName, displayLabel, signatureHash}
использует getInstalledApplications() для поиска установленных банковских приложений. Сверяет packageName со списком известных банков, результат показывается в UI оплаты.
VK Push SDK
При отсутствии master-host приложения шлёт аналитический ивент "vkcm_sdk_client_no_master_host_found" с параметром "installed_apps", содержащим список packageName всех установленных приложений. Этот ивент уходит на серверы аналитики VK.
CLID-детекция
Сохраняется в SharedPreferences и используется для аналитики/аттрибуции.
не особо легальный обход ограничений Android
«Но покроет ли это ограничения Android 11+, где Google ввёл Package Visibility и запретил приложениям просто так видеть чужие пакеты?»Ещё как покроет! Разработчики Яндекса не дураки, чтобы просить у Google Play опасное разрешение QUERY_ALL_PACKAGES (за которое их выкинули бы из стора). Они поступили технически изящнее: захардкодили гигантский список целевых приложений прямо в тег <queries> своего AndroidManifest.xml.
В Android 11+ если пакет явно объявлен в <queries>, приложение имеет полное официальное право проверять его наличие через PackageManager.
Что именно Яндекс внес в свой список «разрешённого наблюдения»:
- Вся экосистема Яндекса и дочек: Такси, Карты, Лавка, Диск, Почта, Еда, Маркет, Дзен, Плюс, Яндекс Банк, Кинопоиск, Драйв, Мессенджер.
- Абсолютно ВСЕ конкурентные браузеры: Google Chrome (включая Beta/Dev/Canary), Mozilla Firefox, Opera (Mini/Beta/Touch), DuckDuckGo, Vivaldi, Samsung Internet, UC Browser, Via, Mi Browser.
- Все популярные мессенджеры и соцсети: Telegram, WhatsApp (+ Business), Viber, VKontakte, Instagram, Twitter, Reddit, Facebook (+ Lite/Messenger), ICQ, OK.ru.
- Все почтовые клиенты: Gmail (+ Lite), Mail.ru, Outlook, Spark, MyMail, Yahoo Mail, Samsung Email, BlueMail.
- Измерители аудитории и трекеры: Mediascope AppMeter (com.cifrasoft.mpm.mediascope.appmeter) - главная российская система панели аудитории и телеизмерений.
Полный список:
Пытаясь втихую обойти приватность Android 11+, Яндекс сам же выдал себя: захардкодив в <queries> сторонние браузеры, мессенджеры и Mediascope, они открыто выложили доказанный факт целенаправленного шпионажа за пользователем - были бы там только банки и сами Yandex-приложения, вопросов бы не было.
REMOTE CONFIG (70+ ФЛАГОВ)
Приложение управляется с сервера. Сервер может включить сохранение карт, форсировать Алису, отложить запрос разрешений на 3 года, включить pre-trigger на полный буфер, отключить валидацию TLS.
Все 70+ флагов:
Для контекста
Remote config - это стандартная технология. Но набор флагов говорит сам за себя. Это не A/B-тестирование кнопок. Это удалённое управление механизмами слежки и разрешениями. Сервер Яндекса может раздать разный набор слежки разным пользователям - одним 3 секунды pre-trigger, другим 30, третьим off.ИТОГИ
Давайте подведём цифры того, что нам удалось раскопать ( многое в статью не влезло, но я подведу итоги того что будет в 2/3 частях ) :- 60+ механизмов слежки (из них 11 критических и 38 высокого риска).
- 387+ сетевых эндпоинтов, 1500+ JNI-точек, 94 JavaScript Bridge API, 587 доменов.
- Звук вокруг вас - ещё до того, как вы произнесли «Алиса» (через pre-trigger буфер).
- Звонки и контакты - через ContentObserver адресной книги.
- Локацию - через сканирование Wi-Fi сетей, GPS и триангуляцию по сотовым вышкам.
- Окружение - полный список ваших приложений (банки, VPN, мессенджеры).
- Платежи - данные карт (PAN/CVV) до токенизации.
