Как проверить .apk-файл на известные уязвимости через CVE-базу

Вы скачали APK не из Google Play — может, это старое приложение с форума, корпоративный клиент, который вам дали на работе, или модифицированная версия. Вопрос один: есть ли внутри известные уязвимости? Проверить это реально, и не обязательно для этого быть безопасником с десятилетним стажем. Разберём конкретный путь — от извлечения информации из APK до поиска по CVE-базам.

Что на самом деле нужно сделать

Идея проста: внутри APK-файла — набор библиотек, зависимостей и компонентов, каждый из которых имеет версию. Если версия известна, можно проверить её по базам Common Vulnerabilities and Exposures (CVE) — и понять, не затронута ли она уже найденными уязвимостями.

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

Шаг 1. Что можно вытащить из APK

APK — это ZIP-архив. Внутри лежит манифест, ресурсы, нативные библиотеки и — самое важное — файл classes.dex (или несколько), в котором находится скомпилированный код. Также внутри могут быть сторонние библиотеки: OkHttp, Retrofit, OpenSSL, FFmpeg, Firebase SDK и десятки других.

Для проверки на CVE нам нужны:

• Названия библиотек и их версии
• Версия используемых компонентов (например, версия OpenSSL, версия Chromium WebView)
• Информация из манифеста: разрешения, целевая SDK-версия

Версия библиотеки — это ключ. Без неё поиск по CVE бессмысленен.

Шаг 2. Инструменты для извлечения информации

APKTool — основной инструмент

APKTool декомпилирует APK обратно в читаемый формат. Установка и запуск:

1. Скачайте APKTool с официального сайта (ibotpeaches.github.io/Apktool/)
2. Выполните: apktool d app.apk -o output_dir
3. В выходной папке появится декомпилированный манифест, ресурсы и smali-код

Из манифеста вы получите список разрешений, используемые activity, а иногда и версии компонентов. Но главное — вы увидите структуру приложения.

Извлечение информации о библиотеках

После декомпиляции ищите в папке output_dir/res и output_dir/lib файлы библиотек. Нативные библиотеки (.so файлы) лежат в lib/ по архитектурам. Их названия часто содержат версии: libssl.so.1.1 — это OpenSSL 1.1.x.

Для Java/Kotlin-библиотек ситуация сложнее. Они упакованы в classes.dex, и нужно искать по строкам. Можно использовать:

• strings classes.dex | grep -i "okhttp\|retrofit\|firebase" — поиск по строкам в DEX-файле
• MobSF (Mobile Security Framework) — автоматизированный инструмент, который сам извлекает библиотеки и их версии
• Dependency-Check от OWASP — если вы можете получить исходный код или JAR-файлы

MobSF — самый удобный путь

Если не хотите делать всё вручную, запустите MobSF. Это веб-приложение, которое принимает APK, декомпилирует его, находит библиотеки, проверяет разрешения и даже ищет известные уязвимости.

Установка через Docker:

• docker pull opensecurity/mobile-security-framework-mobsf
• docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf
• Откройте http://localhost:8000 и загрузите APK

MobSF покажет список библиотек с версиями, разрешения приложения, hardcoded-секреты и потенциальные уязвимости. Это не замена полноценному CVE-поиску, но отличная отправная точка.

Шаг 3. Поиск по CVE-базам

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

Где искать

• NVD (National Vulnerability Database) — nvd.nist.gov — основная правительственная база США. Самая полная, но интерфейс неудобный для ручного поиска
• CVE Mitre — cve.mitre.org — справочник CVE-идентификаторов
• OSV (Open Source Vulnerabilities) — osv.dev — удобный API и веб-интерфейс, хорошо работает с зависимостями
• GitHub Advisory Database — github.com/advisories — уязвимости в открытом исходном коде, часто с патчами
• Snyk Vulnerability Database — security.snyk.io — коммерческая база с бесплатным доступом, хорошо структурирована

Как искать правильно

Просто вбить название библиотеки в поиск — недостаточно. Нужно искать с указанием версии или диапазона версий. Например:

• В NVD: OkHttp 3.12.0 — ищем конкретную версию
• В OSV: pkg:maven/com.squareup.okhttp3/okhttp@3.12.0 — формат Package URL
• В Snyk: вводите название библиотеки и фильтруйте по версии

Если вы не знаете точную версию, а знаете диапазон (например, OpenSSL 1.1.x), ищите все CVE, затрагивающие этот диапазон. В OSV можно указать диапазон версий прямо в запросе.

Шаг 4. Автоматизация проверки

Ручной поиск работает, но если библиотек двадцать — это утомительно. Есть инструменты, которые автоматизируют процесс.

OWASP Dependency-Check

Если у вас есть доступ к исходному коду или вы извлекли JAR-файлы из APK, Dependency-Check просканирует их и сверит с NVD.

• Скачайте с GitHub (jeremy-lin/dependency-check)
• Запустите: dependency-check.sh --scan ./lib_folder --format HTML
• Получите отчёт с найденными CVE и оценкой критичности (CVSS)

