CVE-2019-2215 в ритейле: практический разбор уязвимости Use-After-Free для парка Android-устройств
По данным Habr, исследователь детально разобрал эксплуатацию уязвимости ядра Android CVE-2019-2215, показав путь от реверс-инжиниринга драйвера камеры до получения root-прав через Use-After-Free в подсистеме камеры Qualcomm. Для российского ритейла, эксплуатирующего тысячи Android-устройств на старых версиях ОС, это не академический разбор, а прямой сценарий компрометации кассовых терминалов, ТСД и прайс-чекеров с последующим нарушением 152-ФЗ.
Что произошло
Речь идёт об уязвимости Use-After-Free в драйвере камеры Qualcomm (msm), которая затрагивает широкий спектр устройств на базе Android, включая линейки Nexus и Pixel, а также множество OEM-устройств. Суть проблемы — в некорректном управлении жизненным циклом объекта struct video_device внутри ядра при обработке специфических ioctl-вызовов от непривилегированного пользователя. После освобождения памяти и повторного обращения к ней атакующий может добиться выполнения произвольного кода в контексте ядра. Для эксплуатации требуется локальный доступ к устройству и возможность запускать нативный код, что в ритейле достигается через вредоносное приложение, установленное на ТСД или планшет, либо через физический доступ недобросовестного сотрудника. Исследовательский отчёт на Habr подробно описывает этапы: анализ патча, сборка ядра с отладочными символами, поиск уязвимого кода, написание эксплойта для стабильного вызова Use-After-Free и повышение привилегий до root через перезапись указателей в функциях ядра.
Почему это важно
Для ритейл-компании с парком в несколько тысяч Android-устройств (кассы самообслуживания, мобильные терминалы сбора данных, планшеты для инвентаризации) CVE-2019-2215 — это не просто «уязвимость в ядре», а вектор для полного захвата устройства. Если злоумышленник получает root на ТСД, он может:
- Перехватывать данные: внедрить кейлоггер на уровне ядра для кражи логинов/паролей кассиров, данных банковских карт (даже при использовании пин-пада, если есть уязвимости в интеграции), а также скриншоты экранов с персональными данными клиентов, что является прямым нарушением 152-ФЗ.
- Обходить MDM: отключить или удалить агент MDM, заблокировать сетевые порты, используемые для управления, и сделать устройство «невидимым» для центральной консоли. Это сводит на нет все инвестиции в систему управления.
- Обеспечить персистентность: прошить вредоносное ПО в системный раздел, которое переживёт даже Factory Reset, делая полную перепрошивку единственным способом очистки.
Масштаб риска усугубляется тем, что CVE-2019-2215 эксплуатировалась в реальных цепочках поставок (exploit chains). Многие устройства в ритейле работают на Android 8/9/10 с ядром ветки 3.18 или 4.4, где патчи безопасности выходили нерегулярно, а производители (особенно noname-поставщики ТСД) часто не предоставляют OTA-обновления. Ситуация осложняется, если вы используете устройства, сертифицированные для работы с ЕГАИС или маркировкой «Честный ЗНАК»: их прошивки часто заморожены на конкретной версии ОС ради стабильности драйверов сканеров ШК, и обновление ядра невозможно без полной смены парка. Аналогичный риск несёт уязвимость в компоненте Stagefright, но CVE-2019-2215 опаснее, так как даёт полный контроль ядра, а не только пользовательского контекста.
Что делать
Вместо общих рекомендаций «обновляйте ОС» необходим конкретный план действий в рамках MDM-стратегии, разделённый на экстренные и системные меры.
1. Аудит парка и сегментация. Через API вашего MDM (или выгрузку из /docs/scim) необходимо составить матрицу устройств: модель, версия ОС, версия ядра (uname -r), наличие драйверов Qualcomm. Устройства с подтверждённой уязвимостью (например, старые Nexus, используемые как тестовые, или специфические ТСД) должны быть немедленно изолированы в отдельный Wi-Fi VLAN без доступа к серверам 1С, банковским шлюзам и ПДн.
2. Блокировка вектора на уровне MDM-политик. Если обновление ОС невозможно, нужно закрыть возможность эксплуатации.
- Запрет установки из неизвестных источников: политика
INSTALL_NON_MARKET_APPS=false. Это базовый шаг, отсекающий установку вредоносного APK. - Контроль разрешений: отозвать у всех приложений, кроме системных, разрешение
android.permission.CAMERAна уровне MDM (Runtime Permission Policy). Если приложению ТСД не нужна камера для работы, она должна быть жёстко заблокирована. Это не закроет уязвимость в драйвере, но не даст вредоносному коду инициировать нужные ioctl-вызовы. - Блокировка ADB и отладки: политика
ADB_ENABLED=0. Эксплуатация многих локальных уязвимостей требует включённой отладки или хотя бы возможности подключения по ADB для первичной разведки.
3. Технические контрмеры на устройстве. Для критичных устройств, которые нельзя обновить, но которые должны остаться в работе:
- Проверка прав доступа к /dev/msm_camera. Убедитесь, что права на узел камеры ограничены. В терминале (через ADB, если он разрешён для администрирования) выполните:
ls -l /dev/msm_camera*. Группа должна бытьsystemилиcamera, но неeveryone. MDM может принудительно применять скрипты черезrun-asдля коррекции прав, если производитель прошивки их сбрасывает. - Использование SafetyNet/Play Integrity API. Настройте в MDM политику Compliance, которая блокирует доступ к корпоративным ресурсам (Wi-Fi, VPN), если
ctsProfileMatchилиbasicIntegrityвозвращаютfalse. Это не панацея против рутованных устройств, но отсечёт примитивные эксплойты.
4. Управление обновлениями и жизненным циклом.
- Поиск кастомных патчей: обратитесь к вендорам ваших ТСД (АТОЛ, Эвотор, Штрих-М и др.) с запросом на наличие патчей ядра для CVE-2019-2215. Иногда они поставляются в виде отдельного ZIP-файла для прошивки через Recovery, минуя полный апдейт ОС. Документацию по процессу ищите в /docs/ или на порталах поддержки вендоров.
- План вывода из эксплуатации: для устройств на Android 7 и ниже, где патчей не будет никогда, необходимо утвердить график замены. Стоимость компрометации одной кассы (штрафы Роскомнадзора по 152-ФЗ, репутационные потери) превышает стоимость нового терминала. При расчёте бюджета на следующий год используйте калькулятор на /pricing для оценки TCO старого и нового парка.
- Переход на доверенные ОС: при следующей закупке ТСД включайте в ТЗ требование поддержки Android Enterprise Recommended и регулярных обновлений безопасности. Рассмотрите отечественные защищённые ОС, такие как Аврора, для некритичных сценариев (инвентаризация), где не требуется специфический софт — сценарии миграции описаны в /docs/aurora.
5. Мониторинг аномалий. Настройте в MDM алерты на следующие события, которые могут косвенно указывать на эксплуатацию уязвимости или попытку закрепиться:
- Внезапное исчезновение MDM-агента из списка установленных приложений.
- Появление новых системных пакетов или изменение контрольных сумм критичных библиотек (
/system/lib/hw/camera.qcom.so). - Необычный исходящий трафик с портов, не используемых бизнес-приложениями (например, IRC, Tor).
Источник: https://habr.com/ru/articles/1104346/
---
Источник: https://habr.com/ru/articles/1104346/?utm_campaign=1104346&utm_source=habrahabr&utm_medium=rss