Безопасность и лучшие практики

[android_roman]

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

Как ADB вообще решает, кому доверять:
Начиная с Android 4.2.2 каждое подключение проходит проверку по RSA. При первом запуске демона на хосте adb генерирует пару ключей 2048 бит. Публичный ключ отправляется на устройство, и там появляется диалог "Разрешить отладку по USB?" с отпечатком (SHA-256) этого ключа и чекбоксом "Всегда разрешать с этого компьютера". Если поставить галочку, публичный ключ запоминается на устройстве навсегда, и диалог больше не появляется. Без подтверждения устройство отвечает статусом unauthorized.

Код: Выделить всё

adb devices
List of devices attached
RF8M30XXXXX     unauthorized

Если видите unauthorized, посмотрите на экран телефона, диалог ждет вашего ответа. Если диалога нет, дерните отладку выключателем в "Параметрах разработчика" или переподключите кабель.

RSA-ключи: где лежат, какие права, как ротировать:
На хосте ключи хранятся в домашнем каталоге пользователя.

Код: Выделить всё

ls -l ~/.android/adbkey ~/.android/adbkey.pub
-rw-------  1 user  user  1675  adbkey
-rw-r--r--  1 user  user   717  adbkey.pub

Приватный ключ adbkey обязан быть доступен только владельцу. Если права слишком широкие, поставьте 600.

Код: Выделить всё

chmod 600 ~/.android/adbkey

На Windows путь %USERPROFILE%\.android\adbkey, на macOS и Linux это ~/.android/. Перенос ключа на другую машину означает перенос доверия: скопировав adbkey, вы получите доступ ко всем устройствам, где этот ключ уже авторизован, без повторного диалога. Поэтому к приватному ключу относитесь как к SSH-ключу, не кладите его в git, не таскайте по флешкам.

На самом устройстве авторизованные публичные ключи лежат в /data/misc/adb/adb_keys, по одному на строку. Прочитать файл можно только с root.

Код: Выделить всё

adb shell su -c 'cat /data/misc/adb/adb_keys'
QAAAAB...== user@host

Сгенерировать пару вручную (например, для CI-агента с отдельным ключом) умеет сам adb:

Код: Выделить всё

adb keygen ./ci_adbkey

Подключить дополнительные ключи без перезаписи основного помогает переменная окружения:

Код: Выделить всё

export ADB_VENDOR_KEYS=/secure/ci_adbkey
adb kill-server && adb start-server

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

Код: Выделить всё

rm ~/.android/adbkey ~/.android/adbkey.pub
adb kill-server
adb start-server

На устройстве старое доверие сбрасывается в "Параметрах разработчика" пунктом "Отозвать разрешения для отладки по USB". Это очищает adb_keys, и при следующем подключении любой компьютер снова получит диалог подтверждения. Делайте это перед продажей телефона или после того, как подключались к чужому ПК.

Чем опасна включенная отладка на личном устройстве:
USB-отладка снимает часть защит. Если кто-то получил физический доступ к разблокированному телефону с уже авторизованным ключом, он через adb вытащит данные, поставит APK, прочитает буфер обмена. Даже на заблокированном экране сценарий "always allow" опасен: ключ-то уже доверен. Поэтому простое правило: держите "Отладку по USB" выключенной, включайте только на время работы. Сбросить список доверенных компьютеров стоит после визита в сервис или подключения к незнакомому ПК. Подключение к публичной зарядке с передачей данных (так называемый juice jacking) частично гасится тем самым диалогом авторизации, но если вы один раз нажали "всегда разрешать" на чужом порту, защита снята.

Защита от несанкционированного ADB по сети:
Команда adb tcpip переводит демон в режим прослушивания TCP-порта на всех интерфейсах.

Код: Выделить всё

adb tcpip 5555
restarting in TCP mode port: 5555

С этого момента любой в той же сети может постучаться на порт 5555. RSA-аутентификация при этом сохраняется, но беда в том, что на многих кастомных прошивках, TV-боксах и IoT-железе классический adbd по TCP оставляют без проверки ключей. Именно так в 2018 году червь ADB.Miner находил десятки тысяч устройств с открытым 5555 наружу и ставил майнеры. Вывод простой: не выставляйте 5555 в интернет, не оставляйте tcpip-режим включенным.

Выключить TCP-режим и вернуться на USB:

Код: Выделить всё

adb usb
restarting in USB mode

Жестко закрыть порт можно через системное свойство (нужен root или adb shell), после чего перезапустить демон:

Код: Выделить всё

adb shell setprop service.adb.tcp.port -1
adb shell stop adbd
adb shell start adbd

