Pull to refresh

Comments 14

Благодарю. Прочитал на одном дыхании. Узнал много для себя нового. Большая работа конечно стоит за этой статьей. Очень интересно. Надеюсь не последняя статья.
Еще вот мысли по этому поводу. Сейчас в Казахстане идет активная дискуссия, была вернее. О том, чтобы отменить для многих госуслуг ЭЦП, и сделать авторизацию на базе CMC.
За ЭЦП высказываются что это более надеждный вариант. ЭЦП можно сравнить с печатью. Вот только печать мне кажется сложнее украсть, чем ключ ЭЦП. Тем более ЭЦП в 99,9% имеет стандартный пароль.

Все таки, я бы побоялся действительно важные процессы, такие например как купля\продажа частной собственности и другие значимые услуги закреплять ЭЦП, с учетом как «относительно легко» можно украсть эту «печать».
Через меня проходили контейнеры ЭЦП юридических лиц и отделов администрации города, у всех стандартный пароль. В купе с дырявой настройкой удаленного администрирования это дает злоумышленникам фантастические возможности.
Пока услуг не густо, данные проще найти в даркнете. Но если ЭЦП позволит закреплять куплю/продажу, наступит коллапс.
Благо, грамотных людей в Казахстане не густо, особенно среди злоумышленников.

Статья отличная, написана понятным языком даже для "чайника". Жаль, что подавляющее большинство пользователей смартфонов и ПК подобные статьи не читают, а ведь, именно они становятся жертвами хакеров.

написана понятным языком даже для «чайника»

Вот это я считаю высший пилотаж, как сказал Энштейн «You do not really understand something unless you can explain it to your grandmother.»
3. Подключение к незнакомому компьютеру по USB, с включенным режимом отладки.

Начиная с KitKat, каждый компьютер, пытающийся установить соединение по ADB, надо авторизировать на самом девайсе. Т.е. убрали дыру.

Ситуация с READ_EXTERNAL_STORAGE, конечно, удручающая. А все потому, что Гугель не догадался сделать разделение на «Общие файлопомойки» и «Папки программы». Некоторые подвижки в этом плане были в КК, но реализован был через запрет на доступ к карте памяти, что очень неудобно.

Вы можете подключииь телефон и оставить его без присмотра разблокированным. Злоумышленник нажмет "ОК". Либо обычный юзер, увидев непонятное окно, нажмет "ОК". Я лишь попытался собрать все вектор, хоть этот и трудновыполнимый.

Ситуация вообще довольно печальная с этим всем.
Еще во времена 4.x (и отчасти даже раньше) было несколько типов хранилища:


  • /data/data/<package_name> (0)
  • /sdcard/Android/data/<package_name> как External...Dirs (1)
  • /sdcard/Android/obb/<package_name> как ObbDirs (2)
  • /sdcard/ (и до 4.4 внешние носители) как внешнее хранилище (3)

В сущности правильным поведением было хранить данные в (0), допустимым в (1) и нежелательным (кроме как для медиафайлов и всего, что необходимо выставлять пользователю) в (3).
Но почему-то многие разработчики упорно не следуют этому и хранят кэши в /sdcard/.appname или даже /sdcard/Appname/...Cache, что отчасти и вызывает описанные уязвимости.


В 4.4 из (3) убрали внешние карточки и флешки, переведя доступ к ним на запись с линуксового на уродливый SAF, так что разработчикам всяких галерей и файловых менеджеров пришлось добавлять прямо в приложения инструкции по разрешению доступа к карточкам памяти.


В Q Google пытаются расширить эту модель и на /sdcard, что, пожалуй, имеет плюсы в том, что лишний мусор из /sdcard/ исчезнет, да и разруливать доступ к чувствительным файлам (не из числа фото/видео/аудио) станет проще.
Однако часть проблем с MitD решить не удастся: для работы с любыми другими файлами (pdf, книги, специфичные форматы в т.ч. сертификаты, ЭП) приложения будут обоснованно требовать доступ к /sdcard через SAF, а значит загрузки (те же упомянутые ЭП и сертификаты) все равно останутся под риском перезаписи.


Гораздо печальнее, что это ещё больше удаляет Android от человека, желающего действительно владеть собственным устройством.
Потеряется:


  • Доступ без рута к ряду служебных файлов приложений (может быть полезен)
  • Отвалятся приложения с работой с файлами на системных вызовах
  • Как подмножество предыдущего отвалятся CLI-инструменты, работающие под эмулятором терминала или Termux
  • Могут появиться прецеденты хранения документов в /data/data на манер iOS, что очень больно.

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

Проблема еще в том, что если еще сильнее дифференцировать разрешения, то их станет настолько много, что пользователю неудобно будет кликать огромное количество раз, после установки каждого приложения. Возможно, Google останавливает и это.
> «А далее расшифровать с помощью любого доступного скрипта в сети.»
Что? Как вы видите, расширение у этих файлов .crypt12, они зашифрованы (говорю по памяти) AESом на ключе, лежащем как раз в Internal Storage.

> «А если поставить whatsapp на рутованый телефон, то все ваши переписки хранятся в открытом виде. Видимо whatsapp не считает нужным даже использовать шифрование, на таком „порченом“ телефоне»
Да, Вотсап хранит в Internal Storage простую SQLite БД. Те же Телеграм и Вайбер (о ужас) тоже так делают! Это уже классический пример бесполезности защиты от рута. Если вы рут — то (как правило) смысл защиты ноль, можно хоть в памяти все это выдернуть. Есть конечно исключения, но это и система защиты должна быть соответствующая, и совсем другие затраты по труду/времени/ресурсам.
Спасибо, интересная статья, узнал много нового.
Я не писал для Андроид, не знаю как там устроено, поэтому прошу пояснить: ключ my-release-key.keystore выдаёт гугл как разработчику или самогенерённый?
Конкретно в статье — самосгенерированный. Keystore генерируется командой keytool -genkey
Only those users with full accounts are able to leave comments. Log in, please.