Вразливість Account Manager в Android, про яку необхідно знати

Вітаю тебе, дорогий читачу!
Багато програм використовують можливості Account Manager(AM) в своїх додатках. Так і з одного боку правильно роблять, адже цей інструмент дозволяє спростити деякі речі. Він дозволяє зберігати пароль, токен, та і в принципі будь-які рядкові дані юзера. Так само дозволяє автоматично оновлювати токен, якщо той стає тухлою, так і багато інших речей. Але у зручності цього є і інша сторона — безпека. З-за цього власне я і написав цей текст.

Раз AM дозволяє зберігати такі важливі дані як пароль і токен, то напевно він просто зобов'язаний це робити безпечно, адже якщо вони витечуть, то нічого доброго не вийде. Ви можете сказати, що на рутованих андроїд девайсах ніщо не зберігається безпечно, і я тут погоджуся. Проте якби все обмежувалося лише рутом, то не читати би вам це «твір». Щоб розповісти, заради чого ми тут зібралися, я почну з самого початку.


Взагалі для роботи з AM у додатку потрібно зробити кілька рухів і створити два компоненти — спадкоємця AbstractAccountAuthenticator та Service детальніше тут). Останній доведеться зареєструвати у маніфесті додатка таким чином
<service
android:name=".account.AuthenticatorService"
android:exported="false">
<intent-filter>
<action android:name="android.accounts.AccountAuthenticator" />
</intent-filter>

<meta-data
android:name="android.accounts.AccountAuthenticator"
android:resource="@xml/кодів" />
</service>

А ще, якщо ви помітили, то нам треба створити в ресурсах якийсь xml файл з іменем authenticator.xml. Хоча назва тут не важливо, а важливо вміст. Воно то і грає ключову роль розповіді. Виглядає файл всередині ось так
<account-кодів 
xmlns:android="http://schemas.android.com/apk/res/android"
android:accountType="@string/account_type"
android:label="@string/app_name" />

Параметр label — відповідає за назву в списку записів у налаштуваннях девайса, а саме цікаво несе в собі accountType. Без нього додаток не зможе додавати і отримувати акаунти. А ще з допомогою цього параметра можна перехопити акаунти іншого додатка навіть на девайсах без рута. Давайте подивимося, як це може статися.
На пристрої існує додаток А з accountType = «someType», це додаток створює акаунт, додає в нього токен, пароль та іншу інформацію. В один прекрасний момент на пристрій встановлюється додаток B з таким же accountType = «someType». І от якщо видалити додаток A, то всі створені акаунти перейдуть у владу програми B з повним доступом. Зворотне теж вірно, акаунти програми B передадуться додатком A, якщо видалити B.

приклад відео


Випереджаючи питання про підписи apk, це не залежить від того, яким ключем було підписано додаток, релізних або дебажным, передача відбудеться в будь-якому випадку. Жахливо, правда?
Все це можна виконати в плоть до API версії 23. Виправлено тільки з виходом андроїд 7.0(API 24). Засмучує в цій ситуації мізерно малий відсоток пристроїв з цією версією андроїда. До речі, я дізнався про цю проблему з доповіді з безпеки в андроїд. На жаль у тексті, переказі презентації, про це нічого немає взагалі, а ось відео про це згадали побіжно, не надавши особливого значення.

Так що ж ти пропонуєш? — можете запитати ви. А я пропоную вам два варіанти вирішення проблеми. Перший — продовжувати користуватися AM, але зберігати всі важливі дані в зашифрованому вигляді. Якщо ви перестали довіряти AM, можна продовжувати ним користуватися, але не зберігати важливі дані і скористатися AM в зв'язці з другим варіантом. Другий — взагалі відмовитися від РАНКУ і користуватися сховищем, яке можна шифрувати. Наприклад SQLite в зв'язці з sqlcipher або Realm, який підтримує шифрування з коробки. Я вибрав останній. Тут приклад для realm, де показано, як генерувати і зберігати ключ шифрування.

Приклади коду в статті наводити не став, так як в цьому немає сенсу. З исходниками жертви і перехоплювача ви зможете ознайомитися на гітхабі.
Спасибі за увагу!
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.