В Android 11 и новее есть нормальная "Беспроводная отладка". Она работает по TLS и требует разового сопряжения с шестизначным кодом, порт при этом случайный, а не фиксированный 5555.

Код: Выделить всё

adb pair 192.168.1.50:37145
Enter pairing code: 681924
Successfully paired to 192.168.1.50:37145 [guid=adb-...]
adb connect 192.168.1.50:39555

Порт сопряжения (тот, что в pair) и порт подключения (в connect) разные, оба видны на экране устройства в разделе беспроводной отладки. Этот механизм безопаснее tcpip, пользуйтесь им. И в любом случае работайте только в доверенной сети, на публичном Wi-Fi отладку по сети не поднимайте.

ADB для пентеста: легальные векторы:
ADB полезен при анализе защищенности своего приложения или устройства, на которое у вас есть письменное разрешение. В России несанкционированный доступ к чужой информации это статья 272 УК РФ, так что границу "только свое или по договору" не переходите. Что можно делать легально и с пользой для обороны.

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

Код: Выделить всё

adb shell dumpsys package com.example.app | grep -A2 -i "exported=true"

Проверить, не собрано ли приложение в debuggable-режиме (если да, к его данным можно подобраться через run-as без root):

Код: Выделить всё

adb shell run-as com.example.app ls files/
shared_prefs  databases  cache

Если run-as отвечает "package not debuggable", это хорошо, релизная сборка закрыта. Посмотреть запрошенные разрешения и оценить избыточность:

Код: Выделить всё

adb shell dumpsys package com.example.app | grep -i permission

Все это про поиск своих же дыр до того, как их найдет кто-то другой, документируйте находки и чините.

Безопасное хранение и передача файлов:
push и pull по USB идут по кабелю и локальны, но по классическому TCP (tcpip) трафик не шифруется, в одной сети его можно перехватить. Беспроводная отладка Android 11+ шифрует канал TLS, поэтому для сетевых передач предпочитайте именно ее.

Код: Выделить всё

adb pull /data/local/tmp/report.bin ./report.bin
/data/local/tmp/report.bin: 1 file pulled. 12.3 MB/s (524288 bytes in 0.041s)

Не складывайте секреты в /sdcard, этот раздел читается множеством приложений с разрешением на хранилище. Для временных данных используйте /data/local/tmp, он принадлежит shell. После работы подчищайте за собой:

Код: Выделить всё

adb shell rm /data/local/tmp/report.bin

Целостность переданного проверяйте контрольной суммой на обеих сторонах, sha256sum входит в toybox современных Android:

Код: Выделить всё

adb shell sha256sum /data/local/tmp/report.bin
9f2c... /data/local/tmp/report.bin
sha256sum ./report.bin
9f2c... ./report.bin

Совпали суммы, значит файл доехал без искажений. Старый adb backup для извлечения данных приложений в свежих Android урезан и ненадежен (про него подробно в главе про резервное копирование), для разовых задач надежнее адресный pull нужных файлов.

Частые ошибки:
Видите unauthorized и грешите на кабель, а на экране висит непринятый диалог. Скопировали adbkey на другую машину и удивляетесь, что устройство пускает без вопросов, это и есть перенос доверия. Включили adb tcpip 5555 для удобства и забыли выключить, порт остался слушать после ухода из дома. Передали файл по сети в tcpip-режиме и думаете, что это приватно, нет, шифрования там нет. Держите отладку выключенной по умолчанию, ключи под правами 600, а сетевую отладку только через pair по TLS, и большая часть рисков снимается сама.

[CephMaster]

Про ротацию вопрос. Удалил ~/.android/adbkey и сделал kill-server, новый ключ создался. Но устройство теперь снова unauthorized на КАЖДОМ подключении, диалог не запоминается даже с галочкой. Это нормально или я что-то сломал? UPD разобрался, на телефоне до этого был старый ключ в always allow, после Отозвать разрешения все стало ок

[overclockedcoredump]

на многих кастомных прошивках, TV-боксах и IoT-железе классический adbd по TCP оставляют без проверки ключей

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

[rust4]

а если беспроводной отладки нет в меню (android 9), как тогда безопасно по сети работать? только tcpip 5555 получается, а вы пишете что он не шифрует. Через ssh-туннель на телефоне без рута никак ведь

[luyda]

уточнение по run-as: он работает не только если приложение debuggable, но еще нужно чтобы adb shell был запущен под shell-юзером и пакет был установлен для текущего пользователя. На рабочем профиле иногда отвечает unknown package хотя приложение видно в pm list, ловил такое на корпоративном телефоне с MDM