OSV-Scanner

Более современная альтернатива от Google. Работает с lock-файлами, но может сканировать и просто папки с зависимостями.

• Установите: go install github.com/google/osv-scanner/cmd/osv-scanner@latest
• Запустите: osv-scanner --docker ./output_dir

Сравнение инструментов

Инструмент	Что сканирует	Источник CVE-данных	Сложность настройки	Подходит для APK
MobSF	APK напрямую	NVD + собственные правила	Средняя (Docker)	Да
OSV-Scanner	Исходный код, lock-файлы	OSV.dev	Низкая	Частично
Dependency-Check	JAR, исходный код	NVD	Средняя	Частично
Snyk Code	Исходный код, контейнеры	Snyk DB	Низкая	Нет (только код)

Шаг 5. Что делать с результатами

Вы нашли CVE. Теперь важно понять, насколько это критично в вашем случае.

Смотрите на:

• CVSS-оценку — от 0 до 10. Выше 7 — критично, но не паникуйте раньше времени
• Вектор атаки — требуется ли локальный доступ или атака удалённая
• Эксплоит в дикой природе — проверьте на Exploit-DB (exploit-db.com), есть ли рабочий эксплоит
• Контекст использования — используется ли уязвимый код в вашем сценарии

Пример: вы нашли CVE-2023-36033 в OkHttp 3.14.9 — отказ в обслуживании при обработке повреждённого TLS-сертификата. Если ваше приложение не использует TLS-клиентские сертификаты и не обрабатывает ответы от непроверенных серверов — реальный риск низкий.

Частые ошибки при проверке

Ошибка 1. Проверять только название библиотеки без версии. CVE привязаны к конкретным версиям. «Уязвимость в OpenSSL» — бесполезная фраза без номера версии.

Ошибка 2. Игнорировать CVE с низким CVSS. Низкая оценка не значит отсутствие риска — иногда это неправильная оценка, иногда цепочка из нескольких низких даёт критическую уязвимость.

Ошибка 3. Не обновлять CVE-базы. Новые уязвимости появляются каждый день. Проверка по базе месячной давности — пропуск свежих CVE.

Ошибка 4. Считать, что если CVE нет — код безопасен. CVE-база содержит только известные уязвимости. Неизвестных там не будет по определению.

Ошибка 5. Не учитывать транзитивные зависимости. Библиотека A может быть безопасна, но она зависит от библиотеки B, в которой есть CVE. Проверяйте всю цепочку.

Как действовать в зависимости от вашей ситуации

Ситуация 1: Вы разработчик и хотите проверить свой APK

Используйте MobSF для быстрого сканирования. Затем запустите OSV-Scanner по исходному коду. Если нашли CVE — обновите зависимость до версии с патчем. Если патча нет — оцените риск и рассмотрите замену библиотеки.

Ситуация 2: Вы получаете APK от третьей стороны (вендор, подрядчик)

Попросите у поставщика SBOM (Software Bill of Materials) — список всех компонентов с версиями. Если не дают — извлеките сами через APKTool + MobSF. Проверьте по OSV и NVD. Включите требование об отсутствии критических CVE в договор.

Ситуация 3: Вы проверяете APK перед установкой на устройство

Запустите MobSF или загрузите APK в онлайн-сервис (например, Koodous или VirusTotal — они тоже показывают известные уязвимости). Если найдены критические CVE с рабочими эксплоитами — не устанавливайте.

Ситуация 4: Вы аудитор и вам нужен отчёт

Соберите все найденные CVE, отсортируйте по CVSS, добавьте контекст использования. Используйте Dependency-Check для генерации отчёта. Укажите, какие CVE эксплуатируемы в данном приложении, а какие — теоретически.

Практические рекомендации

• Всегда извлекайте версии библиотек — без них CVE-поиск бессмыслен
• Используйте минимум два источника CVE-данных (например, NVD + OSV) — они иногда расходятся в оценках
• Проверяйте транзитивные зависимости — уязвимость может быть в библиотеке третьего уровня
• Не останавливайтесь на найденных CVE — оцените реальный риск в контексте вашего приложения
• Если нашли критическую уязвимость — проверьте, есть ли эксплоит в открытом доступе (Exploit-DB, GitHub PoC)
• Документируйте результаты — список библиотек, версии, найденные CVE, оценка риска

Итог

Проверка APK на известные уязвимости — это не магия, а методичная работа: извлеките библиотеки и версии из APK (APKTool, MobSF), проверьте по CVE-базам (NVD, OSV, Snyk), оцените реальный риск. Автоматизируйте рутину через OSV-Scanner или Dependency-Check. Главное — не останавливаться на факте «CVE найден», а понимать, эксплуатируема ли уязвимость в вашем конкретном случае.

Начните с MobSF — он даст вам 80% информации за 15 минут. Дальше — ручная проверка по базам для тех библиотек, которые показались подозрительными.