Чердачок Брюса Шнайера. Выпуск №3 “Алгоритмы и ключи”

Криптографический алгоритм (cryptographic algoritm), который также называется шифром (cipher), — это математическая функция, используемая для шифрования и расшифровки. Если безопасность алгоритма обеспечивается засекречиванием самого алгоритма, то он называется ограниченным (restricted). Такие алгоритмы уже давно не применяются. Причина вполне очевидна: если участник группы использующей этот алгоритм покидает группу, то группа вынуждена переходить на новый алгоритм.

Эту и другие проблемы ограниченных алгоритмов современная криптография решает с помощью ключей (keys), который обозначают буквой K. Ключ может быть любым значением выбранным из множества. Множество возможных значений ключа называют пространством ключей (keyspace). Этот ключ используется и при шифровании, и при расшифровке. В формулах он выглядит как индекс K у функций шифрования/расшифровки:

Ek(M) = C

Dk(С) = M

При этом должно выполняться следующее равенство:

Dk(Ek(M)) = M

В некоторых алгоритмах при шифровании и расшифровке используются разные ключи. В этом случае выполняются такие соотношения:

Ek1(M) = C

Dk2(C) = M

Dk2(Ek1(M)) = M

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

Полезно ввести еще одно понятие - криптосистема (crytosystem). Это алгоритм и все возможные открытые тексты, шифротексты и ключи.

#ЧБШ

Всем привет!

29.10.2020 буду записываться в подкасте @android_broadcast, где планируем поговорить о безопасности Android приложений (о чем же еще…). В рамках выпуска попробуем составить “руководство по безопасности” для android-разработчиков. Упор сделаем на “бесплатную реализацию”, т.е. своими силами. Но также затронем вопросы постороннего вмешательства в построение безопасной разработки =)
Примерный список тем для обсуждения выглядит так:
- Основные ошибки, которые допускают разработчики
- SAST
- Как убедиться в безопасности своего приложения
- Практики безопасной разработки
- Как защитить приложение если первый этаж опять затопило деньгами и надо куда-то их деть

https://www.youtube.com/watch?v=x_COvmEIyko

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

https://github.com/Magpol/decrypt-calculatorPlusApk

​​Чердачок Брюса Шнайера. Выпуск №4 “Симметричная криптография”

Существуют два основных типа алгоритмов, основанных на использовании ключей: симметричные алгоритмы и алгоритмы и алгоритмы с открытым ключом.

Симметричные алгоритмы (symmetric algorithms) иногда называют условными (conventional). Это алгоритмы, в которых ключ шифрования может быть вычислен по ключи расшифровки, и наоборот. В большинстве симметричных алгоритмов ключи шифрования и расшифровки совпадают. Эти алгоритмы, также называемые алгоритмами с секретным ключом (secret-key algorithms) или алгоритмами с единственным ключом (signle-key algorithms), требуют, чтобы отправитель и получатель согласовали ключ до начала передачи секретных сообщений. Безопасность симметричного алгоритма зависит от ключа. Шифрование и расшифровка с использованием симметричного алгоритма записывается так:

Ek(M) = C,

Dk(C) = M.

Симметричные алгоритмы подразделяют на две категории. Одни алгоритмы обрабатывают открытый текст побитово (иногда побайтово). Они называются потоковыми алгоритмами (stream algorithms) или потоковыми шифрами (stream ciphers). Другие обрабатывают биты открытого текста по группам. Группы битов называются блоками (blocks), а алгоритмы — блочными алгоритмами (block algorithms) или блочными шифрами (block ciphers). В современных компьютерных алгоритмах типичный размер блока составляет 64 бита — достаточно большое значение, чтобы предотвратить анализ, и в то же время достаточно небольшое для удобной работы.

#ЧБШ

Появились видео с Android Summit 2020, который прошел в начале октября. Я как-то пропустил это событие, а там есть что посмотреть. По "нашей теме" там 4 видео, что в общем-то редкость для таких мероприятий:

Practical security for Android apps - новички традиционно найдут для себя много полезных практических советов о том как делать безопасные приложения в 2020, а зубастые (и бородатые) security-специалисты ничего нового не найдут, зато получат видео на которое можно посылать новичков или надергать советов, которые потом можно выдать за свои 😉

