Через 20 минут стартую стрим с вопросами новичков. Запасайтесь чаем или чем-то покрепче и присоединяйтесь.

Казалось бы, еще одна статья про биометрическую аутентификацию в Android... Но нет. В этой даются полезные пояснения по новым классам аутентификации, которые появились в Android 11.

#4developers #biometric

https://proandroiddev.com/biometrics-in-android-50424de8d0e

Стартую новую рубрику "Чердачок Брюса Шнайера" в ней буду писать всякое про криптографию и пробовать приземлять это на Android-реальность.

Выпуск №1 "Самые базовые понятия"

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

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

Сообщения принято называть открытым текстом(plaintext), а процесс маскировки сообщения называют шифрованием(encryption). Зашифрованное сообщение называется шифротекст(ciphertext), а процесс преобразования шифротекста обратно в открытый текст называеся расшифровкой(decryption)

Хозяйке на заметку: В соответствии со стандартом ISO 7498-2 в англоязычных текстах используются термины enchiper вместо encrypt и decipher вместо decrypt. Видимо, это объясняется тем, что в некоторых культурах термины encrypt и decrypt ассоциируются со словом crypt(склеп).

#ЧБШ

​​Чердачок Брюса Шнайера. Выпуск №2 "Основы криптографии"

Искусство и наука сокрытия сообщений называется криптографией (cryptography), а специалисты по криптографии называются криптографами (cryptographers). Их естественными "врагами" в дикой природе являются криптоаналитики (cryptoanalysts), которые занимаются искусством и наукой взлома шифротекстов - криптоанализом (cryptoanalysis). Отрасль математики, охватывающая криптографию и криптоанализ, называется криптологией (cryptology), а людей, которые ей занимаются - криптологами (cryptologist). Т.е. без хорошей математической подготовки тут никуда. Чтобы ты там себе на напридумывал %username%.

В криптографических формулах, открытый текст принято обозначать буквой M (message) или P (plaintext). Он может быть чем угодно, но в конечном итоге все сводится к набору битов. Шифротекст принято обозначать буквой C (chipertext), который тоже представляет из себя двоичные данные. Функцию шифрования обозначают буквой E, а функцию расшифровки буквой D. Таким образом, в математической форме основные формулы криптографии выглядят вот так:
E(M) = C - шифрование

D(С) = M - расшифровка

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

D(E(M)) = M

Если уже на этом моменте тебе стало ничего не понятно, то самое время сделать вывод, что с криптографией тебе не по пути, потому что дальше будет сложнее 🤤

#ЧБШ

Многие из вас уже знают, что Google недавно представил две новые концепции хранения данных в Android в рамках библиотеки DataStore. Библиотека представляет из себя два хранилища: Preferences DataStore и Proto DataStore. Первое это привычные и понятные всем SharedPreferences, но немного поумневшие и типобезопасные. А вот второе уже гораздо интереснее. как следует из названия это хранилище работает со схемами ProtoBuf и обещает нам много интересного. Единственное, чего оно не обещает из коробки это шифрования данных. Это довольно странно в 2020-м году и при условии, что у Google уже есть все нужные компоненты для реализации. Ну нет так нет. Я написал эту интеграцию сам и хочу поделиться ей с вами. Там никакого космоса, просто Tink встроенный в proto-сериализатор данных. Код можно слить с GitHub-а и поиграться с ним.

https://github.com/Fi5t/secured-datastore

#4developers #cryptography

Google создает новую команду безопасности Android. Ее задачей будет искать уявимости в “особо важных” приложениях из Play Store.

Под особо важными имеются в виду приложения для отслеживания контактов COVID-19, приложения связанные с выборами и т.п.

Кто-нибудь хочет сменить работу? 😉

#google

https://xakep.ru/2020/10/02/special-android-security-team/

Вот и настал тот день, чтобы сказать "И вот этот день настал!". Пока нас потихоньку накрывает второй волной сами знаете чего (🦠) и мы опять переходим на удаленную работу, есть идея провести это время с пользой. Хочу провести online митап по безопасности android-приложений, операционной системы и смежным темам. Конечно же без вашего участия ничего не получиться, поэтому с сегодняшнего дня открываю CFP. Если у вас есть интересный релевантный опыт, то буду рад включить вас в программу митапа.

Если вы новичок в вопросах выступлений на коференциях, то я и программный коммитет поможем вам определитья с темой и направлением доклада, а также подготовиться к самому докладу.

Для тех, кто не любит Google формы - пишите мне в личку. Ваша нелюбовь к Google еще не повод не выступать на митапе 😉

https://forms.gle/nNVZBemesFsFmwvSA

Запилил на хабре небольшой пост про наше сообщество. Поддержите лайком-репостом пожалуйста.

https://habr.com/en/post/522512/

Вышел Tink 1.5.0 c security фиксом для Java и Android касающимся проблем с целостностью шифротекста. Серьезность этой баги невысокая, но сама суть интересная - она позволяет злоумышленнику создавать немного измененный шифротекст, который все еще расшифровывается до того же открытого текста. Это возможно из-за особенностей работы с Unicode в Java.

#4developers #cryptography #tink

https://github.com/advisories/GHSA-g5vf-v6wf-7w2r

Провел тут небольшой воркшоп для начинающих исследователей безопасности приложений на конференции Google DevFest 2020. Наконец-то подъехала запись, поэтому решил поделиться материалами с вами.

#workshop #4beginners

https://github.com/Fi5t/workshop-devfest-2020

Чердачок Брюса Шнайера. Выпуск №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 тут), что не очень то подходит для проприетарного ПО, которые вы чаще всего пишите.

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