Modern security for Android Developers - совсем уж прописные истины, о которых не говорил только ленивый. Да и все ленивые кажется тоже давно уже расшевелились и сказали. Новичкам стоит это смотреть на х2 с целью накопать каких-нибудь недостающих знаний, всем остальным можно не смотреть.

Modern Android Hacking - хороший доклад с довольно нудным вступлением (первые 10 минут можно смело пропустить). Рассмотрены случаи перехвата данных из буфера обмена, "угона" интентов (**intent hijacking**) и злоупотребления возможностями доступности (**accessibility abuse**). Советы по защите от рассмотренных векторов атак также прилагаются.

Defending Your Users - не слишком технический, но от этого не менее интересный доклад о комплексном подходе к обеспечению безопасности мобильных приложений. Лейтмотивом доклада является мысль, о которой часто забывают - безопасность приложения, это не только крутые защиты реализованные в вашем исходном коде. Рекомендую к просмотру.

Совсем недавно, ребята из CheckPoint опубликовали информацию об уязвимости в Google Play Core Library. Там вполне себе LCE, которое можно осуществить в любом приложении использующем уязвимую версию библиотеки. Марк Мерфи (Mark Murphy) подсуетился и показал как проверить свое собственное приложение на наличие уязвимой версии GPCL. И да, вы можете не знать, что используете ее, т.к. другие библиотеки от гугла вполне себе ее используют, а вы используете эти библиотеки. Такие дела.

Проверить свое приложение довольно просто:

./gradlew app:dependencies | fgrep "com.google.android.play:core"

- Если ничего не нашлось, то все хорошо
- Если нашлось, но версия библиотеки 1.7.2 или выше, то все хорошо
- Если нашлась более старая версия библиотеки - у вас большие проблемы. Готовьтесь выкатить force update.

Вариантов решения проблемы два:

1. Прописать в build.gradle явную зависимость от GPCL старше 1.7.2 (актуальная версия на момент написания этих строк - com.google.android.play:core:1.9.0). В этом случае библиотеки, которые зависят от GPCL будут использовать ее более новую версию. Однако, стоит помнить, что они могут быть завязаны на какой-то старый функционал, которого нет в новых версиях и все взорвется. Будьте бдительны!
2. Прекратить использование уязвимой версии библиотеки полностью до тех пор пока не появится возможность перейти на более безопасную ее версию.

#google #bug

https://commonsware.com/blog/2020/12/04/seeing-app-play-core-vulnerability.html

До того как я узнал про сайты вроде APKPure/APKMirror, я пользовался своим скриптом для извлечения apk-шек с девайса. Он позволял по имени пакета или его части найти приложение и сохранить его для дальнейшего изучения. Скрипт не делал ничего космического, это просто две ADB команды помазанные сверху регуляркой. С недавних пор, для некоторых приложений на сайтах-аггрегаторах пропала возможность скачивать "голый" apk. Причина в App Bundle-aх конечно же. Ну и видимо в каком-то желании этих аггрегаторов пихать всем свои всратые инсталяторы. Именно поэтому я собрался с силами, раскопал свой старый скрипт на питоне, переписал его на Go и выложил в паблик. Может кому-то пригодится.

Как всегда буду признателен за обратную связь и bug/feature реквесты.

https://github.com/Android-Guards/apk-extractor

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

https://www.youtube.com/watch?v=LpOvHhpcVG4

Весь код, который показывал на стриме можно взять тут: https://github.com/Android-Guards/storing-api-keys

Почистил видос от косяков, добавил тайминг и перезалил. Теперь можно шарить, ссылка железобетонная

https://youtu.be/Xn6CSqJpf6I

Хочу немного затронуть тему лицензирования в вопросах информационной безопасности. Вопрос и простой и сложный одновременно. Простота его заключается в том, что вы всегда должны смотреть на лицензии библиотек, которые затаскиваете в свое приложение. И тут начинаются сложности. Не всегда без юриста можно разобраться в нюансах той или иной лицензии. Но даже не привлекая юриста, можно попробовать сделать какие-то первоначальные выводы на основании подсказок, которые дает GitHub. Рассмотрим это на примере двух библиотек, которые делают одно и тоже: реализуют биндинги к нативной библиотеке для вычисления хэша Argon2.

Первая библиотека называется argon2kt и распространяется под лицензией MIT, вторая называется еще более незамысловато - Argon2 и выложена под лицензией GPL-3.0. Если не смотреть на лицензии, то нужно выбирать вторую, т.к. ее написали ребята из Signal (защищенный мессенджер, если кто не в курсе). Уж они то знают толк! Не то, что какой-то ноу-нейм! При более трезвом рассмотрении вопроса, мы узнаем, что лицензия MIT не накладывает никаких ограничений на использование, в т.ч. может применятся в проприетарном ПО без раскрытия исходного кода или его кусков. GPL-3.0, в свою очередь требует раскрытия исходников (см. секцию Conditions тут), что не очень то подходит для проприетарного ПО, которые вы чаще всего пишите.

При этом ответ на вопрос "А за мной точно придут?" звучит как "хз". Может да, может нет. Но если да, то будет очень плохо =) Поэтому взвешивайте риски и будьте умницами.

Хочу вам рассказать про одну простую, но показавшуюся мне интересной защиту приложений. Берем какую-нибудь нативную библиотеку с открытыми исходниками, которую будет активно использовать приложение и добавляем в логику ее работы логику нашей защиты. Например можно добавить проверку на модификацию приложения или что-нибудь еще. При срабатывании проверки тихо убиваем процесс. Лучше если это будет происходить не сразу, а через какое-то время, в идеале не фиксированное. Например можно добавить разброс от 1 до 5 минут.

В результате получаем логическую бомбу, которую не так просто обнаружить сходу. Почему? А вот представьте себе большое обфусцированное приложение, в котором есть несколько нативных библиотек (одна из которых "генномодифицированная") при этом само приложение содержит еще несколько защит. Возможно дублирующих (проверка на модификацию приложения).

А с чем интересным сталкивались вы? Делитесь в комментариях.

Многие из вас используют JADX и наверняка видели там функцию экспорта декомпилированных исходников в виде Gradle проекта. Мне эта функция всегда не нравилась, потому что она экспортировала проект в старом формате и проще был ей не пользоваться чем постоянно исправлять результат этого экспорта. В какой-то момент я нашел в себе силы и решил "все пофиксить". И пофиксил =) А еще закинул PR в основной репозиторий и его уже приняли. Так что если кому-то этой штуки не хватало, то теперь она у вас есть.

https://github.com/skylot/jadx/pull/1097

Давно хотел сделать этот формат и похоже звезды сошлись. В этот четверг 04.02.2021 в 19:00 по MSK, запишем подкаст с Павлом Васильевым - android-разработчиком с большим интересом к информационной безопасности.

Я люблю ковыряться со всякими необычными интерфейсами, работал в андроиде с NFC, Bluetooth, USB. Работал с разными бесконтактными карточками, кассовыми аппаратами на android, работал с аппаратными модулями безопасности.

Павел пишет статьи и выкладывает свои наработки на GitHub. Все ссылки будут в шоуноутах.

До встречи в эфире!

https://youtu.be/a4ewiusM1f8

UPD: Перезалил подкаст в аудиоформате. Видео в этот раз не получилось. Будет в следущий. Чуть позже раскатаю еще на всякие площадки чтобы можно было слушать в плеере.

Вышла статья от Паши Васильева, с которым мы общались недавно в подкасте.

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

Как говорил ранее - рекомендую прочитать ее всем, независимо от вашего уровня. Она реально крутая.

https://habr.com/ru/post/541190/

Сам выпуск, в котором обсуждали эту статью уже доступен на различных подкаст площадках.

Google Podcasts - https://podcasts.google.com/feed/aHR0cHM6Ly9hbmNob3IuZm0vcy80YjMyODkxYy9wb2RjYXN0L3Jzcw==

Apple Podcasts - https://podcasts.apple.com/us/podcast/android-guards-community-podcast/id1552280775

Или поищите в своем плеере подкастов, возможно есть уже и там.

Google продолжает радовать неплохими документами. На этот раз они собрали хороший чеклист, по основным требованиям к качеству Android-приложений. Это не какое-то божественное откровение, просто хороший чеклист. Нас, как обычно, интересует "шо там по безопасности". Рекомендации (или требования) опять же довольно стандартные, но удобно, что собраны в одном месте и без воды (в отличие от этого сообщения).

Коротко, что имеем:

- Запрашивать как можно меньше разрешений
- Без крайней нужды не запрашивать разрешения на возможности, которые тратят деньги пользователя (SMS и звонки)
- Запрашивать разрешения в контексте функциональности, а не "на всякий случай" при старте приложения
- Объяснять пользователю зачем запрашиваете разрешения
- Вся конфиденциальная информация должна храниться только во внутреннем хранилище (internal storage)
- ПД и прочая конфиденциальная инфа не должна попадать в логи
- Не использовать хардварные идентификаторы, такие как IMEI для идентификационных целей
- Предоставлять подcказки для autofill фреймворка
- Интегрировать One Tap Sign-up/Sign-in
- Интегрировать биометрическую аутентификацию
- Экспортировать только те компоненты, которые должны делиться данными с другими приложениями
- Все интенты и бродкасты должны следовать лучшим практикам безопасности (почитайте по ссылке, там много)
- Все контент провайдеры, которые шарят данные между вашими приложениями должны использовать protectionLevel=signature
- Весь сетевой трафик отправляется только по SSL
- Должен быть настроен пиннинг через network security configuration
- Если приложение использует сервисы Google Play, то security provider нужно инициализировать при старте приложения
- Все библиотеки должны иметь актуальные версии
- В приложении не должно быть отладочных библиотек
- Не использовать setAllowUniversalAccessFromFileURL() в WebView для доступа к локальному контенту. Вместо него нужно использовать WebViewAssetLoader. На Android 6.0 и выше, вместо этого нужно использовать HTML message channels.
- Приложение не должно динамически загружать код (dex файлы) из внешних источников. Нужно использовать App Bundles.
- Приложение должно использовать лучшие криптографические алгоритмы и генераторы случайных чисел из доступных на платформе, а не реализовывать свои алгоритмы шифрования.

https://developer.android.com/docs/quality-guidelines/core-app-quality#sc

Я часто говорю про аутентификацию по pin-коду, но еще чаще я слышу вопросы на эту тему. При кажущейся простоте, тема весьма глубокая и неоднозначная. В четверг (18.02.2021) поговорим на эту тему максимально подробно и разберемся, какие есть проблемы у локальной аутентификации по короткому коду. Кроме очевидной теории, конечно же пощупаем это на практике! Взломаем pin-код реального приложения в прямом эфире и поговорим как улучшить текущую реализацию локально и с применением сервера.

https://youtu.be/Tpsau_jQK1U

⚡️ Вышла Developer Preview новой версии Android. По безопасности пока не густо, надеюсь еще что-нибудь подвезут к релизу. Пока имеем:

- Всем не системным приложениям запретят получение MAC адреса
- В некоторых случаях, система будет блокировать тач ивенты при перекрытиях одних приложений другими
- Приложениям запретят закрывать системные диалоги

Все подробности тут: https://developer.android.com/about/versions/12/behavior-changes-all#privacy

Еще одно важное изменение, которое ждет нас в Android 12 - явное указание экспорта для компонентов приложения. Проблема довольно известная - указанный <intent-filter> приводит к неявному экспорту компонента. Теперь Google призывает принимать решение в каждом таком случае отдельно. Станет чуть больше кода, но в остальном - явное всегда лучше неявного. А еще они обещают валить приложение с ошибкой при установке, если экспорты не будут прописаны явно 🤞 Прямо как Apple какой-то...

https://medium.com/androiddevelopers/lets-be-explicit-about-our-intent-filters-c5dbe2dbdce0

Запилил небольшой видос про реализацию биометрической аутентификации. Но не так, как вы обычно ее делаете, а с применением “новейших технологий”© С радостью почитаю вашу обратную связь по этому формату. Нужно ли его продолжать и как его преобразовать чтобы было лучше. Все материалы в описании под видео.

https://youtu.be/2DLP2te7gYQ